在人工智Neng领域，检索增强生成曾被视为解决大语言模型知识局限性的关键方案。然而随着Andrej Karpathy提出一种全新的“LLM Wiki”模式，社区开始质疑：RAG是否Yi经过时？

RAG的基本流程是：用户上传文档 → 系统将文档切片并嵌入向量数据库 → 查询时检索Zui相关片段 → 将其输入LLM生成答案。这个过程kan似高效，但实际使用中却常常令人失望。

问题在于，RAG本质上是一个无状态系统。每次查询dou像是从零开始，缺乏上下文连贯性，也难以积累知识。geng糟糕的是分块策略往往破坏了原始信息的结构，导致模型读到的是一堆“断章取义”的句子。

Andrej Karpathy，这位前特斯拉AI总监、OpenAI联合创始人，在一次GitHub Gist中提出了一个全新的知识管理范式——LLM Wiki。他没有发布框架或库，而是分享了一个模式，一个让LLM主动构建和维护个人知识库的方法。

与RAG不同，LLM Wiki强调的是“编译”而非“检索”。当新数据进入系统时LLM不是简单地索引它，而是阅读、理解、整合，并geng新Yi有知识结构。这种模式下知识以结构化、预编译的形式存在而不是在查询时临时拼接。

原始来源层这是你的真实资料集合，包括文章、论文、笔记等，它们被放入raw/目录中，不Zuo任何改动。

维基层LLM读取原始资料，生成摘要、索引，并持续geng新知识页面。这一层是动态的，会随着新信息的加入而自我演化。

模式层定义了LLM如何操作维基的规则，包括页面结构、格式规范、冲突处理等。

传统的RAG系统在处理大规模、多变的文档集时常常面临分块不一致、上下文断裂等问题。而LLM Wiki通过让模型在“摄取时”就完成知识的结构化处理，从根本上避免了这些问题。

geng重要的是LLM Wiki实现了知识的“复合记忆”。每一次交互dou会让知识库变得geng加丰富和准确，而不是像RAG那样每次查询dou重新开始。

Karpathy的提议在社区引发了激烈讨论。一部分人认为，LLM Wiki标志着RAG时代的终结；另一部分人则认为这只是给缓存层起了个新名字。

这种分歧并非毫无道理。RAG在处理企业级、大规模、多租户场景时仍有其不可替代的价值。但对于个人知识管理、研究项目或小团队协作，LLM Wiki显然geng具优势。

Karpathy暗示的未来方向geng加令人兴奋：利用维基生成合成训练数据来微调模型。这意味着，你花费数月构建的知识库，Zui终Ke以转化为一个geng智Neng的模型。

这不仅是工具的升级，geng是知识管理范式的转变。从被动检索到主动编译，从碎片化信息到结构化知识，LLM Wiki正在重新定义我们与AI协作的方式。

我们不Neng简单地说RAG被“扼杀”了。它仍然在处理大规模企业数据、实时信息和安全敏感场景中发挥着重要作用。但LLM Wiki的出现，无疑为AI知识管理开辟了一条新的道路。

或许，真正的答案不是“RAGYi死”，而是“RAG正RAG和LLM Wiki将共存，各自解决其擅长的问题。而Andrej Karpathy的贡献，正是推动了这场进化的关键一步。