Jevstillerは有限サンプル境界を用いてJevとの98%の合意を保証する

TL;DR – Jevstillerが達成すること

JevstillerはJev自身の予測から軽量な分類器を学習し、厳密に調整された信頼度しきい値を適用することで、全リクエストの2%以下しかJevが与えないであろうラベルを受け取らないことを保証します。ローカルモデルはCPU上で約15msで応答し、Jevを直接呼び出す場合の300msのネットワークレイテンシを削減します。

システムの構築方法

モデルアーキテクチャ

エンコーダー: 固定された bge‑small 文エンコーダー (384次元、CPU上の ONNX Runtime)。
ヘッド: Jevのトップラベルだけでなく、完全な確率分布に基づいて学習された多項ロジスティック回帰 (単一の線形層 + softmax)。
サイズとレイテンシ: 数百キロバイト。推論は単一のCPUコアで約15ms。
学習サイクル: 2,000件の新しいJevの回答ごとに数千行のデータを使用して再学習され、数秒で完了します。

ルーティングコンポーネント

k‑NN OODスコアラー – 学習時の埋め込みを使用して、分布外 (OOD) の入力を検出します。
信頼度ルーター – しきい値とOODカットオフを適用し、ローカルヘッドが回答すべきかどうかを決定します。

両コンポーネントはプロジェクトの DESIGN.md (§7.3‑§7.6) で説明されています。

1つの式による契約

トラフィックウィンドウ内の特定のタスクについて：

c = カバレッジ (ローカルで回答されたリクエストの割合)。
e = ローカルの不一致率 (回答されたリクエストのうち、ラベルがJevと異なるものの割合)。
Jevとの全体的な合意率: A = 1 – c·e。

目標合意率 A* = 98 % を設定すると、予算 β = 1 – A* = 2 % が得られます。ルーターは c·e ≤ β を維持しなければなりません。

重要なポイント: この契約は真の精度については何も言及しておらず、Jevとの不一致を制限するだけです。

なぜ単純な信頼度しきい値のスイープが失敗するのか

一般的なアプローチ:

キャリブレーションデータを保持する。
信頼度しきい値をスイープする。
経験的不一致が ≤ β となる最も緩いしきい値を選択する。

5つの公開分類タスク（各20回のランダム分割）において、この点推定ルールはタスクごとに20回中6〜12回で2%の予算を超過し、時には予算を最大1%超過しました。

タスク	カバレッジ (点推定)	平均不一致率	最悪の不一致率	予算超過回数
Banking77	79.8 %	1.90 %	2.70 %	9/20
CLINC150	84.3 %	2.09 %	2.85 %	12/20
AG News	90.3 %	2.06 %	2.65 %	11/20
TweetEval sentiment	28.2 %	1.99 %	2.60 %	8/20
TweetEval offensive	36.8 %	1.81 %	2.70 %	6/20

この失敗は統計的なものです。選択されたしきい値は、ノイズによってサンプルの不一致率が偶然低くなったものです。新しいトラフィックでは、真の不一致率はより高くなる可能性があります。

Jevstillerの統計的に健全な代替案

4つの規律ある選択により、すべての本番バージョンで98%の保証が95%以上の信頼度で維持されます。

損失 = 契約 – 各キャリブレーション行（学習では未使用）に対して、ローカルモデルが回答し、かつJevと不一致である場合にバイナリ損失 1 を記録し、それ以外は 0 とします。平均損失は正確に c·e です。これは二項比率であるため、正確なクロッパー・ピアソン信頼区間を適用できます。
固定グリッド、厳格優先テスト – 候補となるしきい値は事前に定義されています。最も厳格なものから順に評価し、95%信頼区間の上限に違反する最初のしきい値で停止します。この固定順序テスト（"Learn Then Test"）は、多重比較補正なしでファミリーワイズエラーを制御します。
キャリブレーションの漏洩なし – OODカットオフは学習セットのみから導出されます。キャリブレーションセットはしきい値のテストにのみ使用されます。これにより、同じデータでしきい値の選択と評価の両方を行うという点推定の古典的な落とし穴を回避します。
ヘッドルームとシャドウ監査 – 選択されたしきい値は予算の85%に適合させられます。キャリブレーション行とライブシャドウトラフィックのプールされたセットに対する2回目のチェックで、予算全体を検証します。継続的な監査トラフィック（全リクエストの2%）は常にJevに送信され、合意率の偏りのないライブ推定値を提供します。ライブの境界が目標を下回った場合、ルーティングはJevにフォールバックし、再学習が開始されます。

最初の実装ではステップ1と2が欠落しており、時折予算超過が発生していました。修正後、Banking77のリプレイでのカバレッジは70.6%から70.7%に向上し、保証も維持されました。

Jev自身の信頼度フロアへの保証の拡張

Jevは回答ごとに信頼度スコアを返します。多くのアプリケーションでは、低い信頼度を「不確実」として扱い、そのようなケースを人間のレビュー担当者にルーティングします。

バージョン0.4.0以前、Jevstillerはラベルに関する合意のみを保証していました。
0.4.0以降、タスクは confidence_floor を指定できます。キャリブレーションと監査の間、Jevの信頼度がこのフロアを下回った場合も、ローカルの回答は不一致としてカウントされます。
同じ2%の予算が、ラベルの不一致とJevが不確実なケースの両方をカバーするようになりました。
カバレッジへの影響: 5つのベンチマークタスクにおいて、0.6のフロアを設定するとカバレッジが4〜12ポイント低下します。

本番環境での保証の維持

2つの動的な要因が静的な境界を脅かします:

モデルドリフト – ローカルヘッドは新しいJevの回答に基づいて定期的に再学習されます。
データドリフト – トラフィックの分布やJevの動作が変化する可能性があります。

Jevstillerは以下の方法で両方を緩和します:

常にJevにクエリを行う2%の監査スライスを永続的に保持します。
このスライス上でバージョンごとのライブ合意率を測定します。信頼区間が目標を横切った場合、監査率を引き上げ、システムはJevにフォールバックします。
迅速な回復の実証: 12時間目に合成的なJevの変化が発生した際、ローカルのカバレッジは4分以内に90%から9%に低下しましたが、新しい回答で再学習した後、49分で90%に回復しました。

カバレッジと合意率のトレードオフ

この境界は保守的です。ベンチマークタスクでは、単純な点推定ルールと比較して4〜8%のカバレッジを犠牲にしています。
(トップラベルだけでなく) Jevの完全な確率分布で学習することで、多クラス分類タスクで2〜3%のカバレッジを回復します。
目標合意率を調整する（例: 98%から95%へ）と、ツイート感情分析タスクではカバレッジがほぼ倍増し、意図分類のカバレッジは〜70%から80%台前半に上昇します。
90〜99%の合意スペクトル全体において、Jevstillerの人間ラベルに対する精度はJevの精度から±1%以内に収まります。これは、ローカルモデルがJevと不一致になる場合、Jevと同じくらいの頻度で正解しているためです。
カバレッジはJevの一貫性と相関します。TweetEvalタスクでは、Jevの人間ラベルとの合意率は64〜74%に過ぎず、ローカルモデルの自信のある共有範囲を制限しています。

Jevstillerが約束しないこと

精度: 保証はJevとの合意に関するものであり、正解データに対する正確性ではありません。
クラスごとの予算: 現在の契約は集計ベースです。まれなクラスが不一致予算を支配する可能性があります。
静的トラフィックの仮定: 有限サンプル境界は、キャリブレーション行が将来のトラフィックのランダムサンプルであることを前提としています。大幅な分布シフトは境界を無効にするため、ライブ監査が不可欠です。

はじめに

git clone https://github.com/tomerglick57/Jevstiller && cd Jevstiller && pip install .
# Banking77の結果を再現 (APIキー不要、約10分)
bash experiments/reproduce.sh
# フルベンチマークを実行 (全5タスク、約1〜2時間)
bash experiments/bench.sh --no-record

DockerイメージをJevのドロップインプロキシとして実行します:

docker run -d -p 8080:8080 -v jevstiller-data:/data ghcr.io/tomerglick57/jevstiller

TYPESAFE_BASE_URL をコンテナを指すように設定します。数千リクエストの後、サービスは達成された境界とライブ監査間隔を出力します。

コードは Apache 2.0 ライセンスの下で公開されています。