sage-wikiのグラフ記憶を文書コンパイルから検証する
sage-wiki は、AI エージェントと人間が一緒に構築してクエリを実行するグラフ メモリおよび知識ベースです。書類をドロップインします。 LLM コンパイラは、それらをナレッジ グラフを備えた相互リンクされた Wiki に変換します。 One Go バイナリは、個人用ボールトからチーム ハブ、そして会社のナレッジ グラフまで拡張します。
ひと目でわかる
- これは何？
- 文書を相互リンクしたWikiと知識グラフへ変換し、MCPとMarkdownで検索するsage-wikiの構成を読み解きます。
- 誰に向いている？
- 文書、コード、メモを自分で管理し、エージェントと人間が同じ知識基盤を使いたい個人やチームに向きます。グラフ化、出典、エンティティ解決はREADMEに具体的な説明がありますが、LLM費用、検索精度、権限設定、運用負荷は環境依存です。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 3 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
文書からWikiができる仕組み
sage-wikiは文書を投入するとLLMコンパイラが要約、概念抽出、相互リンクされた記事の生成を行うGo製の知識基盤です。人間はプレーンなMarkdownやObsidian、TUI、Web UIから読み、エージェントはMCPツールから問い合わせます。同じデータを異なる入口で扱う設計なので、閲覧用のWikiとエージェント用の検索を別々に同期する必要がない点が特徴です。
READMEはpapers、notes、code、emailを入力候補として挙げていますが、各形式の取り込み条件や失敗時の扱いをすべて示してはいません。最初は機密性のない小さなフォルダを使い、生成された記事、リンク、元文書の対応を確認するのが妥当です。
三つの検索を混ぜる設計
検索は語彙検索、ベクトル検索、グラフ近接の三経路を融合します。BM25で語句を探し、ベクトルで意味の近い断片を拾い、クエリから種になったエンティティの近傍を一定深さでたどる流れです。グラフが空なら結果は従来とバイト単位で同一になるとREADMEは説明しています。導入途中でグラフ機能を有効にしても、検索全体を一度に作り替える設計ではありません。
`search.hybrid_weight_graph`の重みやクエリ拡張、再ランキングは結果に影響します。READMEの説明だけでは最適値は決まりません。代表的な質問を固定し、語彙だけ、ベクトルだけ、グラフ併用の結果と引用を比較すると、グラフを有効にする価値を測れます。
出典付きエッジと矛盾
任意の構造化出力パス`ontology.triples`はsubject、relation、objectの三つ組を抽出し、文書ごとにLLM呼び出しを一回追加します。evidence、confidence、source_docを持つ関係なら、結論がどの文書のどの記述に基づくかを追跡できます。初期設定ではAPIキーを勝手に消費しないオプトイン方式です。
エンティティ解決ではK8sとKubernetesのような別名を一つのノードへまとめる候補を作りますが、提案は既定でレビュー対象です。二時点のエッジを持ち、矛盾する事実が古いエッジを無効にする仕組みも説明されています。自動統合を前提にせず、レビュー画面で元文書、信頼度、変更前後を確認する運用が必要です。
個人、チーム、会社の段階
個人用途では既存Obsidian vaultを`init --vault`で重ね、ローカルモデルを使い、必要時だけグラフパスを有効にできます。チーム用途ではgitやセルフホストサーバーでWikiを共有し、エンティティ解決案とoutput trustを共同レビューします。ハブを介して複数Wikiを連携する説明もあります。
会社規模ではPostgreSQL/pgvectorへの移行、metrics、認証の前段、tiered compilationが候補です。10万件超の文書を対象に高速な索引とLLM予算の配分を行う設計を掲げていますが、実際の速度や費用の保証ではありません。保管先と認証を変えるほど確認項目も増えるため、個人構成からそのまま本番構成へ拡張しないことが大切です。
MCPと運用データ
READMEは19個のMCPツールと生成されたskill fileを挙げ、いつ検索し、いつcaptureやcompileを行うかをエージェントに伝える構成を示しています。`wiki_graph_query`はグラフの辺に基づく回答を返し、`ontology query --entity kubernetes --depth 3 --direction both`や`provenance "service mesh"`のCLI例があります。
問い合わせ結果が検証まで隔離されるoutput trustも含まれます。実機では、入力文書の追加、再コンパイル、引用の表示、矛盾した文書の投入、未確認結果の扱いを順に観察してください。MCPサーバーに接続するエージェントの権限やログの保存先はREADMEの機能説明だけでは確定しないため、設定ファイルと運用環境で補う必要があります。
sage-wikiの検証記録を固定する
リリースにはv0.2.10などの版があり、プロジェクトは1.0前の段階です。概念の整理や社内検索の試作には具体性がありますが、長期互換性や本番のサービス水準は資料から判断できません。MITライセンスもコード利用条件を示すもので、取り込む文書の権利やLLM提供者のデータ条件を解決するものではありません。
検証用ワークスペースを作り、設定の版、モデル、入力文書のハッシュ、生成記事、引用、検索ログを保存してください。`ontology.triples`と`ontology.resolve`を別々に試し、LLM呼び出し数とレビュー対象が増えるかを確かめると、機能の便利さと運用コストを同じ記録で判断できます。
少量の文書で、記事生成後に元の文章へ戻れるか、引用のconfidenceが表示されるか、同じ質問を再実行したときの結果が変わるかを確認します。検索の深さ、候補のレビュー、PostgreSQLへの移行は別々の試験に分け、LLMの呼び出し回数と保存された出典を照合してください。これらを記録すれば、グラフを追加した効果を機能名だけで判断せずに済みます。入力の種類ごとに生成記事の差分も保存し、誤った関係がレビューを通らず回答へ混ざらないかを確かめます。
編集部の結論
文書、コード、メモを自分で管理し、エージェントと人間が同じ知識基盤を使いたい個人やチームに向きます。グラフ化、出典、エンティティ解決はREADMEに具体的な説明がありますが、LLM費用、検索精度、権限設定、運用負荷は環境依存です。まず少量の文書でcompileとwiki_graph_queryを実行し、出典と未検証出力を確認してください。
コミュニティノート