评测规模要与结论的推广范围匹配

所以设计实验前先回答：这份结论要推广到哪里？ 再决定用构造数据还是真实链路。

「几道精心设计的陷阱题」能检查基本功能，但不足以体现海量、多题型下的真实难点。

一、两种「海量」要分开

用人工构造的检索结果，只能研究 Agent 如何使用依据； 要证明真实题库的检索效果，必须走真实搜题服务。两者不能互相替代。

二、规模化评测的四步

1. 用真实链路建立基线，先找问题 —— 真实题经实际搜题服务与 Agent，保留检索结果、工具调用、最终答案与解析。不预设「某个错误一定是最大问题」，让数据说。 起步用探索集（如 100～200 道），按题型、文字/图片输入分层抽样，避免只挑容易拿到的题。
2. 把「答错」拆成可行动的环节 —— 题目理解 / 工具调用 / 检索结果 / 依据使用 / 推理解答。最终答案对错用于衡量效果，Trace 用于定位原因；证据不足就标为待核查，不强行归因。
3. 针对高频错误设计策略，讨论取舍 —— 比较的不只是「加不加一句校验」，而是：全量核验 vs 按题型触发，各减少多少错误、增加多少耗时？检索与独立求解冲突时，何时继续答、何时澄清或拒答？正确性、覆盖率、成本与等待时间之间怎么取舍，才是产品策略价值所在。
4. 用未见题检验能否推广 —— 分开发集/验证集，同源题、近重复题、同一道题的变式放在同一侧；开发集调方案，冻结后再跑验证集。

三、报告口径要防「刷分」

只报整体正确率会掩盖问题，还要同时报：

• 各题型正确率；
• 答案正确但解析错误的比例；
• 回答覆盖率 —— 否则可以靠多拒答把准确率「做高」；
• 原来答对、改后答错的数量（回退）；
• 单题耗时与调用成本。

对很小的差异，需要更多样本或重复运行，不能凭几道题的提升下结论。

四、样本覆盖要能被解释

海量场景不要求跑遍所有题，但要求说清：样本覆盖了什么、遗漏了什么、结论能推广到哪里。 没有真实使用分布时，就明确声明这是「覆盖性测试集」，不称作线上代表性样本。

相关

• 评测要先隔离被测层 —— 隔离是为了单独评「拿到结果之后怎么用」；本页讲它的边界与升级路径（要评规模效果就得回真实链路）
• 判据要用真值而非代理 —— 用构造样本代替真实分布，是在拿代理量换归因能力，必须显式声明适用范围
• 口径先于数值 —— 覆盖率、回退数、解析正确率都是口径的一部分，只报一个数就会失真
• 测试策略 —— 本页是「集成/评测」在规模维度上的延伸
• 通过只证明它实际驱动的路径 —— 构造实验只驱动了受控那条路，不能宣称真实检索被优化