如何构建评测题目和真值？

核心回答

构建评测集要同时解决题目是否覆盖真实任务，以及真值是否足以判断结果。先按业务目标整理常见任务、关键边界和失败场景，再从真实请求、历史缺陷、人工设计与经过审核的合成题中取样。每条题目都要保留完成任务所需的上下文，不能只留下一个脱离业务状态的问句。

真值不一定是一段唯一标准答案。RAG 问答可以标注必需事实、支持证据和适用版本；工具任务可以标注允许的参数与最终状态；开放式分析则用明确的评分维度和质量锚点。可计算、可执行的结果尽量独立验证，语义判断由业务标注与评判标准共同约束。

入集前检查题目能否解答、证据是否充分、标注是否一致，并用已知正确和错误结果检验评分规则。随后去重、划分调参与保留测试集，固定知识、工具和评测集版本。上线后持续把新失败模式补为回归题，让评测集既能反映业务分布，也能保护关键能力。

题目从哪里来，怎样选

保留真实任务的条件

已有系统可以从脱敏后的用户请求、人工验收用例、问题单和失败 Trace 中提取样本。除了问题文本，还要保留影响答案的会话背景、用户权限、时间、知识版本、工具返回及初始状态。

例如，用户说“这笔也取消”，只有上一轮指定的订单和当前状态一并保留，题目才有确定含义。缺少上下文时，应补齐可回放的条件，或把预期行为设为澄清，而不是替用户猜一个目标。

同时覆盖常见与容易失败的场景

可按业务任务、输入形式、难度、时效与权限约束分组，覆盖正常路径、信息不足、无答案、多跳、冲突资料和工具异常。每类同时收集应该触发某行为和不应该触发的情况，例如应查知识库与可直接回答、应执行工具与应先澄清，避免单向训练出过度检索或过度调用。

随机抽样可以帮助估计整体使用表现，但有限样本容易漏掉低频的重要问题。实践中可保留接近真实流量分布的代表集，再补充边界、风险与历史缺陷回归集。补充集经过刻意加权，汇总时应与真实流量口径区分，并报告各组数量。

合成题用于补覆盖

冷启动可以从知识文档或已确认的种子题生成候选问题，覆盖同义表达、错别字、跨段信息和关键边界。生成时要保留依据及定位，检查题目是否可解、答案是否被上下文支持、有没有把文档措辞直接搬成容易匹配的问句。

多跳或跨页题应保留完整的证据组合。按单页独立生成后再拼接，可能漏掉表头、前置条件或引用关系。需要将相关页面、章节或表格结构一起纳入标注，并用独立审核确认生成结果；模型生成的问题、答案和自评分不能共同构成真值保证。

真值按任务类型设计

RAG 与知识问答：标注事实要点、支持的文档或片段、出处、版本、适用条件和允许的替代表达。相关但不支持结论的引用不算正确；无答案题应定义何时澄清或说明资料不足。不要仅以答案文本相似度替代事实判断。

计算、SQL 与代码：使用独立构造的小数据集、业务公式、测试断言或已验证的参考实现确定结果。明确单位、精度、排序和空值等口径。两条写法不同的 SQL 可以产生相同正确结果；只在一个数据集上碰巧相同也不足以说明逻辑等价，需要边界数据和规则共同验证。

工具执行与状态变化：定义初始状态、任务目标、必要约束以及可观察的最终状态。例如结果是否写入指定测试对象、金额是否正确、是否产生重复记录。最终回复“已完成”只是文本；评分依据应包含实际结果。有多条合法完成路径时，保留必要的业务约束，不固定无关的工具调用顺序。

开放式分析与写作：把准确性、覆盖、依据和表达等维度拆开，给出每个分档的可观察锚点，必要时提供多个合格示例。对于无法取得客观真值的维度，保留人工判断与不确定性，不把一个模型分数解释为唯一答案。

一条样本可以怎样组织

下面是自定义数据结构的参考例。假设知识库明确规定：V2 日志保留 7 天，过期不支持常规查询；另有旧版 V1 的 30 天规则。评测要同时检查版本与两项事实，而不要求复述固定句子。

{
  "id": "log-retention-v2-001",
  "inputs": {
    "question": "V2 的日志能查多久？过期还能直接查吗？",
    "product_version": "V2"
  },
  "fixture": {
    "knowledge_snapshot": "demo-v1",
    "documents": [
      { "id": "log-v2", "text": "V2 日志保留 7 天，过期不支持常规查询。" },
      { "id": "log-v1", "text": "V1 日志保留 30 天。" }
    ]
  },
  "reference": {
    "required_facts": ["V2 保留 7 天", "过期不支持常规查询"],
    "supporting_document_ids": ["log-v2"],
    "incorrect_claims": ["V2 保留 30 天", "保证恢复已过期日志"]
  },
  "grading": "逐项检查事实、版本与引用依据，允许同义表述",
  "metadata": {
    "origin": "本文构造的示例",
    "tags": ["版本约束", "多事实"],
    "annotation_version": "v1",
    "split": "test"
  }
}

运行时，输入进入被测系统，知识快照用于准备检索环境；参考事实和判定规则交给评分器。参考答案不应意外传入待测模型。这样既能检查检索是否找到正确版本，也能检查回答是否遗漏“过期不可直接查询”，以及引用是否支持结论。

怎样检查标注和评分规则

先让熟悉业务的人依据同一份规范独立标注一部分样本，对分歧仲裁。分歧可能来自题意不清、证据冲突、规则过期或评分口径不同，修正原因后再确定标签。尚不能确定的题目可以保留为待确认样本，避免混入已有明确标准的评分汇总。

再用已知合格答案验证题目可解、评分器能够放行；加入错版本、漏条件、错误数值、无依据引用等反例，检查它是否会误判。数值容差、单位换算、列表顺序等规则应按业务含义定义，不能为了提高通过率盲目去除单位或忽略顺序。LLM 评分器也需要用这些人工确认样本校准，并保留判定依据与无法判断的出口。

评测失败时同时检查任务、运行环境和评分器：若评分器要求一个题干没有规定的文件路径，或合法表述被严格字符串匹配拒绝，低分反映的可能是评测缺陷。读取具体执行记录，才能区分系统错误与标注错误。

数据集怎样长期维护

先按会话、文档来源、问题家族等关联关系去重和切分，再做表达改写。否则同一原题的多个近义版本落在调参集与测试集两边，会高估泛化效果。保留测试集不参与 Prompt 示例选择、检索规则调参或训练，新增题也沿用这个边界。

固定评测集、标注、评分器、知识库和工具环境版本，并保存每次实验所用版本。规则变化时更新受影响真值，记录改动原因；知识或权限变化后，旧答案也可能不再适用。比较版本时使用同一评测快照，避免把题目变简单误认为模型进步。

维护上可以同时保留稳定回归集和持续扩充的能力集。前者保护已完成的关键任务，后者纳入新需求、长尾和失败模式。样本量根据场景覆盖、基线波动和需要识别的改进幅度决定；大量相似题不能替代少量关键边界。

常见追问

没有专家标注预算，怎样启动？

先从现有人工验收、明确业务规则和可执行结果开始，建立一小组高价值样本，再用模型协助整理和扩展。把有限审核投入到关键规则、分歧与低置信样本，逐步补足覆盖；未经确认的合成标签可以保留为候选。

用户点赞能直接当真值吗？

反馈是重要的选样和业务效果信号，但可能受语气、预期和用户专业程度影响。可以用它发现候选好例或失败例，再结合证据与结果确定标注，避免直接把点赞等同事实正确。

没有真值，是否还能做线上评估？

可以观察格式、错误、引用支持、工具结果及用户反馈，也可以采用无参考评分发现异常。这些信号有助于选出需要复核的样本；要评价完整的答案正确性或任务成功，仍需足够的业务依据。经确认的线上样本可以再沉淀为离线评测题。

对应教程

参考资料