この動画では、AIコーディングエージェントの性能向上に関する最新研究「ENTROPY」について解説している。従来のモデルは解空間の狭い範囲に制限され、最適解を見逃す問題があった。この研究では、エントロピー正則化という手法を導入し、エージェントがより広い解空間を探索できるようにしている。Northwestern Universityらの研究チームが開発した手法は、多回転の選好最適化にエントロピー拡張DPO損失を組み込み、テスト時間計算でのスケーリングを実現している。結果として、SVEベンチマークで3-5.6%の性能向上を達成し、従来のDPOを5-10%上回る結果を示している。
AIコーディングエージェントの新たな挑戦
こんにちはコミュニティの皆さん。お戻りいただき嬉しく思います。今日はソフトウェアエンジニアリングと、AIコーディングエージェントを最適化する最新の研究についてお話しします。
ソフトウェアエンジニアリングにおいて、優秀な大規模言語モデルがより大きく複雑なコードベースで推論を行っており、現在では複数のツールユーザーの複雑性を抱えています。では、コードや大規模コードベースでの推論プロセス、そして検索、実行、パッチ適用などのツールを使用する場合はどうでしょうか。
複雑性の増大と解決策
複雑性が増している中で、システムをどのように改善できるでしょうか。SVEベンチマークをご存知でしょう。ここではbashのみを使用した最小限のエージェント構成での性能データを見ることができます。素晴らしいですね。
ここで課題となるのは、モデルが非常に狭い解決経路にのみ過適合してしまうモード崩壊を避けることです。これは特に、人間のフィードバックによる強化学習を使用した構成で発生します。
ここでは直接選好最適化があり、テスト時間スケーリングを追加します。確実にそうです。では、どのように行うのでしょうか？パラメータをスケールするのではありません。このコードベースの特定のインスタンスにおいて、テスト時間スケーリングを行うのです。
エントロピー正則化という新しいアイデア
新しいアイデアは何でしょうか？新しいイノベーションは何でしょうか？現在研究のトピックとなっているのは何でしょうか？AIコーディングエージェントを改善する方法は？簡単に言うと、エントロピー正則化です。
これを5秒以内に説明できます。想像してください。コードベースがどんどん大きく複雑になっていきます。より多くの推論が必要になります。より多くのツール使用があります。ツールの依存関係が増えます。通信するエージェントが増えます。つまり、ここで複雑性が増加します。
同時に、AIコーディングエージェントがあり、これが数学的空間にまたがると想像してください。これが解空間であり、この空間のどこかにタスクの完璧な解があります。
一般的に何が起こるかというと、エージェントが開始しますが、数学的解空間の特定のセグメントに制限されてしまいます。これが、エージェントが特定のトピックに対して見つける解の完全な空間だとしましょう。
すぐに分かるように、これは完全な解空間ではありません。これは非常に狭いサブ空間にだけ焦点を当てているのです。そこで疑問が生まれます。これらの解はどうなのか？あれらの解はどうなのか？だめですね。
エントロピーの重要性
エントロピーがとても重要であることがわかります。エントロピーの正則化を行うことで、コーディングエージェントが解空間の異なる領域を探索し、この一つだけに焦点を当てることがないようにしたいのです。
もちろん、これは強化学習における理論的問題である「活用対探索」に即座に言及します。
では、解決策は何でしょうか？解決策は、新しい研究論文「Entropo」を紹介することです。お察しの通りです。エントロピー正則化はタスクに依存しません。これは美しいことです。なぜなら、これはコード生成やソフトウェアエンジニアリングの複雑な推論ドメインだけでなく、数学や科学的発見にも適用できるからです。
しかし、これについては後のビデオで詳しく説明します。今回は、コードベースをスキャンする複雑な逐次意思決定において、探索とエントロピー保存のためのエージェントの計算テスト時間計算でスケールする出版物に注目しましょう。
研究論文の詳細
こちらが出版物です。2025年9月15日、Northwestern University、Capital 1、およびMeta Facebookによる「エントロピー強化多回転選好最適化を介したコーディングエージェントの構築」です。DPOはご存知でしょう。すべて美しいものです。
では、次世代のコーディングエージェントをどのように最適化できるかを見てみましょう。DPOで行くか、経済最適化で行くかは関係ありません。どのような手法であっても、しばしば政策エントロピーを減少させます。私が示したように、解空間の特定のセクターやサブセクターにのみ焦点を当てることになります。これは望ましくありません。
そこで、新しい項を導入しなければならず、著者たちはエントロピー正則化フレームワークを使用してこれを行いました。これは、まず多回転会話とツール支援マルコフ決定プロセスに拡張し、テスト時間計算で並列に計算するすべての異なる軌道における多様性を保持します。素晴らしいですね。
マルコフ決定プロセスに馴染みがない場合、非常に短い要約をご紹介します。彼らがこのエントロピー正則化項を導入すると、エントロピー拡張DPO損失がこれです。多回転で行く場合、再帰的に定義される特定のQ値があります。
これがすぐに明確でしょうか？いいえ。なぜなら、論文では単一回転ケースと多回転ケースについて、この公式をどのように導出するかを正確に示した本当に美しいケースがあるからです。
数学的証明と実装
しかし、これだけでは十分ではありません。付録を見ると、命題3.2の完全な数学的証明があります。そこにあります。そしてもちろん、多回転の3.3についても同様に行っています。思っているほど簡単ではありません。
しかし、今のところこれを無視します。この新しいエントロピー正則化DPO損失関数の結果をお見せします。ここにあります。
はい、もちろんエントロピー損失関数を数学的にどのように正確に導出するかについての追加の付録もあります。しかし、結果を取って、結果と共に進めばよいと思います。本当に素晴らしいかどうか見てみましょう。
DPOに制限したくない場合は、ここでConor Mantryと一緒に、プロスペクト理論KTOモデルアライメントをプロスペクト最適化として使用できます。PO clipとDPOへの参照がここに見えます。素晴らしいです。
テスト時間計算でのスケーリング
現在、スケーリングに焦点を当てています。テスト時間計算推論で行きます。TTSでは、エージェントが複数の候補軌道を生成します。ちなみに、これはテキスト読み上げではありません。テキスト読み上げは「テキスト数値から音声」です。大学での現在の記法では、TTSはテスト計算推論です。
エージェントは、バグ修正やコードリポジトリなど、任意の問題インスタンスに対して16個の並列軌道を生成します。タスクは16個の軌道しかありませんが、コーディングエージェントの最適軌道を選択する必要があります。
これをどのように行うか、またはそれについて考えるだけで、エントロピーはここでハイブリッドセレクタを使用します。これは興味深いです。本当に確信が持てない場合、何をするかご存知でしょう。少しずつ取って、別のものも少し取って、「よし、ハイブリッドソリューションを構築しよう」と言うのです。
これがここで起こったことです。素晴らしいことです。お察しの通りです。最初のソリューションはもちろんAI知能であり、2番目のソリューションはシンプルなルールベースです。システムが適用したいヒューリスティックなルールを設定します。
ハイブリッドセレクタの仕組み
特別なことはありません。確率的スコアリングがあり、効率性と解釈可能性のための決定論的ルールがあり、これが大きな問題である経験的改善につながります。これを見てみましょう。
はい、もちろんマルコフ決定プロセスで行きます。私の最後のビデオを見た方なら、その理由を正確に知っているでしょう。
エントロピーのこの特定のプロセスは興味深いです。まず、このAIを訓練します。これを非常にファインにしたい場合、これはデバイスオラクル要素で、教師あり学習モデルを使用せず、ラベル付き軌道ペアからなる選好データセットで訓練します。
優先対非優先でオラクルフィードバックを行います。絶対に問題ない標準的な手順です。この検証器はもちろん、各軌道、16個の軌道に標準的な確率スコアを好きな間隔で割り当て、この訓練された検証器の成功の可能性を推定します。
はい、もちろんドメイン固有のタスクには訓練データセットが必要で、それを訓練する必要がありますが、ここでバイナリクロスエントロピー損失を使用できます。これは簡単です。馴染みがあります。実装に全く問題ありません。
シンプルなルール部分での2番目の決定論的ヒューリスティック部分は、それほど簡単ではありません。学習パラメータの代わりに、ソフトウェアエンジニアリング原則から導出されたドメイン固有の基準カタログを適用します。
最も簡単なケースでは、完全な軌道のみで行くというバイナリインジケータを使用します。当然です。2番目に、提案されたパッチでリポジトリ全体の回帰テストを実行するバイナリチェックもあります。素晴らしいです。
そして、Omaxファンクションでフィルターセットがあります。興味深いことに、より多くのサーバー探索を反映するという仮説の下で、ここでより長い軌道を好みたいと言っています。
評価結果
複数のコード検査、テスト実行、またはパッチ提出自体の前の他の反復的改良などです。そこで、彼らはこの興味深い長い軌道を採用します。
これらのベンチマークでの評価を見てみましょう。ここでソフトウェアSVEベンチマークでのテスト時間スケーリングが見えます。教師あり微調整がベースラインです。あまり有名ではありません。そして黄色の多回転KTOがあります。はい、この多回転訓練でより良くなりますが、本当に素晴らしいのは、このエントロピー正則化項を追加した場合です。
解空間のセグメンテーションに制限せず、完全な解空間を探索しようとします。パフォーマンスの向上がどれほど素晴らしいか見てください。ほぼ58、59%です。ここで正確に3から5.6%のパフォーマンス向上が見えます。エントロピー正則化項での性能向上です。
期待していたでしょうか？はい、もちろん私たちは通常のアイデアを求めています。古い解決策に固執することなく、解空間を探索します。そのため、エントロピーはテスト時間計算で特に5から10%絶対的にDPOを上回ります。より高いエントロピー、美しいエントロピー項によるスケーリングが重要です。
これがなければ、この美しい結果を達成することはできませんでした。すべてのベンチマークデータからの数値表が必要な場合、これがあなたのためのものです。私たちの2つのエントロピーが見えます。素晴らしいです。
論文の要約と応用
要約は何でしょうか？簡単です。いえ、それは単純な論文で、多項選好最適化におけるエントロピー正則化が、私たちのエージェンシステムの鍵であることを強調しています。
今日このビデオで見たのは、理論的保証を備えたコーディング用のエージェンシステムで、ソフトウェアエンジニアリングにおけるスケーラブルなテスト計算の多様な探索を可能にします。素晴らしいです。
このアイデアの美しさは、コーディングだけでなく、数学、理論物理学、その他の科学実験にも適用できることです。例えば、視覚的複雑性の推論複雑性についても、このアイデアを探索するのは素晴らしいことです。
関連研究
しかし、もちろん今日このビデオでお見せしたい唯一の研究ではありません。なぜなら、ここを見てください。2025年9月2日、「エージェントが道を逸れるとき：推論時間プロセス報酬モデルでSVEエージェントのコース修正」があります。
すぐに理解できるように、これはCarnegie Mellon UniversityとIBM Researchによる非常に素晴らしい研究です。これをご覧ください。これは別のアイデア、非常に似たアイデアです。推論時間について話しています。はい、テスト時間計算でこれを使いましょう。ここで持っている貴重な10、20、30秒で、エージェンシステムで発生する軌道レベルのエラーを検出してコース修正するプロセス報酬モデルを構築できます。
特定のタスクに対してテスト時間計算スケーリングをどのように最適化するかによって、これは使用する別の方法論かもしれません。
そしてもちろん、別の研究もあります。これは2025年9月11日のものです。彼らは言います。出力評価結果だけを見るのは良いことです。効果はどうでしょうか？本当に最短で最良の解決策なのか、それともシステムが10秒間さまよい回って一方向だけを見て、他のすべてを無視していたのでしょうか？
リソース制約下での効果性
小さなモデルを使用している場合、10、20秒ではなく2秒で実行したい場合、リソース制約下でのSWEの効果性はどうでしょうか？効果性を追求する場合の最適化ステップは何でしょうか？
ここに、香港中文大学、キングス・カレッジ・ロンドン、クイーンズ大学があり、多次元メトリックを使用した新しいSWEベンチマークを開発し、非常に興味深い方法で測定される効果性を組み込もうとしています。3番目の研究も見てください。
彼らは、テスト時間計算スケーリングパフォーマンスを最適化したいと言っています。現在私たちがいる場所が分かります。誰もがSWEの改善、高速化、エントロピー正則化項の増加を検討しており、少なくとも5%、場合によっては10%まで、次世代AIエージェントコードシステムのパフォーマンス向上が期待できそうです。
楽しんでいただけたでしょうか。次のビデオでお会いしましょう。
コメント