SWE-bench Scienceが示す、科学ソフトウェア修復の難しさ

導入

通常のソフトウェアでは、バグ修正の目標はプログラムを期待どおり動かすことです。しかし科学分野では、コードそのものが測定装置、シミュレーション、解析パイプラインの一部になる場合があります。小さな実装ミスが計算結果を変え、最終的には実験の証拠や科学的結論に影響する可能性があります。SWE-bench Scienceは、単にパッチを生成できるかではなく、修正後も科学的な意味を維持できるかを問うために設計されました。

ベンチマークの構成

このベンチマークは、20の科学分野にまたがる98のGitHubリポジトリから119タスクを集めています。タスクは次の3種類に分けられます。

• 問題起点型：報告された不具合やエラーを再現し、修正する。
• 専門家探索型：分野知識を使い、潜在的な科学・アルゴリズム上の問題を調査する。
• エンジニアリング統合型：修正を複数モジュール、インターフェース、ワークフローに正しく組み込む。

この設計は、公開テストが通るかだけを見る評価とは異なります。論文によれば、報告された最高性能のClaude CodeとOpus-5（max）でもPass@1は50%未満でした。科学ソフトウェアの自動修復は、通常のデバッグよりはるかに難しいことが分かります。

繰り返し現れる4つの失敗

研究では失敗を4つに整理しています。第一は、科学知識の不足、または問題に対する抽象化の誤りです。エージェントが文法や局所的な処理を理解していても、物理・数学・方法論上の制約を捉えられないことがあります。第二は、探索の方向を誤ることや表面的な修正です。目立つ症状だけを変え、根本原因を残してしまいます。

第三は、修正範囲の不足やシステム統合の失敗です。局所的な変更が正しそうに見えても、関連する処理経路や下流の前提が壊れたままになる場合があります。第四は、観測した例から得た知識を、未知の入力や境界条件へ一般化できないことです。

プロジェクトの説明によれば、評価にはエージェントから隠された専用のプライベートテストも使われます。検証器は新しいワークスペースに提出パッチを適用し、科学的な振る舞いの契約を確認します。そのため、公開されたアサーションを編集したり、見えている出力をハードコードしたりしても、最終的な評価を通過できません。プロジェクト側は、Qwen3.8-27Bが119件の公開再現テストをすべて通過した一方、プライベート評価で完全なPass@1に到達したのは35件だったと説明しています。

科学知識は常に有効とは限らない

さらに、リポジトリと実行可能な開発環境を維持したまま、明示的な科学ガイダンスを取り除く比較実験も行われました。結果は単純ではありません。正確でタスクに合った知識は探索範囲を絞り、平均性能とトークン効率を改善します。しかし、問題と合わない説明は誤った解釈にエージェントを固定し、修復を悪化させる可能性があります。

意義

SWE-bench Scienceは、評価の焦点を「実行可能なパッチを作れるか」から「複雑なコードベースで科学的意味を維持できるか」へ移します。今後の研究では、分野推論、統合検証、未知条件への一般化、不確実性の提示が重要になります。Pass@1は能力の一側面にすぎず、科学的結論の確認を専門家に代替するものではありません。

信頼できる研究用コーディングエージェントには、テストを緑にするだけでなく、計算の意味を守り、仮定と適用範囲を明示する能力が求められます。

出典：Hugging Face Daily Papers