大模型评测集如何构建才可靠？

简化版

可靠评测集首先要代表真实任务，而不是随手收集“看起来困难”的问题。应从线上分布、业务关键路径、历史失败和安全边界中分层抽样，明确输入、期望行为、评分规则和严重度。

数据要去重、脱敏并隔离训练集；主观任务需要多标注员和仲裁，客观任务优先使用可执行判定。最终不仅保存问题与答案，还要保存来源、版本、标签、评分器和变更记录，防止评测集随着产品迭代失真。

评测集不是一批静态题目，而是对“产品应该如何表现”的可执行契约。

详细版

一个完整样本至少包含：

id: support_refund_0042
input: "订单已发货还能退款吗？"
context_version: policy_2026_09
expected_behavior: "说明条件，并引用现行政策"
slice: [refund, post_shipment, zh-CN]
severity: high
scorer: grounded_rubric_v3
source: anonymized_production

若线上流量中普通问答占 80%、工具任务占 15%、高风险任务占 5%，不能机械照比例抽样，否则只有 50 条高风险样本的 1000 条评测集难以估计低频严重错误。可同时维护“代表性集”和“压力集”，分别回答总体体验与最坏风险。

子集	样本来源	主要用途
代表性集	线上分层随机采样	估计总体效果
能力集	产品需求与标准任务	衡量核心能力
挑战集	专家构造、对抗生成	暴露边界失败
安全集	政策风险与越狱样本	验证防线
回归集	历史线上事故	防止旧问题复发

完整版教学

一、从决策问题反推评测目标

先明确评测要支持什么决策：选基础模型、验证 Prompt 改动、决定是否发布，还是监控线上漂移。不同决策需要不同样本与统计精度。

若目标是发布客服助手，核心指标应围绕政策正确、引用、工具成功和拒答边界，而不是只使用通用知识 Benchmark。

二、定义任务边界和评分单位

明确输入中有哪些上下文、模型允许使用哪些工具、输出格式和不可接受行为。评分单位可以是整段回答、原子断言、工具步骤或完整会话。

长答案只给一个总分不利于诊断。可拆成事实正确、完整性、引用、风格与安全，每项有独立 Rubric。

三、样本应从哪里来

线上真实请求最能代表用户，但会包含隐私和历史系统偏差；专家题能覆盖关键规则，却可能过于理想化；合成数据便宜，但会继承生成模型模式。

最佳实践是混合来源并记录 provenance。任何外部或合成样本都要抽样人工核验，不能把模型生成的答案直接当真值。

四、为什么需要分层抽样

总体随机样本会被高频简单请求占满。应按语言、任务、用户群、风险、长度、工具类型和难度分层，再为关键稀有层过采样。

目标	抽样方式	汇总方式
线上总体质量	按真实流量比例	使用流量权重
高风险可靠性	高风险过采样	单独报告，不稀释
版本回归	固定历史失败	等权或严重度加权

过采样后若要估计线上总体值，必须使用原分布权重恢复，而不是直接平均。

五、样本量如何决定

样本量取决于指标方差和希望检测的最小差异。对二项通过率，标准误近似为：

SE = √(p(1-p)/n)
95% CI ≈ p ± 1.96 × SE

当 p=0.8、n=100 时，区间半宽约 7.8 个百分点；n=1000 时约 2.5 个百分点。只有几十条样本很难证明 1% 的提升。

六、如何编写标注规范

Rubric 要包含正例、反例、边界例和优先级。避免“回答是否良好”这类无法复现的描述，应写清哪些事实必须出现、哪些错误一票否决。

如果两位合格标注员长期无法一致，首先应检查任务定义和 Rubric，而不是简单要求他们“更认真”。

主观任务使用 2～3 人独立标注并仲裁，定期计算一致性；争议样本进入指南更新循环。

七、真值应该怎样保存

开放式任务不一定有唯一参考答案。可保存必需事实、允许变体、禁止内容和证据来源，而不只是单段 Reference Text。

政策和知识会变化，真值必须关联版本和有效期。过期参考答案会把正确的新模型判错。

八、如何避免数据泄漏和污染

评测样本不得进入微调、Prompt 示例或检索索引。公开 Benchmark 可能已出现在预训练数据中，应准备私有保留集和新鲜时间切片。

使用语义近重复检测，而不仅是字符串哈希。将同一模板改几个实体后分别放入训练和测试，仍会造成模板泄漏。

九、多轮和工具任务如何评测

多轮任务要保存初始状态、用户模拟器行为、工具 Mock/沙箱和结束条件。仅比较最终文本，可能漏掉中间越权调用或错误副作用。

initial state -> conversation -> tool trace -> final state

理想评分同时验证最终状态、步骤合法性、调用成本和是否需要人工接管。

十、自动评分器如何校准

规则、单元测试和 Schema 校验优先用于可客观判断的部分。LLM Judge 适合语义和风格，但要与人工黄金集比较，检查位置偏差、长度偏差和自偏好。

评分器版本也是评测协议的一部分。更换 Judge 后应重新跑历史版本，避免把评分器漂移误当模型提升。

十一、数据集版本与维护机制

每个样本要有稳定 ID、来源、创建时间、标签和修改原因。新增线上事故时进入候选池，经去重、标注和审核后再进入正式集。

可维护固定 Core Set 用于长期趋势，Rolling Set 反映近期流量，Challenge Set 捕获新攻击。三者不能混成一个不可解释总分。

十二、发布前如何检查评测集本身

检查重复率、标签分布、敏感数据、答案有效期、标注一致性和评分器覆盖。抽样让领域专家从零复核，确认没有把旧系统输出当黄金答案。

还应对样本做“可行动性”审查：失败后团队是否知道该改数据、Prompt、模型、工具还是策略；无法诊断的集合价值有限。

十三、常见误区与追问

误区：题目越难，评测集越好。 脱离真实分布的难题不能代表产品质量。
误区：样本越多越可靠。 大量重复、错误标注只会让偏差更稳定。
误区：每题必须有唯一标准答案。 开放任务更适合事实清单和 Rubric。
误区：线上随机采样足够覆盖安全风险。 低频高危事件必须过采样并单独报告。
误区：评测集建完后不应再变化。 知识、产品和攻击都会变化，需要版本化维护。
追问：如何兼顾趋势可比与新鲜度？ 固定 Core Set，加独立 Rolling/Challenge Set。
追问：合成样本能否使用？ 可以扩大覆盖，但必须记录来源、去重并人工抽检真值。

十四、加强记忆

先定决策：评测为选型、发布还是监控服务；四类来源：真实流量、专家设计、合成挑战、历史事故；分层抽样：总体按流量，高风险单独过采样报告。真值可审计：Rubric、证据、版本、有效期缺一不可；持续维护：固定 Core 保趋势，Rolling 保新鲜，Challenge 保边界。

项目实战落地

项目里怎么做的

《AI Agentic RAG高级企业知识库平台》在建评测集之前，先把「一条用例至少要有什么」从指标倒推出来：

指标                 需要的输入
Context Recall       问题 + 标准答案 + 检索到的资料
Context Precision    问题 + 检索到的资料
Faithfulness         检索到的资料 + 生成的答案
Answer Relevancy     问题 + 生成的答案

资料和答案是跑评测时现场产生的，只有「问题」和「标准答案」必须预先准备，而标准答案只有上下文召回用得到。落到 eval_case 表上：

字段	要求
`question`	必填，所有指标都要
`ground_truth`	必填，上下文召回要；手工录入不填时提示「请输入标准答案，没有它就算不了上下文召回指标」
`reference_chunk_ids`	可选，标准答案对应的片段 ID；有了它，上下文召回直接做集合运算，不调模型
`source`	手工录入、文档生成、反馈沉淀三种来源
`enabled`	是否参与评测；标准答案没补完的用例默认停用

用例表的索引建在 (dataset_id, enabled) 上，因为跑评测的查询条件正是「某个评测集里启用的用例」。评测集的三种来源各自的用法，见「RAG 评测集怎么构建？为什么每条用例要标到来源片段？」。

为什么这样取舍

最低要求由指标倒推。 评测集要支撑哪些指标，就决定了每条用例必须带哪些字段；少了标准答案，这条用例只能算三个指标。
提示语写后果。 只说「标准答案不能为空」，管理员不知道漏了它会怎样；写明「算不了上下文召回」，他就知道这个字段为什么必填。

面试官还会追问

从文档自动生成问答对时，一次最多把多少字的片段交给模型？为什么要限制，限制带来了什么代价？
删除一个评测集时，它下面的用例怎么处理？

学完《AI Agentic RAG高级企业知识库平台》，上面这些追问你都会迎刃而解。

简化版

详细版