科学コードエージェントに実行可能な検査を与える

導入

科学計算向けのコーディングエージェントは、単にプログラムを書く以上の仕事を求められます。方程式、境界条件、数値計算上の制約、出力形式を読み取り、修正したコードが要件を満たすかまで判断しなければなりません。従来はこうした規則を自然言語で提示し、モデル自身に理解と検証を任せることが一般的でした。Rules to Toolsは、公開された科学要件を呼び出し可能な実行チェックとして実装し、修復ループに組み込む方法を検討しています。

主なポイント

• 比較条件をそろえてツールの効果を測定。 SciCodeの修復タスクでは、両グループに同じ文章のチェック、開始プログラム、モデル、予算を与えます。ツール条件だけが、要件の実装を呼び出せます。
• 平均値は改善したが、普遍的な優位ではない。 2つのタスクIDコホートでは、完全修復はテキスト条件が26/30、ツール条件が29/30でした。8つのIDを含むコホートでは13/16対15/16です。ただし、タスク単位のクラスターブートストラップによる差の95%区間は-12.5から43.75ポイントで、標本規模を考えると不確実性が残ります。
• タスクごとの差が大きい。 3つのタスクIDはツール条件、1つはテキスト条件を支持し、11個は同率でした。共有定義を使う大規模コホートでは両条件が13/24です。別の開始プログラムを使った5つの開発露出タスクでは、テキスト条件が3/10、ツール条件が7/10でした。
• チェックは自動的な正解ではない。 初期チェックはタスク17を違反として検出し、タスク77と11では違反なしと報告しました。タスク37はテキスト条件が優位で、初期の違反報告はありません。検査の網羅性、正確性、診断能力が結果を左右することが分かります。
• モデル出力の削減と総資源の削減は別問題。 PDEの比較では、詳細なテキスト条件が23/24、チェック条件が24/24で、報告されたモデル出力はチェック条件で31.2%少なくなりました。しかし、2つのタスクIDコホートでは公開CPU使用量がともに増加し、出力削減の大きさもコホートにより異なります。ソースコードをPython経由で扱う別条件も15/16に達し、専用コマンドと同じ集計結果でした。

意義と影響

この研究は、科学エージェントの検証を「規則をどうツールチェーンに取り込むか」という設計問題として捉え直します。境界条件や数値要件を信頼できるチェックに変換できれば、エージェントは長い説明文だけに頼らず、プログラムの違反に関する具体的なフィードバックを得られます。数値コードの修正では、モデルによる説明や再生成の回数を減らせる可能性があります。

ただし、実行チェックは無条件の性能向上ではありません。チェックには作成、保守、独立検証が必要です。実装範囲が狭ければ失敗を見逃し、不完全な診断はエージェントを誤誘導する可能性があります。実用システムでは、自然言語仕様、実行チェック、独立テストを組み合わせ、修復率だけでなくモデル出力、CPU使用量、チェック作成コストまで評価する必要があります。

Rules to Toolsが示すのは、エージェントが規則を「読む」だけでなく「呼び出す」方向への移行です。一方で、その価値はタスクの性質、チェックの品質、そして資源全体の計測に依存します。

出典：Hugging Face Daily Papers