前一段时间，Andrej Karpathy 提出的LLM Wiki概念火遍了技术圈。很多人开始困惑：这是不是意味着我们过去两年苦心搭建的RAG（检索增强生成）白做了？面对复杂的业务需求，我们到底该选RAG、Wiki，还是最新的Agentic Search（智能体搜索）？

2026 年 3 月，资深 AI 观察者 Pasquale Pillitteri 发布了一篇深度指南。他的观点非常明确：这三者不是替代关系，而是不同维度的最优解。

今天，我们就来拆解这篇指南，看看 2026 年真正的顶级玩家是如何玩转 AI 知识库的。

一、RAG 并没有死

首先，我们要给 RAG 正名。

尽管 LLM Wiki 很火，但RAG 依然是企业级应用的中流砥柱。如果你有数百万份文档，或者需要频繁更新数据（如新闻、股价），RAG 依然是无可争议的王者。

RAG 的优势在于：

成熟稳定：经过两年迭代，生态极其完善。

海量扩展：轻松应对十亿级别的文档检索。

事实性强：直接返回原文片段，减少模型瞎编的概率。

但它的致命伤也很明显：

碎片化（Chunking）：为了塞进上下文，文档被切成碎片，逻辑链断裂。

检索 ≠ 理解：向量相似度不等于语义理解，经常“答非所问”。

成本随查询增长：每问一次，就要算一次 Embedding 和检索。

适用场景：客服机器人、电商导购、法规检索、合同比对。

不适用场景：深度逻辑推演、跨文档复杂综述。

二、Karpathy 的“反直觉”：LLM Wiki 模式

就在大家卷 RAG 的时候，Karpathy 提出了一个看似倒退、实则高效的方案：LLM Wiki。

核心理念是：

与其每次提问都去翻书（RAG），不如先把书读透，写成一本精简的教科书（Wiki），以后只读这本教科书。

这就是我们之前讨论的NotebookLM + Claude Skill的本质。

它的工作流程是：

预处理（Pre-processing）：利用 NotebookLM 或类似工具，把几十篇杂乱的 PDF、网页、视频，蒸馏成一份结构化的 SKILL.md或 WIKI.md。

零成本查询：运行时，Claude 不再联网，不再查库，只是读取这份已经“内化”的知识手册。

为什么它火了？

零运行时成本：不用算向量，不用调 API，省钱。

人类可读：那份 Wiki 文件你随时可以打开看，透明、可控。

逻辑连贯：因为是模型一次性读完生成的，逻辑链条完整。

局限：无法处理百万级文档，适合个人或垂直领域团队。

三、终极形态：Agentic Search（智能体搜索）

当问题变得极度复杂，比如“帮我分析这起并购案在过去 5 年的法律风险并预测监管态度”，RAG 和 Wiki 都不够用了。

这时候需要Agentic Search。

这不是一个简单的检索动作，而是一个Research Workflow（研究工作流）：

规划：AI 先拆解问题，制定搜索步骤。

工具调用：AI 自己决定去查数据库、搜网页、调 API。

反思：AI 发现信息不足，会换关键词重新搜索。

合成：最后汇总成一份报告。

这是目前回答质量最高的模式，但也最贵、最慢。

Pillitteri 指出，到 2026 年底，75% 的企业将采用混合架构。

一个典型的 2026 混合架构是这样的：

举个例子：

当你问：“我们的产品 V3 对比竞品 A，在合规性上有何劣势？”

Agent接手任务，拆解成：查自家 V3 规范、查竞品 A 规范、查两地法规。

查自家规范时，直接调用LLM Wiki（因为那是内部固化知识）。

查竞品和法规时，调用RAG去检索最新的外部文档库。

Agent综合两边信息，生成最终报告。

如果你正在搭建 AI 系统，可以参考这个决策树：

[用户提问]↓[Agentic 控制层] (负责拆解问题、多轮追问缺少的税种信息)├─→ [Vector RAG] (精准检索：现行有效法条、地方税局公告)├─→ [LLM Wiki]   (基础常识：税种定义、通用标准流程)└─→ [计算插件/Code Interpreter] (负责精准计算税额，拒绝 LLM 瞎算)↓[最终严谨答复 + 附带参考法条原文链接]

2026 年，AI 工程化已经过了“堆砌模型”的阶段，进入了“架构设计”的阶段。

请点赞推荐，分享给更多的人，关注我会获得更多新AI能力。