北京
先问一个问题：如果你的AI系统有一套看起来很漂亮的质量评分，四项指标全部达标，你会不会默认它运转正常？Vicquant的作者原本也是这么想的，直到一位读者提醒他去检查路由路径。
Vicquant回答金融问题有两条路：一条是rag_vault，检索用户上传的文档，比如401(k)对账单或税务汇总，并标注确切出处；另一条是fast_chat，直接靠模型的通用金融训练数据作答。一个小的分类启发式规则，也就是查询路由器，决定每个进来的问题走哪条路。
问题就出在这里。作者的质量测试用25道黄金问题打分，衡量faithfulness和context recall等四项指标。这25道题全部直接进入RAG路径。也就是说，这四个数字只描述了问题已经抵达RAG之后的表现，对路由器有没有选对路一无所知。
这是一块盲区。当他真正去审计路由器时，发现20道文档类问题里有18道压根没进文档库。
后果可以这样理解：用户上传了401(k)对账单，问"我雇主用的是什么匹配公式"。走RAG，系统会翻对账单、提取匹配档位、引用第2页；走Chat，模型凭通用知识作答，可能非常自信地给出"50%匹配上限6%"的标准说法，而雇主实际公式是"100%匹配上限4%"。第二种情况下，质量指标一点没掉，因为问题从未进入RAG管道。失败对评估框架完全隐形。
两种错误付出的代价并不对等。正因为失败成本严重倾斜，路由器的设计应当大幅偏向检索——拿不准的时候，问题必须交给RAG。
除了延迟基准，作者新增了一个追踪指标：文档类问题被错误路由到聊天路径的比例。反向情况也一并记录，即通用问题被送进RAG，让工程上的取舍保持透明。
检查是这样跑的：40道题的干净基准集，20道关于样本401(k)对账单的文档类问题，20道通用个人理财问题；每道题的预期路径在跑基准之前就已锁定；测试用户上传样本文档后，通过API逐条派发查询，路径直接从流式响应的元数据里读取。
修复前，18道文档题为什么漏掉了文档库？原因分三类：
- 人称物主代词，8次漏判。像"我雇主用什么公式""谁被列为我的第一受益人"这类问题用的是"我的雇主""我的余额"这种个人指代，而非通用关键词，路由器把它们误判成普通闲聊。
- 文档名词缺失，4次漏判。提到"这份对账单"或"我的计划摘要"的问题，在旧关键词列表里找不到精确的词元匹配。
- 计划术语未识别，6次漏判。分级归属时间表、在职转存、计划贷款发起费这类福利运营术语，没有任何启发式触发词。
修复方案叫"默认检索"。架构从"只有命中明确关键词才送RAG"翻转过来：只有当查询匹配到毫不含糊的通用金融正向信号，比如"复利是怎么运作的""解释一下50/30/20预算"，才送fast_chat；任何模糊的、边界性的、带代词锚定的问题，一律默认走rag_vault。如果用户根本没上传文档，亚毫秒级的检索检查会返回零个匹配块，管道平滑地流式输出标准答案，既不报错也不注入空上下文。
验证用了两套题。第一套是40题的基准集。第二套是30道未见过的全新问题，15道文档类、15道通用类，只跑一次、不做调参，用来测试对新表述的泛化能力。作者也注明：15题的样本里出现0次漏判，统计上只能排除真实漏判率高于约20%的可能，更大的持续测试语料会收窄这个置信区间。
回退的成本呢？本地计算可以忽略，本地混合BM25与向量检索平均计算耗时13.8毫秒。上下文开销方面，一次回退问题会多出约400个检索上下文的token，在OpenRouter上大约多花0.000015美元。把73%的边界性通用问题送进RAG管道，是有意为之的设计选择——付出14毫秒计算和不到一分钱，远比让参与者的退休问题落到一个看不见他对账单的聊天模型手里要好。
作者最后总结：质量指标只能衡量流经它的东西。四个RAG评分在数学上无懈可击，却对最危险的失败模式完全失明，因为失败发生在管道开始之前。如果你的AI系统在RAG管道前面立着路由器、分类器或意图门，先去评估那道门，再按错误实际给用户造成的代价来加权。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
