最近有人问我，RAG 系统只要答对率上去了，是不是就算调好了。
不是。
8 月 25 号，arXiv 上挂了一篇预印本，编号 2608.24753，主分类 cs.CL，标题叫 The RAT，做的是一套 RAG 评估的贝叶斯框架。作者四个人，Pius von Däniken、Felix Matthias Saaro、Mark Cieliebak 和 Jan Deriu，提交人是 Jan Deriu。
我关心的不是贝叶斯。我关心的是它顺手拆出来的一个问题：用户有没有拿到正确答案，和生成器在拿到检索结果之后表现是否得体，是两件事。
简单说，RAG 出问题就两个来源。检索没找着东西，模型手里没料，只能瞎编。检索找着了，模型还是答错，或者该说"我不知道"的时候硬撑着答。传统指标只看最后那一下，一个答对率把两种毛病糊在一起。
这就是它说的条件分解。
27 种配置，就是为了证明这件事
论文把这套框架套在 27 种 RAG 配置上跑。3 个数据集，3 种检索器，3 种生成器。
结论一句话：按 RAG 流水线的信息流做条件分解以后，那些在边际指标下看起来等同的系统，行为差异是能看出来的。
"看起来等同"这几个字是我最想拎出来的。边际指标的本质就是把变量平均掉，剩下的那个数好看，但被平均掉的那部分恰恰是你该看的。
这话谁都懂。轮到自己的项目，还是盯着那个数。
我原本想把这期写成"一句话搞懂贝叶斯评估"。写到一半发现不对，值钱的不是那个模型，是它用模型证明的一件小事。
标注预算花在哪，这条最实在
论文里还有一段分析标注资源怎么分配。结论是：如果你的目标是估计策略遵循度，也就是模型有没有按它该有的方式行事，那么标"检索成功"比标"任务成功"信息量更大。作者还从信息论的角度解释了为什么这两类标注的信息量不对称。
白话版是这样。你手上只有一百条能人工看，标哪个？先标检索这一层。
因为检索在上游。上游错了，下游你标得再仔细也是脏的。你花两个小时判断"这个回答算不算对"，其实那一条的检索压根没召回，模型是在没有依据的情况下瞎答。这两小时白花了。
论文里那套贝叶斯推导我只跟进了一半。信息论那段的细节我没细看，先放着，懂了再补。但上面这条结论，我看不出有什么可疑的地方。
LLM-as-a-judge 被当成有噪声的观测
这是论文的另一处扩展。
它没有把机器评委的分数当成真值，也没当成垃圾。它当成"经过校准的噪声观测"，收进同一个概率模型里。
翻译一下。它承认机器打分是会飘的，但把飘的幅度也一起建了模。这样一来，有限的人工判断和便宜得多的自动评估，可以放在同一个框架里算。
这条我觉得方向是对的。要么全信机器，要么只信人工，这两种态度都挺常见，也都挺浪费。承认它会飘，然后给飘的量估个数，比假装它不飘要诚实。
普通人能用上的部分
你不用贝叶斯。你也不用去读那 27 种配置。
你只要在自己的评估表里多分两列。一列记"检索命中没有"，一列记"回答对不对"。两列分开记，问题就露出来一半。
我见过太多人把这两列合成一列，然后陷在"到底是 prompt 的问题还是切片的问题"里反复横跳。分开了就不用猜。
上期那条我讲过命中率怎么算，现在回头看，讲浅了。命中率只是第一列，第二列才是大部分人真正想解决的那件事。
这条我不确定值不值得单独收
整篇论文，普通人拿得走的就两件事：评估要分层看，标注要先标上游。
剩下的对做 RAG 评测和写论文的人有用，对只是在给自己搭个小知识库的人，暂时用不上。
但我还是收了。因为"答对率"这个数在圈子里被当成唯一标准太久了，有人认真去拆它，这事本身就值得记一笔。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。框架那部分尤其欢迎，我确实只懂一半。
下周见。