🧑💻 面试官：你准备怎样评测一个公司内部的 RAG 问答系统？
🙋♂️ 我：可以整理一批问题和参考答案，分别检查检索和最终回答。
🧑💻 面试官：真实问题还不多，让模型根据文档生成一千道题，可以吗？
🙋♂️ 我：可以用来补样本，但还需要检查问题质量和覆盖范围。
🧑💻 面试官：题目、答案和评分都让同一个模型完成，分数很好看。这能说明员工真的会觉得好用吗？
评测集不是凑够一批问答。你需要先证明：这些问题代表了实际任务，而且每道题的“对与错”有独立依据。
面试速答（60 秒版）
构建 RAG 评测集，我会先确定系统服务哪些人、解决哪些问题，再从脱敏后的真实请求、失败案例和业务人员提供的场景中收集样本。缺少的类型，可以用模型辅助生成。
每个样本不只保存问题和答案，还要保存必要上下文、证据位置、文档版本，以及应该回答、追问还是拒绝的判定条件。
合成数据可以补覆盖，但模型可能按文档原句出题，也可能把错误答案一起生成出来，所以需要人工抽查和规则校验，重要样本要逐条确认。
同时，把日常调试使用的数据与最终检验的数据分开，避免反复调到只会答这批题。
评分可以让模型参与，但它只是评价工具。需要用人工确认的样本校准，按问题类型检查结果，不能用一张总分表证明整个系统可靠。
知识点详解：一条能用于评测的样本是怎样来的？
先确定要测的是谁的真实问题
假设咱们做的是员工报销政策助手。
如果模型根据文档出题，它可能问：“差旅管理办法第三章规定了什么？”但员工更可能问：“我去客户现场住了两晚，这张发票能报吗？”
后者缺少城市、出差日期和人员类别等条件。系统应该追问，而不是随便找一条住宿标准给出肯定答案。
因此，评测集应包含实际使用中的表达方式：简称、口语、上下文承接、信息不完整，以及不在系统能力范围内的问题。公开使用真实请求前要取得相应授权并脱敏，不能为了更像线上数据而保留姓名、账号或票据隐私。
没有上线日志时，可以让业务人员按典型工作流程提供场景，再用合成题补足缺口。不必假装这些场景就是“真实用户数据”。
参考答案，不能只是一段标准话术
假设测试语料中有一份虚构政策：某类员工在某城市出差，住宿报销存在金额上限，并且需要符合日期和凭证要求。
若样本只有“问题：能报多少？答案：不超过某金额”，你无法判断系统是不是引用了错误版本，也看不出它有没有漏掉适用条件。
一条更完整的样本可以这样设计：
| 内容 | 用途 |
|---|---|
| 用户问题与必要历史 | 还原本次到底在问什么 |
| 用户身份与授权范围 | 明确允许访问哪些资料，不放真实凭证 |
| 语料快照与政策版本 | 确保不同实验基于同一份事实 |
| 证据段落及位置 | 判断检索是否找到了依据 |
| 必须包含的答案要点 | 检查金额、条件和例外是否完整 |
| 预期行为 | 回答、追问、说明未知或拒绝越权请求 |
这里的参考答案可以有多种表达，不必逐字一致。重要的是哪些事实必须正确，哪些内容不能凭空补充。
同时，参考证据也不一定只有一个固定 chunk 编号。切分策略变了，编号就可能变化；更稳妥的是记录原始文档和证据范围，再按本次切分结果映射。
不要把“文档里都能找到”的题当成完整评测
报销助手至少会遇到几类不同问题：单条政策就能回答的、多份资料需要一起看的、缺少条件需要追问的、政策中没有答案的，以及当前用户无权查看的。
如果题目全部从某个段落的原句改写而来，检索很容易匹配，看起来召回很好，但它没有检查跨文档推理、无答案处理和权限边界。
Ragas 的测试集生成文档提供了单跳、多跳等不同类型的合成思路。它能帮助补充覆盖，但“生成成功”不代表题目已经适合业务，仍然需要核对证据与判定规则。
例如生成了一道“试用期员工出差能否按正式员工标准报销”的题，先检查测试语料是否真的包含这个规则。如果没有，就应该把预期行为标成证据不足，或者移除这道无法正确标注的题，而不是接受模型顺手编出的答案。
自己出题、自己打分，容易形成什么盲区？
模型可能偏好自己熟悉的问法和答案表达。更重要的是，如果生成参考答案时就理解错了政策，后面评分再拿这个错误答案当标准，就可能把正确系统判错。
换一个模型当裁判可以减少部分同源偏差，但不能自动修复错误标签。因此，关键步骤是建立有人工确认和原文证据的样本，再检查裁判是否与这些判定一致。
对金额、日期、是否越权等可以明确检查的内容，尽量使用确定规则。对解释是否完整、回答是否含糊等较开放的项目，可以使用模型评分，并抽查它给出的依据。高风险错误单独统计，不要被大量简单题的高分盖住。
调试题和最后验收的题，要隔开
如果团队每天看着同一批题修改 Prompt，最后再用这批题宣布“明显提升”，结论会偏乐观。
可以留出一部分样本做最终检验。相同问题的改写、同一工单派生的问题，应放进同一组再划分，避免表面上分了集合，实际只是把原题换了个说法。
这里隔离的是评测样本和调参反馈，不是禁止 RAG 访问它本来就应该检索的知识库。为方便对比，要固定语料与评测集版本；知识更新后重新标注受影响样本。LangSmith 的评测说明也支持数据集拆分与版本管理。
面试官继续追问
到底准备多少道题才够？
没有一个通用数量。先覆盖关键业务路径和高风险失败类型，再根据错误分布扩充。几十道经过确认的题可以用于早期发现问题，但不能因此宣称已经代表全部用户。样本数量、覆盖范围和结论的可信程度要一起说明。
系统拒绝回答，是不是都应该扣分？
不是。资料缺失、关键条件不够或用户无权访问时，说明未知、追问或拒绝可能才是正确行为。评测标签要写清楚预期动作，否则系统越谨慎反而分越低，就会把优化方向带偏。
文档更新了，旧评测集还能继续用吗？
可以保留用于旧版本回归，但不能把过期参考答案直接用于新政策评测。需要找出受影响样本，重新核验答案和证据，形成新版本。比较结果时说明是否使用相同语料和题集，否则分数变化可能来自题目变化。
面试速记卡
- 样本来源：真实需求与业务场景为主，合成题用于补覆盖。
- 样本内容：问题、条件、证据、版本和预期行为一起保存。
- 答案依据：来自可核对资料，不把模型生成结果直接当真值。
- 数据隔离：调试与最终检验分开，相似题按组处理。
- 结果分析：按类型与风险看错误，不只追求平均分。
