企业官网建设流程全解析

摘要：RAG 干了五年，Karpathy 一篇 gist 扔出来，直接把知识库的重心从检索挪到了“编译”。本文拆解 LLM Wiki 的三层架构、核心操作、Google OKF 规范，以及生产环境里那些让人头秃的坑。

概览

这篇文章干这么几件事：

1. 把 RAG 的老毛病扒干净，说清楚为什么每次提问都在重新发明轮子。
2. 拆解 LLM Wiki 的底层逻辑：知识只“编译”一次，然后持续保鲜。
3. 手把手讲三层架构怎么搭，收录、提问、体检三个核心操作怎么跑通。
4. 解读 Google 刚发布的 Open Knowledge Format (OKF) v0.2 规范，特别是 frontmatter 里那些信任信号怎么用。
5. 把生产环境里踩过的坑全列出来，包括规模天花板、内容漂移、实体对齐这些硬伤。
6. 最后聊点纯个人偏见：为什么我说两年内，“知识库”的定义会变。

RAG 的老毛病：每次都在重新发明轮子

RAG 这玩意儿，搞技术的都熟。2020 年 Facebook AI 那篇论文（Lewis 等人，NeurIPS 2020）定了调，大致流程三步走：

1. 文档切块，塞进向量库。
2. 提问时检索相关片段。
3. 把片段喂给大模型拼答案。

NotebookLM、ChatGPT 文件上传、市面上九成知识库产品，全是这个套路。

用着挺爽。但有个巨坑。

LLM 每次回答问题，都是从零开始重新发现知识。

你问一个需要综合五份文档的刁钻问题，它就得现场找碎片、拼起来、推理一遍。答完就忘。下次再想问类似的，对不起，重新来一遍。没有任何积累。

打个接地气的比方：你请了个记性为零的顶级顾问，每次见面都得把病历从头讲一遍。顾问水平确实高，但你迟早会疯。

LLM Wiki 是什么：知识“编译”一次，持续保鲜

Karpathy 的思路换了个方向。说白了就是：别让 LLM 在提问时才去读原始文档，让它平时就把知识“编译”成一份持续维护的 Wiki。

这里有个关键比喻：Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。

知识在这套体系里是编译产物，不是运行时临时算的。交叉引用已经建好了，矛盾已经标注了，综述已经反映了所有读过的资料。每多一份资料、每问一个问题，Wiki 就厚一层。

这才是“积累”该有的样子。

LLM Wiki 三层架构：原始层、Wiki 层、Schema 层

想搭这套系统，架构上权责分明，分三层：

1. 原始层（Raw sources）

   • 你喂进去的论文、文章、数据，不可变。
   • LLM 只读不写。这是事实源头，碰不得。

2. Wiki 层

   • 一堆互相链接的 Markdown 文件——实体页、概念页、对比页、综述页。
   • LLM 全权拥有这一层，建页面、改页面、维护交叉引用。你只负责读。

3. Schema 层

   • 一个约定文件（比如 CLAUDE.md 或 AGENTS.md），告诉 LLM 这个 Wiki 的目录结构、命名规范、收录流程。
   • 这是把 LLM 从“闲聊机器人”变成“有纪律的图书管理员”的关键。没有它，LLM 就是个通用聊天机器人；有了它，LLM 才是个“懂规矩的 Wiki 维护者”。

LLM Wiki 核心操作：收录、提问、体检

架构搭好了，日常就跑这三个闭环操作。

1. 收录（Ingest）操作指南

丢一份新资料进原始层，LLM 读完后一口气干这几件事：

1. 写摘要页。
2. 更新总索引。
3. 更新所有相关实体页。
4. 标注和旧结论冲突的地方。
5. 往日志里追加一条记录。

一份资料可能动 10-15 个页面。你可以一篇篇喂、全程盯着，也可以批量灌、事后抽查。workflow 由你定，写进 Schema 里。

2. 提问（Query）操作指南

基于已综合好的 Wiki 提问，LLM 走两步：

1. 先查索引找到相关页。
2. 读完再答，附引用。

关键设计是：好答案可以归档回 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 Format（OKF），把 LLM Wiki 模式正式化成一个开放规范。

OKF 的设计克制得让人感动：就是 Markdown 加 YAML frontmatter，唯一必填字段是type。没有 SDK，没有运行时，没有专用数据库。你能cat一个文件，就能读 OKF；你能git clone，就能分发它。

OKF v0.1 基础结构：Bundle 与 Concept

OKF 的基本单位叫Bundle（知识包）——一个自包含的 Markdown 文件目录树，就是分发的最小单元。里面每个知识点叫Concept（概念），一个概念一个文件，文件路径去掉.md后缀就是它的概念 ID（比如tables/users.md→tables/users）。

每个概念文件就两部分，举个数据表定义的例子：

--- type: BigQuery Table title: Customer Orders description: 每行一个已完成订单 resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders tags: [sales, orders] --- # Schema | 列名 | 类型 | 说明 | |---|---|---| | `order_id` | STRING | 全局唯一订单 ID | | `customer_id` | STRING | 外键，见 [customers](/tables/customers.md) | # Joins 与 [customers](/tables/customers.md) 通过 `customer_id` 关联。

规则就三条硬性的：

1. 每个非保留文件必须有可解析的 YAML frontmatter。
2. frontmatter 必须有非空type。
3. 保留文件名index.md（目录索引）和log.md（更新日志）不许挪用。

其他全是软性建议。消费方必须容忍未知类型、未知字段、断链——宽容到这个份上，就是为了让任何生产者、任何消费者都能即插即用。

概念之间用普通 Markdown 链接互联，目录树只是父子关系，链接才构成真正的知识图谱。链接推荐用/开头的包内绝对路径，文件移动时不会断。

OKF v0.2 信任信号：AI 写的东西凭啥信？

真正有意思的是 v0.2，解决的是一个扎心问题：当 Wiki 是 AI 写的，你凭啥信它？

人写的 Wiki 出了错，可以找人背锅。AI 一晚上生成一万个概念，出了错找谁？v0.2 的答案是五组字段，全部写在 frontmatter 里，让你在读正文之前就能判断这页可不可信：

1. 溯源（sources）
   • 这页内容从哪些材料提炼的。
   • 每条来源能带客观信号——谁写的（author）、被用了多少次（usage_count）、最后更新时间（last_modified）。
   • 正文里具体某句话的出处，用 Markdown 脚注挂在来源 ID 上，逐条归因，而不是文末甩一个参考文献列表。
2. 信任（generated/verified）
   • generated记谁生成的、何时。
   • verified记谁核验过、何时，两者故意分开——写的人未必是核验的人。
   • 核验者带human:前缀的就是“人工复核”档，全是机器核验的就是“机器确认”档，没核验的就是“未验证”档。三个信任等级，消费者自己决定信哪档——比如高管看板只展示人工复核过的指标，一句 frontmatter 过滤就搞定。
3. 新鲜度（stale_after）
   • 一个绝对日期，过期判断就是日期比大小。
   • 故意不用相对 TTL，因为“读取时再过 30 天”这种判断依赖读取时刻，非 LLM 程序没法确定性地算。
4. 生命周期（status）
   • draft（草稿）→stable（稳定）→deprecated（已废弃）。
   • 废弃页面保留不删，为了历史查询可复现，但不再推荐给新工作。
5. 算数担保（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 的坑，评论区里真刀真枪干过的人已经踩出来了：

1. 漂移（drift）
   • 这是生产环境用户报告的头号故障：收录新资料时 agent 漏更新交叉引用，页面悄悄过期。
   • 所以体检（lint）不是可选项，是续命项。有团队直接挂定时任务跑矛盾检测，不然图谱慢慢就烂了。
2. 规模天花板
   • 纯index.md导航在几百个页面内好使得很，到几千个页面就开始喘。
   • 过了这个量级，还是得加搜索引擎——绕了一圈，检索又回来了。
3. 写入时的实体对齐
   • 新资料里提到的“张伟”，到底是已有实体还是同名新人？
   • 这个去重判断目前没有优雅解法，恰恰是这个模式“要么复利、要么蔓生”的分水岭。
4. 贵
   • 收录一份资料要动 10-15 个页面，token 烧得比 RAG 检索猛多了。
   • 一次性问答场景，RAG 便宜得多。
5. 垃圾进，垃圾复利
   • LLM 写错的东西也会被“编译”进 Wiki，还会被后续页面引用。
   • 没有人工抽检，错误会利滚利。这也是 Google 火急火燎给 v0.2 加信任信号的原因。

所以我的判断是：一次性查资料的薄场景，RAG 照旧；需要长期深耕的领域，Wiki 碾压。二者不是替代关系，是分层关系——检索退化为导航层，Wiki 才是沉淀层。

最后，一点纯偏见

[偏激观点]：我赌两年内，“知识库”这个词的定义会变。今天它等于“向量数据库 + 检索器”，两年后它会等于“一个 git 仓库，里面装着 AI 维护的 Markdown”。向量库不会消失，但会缩回基础设施层，像今天的倒排索引一样，没人再拿它当卖点。

当年做高并发的时候，我们就是这么被坑惨的——总以为缓存是优化项，后来才发现缓存即架构。RAG 是查询，Wiki 是缓存。查询谁都会写，能活过三年的缓存设计才是本事。

你的文档库，打算继续每次从零检索，还是今晚就开始让 AI 给你攒一份会复利的 Wiki？

参考资料

1. Lewis et al.,Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020. https://arxiv.org/abs/2005.11401
2. Andrej Karpathy,LLM Wiki. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
3. Google Cloud,Introducing the Open Knowledge Format. https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing
4. Google Cloud,Open Knowledge Format v0.2 Adds Trust Signals. https://cloud.google.com/blog/products/data-analytics/okf-v0-2-adds-trust-signals
5. Open Knowledge Format Specification. https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
6. Russell Ackoff,From Data to Wisdom, 1989. https://faculty.ung.edu/kmelton/documents/datawisdom.pdf
7. Jennifer Rowley,The Wisdom Hierarchy: Representations of the DIKW Hierarchy, 2007. https://journals.sagepub.com/doi/10.1177/0165551506070706

本文作者来自 Adgine 团队，专注 GEO 工具研发。