大きなLLMに文章を書かせるのではなく、与えた選択肢のどれが適切かを素早く選ばせる。そんな用途に絞って作られたのが、GitHubで公開されている「Jeff」というプロジェクトだ。元記事は、Qwen3.5とGemma 4をゼロショット分類向けにファインチューニングしたモデル群の中身と、実際の速度や精度をかなり具体的に示している。派手な生成AIではなく、現場の分岐判断をどれだけ軽く、安定してさばけるかを見せる内容になっている。
元記事の主題は、firelex/jeff というGitHubリポジトリにあるモデル群の説明だ。Jeff は Qwen3.5 と Gemma 4 をゼロショット分類向けに調整したもので、文脈を文章で与え、選択肢を平易な言葉で並べると、その中からどれが合うかを確率つきで返す。生成文を出すのではなく、1回の forward pass で「どの विकल्पが正しそうか」を出す設計で、著者はこれを「小さくて速い decision model」と位置づけている。
対応する入力形式は、たとえば「荷物が壊れて届いたので返金したい」という状況文に対して、「Refunds and payments」「Damaged or lost parcels」「Account and login problems」といった選択肢を与える形だ。Jeff はそれぞれの選択肢に対する確率、選ばれた答え、信頼度を返す。質問タイプは choice、noul（yes/no の確率）、score の3種類で、複数の独立した質問を1回のリクエストにまとめて投げられる。リポジトリには jeff-serve で立ち上げるローカルサーバー例や、curl での呼び出し例も載っている。
性能面では、Jeff-Qwen3.5-0.8B が RTX PRO 6000 で1件あたり22ms、Apple M4 Max の MLX で28msとされている。2B版はそれぞれ24msと60ms、Gemma 4 E2B は29msだった。CPUでも動くが当然かなり遅くなる。重要なのは、これが「小さいから遅い」のではなく、かなり速い分類器として使えると示している点だろう。
ベンチマークは5つの公開ベンチマークに、JevBench の公開 hard tier を加えた 4,599 問で比較している。Jeff-Qwen3.5-0.8B は総合 79.1、2B は 83.1、Jeff-Gemma4-E2B は 81.6 だった。未調整のベースモデルより大きく伸びており、たとえば Financial PhraseBank では 96点台に達している。一方で、BBH、JudgeBench、JevBench のような reasoning-heavy な項目では、大型モデルや Jev より下にとどまる。著者も、サイズ相応に推論力では及ばないと書いている。
面白いのはゲームでの零ショット試験だ。Doom、Frogger、Pac-Man を Jeff に遊ばせ、毎ターン「どの行動が合法か」を自然文で説明して選ばせている。Jeff-Qwen3.5-0.8B は Frogger で 10.3 crossings、Pac-Man で 57.0 pellets まで行き、未調整モデルよりずっと良い。Doom でもルールボットに近い値を出した。一方で、2B が必ずしも強いわけではなく、ゲームでは 0.8B の方が良い結果を出す場面もある。
作り方もかなりローカル志向だ。学習は RTX PRO 6000 の1枚で行い、0.8B は約2時間、2B は約3.5時間で学習できたという。合成データはオープンモデルで生成し、閉じたモデルの出力は学習データに使っていない。公開された Jev と同じリクエスト形式を使うが、TypeSafe とは無関係の独立プロジェクトで、訓練コードも AutoJev のオープンソース recipe を起点にしている。
このプロジェクトでまず面白いのは、生成AIの文脈から少しずらしていることだと思う。今のAI活用は、どうしても「文章を書かせる」「会話させる」に寄りがちだが、実務で本当に回したいのは、問い合わせの振り分け、ラベル付け、危険判定、コマンド選択のような単純な分岐だったりする。Jeff はそこを真正面から狙っている。しかも出力は文章ではなく確率なので、後段のコードが扱いやすい。人間が読む自然文より、システムが飲み込むにはずっと都合がいい。
一方で、こういう分類器は「なんでもLLMでできる」と思っている人ほど軽く見がちだが、実際にはかなり価値がある。問い合わせのルーティングが1回の判定で済めば、下流のオペレーションが全部軽くなる。著者が示した 22ms や 28ms という数字は、ただ速いというより、業務の前段に常駐させられるレベルだという意味で効いてくる。会話AIのように待たせないのは、UXだけでなく運用費にも直結する。
もうひとつ引っかかるのは、単純に大きいモデルが正義ではないと、かなりはっきり出していることだ。ベンチマーク全体では2Bの方が少し良い場面もあるのに、ゲームでは0.8Bが上回るケースがある。これは、モデルサイズを上げればあらゆる実運用が良くなる、という雑な期待を崩している。少なくとも「迷い方」が違うのだろう。
ここで重要なのは、著者が0.8Bを推している理由が、単に安いからではないことだと思う。小さいモデルの方が速く、しかも十分に校正された確率を返せるなら、現場ではむしろそれでいい。多くのプロダクトは、最難関の推論を求めていない。必要なのは「そこそこ以上に当たる」「速い」「ローカルで回る」ことだ。Jeff の数字は、その条件を満たす範囲が思ったより広いと示している。
元記事で好印象だったのは、ゼロショットで万能ではないと明言しているところだ。著者は、確率を返す分類器であって planner ではないと言い切っているし、未来予測のような問いには強くないとも書いている。ここを曖昧にしないのは大事だ。今のAIまわりは、モデルが賢そうに見えるせいで、用途を取り違えやすい。だが Jeff の得意なのは「選択肢の中から選ぶ」ことであって、「状況を理解して次の一手を考える」ことではない。
そのうえで、短い fine-tune が効くという実例も出している。voice-navigation のファインチューニングで held-out accuracy が 31.7% から 95.8% に上がり、1枚GPUで30分ほどだったというのはかなり強い。つまり、このモデル群の価値は、ゼロショットでそれなりに使えること以上に、自分たちの業務データで素早く追い込めることにある。汎用賢さを買うのではなく、現場専用の判定器を短時間で育てる。そういう使い方に向いた設計だと感じる。
Jeff のもうひとつの意味は、モデルそのものより「どう作ったか」を開いた点にあると思う。学習はローカルGPUで完結し、合成データもオープンモデルで作る。閉じたモデルは学習に使わず、品質確認だけにとどめた。こうした手順は、再現性のある実験としてはかなり重要だ。大きなAPIに依存したデモでは、使う側が同じものを再現できないことが多いが、Jeff はそこを避けている。
もちろん、これがそのまま全ての現場に当てはまるわけではない。使う選択肢の設計、文言の揺れ、データの偏りで結果はかなり変わるはずだ。実際、元記事でも wording が極めて重要だと強調していて、選択肢の書き方を揃えるだけで成績が変わると述べている。つまり、モデル単体の性能だけでは済まない。だが逆に言えば、そこまで細かく設計する余地があるのが、この用途の面白さでもある。生成AIの派手さはないけれど、業務システムの中核にはこういう地味な判定がずっと必要で、Jeff はその現実にかなり正面から向き合っている。
参考: GitHub - firelex/jeff: Fine-tunes of Qwen3.5 and Gemma 4 for zero-shot classification
