羊・ヤギふれあい広場的なところでは、怖がって泣いちゃうかもな、と思っていたのだが、羊のモフモフの毛並みが気に入ったのか、追いかけて果敢に触る。お気に入ったようで何より。休日だから、餌をあげる人が多く、餌を持っていると突進してくるのだが、餌がないと結構無関心、という距離感もちょうど良い感じだった。

土曜の開園直後は人もまだまばらで良いね。11時ごろには、もうだいぶ駐車場が混み始めていた。この日は天気も良く、近くてすぐ来れるのも最高である。

朝食。最近は八方だし、がよく食卓に並ぶ。

鬼が首あたりからの、遠くの山々が連なるパノラマの風景も良いんだよなぁ。

木々は徐々に葉が落ちたり、紅葉したりしだしていたり、小さなススキのような植物が見えたりと、すっかり秋の装い。

下山後、子鹿の湯で温泉で疲れを癒す。昼食はお久しぶりのグリルシェフでハンバーグ。その後は那須SHOZOへ行く予定だったが、休業日だった、残念。基本休みなしなのだが、連休後などは休みがあったりする。ゆっくり休んでください。

ベコ氏をお迎えに行った帰り道に、那須パラダイスヴィレッジへ。やたらとハローウィンに手が混んでいて、至る所でお化け屋敷のよう。ベコ氏はまだホラー物を「怖い」という認識ではなく、興味深そうにキョロキョロ見回っていた。

作ってみての感想は、そんなに難しくなくて、フロンティアLLMモデルを作っている各社なら、まぁ作れちゃうだろうなぁ。学習のための合成データセット作成がポイントなので、自分のところのモデル(成果物のライセンス気にしなくて良いし)と推論GPUを大量に使えリソースも潤沢だろうし。テキスト生成に比べたら確率生成は簡単なタスクだと思える。

画像への対応や、より安価で高速なモデルは予定調和として今後出てくるだろうけど、System One の使い道は、1 request でできることに閉じちゃう（だからこそ良い）ので、今の AI Agent のようなハーネス・環境含めて提供し学習のループを回し、といった付加価値を作ることが難しそう。とすると他のLLM 企業に模倣されて終わってしまうのでは。ちょうど OpenAI が Luna Decision 的なモデルを発表したようだしね。

TypeSafe AI は、Jev で、汎用 Classification モデルの需要があることを証明したことは価値があって素晴らしいと思うが、予定調和の進化だと他社に真似されて負けるだろうから、その先はどうなるんだろうね。自分が考えついてもないような視点でイノベーションを起こしてくれると面白いので、期待だね。

K氏の日記を読んで作ろうと思った(妻が)、という長谷川あかり氏のレシピ、焦がし醤油のハヤシライス。シャバシャバ系。スープハヤシライスっぽい感じで、サラリと食べれる美味しさ。

そこで今回、小型なモデルだとどれぐらいの性能が出せるのだろうと、System One Decision モデル の bekko-system-one-v0（以下 BS1）シリーズを制作してみました。汎化性能は Jev の方が圧倒的に上ですが、S1MB（System One Mosaic Benchmark）（注：著者作）では、小さなモデルながら、ほかの大きなサイズのモデル並みの結果が得られています。とりわけ、学習しているドメインのタスクでは、なかなかの精度で利用が可能です。

• 🤗 bekko-system-one collection

なお対応言語は、英語のみとなっています...。

ブラウザ上で実行可能

本モデル(英語のみ対応)は 17M、68M、400M パラメーターの3つのサイズのモデルを公開しており、とりわけ 17M や 68M の小型モデルは、ブラウザ上にモデルをロードし、CPU での推論も十分な速度で可能です。

• ブラウザ上でモデルを動かし、推論するデモ

注意: なおこのデモは、BS1 モデルで解きやすいタスクを恣意的に選んでいるため、ぱっと見の性能は良さそうですが、Jev のような「幅広いタスクで高性能」なわけではないので、ご注意ください。

また、17M パラメーターというのは、総パラメーター数が約17Mで、そのうち埋め込みを除くパラメーター数は、たったの約4Mです（ここでは Active Parameters - AP と呼びます）。ブラウザ実行用に、token の lookup table だけを INT8 にしたものを ONNX へと変換しており、モデルファイル単体のサイズは、たったの約29MBとなります。

評価ベンチマーク

ブラウザで動いたとして、実際のモデルとしての性能はどんな感じでしょうか。というわけで評価をしてみました。S1MB - System One Mosaic Benchmark という、私作のベンチマークを使っています。このベンチマークは、後述のデータセットのうち、test set のデータを中心に、原則100ケースを抽出した、137個(Noul 59, Choice 57, Score 21)のベンチマークで構成されており、Noul、Choice、Score の3軸で評価しています。

S1MB については、S1MB記事で書いているので、詳細は割愛しますが、総パラメーター数500M以下に絞ると以下のような結果です。BS1 も、超小型としては、かなり健闘しているのではないでしょうか。なお比較のために Jev 1.13 も載せています。

AvgはNoul・Choice・Scoreの調整済みスコアを等重みで平均した値です。各スコアは高いほど良く、正解率そのものではありません。

しかしながら、S1MB に含まれる「汎化性能を計測する」ベンチマーク(GPT-6-Astra で生成した合成データセット)では、BS1 モデルは圧倒的に性能が悪いです。これは「特定ドメインを学習したデータセットなら、ある程度の性能は出るが、自由な指示や未知のドメインについては弱い」と言えるでしょう。なので、今回公開した BS1 も「汎化性能を持った System One Decision モデルに達していない」ことから version 0 として、-v0 suffix をつけています。

全体評価と同じモデルについて、汎化性能の6ベンチマークに絞った結果です。Avg順に並べています。

なお、Jev はドメイン特化性能（特別にそのドメインを学習したわけではないのに、すごいですね）も、汎化性能も、特筆したスコアですね。とりわけ汎化性能のスコアについては、ほぼほぼ満点と言えるでしょう。つまり、汎化性能が高い System One Decision モデルを名乗るには、最低限この汎化性能ベンチマークで、Jev 並みのスコア（つまりほぼ満点）を出せないと、あまり意味がないと思っています。

モデルサイズと推論速度

BS1 モデルで、特筆すべきことはモデルサイズと推論速度です。GPU（RTX 5090）を使ったS1MBの26,269件の評価処理は、17Mで約13.33秒、68Mで約34.04秒、400Mで約132.97秒（約2分13秒）でした。17Mでは、モデルロードと各ベンチマークのデータ読み込みなどを含む計測区間の合計でも約21.38秒です。冒頭のデモのように、ブラウザ上でも現実的に動きます。

なおJevはAPI経由となり、通信待ちなどを含む各ベンチマークの評価時間の合計は約58分37秒でした。APIの応答時間はタイミングによって前後するでしょう。ここで示した値は評価処理の計測値で、純粋なモデル計算だけの時間ではありません。また、17Mの約21.38秒もwarmupなどを除く区間の合算で、コマンド開始から終了までの時間ではありません。

技術アーキテクチャでの取り組み

Bekko System One（以下 BS1）で工夫したのは、複数の選択肢を判定するときに、共通する入力の処理を使い回すことです。その方法の前に、まず一般的な encoder model で、Jev のような処理をする、よくある方法の二つを解説しましょう。

cross encoder

通常の双方向 encoder を使う cross encoder では、以下のように、共通する入力と選択肢を組み合わせて処理します。特殊トークンは模式的な表記です。

[CLS] {state} {instruction} [SEP] {criteria A} [SEP]
[CLS] {state} {instruction} [SEP] {criteria B} [SEP]
[CLS] {state} {instruction} [SEP] {criteria C} [SEP]

先頭の CLS トークンの表現や、トークンの表現を平均したベクトル（mean pooling）を、学習済みの head に渡してスコアを求めます。情報検索の reranker でも広く使われている方式です。

入力と選択肢がお互いを参照できるため、細かな対応関係を捉えられます。しかしながら、state が長いと、同じ文章を選択肢の数だけ処理することになります。前半の表現も後半の選択肢によって変わるため、前半が同じ文字列でも、途中の計算結果をそのまま使い回せないのです。

なお情報検索の reranker では、前半に配置する検索クエリが短いことがほとんどのため、共有による計算量削減の効果が小さく、cross encoder でも良いケースが多いですね。

listwise encoder

それなら、選択肢をまとめて一回で処理しちゃおう、という方法もあります。全候補を連結する listwise 方式では、例えば以下のように入力します。

{state} {instruction} [SEP]
{criteria A} [SEP] {criteria B} [SEP] {criteria C} [SEP]

候補ごとの表現や候補前後の特殊トークンを pooling するなどして、スコアを求めます。共通部分を一度で処理でき、選択肢同士も参照できるのが利点です。

一方、候補が多いと入力全体が長くなります。全トークン間で attention を計算する場合、その計算量は長さの二乗に比例するため、多数の候補をまとめると負担が増えます。cross encoder より常に遅いということではなく、文章の長さや候補数によって向き不向きがあります。

BS1 の方法 - 共有 prefix

BS1 では、state と instruction を一つの共有部分（prefix）として処理し、各層の Key/Value、いわゆる K/V を保存して使い回します。

{state} {instruction} → 各層の共有 K/V
                          ├─ {criteria A} → score A
                          ├─ {criteria B} → score B
                          └─ {criteria C} → score C

普通の cross encoder と何が違うの？と思われるかもしれませんが、ここでは参照できる範囲を変えています。共有 prefix は選択肢を参照せず、各選択肢は共有 prefix と自分自身だけを参照します。これなら、選択肢が変わっても共有部分の計算結果は変わらないため、一度計算した K/V を再利用できます。

LLM の KV cache と同じように K/V を保存しますが、次のトークンを一つずつ生成するわけではありません。共有部分を処理した後、各選択肢を並列に処理し、候補側の表現を mean pooling して head からスコアを求めます。

候補側だけを pooling していますが、候補の文章しか見ていないわけではありません。各候補は各層で共有部分を参照するため、state と instruction を踏まえた表現になっています。一方、共有部分の先頭に置いた CLS トークンは候補を参照できないので、その表現だけでは候補ごとの判定はできません。

これによって、長い state と instruction を選択肢ごとに処理し直す必要がなくなります。ただし、通常の cross encoder と同じ計算を、そのまま高速化したものではありません。通常の cross encoder では、候補に応じて入力側の表現も変わり、その情報を候補側が再び参照できます。BS1 では、この相互のやり取りを制限する代わりに、共有部分の計算を使い回しています。

そのぶん、細かな対応関係を捉える自由度は通常の cross encoder の方が高いと考えられます。ただ、実際の精度差はタスクや学習条件にもよるでしょう。

なお、state と instruction はまとめて双方向に処理しています。state だけを独立してキャッシュしているわけではないため、instruction を変えた場合は共有部分を再計算します。

また、今回は、criteria 同士が参照できるような attention は含めてません。本来、例えば Choice のようなケースですと、他の criteria を参照した上で回答した方が精度がありそうですが、短時間で試しただけでは、精度が上がる学習ができなかったです。なおこれは無理だ、と言っているわけではなく、私が試した方法でうまくいかなかっただけの可能性も十分あるでしょう。

大元の base model

大元の base model としては、ModernBERT アーキテクチャの英語高性能モデルである Ettin-encoder を、さらに教師 reranker モデルを用い cross encoder として学習した Ettin-reranker を利用しています。

ModernBERT などの MLM、いわゆる pretrained model の状態では、検索クエリとドキュメントの関連度を直接スコア化するようには学習していません。情報検索向けデータを学習した Dense Embedding モデルや、cross encoder モデルでは、文章とドキュメントの関連性を理解しているため、今回はすでにそれらを学習済みの Ettin-reranker を使っています。小型ながら、英語 rerank 性能は非常に高いです。今回の BS1 では、Ettin-reranker を base model として用い、追加学習を行いました。

以下は Ettin-encoder、Ettin-reranker を base model とし、各データセットに上限を適用した学習データの全量を、同じ条件で学習させた対照実験の結果です。68Mではreranker初期化が総合CE・各型のaccuracyで良く、17Mでは総合CEは僅差で、Noul・Choiceはreranker、Scoreはencoderが良い結果でした。

CEは小さいほど良く、accuracyは大きいほど良い指標です。データセットごとに集計し、二つの入力順序の結果を平均しています。前掲の調整済みスコアとは指標が異なります。各条件1 seedでの比較です。

データセット

データセットでは hotchpotch/bekko-system-one-dataset-v0 を利用しています。このデータセットは、既存の NLP や情報検索関連のデータセットを、Noul、Choice、Score の3形式として学習しやすいように変換した 153 個の学習データセットで、training set は約659万ケースとなっています。一部は合成データセットも追加してあります。なお、このデータセットの test set は S1MB のベンチマークにも転用しているので、同じドメインの training set で学習した BS1 は S1MB の一部ベンチマークのスコアが上がりやすくなっています。

BS1 では、このデータセットを用いて学習を行いました。学習には RTX 5090 を用い、17M の学習では、たった2時間で学習を終えました。なお 68M では5.5時間、400M では約25時間でした。

学習のハイパーパラメーター

学習のハイパーパラメーターやデータセットの件数などは、細かくは解説しませんが、bekko-embedding 論文（私作の、超小型マルチリンガル dense retrieval model の論文です）で書かれている知見を主に、いくつかパラメーターを試し、その範囲で良い結果が得られた値を使っています。

学習用の実装も公開しているので、この実装を使うことで、同様のモデルを学習可能です。興味がある方は、ご利用ください。

• bekko-system-one：学習・推論コード

超小型の System One Decision モデルは実現可能なのか？

将来は、S1MB の汎化性能ベンチマークでも Jev 並みのスコアに達する、アクティブなパラメーターサイズが100M以下といった、超小型なモデルも可能である、と思っています。それを達成するための、最も重要なことは、学習に必要な高品質な合成データセットです。

TypeSafe AI CEO の Diogo Almeida 氏も「100% of our data is synthetic (but not the type of crap that is just spit out from an LLM obviously)」と言っているように、Noul、Choice、Score で、ありとあらゆる質問と適切なスコアの合成データセットが用意できれば、超小型モデルも実現可能だと思っています。どうしても「モデルアーキテクチャ」に目線が行きがちですが、高品質で齟齬がない多様な合成データセットをどのように作り、それをどのように学習するか、が肝心でしょう。

実際に、私作のマルチリンガル情報検索モデルである bekko-embedding シリーズでは、10億以上のデータ（うち1.6億件が合成データセット）を、巨大バッチで学習させることにより、アクティブパラメーターサイズが 8M、25M という超小型サイズのモデルで数倍〜数十倍の情報検索モデルに匹敵する情報検索モデルが作れています。

続いての重要なことは、強力な base model の登場です。実用的なテキスト生成能力を持つ LLM（decoder）を超小型にするのは難しいため、文字列生成にこだわらなければ、もっと小型で性能が良い base model が作れるでしょう。ModernBERT はその例だと思いますが、現状のさらに発展し続けている LLM のモデルアーキテクチャを使い、さらに小型モデルでより良いアーキテクチャと、大量の多様なデータを学習させた base model があれば、その継続タスクの学習に効いてくるでしょう。ただし、合成データセットの方が重要度は非常に高いとは思っています。

終わりに

TypeSafe AI の System One Decision モデル、Jev の登場により、汎化性能が高い Classification model の有益性が証明されました。TypeSafe AI の素晴らしい点は、中途半端な汎化性能で出すのでなく、フロンティア LLM に並ぶ性能の超汎化性能を持つモデルを作り上げ、出したことでしょう。

Classification で解決できる課題は、思った以上に広いです。BERT 以降、分類やスコア付けなどの NLP タスクでは Transformer encoder が広く使われてきました。

本記事では、学習したタスクなら、ブラウザ上でも動くほど小さなモデルである程度の精度を出せる、bekko-system-one-v0 を作ったお話でした。学習済みのタスクで小型モデルを試したり、独自データで追加学習したりするための出発点として、モデル・データセット・学習コードを公開しています。

幅広い未知のタスクへの対応は、今後の課題です。前項で述べたとおり、大量の良質なデータセットや、小型モデルアーキテクチャの進化により、十分な汎化性能を持った System One Decision モデルは、きっと開発されるはずです。

この bekko-system-one-v0 が、何らかの価値につながれば幸いです。

参考URL

bekko-system-one

• bekko-system-one collection
• bekko-system-one-v0-17m
• bekko-system-one-v0-68m
• bekko-system-one-v0-400m
• ブラウザデモ
• 学習・推論コード
• 学習データセット

S1MB

• 評価コード
• 評価データセット
• 評価結果リポジトリ
• Leaderboard
• S1MB の紹介記事

base model・関連モデル・資料

• TypeSafe AI — System One / Jev
• TypeSafe AI — モデル一覧
• Diogo Almeida 氏の合成データについての投稿
• Laya：コード / モデル
• ModernBERT-base
• Ettin：Seq vs Seq 論文
• Ettin-reranker-17m-v1
• Ettin-reranker-68m-v1
• Ettin-reranker-400m-v1
• bekko-embedding-v1-a8m
• bekko-embedding-v1-a25m
• Bekko Embedding 論文
• Sentence Transformers — Cross-Encoders

けんちゃんの朝顔（あさがお交通安全プロジェクト）というんだね。襟を正して運転しないと。

運転免許は、マイナ免許証を発行してもらう。普通の免許証も発行でき、マイナカードでも、免許書でも、どちらか携帯していればOKになって良いね。

せっかくなので、警察署近く(ではないが)の那須パラダイスヴィレッジで作業する。WiFi 使えるし、平日はお客もそんなに多くないしで、快適。こっち方面で作業したい時は良い場所だなー。

遅めの昼食は、麺'sラッキーパンチで、店名にもなっている「ラッキーパンチ」を始めていただく。辛いもつ入りラーメン。旨辛っ〜〜〜。

こういう、何気ない日々のふつうの幸せの話が、時々友人の日記などに書かれるのだけど、読むたびに心温まるのであった。

そしてさくらももこ氏のエッセイ本はたくさん出ていて、どの本に書かれた話だっけ、というのが思い出せなかったが、エーアイ氏に雑に聞いたら速攻正解を出してきてすごいな…。「まる子だった」の「七夕祭り」の回だった。エーアイ氏もすごいが、wikipedia にエッセイの収録の概要をコツコツとまとめた人がすごいね。

ボールプール。100均のボールなので、もっと増やししたいが、ベコ氏がプールごとひっくり返して毎度片付けが大変なのであまり増やせない。ひよこの形のボール（ではないが）も8つほどあって、形が認識できるので、取り出す遊びを楽しんでいる。

白河ラーメンが食べたいぞ、ということで焔に。見た目油どっぷり、だがスルッと食べれちゃう。おいし〜〜。

猪苗代観光船、何度も猪苗代湖に来ている割に一度も乗ったことがなかったのだけど、大満足だったなぁ。また乗りたいね。今度は晴れの日の磐梯山を船から眺めたいぞ（この日は曇りで、山頂付近は見えなかった）。

早めの昼食は、猪苗代観光船のすぐそばのMINATOYAのパン屋、みなとやベーカリー猪苗代で。パンとエスプレッソ、という有名店が監修しているらしい。とりわけ、しらすパンが美味しいかったなー。たくさんある窓際の席からは、猪苗代湖が見れて素晴らし。横浜・湘南あたりのようだ。家からだと海は割と遠いが、海のような猪苗代にすぐ(?)来れてこれまた最高。

亀ケ城公園散歩。散歩すると、興味があるものを立ち止まっては拾い、でなかなか進まない。ほんとどこでも楽しそうだ。

毎度お馴染み、KUUHAKU に立ち寄り、今月の個展を見る。鈴木太郎氏の素敵な作品があったので、お迎え入れすることに。ラッキー。KUUHAKU を知る前は、アート作品とは縁がないと思っていたが、「くらしに、アートを」がコンセプトなだけあって、自分が好きなものに出会え、自分で選んでお迎え入れして良いのだ、という気持ちが芽生えたので、ありたが嬉しいね。

しゅっと15時過ぎには家に到着。今日の猪苗代も最高だったね。

ベコ氏が朝寝(8-9時ごろ)と、昼寝(13-14時ごろ)のタイミングに車移動すると、ベコ氏はスヤリと寝れる(車だと振動が良いのか、寝つきが良い)し、日帰りはこのリズムで出掛けることに慣れてきたなぁ。

お昼はHimal Curry tanrenでダルバート。ダールの深い味付けがしみじみ美味しい。ネパール帽子もかぶっていて、ヒマラヤへの愛も感じられるのもまた良し。

ベコ氏の保育園の先生の個展が開かれている、ドライフルーツ屋のヴァーモスへ。ヴァーモスは土曜だけカフェが開いているようなんだけど、このカフェのロケーション、素晴らしいね。南米エクアドルにご縁があるというオーナーの、エクアドルドライフルーツ、とりわけドラゴンフルーツのドライフルーツが美味しくて、自分用にも購入しちゃった。店内は南米雑貨も置いてあり、3年前に行った南米を懐かしむ。

ベコ氏は、普段抱かれ慣れている保育園の先生なので安心、と思いきや泣いちゃう。先生曰く、小さい子供は場所とセットで人を覚えることが多く、別の場所で会うと別人だと思っちゃうことも多いらしい。なんと！

先生の個展は水彩画で彩りが美しい、ベコ氏をイメージしたイラストなども描いてもらう。絵を描くいたりして表現することを、とても楽しそうに話されて、こちらも温かい気持ちに慣れて感謝だ。

昨日今日、集中してエーアイ氏にお願いして、たくさん働いてもらったら、ChatGTP Pro(月200USDプラン)の weekly limit を24時間程度で75%も使ってしまった。大体 Astro low なのにね。こんな短期間にガッと減ったのは初めてだ。

リセットがあと2回残ってるから良いとはいえ、エーアイ氏が賢くなり、雑指示でも割と長期で働いてくれるようになっているため、エーアイ氏の仕事量がたくさん増えちゃったね。

朝、ベコ氏を抱え散歩をしていると、一年以上前にお話ししたことがある、ご高齢のおばあちゃん（犬連れ）と出会い、おしゃべりする。曰く、最近長年連れ添った夫が亡くなって悲しい、昔の人だから「おい」「お前」と呼ばれていたが、余命宣告を受けた今際に肉声を録音しようということになり、「{お名前}、一緒になってくれて、ありがとうな」と。名前なんて呼ばれてこなかったから嬉しかったと。こんなホロリと来る話が近所の散歩で聞けちゃうなんて。思わず自分も涙ぐむ。

妹一家が行った、東南アジア旅行動画を見る。あー楽しそう。海外旅行行きたいね。

昼食、ドミノピザの宅配。宅配ピザ懐かし〜〜〜！！

typo さん作の、Play Diablo IV on Macの記事で書かれているtypester/sake、Mac で Windows Steam のゲームが普通に上手く動いちゃってびっくりする、すごい。steam.exe が立ち上がり、動くゲームは steam cloud save なども含めてサクッと動いちゃう。動かないゲームもあるけど、7-8割ぐらいは上手く動く感じがするぞい。

と言うわけで動作確認をしていたら、いつの間にかゲームをしてしまい時間が過ぎていったのであった…。

実家へ。ベコ氏は実家のみんなにこれでもか、という程に可愛がられて、何をしても歓声が上がる。ずーっと楽しそう。寝る直前もハイテンション。みんながハイタッチをしまくるので、ハイタッチを覚える。

夕食の豚しゃぶ。白だし + 天かすのタレとあって、めちゃうまだった。

ツリバナ、今年も可愛く実る。ベコ氏はツリバナがお気に入りで、赤い実を摘んでは潰してしまい赤に染まる…。

一週間前に刺された山蛭の箇所が、猛烈に痒くなる。掻くと血が出て、かさぶたになり、また痒くなるを昨日から繰り返している。あーかゆい。

玄関の安価なワイヤレスチャイムの母艦が壊れた(2年も使ってないのになぁ)ので、同じようなものを購入する。今回買ったのは、Umimile ワイヤレスチャイム 自動発電なのだけど、電池不要(押した力で発電する)な物も、安価なものであるんだね。電池はどこだ？と届いた時探してしまった、商品名にそう書いてあるのに。耐久力は不明。

庭の芝を追加で敷いてもらったり、石を敷き詰めてもらったりと外構工事をしてもらう。家を建てるタイミングでやっておくと、出戻りがないんだけど、実際に住んでみてもうちょっとここがこうなるったら良いな、というのが出てくるので、住んでみてから徐々に外構をやっていきである。

• https://github.com/hotchpotch/jev-reranker/

RAG などで検索を利用している場合、検索結果には引っかかるが、回答生成には不要なデータが返ってくることが多くあります。この場合、LLM に全て不要な結果も含め渡すと、処理速度やトークンコストが余計にかかってしまい、場合によってはハルシネーションを起こしかねません。

また全く適切な検索結果がなかった場合は、LLM に渡す前に処理を切り上げたり、別の検索クエリを検討したりできるので、閾値によって不要なデータを削ることができる、スクリーニング用途にも使える relevance rerank filter は単純な並べ替えの rerank よりも重要になるケースが多々あります。本記事の後半でも述べますが、NanoHotpotQA では、検索候補の約92%を削減しながら、nDCG@10で0.975を達成しています。

イメージとしてはこんな感じで、関連しないドキュメントはスコアがかなり低く出るので、閾値を使った足切りがしやすいですね。

relevance rerank filter としての利用例

以下のように簡単に利用ができます。

uv add jev-reranker

from jev_reranker import JevReranker

query = "How long do I have to return an online order to ACME Shop?"
documents = [
    "ACME Shop accepts online returns within 30 days of delivery.",
    "For ACME Shop online orders, submit your return request within 30 days of receiving the item.",
    "ACME Shop in-store purchases can be returned within 14 days of purchase.",
    "ACME Shop products come with a one-year repair warranty.",
    "FooBar Shop accepts online returns within 60 days of delivery.",
]

reranker = JevReranker(api_key="YOUR-TYPESAFE-API-KEY...")
response = reranker.relevance_rerank(query, documents, threshold=0.2)

for item in response["results"]:
    print(f"{item['score']:.2f}  {item['text']}")

結果の出力例は以下です。後半の3つはなんとなく似ていますが、実際は紛らわしい回答なので、閾値未満のため削除されてます。

0.98  ACME Shop accepts online returns within 30 days of delivery.
0.97  For ACME Shop online orders, submit your return request within 30 days of receiving the item.

relevance rerank と rerank は何が違うの？

ここが Jev の面白いところで、異なるのはインストラクション（指示文）のみです。query に強く関連があるかないかだけで評価すると、ソートに適した rerank になりますし、RAG の検索後処理で利用したいような「質問の回答に関連が低いものは極端に低スコア」のような指示文を入れれば、relevance rerank filter として使うことができます。これも Jev の汎化性能の高さゆえですね。

Jev の評価結果

今回は、マルチホップ QA データセットである、HotpotQA の情報検索用にサンプリングされたデータセットの NanoHotpotQA に対して、以下のような評価を行いました。

• NanoHotpotQA を BM25 と dense（harrier-oss-v1-270m）検索を用いて、Hybrid 検索を行い、Top-100 を抽出。もし Top-100 に正解がない場合は 101 件目に正解を挿入
• その結果に対して、nDCG@10 の結果を取得

つまり query 50 に対し、各々検索結果上位の 100（or 101）件に対して rerank するようなベンチマークタスクです。結果は以下です。

評価方法と再現手順は、評価スクリプトの利用ガイド にまとめています。今回の評価では NanoBEIR-en の NanoHotpotQA を使い、候補数を制限せず、50クエリそれぞれの hybrid 検索結果100件を対象にしました。採点方式は listwise、閾値は rerank が 0.0、relevance_rerank が 0.2 です。同じスクリプトで Hybrid search の nDCG@10 も確認できます。

特筆すべきは relevance rerank filter の文書の削減率です。これは、閾値（0.2）未満のスコアのものを全て関連しないとして削除した時の削除率で、1 query あたり、100件の検索結果を平均約7.6件にフィルターで効率よく削除・スクリーニングができています。検索ドキュメントのうち、質問に対する関連性が低いと判定された文書約92%も、この段階で削除ができてるのです。

さらに削除した結果の nDCG@10 も 0.975 と非常に高く、削除したからといって検索結果が劣化しているわけではありません。

RAG のパイプラインで、query に対して検索結果のドキュメント 100 件を取得して、全て後の LLM に渡すと、前述の通り非常に高コストです。しかしながら、この relevance filter を使うことで、1 query あたり平均約7.6件しか渡さずに済んで、かつその中に正解が含まれています。そのため、低い性能の LLM でもハルシネーションを起こす可能性がグッと低くなるでしょう。

このように、jev-reranker の、とりわけ relevance rerank filter を使うことで、query に関係がない検索結果を大幅に削減することが可能なのです。

また、この閾値も柔軟に変更が可能です。例えば見逃すと損害が大きいシステムでは <= 0.05 などにできますし、検索に関連しなそうなら大胆に結果を削除して良いなら、<= 0.5 なども考えられるでしょう。また前述の通り、インストラクション文章を変えれば、自分自身のシステムにあった relevance filter を作成することが可能なのです。これが Jev が注目されている、汎化性能の高さですね。

なお、この結果は、jev-1.13.0 の結果に基づいています。Jev のモデルが更新されると、結果が異なる可能性が高いです。

余談ですが、高性能 reranker としてよく使われている、reranker に特化した cross-encoder である bge-reranker-v2-m3 並みの rerank 性能も、手元では確認できているので、気になる方は評価してみてはいかがでしょうか。

なぜ jev-reranker ライブラリを使うのか？

実際のところ、Jev の API をそのまま叩いても十分機能するのですが、この jev-reranker は情報検索の実利用で便利な機能を最初から実装しています。

listwise or pointwise（pairwise）

Jev では、rerank する際に 2 つの手段が考えられます。1 つは [query, doc1, doc2, ...] など 1 つのコンテキストに全て埋め込む listwise の手法、もう 1 つは [[query, doc1], [query, doc2], ...] と、query と doc の pair を毎回リクエストする pointwise の手法、2 パターンがあります。

jev-reranker ではこの 2 つの方法、両方に対応しています。比較してみたところ、基本的に listwise の方が高速かつ精度が良いので、デフォルトは listwise にしていますが、pointwise の方が良いタスクもあるかもしれません。

また、Jev は現状最大で 32k token しか含めないため、とりわけ listwise の 1 req に全てを詰め込む方法では、max token になってしまいがちです。そのため、適切に文字列長 or token 長で分割してリクエストを送るようにしています。本当は Jev tokenizer が公開されていれば、事前に 32k token を超えていないかが観測できるのですが、残念ながらまだライブラリや API 共に token の長さを事前に測る方法は、公開されていないようです。

並列性

毎度 1 つ 1 つを直列で叩くと非常に遅いため、最初からある程度並列リクエストを叩きます。そのため、高速な処理が可能です。もちろん、設定で並列数は変えられますし、レートリミットでエラーになった場合は時間をおいて retry 等々の再開・例外処理も実装されています。

そのため、jev-reranker を使うことで、rerank、relevance filter に適したインストラクションプロンプトはもとより、これらの便利機能も利用可能なので、よかったら使ってみてくださいね。

• https://github.com/hotchpotch/jev-reranker/

Jev の感想というお気持ちというか

Jev は、巷の評判の通り、LLM では遅く、かといってなんらかの特化 model を学習するにはコストが高すぎる、適切にモデルを作成できる人材がいない、ような用途の隙間にピッタリとハマる、汎化性能が高い structured decision モデルです。

また、汎化性能の高さ、というのも魅力です。検索結果はコンテキストによって優先すべき結果が異なるため、それを instruction により制御できることは、今後重宝されていくでしょう。情報検索タスクの一部である reranker や relevance filter としても、現時点でも性能の高さが窺い知れますね。

そんなわけで、Jev の出現は「今までになかった、隙間を埋める汎化モデル」として非常に喜ばしいですね。また Jev のようなモデルが流行ることによって、別の企業・研究機関なども同様の方向性のモデルを出してくる流れになることは間違い無いでしょうから、その点でも Jev の登場は嬉しいですね。今後の AI 関連技術の発展が見えるような、ワクワクするモデルの登場でした。

というわけで、昼はgarden AUX PARADIS。広いし、適度に騒がしい（子供が騒いでもあまり気にならない）し、料理は美味しいし、ベコ氏も食べれるものが増えてきたしで、引き続き最高である。ベコ氏はロールケーキのフルーツを少々与えると、気に入ったのか、幼児用スプーンでフルーツ1つをまるまるすくい上げ、口に方張る。フォークの使い方も上手になってきたなぁ。

夜は久しぶりに夜鍋して、jev-rerankerなどを作る。昨日作った Jev 評価用 reranker をライブラリとして切り出して、検索結果の足切りフィルターとしても使いやすくしたもの。はー Jev 面白いね。

これは本格的にベンチマークを取らねば！とJev を reranker として計測できる実装を書いて、APIの無料枠を超えたので課金し、英語blog記事を書いて、みたいなことを進めていたら、エーアイ氏が「利用規約 Aug 27, 2026 2.3-fではベンチマーク結果の公開NGですよ？良いんですか？」と教えてくれる。まじか。確認するとちゃんと書いてあるね…。というわけでしばしお蔵入りとなったのであった。そのうち解禁されるだろうから、その時また…。

自分の仕事の1つは、特化性能が高いモデルを作ること(LLMにやらせるより100-1000倍ぐらい速く、かつ安価)だったりするが、Jev のような汎化性能が高くて速度も費用対効果も十分なモデルが溢れてきたら、その仕事の価値はだいぶ目減りしちゃうね。

近隣の草木が身をつける。1つ目の球状に身をつけているのはウド。2つ目のブドウっぽいものはヨウシュヤマゴボウ、毒。

うーん、いい天気。これはベコ氏と朝散歩の時の一枚。

夕方、良い天気に連れられて、千本松牧場へ。ベコ氏は靴を履いて歩けるようになったので、芝生の上で落ち葉を集めたり、石を集めたり。拾うと親のところに持ってきてかわいい。ただの枯葉も石も、ベコ氏にとっては見慣れぬアイテムで、見つけると嬉しそうに拾って楽しそう。自分もこのように、何もかも新鮮に感じていた時があったのだよなぁ…。

N氏が日記で書いていた、脱法ドラッグについてのルポ「脱法」、読みやすく、内容もアングラカルチャーで一気に読んでしまった。脱法ドラッグ、どんなものかよく分かってなかったのだけどなるほどなぁ。と今 amazon を見ると、ちょうど kindle unlimited 配信してるじゃん！普通の価格で買ってしまったよ。