その後、引き続きちまちまと作って遊んでいます。現状のもので、改めてまとめてみました。
簡単に
ドキュメントからObsidianで扱えるWikiにしちゃう。また、ソースとWikiの両方からRAGもできるようにしてみる。
動機
Andrej KarpathyさんがGitHub Gistで公開した「LLM Wiki」の考え方を読んで、「RAG（検索拡張生成）で毎回AIに知識をゼロから探させるより、そもそもちゃんと整理・蓄積された知識ベースを作るのが基本だよな」と改めて感じました。
LLMが自動でまとめた知識は、必ずしも人間にとって読みやすい状態である必要はないのかもしれません。しかし、そもそも綺麗にまとまったWikiがあれば、人間がさっと見るだけで十分なことも多いんですよね。 だったら、LLMにWikiの編纂といった「面倒な作業」を任せつつ、人間はそれを読んで編集したり、方向性を書き換えたりする本来の使い方をした方が絶対に便利です。
そこで、自分なりの解釈を加えて「ローカルで自律的に成長するWikiシステム」を作ってみることにしました。
構成と仕組み
Wikiの閲覧・編集の道具（統合開発環境）としては、「Obsidian」を使います。今更ですけど、Obsidianはシンプルで使いやすいですね。知識がネットワーク状に繋がるグラフビューなども強力で、もっと早く試してみれば良かったです。
LLM Wikiの考え方を使って、全体のデータ構造は大きく２つのレイヤーに分けました。
- A. 一次情報レイヤー (Raw Source)
- 内容: パースされたPDFなどの生テキスト。
- 役割: 「消えてはならない事実」の保管庫。AIが推論する際の揺るぎない根拠になります。
- B. Wikiレイヤー (Compiled Wiki)
- 内容: AIが要約・統合し、人間がレビュー・承認した構造化Markdown。
- 役割: 概念間の繋がり、全体像の把握、および「まとめられた知識」の保管庫。
質問に対してAIに回答させる（RAGとして使う）ときは、Aの「一次情報 (Raw)」と、Bの「AIが整理し人間が編集したWiki」の両方を検索対象にします。
RAG回答の流れとしては以下の画像のようになります。
使ってみてわかったこと
実際に作って使ってみて痛感するのは、「わざわざAIにチャットで質問するまでもなく、Wikiを読むだけで事足りることも多い」ということです…。情報を整理していれば、人間はそれを眺めて整えるのも悪くないです。
まだまだ作っている最中ですが、少し形になってきました。
出力の例
ドキュメント毎のWiki（自動作成）
語句ごとのConcepts（自動作成）
ネットワーク
RAGの答えの例
補正リトリーバル拡張生成 (CRAG) とはどのような手法ですか？また、なぜハルシネーションの抑制に効果的なのですか？
### ハルシネーション抑制に効果的な理由
1. **取得段階でのノイズ除去**: *retrieval evaluator* が文書の正確性をスコアリングし、信頼度の低い情報の使用を抑制します。
2. **生成後の自己評価とフィードバック**: 生成されたテキストは即時「修正取得」ステップで評価され、誤情報がプロセスに浸透するのを防ぎます。
3. **長文推論への適応**: 各ステップごとに動的フィードバックを挟むことで、誤りの伝搬を顕著に防ぎます。
