---
title: LLM Wiki Pattern
created: 2026-06-28
updated: 2026-06-28
type: concept
tags: [wiki, knowledge-base, synthesis, agent, markdown]
sources: [raw/articles/karpathy-llm-wiki-2026.md, raw/articles/nashsu-llm-wiki-2026.md, raw/articles/hermes-research-llm-wiki-skill-2026.md]
confidence: medium
---

# LLM Wiki Pattern

LLM Wiki は、LLM が curated raw sources を読み、持続的な Markdown wiki に統合していく知識管理パターン。通常の [[rag-vs-compiled-wiki|RAG]] のように質問ごとに断片検索からやり直すのではなく、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 をどう保つか。