HN 日本語サマリー

← 一覧へ戻る
AI・機械学習

本番AIエージェントをGPT-5.6に移行:2.2倍高速、27%低コスト

Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper (ploy.ai)

240 pointsby brryant111 コメント

要約

Ployは、自社のAIエージェントをClaude OpusからOpenAIの最新モデルGPT-5.6 Solに移行したことを発表しました。この移行により、ウェブサイト構築エージェントのパフォーマンスが大幅に向上し、完了までの時間が2.2倍短縮され、コストが27%削減されました。移行プロセスでは、モデル固有の挙動(ツール引数の補完、プロンプトキャッシュ、推論の再現など)に対応するため、評価ハーネス、ツールスキーマ、キャッシュ設定、推論再現などのシステム全体にわたる調整が必要でした。

全文翻訳

本日より、Ployのエージェントは、OpenAIが今朝リリースしたモデルファミリーのフラッグシップティアであるGPT-5.6 Solで稼働しています。数ヶ月間、私たちは非常に高い品質基準を満たすモデルをClaude Opusに対抗するものとして見つけることができませんでした。それがGPT 5.6 Solで変わりました。Claude Opusと直接比較テストを行った後、私たちはGPT 5.6 SolをすべてのPloyワークスペースを支えるデフォルトモデルとしました。これは、言うよりも大きな変更です。Ployのエージェントは、実際のマーケティングウェブサイトを構築・編集します。ページを計画し、コードベースを読み込み、コンポーネントを書き、画像を生成し、自身の作業のスクリーンショットを撮り、完了したと判断します。その職務記述は、モデルに対して非常に高い基準を設定しており、私たちはすべての最先端リリースをそれに対してテストしています。Opusがデフォルトスロットを4ヶ月間保持していた間(最初はOpus 4.7、次に4.8)、テストしたものは何もそれを超えませんでした。GPT-5.6がそれを超えた最初のモデルです。最初の評価実行が完璧だったわけではありません。実際の失敗モードがありましたが、それについては後述します。しかし、それは非常にうまく機能し、その約束は即座かつ具体的でした:完了までの壁時計時間が半分以下になり、コストは27%削減され、完了した作業においては既存モデルと同等以上のスコアを達成しました。このような数値は、モデルに本格的な移行作業をさせるだけの価値があります。VercelのAI SDKという汎用LLM SDKを使用しているにもかかわらず、Claude Opus 4.8からGPT 5.6 Solへの切り替えは、私たちが「モデル」と考えているものが、プロバイダー固有の挙動であり、私たちのスタック全体が静かにそれに特化していたことを、評価の失敗を一つずつ発見していくことで明らかにする必要がありました。それは、ツール引数の補完方法、プロンプトキャッシュの仕組み、ターン間の推論の再現方法などです。以下は、そのために必要な作業です:評価ハーネスの修正、次にツールスキーマ、次にキャッシュ、次に推論再現。 ステップ0:単一の数値を信頼する前にハーネスを修正する 私たちの評価スイートは、実際のフィクスチャワークスペースに対して実際のエージェントを実行します。「ゼロからホームページを構築する」から「このクローンリクエストは実行しても安全か」まで、数百のケースがあります。ビルドケースは、参照デザインに対してバイナリチェックを実行するビジュアルジャッジによってスコアリングされます。「ヒーローはフルブリードの写真シーンである」や「プライマリCTAはピル型ではなく丸みを帯びた長方形である」といった10個のyes/no質問に加え、コンテンツチェック、ツール軌跡チェック、ファイルアサーションがあります。失敗したすべてのケースは、スコアだけでなく、実際のツール呼び出しとモデルテキストの完全なトレースに対してトリアージされます。そのスイートを2つのモデルファミリーで実行したことは、個々の結果よりも私たちを驚かせました:あなたのハーネスは、あなたの既存モデルに合わせて調整されており、あなたはそれに気づいていません。私たちのツール呼び出し予算は、Opusのシーケンシャルスタイルに合わせてサイズ設定されていましたが、GPT-5.6は並列呼び出しをファンアウトし、正しく解決しているケースでそれらを使い果たしました。私たちの評価実行子は、バッチファイル読み取りをサポートしていませんでしたが、Opusはほとんど使用せず、GPT-5.6は常に使用します。最初のクロスモデル実行での生の失敗の約3分の1は、モデルの挙動ではなく、ハーネスの仮定に起因しており、モデル間では均等に分布していませんでした。もしあなたが既存モデルに対して挑戦的なモデルを評価しているなら、パスレートを信頼する前にトレースをトリアージしてください。そうでなければ、新しいモデルを古いモデルの模倣のうまさで採点することになります。評価でモデルを公平に採点していることを確認してください。最小スコア閾値を省略したデータセットは、サイレントに1.0のデフォルト値を継承したため、GPT-5.6は0.98をスコアしたヒーローを「失敗」し、Opusは個々のチェックをすべてパスしながらケースを「失敗」しました。2つの擁護可能な設計方向性がありましたが、1つの見えない閾値がありました。 第一印象:即座に有望 ハーネスがクリーンアップされたので、エージェントが参照デザインに対してブランドのホームページを再構築する、私たちの再設計スイートからのサンプルを以下に示します。 完了した各ビルドの平均 Claude Opus 4.8 (n=11) GPT-5.6 (n=10) コスト $3.06 $2.22 壁時計時間 8m 00s 3m 42s 入力トークン 2.60M 1.70M 出力トークン 33.0K 17.1K ビジュアルスコア 0.936 0.970 これは約束の形状です:完了したページまでの速度が2.2倍、コストが27%削減され、出力トークンは約半分です。GPT-5.6は、リーンなコードを書きます。1つのマッチしたペアでは、Opusは17,957文字のglobals.cssを174個のCSS変数(フルカラーランプ、ほとんど未使用)で生成しましたが、GPT-5.6は同等(時にはより良い)のレンダリングされたページのために2,508文字と45個の変数で書きました。 Claude Opus 4.8 全体を見る GPT-5.6 Sol 全体を見る デザイン:シャープでクリーンだが、少し均一 GPT-5.6のデザイン作業に関する私たちの全体的な評価は次のとおりです。クリーンでモダンな、タイトにグリッド化されたレイアウトには非常に優れていますが、うまく誘導しない限り、そのルックに収束する傾向があります。Opus 4.8用に設計された古いハーネスでは、GPT 5.6 Solは既存のデザインシステムを無視する傾向があり、代わりにシャープで控えめで、明らかに一般的な出力を生成します。これを修正した詳細については、別のブログ記事で詳しく説明する価値があります。私たちのデザインおよびエンジニアリングチームの専門知識により、モデルを誘導して、すぐに利用できるものからは得られない、世界クラスのブランド遵守を達成することができます。 ステップ1:ツール呼び出しを確認する これは、捕捉する前にサイレントに結果を破損していたものです。私たちのエージェントのコードツールには25個のトップレベルパラメータがあり、1つ(action)が必要で、残りはオプションです。Claudeは使用している2つまたは3つを送信し、残りを省略します。GPT-5.6は、必要のないものに対してもっともらしい値を生成しながら、毎回すべての25個を送信します:offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000」。3日間の本番トレース、すべてのプロパティを持つコード(read)呼び出し: モデル 呼び出し すべての25プロパティを持つもの gpt-5.6 6,635 6,635 (100%) claude-opus-4.8 2,898 4 (0.1%) claude-sonnet-5 1,933 0 問題は冗長性ではありません。それは、生成された値が意図された値と区別がつかないということです。offset: 0は実際の引数のように見えます。私たちのファイル読み取り実装はそれを引数として扱い、GPT-5.6のファイル読み取りの52%から64%はそのために空で返されていました。ツールはどちらの場合もsuccess: trueを返したため、モデルは空のファイルを読み取っていることを知る方法がありませんでした。単に、より多くの呼び出しで、より悪く作業しただけです。プロンプトではこれは修正されません。ツール説明の「未使用のパラメータを省略する」という指示:依然として25/25です。プロパティごとの「OPTIONAL、未使用の場合は省略する」ヒント:依然として25/25です。OpenAIの厳格モード:同一の挙動(測定済み)であり、それを採用すると、すべてのスキーマからパターン、フォーマット、配列境界検証を削除する必要がありました。これは、モデルが関数呼び出しをどのようにエミットするかに組み込まれています。指示でそれをなくすことはできません。設計で回避する必要があります。機能した修正は、プロバイダー境界でのスキーマ変換です。OpenAIファミリーのモデルのみを対象に、すべてのオプションプロパティをrequiredだがnullable(anyOf: [T, null])として書き換えます。これにより、モデルは「これを使用しない」ということを明示的に伝える方法が得られます。次に、すべてのツール呼び出しが通過する単一のシームで、nullを元に戻して検証に渡します。これにより、ツール実装はまったく変更されません。ラウンドトリップ:モデルは正直さが表現できるスキーマを表示し、ツールは常に同じ入力を受け取ります。 // 前:25キー、すべてが生成された値を持つ { "action": "read", "file_paths": [...], "offset": 0, "timeout": 120000, ... } // 後:25キー、4つの実際の値、21個の明示的なnull(ツール実行前に削除される) { "action": "read", "file_paths": [...], "offset": null, "timeout": null, ... } 結果:空のファイル読み取りは52%から0%に減少し、エージェントは同じ作業に対して約30%少ないツール呼び出しで済みました。なぜなら、空で返されたファイルを再読み取りすることがなくなったからです。 ステップ2:プロンプトキャッシュを再構築する これは最も教育的なエンジニアリングの違いでした。表面上は両方のプロバイダーが「プロンプトキャッシュ」を提供しており、その言葉は2つの全く異なる設計を隠しています。もし1つのことを慎重に移行するなら、これをしてください:移行前、GPT-5.6はOpusよりも約50%高価に見えました。それはモデルの価格設定ではなく、私たちのキャッシュ設定でした。私たちのエージェントのプロンプトは、すべての会話で同じである約29Kトークン(ツールスキーマとコアシステムプロンプト)の静的なプレフィックスで始まります。Claudeでは、cache_controlでキャッシュブレークポイントをマークし、そのプレフィックスは組織全体でキャッシュされます:どの会話でも、どのワークスペースでも、1つの共有エントリ、考慮すべきスループット予算はありません。キャッシュヒット率は92%から96%で、キャッシュはバックグラウンドにフェードします。