jevlike: テキストオプション用のオープンソースJev風1パススコアラー

すぐにわかる要点

jevlikeは、可変長のテキストオプションリストに確率を割り当てる、軽量でオープンソースのJev風1パススコアラーを提供し、トークン単位の生成なしに高速かつ決定論的に選択が可能になります。

リポジトリが提供するもの

コンテキスト文字列と任意のオプションリストを受け取り、1回のフォワードパスで各オプションの確率を返す最小限のモデル。
ドゥームとチェスという2つの古典的なインタラクティブ環境の参照実装で、視覚的パッチからコントローラボタンを直接スコアリングする様子を示す。
合成データジェネレーター、トレーニングスクリプト、評価ユーティリティ、および迅速な実験用のコマンドライン予測ツール。
Hugging Face transformersライブラリを介して、事前学習済みエンコーダ（例: Qwen2.5‑0.5B）を固定するオプションサポート。
MITライセンスのコード。ダウンロードされたデータセットや事前学習済み重みについては別途ライセンスが適用される。

コアアーキテクチャの説明

各オプションは、そのテキストを表す短い数値リストであるクエリベクトルに変換される。このクエリはコンテキストトークンに注目重みを割り当て、そのオプション用の1つのコンテキストベクトルを生成する。共有ドット積は各（オプション、コンテキスト）ペアを1つのスコアに変換する。スコアを合計が1になる確率に変換するsoftmaxは、オプション次元全体で実行される。

オプションクエリ – 各オプションは、デフォルトではバイトレベル、または固定エンコーダを介して固定サイズのベクトルに埋め込まれ、クエリとして機能する。
コンテキストへの注目 – クエリはコンテキストのトークン埋め込みに注目し、オプション固有のコンテキストベクトルを生成する。
スコアリングヘッド – 共有の線形ドット積層が、各（オプション、コンテキスト）ペアに対してスカラーのスコアを計算する。
ソフトマックス正規化 – スコアはオプション次元全体でソフトマックスを経て、確率分布を出力する。

この設計はTypeSafeのJevシステムで説明された「オプション注目ヘッド」と類似しているが、完全に公開され、拡張可能である。

データフォーマットと準備

入力ファイルはJSONL形式で、1行に1オブジェクト：

{"context":"The customer needs a refund.","options":["refund","sales","technical support"],"label":0}

labelは正しいオプションのゼロベースインデックス。
オプション数は行ごとに変動可能で、最小2つ以上必要。
カスタムデータセットの場合、推論時に出現するすべてのオプションを各行に含め、漏洩を避けるために関連するレコードをまとめて分割する。

すぐに始める（合成デモ）

# 仮想環境を作成し、開発依存関係をインストール
uv venv && source .ven/bin/activate
uv pip install -e '.[dev]'

# 合成データを生成
jevlike-data synthetic --output data/synthetic

# 合成トレーニング分割で学習
jevlike-train data/synthetic/train.jsonl \
  --validation data/synthetic/validation.jsonl \
  --output runs/synthetic.pt

# 合成テスト分割で評価
jevlike-eval runs/synthetic.pt data/synthetic/test.jsonl

# 新しいメニューで予測
jevlike-predict runs/synthetic.pt \
  --context "Choose the exact badge amber badger. Badge: amber badger." \
  --option "azure crane" \
  --option "amber badger" \
  --option "gold heron"

評価はトップ1およびトップ3の正確率、期待されるキャリブレーション誤差、およびシャッフルコンテキストコントロールを報告する。有用なモデルはコントロールを上回る必要がある。

固定事前学習エンコーダの使用

uv pip install -e '.[transformers]'
jevlike-train data/synthetic/train.jsonl \
  --validation data/synthetic/validation.jsonl \
  --output runs/qwen-head.pt \
  --encoder hf \
  --hf-model Qwen/Qwen2.5-0.5B \
  --rank 256 \
  --batch-size 8

チェックポイントには訓練済みスコアリングヘッドとエンコーダ識別子のみが保存され、エンコーダ重みは実行時にHugging Faceから読み込まれる。
--rankはスコアリングヘッドの幅を制御する（高いランク = より多くのパラメータ、より高いメモリ使用）。

実世界の例

ドゥームコントローラスコアリング

リポジトリには、生の画像パッチから7つのドゥームコントローラボタンをスコアリングする統合チェックポイントが同梱されている。
10秒のデモ映像では、ドゥーム戦闘とチェスコントローラによる駒の移動が組み合わされ、同じオプション注目ヘッドが視覚的およびテキスト入力に対応できることを示している。
ドゥームチェックポイントは、10回記録されたエピソードで平均0.60キル、-97.50報酬を達成した。

チェス手の選択

チェス専用チェックポイントは、チェス手を表す5つのキーをスコアリングし、ランダムムーバーに対して4勝、46分、0敗を達成（50試合サンプル）。
Stockfishレベル0に対しては0勝、2分、48敗となり、戦略的実力は限定的だが、視覚的盤面状態を処理できることを確認した。

著者の実験から得られたパフォーマンス数値

合成メニュー：1パススコアラーを使用して約98％のトップ1正確率。
Wikispeedia次クリックタスク（ターゲット非交差分割）：
- 固定Qwen2.5‑0.5Bエンコーダ＋スコアラー → 26％正確率。
- ランダムエンコーダコントロール → 約8％正確率。
- 4万回のクリックでスクラッチから学習した小規模モデル → 29％正確率。
速度：8つのオプションの場合、1パススコアラーは小規模デコーダが400トークンを生成させられる状態と比較して約100倍高速。

これらの数値は局所的な実験結果であり、TypeSafeの特許技術Jevモデルとの直接比較ではない。

Hacker Newsコメントからのコミュニティの知見

Jev風スコアラーとしての拡散モデル – ユーザーがVLLMのPRをリンクし、拡散モデルを1パスオプションスコアリングに再利用した例を紹介。DGX Spark上で1回の判断に約0.2秒、言語検出タスクで高い正確率を達成。
オープンソースQwen‑2.5‑1B‑RLCD – 他のコメントでは、JSONワークロード向けの高速オンデバイス推論モデルの最近のリリースを強調。軽量で型安全なモデルへの傾向を示唆。
ユースケースの多様性 – 複数のコメントが、生成テキストではなく、校正された確率重みを得ることの価値に注目。スキル衝突検出、拡散パイプラインの事前飛行コスト推定、マルチモーダルワークフローでのルーティング決定など、さまざまな応用を可能にする。
概念の明確化 – あるコメントでは、元のTypeSafe発表が曖昧だったと指摘。READMEの3文説明（「テキストとN個のテキストオプションを受け取り…1パス…」）が、核心的なアイデアをより明確に捉えていると述べた。

注意すべき制限点

このプロジェクトは研究の出発点であり、TypeSafeのJevの完全な再現ではない。
正確率はデータ品質、分割戦略、選択されたエンコーダに大きく依存する。
デフォルトのバイトエンコーダは安価だが、深い言語理解は欠如している。
固定事前学習エンコーダを使用すると、大きなダウンロードと追加のGPUメモリが必要になる可能性がある。
推論時に完全なオプションリストが必要であり、候補セットが極めて大きい場合、実用的でない可能性がある。
報告された速度向上は小規模デコーダとの比較であり、大規模商用モデルとの比較ではない。

jevlikeの拡張・適応方法

--encoder hfフラグを用いて、LLaMA‑2やMistralなどのより大きな多言語モデルにバイトエンコーダを置き換える。
--rankを増やすことで、より洗練されたオプション区別能力を持つスコアリングヘッドの能力を向上させる。
視覚エンコーダからの視覚埋め込みを同じオプション注目メカニズムに供給することで、マルチモーダル入力を実験する（ドゥーム／チェスデモで示されたように）。
確率的ルーティングや信頼度を意識した分類が必要なパイプラインに予測器を統合する。
速度と正確率のトレードオフを定量的に評価するために、ベースライン分類器（ロジスティック回帰、微調整BERT）とベンチマークを実施する。

ライセンスとクレジット

コードはMITライセンスでリリースされている。
データセットと事前学習モデルはそれぞれの元のライセンス条項を維持する。関連するソース（例: WikispeediaのSNAP、Hugging Faceのモデルカード）を参照すること。