GPT-5.5 low vs medium vs high vs xhigh: オープンソースリポジトリの実作業26件で見た推論カーブ

 (reddit.com)
5 ポイント 投稿者 GN⁺ 8 시간 전 | 1件のコメント | WhatsAppで共有
  • GPT-5.5 CodexをGraphQL-go-toolsの実作業26件でlow、medium、high、xhigh設定にして実行したところ、テスト通過よりも人間のパッチとの意味的同等性やコードレビュー通過率で推論努力の差がより大きく表れた
  • テスト通過はlow 21/26、medium 21/26、high 25/26、xhigh 24/26だったが、意味的同等性は4/26 → 11/26 → 18/26 → 23/26へ増加し、コードレビュー通過も3/26 → 5/26 → 10/26 → 18/26へ上昇した
  • highはmedium比でテスト通過、同等性、レビュー通過をすべて改善しつつ、平均コストは$3.13から$4.49へ1.43倍の増加にとどまり、このデータセットでは最も実用的なデフォルト設定に見える
  • xhighはhighより同等性とレビュー品質を大きく高めた一方、平均コストは$9.77、平均実行時間は753.3秒に増え、さらに多くのテスト・fixture・expected-output変更まで生み出してフットプリントリスクも増加した
  • 推論努力の効果はタスクごとに単調ではなく、highがxhighを上回ることもあれば、高い設定がもっともらしいが誤った実装を作ることもあり、チームはグローバルなベンチマークではなく自前のハーネスと自前のタスクで測定すべきだ

実験の目的と評価方法

  • GPT-5.5 Codexを同じオープンソースリポジトリの26件の作業に対してlow、medium、high、xhighの推論努力設定でそれぞれ実行し、テスト通過だけでなく、人間がマージしたPRとの意味的同等性やレビュー可能性も比較した
  • 対象リポジトリはGoベースのGraphQL-go-toolsで、各タスクは実際にマージされたPRまたはコミットから派生している
  • 各タスクは、固定されたリポジトリスナップショット、変更要求プロンプト、Dockerコンテナ内でパッチを生成する1回の試行で構成される
  • Stetは生成されたパッチを適用し、隔離されたコンテナでタスク別テストを実行して通過可否を確認する
  • テスト後は次の基準で追加評価した
    • 同等性: 候補パッチが元の人間作成パッチと同じ動作変更を達成しているか
    • コードレビュー通過: 正確性、バグ混入リスク、保守性、エッジケースを考慮したときにレビュー担当者が受け入れられるか
    • フットプリントリスク: 人間作成パッチと比べて、エージェントが追加でどれだけ多くのコードを触ったか
    • 作り込み/規律ルーブリック: 明確さ、単純さ、一貫性、意図性、堅牢性、指示順守、スコープ規律、diff最小性を評価する
  • すべてのモデルはタスクごとに1回、単一シードで実行された
  • LLM判定モデルはGPT-5.4で、判定者はパッチとタスクだけを見て、どのモデル・推論設定が作ったパッチかは見ていない
  • 代表例は手動でも確認したが、このタスクセットに対する別途の人手補正はなく、単一の絶対スコアよりも増減の方向を信頼すべきだ
  • 実行の詳細
    • モデル: GPT-5.5
    • ハーネス(harness): Codex 0.128.0
    • データセット: 実際のGraphQL-go-toolsタスク26件
    • 主要指標: テスト通過、意味的同等性、コードレビュー通過、フットプリントリスク、作り込み/規律のカスタム評価、コストと実行時間
  • インタラクティブなチャートとタスク別の詳細分析はhttps://stet.sh/blog/gpt-55-codex-graphql-reasoning-curveにある
  • AGENTS.mdを改善する自動研究ループにも同じ評価を使っている
    • エージェントがリポジトリ向けのAGENTS.md改善案を作り、Stetで過去タスクを実行したうえで、どこで良くなったか悪くなったかを見つけて反復する

全体指標と解釈

  • 全体指標では、推論努力が高まるほどテスト通過よりも意味的同等性とレビュー通過率でより大きな差が見られた
  • 主要結果
    • テスト通過: low 21/26、medium 21/26、high 25/26、xhigh 24/26
    • 人間パッチとの同等: low 4/26、medium 11/26、high 18/26、xhigh 23/26
    • コードレビュー通過: low 3/26、medium 5/26、high 10/26、xhigh 18/26
    • 作り込み/規律平均: low 2.311、medium 2.604、high 2.736、xhigh 3.071
    • 平均タスクコスト: low $2.65、medium $3.13、high $4.49、xhigh $9.77
    • 平均エージェント実行時間: low 286.9秒、medium 411.0秒、high 579.0秒、xhigh 753.3秒
  • lowとmediumはテスト通過がどちらも21/26で同じだが、同等性は4/26から11/26へ上がり、レビュー通過は3/26から5/26へ上がった
  • highはmedium比でテスト通過が+15.4%p、同等性が+26.9%p、レビュー通過が+19.2%p増加し、実用的な改善幅が最もはっきりしている
  • xhighはhigh比でテスト通過が-3.8%p低い一方、同等性は+19.2%p、レビュー通過は+30.8%p増加した
  • 推論努力は単にテスト通過率だけを変えるのではなく、Codexが作るパッチの種類を変えることが示された
  • 公開ベンチマークは多くの場合、タスク成功の可否という二値的な答えを返すが、実際のソフトウェアエンジニアリングでは、そのパッチをマージして後から保守できるかも重要だ
  • Terminal-Benchは主に難解なコーディング問題が中心で、SWE-bench verifiedはモデルがすでに答えを含んでいた可能性があり、SWE-bench Proは有用だが一般性が強い
  • この実験の関心は「エージェントが自分のコードベースで人間がマージしたものと同種の変更を行ったか」と「このパッチをその後も所有したいと思えるか」にある

lowからmediumへ: ヒューリスティックからドメインモデリングへ移行

  • lowとmediumはテスト通過がどちらも21/26で同じなので、テストだけを見れば引き分けのように見える
  • しかしmediumでは意味的同等性が4/26から11/26へ上がり、作り込み/規律平均も2.311から2.604へ上昇した
  • この区間では、テストだけを測ると推論努力の差の大半を見落としてしまう
  • lowは通過するパッチでもヒューリスティックや部分実装にとどまるケースがあり、mediumはリポジトリとドメインの意味をよりよくモデル化する方向へ変わる
  • PR #1297の例
    • GraphQL Federationでnullableなexternal @requires依存関係を検証する作業である
    • nullableなrequiredフィールドがエラーとともにnullで返ってきた場合、その汚染されたエンティティを依存するdownstream fetchに渡してはいけない
    • 作業の本質は単純な検証分岐の追加ではなく、微妙なfederationデータ依存ルールをモデル化することにある
    • lowはテストを通過したが、required-field/errorマッチングをヒューリスティックに処理し、構造化されたnullable @requiresメタデータを見落としていたため、同等ではなくレビューも通過しなかった
    • mediumは汚染されたオブジェクトを追跡し、downstream fetch入力をフィルタリングして同等性とレビューを通過し、作り込み/規律の品質は1.350から3.225へ上がった
    • highとxhighも同じ品質帯にとどまったため、このタスクは主にlowからmediumへ移る際の改善を示している

high: 実用的なデフォルトに近い地点

  • highはmediumよりテスト通過、意味的同等性、レビュー通過をすべて改善しつつ、コスト増加は大きいものの過度ではない水準にとどまる
  • highとmediumの比較
    • テスト通過: 21/26から25/26に増加
    • 同等性: 11/26から18/26に増加
    • コードレビュー通過: 5/26から10/26に増加
    • 平均フットプリントリスク: 0.268から0.314に増加
    • 制作/規律の平均: 2.604から2.736に増加
    • 平均タスクコスト: $3.13から$4.49に増加、1.43倍
    • 平均実行時間: 411.0秒から579.0秒に増加
  • highは、追加トークンが実際の利益に変換される地点のように見え、統合の細部を正確に押さえる比率がより高くなる
  • PR #1209 の例
    • gRPC datasourceがレスポンスJSONでGraphQL aliasを尊重し、参照されたprotobuf message typeを事前に検証し、union/interface mutationパスのマッピングカバレッジを更新する必要がある作業である
    • lowとmediumはいずれもテストには通過したが、同等ではなくレビューも失敗した
    • mediumはaliasのシリアライズと欠落したmessage検証をかなり処理したが、createUser mutationマッピングの更新を見落とし、JSONPathにresponse-keyの意味を過剰に持ち込んだ
    • highは明示的なresponse-key/alias処理を導入し、planningとJSON marshaling全体にaliasを渡して、最初の厳格通過となった
    • highのカスタム品質は3.625に上がり、単にコードを増やしたのではなく、統合上の義務を正確に満たした
    • xhighも通過したが、タスクレベルの解釈を改善はせず、再生成された要約基準ではエージェント実行時間がhighの314.0sより長い790.7sだった
  • PR #1155 の例
    • repeated scalar fieldのサポート、null/invalid message panicの回避、gRPC status codeの伝播、datasourceの無効化、dynamic clientのサポートを含むgRPC datasourceの堅牢化作業である
    • lowとmediumはテストには通過したが、同等ではない
    • mediumは堅牢性を改善したが、invalid repeated fieldをempty arrayとしてシリアライズし、aliased-root planning動作を見落とし、dynamic-clientのライフサイクルリスクが残った
    • highはより安全なnil/invalid処理、status-codeの伝播、disabled-datasource動作、dynamic client-providerのカバレッジによって同等性とレビューを通過した
    • この作業ではxhighがテストには通過したものの、disabled datasourceの意味とinvalid-list動作を誤って処理し、同等ではなくレビューも失敗する逆転が起きた

xhigh: デフォルトというより品質モードに近い

  • xhighはhighより意味的・レビュー品質を高めたが、単純に設定を上げればすべてが良くなるという形ではない
  • xhighとhighの比較
    • テスト通過: 25/26から24/26に減少
    • 同等性: 18/26から23/26に増加
    • コードレビュー通過: 10/26から18/26に増加
    • 平均フットプリントリスク: 0.314から0.365に増加
    • 制作/規律の平均: 2.736から3.071に増加
    • 平均タスクコスト: $4.49から$9.77に増加、2.18倍
    • 平均実行時間: 579.0秒から753.3秒に増加
  • xhighはより多くの基盤をカバーし、人間の意図によく合い、より完全な変更を作る傾向があるが、はるかに多くのトークンを使う
  • レビュールーブリックではxhighの平均は3.365、中央値は3.500で、highの平均2.817、中央値2.750より高い
  • 中央値も平均より高く、xhighの改善が一つ二つの突出したパッチだけで平均を押し上げた結果には見えない
  • xhighは意味的にはより完全だが、人間が作ったパッチに比べてより多くのコードに手を入れるため、フットプリントリスクも増加する
  • xhighが26件のタスクで追加した行数は合計13,144行で、実装コード5,918行とテスト・fixture・expected-output 7,226行に分かれる
  • highと比べてxhighが追加した行数は2,631行多く、そのうち2,436行はテスト・fixture・expected-outputファイルにある
  • フットプリントの増加は巨大なproduction codeを書いたためだけではなく、xhighが検証とfixtureのカバレッジをより多く作成した影響も大きい
  • ただし、テストやfixture、expected-outputの変更も、レビューと保守が必要な実際の表面積である
  • PR #1076 の例
    • subscription処理を再構成して共有mutex race conditionを避ける作業である
    • 要件には、subscriptionごとの直列化されたwrite、subscriptionごとのheartbeat制御、race detectorカバレッジ、WebSocket close semanticsの修正が含まれる
    • mediumはテストを通過したが、同等ではなくレビューも失敗した
    • highは同等性と指示順守を達成したが、新しいworker queueがグローバルなsubscription event loopを塞ぐ可能性があり、shutdownが停止したworkerの背後で止まる可能性があり、hung updateが無制限で、client-level unsubscribeが依然としてinternal subscriptionをスキップするため、レビューに失敗した
    • xhighが最初の厳格通過で、カスタム品質を3.475に引き上げた
    • この作業は、並行処理負荷の高いタスクにおいてxhighがレビューリスクの整理に対価を払う品質モードとして機能した最良の例である
  • PR #1308 の例
    • GraphQL @oneOf input objectを実装する作業である
    • built-in directiveの追加、introspectionでの公開、operation literalとruntime variableの検証、undefined-variable source locationの改善が必要である
    • mediumとhighはテストには通過したが、runtime variable、nullable variable、provided-null payload、introspection shapeに関する重要な@oneOfの意味を見落とし、同等ではなくレビューも失敗した
    • xhighが最初の厳格通過で、堅牢性3.7、指示順守4.0、カスタム品質3.525を記録した
    • 違いは表面的な磨き込みではなく、複数のシステム部分にまたがるエッジケースのカバレッジにある
  • PR #1240 の例
    • GraphQL ASTのfield-selection mergingとinline-fragment selection mergingを1つのnormalization walkに統合する作業である
    • lowとhighは厳格通過だった
    • xhighは意味評価基準では同等だったが、prioritized subpassを維持し、AbstractFieldNormalizerの順序を変え、古いfield-merge registrationを残したため、レビューに失敗した
    • より高い推論設定でも、より精巧でもっともらしいリファクタリングを生み出しつつ、テストやレビュアーが重視する正確な実行動作を見落とすことがある

制作・規律、コスト、限界と結論

  • 制作・規律のカスタム評価も、レビュー・ルーブリックと同様に推論努力が増えるほど全体的に上昇した
  • all-customスコアは xhigh の平均 3.071、中央値 3.087 で、high の平均 2.736、中央値 2.688 より高い
  • 制作と規律はいずれも中央値も高く、xhigh は一部の突出した例だけを生み出したのではなく、全体的なパッチ品質を高めたと解釈できる
  • 平均値・中央値指標
    • Craft aggregate: low 2.327 / 2.338、medium 2.618 / 2.525、high 2.781 / 2.787、xhigh 3.126 / 3.100
    • Discipline aggregate: low 2.295 / 2.325、medium 2.590 / 2.588、high 2.691 / 2.688、xhigh 3.015 / 3.013
    • All custom graders: low 2.311 / 2.338、medium 2.604 / 2.550、high 2.736 / 2.688、xhigh 3.071 / 3.087
  • 詳細な解釈
    • low は堅牢性と指示順守が弱い
    • medium はテスト通過総量を改善しなくても、この点を意味のある形で改善する
    • high は実質的な正確性と堅牢性を改善する
    • xhigh はスコープと diff 規律を含め、ほぼすべての次元を改善する
  • コストと時間
    • low: 平均コスト $2.65、中央値 $1.91、平均実行時間 286.9s、中央値 294.6s
    • medium: 平均コスト $3.13、中央値 $2.87、平均実行時間 411.0s、中央値 371.8s
    • high: 平均コスト $4.49、中央値 $3.99、平均実行時間 579.0s、中央値 572.9s
    • xhigh: 平均コスト $9.77、中央値 $6.39、平均実行時間 753.3s、中央値 732.7s
  • コストは low と、とくに xhigh で偏りがあり、xhigh の平均コストは一部の高額な作業の影響を受けている
  • xhigh は中央値ベースでも high より高コストで遅い
  • high は medium 比で作業あたり約 1.43 倍のコストがかかり、xhigh は high 比で約 2.18 倍のコストがかかる
  • 限界
    • 作業ごとに単一シードのみを使用している
    • 26 件の実際の GraphQL-go-tools 作業しか含まれていない
    • LLM 判定者は GPT-5.4 で、パッチと作業は見るが label は見ない
    • この作業セットに対する grader calibration はない
    • 統計的に有意な普遍的結果や、他のリポジトリにそのまま移せる結果とは見なせない
  • 関連比較
    • Voratiq の実作業 leaderboard も、方法論は異なるが似た方向性を示している
    • Voratiq では GPT-5.5 xhigh は 1994、GPT-5.5 high は 1807 で、+187 点、+10.3% 上昇した
    • コストは $4.23 対 $2.52 で +67.9%、時間は 11.9m 対 7.8m で +52.6% だった
    • Stet 実験では high → xhigh が、同等性 +19.2%p、相対 +27.8%、コードレビュー通過 +30.8%p、相対 +80.0% とより大きく現れ、制作・規律 aggregate は +12.2% で類似している
    • Voratiq は ongoing work に対する preference/selection スタイルのリーダーボードであり、この実験は 26 作業の単一リポジトリ slice なので、直接比較はできない
  • 実用的な結論
    • xhigh は、曖昧だったり、複数領域にまたがったり、並行性中心だったり、レビューリスクが高い作業に適している
    • high はこのデータセットでは、日常的な標準設定として最も実用的に見える
    • medium 以下の設定は、コストがより重要で、作業が日常的または明確に定義されている場合に適している
    • 推論努力の効果は作業ごとに滑らかでも単調でもなく、high が xhigh を上回る場合や、高い設定がもっともらしいが誤った実装を生む逆転もある
    • チームはグローバルなベンチマークのデフォルトをそのまま真似するのではなく、自前のハーネスと自前の作業で測定すべきだ
  • 公開事項
    • Stet.sh を開発中で、このローカル評価ツールで実験を実行した
    • 製品版ではコーディングエージェントが AGENTS.md 改善のような候補変更を作成し、Stet で過去のリポジトリ作業に対して評価する
    • コーディングエージェントを多用するチームで、high vs xhigh、Codex vs Claude Code、AGENTS.md 更新、委任しても安全な作業の判断といった具体的な意思決定を控えているなら、リポジトリ別の試験を一緒に実行するチームを探している
    • Stet は LLM サブスクリプションを使って完全にローカルで実行され、ウェイトリストは https://www.stet.sh/private にある

関連記事

1件のコメント

 
GN⁺ 8 시간 전
Hacker Newsの意見
  • この比較は良いし、5.4との比較も見てみたい
    これまでの体感では、5.5は追加コストに見合う価値がない。5.4-highのほうが5.5のほとんどの推論段階よりうまくやれて、コストは半分、実際の所要時間もずっと短い。5.5-mediumは作業を最後まで完了できず、5.5-highは過剰設計でバグやリグレッションを作った
  • 真剣な作業の大半にはhighがちょうどよさそう
    それより上の段階で得られる改善は、コストに対して収穫逓減に近い
  • Proアカウントで5.5 xHigh Codex Terminal CLIをメインリード、Codex Desktop App 5.5 xhighをサブリードとして回している
    両方に危険なフルアクセス権限を与え、同じプロジェクトで作業させている。それぞれ平均6個の5.5サブエージェントをぶら下げていて、CLIやアプリがどの段階のサブエージェントを使うかを決める。混在するが、CLIは概ね5.5 Mediumを付ける
    CLIには管理者権限があり、GitHub、Supabase、Vercel、Clerk、Linear、Symphonyのようなものとの連携や、push、merge、PR、deployはCLIだけが処理する。自分でやることはゼロで、P0/P1/P2イシューもゼロ。GitHub、Vercel、Supabaseは全部グリーンで、イシューもなく、コードと製品はきれいで、リファレンス画像1枚だけでフロントエンドが驚くほどの出来になる
    欠点は、1日で週次上限の**30%**を燃やしてしまうこと
    • この実験を見て、いくつかの作業でxhighを使ってみたが、かなり効果的な一方でトークンを狂ったように使う
      今はまたhighに戻っている
  • 5.5 xhighへの最大の不満は、聞きもせずにそのまま自分で作業を進めること
    おかげで寿命を数年分と相当な量のトークンを節約できた気がする
    • 主にhighを使っているが、まったく同じ挙動をする
      agents.mdにどんな文言を入れれば勝手に仮定しないようになるのか、ずっと探している。何かについてコーディングを指示する前に、もっと知る必要があって質問すると、返答の代わりにコーディングを始めてしまうことがある。終わったあとで回答の中に質問への答えも入れてはくれるが、こちらの発言には注意を払っていても、質問があるならまだコーディングすべきではないという意味までは理解していないようだ
  • 同じPRについて複数回実行してみたのか気になる
    モデルの実行ごとのばらつきがどの程度あるのか知りたい。上のケースでhighのほうがコーディングがうまくても、実行ごとの変動が大きいならxhighを使うほうが良いかもしれない
    さらに実験としては、実行後の作業結果にフィードバックを与え、人間が修正した内容と比較してAGENTS.md、skills、rulesなどを更新させたうえで、fresh sessionでhigh/xhighを再実行してみるとよさそう。何回か繰り返して改善したあと、すべての努力レベルで再実験すれば、AGENTS.mdやskills/rulesをきちんと詰めることで全体の出力品質を引き上げられそうだ
    • 各バリエーションを複数回実行はしていない。主な理由はコストとトークン制約だ。財布は無限ではないが、追試としては良いアイデアだ
      AGENTS.mdの最適化は本当に気に入っていて、実際に実験を回すために作ったStetにこれをやらせてみた。Codexをいくつかの作業に走らせてスコアや失敗パターンを見たあと、AGENTS.mdを修正させ、再実行するという流れをすべて自律的に回している。AGENTS.md向けの自動研究のように動作し、データに基づく改善案をAGENTS.mdに反映して戻ってくるのを見られるので、かなり興味深い
  • 今は価格インフレ用のCPI指数も必要だ。月次CPIがほぼ100%のように感じる