你的评估分数在样本量上说了谎

取一个包含 58 个用例的黄金测试集，以及一个基于真实搜索索引作答的在线文档助手，比较其重排序器开启和关闭两种情况。只看点估计，重排序器把排名第一的页面恰为正确页面的答案占比从 61.8% 提升到 74.5%。这看起来像是进展，在状态更新里通常会被报告为 12.7 个点的提升。

在什么都没改的情况下把同一组运行两次，答案正确率先是 71.2%，然后是 76.0%。每个用例做三次重复测量后再测，大约每九个观测用例中就有一个在完全相同的测量之间改变了裁决：正确性上是 54 个中的 6 个，排名第一的页面上是 57 个中的 7 个。

原因并不是测量坏了，而是在 58 个用例（其中一些根本无法测量）上的差异，完全落在样本自身就能产生的噪声之内。告诉你是否学到了东西的，是区间，而不是点估计。

应该报告什么

三个数字，按这个顺序：差值、它的区间，以及其背后的用例数。少于这些，读者就无法评判这个结论。以下就是那次运行，重排序器开启对比关闭，逐个用例配对，单位为点：

每个区间都跨过了零，而且跨得很宽。点估计都说重排序器有帮助；区间却说这个测试集无法判断它是有益还是有害。这本身就是一个发现：这个测试集太小、缺失太多，无法回答它被用来回答的问题。

缺失不等于零

58 次调用中有四次从被测系统返回了 HTTP 500，另有两次评判调用没有返回可解析的裁决。把未评分用例按零计入平均的测试框架，会把这六个记为助手失败：在 58 个中凭空制造出六个失败。Oloproof 把它们记为缺失，并加宽区间，以覆盖它们可能的任何取值。

这正是第三行所计入的代价。在截取前三个排名页面时，58 个用例中只有 27 个可以测量，而区间把另外 31 个计入其中，而不是把它们藏起来。

小测试集也能通过门控

同样的规则在小规模一端同样成立。一次三个用例的冒烟运行得分 1.000，95% 区间为 0.292 至 1.000。拿点估计与目标比较的门控会放行它。读取区间的门控则会说出事实：三个用例无法区分一个完美的系统和一个十次只对三次的系统。

收窄区间

更多的用例会收窄区间，少丢失一些用例也会。在同一个测试集上，把系统的 HTTP 500 声明为暂时性错误，让运行器重试，几分钟后就找回了 22 个缺失用例中的 18 个，并使区间收窄了 39%，其他一切都没有改变。

一个区间越过阈值的差值，无论大小，都能支撑决策，门控应当依据的正是它。在此之前，请报告差值、它的区间以及背后的用例，并说明答案尚未揭晓。