十一月二号挂上 arXiv 的 EviCast（2611.02387），cs.CL，交叉列在 cs.LG，十三页、六图八表、十二个作者。我点开它纯粹是因为标题里那个 Forecasting Retrieval Gains——本来想看看又是哪家在给 RAG 刷榜，读下来发现它没刷榜，它在干另一件事：在你把整条链路跑满之前，先算清楚这条链路值不值得跑。
这个角度比论文里那几个数字更值得记。
我们平时判断一个检索器值不值得上，做法基本就是起链路、跑全量、看 F1，然后横着排一张表。七个候选检索器就是七条链路，每个再叠两三档 top-k，一次消融几天就没了。更麻烦的是预算不相等：跑得少的那个天然吃亏，你很难说清到底是检索器差还是样本不够。这篇的出发点就在这儿——它认为现有做法既没法在大规模执行之前判断某组生成器、任务分布、检索器配置值不值得部署，也没法在共享预算下把几个候选检索器放在一起做诊断比较。
EviCast 的做法说穿了就一句：生成器对不同证据状态的响应跟检索器是谁没关系，所以这部分只测一次。作者管这个叫干预式证据状态分解，意思是你人为地把证据摆成几种受控状态，一种一种喂给同一个生成器，量出它在每种状态下的表现，攒成一张共享的响应画像。
STATES = ["no_evidence", "terminal", "bridging", "distractor"]
# 一次性开销：同一个生成器、同一批 prompt，只改证据状态
profile = {}
for s in STATES:
profile[s] = run_generator(prompts, evidence=build_state(s, queries))
这张画像跟检索器无关，换哪个检索器都复用它——整篇论文的基础就在这一步。检索器那边要拿出来的只有一份离线统计：它在你的 query 分布上，会把证据落进各个状态的比例是多少。两边一乘，端到端净效用就出来了，再顺手给一个 95% 置信下界。
# 每个候选检索器：不产生任何生成调用
p = retriever.evidence_state_distribution(queries) # 离线统计
u = sum(p[s] * (profile[s] - cost[s]) for s in STATES)
lcb = u - 1.96 * se(u) # 拿这个排序、拍板
→ 于是本来要跑 N 条链路的事，变成了「测一次生成器 + N 次离线统计」，成本的构成方式整个变了。
结果我只记两个数。HotpotQA 上 14 种检索配置它全判对了，预测误差 2.75 个 F1 点，同时把诊断所需的生成调用量砍掉 80%；低预算那一档，七种被比较的预测器里它的误差最低。14 个全对这件事比 2.75 更让我在意，因为它至少说明在这份数据上它不是靠平均值蒙对了方向。
拓扑感知那个版本 EviCast-T 我读得没那么透。它把证据分成终端证据和桥接证据两类，去刻画两者的互补关系，MuSiQue 加 HotpotQA 合计 16 个配置全判对，往第三个数据集做前瞻性迁移时 24 个里对 23 个。论文里有一节状态细化分析，讲二值实例化和拓扑感知实例化各自在什么条件下能给出精确结果、共享校准又是什么时候比逐检索器单独校准更省。这一节我没完全吃透，尤其是桥接证据具体怎么实例化，我照着推了一遍没推顺，先记个位置，等真要用的时候再回来拆开看。
我自己拿一个小 QA 集照着抄了个最朴素的版本，四种状态，同一个生成器，五十来条 query。结论谈不上验证，只是让我信了一件事：那张响应画像确实有形，无证据和干扰证据两档的分数几乎贴在一起，中间隔着直接证据那一档。这个形状如果你熟悉自己手上的模型，其实是有预感的——检索塞进来的那些东西，它压根没在用。
照着抄的过程里踩到两个坑。第一，状态怎么切是你自己的事，论文给的是几种典型切法，落到你的业务数据上，「桥接」这一档很可能根本切不出来，切不出来预测就废了，这一步没有现成答案。第二，画像是跟生成器绑死的，换个模型或者换个 prompt 模板，前面那张表就得重测一遍，它省的是检索器的钱，不是换模型的钱。成本项也一样，检索延迟和长上下文那笔账怎么折算进 cost[s] 得自己拍，拍歪了净效用就是歪的。
我认这篇论文，认的其实不是那 80%，是「净效用」这个提法。以前讲检索成本，讲的是事后账单；它把成本挪进了决策变量，跟你选哪个检索器摆在同一张表上比较。共享预算下比较多个候选检索器这件事，以前基本靠自觉，现在至少有个能算的东西。
另外一句题外的：这半年 RAG 的论文我越读越觉得方向在往「生成器到底吃不吃得下证据」上挪，而不是继续抠召回率。你要是还在用「加了检索 F1 掉了」这种一句话结论写消融表，可能值得把这块重新做一遍。外部证据就算跟任务相关，也不保证生成模型真的用得上，不加区分地检索既可能拉低任务表现，又顺手把检索和长上下文推理的成本抬上去。
划重点：检索器值不值得上，取决于证据能不能被生成器转成稳定的净效用，相关不等于用得上；生成器的证据状态响应跟检索器无关，测一次能复用，这是省下那 80% 的全部来源；要复现的话，先想清楚你手里能不能把证据切成受控状态，这一步搞不定，后面全是空的。你可以挑自己现成的一个检索配置，只测两档，无证据和加满证据，先看看差值有多大，这个最小的实验半小时能跑完，跑完再回头看这篇论文，判断会比现在准。