本文にスキップ
AI News HubLIVE
サイト内リライト2 分で読了

コーディングエージェントが実際に行動するために必要なコンテキストは何か?

記事の要約

新しい研究によると、コーディングエージェントがコード編集時に本当に必要なコンテキストは最小限であり、信号は編集対象のコード自体にのみ存在する。自然言語要約はソースコードが答える行動質問にほとんど答えられず、周囲のコンテキスト(UMLスケルトン)は削除と同等で、圧縮コンテキストは三分の一のトークンで完全なファイルと同等の性能を示す。温度0推論では約9%の結果が変動し、ノイズフロアとなる。著者らは検証済み環境、決定論的パッチ、事前登録済み仮説を含むツールを公開している。

ソースarXiv Machine Learning著者: Brian Sam-Bodden
コーディングエージェントが実際に行動するために必要なコンテキストは何か?
誤りを報告

訂正窓口はまだ利用できません。記事情報をコピーして保存できます。

訂正案内
本文へ

現代のコーディングエージェントはリポジトリ全体をコンテキストウィンドウに収めることができるが、その読み取りの大半は無駄である。Brian Sam-Bodden氏がarXivに提出した新しい研究(論文番号2607.09691)では、エージェントがコードを編集する際に実際にどの程度のコンテキストが必要かを調査している。研究者らは「発見」と「行動」を分離し、発見部分をオラクルで固定してコードの表現のみを変え、SWE-bench Verified上で実際の問題解決能力を評価した。

結果は驚くほど最小限であった。本当に必要な信号は編集対象のコードそのものに存在する。自然言語による要約は、ソースコードが答えられる行動質問のほとんどに答えられない(4/45対27/45、独立した評価者による)。この差は要約器ではなく表現に起因しており、フロンティアモデルの要約でも3Bモデルと同様に低いスコアだった。周囲のコンテキストもほとんど重要ではない。すべてのマルチファイルインスタンスにおいて、ファイルの残り部分をUMLスケルトンとシグネチャで表現しても、完全に削除した場合と比べて解決される問題の数に有意差はなかった(N=70、マクネマー検定p=0.75)。これは事前登録された仮説であり、棄却された。

一方、圧縮コンテキスト(クラスシグネチャやインターフェースなど)は、トークン数が三分の一で完全なファイルと同等のパフォーマンスを達成した。解決された問題あたりの平均コンテキストトークン数は19Kであり、94Kではない。さらに、温度0のAPI推論は、バイト単位で同一の実行間で約9%の結果を変動させることが判明した。これはSWE-bench上で報告されるすべての小効果に対するノイズフロアとなる。

研究者らは、ゴールドバリデーションされた環境、各インスタンスで参照編集がすべてのアームのコンテキストから表現可能であることの証明、決定論的パッチ構築、および帰無仮説を公開した事前登録仮説を含むツールを公開している。これらの成果は、コーディングエージェントの能力をより正確に評価し、コンテキスト使用を最適化して推論コストを削減するのに役立つ。

要点と分析を開く

記事インテリジェンス

エンジニア上級

要点

  • 編集に必要な信号は編集対象のコード自体にのみ存在し、自然言語要約はソースコードが答えられる行動質問のほとんどに答えられない(要約器の規模によらず)。
  • 周囲のコンテキストをUMLスケルトンで表現しても、削除と比べて解決される問題数に差はない(N=70, p=0.75)。
  • 圧縮コンテキスト(クラスシグネチャ、インターフェース)は三分の一のトークンで完全なファイルと同等の性能(解決問題あたり19K vs 94Kトークン)。
  • 温度0のAPI推論は同一実行間で約9%の結果を変動させ、SWE-bench上の小効果検出にノイズフロアをもたらす。

要点と分析は自動生成され、誤りを含む場合があります。原典をご確認ください。