SWE-Serve、実際のサービングテストを導入し、コーディングエージェントの修正における検証ギャップを明らかに

NVIDIAとカリフォルニア大学バークレー校の研究者は9月22日にSWE-Serveの論文を公開し、翌日に技術解説を発表した。このベンチマークは、SGLangでマージ済みの83件のプルリクエストを53タスクに整理したものだ。モデルの統合、デコーディング、キャッシュ、スケジューリング、サービングAPIを対象に、コーディングエージェントに既存のコードベースで複数のコンポーネントにまたがる変更を行わせる。[公式発表](https://developer.nvidia.com/blog/how-swe-serve-exposes-the-gap-between-local-tests-and-live-serving/)

主要な結果は、実際のモデルサービングを起動する19タスクから得られた。研究では、エージェントが生成した同じ627件のパッチを使い、採点時にエンドツーエンドテストを含めるかどうかだけを変更した。すべての検証を実施した場合の合格率は45.9%だったが、サービングテストを除くと69.4%に上昇した。つまり、他のチェックに合格したパッチの約3分の1は、実際のサービング検証には合格できなかった。これはテスト範囲によるスコアの差であり、モデルの能力向上と解釈することはできない。[論文](https://arxiv.org/html/2609.26777v1)

各タスクではまず、変更前のバージョンが新機能のテストには不合格となる一方、回帰テストには合格することを確認し、さらに参照パッチがすべてのチェックに合格することを求める。エージェントが生成したコードは実行時の振る舞いに基づいて採点され、参照実装と同じである必要はない。これにより、個々の関数をチェックするだけでなく、モデルの読み込み、公開インターフェースの応答、リクエスト間で保持される状態などの問題も検出できる。[評価方法](https://research.nvidia.com/benchmarks/swe-serve)

研究ではmini-SWE-agentを使い、11モデルを対象に、モデルと推論設定の31通りの組み合わせを評価した。各組み合わせで全タスクを3回実行し、1タスク当たりの上限は210分、350ステップとした。実行時には公開ネットワークと上流リポジトリへのアクセスを制限し、モデルの重みを取得するために必要な経路は確保した。1回の試行における平均合格率は最高で約75%だったが、これも今回のタスク群とエージェントフレームワークでの結果に限られる。[実験設定](https://arxiv.org/html/2609.26777v1)

再現実験を行う際は、公開されている実行ツールに`--closed-book`を明示的に指定して初めて、リーダーボードと同じネットワーク制限が適用される点に注意が必要だ。省略するとオープンブック形式のテストとなり、同じ条件として扱うことはできない。また、リリースタグによってタスクや検証プログラムが異なる可能性があるため、プロジェクトでは使用するタグを固定することも求めている。[実行手順](https://github.com/NVIDIA/swe-serve)

エンジニアリング上の示唆は、実際の重みの読み込み、リクエストの処理経路、回帰テストで確認する動作を、エージェントが生成した修正の受け入れ検証に含めることだ。ただし、現時点の対象はSGLangと、CPUまたはH100 1基を使う環境に限られ、複数GPUや複数ノードでのデプロイは検証されていない。ベンチマークに合格しても、修正がマージや本番投入の基準を満たしたことにはならない。今後は、他の推論エンジンでの再現実験や、検証プログラムの改訂後も結果が安定しているかを注視する必要がある。研究者も、テストのカバレッジ不足とエージェントの実装ミスを区別し、すべての失敗をモデルの能力に帰することを避けるべきだ。[適用範囲の制約](https://developer.nvidia.com/blog/how-swe-serve-exposes-the-gap-between-local-tests-and-live-serving/)