評価スコアはサンプルサイズについて嘘をついている

58 件のケースからなるゴールデンパネルと、実際の検索インデックスから回答する稼働中のドキュメントアシスタントを用意し、リランカーを有効にした場合と無効にした場合を比べます。点推定値で読むと、リランカーは最上位のページが正解である回答の割合を 61.8% から 74.5% に押し上げます。進歩のように見え、状況報告ではたいてい 12.7 ポイントの改善として報告されます。

何も変えずに同じアームを 2 回実行すると、回答の正しさは 71.2%、次に 76.0% でした。ケースごとに 3 回の反復で測り直すと、観測されたケースのおよそ 9 件に 1 件が、同一の測定の間で判定を変えました。正しさでは 54 件中 6 件、最上位のページでは 57 件中 7 件です。

測定が壊れているからではありません。一部はまったく測定できなかった 58 件のケースでの差は、サンプルがそれ自体で生み出せるノイズの範囲に十分収まっているからです。何かを学べたかどうかを教えてくれるのは、点推定値ではなく区間です。

何を報告するか

3 つの数値を、この順で示します。差分、その区間、そしてその背後にあるケース数です。これより少なければ、読み手はその主張を評価できません。以下がその実行です。リランカー有効と無効を、ケースごとにペアにして、ポイント単位で示します。

どの区間も、大きくゼロをまたいでいます。点推定値はどれもリランカーが役立つと言っていますが、区間は、このパネルではそれが役立つのか害になるのか判断できないと言っています。それ自体がひとつの発見です。このパネルは小さすぎ、欠損も多すぎて、答えを出すために使われていた問いに答えを出せません。

欠損はゼロではない

58 件の呼び出しのうち 4 件はテスト対象のシステムから HTTP 500 を返し、2 件のジャッジ呼び出しは解析できる判定を返しませんでした。採点されなかったケースをゼロとして平均に含めるハーネスは、この 6 件をアシスタントの失敗として記録します。58 件中 6 件の、作り出された失敗です。Oloproof はそれらを欠損として記録し、それらが何であり得たとしても範囲に収まるよう区間を広げます。

3 行目が織り込んでいるのはそれです。ランク付けされたページ 3 件で打ち切ったとき、測定できたのは 58 件中 27 件だけで、区間は残りの 31 件を隠すのではなく、考慮に入れています。

小さなパネルはゲートを通ってしまう

同じルールは小さい側でも成り立ちます。3 件のケースによるスモーク実行のスコアは 1.000 で、95% 区間は 0.292 から 1.000 でした。点推定値を目標と比べるゲートは、これをリリースさせてしまいます。区間を読むゲートは、事実を告げます。3 件のケースでは、完璧なシステムと、10 回に 3 回しか正しくないシステムを見分けられません。

区間を狭める

ケースを増やせば区間は狭まりますし、ケースを失わないことでも狭まります。同じパネルで、システムの HTTP 500 を一時的なものと宣言してランナーに再試行させたところ、欠損ケース 22 件のうち 18 件が回復し、数分後には区間が 39% 狭まりました。ほかには何も変えていません。

区間がしきい値を越えた差分は、その大きさにかかわらず判断を支え、ゲートが従うべきなのはそれです。それまでは、差分、その区間、背後のケースを報告し、答えはまだ出ていないと伝えましょう。