Cursorにおけるモデル品質の比較方法

Cursorは、コードエージェントが複数のファイル、ツール、ステップにわたる長く複雑なタスクを処理するのを支援する企業です。タスクの範囲が広がるにつれて、エージェントのパフォーマンスを測定する評価も進化する必要があります。そこでCursorは、モデル品質の理解を実際の開発者体験と一致させるために、ハイブリッドなオンライン・オフライン評価プロセスを採用しています。

オフライン評価の中心はCursorBenchです。これはCursorのエンジニアリングチームによる実際のCursorセッションに基づいた内部評価スイートです。多くの公開ベンチマークとは異なり、タスクは公開リポジトリではなく実際の使用から来ているため、CursorBenchはモデル間の区別が優れており、実際の開発者アウトカムとよりよく整合します。CursorBenchはソリューションの正確性、コード品質、効率、インタラクション行動など複数の次元を測定します。このブログではソリューションの正確性に焦点を当てていますが、実際にはこれらすべての軸で評価を行っています。

公開ベンチマークには3つの大きな限界があります。第一にアライメントの問題：開発者がエージェントでますます複雑で多様な作業を行うようになる中、静的または誤ったアライメントのベンチマークは全く異なるものをテストしてしまいます。例えば、ほとんどのSWEベンチマークは依然としてバグ修正タスクに焦点を当てており、Terminal-Benchはパズル的なタスクを重視しています。これらは開発者がエージェントに行わせる実際のコーディング作業とは整合していません。第二に採点の問題：多くの公開ベンチマークは正解のセットが狭いと仮定していますが、ほとんどの開発者リクエストは未指定であり、多くの有効なアプローチを許容します。その結果、ベンチマークは代替の正しいアプローチをペナルティするか、未指定を除去するために合成要件を追加します。どちらも真のパフォーマンスの正確な評価を提供しません。第三にデータ汚染：SWE-bench Verified、Pro、Multilingualなどのベンチマークは公開リポジトリからタスクを引っ張ってきており、それらはモデルの訓練データに含まれることが多く、スコアを水増しします。OpenAIは最近、最先端モデルがゴールドパッチを記憶から再現でき、未解決問題の約60%に欠陥テストがあったことを発見した後、SWE-bench Verifiedの結果報告を停止しました。これらの問題の結果、最先端レベルでは、これらのベンチマークは開発者にとって非常に異なる有用性を持つモデルを区別できなくなっています。

これらの問題に対処するため、CursorはCursorBenchを構築しました。Cursor Blameツールを使用して、コミットされたコードを生成したエージェントリクエストにトレースバックし、開発者クエリと正解ソリューションの自然なペアを提供します。多くのタスクは内部コードベースと管理されたソースから来ており、モデルが訓練で見たリスクを低減します。数ヶ月ごとにスイートをリフレッシュし、開発者のエージェント使用パターンの変化を追跡します。初期バージョンから現在のCursorBench-3まで、問題の範囲（コード行数と平均ファイル数で測定）は約2倍になりました。CursorBench-3のタスクはSWE-bench Verified、Pro、Multilingualよりもかなり多くのコード行を含みます。CursorBenchのタスク説明は意図的に短く、開発者がエージェントと話す際の曖昧さを模倣し、エージェント採点者を使用して信頼性高くスコアリングします。

CursorBenchはモデルの分離において優れています。公開ベンチマークが飽和しつつある最先端レベルでも、CursorBenchはモデル間に有意な差を示し、例えばHaikuは場合によってはGPT-5に匹敵または凌駕します。さらに、CursorBenchのランキングはオンライン評価指標とよく一致します。オンライン評価は、エージェントアウトカムの高レベルプロキシ（インタラクションと出力品質の両方を含む）を追跡し、単一の指標に最適化するのではなく一貫した動きを探します。制御されたオンライン実験により、オフライン採点では良好でも実際には開発者にとってうまく機能しない回帰を特定できます。

将来、CursorBench-3のタスクは公開ベンチマークより長いものの、まだ単一セッション内で解決できます。Cursorは来年中に開発作業の大部分が長時間実行されるエージェントに移行すると予想しており、それに応じてCursorBenchを適応させる計画です。そのためには、採点コストの削減、外部サービスと相互作用するタスクの再現性の解決、オフライン評価と開発者体験のギャップを埋める必要があります。オンライン・オフラインのループは正しい基盤を提供しており、今後も構築を続けるにつれて共有していく予定です。