LLM Wiki — Karpathy gist · blog.jalen.cool

Karpathy 在 gist 里抛出的一种用 LLM 维护个人/团队知识库的模式。这篇本身是元文档——本 vault 的 CLAUDE schema 就是基于它实例化的。

核心论点

主流的 RAG 范式是"查询时即时检索 raw 文档片段然后生成答案"。LLM 每次都在从头重新发现知识,没有累积。

替代方案:LLM 增量构建并持续维护一个 wiki——结构化的、互链的 markdown 集合,坐落在 raw 源和你之间。新源进来时,LLM 不只是为日后检索建索引,而是编译进现有 wiki:更新实体页、修订主题摘要、标注新数据与旧声明的冲突。

关键句:wiki 是持久的、复利的产物。交叉引用已经在那儿,矛盾已经被标过,综述已经反映你读过的一切。

参见独立概念页 LLM-Wiki。简记:

Ingest — 一次一个源,LLM 读 → 跟你讨论要点 → 写摘要页 → 更新 index → 跨页面更新实体/概念页 → 追加 log。单次 ingest 触及 10–15 页。
Query — 对 wiki 提问。LLM 先读 index 定位,再钻进去综合。好的回答应该被回填成新 wiki 页(对比表、综述、新发现的连接),否则会消失在聊天历史里。
Lint — 周期性体检:矛盾、被新源 supersede 的过时声明、孤儿页、应单独成页的高频实体、缺链、可补的数据空缺。

index.md 内容导向。每页一行链接 + 一句摘要。LLM 每次 ingest 必更。"中等规模(~100 源、几百页)够用,无需 embedding-based RAG 基础设施。"
log.md 时间导向。追加式记录。固定前缀(## [YYYY-MM-DD] op | title)→ grep "^## \[" log.md | tail -5 可解析。

Karpathy 把这个模式溯源到 Vannevar Bush 1945 年的 Memex:私人的、主动策展的、文档间联系本身比文档更有价值的知识库。Bush 没解决的是"谁来维护"——LLM 解决了。

NotebookLM、ChatGPT 文件上传、大多数 RAG 系统走的是前一种路线。

文中提到但本 vault 暂不为各工具单独开页(单一来源不够沉淀,见铁律 7),仅记录:

Obsidian Web Clipper — 浏览器扩展,网页转 markdown,塞进 raw
Obsidian Graph View — 看 wiki 形状的最佳方式
Marp — markdown 幻灯片格式,Obsidian 有插件
Dataview — Obsidian 插件,frontmatter 查询
qmd(https://github.com/tobi/qmd)— 本地 markdown 搜索引擎(BM25 + 向量 + LLM rerank),CLI + MCP server。规模上来后可考虑替代 index.md。
图片下载:Settings → Files and links 设 attachment 到 raw/assets/,绑快捷键。LLM 读不了内联图——先读文本,再单独看图。

"The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping."

"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

文档有意保持抽象——它描述模式,不规定实现。具体目录结构、schema 约定、页面格式、工具——全看你的领域、偏好、所选 LLM。