Karpathy知识编译法构建个人LLM知识库实践指南

过去两年，RAG（检索增强生成）几乎成了大语言模型应用的“标配”。无论是企业知识库、智能客服还是个人笔记系统，大家的第一反应都是：把文档切块、向量化、存入向量数据库，查询时检索、再拼进提示词。

这套流程确实有效，但用久了，一些痛点也逐渐浮现：一篇结构化的论文，切成512个令牌的碎片后，上下文关系可能就丢失了；嵌入向量的相似度并不总是等于语义相关度，换个说法就可能检索不到；同一份文档，每次查询时模型都要重新“阅读”原文，造成了算力浪费；原始文档之间缺乏显式关联，知识只是“堆”在数据库里。

这些问题并非RAG的缺陷，而是其设计哲学决定的——它的本质是“检索时理解”。而近期，Andrej Karpathy提出了一种反直觉的思路：为什么不在知识入库时，就让大语言模型先理解好呢？

一、背景：RAG的繁荣与困境

RAG范式虽然普及，但其固有的“分块损失”、“检索不稳定”、“重复理解”和“知识碎片化”等问题，促使业界思考更优的知识管理方案。这引出了Karpathy的核心理念：知识编译。

二、Karpathy的核心思想：知识编译

LLM Wiki架构的核心思想可以概括为一句话：“不要让大语言模型在查询时去理解原始文档，而是提前让模型把文档‘编译’成结构化的知识。”

这借鉴了编程语言的思路：源代码需要编译成优化后的字节码再执行。同理，原始文档（如PDF）经过“摄入”过程，被转化为结构化的Wiki页面，查询时直接使用这些已编译的知识。

“编译”意味着什么？它意味着将一篇20页的论文，提炼成500字的核心摘要；将格式五花八门的资料，统一为结构化的Markdown；将文档间隐含的关联，变成显式的双向链接。最关键的是，查询时模型不再需要“临时抱佛脚”，而是直接读取已经整理好的知识。

这里有一个关键洞察：如果知识库足够精炼，可能就不再需要复杂的向量检索。想象一下，100个Wiki页面，每个平均500令牌，总共才5万令牌——以当前动辄128K甚至200K上下文窗口的大模型来说，完全可以将整个Wiki塞进上下文进行处理。

三、架构设计：三层分离与Schema契约

3.1 三层架构

LLM Wiki采用清晰的三层架构，自下而上分别是：

1. Schema层（行为契约）：定义模型的工作规则、页面模板和质量标准，核心文件是AGENTS.md和SCHEMA.md。
2. 原始资料层（Raw Sources）：只读的原始资料，可通过API或本地文件访问。
3. Wiki层（已编译的知识图谱）：由模型维护的结构化Markdown知识库，包含实体、概念、摘要等。

这种分离确保了职责清晰，原始资料与编译后的知识互不干扰。

3.2 Schema：最核心的设计

在Karpathy的设计中，Schema是整个系统最核心的概念。它并非数据库模式，而是一份“给大语言模型看的行为契约”。

Schema主要分为两个文件：

• AGENTS.md：定义全局行为规范，包括工作流（如摄入、查询、检查）和通用约定。
• SCHEMA.md：定义实例级约束，如页面模板、标签分类、质量阈值等。

Schema解决的核心问题是标准化与可控性。更强大之处在于：修改Schema就能修改模型行为，无需改动代码。想让摘要更详细？只需修改SCHEMA.md里的字数限制。想新增一种页面类型？在模板里添加定义即可。

3.3 五类页面

Wiki内部包含五种职责分明的页面类型：摘要页、实体页、概念页、综合页和查询页。每种页面都有严格的模板，通常包含YAML前置元数据、标准化的Markdown结构以及[[双向链接]]用于交叉引用。

四、三大核心操作

4.1 摄入（Ingest）：知识的“编译”过程

摄入是LLM Wiki最关键的操作，其完整流程是将原始文档转化为结构化的Wiki页面。以一篇论文为例，核心逻辑包括：模型生成摘要并创建摘要页；模型提取实体并创建或更新实体页；模型提取概念并创建或更新概念页；最后更新双向链接、索引和日志。

这里的设计亮点是“模型回调机制”：所有与大语言模型相关的功能都通过回调函数注入。当不提供回调时，系统可退化为简单实现（例如截取前500字符作为摘要）。这使得系统能够灵活接入不同的模型服务，也便于测试。

4.2 查询（Query）：先Wiki后原始资料

查询的设计哲学是：先查询已编译的知识（Wiki层），再查询原始资料，最后综合生成答案。流程上，用户提问后，系统会先搜索Wiki（采用轻量级BM25算法），再搜索原始知识库，然后组装上下文由模型生成答案，并判断该问答是否值得归档为新的Wiki页面。

搜索部分实现了一个轻量级BM25算法，而非简单的子字符串匹配。BM25支持多关键词分词、TF-IDF加权和标题匹配加权，在保持轻量（无需外部依赖或向量数据库）的同时，提供了更好的检索相关性。

查询还有一个精妙的设计：有价值的问答会被自动归档成新的Wiki页面。这意味着Wiki会通过使用不断“自我增长”——问得越多，知识库越丰富。

4.3 健康检查（Lint）：维护知识库质量

Lint操作借鉴了代码静态分析的理念，定期检查Wiki的“健康度”，主要包括：识别“孤儿页面”（无入链的页面）、检测“断链”（指向不存在的页面）、标记“过时内容”（如超过30天未更新）以及发现“矛盾信息”（需要模型辅助检测跨页面矛盾）。最终，系统会输出一个健康分数和详细报告，帮助维护者了解知识库状态。

五、Schema驱动模型：修改文档即修改行为

这是整个系统最具欣赏价值的设计。所有对大语言模型的调用，都会自动将Schema内容作为系统提示词的一部分注入。这意味着：

• 当模型提取实体时，它会遵循SCHEMA.md中定义的实体页面模板。
• 当模型生成摘要时，它会参考Schema里的写作风格指南和字数限制。
• 当模型判断是否归档时，它会依据Schema里设定的归档标准。

想改变模型的行为？修改Markdown文件即可，不需要动一行代码。这在传统的RAG系统中是难以想象的——通常你需要修改提示词、调整代码逻辑、甚至重新部署服务。

六、与RAG的本质区别

LLM Wiki与RAG并非简单的替代关系，而是互补。正如Karpathy所言：“RAG是用技术复杂度来换取处理海量内容的能力。LLM Wiki则是用前期的精炼工作，来换取查询时的简单与准确。”两者适用于不同的场景和需求。

七、适用场景与局限

适合场景

• 个人研究者：用于追踪领域论文、建立个人知识体系。
• 技术学习者：整理学习笔记、关联不同技术概念。
• 内容创作者：管理写作素材、积累特定领域的知识。
• 独立开发者：维护个人技术文档、沉淀项目相关知识。

不适合场景

• 企业级知识库：数据量过于庞大，编译成本过高。
• 实时问答系统：内容更新频繁，Wiki的编译开销不划算。
• 多人协作场景：并发编辑Markdown文件容易产生冲突。

八、总结

Karpathy提出的LLM Wiki，并非要“碘伏RAG”，而是提供了一种不同的知识管理哲学：

• 编译优于检索：提前让模型理解文档，而非查询时临时理解。
• 质量优于数量：500字的精炼摘要可能比5000字的原文更有用。
• 显式关联优于隐式：[[双向链接]]比嵌入向量空间的相似度更明确。
• 简单优于复杂：如果能全量加载上下文，或许就不需要复杂的检索系统。
• Schema驱动：修改文档即可修改系统行为，降低了技术参与门槛。

对于个人知识管理而言，这种方式有其独特魅力：你的知识库不再是一个黑盒的向量数据库，而是一组精心组织、人类可读的Markdown文件。你可以用工具浏览其知识图谱，可以直接阅读任何页面，可以手动编辑修正模型的输出，也可以通过修改Schema来调整整个系统的行为。

知识管理的终极形态，或许就是让AI协助我们维护一个“活”的Wiki——一个能够持续积累、复利增长的知识产物。