RAG 评测怎样定位问题：把检索、依据和答案完整性分开看

检索没有找到有效条款，模型可能给出一个碰巧正确的常识答案；检索正确，模型也可能遗漏例外。把这些情况合成“回答满意度”，会让团队无法确定下一步改什么。

Microsoft 的 RAG 评估文档分别讨论检索、回答依据、相关性和完整性，并注明部分评估器处于预览阶段。本文采用检查维度，不要求读者使用特定评估器或沿用其分数阈值。

资料更新后保留原快照或可重现版本。若用今天的规则评价昨天的任务，结果可能反映版本差异。敏感材料脱敏并按权限保存，不为评测建立一份无人管理的全量资料副本。

对每道问题指定可接受的证据位置，再检查实际返回。简单问题可能只需一条条款，组合问题可能需要主规则与例外两块。只命中主规则，不等于证据完整。

可以计算“包含至少一条正确证据的查询数 / 存在可检索正确证据的已标注查询数”作为命中率示例，同时检查关键证据覆盖和排序。这不是全部检索质量，更不能替代权限检查。不存在答案的问题要单独评估，不能要求它们命中一个虚构标准块。

分组查看产品编号、制度解释、跨文档比较和多轮追问。平均值上升时，某一组仍可能下降；业务最在意的任务应单独展示样本与失败原因。

可以用两道演练题验证分项口径。第一道问商品 A 的当前申请期限，资料中有主条款和渠道例外；只取到主条款时，可能达到“至少一条正确证据命中”，却仍缺关键证据。第二道问资料库从未记录的承诺到账日期，应按无答案行为评分，不要求命中一段看似相似的说明。这样的反例能解释为什么命中率与业务可用性不同。再加入一条本来有完整答案却被拒绝的样本，检查系统是否为了减少错误而过度拒答；报告分组展示正确拒答、误拒答和仍然编造的结果。

报告保存样本清单与各项分母，注明哪些题确有正确证据、哪些应停下。以后换一批题时，重新计算共同样本，避免把题型变化解释为系统改善。

把关键条件写进量表，例如期限、渠道、商品类型和授权状态。不要只给“准确、专业、全面”三个抽象词，也不要把文案相似度当作业务正确性。

用代码检查结构、对象标识和必须禁止的内容；用经过校准的模型评分处理语义；由业务专家抽查关键任务与新规则。Anthropic 的评测文章说明不同评分方式的取舍，不能把模型裁判当作无误的权威。

给评分器看正确、漏条件、错误引用、编造事实和正确拒答的反例。确认它能区分后，再运行批量评测。若评分说明不清，先修口径；不要直接调系统让它迎合错误评分器。

权限泄露、关键金额或不可逆动作错误单独报告。大量低影响问答通过，不应抵消一条越权资料引用。项目放行条件由任务影响决定。

一次只调整与失败相关的变量，记录配置版本。这样分数变化能追溯到具体修改，而不是一次同时换模型、重切资料和改提示词后猜测原因。

先从近期真实问题挑选有代表性的正常、缺资料、冲突和越权样本，明确证据与预期行为。保存一次基线，后续更新资料或配置时运行受影响案例，线上失败复核后补入回归。

本文适合企业知识问答与带检索的助手，不提供通用的通过比例或样本数。评测能够暴露已覆盖问题，仍需要线上监控与业务反馈发现新的任务类型。