放弃RAG！Karpathy亲自下场：LLM Wiki才是个人知识库的正确方向

前言最近Andrej Karpathy的一段分享在圈内刷屏核心观点很直接别再盲目堆RAG了你的知识库思路可能从根上就错了。很多人一提到AI知识库第一反应就是向量库、检索、chunk切分、重排序一套RAG流程焊死不动。但在Karpathy的实际工作流里RAG已经基本被弃用取而代之的是一套更简单、更可积累的范式LLM Wiki。本文结合Karpathy原文和视频内容完整梳理这套新范式不堆砌术语尽量用工程化视角讲清楚它到底是什么、为什么比RAG好用、以及可以怎么落地。一、我们现在用的RAG问题到底在哪先回顾一下现在最常见的RAG模式上传文档→切片向量化→存向量库→用户提问→召回相关片段→塞进上下文生成回答。这套方案能用但在Karpathy看来它有几个本质缺陷没有知识积累每次都在“重新发现”不管你问多少次同一个领域的问题LLM都是临时去原始文档里扒碎片不会形成长期、结构化的知识沉淀。相当于一个每次都会失忆的助手永远在翻资料永远不会真正“学会”。依赖碎片拼接跨文档推理很弱向量检索靠相似度召回的是零散段落。一旦问题需要跨多篇文档综合推理很容易逻辑断裂、前后矛盾、答不到点上。工程链路重调参成本高要搭向量库、调chunk大小、做召回优化、重排序、处理上下文长度限制……对个人开发者和轻量场景来说太重了。Karpathy在分享里直言包括NotebookLM、ChatGPT文件上传在内的多数产品本质都是这套逻辑并不是知识库的最优解。二、LLM Wiki把知识“编译”成可生长的维基LLM Wiki的核心思想非常朴素把LLM当成一个编译器而不是临时检索工具。让它把你的原始资料一次性“编译”成一个结构化、可链接、可维护的个人维基。整个系统极简只有三个目录1. 目录结构原文直接给出raw/存放原始资料论文、PDF、网页、笔记、截图文字等。只进不出只增不改作为知识源头。wiki/LLM自动维护的结构化知识库全部是Markdown文件。包括概念词条、摘要、索引、交叉引用、反向链接。schema/存放模板、提示词、配置规则用来规范维基的格式和生成逻辑。2. 完整工作流Ingest 导入看到好文章、资料直接丢进raw/不用手动分类、整理、标注。Compile 编译让LLM读取新增内容自动提炼关键概念、撰写词条、建立页面间链接更新总索引。这一步相当于“知识结构化”只做一次后续反复复用。Query 查询提问时LLM直接从wiki/里读取结构化内容回答不再反复扫描原始文档。Lint / Heal 自检修复LLM定期扫描整个wiki自动处理信息不一致、矛盾点缺失的概念页面孤立无链接的页面过时或冗余内容整个过程没有向量库没有embedding没有复杂检索 pipeline。三、LLM Wiki 对比 RAG优势在哪从实际使用效果看LLM Wiki完全是另一个维度的思路知识可以复利越用越“聪明”RAG是临时拼凑LLM Wiki是持续沉淀。每一次导入、每一次解释都会丰富维基知识库本身在不断进化。结构透明人也能直接读、直接改全部是Markdown可阅读、可编辑、可Git管理。不像向量库那样是黑盒你完全知道知识库“记住了什么”。工程极轻个人可直接落地不需要部署向量库、不需要折腾检索策略文件夹LLMObsidian就能跑通整套流程。小体量下推理更稳定在个人知识库规模下几百篇文档量级LLM可以直接把整个wiki读进上下文跨章节、跨概念的理解远比碎片召回更连贯。四、Karpathy 自用工具栈可直接抄作业Karpathy在原文和分享中给出了自己的真实工作流非常接地气原始文件维基存储本地文件夹维基查看/编辑Obsidian用反向链接、图谱、DataviewLLM引擎Claude 3 Opus这类大上下文模型成本优化开启prompt缓存大幅降低token消耗版本管理Git记录所有wiki修改典型一天的流程网页剪藏 → 存入raw/执行编译“把新文档更新到wiki”提问时直接从结构化wiki获取答案把精彩解释保存为新的wiki页面定期让LLM自检、修复、补全链接五、总结知识库的未来不是检索是编译Karpathy这一波分享本质上是在纠正一个行业惯性一提到知识库就RAG不一定是最优解。LLM Wiki提供了一条更简单、更接近人类学习方式的路径不是每次都临时翻书找答案而是先把知识整理成体系、建成“维基”再基于体系回答问题Obsidian 是知识IDELLM 是程序员Wiki 是代码库。不需要花里胡哨的技术只需要持续生长的知识体系。对个人开发者、研究员、内容创作者来说LLM Wiki可能真的是比RAG更值得投入的下一代知识库范式。