摘要RAG 干了五年Karpathy 一篇 gist 扔出来直接把知识库的重心从检索挪到了“编译”。本文拆解 LLM Wiki 的三层架构、核心操作、Google OKF 规范以及生产环境里那些让人头秃的坑。概览这篇文章干这么几件事把 RAG 的老毛病扒干净说清楚为什么每次提问都在重新发明轮子。拆解 LLM Wiki 的底层逻辑知识只“编译”一次然后持续保鲜。手把手讲三层架构怎么搭收录、提问、体检三个核心操作怎么跑通。解读 Google 刚发布的 Open Knowledge Format (OKF) v0.2 规范特别是 frontmatter 里那些信任信号怎么用。把生产环境里踩过的坑全列出来包括规模天花板、内容漂移、实体对齐这些硬伤。最后聊点纯个人偏见为什么我说两年内“知识库”的定义会变。RAG 的老毛病每次都在重新发明轮子RAG 这玩意儿搞技术的都熟。2020 年 Facebook AI 那篇论文Lewis 等人NeurIPS 2020定了调大致流程三步走文档切块塞进向量库。提问时检索相关片段。把片段喂给大模型拼答案。NotebookLM、ChatGPT 文件上传、市面上九成知识库产品全是这个套路。用着挺爽。但有个巨坑。LLM 每次回答问题都是从零开始重新发现知识。你问一个需要综合五份文档的刁钻问题它就得现场找碎片、拼起来、推理一遍。答完就忘。下次再想问类似的对不起重新来一遍。没有任何积累。打个接地气的比方你请了个记性为零的顶级顾问每次见面都得把病历从头讲一遍。顾问水平确实高但你迟早会疯。LLM Wiki 是什么知识“编译”一次持续保鲜Karpathy 的思路换了个方向。说白了就是别让 LLM 在提问时才去读原始文档让它平时就把知识“编译”成一份持续维护的 Wiki。这里有个关键比喻Obsidian 是 IDELLM 是程序员Wiki 是代码库。知识在这套体系里是编译产物不是运行时临时算的。交叉引用已经建好了矛盾已经标注了综述已经反映了所有读过的资料。每多一份资料、每问一个问题Wiki 就厚一层。这才是“积累”该有的样子。LLM Wiki 三层架构原始层、Wiki 层、Schema 层想搭这套系统架构上权责分明分三层原始层Raw sources你喂进去的论文、文章、数据不可变。LLM 只读不写。这是事实源头碰不得。Wiki 层一堆互相链接的 Markdown 文件——实体页、概念页、对比页、综述页。LLM 全权拥有这一层建页面、改页面、维护交叉引用。你只负责读。Schema 层一个约定文件比如 CLAUDE.md 或 AGENTS.md告诉 LLM 这个 Wiki 的目录结构、命名规范、收录流程。这是把 LLM 从“闲聊机器人”变成“有纪律的图书管理员”的关键。没有它LLM 就是个通用聊天机器人有了它LLM 才是个“懂规矩的 Wiki 维护者”。LLM Wiki 核心操作收录、提问、体检架构搭好了日常就跑这三个闭环操作。1. 收录Ingest操作指南丢一份新资料进原始层LLM 读完后一口气干这几件事写摘要页。更新总索引。更新所有相关实体页。标注和旧结论冲突的地方。往日志里追加一条记录。一份资料可能动 10-15 个页面。你可以一篇篇喂、全程盯着也可以批量灌、事后抽查。workflow 由你定写进 Schema 里。2. 提问Query操作指南基于已综合好的 Wiki 提问LLM 走两步先查索引找到相关页。读完再答附引用。关键设计是好答案可以归档回 Wiki 变成新页面。一次深度对比、一个意外发现的关联不该消失在聊天记录里——这样你的探索本身也在给知识库复利。3. 体检Lint操作指南定期让 LLM 给 Wiki 做健康检查。查什么页面间的矛盾。被新资料推翻的过时结论。没有入链的孤儿页。被反复提到却没有自己页面的概念。缺失的交叉引用。LLM 还擅长建议“下一步该找什么资料、该问什么问题”。这是 Wiki 不烂尾的续命机制。4. 两个关键索引文件替代向量库Wiki 长大的过程中靠两个特殊文件导航不需要 embedding 基础设施index.md内容导向的总目录。每个页面一行——链接加一句话摘要按类别分组。每次收录必更新。提问时 LLM 先读索引锁定相关页再钻进去细读。实测在约 100 份资料、几百个页面的规模下好使得很。log.md时间线日志只追加不修改。记录每次收录、提问、体检。小技巧每条目用统一前缀比如## [2026-04-02] ingest | 文章标题这样grep ^## \[ log.md | tail -5就能查最近动态也让 LLM 知道最近干过什么。Google OKF 规范详解给 LLM Wiki 定标准如果说 Karpathy 给的是“民间偏方”Google Cloud 六月份干的事就是“收编正规军”——发布 Open Knowledge FormatOKF把 LLM Wiki 模式正式化成一个开放规范。OKF 的设计克制得让人感动就是 Markdown 加 YAML frontmatter唯一必填字段是type。没有 SDK没有运行时没有专用数据库。你能cat一个文件就能读 OKF你能git clone就能分发它。OKF v0.1 基础结构Bundle 与 ConceptOKF 的基本单位叫Bundle知识包——一个自包含的 Markdown 文件目录树就是分发的最小单元。里面每个知识点叫Concept概念一个概念一个文件文件路径去掉.md后缀就是它的概念 ID比如tables/users.md→tables/users。每个概念文件就两部分举个数据表定义的例子--- type: BigQuery Table title: Customer Orders description: 每行一个已完成订单 resource: https://console.cloud.google.com/bigquery?pacmedsalestorders tags: [sales, orders] --- # Schema | 列名 | 类型 | 说明 | |---|---|---| | order_id | STRING | 全局唯一订单 ID | | customer_id | STRING | 外键见 [customers](/tables/customers.md) | # Joins 与 [customers](/tables/customers.md) 通过 customer_id 关联。规则就三条硬性的每个非保留文件必须有可解析的 YAML frontmatter。frontmatter 必须有非空type。保留文件名index.md目录索引和log.md更新日志不许挪用。其他全是软性建议。消费方必须容忍未知类型、未知字段、断链——宽容到这个份上就是为了让任何生产者、任何消费者都能即插即用。概念之间用普通 Markdown 链接互联目录树只是父子关系链接才构成真正的知识图谱。链接推荐用/开头的包内绝对路径文件移动时不会断。OKF v0.2 信任信号AI 写的东西凭啥信真正有意思的是 v0.2解决的是一个扎心问题当 Wiki 是 AI 写的你凭啥信它人写的 Wiki 出了错可以找人背锅。AI 一晚上生成一万个概念出了错找谁v0.2 的答案是五组字段全部写在 frontmatter 里让你在读正文之前就能判断这页可不可信溯源sources这页内容从哪些材料提炼的。每条来源能带客观信号——谁写的author、被用了多少次usage_count、最后更新时间last_modified。正文里具体某句话的出处用 Markdown 脚注挂在来源 ID 上逐条归因而不是文末甩一个参考文献列表。信任generated/verifiedgenerated记谁生成的、何时。verified记谁核验过、何时两者故意分开——写的人未必是核验的人。核验者带human:前缀的就是“人工复核”档全是机器核验的就是“机器确认”档没核验的就是“未验证”档。三个信任等级消费者自己决定信哪档——比如高管看板只展示人工复核过的指标一句 frontmatter 过滤就搞定。新鲜度stale_after一个绝对日期过期判断就是日期比大小。故意不用相对 TTL因为“读取时再过 30 天”这种判断依赖读取时刻非 LLM 程序没法确定性地算。生命周期statusdraft草稿→stable稳定→deprecated已废弃。废弃页面保留不删为了历史查询可复现但不再推荐给新工作。算数担保Attested Computation这是最狠的。一个指标页不只说“营收是这个数”还带一段被认可的计算方式比如一段 SQL和配套检验程序。处理流程Agent 只准填声明过的参数比如year: 2026不准自己编 SQL执行器跑完后返回执行凭证job_id、实际执行的 SQL、结果确定性校验器无 LLM 参与把凭证里实际跑的 SQL 和被认可的 SQL 做规范化比对——改写一个表名、加个过滤条件、少个 JOIN校验直接失败数字拒绝展示。定义层面的“核验过没有”和运行层面的“这次跑的对不对”被拆成两件事各自独立判断。注意一个设计哲学OKF 只记录信号不打“可信度评分”。评分是主观的、会过期的信号是客观的谁拿到都能自己算。这个取舍老架构师看了会点头。深度解析DIKW 金字塔的自动化老学院派有个经典框架Ackoff 1989 年提的 DIKW 金字塔数据 → 信息 → 知识 → 理解 → 智慧。RAG 卡在下面两层它检索的是数据和信息现场拼答案拼完就扔。LLM Wiki 干的是第三层的事把信息持续编译成结构化的、互相咬合的知识。至于智慧那是你的活儿。Karpathy 说得很清楚人负责选资料、提好问题、思考意义LLM 负责其他一切杂活。生产环境踩坑记录别急着把向量库删了想法很丰满落地一写代码发现全是 bug。LLM Wiki 的坑评论区里真刀真枪干过的人已经踩出来了漂移drift这是生产环境用户报告的头号故障收录新资料时 agent 漏更新交叉引用页面悄悄过期。所以体检lint不是可选项是续命项。有团队直接挂定时任务跑矛盾检测不然图谱慢慢就烂了。规模天花板纯index.md导航在几百个页面内好使得很到几千个页面就开始喘。过了这个量级还是得加搜索引擎——绕了一圈检索又回来了。写入时的实体对齐新资料里提到的“张伟”到底是已有实体还是同名新人这个去重判断目前没有优雅解法恰恰是这个模式“要么复利、要么蔓生”的分水岭。贵收录一份资料要动 10-15 个页面token 烧得比 RAG 检索猛多了。一次性问答场景RAG 便宜得多。垃圾进垃圾复利LLM 写错的东西也会被“编译”进 Wiki还会被后续页面引用。没有人工抽检错误会利滚利。这也是 Google 火急火燎给 v0.2 加信任信号的原因。所以我的判断是一次性查资料的薄场景RAG 照旧需要长期深耕的领域Wiki 碾压。二者不是替代关系是分层关系——检索退化为导航层Wiki 才是沉淀层。最后一点纯偏见[偏激观点]我赌两年内“知识库”这个词的定义会变。今天它等于“向量数据库 检索器”两年后它会等于“一个 git 仓库里面装着 AI 维护的 Markdown”。向量库不会消失但会缩回基础设施层像今天的倒排索引一样没人再拿它当卖点。当年做高并发的时候我们就是这么被坑惨的——总以为缓存是优化项后来才发现缓存即架构。RAG 是查询Wiki 是缓存。查询谁都会写能活过三年的缓存设计才是本事。你的文档库打算继续每次从零检索还是今晚就开始让 AI 给你攒一份会复利的 Wiki参考资料Lewis et al.,Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020. https://arxiv.org/abs/2005.11401Andrej Karpathy,LLM Wiki. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94fGoogle Cloud,Introducing the Open Knowledge Format. https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharingGoogle Cloud,Open Knowledge Format v0.2 Adds Trust Signals. https://cloud.google.com/blog/products/data-analytics/okf-v0-2-adds-trust-signalsOpen Knowledge Format Specification. https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.mdRussell Ackoff,From Data to Wisdom, 1989. https://faculty.ung.edu/kmelton/documents/datawisdom.pdfJennifer Rowley,The Wisdom Hierarchy: Representations of the DIKW Hierarchy, 2007. https://journals.sagepub.com/doi/10.1177/0165551506070706本文作者来自 Adgine 团队专注 GEO 工具研发。