RAG 评估别再问‘感觉怎么样’：从 120 个真实问题开始

做第一个 RAG 原型时，团队评估方式是每个人随手问几个问题，然后在群里说“这版感觉更聪明”。换 embedding、chunk size 或 reranker 后，演示问题可能更好，真实用户问题却更差。没有固定数据集，所有改动都能找到一条支持自己的样例。

我们从客服记录、研究任务和失败反馈中整理了第一批 120 个问题。数据量不大，但每条都有来源、期望证据、权限条件和可接受回答标准。RAG 终于从主观演示变成可以回归的系统。

图 1：先判断证据有没有被找到，再判断模型有没有忠实使用；不能用一个总分掩盖不同失败。

数据集保留问题是怎样产生的

type RagCase = {
  id: string;
  question: string;
  userContext: { role: string; allowedDocumentIds: string[] };
  expectedEvidence: Array<{ documentId: string; sectionId: string }>;
  answerRubric: string[];
  mustRefuse: boolean;
  source: "support" | "research" | "production_failure";
  tags: string[];
};

问题文本会脱敏，但不能被改写成系统更容易回答的“标准问法”。口语、省略和错误术语恰恰是真实难度。数据集按版本保存，修改标准需要评审，不把不通过的用例悄悄删除。

检索与生成分开评分

如果期望证据没进入 top K，回答错误主要是检索问题；证据已经出现但模型忽略，才看提示与生成。

Recall@K = 命中的期望证据数 / 期望证据总数
MRR = 第一个正确证据排名的倒数
Citation precision = 被引用且真正支持结论的引用 / 全部引用

我们还记录“最小充分证据”：回答这个问题至少需要哪几段。否则检索返回一整本文档也能获得召回，却把成本和干扰留给模型。

权限错误比答错更严重

每条 case 携带用户可访问文档集合。评估在检索前注入权限，断言 top K 和引用中不出现越权文档。禁止先全局检索再在生成后过滤，因为标题、摘要和排名本身就可能泄漏信息。

评分器也需要被校准

LLM-as-judge 可以扩展评估，但它不是绝对真值。我们先让两位人工标注者独立评 50 条，解决 rubric 分歧，再比较 judge 与人工一致率。Judge 输入只包含问题、证据、回答和 rubric，不告诉它候选模型名称，减少偏好。

对数字、日期和实体关系，优先使用确定性检查；对解释完整性才用模型评分。所有低置信或发布边界附近用例进入人工复核。

回归报告必须能定位到配置变化

每次实验保存 corpus 版本、切分器、embedding、索引参数、reranker、提示版本和模型版本。报告不仅展示总分，还按问题标签、文档类型和失败阶段切片。

{
  "runId": "eval_20250419_07",
  "corpus": "finance-docs-v12",
  "chunker": "semantic-v4:600",
  "retriever": "hybrid-rrf-v3",
  "topK": 8,
  "prompt": "answer-with-citations-v9",
  "model": "pinned-model-version"
}

一次 chunk 调整让总分上升 2%，但“跨章节比较”标签下降 11%。如果只看平均值，我们会发布一个对关键研究任务更差的版本。

线上失败要回流，但不能污染测试集

用户点踩、人工修正和无答案请求进入候选池，经脱敏与标注后加入下一版数据集。用于日常调参的开发集和最终发布门禁集分开，避免团队无意中对固定答案过拟合。

这 120 个问题没有让 RAG 立刻变好，却改变了团队讨论方式。我们不再说“这个回答更自然”，而是能指出检索没找到证据、权限过滤太晚、引用不支持结论，或拒答边界错误。AI 系统能沉淀的第一份资产，往往不是提示词，而是一套来源真实、标准明确、可以反复运行的评估集。

有一件事我在早期吃过亏：评估集只覆盖“模型会不会答”，不覆盖“系统会不会发布”。把同样的用例接上发布流水线，用固定回归集做门禁、用影子流量验证真实分布，是从研究走向工程的那一步。这套完整流程在AI 功能怎么发布里，那里把 120 个问题变成了发布前置条件；评估任务本身的选型标准（频率、可验证性、错误后果）则来自AI 产品的起点不是模型能力。