悪いベンチマークと評価：Senior SWE-Bench、ナプキン計算、そして冬用タイヤ

この記事では、3種類の異なるベンチマークについて見ていきます。1つは性能の「概算計算」のためのベースライン数値のセット、1つはAIモデルの評価のセット、そしてもう1つは車のタイヤに関するものです。物事に対する私の直感を養うために、説明を見る前にそれらについて考えるのが好きなので、もしあなたの考えを説明の前に考えたい場合は、ベンチマーク情報が最初に提示され、その後で説明が続きます。

29. 友人がコンピュータ性能の面接対策のために性能の桁数をレビューしていて、https://github.com/sirupsen/napkin-math（5.4kスター）がトップヒットであることを見つけました。READMEの表には以下が含まれています：

Napkin Math 性能推定

このベンチマークの問題点は何でしょうか？

30. DeepSWEとSenior SWE-Benchを、お気に入りのモデルが他のモデルより優れている、あるいは一般的に良好なベンチマークであると「証明」するために参照するのをよく目にします。

［画像: DeepSWEリーダーボード、様々なモデルと作業レベルに対するタスクあたりの平均コストとスコアのプロット］ ［画像: Claude Fable 5、Claude Opus 4.8、GPT-5.6 Solを上位3モデルとして示すSenior SWE-Benchリーダーボード］

これらのベンチマークの問題点は何でしょうか？

31. 冬用タイヤは寒い時期にはオールシーズンタイヤよりも優れているとよく言われます。例えば、「all season tires during winter cold」（引用符なし）でGoogle検索すると、Google AIの要約には次のように書かれています。

オールシーズンタイヤは、冬の気温が氷点下になるとトラクションを失い、硬くなります。そのゴムコンパウンドは暖かい気候向けに設計されており、7℃（45°F）以下では硬くなり、ブレーキ距離が著しく長くなり、グリップが低下します...オールシーズンタイヤのゴムは、氷点下の温度で柔軟性を維持できないため、雪や氷の上では硬いプラスチックのように機能します。

トレーニングデータには多くのインターネットコメントが含まれているため、これは妥当なコメントです。なぜなら、どのタイヤを使うべきかという議論で、このコメントのバリエーションを頻繁に見かけるからです。

このベンチマークの問題点は何でしょうか？

29. Napkin math（概算計算）の数値

ランダムメモリアクセスレイテンシ

私の友人（ジェイミー）がすぐに奇妙だと感じたのは、ランダムメモリ読み書きが20nsとリストされていることでした。なぜなら、ランダムメモリ読み書きは実際のDRAM読み込み（キャッシュヒットとは対照的に）を意味すると考えられるのに、彼はそれが概算見積もりとして100ns程度であるべきだと感じたからです。

私たちがこれについて話していると、彼はREADMEが実際にはレイテンシではないものに「レイテンシ」という言葉を使っていると指摘しました。そして、彼はランダムメモリ読み込みレイテンシのコードを調べたとき、以下のものを見つけました（もう一つ演習したい場合は、説明を読む前に以下のコードの何が問題か考えてみてください）：

  while test.i < test.vec.len() {
      let random_index = test.order[test.i];
      black_box(test.vec[random_index]);
      test.i += 1;
  }

ジェイミーは、ループの反復間にデータ依存性がないため、メモリ読み込みはここで並列に行われると指摘しました。 alleged（主張されている）レイテンシ数はアクセスごとの平均時間を求めることで決定されるため、CPUは複数のロードを同時に実行できるため、これは不正確です。この方法でレイテンシを測定したい場合は、重複アクセスを防ぐために、ロード間に依存関係を導入する必要があります（このシリーズのパート4でカバーされた演習19で関連トピックを議論しました）。

ランダムSSD読み込み

私はジェイミーのコメントすべてに同意しますが、レイテンシという言葉の使用を自分で特に問題視しませんでした。なぜなら、場合によってはレイテンシの略語であり、他の場合はレイテンシに似たもの（逆スループットなど）であるため、テーブルがよりシンプルになるからです。

メモリレイテンシの数値以外で最初に気になったのは、他のいくつかの数値でした。例えば、ランダムSSD読み込みは100μs / 70MB/sとリストされています。もっと速い（そしてもっと遅い）SSDも入手可能です。例えば、高速な（ただし、Optaneのような非エキゾチックなものではない）デバイスの場合、40μs未満のレイテンシが見られるかもしれません。例えば、Kioxia CD9P-Rはここで約30μsと測定されました。些細なスクリプトを除けば、ディスクパフォーマンスを気にするような作業はしてこなかったので、どのような数値を念頭に置くべきかという直感はありません1が、ランダム読み込みレイテンシとスループットに単一の数値を設定することが、DRAMアクセスの場合よりも有用性が低いのではないかとも疑問に思います。ディスクベンチマークを見るたびに、読み込みサイズ、キュー深度、ジョブ数（例えば、Kioxia CD9P-Rに関する前のリンクを参照）に基づいて結果に大きなばらつきがあるように見えます。もちろん、DRAMのレイテンシと帯域幅に影響を与える同様の要因がありますが、メモリアクセスについて考える際には、1つか2つの数値を知ることが役立つ領域にいることが多いようです。ディスクパフォーマンスについては何も知らないので、Postgresのディスクパフォーマンスに取り組んだことがあるPeter Geogheganに尋ねました。彼は同意し、ディスクパフォーマンスの複雑さについて追加のコメントを以下に書いてくれました。

このSSDランダム読み込み数値のコードを見ると、ジェイミーがランダムメモリ読み込みコードをオフセットで生成する際に感じたのと同じように、私には違和感があります。

for i in 0..(buffer.len() / page_size) {
    pages.push((i * page_size + 1) as u64);
}

そして、8KiBの読み込みを行います（オフセットはランダム読み込みを作成するためにシャッフルされます）。いくつか不適切な点があります：

1. +1により、すべての読み込みがアラインメントされなくなります。4KiBのページサイズの場合、1回の読み込みで3ページにまたがります。
2. 異なるオフセットが同じページをオーバーラップする可能性があり、ページキャッシュからの意図しない読み込みが発生する可能性があります。
3. ページサイズによっては、読み込みがファイルの末尾を超えてしまい、パニックを引き起こす可能性があります。

buffer.len() / page_sizeという構成は、アクセスを範囲内に保つことを意図しているようですが、これはアクセス長とは無関係です。もし正確なオフセットを考えずに怠惰になりたいなら、4GiBのような巨大なアクセス長（バッファサイズは8GiB）を考えてみてください。それは確実にオーバーフローするでしょう。より正確に言えば、オーバーフローケースは4KiBページと8KiBアクセス長のようなものになるでしょうが、考え方は同じです。

最後のオフセットはSIZE - 4096 + 1になります。これにより4095バイトにアクセスできますが、8192バイトを読み込もうとします。ベンチマークは5秒しか実行されないため、EOFを読み越して失敗するかどうかは、実行ごとにランダムに失敗するかどうかに関わらず、バグは依然として存在します。

シーケンシャルSSD読み込み

コードを見ただけで、多くのことが正しくないように感じます。例えば、シーケンシャル8KiB SSD読み込み（1μsのレイテンシと8GiB/sのスループットを持つとされる）を生成するために使用されているコードを考えてみてください。前述したように、ディスクパフォーマンスが重要となる問題に取り組んだことはないので、このような数値が妥当かどうかについての直感はありませんが、コードは私には奇妙に思えます。コードは1GiBのファイルを読み込み、フラッシュしてから繰り返し読み込むため、キャッシュされていない読み込みが1回あり、その後にキャッシュされた読み込みがあります。ここではキャッシュされていない読み込みを測定することを意図しているようですが、キャッシュされた読み込みを測定することを意図している場合でも、コードはそれを実行していません（これは、fsyncされた読み込みで3GiB/sのような他の数値にも問題があるようです）。キャッシュされていない読み込みの後にキャッシュされた読み込みが続くことは現実的だと主張することもできますが、集計された数値（キャッシュされていない読み込み1回とキャッシュされた読み込みN回）を、正確に同じワークロードを持たない人がどのように使用すべきかは明確ではありません。Nが明白な方法で示されていないため、同じワークロードを持っているかどうかもわかりません。

ここでは数値がどうあるべきか全く分からないので、いくつかの数値を調べてみましょう。測定はc4-standard-48-lssdで行われたとされています。そのインスタンスに関するGoogleのドキュメントでは、8つのアタッチされたディスクの最大スループットは5000MiB/sであると主張しています（Googleの表によると、これはアタッチされたディスクの数に応じてスケーリングされ、ディスクあたり625MiB/sです）。ディスクベンチマークについて私が知っていることはごくわずかですが、ピークスループットの数値は通常、より大きな読み込みを使用した場合に行われるように思われるため、8GiB/sは過剰であり、コードから何かがおかしいという感覚は正しいようです。そして、他の数値を見ると、特定の読み込みサイズに対する少数の単一の数値が、一般的なディスクパフォーマンスを代表していないという、より広範なポイントがあるようです。

代表性

しかし、このような「概算計算」の背後にある考え方は、一般的に特定のクラウドインスタンスがどのようにパフォーマンスを発揮するかを正確に知ることではなく、様々な方法でパフォーマンスを推定するために使用できる基本的な数値を得ることです。Kioxia CD9Pベンチマークを振り返ると、様々なパラメータを持つ、それよりも高い帯域幅を持つ読み込みベンチマークがたくさんあります（そして、様々なパラメータを持つ、それよりも低い帯域幅のものもたくさんあります）。レイテンシに関しては、レイテンシを最小化する設定（ベンチマーク内の他のディスクを含む）でも、シーケンシャル読み込みのレイテンシは高くなります。これは、sirupsenベンチマークが意図せずキャッシュから読み込んでいるもう一つの兆候ですが、たとえ数値が正しかったとしても、それらをどう使うかは不明です。

sirupsenコードには、キャッシュとプリフェッチを防ぐための試みがあるようです。Linuxでテストが実行されていることを検出すると、アドバイザリPOSIX_FADV_RANDOMを設定し、テスト開始前にアドバイザリPOSIX_FADV_DONTNEEDを設定しますが、これらはOSレベルでこのベンチマークでのキャッシュを防ぐことはできませんし、低レベルのキャッシュ（SSD内部など）を防ぐことも期待すべきではありません。Macでは、ベンチマークはCommand::new("sudo").arg("purge").output().expect("failed to flush page cache")を事前に呼び出しますが、POSIX_FADV_RANDOMに相当するものはなく、他のOS（BSDやWindowsなど）では何も行われていないようです。

コードの他の部分にも問題がありますが、すべての特定の問題や提示された値の詳細に入るのではなく、さまざまなレジームで数値の範囲を把握したいという考えに戻ると、それが当てはまる場所がかなりあります。別の例を挙げると、READMEは「解凍」を1GiB/s、「圧縮」を500MiB/sと引用しています。もちろん、どのような概算計算も正確ではありませんが、さまざまなzstd圧縮オプションを試すだけで、圧縮速度に2桁以上の差があり、高速圧縮に特化したアルゴリズムもあり、さらに大きな範囲を提供します（そしてもちろん、低速で高密度な圧縮を得るためにさらに労力を費やすこともできます）。

ディスクの例に戻ると、ディスクの数値は8台のディスクを持つVM構成から来ていることに注意しました。数値は不正確に見えますが、もし数値が正確だったとしても、GCPの特定の8ディスク構成の読み込み帯域幅の数値は、VMのシングルディスクバージョンを使用した場合には異なる数値になるでしょう。ページキャッシュから読み込んでいない場合、読み込みベンチマークでは約1/8の読み込み帯域幅が期待されます。なぜ特定の8ディスク構成のGCPでの読み込み帯域幅の数値を概算計算の数値として記憶しておくことが特に有用なのかは不明です。

何を学ぶのが有益か？

全体として、これらの種類の数値をいくつか知っておくことは有用だと感じますが、必ずしもテーブルを見て数値を確認したいとは思いません（面接で聞かれる可能性が高いと確信している場合、面接直後に忘れることを期待して、面接対策としてなら別ですが）。一般的に、これらの数値を把握することが意味をなすようなことをしている場合、それらは使用するうちに自然と身につくものです。例えば、20年前に光学・フォトニクス関連の仕事をしたので、標準単一モードファイバーの分散が17 ps / nm * kmであることを今でも覚えています。これは、裏紙計算で十分な頻度で登場するため、十分に使用していればいつか覚えることになります。同様に、さまざまな2のべき乗（例：2^8 = 256、2^16 = 65536など）も、暗記しようとはしませんでしたが、十分なコーディングでこれらの数値に触れると、役立つ数値を覚えていくことになります。

リンクされているnapkin mathリポジトリは、「記憶のために丸められた数値」と述べており、これらを記憶することが理にかなっていることを示唆しています。上記に加えて、これらの数値の多くは導出可能であり、私の意見では、これらを仕事で使用している場合、概数でも記憶しておいても、その導出を理解することが理にかなっています。例えば、Sandy Bridgeプロセッサのシングルコアメモリ帯域幅の数値をパート4で基本的なパラメータから導出しました。コードがどれくらいの速さで実行されるかを知りたいだけであれば、すべてをゼロから再導出する必要は一般的にありません。しかし、何かを変更することの影響を理解しようとしている場合、どのようなメカニズムが関与しており、それらがどのように相互作用するかを知ることが役立ちます。これは、少数の数値を記憶しているだけでは得られないものです。

この質問の文脈に戻ると、面接準備をしていた友人が最後に懸念していたのは、このリポジトリが非常に人気があるため、面接官がリストされている数値のほとんどが間違っていることを知らずに使用する可能性があるということでした。

ボーナス情報：メモリレイテンシの変遷

ちなみに、実際のシステムでメモリレイテンシがどのように観測されているか気になったので、instlatx64サイトのデータをプロットしてみました。以下のようになります。

ここには2つのグラフがあります。なぜなら、比較できない2つの異なる方法論が使用されたからです。元の方法論は、メモリレイテンシを見つけるために1024バイトのストライドを持つアクセスを使用しました。これは、古いプロセッサでは十分なデータセットでのアクセスにはうまく機能しました。新しいプロセッサは、これを純粋なDRAMアクセスにするのを妨げるメカニズムを追加したため、新しい方法論はメモリレイテンシを見つけるためにランダムアクセスを使用します（古い方法論を使用した後のいくつかの数値は、ランダムメモリアクセス時間として考えると実際には有効ではありません）。レイテンシはinstlatx64サイトから取得し、CPUのリリース年はGPT-5.6 Solをコードックスで検証せずに尋ねて見つけたため、いくつかの年は間違っている可能性があります。

グラフを目で見るだけでも、メモリレイテンシはしばらくの間劇的に改善しましたが、この改善は最終的に停滞し、ポストの範囲外の理由で時間の経過とともにレイテンシが高くなっていることがわかります。

690ns？

90年代からの非常に高い外れ値の結果もいくつか見られます。これらの結果をあまり時間をかけて調べることなく、結果が間違っているとは明らかではありません。Intel側では、大きな外れ値は83 MHzのIntel Pentium Overdriveです。他の古いIntelの結果はすべて非Overdrive Pentiumです。

Overdrive Pentiumは、前の世代のCPUのマザーボードに装着できるチップでした。テストは、ALi M1489/M1487チップセットを33 MHzのバス速度に設定したGigabyte GA-5486ALマザーボードで実行されたようです。ALi M1489/M1487データシートによると、DRAM読み込みタイミングには4つの可能な設定があります。「ノーマル」設定の場合、リードページミスはCP+8で、4-4-4のリードタイミングです。私は486バスタイミングについては、ディスクパフォーマンスよりもさらに詳しくないので、LLMに尋ねたところ、これは正しいと答え、ここで21、22、または23サイクルをメモリアクセスに期待すべきだと述べました。これは、LLMにこれらの数値の意味を尋ねたところ、最初の単語に続き、各追加単語に対するものであり、そのサイクル数はキャッシュライン全体を埋めるためのものであるため、あまり正しくないように感じます。単語アクセスに対する実際のロード・トゥ・ユース・レイテンシは、最初の部分、つまり11バスサイクルであるべきですが、キャッシュライン全体の時間が必要な場合、その数値はキャッシュライン全体を埋めるのに妥当な範囲にあるようです。

外れ値のAMD K5 PR166の結果を見ると、少し奇妙な点がありますが、現代のコンピュータパフォーマンスに関する質問からはかなり外れた領域に入っているので、これは後でシリーズの別の質問にしましょう。

30. DeepSWE / Senior SWE-Bench

一般的な妥当性

これらのベンチマークの方法論を見る前に、結果だけを見ると、DeepSWEもSenior SWE-Benchも、コーディングエージェントの全体的なパフォーマンスの概要としては妥当性に欠けるように感じます。DeepSWEのホームページを表面上読むと、OpenAIの最新世代モデル（GPT-5.5）がAnthropicの現行世代モデル（Fable 5）と同等であり、Senior SWE-Benchを表面上読むと、Anthropicの最新世代モデル（Opus 4.8）がOpenAIの現行世代モデル（GPT 5.6）よりも優れているとなっています。一般的に、表面上の読み取りがほとんどの人が受け取るものであり、私はこれらが使用されるのを見るのはこの通りです（例えば、仕事のスラックで、人々が私に直接送ってくる場合など）。

方法論の問題点

どのように「ソーセージが作られるか」を見ると、公開されているベンチマークのほとんどは、コーディングエージェントの全体的な優秀さを把握するために信頼できるものとしては合理的ではありません。方法論の観点から、ベンチマークは一般化可能な結果を得るために測定する必要があるものに関して、実際には意味をなしません。ディスクパフォーマンスについて何も知らないのと同じように、AIについても何も知りません。そこで、Anthropicでしばらく評価チームを率いていた人物（Aaron Levin）に、その推論と結論をレビューしてもらうよう依頼したところ、彼は一般的な考え方と推論に同意しました。ディスクパフォーマンスの専門家との相談と同様に、このポイントは専門家が同意するから同意すべきだということではありません。それは、これらのケースでは、専門知識を全く必要とせず、専門家と同じ結論に達することができるということです。単に、ベンチマークや実験デザインの問題を評価する際に使用するのと同じ種類の一般的な推論を適用するだけです。

サマリースコアの代表性

前回の投稿で、単一のサマリースコアはほとんど何でも言えるというハイレベルなアイデアについて議論しました。なぜなら、サブベンチマークの結果を見ると、モデルXがモデルYより優れているものがたくさんあり、ベンチマークAがベンチマークBより優れていると一般的に言うための、タスクの分布をサンプリングする特に良い方法がないからです。それはより代表的だからです。

これらのベンチマークの詳細を見ると、DeepSWEには113のタスクがあります（少なくともcodexはそう言いました）。各タスクは4回実行され、一般的に合格/不合格のスコアが付与されます（モデルは各タスクで0%、25%、50%、75%、または100%のスコアを獲得するようです）。グラフを見ると、GPT-5.5はOpus 4.8よりもはるかに優れていることがわかります。GPT-5.5とOpus 4.8の違いは、Opus 4.8とGemini-3.5 Flashの違いと同じくらい大きいです。前述したように、これらのモデルを使用したことがある場合、これは私や信頼できる判断を持つ他の誰かの経験全体とは一致しません（もちろん、特定のタスクやサブベンチマークでこれが当てはまる場合もあります）。

これがなぜそうなるのかを見ると、GPT-5.5 xhighはOpus 4.8 xhighよりもわずかに安価で、はるかに優れているとされています（スコアは67%対54%）。113のタスクのうち、モデルは34のタスクで引き分け、GPT-5.5 xhighが57のタスクで勝ち、Opus 4.8が22のタスクで勝ちました。私や他のプログラマーにとって、これらのタスクが私や他のプログラマーが行うタスクを代表している場合、これは意味のあるものになるでしょう。113のタスク（あるいは79の異なるタスクだけでも）は、この投稿で詳細に調べるには多すぎますが、タスク名を見ると、私が行うタスクに関連するものはほとんど、あるいは全くありません。そして、言語を見ると、結果が異なるタスクのうち、4つのタスクは私がコーディングエージェントを頻繁に使用する言語（Rust）であり、残りのタスクはコーディングエージェントを使用しない言語、あるいはどのモデルでも問題ない些細な問題に使用する言語です2。

結果が異なる4つのRustタスクは以下の通りです。

Boaでの階層的評価キャンセル（https://deepswe.datacurve.ai/data/v1.1/tasks/boa-hierarchical-evaluation-cancellation）、fdでの決定論的多キーソート（https://deepswe.datacurve.ai/data/v1.1/tasks/fd-deterministic-multi-key-sorting）、oxvgでのスタイルシートセレクタ構造の維持（https://deepswe.datacurve.ai/data/v1.1/tasks/oxvg-structural-selector-preservation）、wasmiでのコアダンプ生成のトラップ（https://deepswe.datacurve.ai/data/v1.1/tasks/wasmi-trap-coredumps）。これらのどれも、私がコーディングエージェントを使用するタスクとはあまり関連性がありません。そのため、私にとっては無価値です。

これらのうち1つは、過去1年間に私が経験したこととわずかに似ていますが、他の3つはそうではありません。個々のベンチマークからわかるように、異なるベンチマーク間には結果に大きなばらつきがあります（例えば、前回の投稿のOptimization 1ベンチマークでは、DeepSWEに似たモデルランキングが得られますが、GameAIではSenior SWE-Benchに似たランキングが得られます。しかし、その投稿でも観察したように、私たちが気にするタスクに名目上似ているように見えるベンチマークが、実際のタスクとは逆の結果をもたらすことがあります。これは、ばらつきが非常に大きいためです）。113のタスクのうち1つだけが、私が経験したタスクに少し似ているということは、DeepSWEベンチマークスコアは私個人にとっては無意味であることを意味します。

Senior SWE-Bench

もう一つのベンチマークに移ると、Senior SWE-Benchは上記のすべての問題を抱えており、さらに結果をより誤解を招く形で提示し、結果の主観的な採点という追加の問題も抱えています。ここでは非常に長いポイントバイポイントの解体をしませんが、1つの問題を見てみましょう。「tasteful solve」（洗練された解決策）と見なされるためには、ルーブリックで特定のスコアより高いスコアを獲得し、参照結果の2倍未満の長さであることなど、複数の基準を満たす必要があります。

任意かつ主観的な採点関数

さらに深く見なくても、これは古典的なhttps://danluu.com/discontinuities/の状況であることがわかります。ベンチマークには連続的なスコアがありますが、厳密なカットオフを要求することで閾値効果が導入されます。私の経験では、このようなことはしばしば物事を単純化するために行われますが、根本的な基準が重要だと信じている場合、一般的に、Xというスコアは合格、X-epsilonというスコアは不合格と言うのは避けたいものです。代わりに、スコアは非連続的な方法で集計されるべきです。このための式を書こうとすると、重みが任意であり、スコアが無意味であることが明らかになるため、このことを避けるためのためらいがあることが多いと思います。参照がR LOCである場合、1 LOCの解決策に対して最大Nの追加スコアを与えることは望ましくないことを知っているので、そこで値を2にキャップするような (2R)/(R+N)のような関数が必要になります。これは大きな関数を十分に罰しないかもしれないので、(2R^2)/(R^2+N^2)に切り替えるべきかもしれません。これを1+tanh(ln(R/N))のように書くと、その動作をより簡単に確認でき、必要に応じてそのように置き換えることができます。その後、これを他のスコアと組み合わせる必要があり、少なくともM-1のM個の式を追加して、相対的な重み付けを行う必要があります。

これは明らかに任意で、正当化が難しい式になるでしょう。しかし、実際に使用されている、これらの不連続性を持つ式は、さらに任意で、より悪い特性を持ち、さらに正当化を難しくしています！単に、それを書いている人が式として考える必要がないため、それがどれほど任意であるかについて考えるのを避けることができるだけです。

閾値効果

Senior SWE-Benchで定義されているLOC測定値に具体的に注目すると、もちろん閾値効果が見られます。例えば、https://senior-swe-bench.snorkel.ai/tasks/paperless-ngx-perf-workflow-queriesでは、GLM-5.2は参照の61 LOCに対して121 LOCで「tasteful」とスコアされました。もしLOCが1つ多かったら122 LOCになり、倍になるため、GLM-5.2は合格ではなく不合格になります。また、リンクから、ベンチマークは条件ごとに1回実行されたことがわかります。LLMを使用したことがある人なら誰でも知っているように、そして前回の投稿で見たように、実行間には膨大なばらつきがあります（多くの場合、異なるモデルや作業レベル間のばらつきよりも実行間のばらつきの方が大きいことが、前回の投稿で観察されました）。このばらつきがある単一の実行を、ある種の合理的な連続スコアで採点することは、それ自体あまり意味がありません。このようなノイズの多いメトリックから閾値効果で情報が削除されると、結果はさらに無意味になります。

これは、LOCスコアに関してそれほど問題のないベンチマークでさえありません。plausible-fix-top-pages-comparisonはさらに悪いです。なぜなら、参照ソリューションが1 LOC（追加と削除がそれぞれ1 LOCとしてカウントされるため、これは2 LOCとしてスコアされます）だからです。これにより、tastefulな解決策の最大サイズは3 LOCになります。追加と削除の両方が発生した場合、これは1 LOC削除と2 LOC追加、あるいはその逆である必要があります。

コード品質

実際の結果を見ると、それらは意味をなしません。このタスクでは、Opus 4.8が「tasteful」とスコアされ、Opus 4.7とFable 5はそうでないことがわかります。実際の差分を見て、参照ソリューションと比較すると、以下のようになります（注：LOC基準の変更点としては、実際のコードへの変更のみがカウントされ、テストLOC、コメントなどはカウントされません）。

参照

  --- a/lib/plausible_web/controllers/api/stats_controller.ex
  +++ b/lib/plausible_web/controllers/api/stats_controller.ex
  @@ -723,7 +723,7 @@ defmodule PlausibleWeb.Api.StatsController do
       else
         json(conn, %{
           results: pages,
  -        meta: Map.merge(meta, Stats.Breakdown.formatted_date_ranges(query)),
  +        meta: Map.new(meta.values) |> Map.merge(Stats.Breakdown.formatted_date_ranges(query)),
           skip_imported_reason: meta[:imports_skip_reason]
         })
       end

Opus 4.8 (合格)

  --- CHANGELOG.md
  +++ CHANGELOG.md
  +- Fixed blank comparison dates in row tooltips on the Top Pages report
                                                   
  --- lib/plausible_web/controllers/api/stats_controller.ex
  +++ lib/plausible_web/controllers/api/stats_controller.ex
  -        meta: Map.merge(meta, Stats.Breakdown.formatted_date_ranges(query)),
  +        meta: Map.merge(Map.new(meta), Stats.Breakdown.formatted_date_ranges(query)),
                                                   
  --- test/plausible_web/controllers/api/stats_controller/pages_test.exs
  +++ test/plausible_web/controllers/api/stats_controller/pages_test.exs
  +      assert json_response(conn, 200)("meta") == %{
  +               "date_range_label" => "2 Jan 2021",
  +               "comparison_date_range_label" => "1 Jan 2021"
  +             }

Opus 4.7 (不合格)

  --- lib/plausible_web/controllers/api/stats_controller.ex
  +++ lib/plausible_web/controllers/api/stats_controller.ex
  -        meta: Map.merge(meta, Stats.Breakdown.formatted_date_ranges(query)),
  +        meta:
  +          meta.values
  +          |> Map.new()
  +          |> Map.merge(Stats.Breakdown.formatted_date_ranges(query)),
                                                                                                                                                                                                           
  --- test/plausible_web/controllers/api/stats_controller/pages_test.exs
  +++ test/plausible_web/controllers/api/stats_controller/pages_test.exs
  +      assert json_response(conn, 200)("meta")["date_range_label"] == "2 Jan 2021"
  +      assert json_response(conn, 200)("meta")["comparison_date_range_label"] == "1 Jan 2021"

Fable 5 (不合格)

  --- lib/plausible/stats/breakdown.ex
  +++ lib/plausible/stats/breakdown.ex
       %{ 
         results: build_breakdown_result(results, query_with_metrics, metrics),
  -      meta: meta
  +      # `meta` is a `Jason.OrderedObject` - convert it to a plain map so that
  +      # callers can safely `Map.merge/2` extra fields into it. Merging into the
  +      # struct would add keys outside of its `values` field, which the JSON
  +      # encoder for `Jason.OrderedObject` silently ignores.
  +      meta: Map.new(meta.values)
       }

  --- lib/plausible_web/controllers/api/external_stats_controller.ex
  +++ lib/plausible_web/controllers/api/external_stats_controller.ex
  -  defp maybe_add_warning(payload, %Jason.OrderedObject{} = meta) do
  +  defp maybe_add_warning(payload, meta) do

  --- test/plausible_web/controllers/api/stats_controller/pages_test.exs
  +++ test/plausible_web/controllers/api/stats_controller/pages_test.exs
  +      assert json_response(conn, 200)("meta") == %{
  +               "date_range_label" => "2 Jan 2021",
  +               "comparison_date_range_label" => "1 Jan 2021"
  +             }

私はElixirプログラマーでも、このコードベースに詳しいわけでもありませんが、コードを見るだけで、不合格で「tasteful」でないOpus 4.7の解決策は、参照ソリューションと意味論的に同一に見えます。唯一の違いは、読みやすさのためにパイプラインが複数行に展開されたことです。Elixirを知らなくても、「tastefulness」に基づいてこれを失敗させるのは不条理に思えます。

私はこのようなパイプ演算子を一般的に使用する他の言語（F#やtidyverseでのRなど）を使用したことがありますが、「tasteful」でないためにOpus 4.7の変更を却下した人を（スタイルガイドに、複数行に展開すべきものとそうでないものに関する厳格なルールがない限りは）見たことがありません。もしそうであれば、自動フォーマッターがこれを処理すべきであり、解決策のフォーマットは無関係です。

Fable 5の解決策は、変更の範囲を広げすぎたために却下されるべきかもしれませんが、他の理由で却下されるべきかどうかに関わらず、長さのために「tasteful」でないとして却下されるのは間違っているように思えます。

グレーダーのばらつき

LLMのばらつきは、採点自体にも適用されます。同じ問題を複数回解くようにLLMに依頼すると、異なる結果が得られるのと同じ理由で、単一の実行結果をLLMグレーダーに複数回入力すると、同じものに対して異なるスコアが得られることは当然です。私は、近所のコーディングエージェントに、GPT-5.6 SolとOpus 4.8がテストされた各条件について、それぞれ10回採点を再実行させました（codexによると、採点はSonnet 4.6を使用して実行されたとのことなので、それで再実行しました）。期待されるLLM採点のtastefulnessの結果は、同じモデルと作業レベルを使用した場合、公式結果の23%の確率で反転します（サブ結果の観点から見ると、相対的なtasteは32%のケースで反転し、practice alignmentは5%のケースで反転し、task rubricは3%のケースで反転します）。代わりに、公式結果が典型的/中央値の結果と異なった確率を見ると、全体で21%の違いがあります（相対的なtasteでは27%、practice alignmentでは3%、task rubricでは2%）。全体的な反転率は個々の反転率よりも低いですが、それは、あるケースでは、サブスコアで結果がtastefulからuntastefulに反転したが、全体スコアはすでにuntastefulだったためです。

明確にするために、これは実行ごとのばらつきではありません。これは単一の実行に対するLLM採点のばらつきであり、公開されているGPT-5.6 SolとOpus 4.8のベンチマーク全体で、約20%の確率で不正確な結果を与えるようです（測定されているものが正確で、そもそも測定可能であり、最も可能性の高いSonnetスコアが正しいスコアであると仮定した場合）。

もちろん、異なるモデルで採点した場合も異なる結果が得られます。GPT-5.6 Solで再採点すると、Sonnet 4.6で採点した場合と比較して、tastefulと判断される解決策の数は両方のモデルで半分以下になります。それはより正確なのか、それともそうでないのか？誰が知るでしょうか？

31. 寒冷地タイヤの性能

オールシーズンタイヤは7℃/45°Fで非常に硬くなり（「ホッケースティックのように硬くなる」という表現がよく使われます）、安全でなくなるということが一般的に言われていますが、ベンチマークがありません！これはこのシリーズでよく見られるテーマです。測定に基づかない主張を繰り返す人々です4。

幸いなことに、プラットフォームと収益化に関するこの投稿で議論したように、Jonathan Bensonはタイヤの詳細な調査を収益化することに成功し、公開されているタイヤベンチマークで前例のないレベルの詳細をもたらしました。彼はさまざまな温度と条件で異なる種類のタイヤがどのように機能するかをテストしました。タイヤメーカーがこのようなさまざまなテストを行っていることは確かですが、私の知る限り、これは包括的な方法で公開されたことはありませんでした（うーん、これはコーディングエージェントの公開ベンチマークとそれほど違いはないようです）。

Bensonのテストでは、乾燥路面では、夏用タイヤが0℃/32°Fまで最高のグリップを発揮し（それ以下の温度はテストしていません）、次にオールシーズンタイヤが続き、冬用タイヤは夏用タイヤとオールシーズンタイヤの両方よりもかなり劣るという結果でした。ウェットコンディションでは、0℃では氷結路面となり、単なるウェットコンディションではなくなるため、2℃までしかテストしていません。ランキングは少し異なります。なぜなら、2℃のウェットコンディションではオールシーズンタイヤが夏用タイヤを大きく上回ったからです。しかし、夏用タイヤは冬用タイヤよりも優れていました。

ビデオでBensonが冬用タイヤと呼んでいるのはUHP（ウルトラハイパフォーマンス）冬用タイヤであり、アメリカやカナダではほとんど見かけません（ただし、私の住んでいる地域の状況では冬用タイヤとして使用しています）。タイヤを見ている変人の私から見ると、私の車以外では、高性能車でOEM推奨オプションがUHP冬用タイヤである場合にのみ、地元でUHP冬用タイヤを履いている人を見かけました（それでも、冬用タイヤを履いているほとんどの場合、UHP冬用タイヤを履いていません）。

彼が「ノルディック」タイヤと呼んでいるものは、地元や私が住んでいた他のすべての場所でほとんどの人が冬用タイヤとして使用しているものですが、それらの場所では、山間部によく行く場合を除いて、それほど意味がありません（それでも、私が住んでいたほとんどの人にとっては適切な選択ではないでしょう）。あるいは、氷上を長時間運転する場合です。なぜなら、乾燥路面やウェットコンディションでのパフォーマンスは、UHP冬用タイヤよりも劇的に劣るからです。私の住んでいる地域では、市街地で氷に遭遇することは非常にまれです（5年以上、街路速度で一度も遭遇したことがありません）。そして、主に市街地を運転する人は、時折雪が降る乾燥路面やウェットコンディションを運転することがほとんどであり、その場合、「ノルディック」（標準）冬用タイヤは、トラック用タイヤやオールテレーンタイヤのような専門タイヤを除けば、あなたが走らせることができる最悪のタイヤです。そして、UHP冬用タイヤの結果をオールシーズンタイヤと比較すると、0℃以上ではオールシーズンタイヤが乾燥路面やウェットコンディションで優れているという事実は依然としてありますが、その差の大きさは、「ノルディック」冬用タイヤ（米国でほとんどの人が使用しているもの）と比較した場合よりもはるかに小さいです（彼が使用している用語はヨーロッパでより一般的かもしれません）。

もちろん、タイヤによってパフォーマンスは異なり、異なるタイヤで結果のばらつきが見られるでしょう。そして、オールシーズンタイヤや夏用タイヤよりも冬用タイヤの方が適している多くのコンディションがあるのは確かですが、オールシーズンタイヤが硬くなりすぎてグリップできなくなり、低温のためだけに冬用タイヤが必要になるという考えは、一般的に引用される温度では明らかに誤りです。

タイヤに誰が気にするのか？

ちなみに、なぜタイヤに気を使うべきなのか疑問に思っているなら、平均すると、自動車事故はかなりの死因です。そして、速度が事故の深刻度に与える影響を見ると、それはかなり大きいので、より迅速にブレーキをかけたり、少しコーナーをうまく曲がったり、事故を回避したり、かわしたりできるタイヤがあれば、事故の深刻度に大きな影響を与える可能性があると考えるのは合理的です。この種の明確なデータがあるとは思いません（ランダム化比較試験を実行するのは非常に困難であり、観察データは一般的に非常に交絡しやすいです）。

しかし、昨年行った分析の一環として、実際の衝突テストデータにおけるHICと速度の関係を見つけようとしました。驚くべきことに、私はこの研究を見つけることができませんでした（このシリーズの演習として役立つ論文はいくつか見つけましたが）。しかし、簡単な分析では、その関係はおおよそ4乗に比例すると示されました。私はこれを、この他の衝突テストに関する投稿のようなものですが、特に様々な車両のHICと脳震盪リスクに特化した投稿として書くべきです！いずれにせよ、私はその地域に適したタイヤを装着した車を運転するようにしていますが、それはおそらく、私の安全のために、ドルあたり、あるいは労力あたりの影響が最も大きい介入の1つであるように思われます。しかし、私の非常に良いタイヤが違いを生んだ状況に近づいたことは一度もありません。安全上の理由で適切なタイヤを見つけようとする人は、そもそも事故に遭う可能性が低いかもしれません。したがって、これは単にどうでもよい趣味である可能性もあります。

ベンチマークと評価におけるさらなる問題点

この記事が気に入った場合、これはベンチマーク、評価、実験デザインに関する一連の演習の一部です（1、2、3、4、5、6）5。

Peter Geoghegan、Aaron Levin、Luke Burton、Em Chu、Jamie Brandon、Yossi Kreinin、Jeshua Smith、Ikhwan Leeのコメント/訂正/議論に感謝します。

付録：ディスクパフォーマンスについてさらに詳しく

これは、私とは異なり、ディスクパフォーマンスについて何か知っているPeter Geogheganによるフォローアップコメントです。

私は、比較可能なSSD間で、特定のアクセスパターンにおいてパフォーマンスに大きなばらつきがあるのを見てきました。これはおそらくFTL/ファームウェアレベルの違いによるものです。明らかに、OSのリードヘッダ（ダイレクトIOを使用）とは無関係に、後方シーケンシャル読み込みにおいて、あるSSDは他のSSDよりもはるかに優れています。これに関するブログ記事は、私がPostgresのインデックススキャンにおけるIOプリフェッチについて共同作業している人物によるものです：https://vondra.me/posts/fun-and-weirdness-with-ssds。

これらのことがOS/ファイルシステムにとって依然として不透明であると確信しています。この時代遅れのLWN.net記事は、その正当性を提供しています：https://lwn.net/Articles/353411、「SSD実装に関する詳細情報を求められた場合、ファイルシステム開発者へのメッセージは「私たちを信頼してください」であり、「あなたの美しいシステムプログラマーの頭を心配しないでください」です。」

私はLinuxハッカーのMatthew Wilcoxに2023年にこれを尋ねました。彼は同じだと述べ、もしマイクロベンチマーク目的でパフォーマンスのばらつきを考慮したいなら、プロビジョニングに非常に注意を払い、定期的にTRIMを実行するなどするのが依然として最善の方法だと述べました。

かつて（おそらく2015年頃）、CPUパフォーマンスに関する演習やチュートリアルにするつもりでコードを書きました。それは概算計算リポジトリのようなものでしたが、範囲ははるかに狭かったです。アイデアは、「X CPUがあります。このループがどれくらいの速さで実行されるかを知りたい場合、どのパラメータを知る必要がありますか？」や「これらのパラメータが与えられた場合、ループはどれくらいの速さで実行されるべきですか？」といった質問ができることでした。

私はさまざまなものに対して望むコードを持っていましたが、何らかの理由で、私が書いたコードはDRAMのオープンページアクセスとクローズドページアクセスの違いを明らかにしなかったので、その後他のことに気を取られ、書き上げることはありませんでした。LLM以前は、これを正しく行うには、関与しているメカニズムについて十分に知る必要があり、その後コードの記述と動作の確認に注意を払う必要があったため、このようなことを行うのはかなり時間がかかりました。そして、私が何かを台無しにしてデバッグする時間が十分にあったため、少なくとも1つの問題があるという謎があったため、演習を書き上げることはありませんでした。

いずれにせよ、ディスクははるかに複雑であり、良い数値を得るにはさらに注意が必要です。LLMを使えば、これは今ではそれほど時間がかからずに可能になると思いますが、それでもある程度の注意は必要でしょう。

P.S. （29）で言及されている私の友人はJamie Brandonで、現在面接を受けて仕事を探しています。彼はデータベース（クエリエンジン）やストリーミングシステムでかなりの仕事をしてきました。彼の最も有名な著作はおそらくAgainst SQLですが、ストリーミングシステムの整合性バグの分析のような他の多くの好きな投稿も書いています。彼は主にバンクーバー近郊の仕事かリモートの仕事を探しています。彼に連絡を取りたい場合は、jamie@scattered-thoughts.netまでご連絡ください。

---

1. 私はしばしばパフォーマンスエンジニアと間違われますが、それは、ハードウェアのバックグラウンド（ソフトウェアよりも成熟した分野です。ここで議論されているように）によるベンチマーク/評価/実験デザインに関する異常な経験と、ドル価値に容易に関連付けられる問題に取り組む傾向（これ、またはこれ）の組み合わせにより、パフォーマンスの問題を解決することがありますが、パフォーマンスの仕事に日々従事している人々と比較して、パフォーマンスの問題に関する深い知識や幅広い知識を持っているわけではありません。［戻る］
2. 言語でフィルタリングすることが理にかなっているかどうかというトピックについて、人々がこの投稿で言語のトークン効率について言及しているのを見た後に調査しました。その投稿の結果は、非自明なタスクでは再現しませんでしたが、言語間に実際に十分な違いがあるように見え、言語でフィルタリングすることが理にかなっている可能性がありました。特に、エージェントが何かを実装できない場合、特に低労力レベルでは、言語の特異的な誤用が原因であることがよくあります。例えば、その投稿のzstd評価では、Clojureを使用するエージェントはバイト変換の誤ったセマンティクスに依存することが非常に多かったですが、Javaを使用するエージェント（基本的に同じ操作が利用可能）はその間違いをしませんでした。［戻る］
3. メタレベルでは、他のトピックについて一般的に合理的なコメントをする人々は、これらのヘッドライン/サマリー結果をあまり真剣に受け止めません。

例えば、これらのベンチマークの有用性に関するコメントで、Em Chuは次のように述べています。

twitter/hacker newsのセンチメントは、少なくとも誤解を招くほど正確ではないため、モデルが有用かどうかを判断するより良い方法のように思えます（奇妙なことですが、残念ながら多くのHacker Newsの投稿を読む必要があります。そのためお勧めできません。）LLMベンチマークのように見えるものは、読む価値がある可能性がほぼゼロなので、通常は目をそらします。（Hacker Newsのコメントにもそうしたいです。）

私が信頼する判断を持つほとんどの人は同様のアプローチを取ります（オンラインセンチメントの代わりに、知っている人の意見を使用することもあります）。例外は、一般的にこの分野で働き、多くのベンチマークを見て、それらを何らかの方法で精神的に集計する人々です。例えば、Max Bitker（RL環境スタートアップを経営）と話すと、彼はほぼすべての公開ベンチマークに精通しており、モデルリリース後のセンチメントがどうなるかを、すべてのベンチマークの集計された景観のメンタルモデルに基づいて数週間後に予測できるようです。しかし、それはサマリースコアメトリックを見るのとは全く異なるものであり、AIで働いていない限り、モデルの有効性を評価するために行うこととしては、趣味の興味というよりも、それほど時間がかかるものではありません（趣味の興味に反対するものではありません。私にもたくさんの趣味があります）。

具体的な例として、これらのベンチマークの結果を真剣に受け止めることと、現実世界で観察されることの違いを示します。ここにスレッドがあります。ある人が、当時新しかった5.6 Sol/Terra/Lunaと5.5の有効性対コストの表をDeepSWEの結果を使用して作成しています。ある人（私は同意しますが、別の言い方をするでしょう）は次のように返信しています。

馬鹿げてる。モデルを使ったことがあるのか、それとも自慰行為をしているのか？この表によると、5.6-sol xhighは5.5 xhighよりも安価で優れているはずだ。それは現実のどこで真実なのか？

別の人もそれに返信して

どこにもない。ベンチマークタスクは非常に単純なので、表は真実かもしれない。

私はそれが完全に公平だとは思いません（真実であるように思えるタスクを試しました）が、一般的に、人々は公開ベンチマークが示していることとは大きく異なる経験をしています。これは、私が個人的に知っている人々からランダムなインターネットコメンターまで、かなりの数の人々によって理解されているようです。しかし、それは普遍的ではありません。なぜなら、私は依然として人々がこれらのスコアを、あるモデルと作業レベルを使用する理由を説明するために広めているのを見かけますが、それは一般的に正当化されないように思えます。

［戻る］
4. 一般的に、私はこれらの例を演習に変えることはありません。なぜなら、誤った主張が非常に頻繁に発生するため、一般的なケースではそれほど面白くない、多くの回数見かける一般的な主張である場合を除いては。 ［戻る］
5. 私はPatreonでこれらを公開しています。理由は特にありません。Patreonからいくらかのお金を得ていますが、お金を最適化していたなら、すべてのものを公開するのが明らかに正しい選択でしょう。なぜなら、潜在的な仕事へのつながりから得られる可能性のある差額は、Patreonから直接得られる収益をはるかに上回るからです。これは、面接が下手であることを考えるとさらにそうです（私はほとんどの場合、面接が形式的な仕事しか得ていません。そうでなければ、面接に合格する確率はゼロに近いです。最後に面接を受けたとき、LeetCodeスタイルの質問で電話スクリーニングに落ちました。そして、それらに合格した場合でも、それが実際の面接であれば、通常は後で最終面接で落ちます）。

当初、私はPatreonで公開していたものを、ブログ記事にするには小さすぎる、あるいは取るに足らないと考えていたものにしていましたが、その後Patreonで公開する習慣がつき、しばらくの間、あまり公開記事を書いていません。

この種の投稿は、一連の演習の一部であり、通常のブログには小さすぎて取るに足らないと思われるものに分類されます。これについて意見があれば、ぜひ聞かせてください。

このシリーズの背後にある考え方は、ベンチマークと評価を改善するためのチュートリアルまたはブログ記事のようなものを書きたいと思ったことです。しかし、評価に関する私の考えは、特定のプロセスに従うことよりも間違いを避けることの方が重要であるということです。そのため、一般的なケースで機能するステップバイステップガイド形式は実際にはありません。因果グラフを描き、そのグラフを見て潜在的な問題（例：コライダーバイアスhttps://en.wikipedia.org/wiki/Collider_%28statistics%29）を見つけるといったことを教える実験デザインのアプローチがあることは知っています。このようなテクニックを学ぶ前と後のデータ分析のやり方を見るだけで、平均してそれほど大きな違いはないと思います（ただし、数人の人々にとっては非常に役立ちます）。

私は、この一般的な実験デザインの問題を回避する方法に対する批判（おそらくAndrew Gelmanから）を見ました。問題は、すべてがすべてに関連しているため、因果グラフを作成する際に依然として判断を適用する必要があるということです。グラフが作成されたら問題を機械的に見ることができるというだけでは、最初に間違ったグラフを描くことを止めることはできません。

数年前にMcElreathのStatistical Rethinkingの最初の部分を読んだときに見た、厳密な統計分析につながるプロセスを学びたいという願望とは少し関連のあるアイデアは、そのようなプロセスは実際にはなく、最終的には何かが理にかなっているかどうかを判断するために自分の判断を使用する必要があるということです。

その場合、演習のシリーズが機能するかもしれないと考えました。そこで、例えば50または100の演習を1つの投稿にまとめるというアイデアがありました。これは小さな演習には非常に実行可能ですが、さまざまなことを学ぶ人々を見ていると、人々が多くの小さな演習を与え、それから人々がそれらのテクニックをより大きく、より複雑な演習に一般化することを期待しても、それは通常あまりうまくいかないことが明らかです。より大きく、より複雑な演習を追加し始めると、すぐに長い投稿の長さを超えてしまいます。このブログの基準でも、FTCが2011-2012年のGoogle調査で何が間違っていたかについての32kワードの投稿（参考までに、典型的な小説はしばしば80k-100kワードと言われています）と比較してもです。

一般的に、私は複数のパートからなる投稿をブログに掲載することを避けてきました。なぜなら、読者として、物事が1つの投稿にすべて収まっている方が、いくつかの長い投稿に分散されているよりもはるかに好むからです。著者が複数のパートからなる投稿を好むのは、一般的にトラフィックが増え、ソーシャルメディアでバイラルになる可能性が高まるためですが、私は常にこのブログを、読みたいものにより似せるように最適化してきました。この場合、単一投稿版は、ドアストッパーファンタジー小説と同じくらいの長さになる可能性があります（参考までに、Brandon SandersonのStormlight Archiveシリーズの書籍は約450kワードと言われています）。この投稿は3つの演習と約7kワードです。そのペースで64の投稿が必要だと思いますが、私はまだ7番目です。しかし、確かに64の投稿を書くのに十分な問題があり、それはそれらに時間を割くかどうかの問題です。

［戻る］