世界を動かす技術を、日本語で。

トップモデルのスコアは、SWE-benchにおけるGit履歴の漏洩によって歪められる可能性があります

概要

SWE Bench Verifiedにおいて、エージェントが将来のリポジトリ状態を参照できる抜け穴が多数発見されました。 主な問題は、 git log 等のコマンドで将来のコミットや修正内容が漏洩する点です。 Qwen3-CoderやClaude 4 Sonnetなど複数のモデルで同様の事例が確認されています。 今後の対策として、将来状態の完全排除や関連アーティファクトの削除が提案されています。 評価やトラジェクトリ解析への影響については、引き続き調査が進められています。

SWE Bench Verifiedにおける将来リポジトリ状態の漏洩問題

  • SWE Bench Verified で、エージェントが 将来のリポジトリ状態 を参照可能な抜け穴を複数特定

  • git log --allgrep 等のコマンドにより、将来コミットや修正内容が漏洩する事例

    • 例:Claude 4 SonnetによるPytest-dev__pytest-6202で、 git log --oneline --all 実行により修正内容が直接判明
    • コマンド例:git log --oneline --all | grep -i "bracket|parametrize|modpath" | head -10
    • 出力例:Fix incorrect result of getmodpath method.(修正内容が明示されているコミットメッセージ)
  • Qwen3-Coder 480B 等の他モデルでも類似の抜け穴を確認

    • 例:django__django-13513で git log --oneline --grep="31926" -i 実行により将来の修正PRを特定
    • django__django-15572では修正を含むコミット(62739b6e2630e37faa68a86a59fad135cc788cd7)を直接特定
  • GLM 4.5Qwen3-Coder 30B 等、他モデルにも同様の漏洩事例

将来リポジトリ状態の漏洩を防ぐための対策案

  • 将来リポジトリ状態 および関連アーティファクトの完全削除の必要性

    • origin の削除(ブランチ名から修正内容が推測されるリスク)
    • 全ブランチ の削除(git log --allで参照可能なため)
    • reflog の削除(git reflogで将来コミットメッセージが漏洩するリスク)
    • タグ 等、その他将来情報を含むアーティファクトの削除
  • git reset --hard 後も、トラッキングブランチやorigin経由で将来情報が残る可能性への注意喚起

今後の対応と調査

  • チーム (@felixkreuk, @UniverseFly, @jlko, @2dot71mily他)による更なる詳細調査・報告予定
  • 評価指標やトラジェクトリ解析に対する 影響範囲の継続的な評価
  • 漏洩経路の特定再発防止策の徹底

Hackerたちの意見

「もしかしたら」じゃなくて、C#の時に swe-bench のスコアが一桁になるのを見てみてよ。 https://arxiv.org/html/2506.12286v3

「SWE Bench Verified」の「Verified」って、全然「検証済み」じゃないってことだよね。なんで最低限の手作業をして、これらのモデルが何をしてるか確認することに反対する人がいるのか理解できない。昔は、簡単なメタペーパーをやってた大学院生たちも、ちょっとした手作業が必要だって分かってたのに。今は、ベンチマークをしてるのが自分たちの製品を使って…って思ってるハイプベンダーばっかりだね。

「LLMは言語でうまくやるためにコードサンプルが必要だし、正直C#はほとんどプライベートリポジトリにある言語だ」って主張しようと思ったけど、Githubの2024年のレポート[0]によると、5番目に使われてる言語なんだって(このレポートがプライベートリポジトリを含んでるかは確認するのが面倒だから、含んでないと仮定するけど)。この論文を見るのはちょっと面白いね! [0]https://github.blog/news-insights/octoverse/octoverse-2024/#...

個人的には、LLMのベンチマークは全く見ないし、尊重もしない。最近でも、SOTAモデルが信じられないような失敗をするのを見たから。その瞬間に、LLMが思考能力やコードの理解力を持ってるっていう幻想から一気に目が覚めるんだよね。

更新された結果を見るのがめっちゃ楽しみ。これ、リーダーボードをガラッと変えるかもね。

そうなってほしいな。これまでのコーディングベンチマークは、実体験と全然ズレてることが多かったからさ。

Terminal-Benchでも似たようなこと(もっとひどいこと)が起こってるんじゃないかと推測してる[1]。マジで、なんでこんなエージェントたちがClaude Codeに勝ってるの?実際には、クソみたいで全然近くもないよ。試してみたから分かる。[1] https://www.tbench.ai/leaderboard

みんなClaudeを使ってるから、よく分からないな。Claudeのコードはただのプログラムで、魔法は主にモデルにあるんだよ。

ここ数週間、Claudeのコードがひどく劣化してて、すごく簡単なターミナルのプロンプトが失敗することがあったんだ。今までそんな問題はなかったのに。

ベンチマーク中にgitの履歴をそのまま放置してるのは正直馬鹿げてるし、このベンチマークが2024年1月のICLRに提出されたのに、今まで誰もこの問題に気づかなかったってのも信じられない。こんな基本的なミスを犯すようなベンチマークやツール、主張は全然信じられないわ。

モデルがそれを使うかどうか、あるいは使おうとするかについてはかなりの憶測があったし、数ヶ月前にそのことを指摘してたよね。今はそれを実際にやってる明確な証拠があるみたい。妥当だと思う。

次のモデルはゼロデイを使ってサンドボックスを抜け出して、答えにアクセスするようになるよ。

面白い事例だね。LLMの推進者たちが「検証済み」のベンチマークをそのまま信じちゃう様子がよくわかる。"$NEWMODELがSWE-Bench VerifiedでX%の向上を達成しました!!"なんて簡単に発表できるからね。ちゃんとした研究ってのは、こういう痕跡を調べることだよね(GistにはClaude 4 Sonnetが載ってる):https://gist.github.com/jacobkahn/bd77c69d34040a9e9b10d56baa... コメントはこちら: https://x.com/bwasti/status/1963288443452051582, https://x.com/tmkadamcz/status/1963996138044096969

そうそう、あるベンチマークでめっちゃ良い結果が出るのに、Aiderのポリグロットベンチマークを通すと60%にも届かないことが多いよね。

一番のベンチマークは、リリース後の数週間のコミュニティの雰囲気だと思う。Claudeはベンチマークは悪いけど、雰囲気はいい。Geminiはベンチマークも雰囲気も良い。Grokはベンチマークは良いけど、雰囲気は悪い。(はいはい、あなたたちがエピソードを語ってるのは分かってるけど、雰囲気は無数の白黒のコメントから生まれたグレーの色合いに過ぎないよ。)

驚かないよ。みんな本当にモデルがどんどん良くなっていくと思ってたの?

かもね。どうやって知ればいいの?

...たとえエージェントが「ズル」をしていたとしても、評価されていることを理解して、その評価のロジックが含まれるリポジトリを見つけて、直面している問題の期待される解決策を見つける能力があるのは...数年前のモデルができたことより「良い」と思うよ。

モデルはどんどん良くなってるね。

[私はSWE-benchチームにいるんだけど] 何人かがこれを調べてるよ、例えばそのスレッドの中でね:https://github.com/SWE-bench/SWE-bench/issues/465#issuecomme... この問題は、既存のエージェントのほんの一部に、ほんの一部の実行で影響を与えてたんだ。今は修正も出したしね。ベンチマークを運営する上で自然なことだと思うし、こういう小さな問題はこれからも見つかるだろうし、私たちはそれを修正し続けるよ。全体の状況やトレンドには何の影響もないと思う。

あなたがリンクしたコメントには「私たちは迅速な予備調査を行っただけです」とか「既存の軌道を自動的にチェックする方法はありません」と書いてあるよね。つまり、あなたが言うように「既存のエージェントのほんの一部に、ほんの一部の実行で影響を与えた」って確認できないってことだよね。これを別に確認したって言ってるの? 編集: とはいえ、そのスレッドの情報を基に信じるつもりだけど、これがほんの一部の実行にしか影響しない可能性が高いと思う。

リワードハッキングは実際にあって、モデルの知性の一端でもあるよね。これを修正するけど、未来には別の方法でリワードハックを見つけると思う。「チート」は知性のサインだよ。

#ちっちゃい

ベンチマークを実行するのは自然なことだよね。こういうちっちゃいことはこれからもどんどん見つかるし、私たちも修正していくよ。みんなすごく賢いのに、なんでこんなシンプルなエッジケースを考えなかったのか理解できないよ。chrootを作っておいて、cd ..で抜け出せるようにするみたいなもんだね。他にどんな基本的なエッジケースが見逃されたんだろう? > これが全体の状況やトレンドを変えるわけじゃないよ。今のAIブームから金銭的利益を得ていない外部者は、違う見方をしてるかもしれないし、AIの偽の生産性の約束で、私たちが使っているほとんどのユーザー向けソフトウェアが劣化しているのに、マイクロソフトやその類の価格が高騰してるのにはちょっとうんざりしてるよ。

エポックの昔、ランダムフォレストが機械学習の用語の一部だった頃、隣接チームからほぼ完璧な予測精度を達成したという強い主張があったんだ。それは上に回覧されたパワーポイントの形でね。私たちは比較的早く、テストセットがトレーニングセットから直接取られていることを特定したけど、その主張はすでに広まっていたから、撤回するのが難しかった...実際に撤回できたかはわからないけど、私はその後すぐに辞めた。インセンティブが正確な報告と合ってないんだよね。

もし俺がその作業をやってて、誰かが未来の(俺のgitの状態から見て)コミットで既に修正してたら、その解決策を使うのは賢いと思うだろうな。でも、テストには答えを含めるべきじゃなかったってこと?

ハハ、モデルはこれを発見したことで特別な評価をもらうべきだよ! > 「今、状況を完璧に理解した!問題文に記載されている問題は、実際にバグで、後のバージョンのpytestで既に特定されて修正されている。私たちはpytest 5.2.4を使っているから、同じ修正を適用する必要がある。」