ベンチマーク ≠ 生産性 · ギャップは測定可能
SWE-Bench のスコアは良く見えるが、実タスクはしばしば失敗する
リーダーボードに騙されないで
汚染、過学習、古いリポジトリ、統合テスト欠如……これらのギャップを理解して、自社コードベースで信頼できる評価を構築しましょう。
高スコアモデルが実プロジェクトで失敗する理由
SWE-Bench のタスクは主に公開された古いリポジトリから来ており、モデルが既に見ている可能性があります。実コードベースにはプライベートドメイン知識、複雑なビルド、サービス間統合があり、ベンチマークには含まれていません。
具体的なギャップの原因
ベンチマーク汚染、古いリポジトリ、長いホライズンタスクでの失敗、統合テストや本番環境特有の制約の欠如。これらを認識することが第一歩です。
自社リポジトリ用の評価を構築する方法
実際の issue や PR 記述をタスクとして使い、成功率・平均イテレーション数・人間介入回数・回帰バグ導入数を記録。内部で比較可能なデータを作ります。
QCode 上での多モデル A/B テスト
同じタスクを異なるモデルで実行し、結果を比較。統一キーにより素早い切り替えが可能で、ダッシュボードで使用量と結果を追跡できます。
QCode で本物のベンチマークを構築
自社リポジトリの実 issue や PR 記述を QCode 上で実行し、成功率、平均トークン、人間介入回数を記録。内部比較可能なデータを作成します。
SWE-Bench 現実 FAQ
リーダーボードのスコアは全く役に立たないのですか？
「相対的能力」のシグナルとして参考値はあります。ただし、自社リポジトリで小規模 A/B を実行して初めて実効性がわかります。
どのような指標を測定すべきですか？
タスク完了率、平均イテレーション数、人間レビュー時間、導入された回帰バグ数、最終コードの保守性スコア。
Terminal-Bench は SWE-Bench より信頼性が高いですか？
ターミナルエージェント能力に重点を置いており、有用な補完です。ただし過学習リスクは依然としてあり、実価値は自社検証が必要です。
QCode は測定にどのように役立ちますか？
統一キーにより同じタスクを複数モデルで素早く切り替えて実行できます。ダッシュボードは追跡可能な使用量と結果を提供し、継続的な追跡と改善を支援します。