2.6 KiB
title, created, updated, type, tags, sources, confidence
| title | created | updated | type | tags | sources | confidence | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| LLM Wiki Pattern | 2026-06-28 | 2026-06-28 | concept |
|
|
medium |
LLM Wiki Pattern
LLM Wiki は、LLM が curated raw sources を読み、持続的な Markdown wiki に統合していく知識管理パターン。通常の rag-vs-compiled-wiki のように質問ごとに断片検索からやり直すのではなく、source ingest 時点で entity page、concept page、comparison、index、log を更新し、知識を「蓄積済みの synthesis」として残す。
このパターンの価値は compounding にある。cross-reference、矛盾、更新履歴、既存 synthesis が wiki 内に残るため、後続の query や ingest が過去の作業を再利用できる。wiki-maintenance-loop が回るほど、単なるファイル置き場ではなく、読みやすい中間知識層になる。
人間の役割は source selection、問いの設計、レビュー、方向づけ。LLM の役割は要約、相互リンク、既存ページ更新、矛盾検出、index/log 更新などの bookkeeping。閲覧・探索には obsidian のような wikilink 対応エディタが合う。
Implementation Surface
Karpathy の原案は抽象的な運用パターンだが、実装形態は複数ある。Hermes の llm-wiki skill は Markdown directory、SCHEMA.md、index.md、log.md、raw source frontmatter、agent の手順を組み合わせて、軽量な file-based workflow として実行する。一方、llm-wiki-app は同じ発想を desktop app、persistent ingest queue、folder watch、knowledge graph、semantic search、web clipper、local HTTP API/MCP server まで含む product として具体化している。
この差は「単純な Markdown vault を agent が保守する」のか、「専用アプリが ingest/search/API を統合する」のかという設計選択。小さく始めるなら skill + obsidian で十分だが、source 数が増え、画像/PDF、queue、graph、API 連携が必要になると app 型の surface が効いてくる可能性がある。
Open Questions
- どの粒度でページを分けると、後から検索・更新しやすいか。
- チーム運用では、LLM 更新をどこまで自動化し、どこを人間レビューにするか。
- 小規模 wiki では index.md だけで十分か、いつ CLI/MCP search が必要になるか。
- 専用アプリ化した場合、raw source と wiki page の source of truth をどう保つか。