ベンチマークスコアの大半は「ハーネス」のスコアかもしれない

#LLM #ローカルLLM #ベンチマーク #エージェント設計

ベンチマークスコアの大半は「ハーネス」のスコアかもしれない

きっかけ

hellohazime さんのこの記事を読みました。

2bitに量子化したKimi K2.7 CodeにMac Studio 1台で$69,875を稼いでもらった

Mac Studio（M3 Ultra / 512GB）1台の上で、Kimi K2.7 Code を 2bit まで量子化したもの（Unsloth の GGUF、約341GB）を動かし、SWE-Lancer というベンチマークの IC SWE (Diamond) 198タスクを解かせた、という検証記録です。13日弱かけて 47.0% 正解、獲得「報酬」は $69,875。

タイトルのインパクトが強いので、そこだけ切り取られて流れていきそうな記事なのですが、私が読んで手が止まったのは金額ではなく、記事の中盤にある 3.85% → 47.0% という数字でした。

以下、そこに至る前提を整理しつつ、自分が何を持ち帰ったかを書きます。

まず、$69,875 は実収入ではない

これは著者も隠していないので確認だけしておくと、SWE-Lancer は OpenAI が公開しているベンチマークで、実在した（過去の）フリーランス案件を、当時の報酬額つきでタスク化したものです。「解けたら、その案件の報酬額を獲得したものとみなす」というスコアリング。

つまりこの $69,875 は、ドル建ての得点表です。誰かの口座に入ったお金ではありません。

Diamond セット198タスクの報酬総額が $189,300。1タスクあたり平均 $956。実案件由来なので単価が高く、最高額は $32,000 の1件があります。だから半分弱正解するだけで7万ドル相当に届く、という設計になっています。

「AIが○○円稼いだ」という見出しは今後も増えると思うので、その金額の単位が通貨なのか得点なのかを最初に確認する、というのは癖にしておいたほうがよさそうです。

本題: ソルバーを直したら 3.85% が 47.0% になった

ここが、この記事のいちばんの価値だと思っています。

著者の最初のランは、52タスクを採点した時点で正解2つ、3.85%。そこで一旦止めてログを見たそうです。

そこで分かったのが、Kimi が問題を解けていないのではなく、答えを出す経路が噛み合っていなかったということでした。

SWE-Lancer に付属する標準のソルバーは、モデルに本文中で python のコードブロックを書かせ、それを取り出して実行する方式です。ところが Kimi K2.7 Code は、学習によって「ツールを呼ぶ」作法が強く定着しているモデルで、コードブロックを書かない。代わりに、存在しない functions.python のようなツール呼び出しを延々と出し続ける。そして一度もコードを実行しないまま100ターンを使い切る——そういうタスクばかりだった、と。

対策として著者は、OpenAI 互換の関数ツール python（引数は code）を定義した新しいソルバーを書き、モデルが訓練で慣れている形をそのまま使わせるようにしました。

結果が 47.0%。12倍以上です。

さらに、それでもモデルがツール呼び出しの生の記法や JSON の code 欄にコードを出してくることがあったため、そこから Python を抽出して実行するフォールバックも追加。これが198タスク中21タスクで実際に発動しており、無ければスコアはもっと低かっただろう、と書かれています。

モデルは一切変えていません。変えたのは、答えの受け取り方だけです。

ここから持ち帰ったこと

1. 測っているのは「モデル」ではなく「モデル × ハーネス」の積

ベンチマークの数字を見るとき、私たちはつい「このモデルは○%」と読みます。でも実際に測られているのは、モデル単体ではなく、モデルと実行環境の噛み合わせを含んだ系全体の性能です。

同じモデルで1桁変わりうる。これは、モデル比較の議論をするときの前提として、かなり重い事実だと思います。

実務に落とすと: モデル選定に時間を使う前に、まず自分たちのハーネスがそのモデルの作法に合っているかを疑う。特にエージェント系の実装では、どのモデルを選ぶかより、どの形式で答えを受け取る契約にするかのほうが、成否を分けている可能性が高い。

2. プロンプトによる「禁止」は効きが悪い

著者はプロンプトに「functions.* というツールは無い、実行できるのは python だけ」と明記していました。それでもモデルは存在しないツールを呼び続けた。

学習で身についた出力形式は、プロンプトの禁止文では上書きしづらい。

ということは、設計の向きが変わります。やってほしくない形を禁止するのではなく、やってほしい形をモデルが慣れた姿で用意する。 抑え込むのではなく、通り道を作る。

私は以前、音声認識モデルの LoRA ファインチューニングを回したことがあるのですが、そのときの WER / CER の改善も、よく見ると音響的な精度向上というより、学習コーパスのトークナイズ流儀にモデルが寄っただけ、という側面が大きかった。構造は同じだと感じています。

モデルは「正しさ」ではなく「見慣れた形」に引っ張られる。

3. 数字の限界を自分で開示している記事は信用できる

この記事で個人的にいちばん好感を持ったのは、成果を出したあとの節です。

著者は、モデルの応答1回が900秒を超えたら打ち切って途中状態のまま採点する、という上限を自分で追加したことを明かしています。しかもこの打ち切りは198タスク中109タスク、半数以上で最低1回発生していて、そのうち75タスクは0点だった、と。

つまり 47.0% という数字自体が、半分以上のタスクを途中で切った上でのものだ、と自分で割り引いている。

検証記事の価値は、数字の大きさではなく、数字がどこで壊れるかを書いているかで決まると思います。これは読む側の基準であると同時に、自分が書く側に回ったときの基準でもあります。

「1台で稼げる」ではなく「手元に置ける」

経済性の話もしておくと、これは仕事としては成立していません。

なので、この記事から読み取るべきは「Mac Studio 1台でフリーランス代行が回る」ではないはずです。

読み取るべきは、たぶんこちらです。

フロンティア級のコード能力が、ネットワーク不要・従量課金なしで、手元のデスクトップ1台に置ける水準まで来た。

参考として、SWE-Lancer の論文が出た2025年2月時点で、IC SWE (Diamond) の最高値は Claude 3.5 Sonnet の 26.2% でした。その1年4か月後に、2bit まで削ったオープンウェイトのモデルが、店で買える機材1台で 47.0%。

この差分が意味するところは大きいと思います。特に、データを外に出せない領域の仕事をしている人にとっては。ただしスループットは実用にはまだ遠いので、当面は「バッチで回せる・非同期でよい」タスクに限られるでしょう。

おわりに

私がこの記事から受け取った一行は、これです。

モデルの能力より、インターフェースの噛み合わせのほうが、しばしば支配的である。

AI を仕事に組み込むとき、私たちは「どのモデルが賢いか」を議論しがちです。でも実際に成果を分けているのは、もっと地味な接続部の設計かもしれない。3.85% と 47.0% を分けたのは、モデルではなく、そこでした。

丁寧な検証と、正直な自己開示に感謝しつつ。元記事はぜひ全文読んでみてください。

参照