【要約】SWE-Bench Proから作る3ログ評価ハーネス [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
OpenAIがSWE-Bench Proの監査を行った際、合格率の数値がベンチマーク自体の不備によって歪められていることが判明した。評価指標が実態を反映していない問題は以下の通りである。
- ・OpenAIの監査では、約30%のタスクが「壊れている（broken task）」と判定された。
- ・失敗の原因は、実装を縛りすぎるテストや、要件不足のプロンプト、低カバレッジなテストにある。
- ・単一のpass/fail指標では、モデルの性能向上か、ベンチマークの汚染か、実行環境の変化かを判別できない。
// Approach
評価結果を単一のスコアで管理するのではなく、情報の性質ごとに3つのログに分離して記録する手法を提案している。これにより、失敗の真因を特定する。
- ・Task Contract: 問題文、明示的な要件、テストが求める振る舞い、実装の自由度を定義する。
- ・Execution Trace: 使用モデル、backend（vLLM等）、並列数、リトライ回数、実行時間を記録する。
- ・Grader Reason: 失敗理由を「実装ミス」「要件不足」「テスト過剰」などのラベルで分類する。
// Result
評価ログを構造化することで、モデルの真の性能と評価環境の影響を切り分けて分析可能になる。これにより、以下の効果が期待できる。
- ・「モデルの進化」「テストの不備」「backendの条件変化」を明確に判別できる。
- ・失敗理由をLLMやルールで分類することで、人間によるレビューコストを最適化できる。
- ・実務におけるコーディングエージェントの継続的な改善に向けた、堅牢な評価基盤を構築できる。
Senior Engineer Insight
> スコアの「高さ」を追うフェーズから、評価の「解釈性」を追うフェーズへの転換が必要だ。大規模な開発現場では、モデルの性能向上だけでなく、推論バックエンドの変更や並列化設定が結果を左右する。これらを分離して記録するログ設計は、実験の再現性と信頼性を担保するために不可欠である。単なるベンチマークの実行ではなく、プロダクト運用のログ設計として評価系を捉える視点が、エンジニアリングの質を分ける。