你手上的 RAG 知识库可能半年前刚跑通，最近却总听说多了新玩法：多模态、Agent 循环、图结构、重排新做法。到底哪些是值得动手的演进，哪些只是换了个名词？这篇不吹趋势，只给判断标准：先分清你的痛点落在检索链路的哪一段，再决定往哪个方向升，最后附一份改前改后的自检顺序。
你手上的 RAG 知识库可能半年前刚跑通，最近却总听说多了新玩法：多模态、Agent 循环、图结构、重排新做法。到底哪些是值得动手的演进，哪些只是换了个名词？这篇不吹趋势，只给判断标准：先分清你的痛点落在检索链路的哪一段，再决定往哪个方向升。
读法建议是这样的：把下面每一节当成一个独立开关，先判断自己「是不是这个症状」，再看代价能不能承受。全篇不给绝对值，凡是涉及当下价格、延迟、榜单这类一直在动的数字，都写成站内对应页面的查看提示，你到现场对一遍更靠谱。
先分清：变的到底是哪几个环节
把检索链路拆成进料清洗、切片、向量化、召回、重排、拼装、生成七段，然后逐段问自己一句「这段现在是不是瓶颈」。经验上，真正在动的地方通常只有三处：召回方式更杂、重排更普遍、生成前多了一层「判断够不够料」的环节。剩下的切片与进料清洗看着不酷，但对最终结果的影响往往比换模型大。
- 先看进料，再谈前沿：文档脏、格式乱的时候，后端再怎么优化也顶不住；
- 召回、重排、生成前判断这三处是近年的主战场，升级收益相对集中；
- 切片策略偏工程细节，改动成本低但容易被忽略，值得单独拉出来做小实验；
- 不适用的情况：如果连基础召回都还没跑通、没做过端到端对比，任何新方向都不该优先做。
文档进料：从纯文本扩到版面与图表
过去 PDF 一律 OCR 成纯文本，表格和版式信息基本丢光；现在的做法是保留版面结构或整页理解，再决定怎么入索引。判断要不要上，先翻你的历史提问记录：如果存在「这张表里第几列是什么」这类问题，纯文本路线基本答不准，那就是该动的地方。
| 症状 | 该不该上多模态进料 | 先做的小实验 |
|---|---|---|
| 问题大量涉及表格、图表、扫描件 | 值得试 | 挑一批真实文档跑通整页理解再入库 |
| 问题只是段落级事实 | 先别上 | 先把纯文本切片和召回调好 |
| 文档本身就规范、电子原生 | 看情况 | 比对整页理解与纯文本的答对率差异 |
| 存储与调用预算紧张 | 谨慎 | 算清加进来后单次问答的成本增量 |
不适用的情况也要说清：文档本身就规范、问答只问段落级内容时，做版面还原属于过度投入，投入产出比很难看。这时候更该做的是把切片边界调好，而不是上多模态。
召回与重排：从单一向量到多路混合
常见组合是向量召回加关键词召回各取一批，再用重排模型裁到能塞进上下文的数量，比单独提高召回条数更稳。要不要加一路召回，看你的失败样例：问法里有大量专有名词、编号、代码符号的，关键词那一路收益通常更明显。
- 收集失败样例把近期答错的几十条问题单独存一份，标注错误发生在召回还是生成阶段，作为后面改动的对照基线。
- 只加一路召回去测在向量召回之外补关键词召回，跑同一批问题，看答对率有没有明显变化，没有就别留。
- 再引入重排给候选集加一层重排，把裁剪后的条数固定下来，观察响应时间和首字延迟的变化。
- 设超时兜底给重排调用设超时，超时就直接用原始排序结果，避免交互式问答被拖慢。
重排的取舍是：它换的是准确率，付出的是延迟和一次额外调用。交互式问答里要设超时兜底，别让它拖慢首字。语料量很小、问题又都是自然语言泛问时，多路召回加进来只是增加维护面，这时候保持单路更划算。
把检索塞进循环：Agent 化与结构化索引
RAG 和 Agent 结合的核心变化是「检索不再只做一次」：模型可以先看结果、判断不够再换词重查，多跳问题改善明显。代价是调用次数和不可控性同时上升，必须配步数上限、超时和成本阈值，否则一次提问能把额度吃掉一大块。建议先给这类流程设一个「最多查几轮」的硬性上限。
结构化索引是另一条路：把实体和关系单独存一层，适合回答「A 和 B 之间隔着谁」这类关系型问题，纯语义相似度在这类问法上答不好。判断标准很简单：如果你的问题里经常出现多跳关系、时间线、组织层级，就值得单独建一层图结构；如果单跳事实问答占九成以上，加循环只会更慢更贵，收益看不出来。
- Agent 化检索
- 让模型自己决定要不要再查一轮，适合多跳问题，代价是成本和不可控性上升
- 结构化索引
- 把实体与关系单独存一层，适合关系型问法，维护成本比纯向量高
- 步数上限
- 限制一次提问最多触发多少轮检索与生成，防止额度被单次请求吃掉
动手前的自检清单
不管往哪个方向升，动手前先固定一批几十条真实问题作为对照集，改前跑一遍记录谁答错、错在哪一步，别凭感觉判断变好没有。一次只改一段链路，进料、召回、重排、生成分开上，同时改两处就分不清是谁的功劳。
- 固定对照集挑几十条真实问题，覆盖表格、专有名词、多跳关系等典型场景，作为前后对比的基线。
- 每次只改一段进料、召回、重排、生成分开上，记录改动前后的答对率差异，做不出差异就回退。
- 记三个数答对率、单次响应时间、单次调用开销，去站内 /tools/model-cost-calculator 把开销折算成钱。
- 确认方向后再查资料概念名词到 /ai-dict/category/frontier 混个脸熟，向量库到 /stacks/vector-dbs 对照，嵌入模型到 /embeddings 挑。
- 留回滚预案新链路先和旧链路并行跑一段时间，出问题能一键切回，别把线上问答直接换成没验证过的新流程。
还有一点容易被忽略：改完不要只看「感觉更聪明了」。延迟、成本、失败样例三类证据至少要有两类支持这次改动，否则很可能只是换了个新鲜名词，实际问题还在原地。
下一步想动手前先看看别人踩过的坑和当下的价格、延迟口径，这些数字一直在动，去站内相关页面核对当时的数字比记在脑子里靠谱。→常见问题
2026 年的 RAG 和两年前比，最大的变化是什么？
不是某一个单点技术被替换，而是链路变厚了：进料从纯文本扩到版面与图表，召回从单路向量扩到多路混合加普遍重排，生成前多了一层「料够不够、要不要再查」的判断。基础环节本身没被淘汰，只是可选做法变多了。
我该不该把现有 RAG 全换成 Agent 式检索？
先看你现在的失败样例是什么类型。如果是单跳事实问答答不准，问题多半在进料和召回，换循环没用。只有多跳、需要连续追问的问题占比明显时，Agent 化的收益才划得来，而且必须配步数上限和成本阈值。
升级 RAG 之前，最少要准备什么？
一批固定下来的真实问题做对照集，几十条就够；再加一套记录答对率、响应时间、单次开销的简单记账方式。没有对照集，改了之后只能靠感觉说变好，等于白改。具体成本折算可以到站内 /tools/model-cost-calculator 试算。
