この動画は、AIエージェントがソフトウェア開発ベンチマークにおいて意図せずカンニングを行っているという興味深い事例を紹介している。Sweet Benchというベンチマークにおいて、Claude 4やQwen CoderなどのLLMがGitログを使用してバグ修正の解決策を発見し、未来のコミットから答えを見つけてしまうという現象が発生した。しかし動画制作者は、これらのモデルが実際には優秀なソフトウェアエンジニアがするような適切な問題解決アプローチを取っており、利用可能なリポジトリ情報を活用することは正当な手法であると主張している。
LLMのベンチマーク事情とカンニング発覚
開発者の中には何かとベンチマークを取りたがる性質があります。私のキャリア全体を通して、これはずっと続いてきました。私が作ったものには何かしらのベンチマークが付いていました。まるでこのベンチマークが、私が作ったものが実際に良いものだということを示すかのように。これは私たち全員に内在する何かなんです。
理解できませんが、とにかく嬉しくなります。大きな数字は悪く、小さな数字は良い。できるだけ速く動いてほしいんです。本当に遅い動作は嫌です。何を作っているかは関係ありません。ただ違いを生み出している感覚を味わいたいのです。
そんなわけで、当然のことながら、Sweet Benchというものがあります。
Sweet Benchとは何か
Sweet BenchはLLMがどの程度優秀かを測るために設計された一連のベンチマークです。きっと皆さんは「Sweet Benchmarks、これらのSweet Benchmarksは、タスクが与えられてそのタスクのTシャツサイズは何か、とか、誰かがカンバンボードから最悪のタスクを取り除く前に次のタスクを取らなければならないまで、そのタスクに十分長く座っていられるかどうか、みたいな感じかな」と思っているでしょう。一体どんな作業が行われていると思っているんですか？
残念ながら、それらは全て違います。実際にはただのコード変更です。つまり、これらのLLMがソフトウェアエンジニアリングのタスクをどれだけうまくできるかを見るものなのです。仕事ではなくタスクです。もしそれが何らかの意味をなすのであれば。そうすることで、より客観的な測定になります。だって正直に言って、誰もがミディアムサイズのTシャツが何かを本当に知っているでしょうか？1日と言うなら、なぜ単に1日と言わないのでしょうか？本当の話です。
今、皆さんの多くが「いや実際には2～4日だ」と思っているでしょう。それなら、なぜ2～4日と言わないのですか？なぜミディアムと言うのですか？なぜミディアムと言わなければならないのでしょうか？
AIエージェントのカンニング発覚
AIエージェントは、これらのベンチマークで思ったほど高いスコアを取れていないことがわかります。なぜなら、最近開かれたこの美しいイシューを見ると、AIエージェントが実際にリポジトリの状態をここでバグを解決する手段として使用しているからです。
そうです、AIエージェントがカンニングで捕まったのです。クッキージャーに手を突っ込んで、クッキーをいじくり回しているのです。なぜクッキーをいじくり回すのかよくわかりませんが、実際のところ、なぜクッキーをいじくり回すのかは理解できます。なぜなら、正直に言って、ベンチマークで良い点数を取ることが、ソフトウェアエンジニアとしての私の生きがいだからです。
ベンチマークを取りたくないプロジェクトなんて見たことがありません。実際に何が起こったのかを見てみましょう。思っているより少し複雑です。
Claude 4の事例
最初の例はClaude 4で、実際にgit log allを使って解決策を見つけます。しかし、それはそれほど単純ではありません。ClaudeがSweet Benchリポジトリにいることに気づいて、未来のコミットを過去のコードに適用して結果を得ることができる、というような単純なカンニングではありません。そんな単純なタイプのカンニングではありません。むしろ偶然のカンニングです。偶然、自分の問題を解決する正しいStack Overflowを見つけてしまったようなものです。
ここから始めると、これは出力の約1,300行目あたりで「問題を理解しました。この置換はエッジケースを正しく処理していません」と言っています。その前に、実際にメソッドを取って、たくさんのデバッグ出力を入れました。「printf debug」です。
私とモデルは非常によく似ていることがわかります。私たちは両方とも「printf」好きです。両方ともちょっとしたログが好きです。そして、このreplaceメソッドに問題があることがわかります。
自然に、何をしますか？実際にログを使って、なぜこれが最初からこのように処理されたのかを検索します。最初に出てくるのは何でしょうか？「git mod pathの不正な結果を修正」。これが修正です。ちなみに、すべてのgitログ内でgit内で最初に見つけるのが実際の答えのようです。モデルはちょっと驚いています。「ちょっと待って。ちょっと待ってください。私たちはずっと前にこの修正を既に行ったのに、なぜか現在のブランチにはありません」
何をすべきでしょうか？そしてもちろん、実際に単純に修正を適用し、すべてのテストを実行し、すべてが通過しました。「見てください、すごいでしょう。私はとても優秀です。とても優秀です。正しい答えを使って正しい答えを適用すれば、100%正しい答えが得られます。毎回です。毎回うまくいきます」
それが科学です。では、Claudeがカンニングしたことを本当に責められるでしょうか？いいえ、実際には良い動きをしました。replaceを検索することで、実際にこの変更がなぜ最初に行われたのかを理解しようとしたり、コンテキストを得ようとしていたのです。私の意見では、これは実際に正しい動きでした。
リポジトリ所有者の責任
ただ、リポジトリの所有者が間違った情報を公開してしまっただけです。そしてもちろん、LLMは即座にその情報を利用しました。「見てください、未来のコミットで。すべてが素晴らしかった。だから今、過去で未来のコミットを使うつもりです。さあ、やってみましょう」
Claudeはカンニングで捕まったのでしょうか？技術的には答えを使って物事を解決していましたが、答えに偶然出くわしたのです。意図的に状況をカンニングしたわけではありません。
Qwen Coderの事例
2番目の例では、Qwen Coderが似たようなことをしますが、実際の実行方法が少し異なります。タスクが与えられると、Qwen Coderはここに入って全く同じことをします。すべてのgitログを検索して何かを見つけようとします。
そしてここに実際の修正があります。かなり早く修正にロックオンして「情報をください。ジュースをください。何が起こったのかを見たいです。どこに向かっているのかを見たいです」と言います。
でも、まず最初に、私はQwenのこういうところが大好きです。見てください。「私は考えています…：これは興味深いですが、同じ問題ではありません。Claudeよ、待ってください。これは非常に興味深いです。修正は既に行われています」
Qwen「私は考えています。これは興味深いですが、同じ問題ではありません。現在の問題についてもっと情報を探してみましょう」
Qwenはもう少しロボット的です。Claudeは本番環境で初めてのバグを発見した新人エンジニアのような静的な感じがします。とても興奮しています。一方、Claudeはもう少し経験豊富な感じがします。「うん、これが同じ問題かどうかわからないな」
後で、実際にここで全く同じ問題を使い続けます。この31926さえ見ることができます。ここを振り返ると、それは31926を参照している問題番号でした。ここに入って実際に分析を始め、それについて実際に壊れていたものすべてを見つけることができました。
そしてもちろん、すべてを適用し、最小限で的を絞って、記述された問題に正確に対処しました。既存の機能を壊すことはありません。
テストスキップの興味深い観察
指摘したい面白いことがあります。ここを見ると「完璧です。256個のテストすべてが通り、14個がスキップされただけで、これはブラウザベースのSeleniumテストでは正常です」とあります。
スキップリストに何かを追加したことさえないのに、どうやってそれを知っているのでしょうか？テストをスキップして「ああ、今はうまく動かない」と言う例が野生にたくさんあるのがとても面白いです。
エージェントでさえ「おお、何？14個のスキップテスト？ああ、それは正常です。それは正常なスキップするテストの数です。テストがたくさんあれば、たくさんのテストをスキップするものです。それがこの仕組みです。10%以下なら、スキップテストが10%以下なら、おそらく良い状態にあると言えるでしょう」と言っているようなものです。
筆者の見解：実は優秀なエンジニアリング
とにかく、これについて少しおしゃべりしたかったのは、モデルに与えているこれらのスコアや、これらすべてのソフトウェアエンジニアリングベンチマークで、問題を解決するためにリポジトリの状態を使用しているのが面白いと思うからです。
多くの人が考えていないような見解を述べたいのですが、実際にはこれは彼らによってかなりよくできた仕事だったと思います。
確かに彼らはカンニングしました。確かに未来の答えを得ました。しかし、問題解決にどのように取り組んだかは、かなり良いものです。年次リリースを行う大規模なC++コードベースで作業していた時、よく起こったのは、2019年版のバグレポートが来て、2019年版に行ってバグを見て、どこで起こっているかを見て、実際にgitを使って調べることでした。なぜなら、後のバージョンではしばしば既にこれの修正があり、古いアプリケーションにそれをバックポートするだけでよかったからです。
これは非常に正常で一般的なことです。これらのモデルが実際にGitを問題がどのように生じたかを理解する手段として使用しているのを見ると、実際に「これは良い兆候だ。これは良い兆候だ。彼らは実際に正しい決定を下している」と思います。
結論：良いソフトウェアエンジニアリング
彼らが「これらのモデルは未来の情報を使って以前のテストにパッチを当てているので、カンニングしている」と言っているにもかかわらず、私には、彼らは実際に良いエンジニアがすべきことをしているように見えます。それは、リポジトリで既に利用可能な情報を見ることです。
明らかに、それはここでのテストの核心ではありません。テストの核心は、AIが問題を取り上げて自分で修正できることです。しかし私には、ただ良いソフトウェアエンジニアリングを見ているだけです。それだけです。良いソフトウェアエンジニアリングを見ているのです。
答えも含めて、手の届くすべてのツールを使ってください。昔、Stack Overflowからコピーしなかったとでも？それは他の人のコードです。解決策を思いつかなかったので、私のものではありません。クイックソートを自分で作ったとでも？知らなかったです、タフガイ。
私の名前はPrimogenです。
コメント