Vicquant的RAG评测盲区：20道文档问题漏掉18道，先查路由再看回答质量
上传了退休账户对账单，再问AI："公司到底按什么公式给我配缴？"你期待它翻开文件找答案。可如果系统连文件都没看，只凭常见规则回答，答案越流畅，反而越难让人察觉问题。
Vicquant的一次路由检查就发现了这样的漏洞：20道需要依据文档回答的问题，有18道根本没进入文档检索流程。原有的四项RAG质量指标也完全看不见这些错误。
这件事提醒所有使用RAG（检索增强生成）的产品：评测不能只检查"查完资料后答得好不好"，还得先确认"该查资料的问题，是否真的去查了"。
回答质量再高，也救不了走错入口的问题
Vicquant回答金融问题有两条路径。rag_vault会搜索用户上传的文件，比如401(k)退休储蓄计划对账单或税务汇总，并引用具体来源；fast_chat则依靠模型训练中学到的一般金融知识回答。
决定问题走哪条路的，是query router：一套轻量的分类启发式规则。可以把它理解为入口处分流的工作人员，先判断这件事需要调取个人档案，还是用通用知识就能解释。
原有质量评测使用25道预设标准问题，计算包括faithfulness（回答是否忠于检索内容）、context recall（所需信息是否被检索覆盖）在内的四项指标。但这25道题全部直接进入RAG路径，绕过了入口分流。
这些分数因此只能说明问题进入RAG之后的表现。即使计算本身没有错，也无法回答另一个更早的问题：该进RAG的问题，有多少被挡在门外？开发者在读者提醒后检查query router，才发现这块盲区。
把个人文件问题交给通用知识，错误代价更高
以雇主配缴为例，用户上传401(k)对账单后，问："公司按什么公式给我的缴款做配缴？"正确进入RAG时，系统应该检查文件，提取配缴档位，并引用对应页码。案例中用的是文档第2页。
如果问题被送往fast_chat，模型可能给出一种常见规则，例如"对不超过工资6%的缴款，按50%配缴"。但用户所在公司的实际规则，可能是"对不超过工资4%的缴款，按100%配缴"。这是用来解释风险的假设对比，并不是一次已记录的错误回答。
两种误分的后果并不对等。一般金融问题被送去检索，可能多花一点时间、带入一些用不上的资料；个人文档问题被送去通用聊天，却可能让一个听起来很专业的答案，套错了用户的具体条件。
这更麻烦的地方在于，后一种错误不会自动拉低原有RAG评测分数：问题压根没进入那套评测覆盖的流程。对涉及个人退休安排的问答，分流规则应当更重视漏查文件的风险，不能只追求两条路径分得"整齐"。
先给问题标好答案路径，再从API检查实际去向
为补上盲区，开发者在延迟基准之外，增加了一项直接指标：本应依据文档回答的问题，有多少被错误送到了聊天路径。同时也记录反方向的误分，即一般金融问题有多少进入了RAG，让取舍能够被看见。
检查使用了40道题：20道围绕一份样例401(k)对账单提问，另20道是一般个人理财问题。每道题的预期路径都在运行前确定，避免看到结果之后再修改判定标准。
执行时，测试用户先上传样例文档，再通过API逐一发送问题。实际路径直接从流式响应的metadata中记录，无需根据回答"像不像查过资料"来猜。模型完全可能没查文件，却写出一副查过的样子，这一步因此很关键。
修复前，20道文档问题中有18道没有进入文档库，也就是这组题的漏检索比例达到90%。具体结果图位于下方；这一比例描述的是这组基准题，不能直接当作全部真实用户请求的错误率。
关键词没有命中，不代表用户不需要查文件
18次遗漏可以分成三类。第一类有8次，问题使用了个人所属表达，例如"我的雇主采用什么公式""谁被列为我的主要受益人"。旧规则没能把这些指向个人资料的表达识别出来，反而把它们当成了一般聊天。
第二类有4次，问题提到了"这份对账单"或"我的计划摘要"，但没有精确命中旧关键词列表。用户已经在指着文件说话，系统却还在等某个指定词出现，像是办事窗口只认表格上的标准用语。
第三类有6次，涉及graded vesting schedule（分阶段取得雇主缴款归属权的安排）、in-service rollover（在职期间的账户资金转存），以及plan loan origination fee（计划贷款发放手续费）等福利计划术语。这些词没有对应的启发式触发规则，问题也就漏了过去。
这三类错误说明，仅靠不断补关键词，很容易追着用户的说法跑。检查类似系统时，应当覆盖个人所属表达、对文档的间接指代，以及业务中的具体术语；只测试标准问法，会把最需要检查的地方藏起来。
Retrieval by Default，把不确定的问题先送去检索
修复采用了Retrieval by Default：从"只有明确命中关键词才进入RAG"，改成"只有明确属于一般金融知识的问题才进入fast_chat"。例如"How does compound interest work?"或"Explain the 50/30/20 budget"这类通用解释，才满足直接聊天的条件。
含义模糊、处在边界上，或带有指向个人资料的代词表达，都默认进入rag_vault。这里既改变了词表，也改变了默认选择。系统不确定时，先检查用户资料是否能提供依据。
用户没有上传文件怎么办？按开发者描述，没有文档时，检索检查会在不到一毫秒内返回零个匹配片段，随后流程正常输出一般回答，不因空结果报错，也不把空上下文硬塞进去。这个空库检查耗时，与后面有实际检索工作时的平均计算耗时，是两个不同情形。
验证分成两组。第一组重新使用40道基准题，检查已知问题是否得到修复。
第二组使用30道此前未见的问题，其中15道文档问题、15道一般金融问题；只运行一次，没有再针对结果调参。不过，这组题被明确标为"非独立"，不能把它当成完全独立的外部验证。
即使15道文档题没有出现遗漏，也不意味着真实漏检索率已经降到零。开发者给出的统计提醒是，这么小的样本，零遗漏仍只能把真实遗漏率的上界粗略约束在20%左右；具体解释还取决于统计假设。要进一步缩小不确定性，需要持续扩大测试题库，覆盖更多表达方式。
多查一次的成本，要和漏查的后果一起算
默认检索当然有成本。开发者报告，本地混合BM25与向量检索的平均计算耗时为13.8 ms；一次回退检索大约增加400 tokens的上下文，在所用OpenRouter配置下，费用约增加0.000015美元。这些是该项目报告的条件和结果，不能直接套到其他系统的延迟或账单上。
开发者还报告，73%的边界型一般问题会经过RAG流程，并将其视为有意接受的取舍。这里说的是"边界型一般问题"，不能扩大成所有一般金融问题，更不能理解为所有请求。
多付约14 ms的检索计算时间和少量上下文费用，通常比让个人退休问题落到一个看不见对账单的模型手里更容易承担，这就是接受这项成本的理由。但这也不代表"凡事检索"就自动正确；路由解决的是该不该查资料，检索是否找对、回答是否忠于资料，仍需要原来的质量评测。
选择路由策略时，可以先问两件事：少查一次，会不会把通用规则误当成用户的具体条件？多查一次，实际增加多少时间和费用？把两种错误分别统计、分别估算代价，才能决定默认路径该偏向哪边。
回到开头那个问题：用户上传了对账单，问公司的配缴公式，系统首先要证明自己确实去看了文件。检查一个带query router的RAG产品时，不妨先准备一组必须依赖文档的问题，提前锁定预期路径，再通过API记录实际去向。入口查清楚了，后面的质量分数才知道究竟在替谁作证。