rag 检索增强生成 最新进展

你大概已经跑通了一版 RAG：文档切了、向量入库了、问答能答了。然后问题开始冒出来——召回不稳、上下文越塞越贵、模型一换效果就飘、线上没有指标只能靠感觉调。这篇不重复讲原理，只讲工程上怎么判断和动手：哪些近期方向值得引入，引入前要先补哪块，怎么用一小套用例把改动量出来。看数字的地方都会告诉你去站内哪一页核对。

你大概已经跑通了一版 RAG：文档切了、向量入库了、问答能答了。然后问题开始冒出来——召回不稳、上下文越塞越贵、模型一换效果就飘、线上没有指标只能靠感觉调。这篇不重复讲原理，只讲工程上怎么判断和动手。

哪些近期方向值得引入，引入前要先补哪块，怎么用一小套用例把改动量出来。看数字的地方都会告诉你去站内哪一页核对。核心思路是：先分清什么是真进展，再按检索侧、架构侧、成本侧、失败面、评测这五块逐个判断，最后用一张清单卡住上线。

先分清：哪些是「新进展」，哪些只是换了名字

先看落到哪一环。只有能落在这三类里具体某一环的，才算工程上值得关注的进展。很多听起来新鲜的名词，拆开看只是把老做法重新包装了一遍。你的判断动作很简单：把读到的每个新方向,试着塞进这三类里，塞不进去说明它跟你现有的链路没关系。

• 预检索阶段的改写与多路查询：同一个问题换几种问法，或者先让模型把问题拆开；
• 检索阶段的多路融合与重排：向量召回之外加关键词召回，再把候选结果重新排序；
• 生成阶段的迭代式检索与自检：生成到一半发现信息不够，回头再查一轮。

判断一个方向值不值得跟，只看三点：它解决的是不是你现在真实存在的失败模式、能不能在你现有链路上做增量改造、效果是否可测。三条里缺两条就先放观察清单，别急着动手。记住，能落到链路上某一环、能测出好坏，才叫进展。

想先混个名词，到 前沿词典（/ai-dict/category/frontier） 对一遍术语再决定要不要深入。术语对不上，后面选型和排错都会互相听不懂。

检索侧近期在动的地方：多路召回与重排怎么加

顺序建议：先补全文检索做混合召回，再加重排模型。向量召回单独用的时候，专有名词、编号、短查询这几类最容易漏——用户搜一个产品型号或一串错误码，向量模型很难区分相近的编号，关键词召回反而稳。所以第一步不是加重排，是把关键词这条路补上。

混合召回落地时把两路结果分别打分再融合，不要直接把两段结果拼起来丢给模型；拼接会让模型分不清哪段更相关。重排的收益大小取决于候选集规模：候选太少重排没空间，候选太多延迟顶不住。先用你真实的失败查询集，跑一遍看召回里到底有没有正确答案，再决定要不要加重排——如果正确答案压根没进候选，重排也救不回来。

判断是否适用：如果你们的查询以长句描述为主、几乎没有编号和专有名词，混合召回的边际收益会明显变小，这时候优先做切分和嵌入模型对比更划算。向量库和嵌入模型的可选范围可以到 向量库对照（/stacks/vector-dbs） 和 嵌入模型资料（/embeddings） 对照，别凭印象选。

Agentic RAG 什么时候值得上，什么时候是过度设计

它擅长的是「一次检索答不了」的问题：需要多跳、需要先判断该查哪个库、需要根据中间结果换查询词。典型的单跳问答上它只会变慢——多了一轮决策和一次检索，延迟涨了但答案质量没变。上之前先量化：你现在有多大比例的问题是一次检索就能定位到正确片段的；这个比例高，就先别动架构。

多跳问题

答案需要串起两处以上分散信息才能拼出来

路由判断

先决定这次该查哪个库或哪类索引，再检索

查询重写

根据上一轮结果换词再查第二次

成本闸门

给多轮检索设总步数上限，超了兜底返回

上的时候要配成本闸门：单次提问允许几轮检索、总步数上限多少、超了怎么兜底返回。没有上限的多轮检索是成本失控的最常见来源——某个问题触发模型反复换词查询，一次问答的消耗顶平时几十次，而你在账单来之前未必察觉。和工具调用循环的关系，可以对照 工具调用机制（/guides/agent-tools） 里讲的调用方式来设计，不要另起一套。

判断是否适用：如果你的用户提问基本是「文档里一段话能答」的类型，Agentic RAG 属于过度设计，先补召回质量收益更直接。反过来说，如果一批问题确实需要跨文档对照才能答全，而你又已经有评测集能测出来，那它就值得试。

上下文与成本：把「塞得下」换成「塞得值」

拼装顺序比总量更重要：把最相关的片段放两头、把元信息压缩成一行、把明显重复的片段先去重，通常比单纯加大上下文有效。模型对中间位置的注意力天然弱一些，把最该看的放开头和结尾，比再多塞两段无关内容管用。

1. 先记三样东西按请求记录：检索命中了几段、实际拼进 prompt 多少字符、这次回答有没有被用上；没有这三样就没法解释为什么这个月贵了。
2. 再定去重规则同一文档相邻切分的片段内容高度重叠时，只保留信息量更高的那一份，别重复计费。
3. 最后压元信息标题、来源、时间这类字段压成一行前缀，不要每段都带一大块头部。

预算口径可以到 Token 成本计算器（/tools/token-price-calculator） 和 用量页面（/usage） 核对你当前的实际用量水平，不在这里写死数字。判断是否适用：如果你们的查询量很小、单次问答对成本不敏感，优化上下文拼装带来的收益可能不值一天的开发时间，先把精力放到召回正确率上。

失败面：检索为空、超时、模型换了，分别怎么办

这三类失败在线上出现频率最高，处理方式也不一样。放一起讲是因为它们的排查顺序有共性：先分干净是检索段的问题还是生成段的问题，再往下钻。别一上来就换模型，多数时候问题不在那一层。

检索为空要分两种：真的没有相关资料，还是召回了但阈值卡掉了；前者应该明确告诉用户没找到，后者调阈值比换模型快。超时按段设：嵌入调用、向量检索、重排、生成各自有独立超时，不要只有一个总超时；哪段先超时决定了你该优化哪里。

• 重排或生成服务不可用时，降级顺序是：去掉重排直接用召回结果、减少拼装片段数、最后才是换模型；
• 每级降级都要在日志里标明，否则事后无法复盘到底是真降级还是误触发；
• 降级期间的表现也要进评测集，不然你只在正常路径上调优。

换模型导致效果变化的排查顺序，可参考 模型替换排查流程（/guides/model-upgrade-workflow-fix） 那套思路，先定位是检索段还是生成段。判断是否适用：如果你们还没有分段计时和降级开关，先补这两样，比研究任何新方向都更急。

没有评测就没有「最新进展」：一小套用例怎么建

任何改动值不值得留下，最后都要靠一小套用例说话。起步不需要大而全：准备一批真实问题，每条标上「正确片段在不在库里」「期望答案的要点」，就够支撑大多数改动决策了。关键是这些问题来自真实用户，而不是你临时编的。

1. 收集真实问题从线上日志、客服记录里捞一批，覆盖常见问法和已知的答错案例。
2. 标两件事正确片段在不在库里、期望答案有几个要点；不用写标准答案全文。
3. 每次只改一个变量换切分、换嵌入、加重排分开测；一次改三样，结果变好了也不知道是哪样起的作用。
4. 定期换血把线上答错的真实问题补进去，把已经稳定的老题移出去，否则评测集会慢慢和实际脱节。

指标看两个就够：正确片段进没进最终上下文、回答里的关键点覆盖了几条；不用一上来就上复杂的自动评分。判分规则的口径可以参考 质量检查（/tools/quality-check），别自己另立一套标准，否则不同人跑出来的结论对不上。

上线前的一张检查清单

前面所有判断，最后都收敛到这张清单。新检索链路、新重排、新模型，上线前挨条过一遍，缺哪条补哪条。这里不写具体数值，基线水平到站内对应页面核对你自己的实际情况。

• 日志字段：查询原文、召回片段 ID 与分数、最终拼装内容摘要、各段耗时、是否降级、用了哪个模型；缺任何一项都会让线上问题变成玄学；
• 并发与限流：嵌入和重排通常是先撑不住的两段，给它们单独设并发上限和排队，别和生成请求抢同一份额度；
• 开关：检索开关、重排开关、降级开关都要能单独关掉，出问题时先关功能再查原因；
• 灰度：新检索链路先切一小部分流量，按上面的指标对比再全量；直接全量切换是这类改动最常见的翻车方式；
• 接口通不通、延迟基线多少，用 测速工具（/tools/speed-test） 和 接口校验（/tools/verify） 先量一遍再上线。

判断是否适用：如果这次只是改了切分粒度、没动链路结构，清单可以简化到日志和灰度两条；但只要动了召回或重排，并发和降级开关这两条不能省。