2026-07-13 05:03:26 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文分析RAG技术现状，指出朴素RAG已死但检索进化成上下文工程。核心决策依据三问：资料大小、变化频率、查询频率。小且稳定用长上下文或CAG缓存；大或动态用混合检索加重排；复杂多跳用AgenticRAG；关系密集用GraphRAG；表格图表用视觉检索。注意检索质量是主要瓶颈，省钱需自托管向量库和压缩上下文。建议先回答三问再选方案。 综合评分： 90 文章分类： ai安全,解决方案,技术标准

cover_image

要不要给 AI 建知识库，其实就看三件事

原创

AI安全工坊 AI安全工坊

AI安全工坊

2026年7月12日 19:18 江苏

在小说阅读器读本章

去阅读

上个月整理选题的时候，我刷到一条消息，愣了一下。

Claude Code——就是 Anthropic 那个写代码的 AI——把向量检索给删了。

就是那个被无数教程捧上天、几乎和”RAG”划等号的核心组件。作者 Boris Cherny 说，他们早期版本也用 RAG 加向量库，后来换成让 AI 自己用 grep 满仓库翻，结果”碾压一切，而且是大幅度，令人意外”。

我第一反应是：那我们还费劲学 RAG 干嘛。

这个念头维持了大概十秒钟。

然后我反应过来，坏了，又要被带节奏了。

这半年”RAG 已死”这四个字被刷得太狠。真信了它、跟着把技术选型全推倒的人，我估计不少半年后又得默默把 RAG 搬回来。

这篇就想把这事一次说清楚：RAG 到底死没死，市面上那一堆新方案各自在解决什么、代价是什么，以及对你我这种一个人干活的，到底怎么选才不烧钱、不返工。

有点长，但看完你就不用再被任何一篇”RAG 已死”带节奏了。

一、先把”RAG 已死”这场架看明白

你但凡刷技术圈，肯定见过这四个字。

写的人还分三派。一派说长上下文一统天下，模型窗口都上百万 token 了，还检索什么，全塞进去让它自己读。一派说 agent 时代到了，AI 自己会搜，不需要你预先建库。还有那篇被转疯的《RAG Was Always a Temporary Workaround》，标题直接把 RAG 打成”从头到尾就是个临时补丁”。

这是第一层。看着挺唬人。

往第二层想一步，你会发现——他们吵的根本不是同一个 RAG。

真正死掉的，是 2023 年那套最原始的玩法：把文档切块、一股脑塞进向量库、来个问题按相似度捞几段拼给模型。这套确实过时了，业内有个更准的说法叫 naive RAG，朴素 RAG。它死得不冤。

但”检索”这件事没死。它长成了一个更大的东西，现在业内管它叫 context engineering，上下文工程。检索只是其中一个环节，外面还套着压缩、记忆、多工具调度。

我看到一句话，把这事说透了：最初那个朴素版本基本死了，但它的后代们正枝繁叶茂。连 Gartner 都把 2026 定成了”上下文之年”。

回头看 Claude Code 那个操作，你就懂了。它没有不检索——它是把”预先切块塞库”换成了”让 agent 自己 grep、自己翻”。检索还在，只是换了个活法。

Amazon 在 AAAI 2026 有篇论文更狠，说这种 agent 自己关键词搜索、零向量库的方案，忠实度能做到传统 RAG 的 94.5%。

顺便说一句，那篇”临时补丁”的文章我专门去扒了原文。

作者压根没说长上下文能取代 RAG，他反而专门怼了大窗口一句，特别妙：更大的上下文，是一本更好的书，但不是把你上一个念头瞬移过去的办法。他赌的是更远的东西——让模型直接持久化自己的神经状态。那玩意儿现在还没影，属于愿景，不是能落地的方案。

所以你看，”RAG 已死”这四个字，一半是误读，一半是把还没发生的事当成了已经发生。

对你我来说，真正的问题从来不是”RAG 死没死”，是——

这活儿，到底要不要上 RAG，上哪种。

二、把市面上的方案摊开：七条路，各治各的病

先别急着选。你得知道货架上到底有什么，才谈得上挑。

我按”它到底解决了朴素 RAG 的什么毛病、代价是什么”来拆，一条一条过。

1. 直接塞长上下文——最省事，但有天花板

不检索了，把整份资料一次性塞进模型的大窗口，让它自己读。资料小的时候，这是最优解，切块、做向量、装数据库这一整套工程你全省了。

但它有两个硬天花板。

一个是贵。同一个问题，走长上下文比走 RAG 贵几百到上千倍，极端企业案例差到 1250 倍。

另一个更隐蔽：准确率会随窗口变大而掉。号称一百万 token，实际有效容量大概只有六到七成。信息一多，埋在中间那部分模型经常”看丢”，这毛病叫 lost in the middle，到 2026 年都没解决——有个基准测了十七个主流模型，全都随输入变长在掉分。

营销页写着 99.7% 召回，那是往一堆无关文字里藏一根针再让它找。真到多事实检索的实战，平均掉到六成。

一句话：大窗口解决的是”装得下”，不是”找得准”。

2. CAG 缓存增强——高频、稳定语料的偷懒神器

这个知道的人不多，但对一人公司特别有用。CAG 全称 Cache-Augmented Generation。思路是：把整个资料库一次性塞进模型，然后把它的运行时缓存（KV）存下来，之后每次提问都对着这份缓存回答，完全跳过检索。

它治的是朴素 RAG 的”检索慢、还老捞错”。缓存命中是亚秒级的，生成速度能快到几十倍。代价也很明确：受窗口限制，只适合小而稳定的库（五十万 token 以内最佳），而且语料一变就得重建缓存。

举个你能对上号的场景：一份定好的产品说明书、一套很少改的政策文档，但客服每天要查几百上千次——这种”内容稳、查得勤”的活，就是 CAG 的主场。它跟长上下文一样怕”频繁更新”，但比长上下文省，因为缓存能反复用。

3. 朴素 RAG + 混合检索 + 重排——大多数人性价比最高的一档

如果资料大、还要查最新，那就得老老实实检索。但别再用 2023 那套纯向量了——纯向量召回差，是公认的坑。企业里”混合检索”的采用意向一个季度从 10% 涨到 33%，就是被纯向量坑怕了集体转向。

混合检索（hybrid）不玄，就是向量检索配上关键词检索（BM25）。向量负责”意思相近”，关键词负责”人名、编号、术语这种要精确命中的”。上面再加个重排器（reranker），专治”正确答案在候选里、但排名不靠前”。

这一档不高深，本周就能上线，却是多数团队最大、最便宜的那笔收益。别一上来就琢磨那些花哨的。

4. Agentic RAG——复杂多跳查询才配得上

把 LLM 从流水线末端搬到中间当指挥。它不再是”捞一次就答”，而是自己判断：要不要检索、检索什么、够不够、要不要再来一轮。对付那种”先查 A 公司被谁收购、再查收购方 CEO 是谁”的多跳问题，它是刚需。

代价是真大。一次查询要多轮 LLM 调用，token 烧五到三十倍，延迟从几秒起步。Anthropic 自己做多 agent 研究，用了十五倍的 token 换来好 90% 的答案——只有当”任务值这个钱”时它才划算。简单事实查询用它，纯属杀鸡用牛刀，还是那种把自己也搭进去的杀法。

5. GraphRAG——关系型问题和强监管场景的答案

它在检索里塞进了知识图谱。先找到起点，再沿着实体之间的关系边往下走，把节点、关系、属性一起捞出来。它治的是向量检索的”答案碎片化、说不清为什么”。

有句话概括得好：一条图谱路径，就是一句人能读懂的话——这对法律、合规、投研这种要可解释的领域是命根子。

死穴是贵。要先把文档里的实体、关系全抽出来建图，索引成本比向量 RAG 贵一百到一千倍。微软后来出了个 LazyGraphRAG 把成本压到原来的千分之一，但对一个人来说，建图和维护本身仍是场灾难。除非你真在做反欺诈、投研这类关系密集的活，否则别碰。

6. Agent Memory——当”连续性”本身就是你的产品

前面几条都是”读”，这条是”写”。有个区分我觉得特别精辟：RAG 给了 agent 知识的入口，记忆给的是连续性。

RAG 是无状态的查一次就忘；agent memory 是有写入策略的持久化状态，能跨会话记住你、从反馈里学。做那种越用越懂你的助手，才需要它。代价是写路径难管——记忆会被投毒、会在反复摘要里漂移走样。

7. 视觉检索——一个正在掀桌子的新范式

这条最前沿，也最反直觉。传统 RAG 处理网页和 PDF，第一步是把 HTML 解析成纯文本。问题是——表格被压成没有列对齐的一坨、图表直接消失、并排对比塌成流水句。你以为检索翻车是模型笨，其实信息在解析那一步就丢光了。

伯克利今年出的 PixelRAG 干脆不解析了：给网页截图，让视觉模型像人一样”看”。在财报这种图表密集的 PDF 上，纯文本检索召回 62%，视觉检索干到 84%。整体准确率比文本基线高 18%，低分辨率下还省三倍 token。

这条路（ColPali、视觉 RAG 那一大类）正在把 PDF、文档检索的主场从”解析成文本”整个端走。

七条路摊完了。你先别晕，下一节我把它拧成三个问题，你照着答就行。

三、七条路，其实是一棵决策树：先过三问

真到自己选的时候，别对着七个名词纠结。先问自己三件事。

第一问：资料有多大？

一本产品手册、一份内部 wiki、几十篇文档——二十万字以内，别建库。直接塞长上下文，或者用 CAG 把缓存存下来反复用。工程全省。

第二问：多久变一次？

天天更新、随时要查到最新的——长上下文和 CAG 都救不了你（它们怕”变”），老老实实上 RAG。

第三问：查得有多频繁？

一天个位数次，塞上下文最省心。一天几百上千次，长上下文那个”贵几百上千倍”的账你自己算——这种就得 RAG，把成本摊薄。

三问过完，八成场景的答案已经出来了。我给你一张路由表，照着抄：

| | | — | | |

这张表你存下来，比记七个术语有用。

四、两个容易被跳过的深水区

选对方案只是及格。真正拉开差距的是下面两件事，多数教程根本不讲。

第一个：你的问题，大概率出在检索，不在模型。

先说个反常识的数——RAG 翻车，七成以上不在”生成”，在”检索”。

就是说，AI 答得不对、在瞎编，十有七八不是模型笨，是它压根没捞到对的内容。很多团队在这儿栽：花好几周调 prompt、换模型，其实是检索每三次就返回一次错误上下文。方向从一开始就找歪了，越努力越白费。

更阴的是——检索质量你很难自己发现。

有个特别扎心的证据：一个 RAG 系统可以在”忠实度”这项拿到 0.95 的高分，照样给出完全错误的业务答案。为什么？因为忠实度只衡量”答案有没有忠于检索到的内容”，可它检索到的内容本身就是过时的、错的。独立评测发现，现有工具没一个能分辨”检索到的上下文事实对不对”。

所以但凡你要认真做 RAG，评测这一层不能省。

三个工具值得知道：RAGAS 轻量、无需标准答案，适合开发时快速调参；DeepEval 是 pytest 那套，指标一掉就让构建失败，适合当质量门禁；TruLens 带追踪，适合盯生产。成熟团队是三个一起用，不是二选一。

第二个：省钱的两个杠杆，和一个多数人会踩的预算坑。

省钱这块，两个杠杆最实在。

一个，自己托管向量库。别默认上那些按次收费的云服务，自己架一个开源的（比如 Qdrant，或者你手头本来就有 Postgres，那就 pgvector），基础设施成本能砍掉四到六成。

另一个，压模型的输出。把每次喂给它的上下文从四千 token 压到两千，生成成本直接对半砍。顺带一提，embedding 本身很便宜，不是成本瓶颈，别在那儿省错地方。

还有个坑得提前打预防针：真实成本，多数人会低估两到三倍。一开始算得美滋滋，半年后存储、重建索引、你自己搭进去的工时，全冒出来了。预算按乐观估计乘个二到三，留够冗余。

说白了，这跟一个人创业的逻辑一模一样。OpenAI 一线的人聊过一个观点我很认同：未来高杠杆的一人公司，核心能力就是知道该买什么工具、把不想干的事外包出去。

选 RAG 方案也是这么回事。别把最新最全的架构往身上堆，搞清楚自己那点活儿，配多大的刀就够。

（顺便，我之前写过一篇 LLM 推理框架的选型指南，三万多阅读。选型这事的底层逻辑，其实一直没变：先搞清自己的约束，再挑工具，而不是反过来。）

五、收个尾

绕了一大圈，回到开头那条让我愣住的消息。

Claude Code 删掉向量检索，不是 RAG 不行了。是它想清楚了自己要什么——让 agent 自己去翻、去查，而不是提前把整个世界塞进一个库里。这恰恰是”检索进化成上下文工程”最好的注脚。

而对你我，重要的从来不是追哪个新架构，是先回答那三个问题：资料多大、多久变、查多频。答完了，七条路自己会告诉你该走哪条。

想清楚你要检索、要缓存、还是要记忆，比追任何新名词都值钱。

RAG 没死。

是你把它想复杂了。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AI安全工坊 AI安全工坊 AI安全工坊《要不要给 AI 建知识库，其实就看三件事》