← 返回博客

编译你的知识,而非检索它:LLM 知识库揭示了 Agent 记忆的未来

RAG 检索片段。知识编译构建结构化、可进化的 wiki。这个区别至关重要——尤其当 Agent 需要记忆、共享和改进它们所知道的知识时。

编译你的知识,而非检索它:LLM 知识库揭示了 Agent 记忆的未来

Andrej Karpathy 最近描述了一套个人工作流,引起了我们的注意——不是因为它在技术上多新颖,而是因为它独立收敛到了我们在 Rotifer Protocol 中已经形式化了数月的模式上。

这套工作流是:将原始文档(论文、文章、仓库、数据集)收集到一个目录中。使用 LLM 增量"编译"为一个 Markdown wiki——结构化的概念文章、反向链接、分类索引。在 Obsidian 中查看。用 LLM Agent 对 wiki 进行问答。将答案归档回 wiki。定期运行 "linting" 检查一致性并补充缺失数据。

关键一句话:"我以为需要 fancy RAG,但 LLM 自动维护索引文件和摘要就够了。"

本文探讨这句话为何重要,它揭示了 Agent 记忆的什么未来,以及当知识编译从单用户笔记本走向自主 Agent 网络时会发生什么。


1. RAG 的默认假设

过去三年,"AI 系统如何使用外部知识?"的默认答案一直是检索增强生成(RAG)。这个模式大家很熟悉:

  1. 把文档切成片段
  2. 向量嵌入
  3. 查询时找最近邻向量
  4. 把片段粘贴到上下文中
  5. 让 LLM 合成答案

RAG 有效。它用最少的基础设施解决了"LLM 不知道我的数据"的问题。但 RAG 有一个结构性盲区:它检索片段而不理解它们之间的关系。

向量数据库知道第 4,271 号片段和第 8,903 号片段在语义上接近。但它不知道第 4,271 号第 8,903 号矛盾,也不知道两者都是第 112 号中某个一般性原则的特例,更不知道第 8,903 号已经被一项更新的发现所取代——而那项发现还没被切分。

RAG 执行的是信息检索。Karpathy 的工作流执行的是知识编译


2. 编译 vs. 检索

这个区分是精确的。在软件工程中,解释执行源代码和编译它之间的区别众所周知:

解释执行 (RAG) 编译 (Knowledge Compilation)
输入 原始片段 原始文档
过程 查询时进行相似度搜索 提前进行结构化转换
输出 粘贴到上下文中的片段 组织化、交叉链接的知识制品
关系 隐式(向量近邻) 显式(反向链接、分类、层次)
质量信号 相关性分数 结构完整性(linting、一致性检查)
增量更新 重新嵌入新片段 增量编译到已有结构中

Karpathy 的工作流是一个编译器。原始输入进入,结构化、互相链接、被索引的输出产出。LLM 不只是找到相关文本——它理解了领域的结构,足以维护一个关于它的连贯 wiki。

这个区分干净地映射到了 Rotifer Protocol 中的一个概念:原始数据与编译后的中间表示(IR)之间的区别。正如协议将 TypeScript Gene 编译为 WASM IR——将人类可读逻辑转化为可移植、可评估、可组合的格式——知识编译将原始文档转化为结构化、可查询、可传播的知识制品。

知识系统的瓶颈,原来不在检索。瓶颈在编译——那个将噪音转化为信号的结构化转换过程。


3. 反馈循环:查询即贡献

Karpathy 工作流中最有揭示力的细节是查询之后发生了什么:

"我经常把输出归档回 wiki,为后续查询增强它。所以我自己的探索和查询总是在知识库中'累加'的。"

这不是一个小小的用户体验便利。这是一个基本的架构属性:每次查询同时也是一次贡献。

在传统知识管理系统中——wiki、数据库、文档库——读取和写入是分离的操作,由不同角色执行。读者消费;编辑者生产。除非有人显式维护,系统会随时间退化。

在 Karpathy 的系统中,使用知识库就在改进知识库。每次查询生成结构化答案并归档为新的 wiki 页面。提问这个行为本身创造了新知识,未来的问题可以在此基础上构建。

这个属性——消费和生产是同一个操作——是让系统真正进化而非仅仅归档的关键。知识库不只是存储信息;它从交互中生长。

Rotifer Protocol 的 Gene 抽象——模块化、可评估适应度、可竞争选择的逻辑单元——最初是为代码设计的。但"查询即贡献"模式暗示了一个自然延伸:如果代码可以是 Gene,知识为什么不行?

一个结构化的知识制品——回答问题、提供上下文、辅助决策——与执行任务的代码 Gene 具有同样的形状。两者都是模块化的。两者都可以被评估质量。两者都可以被更好的替代品取代。协议的现有基础设施——Arena 竞争、适应度评估、水平逻辑迁移——本质上并不关心 Gene 包含的是算法还是一个精心策展的知识体系。进化机制是基质无关的。


4. 知识 Linting

Karpathy 描述了对 wiki 运行"健康检查":

"我对 wiki 运行了一些 LLM '健康检查',例如发现不一致的数据、补充缺失数据(使用网络搜索)、为新文章候选项发现有趣的连接等,以增量清理 wiki 并增强其整体数据完整性。"

这是应用于知识的质量保证——它直接映射到驱动进化系统的选择压力。

Rotifer Protocol 已经通过 F(g) 这个乘法适应度函数评估代码 Gene,综合成功率、使用率、鲁棒性和成本。同样的逻辑自然适用于知识:它准确吗?它真的有用吗?它与其他知识一致吗?它是最新的吗?乘法结构毫不宽容——一个全面但不准确的知识制品失败的方式,与一个输出结果错误的快速算法完全一样。任何关键维度为零,整个乘积归零。

Karpathy 通过定期 linting 手动施加这种压力。在协议级系统中,同样的压力可以通过竞争评估在整个网络中持续运作,而非依赖个人策展。


5. 隔离问题——再次出现

如果你读过我们之前的分析——关于 Karpathy 的 autoresearch 项目——这个模式会很眼熟。autoresearch 展示了进化式代码优化——变异 train.py、通过 val_bpb 评估适应度、保留或丢弃、重复。在隔离环境中很出色,但每个 fork 的发现都锁定在那个 fork 里。

同样的隔离问题适用于 LLM 知识库。Karpathy 构建了一个优秀的个人知识系统。但他的 wiki 活在他的笔记本上。他编译的知识、他查询派生的洞察、他一致性检查过的文章——只有一个人受益。

现在乘以一千。想象一千个研究者,每个人在重叠的主题上构建自己的 LLM 知识库。每个人独立编译同样的论文。每个人独立发现同样的联系。每个人独立 lint 同样的不一致。

这再次是前 HGT 时代的进化瓶颈——不是针对代码,而是针对知识。每个 Agent 重新发明每个洞察。集体学习的速率受限于个体编译的速率。


6. 可传播的知识

Rotifer Protocol 已经通过**水平逻辑迁移(HLT)**解决了代码隔离问题——高适应度的 Gene 通过 Arena(协议的竞争评估环境)在 Agent 间传播。同样的机制无需任何架构修改就能应用于知识。

考虑这个动态:一个 Agent 将原始文档编译为结构化知识制品。该制品进入 Arena 竞争,与覆盖同一领域的其他知识制品对比评估。更高质量的编译排名更高。获胜的制品通过 HLT 传播——其他 Agent 采用它们。每个采用 Agent 的查询进一步精炼知识(查询即贡献),生成更新版本重新进入竞争。生态系统收敛到每个领域最准确、最有用的知识编译。

关键洞察:知识编译是创造步骤;Arena 竞争是选择步骤;HLT 是传播步骤。 三者共同构成一个完整的进化循环——与代码 Gene 的循环结构完全一致,自然延伸到知识领域。


7. 编译为 Code as Gene 增加了什么

"Code as Gene" 论题——模块化代码单元可以参与进化动态——从一开始就是 Rotifer Protocol 的核心抽象。编译隐喻将这一论题从代码延伸到知识:

代码 知识
原始输入 源代码(TypeScript 等) 文档(论文、文章、数据集)
编译 TypeScript → WASM IR 原始文档 → 结构化、互联的 Markdown
评估 代码是否完成了任务? 知识是否准确回答了问题?
选择 更好的算法淘汰更差的 更准确的编译淘汰不准确的
传播 高适应度代码通过 HLT 传播 高质量知识通过 HLT 传播

协议的现有基础设施——Arena 评估、F(g) 适应度评分、HLT 传播、沙箱隔离、L0 不可变约束——不需要为知识管理建立单独的系统。知识制品与代码 Gene 结构同构:模块化、可评估、可替代、可传播。

这正是编译隐喻特别贴切之处。Rotifer IR 编译器将多种源语言转化为单一可移植格式(WASM + 自定义段)。知识编译将多种源材料转化为单一结构化格式。在两种情况下,编译都是创造价值的昂贵步骤;执行和检索相对廉价。


8. 从个人 Wiki 到集体智能

Karpathy 的工作流处于一条自然轨迹的起点:

当下:人在回路中。 单个用户收集原始数据,指导 LLM 编译,审查输出,提问,策展 wiki。用户的判断是主要的选择压力。这是 Karpathy 的系统目前所处的位置——它已经非常高效。

下一步:半自主编译。 Agent 独立识别知识缺口,获取新的原始材料,编译并整合,运行质量检查——用户提供偶尔的方向指引并审查高层级输出。最佳编译传播到其他 Agent。用户从编译者转变为策展者。

最终:自主知识进化。 网络中的多个 Agent 在没有直接人工参与的情况下编译、评估和传播知识。集体智能从应用于知识制品的选择压力中涌现。人类的角色从策展知识转变为定义评估标准和设定宪法约束。

每个阶段保留核心架构:原始 → 编译 → 结构化 → 查询 → 反馈。变化的是人工投入与自主运行的比例,以及选择压力运作的规模(单用户 → 单 Agent → Agent 网络)。


9. 为什么不直接用 RAG?

公平地说:RAG 有效。对于许多应用——客服聊天机器人、文档问答、内部搜索——对原始片段的向量检索足够且实用。RAG 是知识系统的 grep:快速、简单、有用。

grep 不编译代码。它找文本。对于复杂的知识领域——概念之间的关系重要、一致性必须维护、新信息必须与现有理解整合而非简单追加到片段库——编译产出更好的结果。

证据来自 Karpathy 自己的经验。他的知识库约 100 篇文章、约 40 万字。在这个规模下,一个维护良好的索引加摘要让 LLM 无需向量搜索就能导航整个结构。LLM 读索引、定位相关文章、阅读它们,然后在完整的结构上下文中合成答案。

这之所以可能,是因为知识被编译了——组织成带有显式分类、反向链接和摘要的文章。在 RAG 系统中,同样的 40 万字会变成 2,000 多个片段,没有显式关系。LLM 看到的是碰巧在向量空间中距离最近的片段,错过了编译后的 wiki 能让人一目了然的结构性联系。

当知识库增长到单个 LLM 无法维护完整索引的规模时,编译方法与 RAG 的扩展方式不同。与其添加更多向量并期望相似度搜索找到正确片段,编译后的知识自然分解为特定领域的模块——每个内部一致、外部链接、独立可评估。进化生态系统通过专业化和竞争处理规模,而非通过更大的向量数据库。


10. 产品洞察

Karpathy 以一个产品观察结束了他的描述:

"我认为这里有一个 incredible new product 的空间,而非一堆 hacky scripts。"

我们同意。他描述的工作流——原始数据摄入、LLM 驱动的编译、结构化 wiki、带反馈的交互式问答、质量 linting——不是一个小众的个人生产力工具。这是 AI Agent 应该如何管理知识的基本模式。

产品机会不是"更好的 RAG"。而是一条知识编译管道,其中:

这正是 Rotifer Protocol 的进化基础设施——Gene、Arena、HLT——自然延伸的方向:不是个人工具,而是一个知识与代码并肩竞争、进化和传播的协议级能力。


结论

两个系统。两种规模。一次收敛。

Karpathy 的 autoresearch 证明了进化式代码优化有效——变异、评估、选择、重复。他的 LLM Knowledge Bases 证明了同样的模式适用于知识——编译、查询、精炼、累积。

两者结合覆盖了 Agent 需要改进的两个维度:它们运行的代码和它们使用的知识。它们的共同点是编译步骤——那个昂贵的、创造结构的转换,将原始材料变成可组合、可评估、可用的东西。

Rotifer Protocol 添加了个体系统无法提供的:跨 Agent 传播、质量竞争性选择、共享知识的安全保障、以及让知识进化与代码进化同样严谨的形式化框架。

从个人 wiki 到集体知识的路径,映射了从隔离 fork 到水平基因转移的路径。Karpathy 构建了一个优雅的个人系统。问题是:当知识在网络规模下编译、竞争和传播时,会发生什么?

这正是 Rotifer Protocol 要回答的问题。


延伸阅读

  1. Rotifer Protocol 规范——Gene Standard、Fitness Model、Arena Mechanism. rotifer.dev/docs
  2. 从 autoresearch 到集体进化:Karpathy 项目揭示了 AI Agent 的下一步——我们之前对 Karpathy autoresearch 项目的分析
  3. 从 Skill 到 Gene:为什么 AI Agent 需要超越工具范式——进化式 Agent 架构的基础论证

Rotifer Protocol 在 Apache 2.0 + Safety Clause 下开源。官网:rotifer.dev。CLI:npm i -g @rotifer/playground