Zenn
✍️

自作ナレッジベースをCLIで構築してみた話

に公開
ナレッジベース
tech

はじめに

「知識は、蓄積されることで力になる」──。そう信じてきたはずの私が、ある日ふと気づいたのは、自分の記した知見が“生きていない”という事実でした。書き溜めたノート、保存されたMarkdownファイル、クラウドに散在するドキュメントたち。それらは、検索できず、連想できず、結局また書き直されるばかり。

ナレッジとは、アクセスできてこそ意味がある。

そんな思いから始めたのが、「CLIで完結する、思想に根ざした自前のナレッジベース」構築でした。ナレッジはGoogle検索では届かない、“自分だけの文脈”を孕んでいます。それゆえに、その文脈を保持したまま構造化し、再活用できる仕組みが必要だと考えました。

この記事では、その思想と実装の両面から、自作CLI型ナレッジベースの設計哲学と実装方法を紹介します。

アーキテクチャの背後にある構造思想

技術的な構成はシンプルです：

  • CLIツール（Python製）
  • Haystack（Retriever-Readerモデル）
  • Markdown文書ベースの知識体系

しかしこの裏には、「知識を意味単位で再構成し、問いに応じて応答可能な状態に保つ」という設計思想があります。人は単に全文検索ではなく、“文脈に合った意味”を探している。だからこそ、ベクトル空間による意味検索と、その意味に対して言語的なスコアを与えるReaderの導入が、思想と実装の接続点になります。

CLI設計：問いへの動線をデザインする

CLIとは単なる操作手段ではなく、“知の入り口”です。

scripts/
  cli/
    commands/
      add.py
      search.py
      tags.py

意図したコマンド群

  • kb add: 文書の「意味単位」への変換と登録。
  • kb search: 「問い」に対する文脈的な応答の抽出。
  • kb tags: 構造内のメタ的観点を横断的に把握。

各コマンドは、単なる機能ではなく「知識と対話する形式」を持っています。つまり、CLIを通して“静的な情報”を“対話可能な知”へと変換する仕掛けです。

検索モデルに込めた思想：意味との距離を測る

Haystackを採用した理由は、「文書を意味空間に投影し、類似概念のあいだに連続性を持たせる」ことでした。

retriever = DensePassageRetriever(...)
reader = FARMReader(...)
pipe = ExtractiveQAPipeline(reader, retriever)

ここで重要なのは、「検索」が単なるキーワードマッチではなく、**“意味の近傍”をたどる行為”**であるということ。Retrieverが構造的に近いものを引き、Readerが言語的に確からしさをスコア付けする。この二段階は、まさに“他者の問いに応じる”ような知の振る舞いを模倣しています。

実装で気づいた限界と可能性

Markdown処理

テキストの構造を壊さずに意味を抽出するのは容易ではありませんでした。しかし「構造を捨てると意味も捨てる」ことに気づき、最終的にはMarkdownの構造そのものを軽量なメタ情報として保持しました。

検索の曖昧さ

ベクトル検索は文脈を扱う反面、誤認も起こします。その不確かさに対して、「確からしさのスコア」と「ヒューマンフィードバックによる修正余地」の両立が今後の課題です。

今後の構想：知のエージェント化へ

このCLIは、単なる自動化ではなく「知識との対話を設計する最初の一歩」です。

  • Web UIはその文脈にビジュアルを与えるために
  • Slack連携は日常言語と接続するために
  • YAMLやタグは構造化された知の軸として

そして将来的には、「このナレッジベース自体が、自ら学び、自己最適化する知的エージェント」になることを目指しています。

終わりに：思想と実装の共進化

このプロジェクトは、単に「便利なツールを作った」では終わりません。設計とは思想を形にする行為であり、実装とは思想を他者に開く行為です。

「なぜそれを作るのか？」「どうしてこの形なのか？」という問いに、自ら答え続けるプロセスこそが、真に価値ある知の構築だと思っています。

この記録が、誰かの“問い”への小さなヒントになれば幸いです。

Discussion