chimera-when-two-results-contradict-suspect-the-apparatus

自分で出した2つの測定結果が、説明のつかない幅で食い違っている場合に当てはまる。データの一部しか使っていない実行の方が、大きい実行より良いスコアを出す。隣接する測定では日常的にこなしていると示されているタスクで、あるコンポーネントが 0% を記録する。ある変更が、ありえない方向に数値を動かす。

トリガーはその差の大きさであって、差が存在すること自体ではない。2つの実行がノイズの帯の範囲内で食い違うのはサンプリングの問題であり、このカードはそれについて何も言うことがない。また、自分の数値と他人の公表した数値の対比にも当てはまらない。データ、プロンプト、シード、バージョンの違いが一日中それを説明してくれるし、それを測定器の警報として扱えば、何ともないハーネスを監査する羽目になる。ここで扱うのは、矛盾の両側が自分のものであり、両方が真ではありえない場合だ。

1. まず矛盾を2行で書き留める。2つの数値と、それらを生み出した正確なコマンドとコミットだ。それが紙の上に載るまで理論化をやめること——書かれない矛盾は、ひと段落ほどのうちに「パズル」へと角が取れてしまう。
2. 推論を始める前に2つの実行を差分する。設定、コミット、コードの経路、入力ファイルのハッシュ、採点器のバージョン。組み立てられる説明よりも、読める差分を優先すること。
3. 既知の答えを測定そのものに通す。モデルのスコアを信じる前に、参照解答・正解を自分の採点器に通すこと。正しいと分かっている答えが失敗と採点されるなら、欠陥は採点器にあり、それが生み出したすべての数値は、気に入っていたものも含めて無効である。
4. 測定器が手順3を生き延びて初めて、その現象の説明に労力を費やす。
5. 測定器に欠陥があったなら、数値を解釈し直すのではなく撤回すること。壊れた採点器から出たスコアは、真値のノイズの乗った推定値ではない。真値と無関係なのだ。

矛盾が本物で、驚くべき結果こそが所見である場合もある。ハーネスを疑う反射はそれを捨ててしまうし——さらに悪いことに——都合の悪い測定結果を消したい者にとって、それはいつでも使える手でもある。だから範囲を区切ること。測定器の確認は、固定された短いリスト(実行を差分する、正解を採点器に通す、入力のハッシュを確認する)である。そのリストが問題なしで返ってきたなら、その矛盾を信じ、現象の調査に向かうこと。このカードは作業の順序を決めるものであって、答えを選ぶものではない。

2つ目のコストは再帰的だ。古いコードを確認するために書かれた新しいコードは、間違いうるものがもう1つ増えたということであり、バグのある監査スクリプトは3つ目の数値を生み出してしまった。異常事態の圧力の下で新しいハーネスを書くよりも、すでに手元にある成果物と、答えの分かっている入力を使う確認を優先すること。