项目测试或评测使用了多少数据，数据规模如何确定？

核心回答

这个问题先报实际有效的独立测试任务数、覆盖范围和执行次数，再解释规模为什么适合本次验证。例如一条多轮任务反复运行若干次，是一个任务的多次试验，不能都算成新的业务问题；知识库文档数、训练数据量也不是测试样本数。

规模由目标决定：早期用小而有代表性的集合检查链路和评分规则；比较方案时固定数据、环境和评分口径；要估计实际成功率或验证低频风险，就需要考虑样本代表性、允许误差和置信区间，并单列高风险场景。没有适用于所有项目的“够用条数”，增加大量近义改写也不等于增加同样多的独立证据。

把“多少数据”说成可核对的项目事实

可以按下面的顺序整理自己的实际记录，再组织回答：

• 统计单位：一条问题、一段多轮会话，还是一次完整工具任务；一次任务怎样判成功。
• 来源和去重：来自真实请求、历史故障、业务人员设计还是合成数据；是否排除了重复问题及训练泄漏。
• 覆盖与数量：按任务类型、难度、权限、数据新旧或失败类型分层，分别有多少独立任务。
• 执行与有效结果：独立任务数、每题重复次数、完成次数；超时、工具故障和评分失败分别如何统计。
• 用途与局限：用于找错、比较版本，还是估计某个人群和时间范围内的实际表现。

如果还在早期，直接说明“当前这批数据用于验证链路与定位典型错误，尚不足以估计线上成功率”，随后说明扩充计划依据什么风险和缺口。比单报一个大数字更能回答题意。

覆盖面比重复堆数量更重要

以知识库助手为例，分层可以包括直接事实查询、需综合多份材料的问题、版本冲突、无答案问题和越权请求。工具型 Agent 还要覆盖工具选择、参数构造、依赖调用、业务拒绝和外部故障。不同任务的成功标准不同，不能拿一套字符串匹配覆盖所有场景。

建议把两类集合分开：

集合	选择方式与作用	结论边界
业务分布样本	从定义好的目标请求范围抽样，用于估计总体表现	要说明时间范围、分层权重和抽样偏差
风险与回归集合	刻意收集越权、重复扣款、无答案等难例，用于防止严重错误和历史问题重现	其失败占比通常不代表自然流量中的失败率

某层样本太少，就报告该层结果不稳定，而不是用整体均分掩盖它。若刻意过采样稀有场景，汇总总体指标时应按目标业务分布加权，或者只分别报告各层结果。

固定读取数据集的前若干条，适合检查脚本能否运行；如果文件按类别或难度排序，这种前缀取样不能自动代表整个数据集。

样本数为什么与结论精度有关

假设每次测试相互独立、代表同一个目标分布，而且失败判定稳定。即使连续 $n$ 次没有观察到失败，也不能证明失败概率为零。根据二项分布，出现零次失败的概率为 $(1-p)^n$。令它等于 $0.05$，可得到零失败时失败概率的单侧 95% 置信上界：

$$ p_{\text{upper}}=1-0.05^{1/n} $$

例如 100 个独立样本零失败，上界约为 2.95%。若要在同样的零失败条件下把这个上界降到 1% 以下，至少需要 299 个独立样本。这是解释样本量与风险结论关系的计算例子，不是建议每个项目都测 299 条。

真实项目还存在请求相关、长尾分布、评分误差和环境变化；这些条件不满足时，不能机械套公式。一般成功率估计可以报告合适的比例置信区间；比较两个版本的小幅提升，还应考虑同题配对、结果波动、希望检出的差异和所需统计把握度，不能只看均值高了一点。

多次运行与版本比较怎样记录

Agent 有随机性，同一道任务可以多跑几次，观察结果是否稳定；但“多任务”与“同题多次运行”应分开报告。同一任务的多个改写和多轮输入也可能高度相关，不能默认是独立抽样。

比较模型、提示词或检索方案时，尽量使用同一批任务、同一环境和判分规则。开发时反复查看和调优的集合，与最终保留测试集分开；提示示例里不放测试答案。修改评分规则后，也要重审历史结果是否还能比较。

应用失败应进入任务结果；评分器自己报错、数据格式不合格等则单列，并说明是否影响了有效样本分母。不能悄悄丢弃失败执行后，只对剩下的成功完成样本报高分。

是否继续扩数据，可以看新增样本还能发现哪些新错误、关键分层是否欠缺、指标区间是否足以支持决策。扩大数量仍不稳定时，还应检查任务定义和评分一致性，而不只是继续加样本。

对应教程

参考资料