stoneskin (Mr. Sun)

Personal homepage of Mr Sun - AI Solutions Architect, Tech Lead & AWS Cloud Specialist: resume, selected projects, and teaching archive

Karpathy《LLM Wiki》导读:把知识一次编译进 wiki,而不是每次重算

← 返回目录

来源(一手原文):Andrej Karpathy《LLM Wiki》,GitHub Gist,2026-04-04,https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f 详细摘要见 karpathy-llm-wiki-summary.md;本篇是导读(为什么值得看、主线、怎么读)。 背景:Karpathy 2026-04-03 先发推”LLM Knowledge Bases”,次日贴出这份 gist。他称之为 idea file——不是代码,是拿去贴给自己的 agent 的想法文件;48 小时内 5,000+ stars。

一句话结论

RAG 每次都从头找答案、不积累;LLM Wiki 让 LLM 把知识一次编译进一个持久的、互相链接的 markdown wiki,越用越富,而不是每次重算。

为什么值得看

叙事主线

  1. RAG 的毛病:每次提问都从头拼碎片,不积累;问一个要综合五份文档的问题,LLM 每次都得重新找、重新拼。
  2. 换成编译:LLM 增量地建一个持久 wiki,夹在你和原始资料之间;新资料进来,它读、抽、合进已有页面、标出与旧结论的矛盾,综合随之进化。
  3. 三层 + 三操作:raw(不可改的原文)/ wiki(LLM 写的 markdown)/ schema(告诉 LLM 怎么维护的纪律文件);ingest(吃进新资料)、query(对着 wiki 问,好的答案也存回 wiki)、lint(定期体检:矛盾、过期、孤页、缺页)。
  4. 规模化:index.md(目录,先读它再钻进去)+ log.md(时间线,可 grep);~100 份资料、几百页的规模下,index 就够用,不用 embedding;再大就上本地搜索(qmd)。
  5. 为什么能成:维护知识库最烦的不是读和想,是记账(更新交叉引用、保持摘要最新、标矛盾、保一致)。人会因为维护成本超过价值而放弃;LLM 不会烦,一次能改 15 个文件,维护成本近零。

摘要第 10 节:一个现成的实现 Graphify——这个模式在代码库上的落地(确定性解析、边带置信度、git hook 自动重建)。

怎么读(分级)

跟你的咬合