Karpathy的LLM Wiki：一种将RAG从解释器模式升级为编译器模式的架构

Andrej Karpathy在GitHub上发布了一份名为LLM Wiki的文档引起了巨大的关注一派认为这不就是多绕了几步的RAG另一派已经打开编辑器着手搭建测试。文档里没有新模型、新算法、新硬件。它描述的无非是一套流程把原始素材喂给LLM让它生成结构化的Markdown wiki再基于这个wiki做检索、问答和持续更新。其实我们值得关注的是它背后的架构思想思路从需要时去检索源文本变成了将原始素材编译成结构化中间表示后续推理都基于这个产物展开。解释器 vs. 编译器传统RAG的流程清晰对文档分块将分块嵌入向量数据库查询时检索最相关的top-k分块作为上下文传递给LLM生成回答。NotebookLM、ChatGPT文件上传以及大多数生产环境的RAG管线都遵循这一模式能用也能扩展到企业级场景。但设计中埋着一个结构性限制LLM在每次查询时都从头重新发现知识。一个需要综合五份文档才能回答的问题模型每次都要实时定位、拼凑相关片段。没有任何东西积累下来查询之间不存在持续构建的持久化结构。Karpathy引用了一个计算机科学的类比RAG表现得像解释器——运行时重新求值一切LLM Wiki更像编译器预先将源材料处理成结构化中间表示即wiki后续工作针对编译产物展开而非反复阅读原始材料。Wiki充当中间表示index.md充当符号表log.md充当构建日志LLM agent充当编译器进程。原始素材输入一次被编译成带有交叉引用、实体页面和综合摘要的结构化Markdown页面之后所有推理都基于这些编译输出展开。复利效应在实践中到底意味着什么Karpathy反复提到compounding复利一词它在这里承担的是真正的概念工作不是包装话术。标准PKM个人知识管理工作流中信息的增长充其量是线性的。收藏了200篇文章190篇原封不动地躺着记得住的10篇是读过两遍的。知识不会自己相互关联每次需要用到时结构都得手动搭建。LLM Wiki改变了这一点。模型不只是写一个摘要页面它会通读整个现有wiki找出新内容与已有实体页面、概念页面和主题摘要的交集然后更新所有相关内容一个新来源可能触及10到15个现有页面。每一个新输入都被整合进现有知识结构而非堆叠在上面。矛盾被标记交叉引用被添加综合页面被修订。这就是复利效应的实质摄入的内容越多新材料被解读时所处的上下文就越丰富。第100个来源的处理建立在一个已经蒸馏了前99个来源知识的wiki之上不会从零起步。跟常规笔记方式的对比很鲜明。在Notion、Roam或普通的Obsidian仓库里添加第100条笔记不会让第50条笔记变得更聪明。LLM Wiki模式下会这是因为wiki本身是被持续更新的产物也是所有后续推理的依据。使其真正模块化的三层架构从软件工程角度看这个设计站得住脚的原因在于它将大多数笔记工具混为一谈的三个问题清晰拆开了。第一层是原始素材不可变。文章、论文、PDF、网页剪藏、代码文件、图片统一进入raw/目录永不被修改。LLM可以读取但没有写入权限。这是事实基准——如果wiki出了问题可以从原始素材重建。来源的可追溯性得以保留。第二层是wiki由LLM操作。一个Markdown文件目录包含实体页面人物、公司、论文、概念页面思想、方法、框架、主题摘要、对比表格和综合概述。LLM创建、更新、维护全部内容人来阅读。这就是编译产物。第三层是schema即CLAUDE.md或AGENTS.md。一份配置文档告诉LLM wiki的结构规范、约定和工作流。Karpathy称之为关键配置文件。主要是通过这个文件把LLM从一个通用聊天机器人转变为有纪律的wiki维护者。分层的意义在于每层可以独立替换。任何Markdown阅读器都能替代ObsidianClaude Code可以换成OpenAI Codexschema可以随领域演进而调整。原始素材始终不动。Wiki只是git仓库中的文件版本历史、差异追踪和分支功能天然具备。多数AI笔记应用产品把存储、组织和展示纠缠在一个不可拆分的层中这是它们与LLM Wiki设计之间的根本区别。摄入→查询→检查 操作循环运行模型的三个核心操作需要说明清楚。摄入将新来源放入raw/指示LLM处理。LLM读取内容如有需要与你讨论关键要点然后编写摘要页面、更新索引、更新相关实体和概念页面、追加日志条目。一个来源进去一次操作更新多个页面。查询提出问题LLM先读index.md定位相关页面再深入具体页面跨页面综合信息生成带引用的答案——引用指向wiki页面wiki页面又指回原始素材。关键之处在于好的答案可以作为新页面归档回wiki。你要求的分析、你需要的对比、你发现的关联不会沉没在聊天记录里而是成为持续积累的产物的一部分。检查定期运行wiki健康检查让LLM识别页面之间的矛盾、被更新来源取代的过时内容、没有入站链接的孤立页面、被提及但缺少独立页面的重要概念以及缺失的交叉引用。这类维护工作人往往会跳过LLM则不会。摄入操作的实现框架如下# llm_wiki_ingest.py — minimal ingest operation pattern import os from pathlib import Path from datetime import datetime RAW_DIR Path(raw/) WIKI_DIR Path(wiki/) LOG_FILE WIKI_DIR / log.md INDEX_FILE WIKI_DIR / index.md SCHEMA_FILE Path(CLAUDE.md) # or AGENTS.md for Codex def ingest_source(source_path: str, llm_client) - dict: 将单个原始来源摄入wiki。 返回更新/创建的页面字典。 source Path(source_path) assert source.exists(), fSource not found: {source} # 读取schema以便LLM了解wiki约定 schema SCHEMA_FILE.read_text() # 读取当前索引以便LLM了解现有页面 index INDEX_FILE.read_text() if INDEX_FILE.exists() else # Index\n # 读取来源内容 content source.read_text() prompt f You are maintaining a personal wiki following this schema: {schema} Current wiki index: {index} New source to ingest: --- BEGIN SOURCE: {source.name} --- {content} --- END SOURCE --- Tasks: 1. Write a summary page for this source (wiki/sources/{source.stem}.md) 2. Identify all entities (people, papers, projects, companies) mentioned 3. For each: update or create their entity page with new information 4. Identify all concepts/topics and update their concept pages 5. Note any contradictions with existing wiki content 6. Update index.md with any new pages 7. Append to log.md: ## [{datetime.now().strftime(%Y-%m-%d)}] ingest | {source.name} Return a JSON list of all files modified with their full content. response llm_client.chat(prompt) pages_updated parse_file_updates(response) # 将所有更新写入磁盘 for filepath, file_content in pages_updated.items(): full_path WIKI_DIR / filepath full_path.parent.mkdir(parentsTrue, exist_okTrue) full_path.write_text(file_content) return pages_updated def lint_wiki(llm_client) - list: 对wiki进行健康检查。返回发现的问题列表。 all_pages list(WIKI_DIR.rglob(*.md)) page_contents { p.relative_to(WIKI_DIR): p.read_text() for p in all_pages[:50] # 分批处理以控制在上下文窗口内 } prompt f Review these wiki pages for quality issues: {format_pages(page_contents)} Identify: - Contradictions between pages - Orphan pages (no inbound links from other pages) - Concepts mentioned but lacking their own page - Claims that seem stale or need verification - Missing cross-references that should exist Return a structured list of issues with page names and descriptions. return llm_client.chat(prompt)Schema文件CLAUDE.md使整套流程具备纪律性# Wiki Schema — Personal Research: [Your Domain] ## Directory Structure wiki/ index.md # master catalog, updated on every ingest log.md # append-only chronological record overview.md # evolving synthesis of the whole domain sources/ # one page per raw source ingested entities/ # people, papers, projects, companies concepts/ # ideas, methods, frameworks, terms comparisons/ # structured comparisons between entities/concepts ## Conventions - Every page has YAML frontmatter: title, tags, source_count, last_updated - Cross-references use [[wiki-link]] syntax (Obsidian-compatible) - When new info contradicts existing content, add a ⚠️ Contradiction section - Orphan prevention: every new page must link from at least one existing page - Log entries format: ## [YYYY-MM-DD] operation | description ## Ingest Workflow 1. Read source fully 2. Write sources/[name].md summary 3. Update entities/ pages for all named entities 4. Update concepts/ pages for all key ideas 5. Update overview.md synthesis if thesis evolves 6. Update index.md catalog 7. Append log.md entry 8. Report: X pages created, Y pages updated, Z contradictions flaggedObsidian作为IDEKarpathy对自己实际工作流的描述是整篇文档中最有实操价值的段落“实际操作中我一边打开LLM agent另一边打开Obsidian。LLM根据对话进行编辑我实时浏览结果——跟随链接、查看图谱视图、阅读更新后的页面。Obsidian是IDELLM是程序员wiki是代码库。”这描述的是一个真实的反馈循环LLM写入你阅读你浏览图谱视图注意到哪里缺少链接、哪些页面还很单薄你追问LLM继续更新页面你再读一遍。这个交互循环把它和批量处理文档生成知识库区分开来。这是一个实时的、迭代式的系统人的角色是导航、策展和判断不是写作和归档。IDE类比之所以精准在于IDE不是被动的文本编辑器。它提供语法高亮、跳转到定义、引用追踪、错误指示,还能在整个代码库范围内一次完成重构。Obsidian的图谱视图在知识领域扮演了类似角色展示哪些概念是枢纽哪些页面是孤岛哪些主题之间密集互联哪些研究方向尚待深入。LLM负责写入Obsidian负责导航两者的组合产生了各自单独无法达到的效果。LLM看不出图谱中缺了什么你无法在一次操作中更新15个相互引用的页面。配合起来这个空白就被填上了。硬性限制维护成本与语料库规模一同增长比如说20个来源时wiki还好管理但是200个来源时就变成了一项治理工程。LLM传播的不只是事实错误还有结构性错误。RAG中一个错误的答案只是一次性的偏差再问一次可能就对了。LLM Wiki模式下如果模型在摄入过程中错误关联了两个概念这条错误链接会在多个页面中被反复强化后续摄入在错误关系的基础上继续叠加。错误不再孤立而是被编织进结构。事后检测和纠正需要专门的审计重新查询解决不了。Schema也是薄弱的一环。Wiki的质量上限取决于CLAUDE.md schema的质量。约定模糊或前后不一致LLM在不同摄入会话中就会做出矛盾的决策。这不是模型能力的问题这是规格说明的问题。Schema必须明确、具体并随发现的边界情况持续修订。上下文窗口限制在规模化时不可忽视。索引优先的方法在约100个来源、几百个页面时运作良好超过这一规模就需要正式的搜索基础设施。Karpathy提到了qmd——一个用于Markdown文件的本地混合BM25/向量搜索引擎带有MCP服务器接口。缺少类似工具的话LLM花在读索引上的开销增加查询延迟随之上升。为什么这是个人工具不是组织工具大多数人跳过了这一点但对任何考虑将此模式推广到团队或公司的人来说它至关重要。个人知识系统和组织知识系统的差异不在数据量在问责结构。个人系统中你是唯一的质量关卡。哪些来源可信、哪些结论是暂定的、哪些页面需要重新审视这些判断全由你做。你容忍不完美因为所有后果自己承担。Wiki虚构了两个概念之间的关系发现它的是你从中学到教训的也是你。团队系统中四个问题会立刻浮现而且没有纯技术解决方案。谁来判断来源质量——多人同时摄入来源质量差异马上显现。谁的schema说了算——不同贡献者对概念组织方式有各自的心智模型。谁负责矛盾解决——页面A说X页面B说非X总得有人拍板。谁来审计虚构的关系——LLM生成的交叉引用看上去合理但实际上错了没读过原始来源的人根本察觉不到。缺少明确的治理机制——审查流程、版本控制纪律、每个页面类别的责任人——AI非但不会减缓错误传播反而会加速。Wiki变得权威的速度会快过人工审查验证的速度。Karpathy的gist简短提及了企业/团队场景说的是可能让人类参与审查更新。这句话背后的分量很重。对组织wiki来说人类参与不是锦上添花它就是那个组织几十年来一直没能解决的治理难题——无论有没有AI。这个模式对个人有用。作为团队模板去推广需要一整套独立的流程设计层。Karpathy的文档明确没有涉及这部分。最现实的采用方式从小处起步读到这里就想立即搭建的人最容易犯的错误是试图在一次会话中导入全部现有研究资料并把输出当作权威结论。这不是它的用法。系统面向增量成长不是批量初始化。一个可行的路径1、为一个聚焦的领域编写CLAUDE.md schema不要试图覆盖所有知识摄入5到10个来源逐页阅读LLM生成的内容遇到不一致就修正schema。2、每次会话添加两三个来源每周跑一次检查留意哪些类型的页面始终单薄或出错相应调整schema。3、当你提出一个需要综合20个以上来源的问题拿到的答案引用了你三周前通过LLM写成的某个页面——wiki开始产生真正的回报。复利效应需要时间积累。一次性设置不够它是一个随每次会话质量提升的系统前提是schema保持干净、检查操作持续执行。Wiki是Markdown文件组成的git仓库版本历史和分支功能天然具备。用好它——每次摄入会话后提交。如果LLM犯了一个扩散开来的结构性错误可以查看差异并回滚。总结Karpathy没有发明新技术他在清晰阐述一个工作流模式让LLM天生擅长的事——快速阅读、综合、交叉引用、一致地遵循约定——去接替人类一直需要但从未能持续做好的工作。核心洞察不是用LLM充当知识库。知识工作中最乏味的那些事——归档、交叉引用、更新、保持一致性——恰恰是LLM可以长期执行而不退化的部分。良好的来源筛选、精心维护的schema、定期的健康检查以及在结构性错误扩散之前捕捉和修正它们的判断力。系统负责记账思考仍然是你的事。https://avoid.overfit.cn/post/aa66818e5918471ea5545161f3d1a932by JIN