Karpathy 的 LLM Wiki:知识库 locale
LLM Wiki 是 Andrej Karpathy 于 2026 年 4 月描述的一种模式:模型不必在每次提问时翻找您的文档,而是编写并持续更新一个 Markdown wiki,每当有新来源时便不断充实。本指南根据他的帖子和 gist 讲解这一原理,介绍使用 Ollama 和终端代理进行本地部署,然后说明这一模式在 RAG 中无法替代什么。文中不包含自测或量化比较:关于该模式的内容均归属于其来源,其余部分则标明为我们的实现。
#LLM Wiki:两分钟了解其原理
2026 年 4 月 2 日,Andrej Karpathy 在 X 上描述了他如何利用语言模型构建个人知识库。两天后,他发布了一篇名为《LLM Wiki》的 gist,并将其介绍为使用 LLM 构建此类知识库的一种模式。两篇文字都很短,十分钟即可读完;链接位于页面末尾。
这篇 gist 基于一个观察:大多数将 LLM 与文档结合的用法都类似 RAG。我们放入文件,系统在提问时检索片段,再由模型撰写答案。Karpathy 承认这种方式有效,但指出模型每次提问都要重新发现知识,而且不会积累任何东西。一个需要交叉检索五份文档的问题,每次都要求重新找出并拼接相同的片段。
LLM Wiki 将工作转移到前置阶段。当新来源到来时,模型不会仅仅为其建立索引:它会阅读来源,提取关键信息,并将其整合到一组相互关联的 Markdown 页面中。它会更新现有页面,修订摘要,并标记新来源与原有内容相矛盾的位置。该 gist 将其描述为一种会随时间改进的持久化产物:当问题出现时,交叉核对已经完成。
文中的角色分工很明确。人类选择来源、进行探索并提出问题。模型完成其余所有工作:总结、关联、分类、维护记录。Karpathy 表示,他在屏幕一侧使用开放式代理,另一侧使用 Obsidian,并用一个比喻概括这套配置:Obsidian 是 IDE,LLM 是程序员,wiki 是代码库。
#三层结构:来源、wiki、约定
你的文档,你的 AI:基于你的 PDF、笔记和邮件的可靠本地 RAG——无需向云端发送任何内容。
- 在线空间,终身可用
- PDF + 文件
- 终身更新
该 gist 描述了一种三层架构。每一层都不需要特定工具:它们只是文件夹和文本文件。
- 原始来源
- 你的文档集合:文章、研究论文、图像、数据文件。它们是不可变的:模型只读取它们,绝不会修改。真正具有权威性的是这些文档,而不是 wiki。
- wiki
- 一个由模型编写的 Markdown 文件文件夹:来源摘要、实体页面、概念页面、比较结果和整体综合。这一层属于模型,由它创建页面、更新页面并维护链接。你负责阅读,它负责写作。
- 约定文件
- 一份向模型说明 Wiki 结构、应遵循的规则,以及如何摄取来源、回答问题或进行清理的文档。该 gist 引用了 Claude Code 的 CLAUDE.md 和 Codex 的 AGENTS.md。正是这个文件,让通用型智能体成为一名遵守纪律的 Wiki 维护者。
两个特殊文件可以帮助模型,也帮助你理清内容。第一个是 index.md,它是一个目录:每个页面都按类别列出,并附有链接和一行摘要。要回答问题时,模型先读取索引,然后打开有用的页面。第二个是 log.md,它是一个只追加内容的时间顺序日志:摄入、问题和验证轮次。
gist 建议为每条日志记录使用固定的前缀开头,这样便可用简单的 Unix 工具进行筛选。示例采用以下形式:
#三种操作:摄取、查询、验证
- 摄取(ingest)
- 将来源放入原始来源文件夹,然后要求模型处理它。根据 gist,模型会读取来源,与你讨论关键点,写入摘要页面,更新索引以及相关的实体页和概念页,然后在日志中添加一条记录。Karpathy 表示,单个来源可能影响 wiki 中 10 到 15 个页面。
- 查询(query)
- 你提出问题。模型查找相关页面,阅读这些页面,并撰写一份引用参考来源的回答。gist 强调了一点:好的回答可以作为新页面归入 Wiki,这样你的探索就会不断积累,而不是消失在某次讨论的历史记录中。
- 检查(lint)
- 有时,你会让模型对 wiki 进行健康检查:检查页面之间的矛盾、被更新来源推翻的过时断言、没有入站链接的孤立页面、被提及但没有专门页面的概念,以及缺失的交叉引用。
为什么要把这项工作交给模型?gist 的论点很简单:真正扼杀个人 wiki 的既不是阅读,也不是思考,而是维护记录。更新交叉引用、保持摘要最新、找出矛盾:维护负担增长得比 wiki 的价值更快,于是人们便会放弃。模型不会感到疲倦,而且可以一次修改十五个文件。Karpathy 将这一想法追溯到 Vannevar Bush 于 1945 年构想的 Memex。
#由本地模型维护的 wiki 的前置要求
该 gist 不假定任何特定供应商。它需要的是一个由模型驱动、能够读写文件的智能体。在本地,这对应以下组件。
- Ollama,截至最新
- 它在 http://localhost:11434 上提供该模型服务。下文使用的命令 ollama launch 只有在较新的版本中才存在。安装过程在我们的指南《安装 Ollama》中介绍。
- 一个能够访问文件的代理
- 仅有一个聊天界面还不够:还需要一个能在磁盘上打开、创建和修改文件的工具。下面的示例使用 OpenCode,这是 gist 中提到的终端开源代理,它会读取放置在文件夹根目录的 AGENTS.md 文件。
- 能够调用工具的模型
- 读取和写入文件需要通过工具调用完成。请选择在Ollama模型库中显示 tools 能力的模型。我们的指南《OpenCode + Ollama》列出了多个此类模型,包括 qwen3-coder:30b、devstral-small-2:24b 和 gpt-oss:20b。
- 用于上下文的内存
- 仅计算权重时,Q4_K_M 的参考值为:70 亿参数约 5 GB,140 亿参数约 9 GB,320 亿参数约 19 GB。Ollama 的文档要求代理至少使用 64 000 tokens 的上下文,这部分还需叠加到上述数值之上。
- Git
- wiki 只是一个 Markdown 文件文件夹:该 gist 指出,将其做成 git 仓库即可获得版本历史,而无需增加其他内容。
- Obsidian(可选)
- 用于阅读 wiki、跟随链接并显示页面图谱。任何 Markdown 编辑器都可以;Obsidian 不参与编写。
#使用 Ollama 逐步完成设置
这些命令面向 macOS 和 Linux 编写;在 Windows 上,最简单的方式是使用 WSL。目录结构和约定文件都只是需要调整的示例:gist 明确说明,文件夹结构、约定和页面格式取决于你的领域和模型,并且其中所有内容都是可选且模块化的。
- 01创建文件夹和仓库一个目录存放原始来源,一个目录存放页面,另有一个索引和一个日志,全部置于 git 下。
- 02编写约定文件根目录中的 AGENTS.md,用于说明结构、写作规则以及三个流程:摄取、提问、验证。
- 03运行模型和智能体Ollama 提供了一个能够调用工具的模型,支持 64 000 个 token 的上下文;OpenCode 会在 wiki 文件夹中打开。
- 04摄取第一个来源一份文档,在你眼前完成处理,经过复核后写入 git。
- 05查询并整理响应问题在 wiki 中提出;有用的总结则整理成页面。
- 06定期检查一次检查流程,列出矛盾、孤立页面和失效链接。
#1. 创建文件夹和仓库
raw/ 文件夹用于存放你的文档,wiki/ 文件夹用于存放模型编写的页面。名称可以自由设定,只要两者之间的分隔保持清晰即可。
#2. 编写约定文件
这是最关键的部分。没有它,代理每次会话都会临时构建不同的结构。请在 ~/wiki 根目录创建 AGENTS.md 文件,例如基于以下内容:
这个文件是我们的,不是 Karpathy 的:该 gist 描述了约定文件的作用,却没有提供模板,并建议随着你在所在领域发现哪些做法有效,让它与模型一起持续演进。保持简短。代理每次会话都会重新阅读它,而每一行都会占用上下文空间。
#3. 启动模型和代理
下载一个能够调用工具的模型,然后在 wiki 文件夹中打开 OpenCode。命令 ollama launch opencode 会启动 OpenCode,并使用由Ollama提供的模型;具体模型可在选择器中选取。OpenCode 本身的安装方法详见我们的指南《OpenCode + Ollama》。
剩下的是上下文。根据 Ollama 的文档,默认窗口取决于 VRAM(低于 24 GB 时为 4 000 个 token,24 至 48 GB 之间为 32 000 个 token),而智能体至少需要 64 000 个 token。OLLAMA_CONTEXT_LENGTH 变量会在服务器启动时设定该值;如果 Ollama 已经作为应用或服务运行,请在其设置中调整数值,而不要启动第二个服务器。
ollama ps 命令会显示模型是否完全驻留在 GPU 上。如果溢出到处理器,每次摄取都会变得非常缓慢:请先选择更小的模型,而不是削减上下文。
#4. 摄入第一份来源
将首份文档放入 raw/,最好使用 Markdown 或纯文本。对于网页,gist 推荐使用 Obsidian Web Clipper 扩展,它可以将文章转换为 Markdown 文件。然后向代理提供指令:
代理读取源内容,提出要点,然后创建和修改页面。继续之前请先复核结果:摘要页、创建的实体页、索引和日志。随后保存 wiki 的状态。
#5. 查询并整理回答
收集几份资料后,在同一个文件夹中向代理提问。明确要求它引用页面和资料,并说明 wiki 中没有包含哪些内容。
#6. 定期检查
每完成几次摄取,就运行一次验证流程。在进行任何修正之前,先要求列出问题:这样你可以掌控哪些内容被合并、重命名或删除。
无需代理即可查看日志。利用条目的固定前缀,gist 中给出的命令会显示最近的操作(只有路径根据我们的目录结构进行了调整):
#LLM Wiki 还是 RAG:框架无法替代的部分
这段 gist 将 wiki 与 RAG 对比,以帮助理解其理念。它并没有说其中一种会取代另一种,本指南也没有这样说:两种方法适用于不同的场景。以下是不含数字的区别,因为我们没有可供展示的测量结果。
- 工作时刻
- RAG 在提问时工作:先查找片段,再由模型撰写。wiki 在摄入时工作:摘要只写一次,然后在每次提问时重新读取。
- 保留的内容
- RAG 保存的是片段及其向量,无法直接阅读。Wiki 保存的是经过撰写的页面,您可以阅读、修正并进行版本管理。
- L'infrastructure
- RAG 需要嵌入模型、向量数据库和切分策略。Wiki 需要一个目录和一个代理。根据 gist,在中等规模下(大约一百个源和几百个页面),索引就足够了,也无需搭建基于嵌入的 RAG 基础设施。
- 对来源的忠实度
- RAG 会将原始段落交还给模型。wiki 则会交给模型一份由模型改写的内容,其中存在相应的错误风险。
- 音量
- RAG 是为大型语料库设计的。wiki 受模型一次能够读取的内容限制:索引、有用页面和来源必须容纳在上下文窗口中。
超过中等规模后,gist 本身又重新引入了搜索功能。它引用了 qmd——一个面向 Markdown 文件的本地搜索引擎,结合了 BM25、向量搜索和 LLM 重排序,可在命令行中使用,也可作为 MCP 服务器使用。因此,大型 wiki 最终会依赖 RAG 的组件,只不过这些组件应用于已经整理成摘要的页面,而不是原始文档。两种方法更多是相互结合,而非彼此排斥。
在实践中,当语料库规模庞大或持续变化时(企业文档、工单、合同),当回答必须复现文档中的精确段落时,或者当拥有不同权限的多人查询同一个数据库时,应保留经典 RAG。对于需要数周深入研究的主题,LLM Wiki 更合适:信息跟踪、研究、阅读书籍、准备材料。这些都是该 gist 自己列举的用途。
#需要了解的限制,尤其是在本地运行时
- 错误也在不断累积
- 页面中写入的摘要错误会被再次阅读、引用,并传播到后续页面。在 RAG 中,错误回答会随着对话结束而消失;在 wiki 中,它会保留下来。这正是必须系统性回溯原始来源并复核修改的原因。
- 本地模型的余量更小
- 摄取过程要求遵循一条很长的指令,读取多个文件,并修改其中十几个文件而不遗漏任何一个。小模型通常不如 gist 中所述代理背后托管的大模型擅长这类长任务。请根据自己的来源进行判断,并从小规模开始。
- 上下文窗口限制了一切
- 超长的资料、不断膨胀的索引和十页待复核内容,并不总能容纳在 64 000 个 token 中。请按章节拆分大型资料,并保持页面简短。
- 摄取需要时间
- 每个来源都会触发一系列读取和写入操作。在配置 modest 的机器上,应按来源逐一处理,而不是在一晚上完成整个库的import d。
- 结构逐渐偏移
- 没有严格的规则,代理会创建重复内容(同一实体使用两个名称)以及没有任何链接关联的页面。命名约定文件中的规则和验证流程就是为此服务的。
#技巧与故障排除
- 代理跳过了摄取过程中的步骤
- 上下文可能太短:指令在处理中途超出了当前窗口。请检查 OLLAMA_CONTEXT_LENGTH 的值,缩短 AGENTS.md,或拆分源文件。
- 代理描述它会做什么,但不写入任何内容
- 该模型对工具调用的处理不佳。请选择在库中显示 tools 能力的模型 Ollama。
- 同一个实体以两个名称出现
- 要求针对重复项进行一次定向核验,逐一确认合并操作,然后将缺失的命名规则补充到约定文件中。
- 索引变得过长
- 按类别拆分,并设置一个指向各个次级索引的主索引;或者像 gist 中提到的 qmd 一样,为 Markdown 文件添加搜索工具。
- 回答会忽略已有页面
- 索引在一次摄取过程中没有更新。请根据 wiki/ 文件夹的内容重新构建索引,然后检查日志。
#开箱即用的实现
你不必把所有内容都手写出来。Nous Research 的开源代理 Hermes Agent 记录了一个名为 llm-wiki 的内置 skill,归在其 research 类别中,用的就是这种模式。如果你已经在使用带有 Ollama 的该代理,这会是更快的起点;下方链接中的文档页面介绍了它的工作方式。原则不变:在把来源交给它之前,先阅读相关约定。
#来源
关于提示词模板的所有内容都来自 Andrej Karpathy 的帖子和 gist。Ollama 和 OpenCode 的设置来自其文档,我们已在《OpenCode + Ollama》指南中引用。粘贴命令前请重新阅读这些页面:这些工具更新得很快。
#深入了解
LLM Wiki 位于网站上多个已处理主题的交汇处。这些指南分别涵盖了本文有意不涉及的内容。
- 本地 RAG:简介
- 嵌入、向量数据库、分块:了解经典 RAG 的工作方式,以便判断何时它仍是正确选择。https://quelllm.fr/guide/rag-local-introduction
- Obsidian + 本地 LLM
- 通过 Copilot 和 Smart Connections 插件,将本地模型连接到 Obsidian 知识库,以便与自己编写的笔记进行对话。https://quelllm.fr/guide/obsidian-llm-local-ollama
- 本地运行 NotebookLM
- 无需中间 wiki 即可复现来源笔记和带引用回答的开源工具。https://quelllm.fr/guide/notebooklm-local-alternative
- 微调 vs RAG
- Karpathy 在他的帖子中将基于其数据库数据对模型进行微调作为探索方向之一。本指南帮助你判断这是否值得投入精力。https://quelllm.fr/guide/fine-tuning-vs-rag-choisir
- OpenCode + Ollama
- 安装此处使用的代理、调整上下文和设置权限。https://quelllm.fr/guide/opencode-ollama-agent-terminal
有反馈、发现了错误,或想补充说明?请告诉我们,让这份指南对每个人都更有帮助。