2026年，知识库重新回归

当业界还在争论RAG（检索增强生成）是否是知识库的最优解时，一位传奇人物的最新实践再次搅动了这个领域。就在一个多月前，OpenAI创始团队成员、刚刚加入Anthropic的AI大牛Karpathy发布了他日常使用的知识库形态。与传统基于向量召回的知识库不同，这套方案让LLM全面接手知识库的管理工作，将知识"编译"成结构化的wiki摘要，从而实现更高效的知识调用与复用。

概述

这套方案的核心是一个精心设计的三层目录结构： • raw目录：存储原始文档，作为知识的"源文件" • wiki目录：存储经过LLM处理的各个wiki页面，包括摘要、实体、概念等，这是知识的"编译产物" • schema目录：存储各种规则、提示词、约束，确保流程的可复用性 基于这个架构，系统提供了三种核心操作：Ingest（摄入）、Query（查询）、Linter（健康检查）。其中最关键的是摄入操作——LLM会将原始知识"编译"成wiki摘要，而不是像传统RAG那样每次都读取原始知识。这使得LLM Wiki成为了知识的"编译器"，而非简单的"解释器"。

LLM Wiki的三重架构

Karpathy的开源方式同样别具一格——没有完整的项目仓库，而是直接在GitHub上开源了一个"llm-wiki.md"文件。这种极简主义引发了大量社区复现，但绝大部分都局限于文本数据。 受此启发，有团队开始探索更激进的应用：将代码直接塞进知识库。面对MySQL（6.36GB）、PostgreSQL（958MB）这样的庞然大物，他们创新性地采用Submodule管理原始代码，通过两阶段生成方案处理wiki页面：先由LLM扫描仓库元信息了解整体架构，再针对每个模块阅读具体代码生成wiki内容。这种解析方式让LLM能够自主决定模块划分，确保每个模块的代码规模适中。

突破边界：将代码仓库纳入知识库

在代码仓库的解析过程中，如何对齐概念和模块名称是一个关键挑战。团队设计了三条规则：阅读已有概念、总结3-5个新概念、限制新概念数量。这一机制鼓励LLM匹配并更新已有概念，而非新建，确保wiki结构不会过于发散。 更巧妙的是，他们在解析代码仓库之前，提前将其他仓库的wiki目录注入上下文，要求LLM在划分模块时必须参考已有的模块标题。这样，划分模块的过程就从"填空题"变成了"选择题"，大幅提升了模块对齐的准确性。

概念对齐与模块划分

在某次横向对比MySQL、PostgreSQL和NeuG三个数据库事务管理能力的测试中，使用wiki的实验组与使用原始代码的对照组表现出相近的回答质量——都能精准提取MVCC、并发控制、隔离级别、WAL等关键模块。差异在于对照组加入了更多代码细节，而实验组更倾向于介绍整体架构设计。 然而在资源消耗上，两者差距悬殊：使用wiki后，通过极少的token就可以解答问题，整体提升率在6倍左右。由于token生成速度相对固定，token消耗与执行时间大致成正比，整体执行时间同样存在4倍以上的差异。这不仅节省了成本，更节省了宝贵的时间。

如有侵权，请联系删除。