周一早上九点十七，arXiv cs.CL 新提交列表，刷到一篇叫 TRIO 的。点进去纯粹因为标题里那个 “Individual Optimization”——现在 RAG 论文一水儿往 pipeline 上叠 agent，叠完报涨点，我倒想看看这个“各自优化”是真有东西还是换个说法。
先说是什么。三个 agent 分工：一个把问得含糊的查询扩写圆，一个判断“扩完之后捞回来的东西够不够答这个问题”，一个拿着证据写答案，三个各带各的奖励信号反复迭代。EMNLP 2026 的 findings，DOI 已经下来了。所以这期报幕方式得换一下，不是 owner/repo，是篇论文；代码作者说公开了，链接在正文里，我没去 clone，这句先声明在前面。
我真正想聊的不是它报的那点提升。是中间那个判官。
现有 RAG 有两个老毛病，检索不充分、模型硬编。作者在 intro 里分开写，我觉得是同一件事：整条流水线上没有任何一个环节为“我手里的证据够不够”负责。检索器只管捞回 top-k，捞得烂也照捞；生成器只管往下写，写完看着挺顺。中间那步没人管。你让人去看这一堆 chunk 到底支不支持这个问题，那是人肉 eval 的活，标注成本高到没人干。
TRIO 干的事说白了，就是给这一步配一个能训的判官。麻烦在标签从哪来。它的解法是一致性投票：同一个查询扩出若干个变体，分别去检索，让模型对“这些材料够不够答”投票，票型收敛的结果就当训练标签喂给判断器。
这篇真正值钱的地方不在榜单，在它把一件平时靠人肉感觉糊过去的事，做成了能训的模块。
这个思路我服。它绕开的正是 RAG 里最难标的那类标签——不是“答案对不对”，是“材料够不够”，后者连人类标注员之间的一致性都不高。用投票把标注问题转成生成问题，代价可控，还算能复现。
但这也是全篇最脆弱的一环。
扩写变体是同一个查询智能体吐出来的，语义上天然同源。同源的问法捞回同源的 chunk，投出来的“充足”很可能只是“我这几个问法都能捞到点东西”，不是“证据真的足以支撑一个答案”。投票一致性天然往“够”那边偏，判官学到的就是一个偏松的标准。判官一松，后面回答智能体拿到的课程难度就全是虚的——它以为自己在做进阶题，其实卷子早被降过难度了。
我不确定作者有没有做过这个方向的消融，反正在我读到的方法部分里没提。这是我个人的怀疑，不是结论。
查询扩展那个 agent 的奖励，用的是回答质量的提升幅度。思路没错，扩写好不好最终看下游答得好不好，够直接。问题也直接：信用分配被拉得太长，一次扩写动作要等整个回答链路走完才拿到分数，方差大得离谱；而且扩写和下游生成被绑死了，扩写器学到的可能不是“怎么把问题问清楚”，是“怎么讨好后面那个写答案的”。这两件事在训练里很难分开——扩写器越训越会顺着写答案的喜好来，不是越训越会问。
回答智能体那边是动态匹配的奖励加课程学习。这段我读得最快，因为它最像工程调参——不是贬义，只是这一类设计的效果高度依赖课程怎么排、奖励怎么归一到同一个量纲，论文里报的数字我信一半。
老实交代检验程度：代码没跑，实验没复现，方法部分读了两遍，intro 一遍。上面这些全是读出来的印象，不是跑出来的结论。这类东西真正的成色得看有人把它塞进自己的流水线跑一周，看那个判官的输出分布是不是真的跟着证据走，还是稳定吐“充足”。这个我蹲后续。
顺手看了眼同一天 cs.CL 的新提交列表，标题里带 agent 的能占去小一半。RAG 这块现在有点这个意思——不是坏事，但看多了一眼扫过去全是三个 agent 四个模块五个阶段，反倒 TRIO 这种把一件事拆干净、每块都交代清楚为什么这么设计的，显得克制。刷着刷着跑题