【ITニュース解説】We Measured the 200x Claim, and Got It Wrong Twice First

今回の記事は、新しい大規模言語モデル（LLM）である「Jev」と、すでに運用している既存のモデルの性能を比較評価した際の具体的な過程と、その中で直面した課題、そしてそこから得られた重要な教訓について解説している。システムエンジニアを目指す皆さんにとって、実際のシステム評価の難しさや、陥りやすい落とし穴を学ぶ良い機会となるだろう。

比較対象は、中規模のオープンソースモデルをサーバーレス環境で運用していた既存システムと、TypeSafe AIが提供する新しいJevモデルだ。評価に用いたワークロードは、管理者が特定のメールアカウントの送信状況をレビューする機能だった。この機能では、アカウントの活動データからモデルが分類と判断理由を生成し、管理者はその結果を待つため、応答速度がユーザー体験に直結する重要な要素だった。

性能評価を進める中で、私たちは二つの大きな間違いを犯した。一つ目は、JevのAPI（アプリケーション・プログラミング・インターフェース）の仕様を誤解していたことだ。JevのAPIは、一度のリクエストで複数の質問を同時に処理できるが、各質問は互いの回答を参照できない特性があった。当初、モデルに「アカウントのカテゴリ分類」と「取るべきアクション」を同時に質問した結果、「開発者のテスト送信」と分類したアカウントに「停止」を推奨するなど、論理的に矛盾する回答が出力された。既存モデルでは、テキスト生成過程でこれらの情報が一体となって出力されるため、この問題は起きなかった。この経験から得られた教訓は、新しいツールのAPIドキュメントを徹底的に読み込み、その動作原理を正しく理解することの重要性だ。最終的には、モデルには分類判断のみを任せ、具体的なアクションの決定は、コード側で制御するように修正した。

二つ目の間違いは、テストデータが実際の運用状況と大きくかけ離れていたことだ。モデルの精度評価のため、過去に人間が停止したアカウントをテストサンプルとして用いた。しかし、これらの停止済みアカウントの多くは、モデル導入前に停止され、テスト期間の直近30日間はメール送信活動が一切なかった。つまり、モデルは活動していないアカウントのレビューを求められていたことになり、当然「何も問題は起きていない」と回答した。私たちは当初、この結果から「モデルは機能しない」という誤った結論を導きそうになった。また、不正アカウントの検出基準を厳しく設定しすぎ、既存モデルが「疑わしい」と分類し管理者アラートに繋がるケースを見落としていた。この間違いから学んだのは、ベンチマークテストの入力データは、実際の運用環境で発生しうる状況を正確に反映している必要があるということだ。

これらの反省を踏まえ、より実運用に近い環境で再測定した結果、様々な数値が明らかになった。

応答速度では、Jevは既存モデルより大幅に高速だった。既存モデルの中央応答時間が約7.3秒だったのに対し、Jevは約0.6秒と、表面上は約12倍の速度差があった。しかし、既存モデルは分類理由を説明するテキスト（平均459トークン）を生成していたのに対し、Jevはより簡潔な情報（平均138トークン）を返していた。この出力量の違いを調整すると、Jevは既存モデルより約3倍速いという結果になった。

速度以上に重要だと判明したのは、応答の「安定性」（分散）だった。Jevの応答時間は最も遅いものでも687ミリ秒と、標準偏差がわずか38ミリ秒と極めて安定していた。一方、既存モデルは最も遅いもので12.7秒と、標準偏差が2353ミリ秒と非常にばらつきが大きかった。人間が直接結果を待つシステムでは、平均応答速度よりも、応答が常に安定している予測可能性がユーザー体験にとって極めて重要となる。

コスト面では、Jevは既存モデルより約7倍安価だった。しかし、この大幅なコスト差の主な要因は、モデル自体の価格差ではなく、料金体系の違いにあった。既存モデルは出力トークン料金が入力トークン料金の約15.5倍も高く、総コストの83%を出力トークンが占めていた。対照的に、Jevは入力トークンにのみ料金が発生し、出力トークンは無料だった。入力トークン単価で比較すると、両モデルの差は約1.31倍と小さく、Jevのコスト優位性は「出力が無料」という料金設定に大きく依存していた。

品質面では、Jevが提供する「型付けされた出力」（typed output）のメリットが明確になった。既存モデルは50回中3回、JSONパーサーで読み取れない形式のテキストを返すことがあり、これがシステムのエラーページ表示に繋がる致命的な欠陥だった。Jevのようなモデルは、あらかじめ定義された形式で応答を返すため、このような解析エラーは根本的に発生しない。これは速度向上以上に、システムの信頼性を大きく高める重要な改善点だった。

これらの知見に基づき、最終的に管理者のレビューボタンはJevモデルを呼び出すように変更された。これにより、約600ミリ秒という高速かつ安定した応答で分類結果が得られるようになった。詳細な理由文の表示は、数秒かかるため、必要に応じて押すオプションのボタンとして分離した。また、人間が応答を待たないバックグラウンド処理には引き続き既存モデルを使用し、モデルの切り替えは設定で容易に行えるように配慮した。

今回の経験から得られた重要な教訓は多岐にわたる。一つ目に、性能測定は必ず実際のワークロードと同じ環境で行うべきだ。二つ目に、比較対象となる両方のツールに対し、それぞれの特性を最大限に活かせる最適な形でテストを行うべきである。三つ目に、テストに用いるデータが、実際の運用で発生しうる状況を正確に反映しているか、常に厳しく検証する必要がある。四つ目に、最初に提示される数字を鵜呑みにせず、何がその差を生み出しているのか、出力量や料金体系といった詳細な要因まで分解して分析する習慣を持つことが重要だ。最後に、そして最も大切なことだが、自分たちにとって都合の良い、魅力的すぎる結果が出た場合は、特に注意して二重、三重に検証するべきだ。魅力的すぎる結果は、誤解や誤った測定方法の兆候である可能性が高いため、より入念な確認が不可欠となる。これらの教訓は、将来システムエンジニアとして様々なシステムの評価や導入に関わる皆さんの糧となるだろう。