JevとSystem Oneモデル：精度よりもキャリブレーション

先週、TypeSafe AIはJevをリリースしました。これは同社が最初の「System Oneモデル」と呼ぶもので、チャットせず、書かず、ステップバイステップで推論しないモデルです。入力に関する構造化された質問に、単一のフォワードパスで、すべての回答に確率を付けて返します。ほとんどのカバレッジは速度に焦点を当てていますが、私が出荷したすべてのプロダクション分類器、私のCOMPSAC論文の分類器を含め、静かに限界となってきたのはキャリブレーションであるという主張の方が、より興味深いと私は考えています。この記事は、Jevが実際に何を変えるのか、実際のMLスタックでどこに位置するのか、そして鵜呑みにするのではなく、どのように主張をテストしたいのかを理解しようとする私の試みです。 Jevとは何か、マーケティングなしで#セクションへのリンク: Jevとは何か、マーケティングなしで Jevは、TypeSafeのローンチポストによると、3つのアイデアを中心に構築されています。 非自己回帰出力。通常のLLMは一度に1つのトークンで回答を生成し、各トークンは前のトークンに依存します。Jevは構造化された回答全体を一度に発行します。それが速度の源です。TypeSafeは、同等のタスクで70〜500ミリ秒の終了時間と、最先端のLLMよりも「40倍〜200倍高速」と引用しています。 プロンプトではなく、型付けされた質問。状態（テキスト、構造化データ、またはメッセージ履歴）と一連の質問を送信します。各質問は3つのタイプのうちの1つです：選択（セットから選択し、各オプションに確率を取得）、スコア（順序付けられたレベルに対して評価し、連続的なスコアと分布を取得）、またはnoul（はい/いいえ、ステートメントが真である確率として返される）。 リクエスト内のすべての質問は並列で評価されるため、質問を追加してもレイテンシはほとんど変わりません。 キャリブレーションのためのトレーニング。モデルは、TypeSafeが「キャリブレーションされた決定のための強化学習」（RLCD）と呼ぶものでトレーニングされます。述べられている目標は、チャットモデルがチューニングされる人間選好または検証可能な報酬目標ではなく、「認識論的に正直な確率」です。 制約も機能と同様に重要です。Jevは自由形式のテキストを生成できません。選択質問は最大255個のオプションをサポートします。現時点では画像入力はありません。価格は、入力トークン100万あたり0.042ドルで、出力トークンは無料です。アクセスは現在ウェイティングリスト制です。 したがって、これはGPTの小型版ではありません。それは、非構造化入力を読み取り、信頼できるはずの確信度を伴う型付けされた決定を返す、非常に高速で非常に汎用的な表形式分類子に近いものです。 なぜ精度ではなくキャリブレーションが真のボトルネックなのか#セクションへのリンク: なぜ精度ではなくキャリブレーションが真のボトルネックなのか 私が自分の論文で繰り返し参照する部分です。私たちは、プルリクエストがマージされるかどうかを、提出時間で利用可能なシグナルのみを使用して予測しました。ランダムフォレストは0.958のF1スコアを達成しました。すべてを「マージ」と言う多数派クラスのベースラインは0.957を達成しました。有用なモデルとそうでないモデルを実際に分けた数値はROC-AUCでした。フォレストでは0.676、ベースラインでは0.500でした。そして、私たちはモデルが「完全にキャリブレーションされた確率モデルとして扱われるべきではない」と率直に書き、トリアージには適していましたが、自動的な受け入れ/拒否決定には適していませんでした。 それは単一のデータセットの奇妙なことではありません。プロダクション分類器の通常の形状です：精度は早期に飽和します。不均衡な問題では、利用可能な精度のほとんどは無料で得られます。難しい部分はランキングと確信度です。 下流のロジックはラベルではなく確率を必要とします。「モデルが80％未満の確信度しか持たない場合は、この注文を手動レビューにルーティングする」は、80％が80％を意味する場合にのみ機能します。モデルが70％の時間で正しいものに対して0.95と言う場合、設定するすべてのしきい値は嘘になります。 誤キャリブレーションは通常のメトリックでは見えません。F1、精度、AUCさえも、すべてしきい値またはランクメトリックです。モデルは優れたAUCを持ちながらひどいキャリブレーションを持つことができ、その上に構築されたビジネスルールが誤作動し始めるまで、あなたはそれを知りません。 標準的な修正は事後的なものです：Plattスケーリング、アイソトニック回帰、温度スケーリング。これらは機能しますが、データがドリフトしたときにドリフトする別の適合コンポーネントです。 Jevが主張しているのは、私が正しく読んでいるとすれば、確率がモデルからすでに正直に出てくるということです。なぜなら、正直さがトレーニング目標だったからです。これがTypeSafe自身のベンチマーク以外のタスクでも成り立つ場合、プロダクションMLシステムから接着剤のレイヤー全体を取り除くことになります。その「もし」が全体の質問であり、テスト可能です。 System Oneモデルが実際のスタックでどこに位置するか#セクションへのリンク: System Oneモデルが実際のスタックでどこに位置するか 私は卸売業のビジネス内でMLに取り組んでいます。そのほとんどはチャットではありません。ほとんどは、2つのシステムの間にある小さく繰り返される決定です。 DecisionToday なぜそれが面倒なのか Jevの形状は適合するか？ このインバウンド注文は人間の介入が必要な例外か？ ルールと小さな分類器 ルールは腐敗し、分類器の再トレーニングはプロジェクトになる はい：しきい値付きのnoul この新しいSKUはどの規制製品カテゴリに属するか？ キーワードルール、手動クリーニング ベンダーの説明は乱雑な自由形式テキスト はい、カテゴリが255個の選択肢に収まる場合 このカスタマーサポートメッセージはどれくらい緊急か？ 何もなし、または数秒かかるLLM呼び出し レイテンシとコストにより、すべてのメッセージで実行するのが困難 はい：順序付けられたレベルに対するスコア この遅延注文をどの配送ルートで吸収すべきか？ 制約ソルバー 分類問題ではない いいえ 顧客向けの置換を説明するメモを書く LLM 生成されたテキストが必要 いいえ パターンは明らかです。LLMがチャットの衣装を着た分類の仕事を本当にしている場所ならどこでも、System Oneモデルは2桁少ないレイテンシとコストで実行可能な代替手段となります。入力が自由形式テキストであるために壊れ続ける手書きのルールがある場所ならどこでも、それはルールの実行可能な代替手段となります。生成や最適化が仕事である場所では、それは間違ったツールであり、TypeSafe自身もそう言っています。 ERP統合のストーリーも魅力的です。100ミリ秒で`{"is_exception": 0.93}`を返すモデルは、リクエストパス内に配置できます。4秒で段落を返すLLMは、キューの横に配置する必要があります。その違いが、MLが機能なのかバッチジョブなのかを決定します。 まだ受け入れる準備ができていない主張#セクションへのリンク: まだ受け入れる準備ができていない主張 ローンチ資料のいくつかの点は、懐疑的な読み込みに値します。 「ゼロハルシネーション」。TypeSafeが保証できるのは、出力タイプが常に有効であることです。5つのカテゴリの1つを求めれば、確率が合計1になる5つのカテゴリの1つが得られます。これは現実的で有用であり、LLMの構造化出力モードはそれに近似するだけです。しかし、選択されたカテゴリが正しいかどうかについては何も述べていません。有効なスキーマでの自信に満ちた誤った回答は、依然として誤った回答です。正直な表現は「スキーマエラーゼロ」であり、キャリブレーションが残りをカバーする必要があります。 誰の分布に対するキャリブレーションか？モデルは、トレーニングおよびベンチマーク分布に対しては良好にキャリブレーションされていても、あなたの分布では大きくドリフトする可能性があります。キャリブレーションは、モデルとデータセットのプロパティです。私が信頼する唯一の数値は、私のデータで測定された数値です。 比較ベースライン。「分類タスクでLLMより200倍高速」は真実であり、また少し不公平でもあります。なぜなら、これらのタスクの多くにとって正しいベースラインはLLMではないからです。それは、エンジニアリングされた特徴量に対する勾配ブースティングツリーであり、これもミリ秒未満で無料です。興味深い比較は3方向です：同じタスクで、精度、ランキング、キャリブレーション、レイテンシ、コストについて、古典的な表形式モデル、LLMとしての分類器、そしてJev。 実行したい実験#セクションへのリンク: 実行したい実験 私はすでに構築された、まさに適切なテストベッドを持っています：私の論文からのPR受け入れパイプラインです。これはリーケージを認識しており、固定された5分割クロスバリデーションを持ち、既知のキャリブレーションの弱点を持つ公開されたツリーモデルベースラインを持っています。設計は次のとおりです。 タスク。論文のRQ1と同じ：提出時のPRを与えられ、マージなしでクローズされたかどうかを予測する。Jevの状態は、PRのタイトル、本文、およびツリーが見るのと同じ提出時メタデータと差分統計をテキストとしてシリアライズしたものです。提出後に現れるもの（コメント、CI、後続のコミット）は状態に含まれません。リーケージルールは緩和されません。