RAG 评估漂移控制：离线金标与线上真实问题为何会逐渐失配

RAG 团队常有一套离线问题集，发布前计算召回、忠实度和答案评分。它很必要，却会自然老化：产品增加新功能、文档更新、用户换了提问方式、流量从内部员工扩展到外部客户，原先的金标集仍然很高分，线上却开始出现“答非所问”。这不是单一模型退化，而是评估分布与真实分布逐渐分开。

控制漂移的第一步是把离线样本视为有生命周期的数据集。每个样本应记录来源、创建时间、所属产品区域、预期证据、答案条件、语言、难度和最后验证时间。来源可能是人工设计、用户反馈、事故复盘或合成对抗问题，但不能只保留问题和标准答案。

从线上信号选择新增样本

线上并不需要保存所有原始提问才能发现问题。可以记录脱敏后的查询特征、检索路径、零结果、引用点击、追问、用户纠错、人工转接和最终满意度。把高频失败模式聚类后，由评审者挑选可安全纳入金标集的代表问题。这样评估集随真实需求更新，而不是靠团队猜测。

特别关注“看似成功”的样本：用户没有点差评，但立即重复问、改写问题或转到人工渠道，可能意味着首次答案没解决问题。将这些行为与检索证据结合，能区分是文档缺失、路由错误、召回不足还是生成过度自信。

用户点赞不一定意味着事实正确，用户纠错也可能基于旧政策。新增金标样本前，要由领域负责人确认权威证据与适用范围。对时效性强的答案设置过期时间，文档变更后自动重新验证。否则评估集会把旧答案固化成“正确”，反过来阻止系统更新。

离线评估应分层报告：核心安全与权限样本、主流任务样本、长尾问题、最新发布功能和对抗样本分别计算，而不是用一个平均分掩盖某一类崩溃。对于每次检索模型或提示词变更，比较每层的差异和置信区间，允许小范围权衡，但不能牺牲关键安全样本。

新策略先在影子流量中运行，不影响用户答案，只记录与当前策略的候选差异、成本和延迟。对高价值查询抽样人工比较；当离线与影子结果一致改善时，再小比例灰度。灰度期间设置自动回退条件，例如引用缺失率、零结果率或人工转接率异常上升。

验证流程还应检查观测数据是否能跨版本关联：同一查询在不同检索策略、文档快照和模型版本下的结果要能并排比较。没有版本维度，团队很难知道分数变化是内容、索引还是模型造成的。

线上样本进入评估前应先做脱敏、访问控制和最小化保留。不要因为要提升 RAG 就把完整用户提问、文件名或业务数据复制到公共评估集。可以保存结构特征、匿名化查询、证据类型和失败标签；确需原文时走受限审批，并设置明确保留期。

代表性也不能只依赖高频流量。高价值长尾问题、低资源语言、失败后转人工的会话和新功能查询常常样本少，却对体验影响很大。按来源和风险分层抽样，并在报告中显示覆盖缺口。这样团队既能观察真实漂移，也不会让评估数据本身成为新的合规风险。

金标集的每次新增、修订或删除都应像代码变更一样被审阅。提交内容包括问题来源、脱敏说明、权威证据、预期回答条件、适用时间和风险标签；评审者确认它代表真实场景而不是某个偶然案例。对存在多个合理答案的问题，记录允许答案范围和必须引用的证据，避免评分器奖励措辞而忽略事实。

同时维护一个冻结的核心集和一个滚动的探索集。核心集保护发布质量，只有严格审阅后才改变；探索集吸收新功能和线上新模式，可以更快更新。报告中分别展示两者的分数，团队就能看到策略是改善了稳定能力，还是只针对最新样本过拟合。必要时将关键样本按版本锁定，确保历史发布可以重放比较。

评估运行还应固定模型参数、索引快照和评分器版本。若其中任意一个因素变化，结果报告必须显示不可直接横向比较，而不是把两次不同环境的分数画在同一趋势线上。对于关键发布，保留原始检索证据和评分理由，便于后续调查“为什么这次通过、线上却退化”。

发现分层指标异常时，先暂停对应灰度，再确认是数据漂移还是评分链路故障。