当前位置：首页 > news >正文

Karpathy LLM Wiki 实践：用“知识编译“替代 RAG，构建个人知识库

news 2026/4/19 12:00:59

❝
Andrej Karpathy 提出了 LLM Wiki 架构——一种完全不同于 RAG 的知识管理范式。本文将深入解读其核心思想，并分享我从零实现一个 LLM Wiki 系统的完整实践。
❞

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

过去两年，RAG（Retrieval-Augmented Generation）几乎成了 LLM 应用的"标配"。无论是企业知识库、智能客服还是个人笔记系统，大家的第一反应都是：把文档切块 → 向量化 → 存入向量数据库 → 查询时检索 → 拼进 Prompt。

这套流程确实有效，但用久了你会发现一些痛点：

「分块损失」：一篇结构化的论文，切成 512 token 的碎片后，上下文关系全丢了
「检索不稳定」：Embedding 相似度并不等于语义相关度，换个说法就可能检索不到
「每次重新理解」：同一份文档，每次查询时 LLM 都要重新"阅读"原文，浪费算力
「知识碎片化」：原始文档之间没有显式关联，知识只是"堆"在数据库里

这些问题并非 RAG 的 Bug，而是其设计哲学决定的——「RAG 本质上是"检索时理解"」。

而 Karpathy 提出了一个反直觉的思路：「为什么不在入库时就让 LLM 理解好？」

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

Karpathy 的 LLM Wiki 架构，核心就一句话：

❝
「"不要让 LLM 在查询时去理解原始文档，而是提前让 LLM 把文档'编译'成结构化的知识。"」
❞

这跟编程语言的编译器是同一个思路：

源代码 (.py) → 编译 → 字节码 (已优化) → 执行 → 结果 原始文档 (PDF) → Ingest → Wiki 页面 (结构化) → Query → 答案

「"编译"意味着什么？」

一篇 20 页的论文，核心贡献可能只需 500 字描述
格式五花八门的原始资料（PDF、网页、笔记），统一成 Markdown
文档之间隐含的关联（同一个概念在不同论文里出现），变成显式的双向链接
查询时不再需要 LLM "临时抱佛脚"，而是直接读已经整理好的知识

关键洞察在于：「如果你的知识库足够精炼，你根本不需要复杂的向量检索」。100 个 Wiki 页面，每个平均 500 tokens，总共才 50,000 tokens——现在的 LLM 动辄 128K 甚至 200K 的上下文窗口，完全可以把整个 Wiki 塞进去。

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

3.1 三层架构

LLM Wiki 采用清晰的三层架构：

┌─────────────────────────────────────────────┐ │ Layer 3: Wiki（已编译的知识图谱） │ │ entities/ concepts/ summaries/ synthesis/ │ │ queries/ index.md │ ├─────────────────────────────────────────────┤ │ Layer 2: Raw Sources（原始资料） │ │ IMA API / 本地文件 / 外部数据源 │ ├─────────────────────────────────────────────┤ │ Layer 1: Schema（行为契约） │ │ AGENTS.md + SCHEMA.md │ └─────────────────────────────────────────────┘

「Schema 层」：定义 LLM 的工作规则、页面模板、质量标准
「Wiki 层」：LLM 维护的结构化 Markdown 知识库
「Raw Sources 层」：只读的原始资料，通过 API 访问

3.2 Schema：最核心的设计

在 Karpathy 的设计中，「Schema 是整个系统最核心的概念」。它不是数据库 Schema，而是一份「给 LLM 看的"行为契约"」。

Schema 分为两个文件：

AGENTS.md：全局行为规范，定义工作流（Ingest/Query/Lint）和通用约定
SCHEMA.md：实例级约束，定义页面模板、标签分类、质量阈值

「Schema 解决的核心问题：」

问题	没有 Schema	有 Schema
格式	混乱不统一	严格模板、标准结构
质量	长短不一、详略不同	质量稳定、可预测
维护	知识库逐渐混乱	知识库持续整洁

更强大的是——「修改 Schema 就能修改 LLM 行为，不需要改一行代码」。想让摘要更详细？改 SCHEMA.md 里的字数限制就行。想新增一种页面类型？在模板里加一个定义即可。

3.3 五类页面

Wiki 中有五种页面类型，各司其职：

类型	目录	内容	示例
「Entities」	`entities/`	人物、组织、项目	`geoffrey-hinton.md`
「Concepts」	`concepts/`	技术概念、理论	`transformer.md`
「Summaries」	`summaries/`	源文档摘要	`attention-is-all-you-need.md`
「Synthesis」	`synthesis/`	跨文档综合分析	`evolution-of-nlp.md`
「Queries」	`queries/`	归档的高质量问答	`query-20240115-scaling-laws.md`

每种页面都有严格的模板：YAML frontmatter 元数据 + 标准化的 Markdown 结构 +[[双向链接]]交叉引用。

四、三大核心操作

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

Ingest 是 LLM Wiki 最关键的操作，完整流程如下：

原始文档 → 内容提取 → LLM 生成摘要 → 创建 Summary 页面 → LLM 提取实体 → 创建/更新 Entity 页面 → LLM 提取概念 → 创建/更新 Concept 页面 → 更新双向链接 → 更新 index.md → 记录 log.md

以摄入一篇论文为例，代码的核心逻辑是这样的：

def _ingest_content(self, source_id, source_title, content, source_type, metadata): # 1. LLM 生成摘要 summary = self._summarize(content) # 2. 创建摘要页 summary_page = self.wiki.create_page( title=source_title, category="summaries", content=summary, frontmatter={"source_id": source_id, "tags": ["summary"]}, ) # 3. LLM 提取并创建/更新实体页 for entity in self._extract_entities(content): self._update_entity_page(entity, summary_slug) # 4. LLM 提取并创建/更新概念页 for concept in self._extract_concepts(content): self._update_concept_page(concept, summary_slug) # 5. 更新索引和日志 self.wiki.write_index_file() self.wiki.append_log("ingest", details, source=source_id)

这里的设计亮点是「LLM 回调机制」：所有 LLM 相关功能（摘要、提取、问答）都通过回调函数注入，不提供回调时退化为简单实现（如截取前 500 字符做摘要）。这让系统可以灵活接入不同的 LLM 服务，也方便测试。

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

Query 的设计哲学是——「先查已编译的知识（Wiki），再查原始资料（Raw Sources），最后综合生成答案」：

用户提问 → 搜索 Wiki（BM25 算法）→ 搜索 IMA 原始知识库 → 组装上下文 → LLM 综合生成答案 → 判断是否值得归档 → （是）创建 Query 页面

搜索部分我实现了一个「轻量级 BM25 算法」，而非简单的子字符串匹配：

def search(self, query, category=None, top_k=20): query_tokens = self._tokenize(query) # BM25 参数 k1, b, title_boost = 1.5, 0.75, 3.0 # 计算每个查询词的 IDF for token in set(query_tokens): doc_freq = sum(1for doc in doc_contents if token in doc) idf_scores[token] = math.log( (n_docs - doc_freq + 0.5) / (doc_freq + 0.5) + 1.0 ) # 对每个文档计算 BM25 分数 + 标题加权 for page in candidate_pages: score = sum(idf * tf_norm for each query_token) if token in title_tokens: score += idf * title_boost # 标题匹配额外加权

BM25 相比简单子字符串匹配的优势：支持多关键词分词、TF-IDF 加权、标题匹配加权。同时保持轻量——不需要外部依赖，也不需要向量数据库。

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

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

Lint 操作借鉴了代码静态分析的理念，定期检查 Wiki 的"健康度"：

「孤儿页面」：没有任何入链的页面（说明知识孤立）
「断链」：指向不存在页面的链接
「过时内容」：超过 30 天未更新的页面（天数从 SCHEMA.md 读取）
「矛盾信息」：跨页面的矛盾内容（需要 LLM 检测）

最终输出一个健康分数和详细报告：

🔍 Wiki Health Report Health Score: 85.0% | Issue Type | Count | |------------------|-------| | Orphan Pages | 2 | | Broken Links | 1 | | Outdated Pages | 3 | | Contradictions | 0 |

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

这是整个系统我最欣赏的设计。所有 LLM 调用都会自动注入 Schema 作为 System Prompt：

class WikiLLMFunctions: def _build_system_prompt(self, task_instruction=""): parts = [ "You are an intelligent wiki assistant.", "You MUST follow the rules and conventions defined below.", ] if self._agents_content: parts.append("--- AGENTS.md (Global Behavior Rules) ---") parts.append(self._agents_content) if self._schema_content: parts.append("--- SCHEMA.md (Instance-Specific Constraints) ---") parts.append(self._schema_content) if task_instruction: parts.append(f"--- Current Task ---\n{task_instruction}") return"\n\n".join(parts)

这意味着：

「提取实体时」，LLM 会遵循 SCHEMA.md 中定义的 Entity 页面模板，输出符合规范的结构化数据
「生成摘要时」，LLM 会参考 Schema 里的写作风格指南和字数限制
「判断是否归档时」，LLM 会根据 Schema 里的归档标准做出判断

「想改变 LLM 的行为？修改 Markdown 文件即可，不需要动一行代码。」这在传统 RAG 系统中是不可想象的——通常你需要改 Prompt、改代码逻辑、重新部署。

六、与 RAG 的本质区别

维度	传统 RAG	LLM Wiki
「核心思想」	原始数据 + 智能检索	预编译 + 全量上下文
「数据处理」	分块存储，保留原文	LLM 预处理，提炼精华
「检索方式」	向量相似度搜索	BM25 关键词匹配（或全量加载）
「信息密度」	低（包含冗余）	高（经过精炼）
「知识关联」	隐式（Embedding 空间）	显式（`[[双向链接]]`）
「查询时 LLM 负担」	重（需理解原文）	轻（知识已结构化）
「更新成本」	低（增量更新向量）	高（需要重新编译）
「适合数据量」	大规模（10GB+）	中小规模（< 500 页）
「行为修改」	改代码、改 Prompt、部署	改 Markdown 文件