如何保证评测集覆盖目标场景且可用？

核心回答

评测集不能保证穷尽所有真实场景，但可以证明它覆盖了明确的目标范围、主要流量和关键风险。先把业务任务、输入形态、难度、权限与工具状态列成覆盖矩阵，再结合线上分层抽样、已知失败和人工边界样本构建数据。

“可用”还要求每条样本能执行、能复现、能判分：保存输入与初始环境、期望行为、评分规则和版本，先小规模试跑排除无解任务、失效接口与模糊标注。开发集和保留测试集按用户、会话或来源组去重隔离，持续用线上新问题补缺，而不是不断围绕同一组题调提示词。

展开解析

1. 覆盖矩阵从真实任务出发

以客服 Agent 为例，任务可以包括政策问答、订单查询、退款申请和转人工。每种任务再交叉检查单轮或多轮、文本或附件、信息完整或缺失、正常或越权、工具成功或超时、订单状态是否变化等条件。

不需要穷举所有笛卡尔积，先覆盖高频主路径和高损失组合；发现事故或新流量后再补充。样本同时保留两种视图：一组按真实流量分布估计整体效果，另一组加强边界、长尾和对抗情况做专项门禁。不能用人为加重难例后的简单平均直接宣称线上总体成功率。

2. 把“覆盖了”变成可以核对的证据

每条样本标记任务类型、语言、难度、渠道、风险、来源及失败模式，然后统计：哪些场景有样本、样本来自哪些独立来源、哪些分层仍稀疏、线上近期流量有哪些未被表示。

如果只有 Top 20 典型案例，可以把它称为主路径或冒烟集，说明覆盖哪些已知任务。它不能仅凭“典型”证明覆盖率；还需要与真实流量中的任务分布、边界和失败模式比较。样本量由希望识别的差异、方差、分层要求和风险决定，没有通用数量门槛。

3. 每条用例需要完整的执行契约

字段	用途
输入与历史	重建本次任务，而非只保留一句孤立问题
初始环境与工具数据	还原订单、权限、时间和资料版本等必要条件
期望行为	正确答案、应澄清什么、应拒绝什么或最终业务状态
评分器与依据	确定性断言、语义评分标准、业务专家参考
样本与版本标识	比较不同模型、提示词和流程的结果
运行记录	轨迹、结果、费用、耗时和失败分类

先检查基线能否运行，再核对评分器能否识别明显正确与明显错误的输出。退款任务要查实际金额和单据状态，不能因为最终文本说“成功”就给分。无效样本、环境故障和系统失败分别记录，不能把运行失败悄悄删掉后抬高通过率。

4. 防泄漏需要按来源组切分

同一会话的不同轮、同一文档生成的相似问法、同一事故的多个改写，通常高度相关。应先聚成来源组，再分到开发与保留测试集，避免一份事实或答案的近重复跨集出现。检查测试内容是否进入训练、少样本示例、调参反馈或缓存。

对于 RAG，生产本来应可检索到的业务文档可以作为输入证据；但把评测答案、评分标签或测试专用解释混入检索库会造成泄漏。新业务和时效性问题可增加时间后移的保留集，记录外部工具和资料快照；实时环境评测另报，以免把环境变化误判成模型退化。

5. 处理抖动与持续更新

同一任务可重复运行，估计任务内波动；不同版本在同一批任务上配对比较，并按风险、难度分别报告。重复十次同一问题不等于十个独立业务样本，区间或显著性计算应尊重会话、用户等相关结构。

保留集要限制用于调参的反馈频率，并定期补充新来源。线上确认过的失败进入回归集，新的独立任务继续进入保留集，避免把原来的测试集逐步变成开发集。

追问

用大模型自动生成样本能直接作为评测集吗？

可以补覆盖缺口，但需要去重、核事实和人工检查可判定性。生成器容易复制同一风格或已知答案，不能用合成样本替代真实分布，也不能让同源模型的自评成为唯一真值。

样本分布合理，是否就说明覆盖足够？

还不够。平均分布可能遗漏低频高损失情形；要同时检查专项风险、跨条件组合和近期未覆盖的线上失败。

参考资料