Sonnet 5.5 は 30% 高速であると主張しています。受信箱が何か違うことに気づきました

Sonnet 5.5 は、出力が 30% 高速になり、タスクあたりのコストが最大 30% 低下し、Sonnet 5 の 10.3% に対して Terminal-Bench が 70.6% という数字を伴ってリリースされました。大丈夫。ベンチマークでは請求額が支払われないため、私は意図的な実験を実行しました。つまり、月曜日の丸々 1 回、実際の作業を 2 回、各モデルで 1 回ずつ、同じタスクを実行し、独自のタイミングで行いました。

タスクは地味なものでした。クライアントからのメール 14 通、プロジェクト概要の書き直し、契約書の疑問符の一部、調査結果をまとめた表、そして週刊ニュースレターの草稿です。まさに、Anthropic が主張する「範囲の広い日常業務」のために Sonnet 5.5 は構築されています。 Sonnet 5 では、その日の AI 部分には約 2 時間かかりました。 5.5では約80分。

しかし、興味深い発見は数分ではありませんでした。古いモデルでは、私のパターンはバッチアンド待機でした。いくつかのプロンプトをキューに入れ、別のものに切り替え、戻ってきました。高速な方ではバッチ処理をやめました。尋ねて、得て、次に進み、また尋ねます。レイテンシが注意を切り替える閾値を超えたため、ワークフローの形が変わりました。これは、本来の 30% よりも価値があり、速度の向上が奇妙に複雑になるのはこのためです。

私が測定できる限り、品質は維持されていました。電子メールの下書きには同じ回数の編集が必要で、要旨はおそらくより厳密なもので、契約書の回答には同じ条項にフラグが立てられていました。ターミナルベンチのジャンプは、エージェントコーディングの実際の能力が向上していることを示唆していますが、私が電子メールのトリアージを一日かけて個人的に検証することはできませんが、私のレーンでは何も悪くなりませんでした。

ここではコスト削減が静かな革命です。同じワークロードでの月々の請求額は著しく減少し、1 日に何千ものタスクを実行するチームの場合、人員数に換算すると 30% になります。ソロの私にとって、それはサブスクリプションに明らかに価値があるか、更新時に肩をすくめるかの違いです。安くて早いということは、AI があなたが考える項目ではなくなる方法です。