Show HN: Jevstiller – Jevをローカルモデルに蒸留し、不一致バウンドを設定

ローカルモデルが98%の時間Jevのように応答し、その方法を検証します。ここでのすべての数値はベンチマークからのもので、bash experiments/bench.sh --no-record はAPIキーなしでそれらを再実行します。 Jevでテキストを分類する場合、すべての応答は1つのベンダーへのネットワーク呼び出しであり、負荷に関係なく約300ミリ秒で返されます。バッチジョブの場合はこれで問題ありません。しかし、決定、実行、そして再び決定を繰り返すエージェントループや、ゲームのティック、あるいは分類してから実行するようなあらゆるものでは、ステップあたり300ミリ秒が全体の予算となります。 Jevstillerは、その呼び出しの前に位置し、Jev自身の回答から小さなローカルモデルを学習し、CPU上で約15ミリ秒で、確信があることに対して応答させます。興味深いのは小さなモデルそのものではありません。それは契約です。1つの数値を設定します。例えば98%です。Jevstillerは、リクエストの少なくともその割合でJevが返したラベルを返します。 この投稿は、その文を真実にするために何が必要か、なぜ単純な信頼度閾値の選択がそれを真実にしないのか、そしてそのコストについて説明します。 具体的に何を学習するか リクエストごとに、フリーズされたセンテンスエンコーダー（bge-small、384次元、CPU上のONNX Runtime）が埋め込みます。その上に、Jevstillerはタスクのラベルに対するJevの完全な確率分布、単一のトップラベルだけでなく、それに基づいてクロスエントロピーで多項ロジスティック回帰ヘッド（線形層1つとソフトマックス）を学習します。これはフルバッチAdamと検証スライスでの早期停止を使用します。 それがモデル全体です。数キロバイトで、数千行のデータで数秒で学習され、2,000件の新しいJevの回答ごとに再学習され、バージョン管理され、本番トラフィックでシャドウテストされた後に昇格されます。 その隣には、ヘッドが応答することを許可される時期を決定する2つの小さなものがあります。学習済み埋め込みに対するk最近傍法（k-NN）の分布外（OOD）スコアラーと、ルーティングポリシー（信頼度閾値とOODカットオフ）です。これは、以下のバウンドでキャリブレーションされたホールドアウトされたIIDスライス上で行われます。 閾値を超え、学習分布内にあるリクエストは、約15ミリ秒でヘッドの応答を受け取ります。それ以外はすべてJevに送られます。コードパスはDESIGN.md §7.3から§7.6にあります。 一言で言うと契約 タスクごとに、トラフィックのウィンドウ全体で、ローカルモデルが応答するリクエストの割合をc（カバレッジ）、そのうちJevとラベルが異なるものの割合をeとします。応答しないリクエストはJevに送られ、定義上Jevと一致します。したがって、システムとJevの一致率はA = 1 − c · e となります。 目標のA*は、Jevが与えなかった回答になる可能性のあるすべてのリクエストの割合である予算β = 1 − A*を与えます。98%の場合、それは100件中2件です。ルーターの仕事は、c · e をβ未満に保ちながら、できるだけ多く応答することです。 その文には意図的に2つのものが欠けています。真実に対するモデルの精度については何も述べていません。Jevが間違っていれば、ローカルモデルも同じように間違っており、ステータスレポートはすべての数値の横にそのように表示されます。そして、それはローカルモデルが応答を選択したリクエストに対する精度ではなく、すべてリクエスト全体での一致についての声明です。最初のフレーミングは検証可能なものです。2番目はほとんどのツールが報告するものです。 明白な方法、そしてなぜそれが破綻するのか このようなカスケードの通常のレシピは、一部のデータをホールドアウトし、信頼度閾値をスイープし、予算内に測定された不一致がある最も緩いものを保持し、出荷するというものです。これは、午後に書くようなものであり、ベンチマークのポイント推定ルールが実行することです。しかし、それは予算を約半分の時間で破ります。 5つの公開タスク、それぞれ20回のランダムなトレーニング/キャリブレーション/テスト分割で、ポイント推定ルールはタスクあたり20分割中6〜12分割で2%の予算を超過し、最大で1パーセントポイントまで超過しました。 | Task | Rule | Coverage | Disagreement, mean worst | Budget broken | |---|---|---|---|---| | Banking77 (77 intents) | point estimate | 79.8% | 1.90% 2.70% | 9 / 20 | | Banking77 | bound | 74.9% | 1.15% 1.55% | 0 / 20 | | CLINC150 (151 intents) | point estimate | 84.3% | 2.09% 2.85% | 12 / 20 | | CLINC150 | bound | 78.9% | 1.25% 1.80% | 0 / 20 | | AG News (4 classes) | point estimate | 90.3% | 2.06% 2.65% | 11 / 20 | | AG News | bound | 86.5% | 1.34% 1.75% | 0 / 20 | | TweetEval sentiment | point estimate | 28.2% | 1.99% 2.60% | 8 / 20 | | TweetEval sentiment | bound | 24.0% | 1.46% 2.10% | 1 / 20 | | TweetEval offensive | point estimate | 36.8% | 1.81% 2.70% | 6 / 20 | | TweetEval offensive | bound | 28.7% | 1.10% 1.40% | 0 / 20 | これはレシピのバグではありません。有限データで最も緩い合格閾値を選択すると、予算を破るということです。任意の閾値での測定された不一致は、真の不一致のノイズの多い推定値です。予算を下回っているように見える最も緩い閾値を選択すると、優先的にノイズが下向きに指している閾値が選択されます。次のトラフィックサンプルではノイズは別の方向に指し、1.9%を測定した閾値は2.7%を提供します。 100回の分割のうち、バウンドは一度だけ予算を破りました。2.10%でした。その一度は予想通りです。バウンドは95%の声明であり、約100分の5が失敗する可能性があります。ポイント推定は声明ではありません。 Jevstillerが代わりにすること 4つの決定、それぞれは小さいですが、一緒に、本番環境に投入されるローカルモデルのすべてのバージョンに対して、少なくとも95%の確率で契約が有効であることを保証します。 1. 損失は契約そのものです。Jevによってラベル付けされ、トレーニングには決して使用されないIIDキャリブレーションセットの各行について、ローカルモデルがそれを応答し、Jevと不一致になる場合は1をスコア付けし、それ以外の場合は0とします。すべての行にわたるその指標の平均は、まさに予算が制限する「すべてのリクエストに対する不一致」です。これは二項分布であり、近似や大規模サンプルへの訴えなしに、正確な信頼区間バウンド（Clopper-Pearson）を持ちます。 2. 閾値を最も厳しいものから順に、固定グリッド上でテストし、最初の失敗で停止します。閾値が緩むにつれてレートは成長するだけなので、最も緩い候補から最も緩いものまで歩き、それぞれの上限を予算に対してチェックし、最初に失敗したところで停止することで、多くの候補をテストしたことに対する補正なしに、誤った選択の確率を同じ5%で制御します。これはLearn Then Testのような固定シーケンステストです。グリッドはキャリブレーション行が一切見られる前に固定されており、キャリブレーション行はテストのみを行います。 3. 他のものは何もキャリブレーション行に触れません。見慣れない入力を信頼度に関係なくJevに送る分布外ゲートは、トレーニングデータからそのカットオフを取得します。候補となる閾値は固定グリッドです。どちらかがキャリブレーション行で調整された場合、バウンドはすでにそれを境界付けるために使用されたデータ上で計算されることになります。これは別の形でのポイント推定の間違いです。 4. ヘッドルームを残します。閾値は予算の85%で適合されます。候補は次に、キャリブレーション行とシャドウイングした新しいトラフィックをプールしたもので、完全な予算で2回目のチェックに合格する必要があります。このチェックは独立した保証ではありません。なぜなら、キャリブレーション行は閾値を選択するのに役立ったからです。しかし、それはちょうど線上に座る閾値をキャッチします。 この最初のバージョンは4つのうち2つを間違えました。選択率をバウンドし、正確であるかのように推定カバレッジを掛け合わせ、それぞれが単独で合格した200の閾値のうち最も緩いものを保持しました。これはポイント推定と同じようにノイズで選択します。先行技術レビューが両方を検出しました。 修正されたルールは、Banking77のリプレイではコストがかかりませんでした。カバレッジは70.6%から70.7%に移動しました。 2番目の約束：「Jevは不確かでしたか？」 Jevはすべての応答に信頼度を返します。そのドキュメントは、低い信頼度を「不確か」として扱うことを推奨しています。人間に送る、もう一度尋ねる、安全な分岐を取るなどです。 自信があるときだけ応答するローカルモデルは、ローカル応答が不確かなまま返されることがないため、そのパターンを静かに破ります。ベンチマークタスクでは、0.6でのチェックは、Jevが提起したフラグの8%から37%を失いました。 0.4.0以降、タスクはconfidence_floorを持つことができます。これは、あなたのコードが応答を不確かとして扱うJevの信頼度の閾値です。キャリブレーション、シャドウテスト、監査は、ローカル応答が不一致とカウントされるのは、ラベルが異なる場合だけでなく、