Databricksの数百万行に及ぶコードベースでのコーディングエージェントのベンチマーク

Databricksでは、エンジニアリングへのAIの積極的な導入により、ソフトウェアの構築方法が急速に変化しています。過去1年で、コーディング支援のためのモデルやフレームワークの選択肢が飛躍的に拡大し、開発者はかつてないほど多くの選択肢を得ています。選択肢が増えるにつれて、実際のコーディングタスクにおいてどのコーディングエージェントが最高のパフォーマンスを発揮するか、またタスクパフォーマンスが価格によってどのように変動するかを理解することがますます重要になっています。 この記事では、Databricksのコードベースでエンジニアが実際に行ったコーディングタスクを評価する、社内で構築した内部コーディングベンチマークの結果と方法論を共有します。タスクには、Python、Go、Typescript、Scalaなど、多くの人気言語をカバーする数百万行のコードベースに対する編集が含まれており、タスクとソリューションの両方が正確性を期すために慎重にレビューされました。これは網羅的なものではありませんが、この取り組みにより、コーディングエージェントを使用してエンジニアリングチームの効率が大幅に向上する洞察が得られました。以下に、モデルとフレームワークが全体ベンチマークでどのようにスコアリングされたかを示します。 図1: ベンチマークにおけるコスト対パフォーマンス 私たちの分析から得られた主な結論は以下の通りです。 コーディングタスクにおけるパレートフロンティア（つまり、特定のコストで最高の品質）には、OpenAI、Anthropic、およびオープンソースのモデルが含まれます。これは、今日、ツールの組み合わせのみがフロンティアパフォーマンスを提供できることを意味します。 オープンモデル、特にGLM 5.2は、現在、最も高いレベルのタスク難易度にも対応できます。 モデルのトークン価格は、エンドツーエンドタスクで発生する実際のコストの乏しい指標です。より大きなモデルは、トークン効率がはるかに高く、全体的なコストが低くなる可能性があります。 モデルが呼び出されるフレームワークは、コストと品質に劇的な影響を与えます。多くの場合、Piのようなシンプルなフレームワークが私たちのワークロードで最良のパフォーマンスを発揮しました。 それぞれについてもう少し詳しく見ていきましょう。 モデルは「能力ティア」に大まかにクラスター化されます 特定のポイントのずれは、実際のタスクではしばしば相殺されることがあります。私たちは、さまざまなタスクに使用するモデルを推論するのに役立つテーマ的なパターンにより焦点を当てました。実際、結果は、モデルとフレームワークが3つの能力ティアに明確にクラスター化されていることを示しました。 図2: 全体的な結果で3つの明確な能力ティアが出現し、各グループで効果的なモデルにニュアンスがありました パフォーマンスの最上位では、最も知的なモデルがすべての種類の問題を解決するのに非常に効果的ですが、非常に高価であることがわかります。中程度およびそれ以下の知能を持つモデルは、一般的なタスクに対して依然として非常に効果的であり、多くの場合、それらは大幅に安価でもあります。日々の業務では、エンジニアは複雑さが大きく異なるさまざまなことを行います。フラグを切り替えたり、設定を更新したりする一般的な運用タスクには、極端に知的なモデルは必要ありませんが、より深い設計探求には必要です。しかし、過去には、私たちのデフォルトモデルは常に最も高価なものでした。この分析に基づき、HaikuおよびGPT 5.4 Miniクラスのモデルに、より多くの作業を移行すべきだと判断しました。 コーディングのためのオープンモデルが登場しました GLM 5.2については多くの興奮があり、私たちの結果は、GLMが多くの開発者にとって日常的なドライバーモデルになり得る証拠を示しました。それはトップの能力ティアに位置し、品質においてOpus 4.8と統計的に同等でしたが、Opusの1.94ドルに対してタスクあたり1.28ドルでした。 GLMの品質スコアは、日常的な開発でGLMをパイロット運用している社内開発者から得られた定性的なフィードバックと一致しています。日常的なコーディングタスクにおけるその優れたパフォーマンスのため、私たちはGLMを最高のパフォーマンスで提供することに焦点を当てており、証拠は、コーディングのための日常的なドライバーとしてこれらを展開し始める時期が来ていることを示しています。 タスクあたりの価格対トークンあたりの価格 開発者は、コーディングタスクを完了する際のモデルのコストを判断するために、しばしばトークンコストを概算します。しかし、モデル間の推論効率のばらつきのため、トークンコストは全体的なタスクコストの乏しい指標であることが多いことがわかりました。これは、タスクの形状と複雑さがコンテキストによって異なる可能性があるため、タスクレベルのベンチマークの必要性を強調しています。 例として、Sonnet 5はOpus 4.8よりもトークンあたり約1.7倍安価ですが、私たちのタスクでは、Sonnetはタスクあたり2.09ドル、Opusは1.94ドルであり、タスク完了率では6ポイント低い（81%対87%）スコアでした。これは主に、Sonnet 5がより長く動作し、より多くを読み取る必要があったためで、トークン消費量は1.9倍でした。 フレームワークは効率に大きな影響を与えます 同じモデルを同じ思考努力で2つの異なるフレームワーク（Claude Code/Codex対Pi）で実行したところ、タスクあたりのコストは大幅に異なりました（場合によっては2倍以上）。品質は同じままでした。主な違いは、各ターンで各フレームワークがモデルにどれだけのコンテキストを供給したかという点にありました。 Piは、ターンあたり約3分の1のコンテキストを送信しました。コンテキストをより良く管理し、よりタイトな作業セットを維持し、より少ない実行でタスクを完了しました。 ここでの教訓は、あるフレームワークが常に安いということでも、ネイティブフレームワークが劣っているということでもありません。むしろ、モデルの選択はパズルの1つのピースにすぎません。この柔軟性を確立することが、モードとフレームワークのスワップをシームレスにするためにOmnigentに投資した理由です。 独自のベンチマークを構築する理由 SWE-BenchやTerminalBenchのような公開ベンチマークは有用ですが、私たちの疑問に答えることはできませんでした。これにはいくつかの理由があります。 タスクは公開されているため、時間の経過とともにソリューションがトレーニングデータに漏洩します。 私たちのコードベースは、Scala、Go、Rust、Java、Python、Bazel、Protobufなど、10以上の言語と多くのサービスにまたがっており、結果が代表的ではないことがわかりました。 独自のPRでベンチマークを構築することにより、開発者を妨げることなく最適化を展開できるという高い確信を持ってこれらの決定を下すことができます。 ベンチマークの構築方法 Unity AI Gatewayを使用して、すべてのコーディングインタラクションのログをキャプチャしました。これにより、コーディングエージェントを使用してエンジニアが取り組むタスクの複雑さを分析することができました。タスクの複雑さには大きな多様性があり、約4分の1が低複雑度の作業としてタグ付けされ、約60%が中程度の複雑度でした。 しかし、高価なモデルはエンジニアが使用するデフォルトのモデルであるため、効率を改善する大きな機会が明らかにありました。 タスクの構築 私たちのエンジニアは1日に数千件のコード変更をマージするため、すでに構築のための優れたデータセットがあります。優れたプルリクエストは、開発者からのイテレーションを示すコミット、人間によるレビュー、およびコード変更が意図に忠実であることを検証するのに役立つテストを備えた、豊富な成果物です。しかし、高品質なベンチマークを構築するために、いくつかの品質チェックとフィルターが必要でした。 新しさ: 現在使用されているフレームワーク、パターン、および規約を含む、今日の構築方法を反映するように、最近の履歴からプルします。 人間による作成: ボットコミット、サービスアカウント、完全にAI生成された変更、および自動生成された変更はフィルタリングされました。 関連する高品質なテストスイート: コード変更を検証するための高品質なテストが含まれているPRをフィルタリングしました。 自己完結型: 変更はいくつかのモジュールに限定されていました。 典型的なタスクの代表性: フルスタック全体（Scalaバックエンドサービス、Rustシステムコード、ReactおよびTypeScriptフロントエンド、ProtobufおよびgRPCコントラクト、Bazel設定）にわたるタスクの分布からPRを選択しました。 候補となるPRを取得したら、よく指定されたタスクを構築することに焦点を当てました。 意図を読み取り、それをプロンプトとして要約します。PRを読んで、それが実際は何のためであったかを理解し、望ましい結果を記述しました。通常、これは問題または目標を述べ、制約を名前で指定し、ソリューションの説明を削除することによってPRの説明を書き直すことを意味しました。たとえば、バグ修正が正しい理由の説明を削除することが重要です。それはタスクを簡単すぎるものにするからです。 関連するテストを分割します。非テストファイルは、モデルが独自に再現する必要のある変更であったため、テストファイルを脇に置き、コンパイルできることを確認しました。私たちのビルドシステムはすでにどの