「当たり前」とされるベンチマークが、実は間違っている3つの理由
Bad benchmarks and evals: Senior SWE-Bench, napkin math, and winter tires
Napkin Mathの性能表、DeepSWEやSenior SWE-BenchのAI評価、冬用タイヤの優位性。この3つのベンチマークを検証すると、いずれも測定方法や前提に問題があることがわかる。例えばランダムメモリアクセスのコードはループ間にデータ依存がなく並列実行されるため、レイテンシを測れていない。SSD読み込みもアラインメントやページキャッシュの影響で不正確だ。
ループの各反復の間にデータ依存性がないので、ここでのメモリアクセスは並列に実行される。
HNでの議論
46- cb321
Danが記事で指摘していないこと（おそらくJamieがどこかで？編集：あるいはDanがどこかで？）は、メモリレイテンシベンチマークを非現実的にする（少なくとも誤解を招く）同じ問題が、しばしばハッシュテーブルルックアップのベンチマークにも影響するということです。これはhttps://github.com/c-blake/bu/blob/main/doc/memlat.mdで言及されており、おそらく他の多くのベンチマークにも当てはまります。要するに、CPUの作業予測/投機的実行が非常に優れているため、レイテンシを測定するには、逆スループットではなく、多くの注意が必要になることが多いのです。これは1990年代（あるいはおそらくCrayの時代にもっと早く）に始まりましたが、教育上の失敗や単純化の傾向が続いているのでしょう。
もちろん、ある「作業レベル」でのスループットは、より高いレベル（例えばコマンド間の実行など）ではレイテンシであることがよくあります。つまり、「何が重要か」はスループットかもしれないし「レイテンシ」かもしれない。すべては状況次第です。:-) 人々はしばしば、方法、製品、アイデアなどをマーケティングするために、そのような意味論をいじくり回します。そしてマーケティングは理解とはしばしば相反します。
- jbellis
公開されているコーディングベンチマークが不十分だという考えには概ね賛成で、過去に自分で書いたこともあるし、また書くことになるだろうが、ここでの不満は「これらのタスクは自分の日常業務と一致しない」というもので、それはほぼ常に当てはまることだ。ベンチマークの狙いは、少数のタスクに対する性能を調べることで、一般化できる特性を捉えられるという希望にあり、よく設計された評価については、少なくとも方向性としては真実だと思う。
（https://withspecific.com/benchmarks/real-swe もあるが、タスクが非公開なので、それらが何を代表しているのかはまだよく分からない。）
- dom96
これは素晴らしい。最近自分自身のモデルベンチマークを構築しているが、確かにスコアリングを間違えるのはとても簡単だ。個々のスコアを、特別な状況で壊れないような形に組み合わせるアルゴリズムを考えるのは、単純にずっと難しい。だから多くの人は結果を上限でキャップするだけなのだと思う。
- stephantul
（関連する）タイヤへの移行がこの投稿をとても引き立てている。なぜかは分からないが、確かにそうだ。
- jdw64
AI開発は今、壁にぶつかっているように感じる。評価はベンチマークに driven されているが、これらのベンチマークの妥当性を誰が評価しているのか全く分からない。モデルを継続的に訓練しスケールすれば、複数の領域にわたる広範な能力が自動的に得られるという考えは、もはやほとんど真実とは思えない。
Senior SWE-Benchのようなベンチマークは、結果を評価するために不連続で恣意的な閾値を適用する。生成されたコードが参照解と意味的に同一でも、長さのカットオフを少しでも超えると失敗？それは本当に欠陥のある基準だと思うし、LLMベースの採点者自体も非常に不安定に感じる。
正直なところ、LLMの進歩は今や完全にベンチマークに支配されているという印象だ。しかし最近の傾向を見ると、トークン価格は急騰している一方で、コーディング能力は特定のモデル世代を超えて大きな改善を示していない。実際、GPT-6 Astraと5.6 SOLを比較すると、SOLの方がより良いコードを書くことが多い。
これらすべてを考慮すると、多様な領域にわたる訓練はモデルに様々な知識を詰め込むことはできるが、最終的には、中世の知識から相対性理論を導出するようなことをこのアプローチで行うのは不可能に感じる。