そこで今回、小型なモデルだとどれぐらいの性能が出せるのだろうと、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

• 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 関連技術の発展が見えるような、ワクワクするモデルの登場でした。

リリース当初、考えもなくとりあえず python で作ってしまったのだけど、どう考えてもパフォーマンスが悪いし python である理由もないので、golang で書き換える。エーアイ氏に書き換えていただく。これで速攻立ち上がるようになり、利用メモリも10M以下となったので、常時立ち上げっぱなしでも気にならない感じになった。起動自体は互換性を考慮し、uvx 経由で golang バイナリが立ち上がるようにしている。

貰ったPR、たまたまかもしれないが、どれも丁寧に作られている。AI Slop 的な PR ではなく、PR がマージしやすいように色々配慮されて作らていてびっくり。コーディングエージェントの性能も上がったので、その辺のやり方もこなれてきている感じがするね。人間が気をかけることが減って、ありがたい限りだね。

やりたかったことは、聴いている音楽(Spotifyを愛用してる)のアートワークを部屋のどこかに表示したかったのだ。だいたいPCかスマフォから、部屋のスピーカで音楽を再生しているのだけど、思った以上にアートワークを見る機会がなく、ランダムに流していると、今流れている曲はなんだろう、と知りたい欲求もちょくちょくあって、どこかで常時表示されていてほしい。

というわけでエーアイ氏に実装していただいた。正確には7ヶ月ぐらい前に作って日々使っているのだけど、ちょっと手直しして公開。Pixoo の API ドキュメントはお世辞にも人間が読みやすい・使いやすいとは言えないのだけど、エーアイ氏なら読み解いてくれて実装してくれて便利。叩けるAPI自体は便利なものが幅広く実装されていて、ドキュメントはとりあえず公開されているだけで十分とも感じる。

• https://github.com/hotchpotch/pixoo-spotify

こんな感じで表示される👇

64x64 ピクセルしかないので、ピクセルアートっぽくなって満足。kawaii。曲タイル取るなどは、美咲ゴシック8pt をオーバーレイで重ね、gif を作り、それを表示している感じ。小さなピクセルフォント様々(ありがたや〜)。プログラムは余っている raspi で動かしている。spotify API は pooling なので反応が若干遅い。イベントで受け取れるといいんだけどねぇ。

つい、やらなくてもいいようなことを、たくさんやってしまった一日。AI Agent により、以前ははやればできるが時間かかるのでやらない・やるべきでないと判断していた開発が雑指示で出来てしまう。それらは本来優先度が高くないのだけど、10分ぐらいで終わるなら、とついやってしまう。設計・実装的には無駄なコードが増えがち・チーム共有の他人への認知負荷も発生するのでなので、マイナスですらある。

今までは数時間〜数日かかった開発が物の数分〜数十分出てきちゃうので、成果が出たと勘違いしてしまうが、むしろマイナス。本末転倒である。もっと考えを広げたり深めたりする時間に使う分だが、AI Agent は毎度ガチャが発生して射倖心を煽る(短時間で良いものが作れるかどうかはギャンブルみがある)からなぁ。issue, PR をこなすと成果が出た気になれてしまうのも良くない。

以前某社にソフトウェアエンジニアとして入社した時、目標設定の際に、開発はしなくて良いから、目標を徹底的に考えて。この目標は小さな積み重ねではなく、到達が非常に難しいが、達成した時に大きな価値につながるものね、というお題をこなしていた時期が1ヶ月ぐらいあった。

目標承認も、上司の部長承認、その後社長承認を経て、初めて開発に取り掛かれる、というものだった。とりわけ社長承認が「うーん、本当？なんか違うんじゃないかなー」という禅問答のような内容で、まぁ解も特になかった(と思う)のだけど、エンジニアだけど手を止めて開発せずに、徹底的に考える、みたいなプロセスには非常に価値があった。何も価値を出せていない焦り（何かを開発すると、とりあえずは価値が出せている感じなり安心できる。新参者は新しい組織で居場所が作れてないから尚更）はあって、入社早々転職を考えたりもしたけど、今振り返るとありがたい思考プロセスであった。サラリーマンなので給料はもらえてたしね、ラッキー。

個人的には、今世に出ている AI を使ったプロダクトの成功は非常に難しいのでは、と思っている。技術進化が速く、あっという間に時代遅れになるから、プロダクトリリースし、そこから進化し続けない限りは失敗する。ほとんどのプロダクトはスタートが今見えているゴールであるし、ユーザが定着するとそれはそれで破壊的変更を入れることが難しい(裏側の見えない部分を徹底的に良くする、みたいな方向になる)ので、AI Agent でガット作っても、ガットの作り直しはリリースしてからは出来にくい。

またAIを使わないプロダクトは、AIによって代替されるなら、今作っても意味がないので、プロダクトを成功させる難易度が、プロダクト実装は簡単になったが、むしろ世の中の流れ的には、非常に難しくなっている。

AI における開発生産性向上も、結局 AI を使ったベストな開発手法なんてしょっちゅう変わっていっているので、あんまり追いかけてもなーと思っている。プロダクトを作るのが難しい今、開発生産性が上がっても事業価値は上がらないから、なら別に組織としては上げなくても良いのでは、とも思っている。時間が経てば、ある程度汎用的なAIとの協調開発手法が生み出されていくわけだし。

例えば今流行りのハーネスも、AIと協調開発しやすい環境を整えましょうやっていき〜〜という感じで、今今AIにおける開発生産性を上げたいならやりましょう、となるのだが、将来 AI ready cloud みたいな完成系が出たタイミングで移行する、でも良いのでは。

流行りのループなんかも、プロダクトにおけるループゴールの設定を考えるには、結果組織が何をゴールにするべきか、そのゴールを提供するための判断材料は、そのためにはコンテキストが必要だからさまざまな方法、例えば Claude Tag を用いて slack でのフロー情報を集めたりして、組織最高のコンテキストメモリを作ってくぞ、みたいな話になったりしがちだが、そのコンテキストメモリの作り方も今後変わっていくだろうし、いやいやそんなみんながデジタルな場所に情報は出さないでしょ、もっと別のところから変えていくべきでは、などとも思ったりする。

組織の価値提供・向上のボトルネックは開発やデジタル作業から別のところに移るのは間違いないので、ではそのボトルネックは自分の組織ではどこになって、どういうふうに変えていくと良いのでは、といった解を考え、変えていくことに時間をかけるべきなんじゃないかなぁ。言うが易しだけどね。

あれこれと無駄なことをやり過ぎてしまった1日を自省しつつ、なにもやらないこと自体が価値になったりもするんじゃないかなー、となにもしなかった1ヶ月間を思い出したりしていたのでした。

ただ、自分が興味を持ったのは巨大な高性能化とは反対の、どこまで小型にできるかというアプローチです。実際の検索に使える性能を残したまま、どこまで小さくできるのか。そこで作ってみたのが Bekko Embedding です。 bekko-embedding-v1-a8m と bekko-embedding-v1-a25m の2モデルでMITライセンスで公開しています。以下では短く bekko-a8m、bekko-a25m と表記します。

小さい方(a8m)のモデルは、Active Parameters（AP）がわずか 7.67Mです。APとはトークン埋め込み参照テーブルを除いた、Transformer演算で使う重みの部分のパラメータです。検索性能も公式の MMTEB Multilingual v2 に含まれる18の検索タスクでは平均スコアをa8m では56.2を記録し、APが約3〜40倍ある multilingual-e5 系の全モデルと BGE-M3 を上回りました。またよりパラメータが大きい bekko-a25m はより良いスコアを出しています。

インストールせずに試すこともできます。bekko-embedding-web のデモはモデルをブラウザに読み込み、そのままブラウザ上で実行します。

小型モデルを作った理由

コーディング・AIエージェントの台頭により、PCの使い方が変わりました。LLMの推論はAPIの先にあるフロンティアモデルが行うため、その部分においては手元のマシン性能は以前ほど気になりません。一方、エージェントが情報を探すための処理は、今も手元のマシンで動かします。ドキュメントの埋め込み(ベクトルに変換)、インデクス作成、コンテキストの探索等々です。

手元のマシンにGPUがないことも多く、低スペックなマシン(Raspberry Piなど)で動かすこともあります。その際 multilingual-e5-large で1万件の文書を埋め込むと、高速なデスクトップCPUでも約8分、Raspberry Pi 5 では2時間近くかかります。しかもクエリの埋め込みはインデックス作成時に一度計算すれば終わりではなく、検索のたびにも推論が必要です。

小さな埋め込みモデル、たとえばAPが30M未満のモデルの選択肢はかなり少ないです。自分が調べた範囲では、オープンなライセンスで利用でき、文脈を考慮する多言語埋め込みモデルのうち、Bekko以外で30M未満かつ検索に使える性能だったのは2つだけでした。2020年に蒸留された MiniLM を初期値にした multilingual-e5-small と、2026年に公開されたAP 28.3Mの granite-embedding-97m-r2 です。

なおModel2Vec などの 静的埋め込み Static Embeddings はさらに小さくできます。ただし、Transformers のような文脈を理解するモデルではなく、性能も低くなります。

モデルパラメータと演算量

多言語埋め込みモデルの演算量は、総パラメータ数だけでは見積もれません。モデルが118Mパラメータと書かれていると、そのパラメータすべてを使って計算するように思えます。しかし、多言語エンコーダでは、その大半が多言語のためのトークン埋め込みテーブルです。Bekkoの場合はこの埋め込みテーブルが256,000トークンありますが、推論時にはこのテーブルを参照するだけです。トークンごとに1つを取り出すため行列積はなく、このルックアップテーブルから読み込むだけです。

各トークンで実際に行列積を行うのは、Transformerブロックに含まれるパラメータです。スケーリング則で用いられるパラメータの数え方にならい、ここではこれらを Active Parameters(AP) と呼びます。総パラメータ数よりもより推論コストを考える際に重要な指標となります。

この Active Parameters (AP) という言葉は別の意味でも使われるため、補足します。ここでいう AP は、ルータがトークンごとに異なるエキスパートを選び、全重みの一部だけを動かす Mixture-of-Experts(MoE) の文脈のAPではありません。Bekko は MoE ではない通常のエンコーダで、7.67Mのパラメータすべてを推論時に使います。パラメータ数から除いているのは、埋め込みのルックアップだけです。

たとえば、multilingual-e5-small は総パラメータ数118Mのうち、APが21.6Mです。bekko-a8m は総パラメータ数106M、AP 7.67Mです。この差が推論時間に表れます。なおこのAPだけで速度が決まるわけではありませんが、小さいほど基本的に推論が高速です。

Bekko Embedding

Bekko は、22層の mmBERT-small エンコーダを4層(a8m)と13層(a25m)にそれぞれ pruning し、これらの2モデルを約11億の多言語ペアで学習しています。

• 100以上の言語を含むデータで、言語横断検索ができるように学習しました。翻訳を挟まず、日本語のクエリから英語の文書を検索できます。後述する言語別評価では、そのうち14言語を扱います。
• どちらのモデルも8,192トークンまで入力できます。
• 出力は384次元です。Matryoshka学習により、256 / 128 / 64次元へ切り詰めて使えます。bekko-a25m を256次元にすると、検索性能は HAKARI-Bench Overall が相対で約1.3%、128次元では約6.2%低下します。
• モデルの重みはMITライセンスです。
• 学習データも、第一段階のコーパスとマイニングしたhard negativesを公開しています。

ベンチマーク結果

下の図には6つの列があります。最初の2列は、同じ MMTEB Multilingual v2 評価を異なる切り口で集計したものです。ALLは全131タスクの平均、Retはそのうち18の検索タスクだけの平均です。比較モデルのスコアには公式に公開されているスナップショットを使い、Bekkoも同じタスク集合と集計方法で評価しました。

残る4列は、すべて検索タスクのベンチマーク評価です。Multilingual NanoBEIR は、英語版のオリジナル NanoBEIR に、コミュニティが公開した13の翻訳版を加えたものです。これらの翻訳版は私が作ったものではありませんが、他の Nano-set は後述の HAKARI-Bench 用に私が作った物です。NanoRTEB は、実運用に近い検索データセットを集めた RTEB の小型版です。NanoCoIR はコード検索、NanoLongEmbed は長文入力を扱います。この4つは、私が作った HAKARI-Bench（arXiv）で同じ設定を使って評価しました。語彙一致のベースラインとして、BM25も含めています。

MMTEBの2列を並べると、順位がかなり違います。特に分かりやすいのが granite-embedding-97m-r2 で、18の検索タスクでは60.3と比較中4位ですが、全131タスクでは51.9と最下位です。検索タスクを集中して学習すると、そのほかのタスクで性能を落とすことがあります。Bekkoも検索向けに学習したモデルですが、全タスクの平均も悪くはありません。

bekko-a8m は6つの列すべてで multilingual-e5-small を上回り、multilingual-e5-small のAPは2.8倍と約3倍の大きさです。bekko-a25m は、APが約12分の1でありながら、MMTEBの検索18タスクでは multilingual-e5-large と BGE-M3 を上回ります。ただしMMTEB全131タスクでは、どちらのモデルも bekko-a25m より高いスコアです。

18の検索タスクでは、5モデルが bekko-a25m を上回ります。harrier-oss-v1-270m、granite-embedding-311m-r2、EmbeddingGemma-300M、granite-embedding-97m-r2、snowflake-arctic-embed-l-v2.0 です。全131タスクでは4モデルが上回ります。harrier-oss-v1-270m と EmbeddingGemma-300M に加え、BGE-M3 と multilingual-e5-large です。gte-multilingual-base は同点でした。

ここで bekko-a25m を上回ったモデルは、granite-embedding-97m-r2 を除き、bekko-a25m の4〜13倍のAPを持ちます。検索精度を最優先し、十分な計算資源があるなら、どれも優れたモデルと言えるでしょう。

コード検索では、bekko-a25m は78.6で、multilingual-e5-large と BGE-M3 を上回る一方、84.7の EmbeddingGemma-300M と81.4の granite-embedding-311m-r2 には届きません。長文入力の結果は、もう少し意外でした。長い文書の中から1つの箇所を探す場合、語彙一致は強く、BM25が82.2で全モデルを上回ります。しかし12の密ベクトルモデルの中では、bekko-a25m が70.6で1位、bekko-a8m が3位でした。

言語別の結果

平均値だけを見ると、特定の言語でモデルの性能が崩れていても気づけません。以下は、Multilingual NanoBEIR の14言語を個別に見た結果です。

bekko-a25m は、14言語すべてで multilingual-e5-small と BM25 を上回りました。BGE-M3 との差が最も大きい言語でも2.7ポイントです。14言語の中ではタイ語、アラビア語、セルビア語が弱く、まだ改善の余地があります。

推論速度

APはスループットを大まかに見積もる目安になります。Raspberry Pi 5 から RTX 5090 まで、4つの環境で6モデルを同じ条件で測定しました。

bekko-a8m は、どの環境でも6モデル中もっとも高速でした。実際のインデックス作成で、Ryzen 9 7590X CPUで10万文書を埋め込みベクトルに変換すると、bekko-a8m なら約5分ですが、multilingual-e5-large なら約80分かかります。

自分がより面白いと思ったのは、Raspberry Pi 5 の結果です。1秒あたり33文書はGPUに比べれば圧倒的に遅いですが、1万文書のインデックスなら約5分で作成可能です。これぐらいの速度なら、用途によっては実用的でしょう。同じ Raspberry Pi 5 で multilingual-e5-large を使うと、2時間近くかかります。

図の2つのCPUパネルでは、それぞれのモデルが公開している PyTorch のバックエンドに OpenVINO を使う版を使っています。6モデルとも、CPUでは OpenVINO が最速だったためです。一部のモデルだけOpenVINO を使わずに動かすと公平な比較になりません。同等の OpenVINO 版がないモデルに、ここでの数値をそのまま当てはめることはできません。Bekko は両サイズとも OpenVINO 版を公開しています。

APだけですべての速度差を説明できるわけではありません。multilingual-e5-small のAPは bekko-a25m の87%ですが、CPUでは1.7倍高速です。granite-embedding-97m-r2 はAPが14%多いものの、速度はほぼ変わりません。

自分は、アーキテクチャの違いが効いているのではないかと思っています。ModernBERT のアーキテクチャでは、unpadding、可変長 FlashAttention カーネル、global attention と local attention の相互配置など、GPUカーネルを意識した高速化を行っています。一方、素直な XLM-R 系エンコーダアーキテクチャは、CPUバックエンドに載せやすそうです。原因を切り分けるところまではできていないので、ここは実際の実装を真に確認した結果ではなく自分の解釈です。ただこうした違いがあっても、bekko-a8m は十分に小さく、今回の比較では最速でした。

124 MiB の配布サイズとブラウザ実行

総パラメータ数を大きくしている語彙埋め込みテーブルは、ダウンロードサイズも大きくします。このテーブルは静的なルックアップなので、ONNX 版と OpenVINO 版では行ごとの int8 量子化で保存し、Transformer の重みは fp32 のままにしました。リリース時の検証では、PyTorch 版とのコサイン類似度は最小でも0.9994でした。

これにより bekko-a8m は124 MiB、bekko-a25m は190 MiBになり、ブラウザへ配れるサイズになりました。なおTransformer の重み自体をさらに小さくfloatから int8 にしサイズ削減もできるのですが、精度劣化が激しいため行なっておりません。

上の速度図と同じ Natural Questions の入力を使っています。最後の行はブラウザでの結果ではなく、比較用に同じモデルをネイティブ実行した値です。

ブラウザデモは huggingface.co/spaces/hotchpotch/bekko-embedding-web で試せます。埋め込みの計算はブラウザ内で行うため、入力した文章をサーバーへ送ることはありません。

ほかのモデルを選んだ方がよい場合

• 日本語のみを扱いたい場合、ruri-v3 シリーズは小さく Bekko より高性能です。ruri-v3-30mは AP 10M、出力次元が 256 と小型ながら必要十分な性能のことも多いでしょう
• 計算資源に余裕があり、この比較で最も高い検索精度を求める場合は、harrier-oss-v1-270m、granite-embedding-311m-r2、EmbeddingGemma-300M の方が高いスコアです。
• 検索以外にも広く使える文章埋め込みモデルが必要な場合、Bekko の分類とクラスタリング性能はは中位から下位です。検索ではない目的なら、他のモデルの方が適していることも多いでしょう。

Bekko Embedding の使い方

どちらのモデルを試すか迷ったら、CPUでのインデックス作成やブラウザ検索には a8m、Apple MPS やGPUが使え速度より検索性能を優先するなら a25m がよいでしょう。

PyTorchでそのまま動かすほか、CPUでは OpenVINO、ブラウザでは Transformers.js を使えます。3つとも同じモデルIDで動き、prefixも不要です。実行環境ごとにAPIが異なります。

pip install -U "sentence-transformers>=5.0" "transformers>=5.12"

from sentence_transformers import SentenceTransformer, util

model = SentenceTransformer("hotchpotch/bekko-embedding-v1-a8m")

query = "What are the characteristics of sushi?"
docs = [
    "A warm noodle soup served in broth with sliced toppings.",
    "天ぷらは魚や野菜に衣をつけて揚げた料理です。",
    "Une fine crepe garnie de sucre, de beurre ou de fruits.",
    "A Japanese dish made with vinegared rice, often shaped with seafood, vegetables, or egg.",
]

scores = util.cos_sim(
    model.encode(query, normalize_embeddings=True),
    model.encode(docs, normalize_embeddings=True),
)[0]
print("best doc:", docs[int(scores.argmax())])

prefix やタスク指示は不要で、クエリと文書はどちらも同じ encode 呼び出しで処理します。上の条件では、a8m の OpenVINO 実装は PyTorch より x86 で約2.8倍、Raspberry Pi 5 で約1.7倍高速です。

pip install -U \
  "sentence-transformers[openvino]>=5.0" \
  "transformers>=4.57,<5"

from sentence_transformers import SentenceTransformer, util

model = SentenceTransformer(
    "hotchpotch/bekko-embedding-v1-a8m",
    backend="openvino",
    device="cpu",
    model_kwargs={"file_name": "openvino/openvino_model.xml", "device": "CPU"},
)

query = "What are the characteristics of sushi?"
docs = [
    "A warm noodle soup served in broth with sliced toppings.",
    "A Japanese dish made with vinegared rice, often shaped with seafood, vegetables, or egg.",
]

scores = util.cos_sim(
    model.encode(query, normalize_embeddings=True),
    model.encode(docs, normalize_embeddings=True),
)[0]
print("best doc:", docs[int(scores.argmax())])

Transformers.js でも、同じモデルをブラウザ内で動かせます。対応しているブラウザでは WebGPU を使います。

npm install @huggingface/transformers

import { pipeline } from "@huggingface/transformers";

// Browser: use WebGPU when available, otherwise fall back to WASM.
// Node.js: replace this line with `const device = "cpu";`.
const device = navigator.gpu ? "webgpu" : "wasm";

const extractor = await pipeline(
  "feature-extraction",
  "hotchpotch/bekko-embedding-v1-a8m",
  { device, dtype: "fp32" },
);

const embedding = await extractor("What are the characteristics of sushi?", {
  pooling: "mean",
  normalize: true,
});

console.log(embedding.dims); // [1, 384]

リソースへのリンク

• モデル：bekko-embedding-v1-a8m と bekko-embedding-v1-a25m
• ブラウザデモ：bekko-embedding-web
• 学習データ：第一段階のコーパス と hard negatives

モデルの学習方法

使い方を中心にした記事なので、学習については簡単に。mmBERT-small の22層を4層と13層に削り、先頭側の層と、深い位置にある global attention の層を1つ残しました。削った後のチェックポイントを、そのまま基盤モデルとして使っています。

そこから2段階の対照学習を行いました。第一段階では、公開しているコーパスの約11億多言語ペア(合成データセットなども多様して作成)を使っています。性質の異なる2系統の LLM 合成クエリも含まれます。続いて、8,192トークンの長文も含む hard negative を使ってファインチューニングしました。どちらの段階でも教師モデルや蒸留は使っていません。

両モデルとも、RTX PRO 6000 Blackwell Max-Q 1枚のみで学習しました。所要時間は a8m が約3日、a25m が約8日です。一般的な規模の多言語埋め込みモデルは GPU クラスターで学習され、BGE-M3 の論文では最大96基の GPU を使ったと報告されています。APを小さくすると推論コストが下がり、学習もワークステーション GPU 1枚で行えます。RTX5090でも学習時間は増えますが、学習可能です。大量のGPUが必要ないことも、自分がこのサイズのモデルに取り組む大きな理由の1つです。

今回のモデルは、かなり多くの研究や実装を参考にしています。基盤モデルには mmBERT と ModernBERT、学習方法には E5、GTE、BGE-M3、Qwen3 Embedding、Ruri、実装には sentence-transformers を使いました。これだけ小さなモデルで、どうやって多言語検索の性能を保ったのか。残す層を選ぶ実験、損失、約11億ペアの収集・合成方法、詳しい評価結果をまとめた野良論文は以下で公開しています。

• arXiv: Bekko Embedding: Parameter-Efficient Multilingual Retrieval with Ultra-Compact Encoders
• 日本語版: Bekko Embedding: 超小型エンコーダによるパラメータ効率の高い多言語検索

小さな多言語検索モデルを探している方に、Bekko Embedding が一つの選択肢になれば幸いです。

• https://gist.github.com/hotchpotch/8fbca5605af16c386acb34bc74f8c1ae

herdr は以下の三つの状態を検討する必要がある。

• 現在の workspace の tab, pane の dir
• 別の workspace の tab, pane の dir
• agent が作業している dir

これらを考慮し、zsh 決め打ちで、以下のような仕様で作った。bash その他用もエーアイに伝えれば同様な実装はすぐ作れると思う。

• cdd のみを実行すると、 すべての作業ディレクトリ一覧を fzf でフィルターし移動が可能
• cdd 3 などで、現在の workspace の tab id 3 に移動
• cdd a3 で、agent list の3番目の agent の cwd に移動
• cdd w3:p2 などで、workspace id 3 の pane id 2 に移動。w3:p2 などは herdr オフィシャルでの表記と一緒。
• cdd w3:t2 など(w3, tab 2)も。
• 適当に tab を打つと補完リストが出てきて選択も可能
• なお jq と fzf に依存しているので、これらのコマンドが必要

今まで使っていた tmux では、tmux-fingersという、画面上に表示されているコピーしたくなるような文字列(url, SHAs, UUID などなど)を短いキーでコピーできるものが便利でよく使っていたのだけど、これがなかったので、herdr pluginとして実装してみた。

• https://github.com/hotchpotch/herdr-tiny-fingers

herdr plugin install hotchpotch/herdr-tiny-fingers

[[keys.command]]
key = "prefix+f"
type = "plugin_action"
command = "hotchpotch.herdr-tiny-fingers.open"
description = "fingers mode"

などすれば使えるので、tmux-fingers 使いの方はどうぞ。

例によってエーアイに herdr の repos を見せて実装してもらったんだけど、herdr は plugin 開発もめちゃ楽な感じであった。エーアイによって上手く開発されているプロジェクトは、エーアイが開発・デバッグしやすいように作られていているのだなぁ、と改めて感じる。

• https://github.com/hotchpotch/mac-translate-cli

brew tap hotchpotch/mac-translate-cli https://github.com/hotchpotch/mac-translate-cli
brew install hotchpotch/mac-translate-cli/trn

で入れて

trn --to ja "Hello world!"
#=> こんにちは、世界！
echo "Hello world!" | trn --to ja
#=> こんにちは、世界！
trn --to ja -q low "Hello world!" # デフォルト
trn --to ja -q high "Hello world!" # ニューラルネットワーク翻訳ぽい、高品質…？

みたいに使える。なお macOS Tahoe 26.4 以降に対応。最初、Apple Intelligence models(ニューラルネットワークを使った翻訳なのか?) API をデフォルトとして使っていたんだけど、これが遅い割に、あんまり品質が高くない。長文ならコンテキストの空気を読むのかな、と思いきや en <-> ja に関しては試した感じ別に良くない。今までの統計確率ベース翻訳モデルの方が、10倍以上速くてLLMから見たクオリティはあまり変わらず。high は自然な文章、な気もするが、場合によってはうまく翻訳ができてないケースもありそう。なのでデフォルト品質は low (今までの翻訳API)とした。

音声をテキストに変換する STT は kanary.app 経由で使った限り、変換品質そこそこで1時間の音声を1分で文字起こしできて爆走だったため、翻訳(highのApple Intelligence model)でも爆速を期待したんだけど、翻訳の方は次のモデルに期待かな。

• https://github.com/hotchpotch/openai-api-server-via-codex

uvx openai-api-server-via-codex

これでローカルにサーバーが立ち上がります。デフォルトでは http://127.0.0.1:18080 で待ち受け、OpenAI API を叩けるクライアントから、/v1/responses や /v1/chat/completions のエンドポイントが利用できるようになります。ライブラリ経由で API を叩きたいときに便利ですね。

例えば、起動した環境に適当な OpenAI API に対応している GUI クライアントを使ってみるとこんな感じです。ChatGTP Pro サブスクリプションでは Codex から今現在(2026年5月7日)、gpt-5.3-codex-spark が使えるので、以下のスクリーンショットでは試しに使ってみています。

どのように実現しているの?

この方法は、OpenClaw が Codex を経由で処理するときに利用しているエージェント実行エンジンの一つ、Piでも行われている方法で、認証は Codex の情報を利用しつつ、https://chatgpt.com/backend-api/codex の Codex 用 API エンドポイントを叩いています。

この API エンドポイントを勝手に使って良いかは不明だったのですが、Simon Willison 氏の記事 A pelican for GPT-5.5 via the semi-official Codex backdoor API を読むと、どうやら利用してもよさそう(semi-official とは言い得て妙ですね)な雰囲気なので作ってみました。

注意事項

このプロジェクトは OpenAI 公式のAPI ではありません。あくまで、自身が利用権限を持つ Codex の認証情報を使い、ローカルなどの開発環境で OpenAI API 互換の形に変換するものです。次のような用途に利用すると、OpenAI の利用規約に抵触する場合があります。

• ChatGPT / Codex の利用制限を回避する目的で使う
• 自分以外の人に API として提供する
• サブスクリプションを再販・共有する
• 公開 API や第三者向けサービスのバックエンドとして使う
• Codex の認証情報やトークンを他人と共有する

また、Codex backend の仕様は予告なく変更される可能性があります。動作していたリクエスト形式やモデル名が突然使えなくなることもあり得ます。

Codex, ClaudeCode サブスクの2社のスタンスの違い

ClaudeCode が、OpenClaw などでのサブスクション契約での利用禁止が、2026年4月に通達されましたが、反対に Codex では、Codex App ServerやCodex SDKが公開されるなど、少なくとも今今はサブスクでも幅広く使ってもらうための仕組みを提供し始めており、両者のスタンスが反対で興味深いですね。

Anthropic 社はClaude向けの推論リソースが現状カツカツな感じがするので厳しく制限していることに対し、OpenAI 社はリソースが余っているのか、割と大盤振る舞いな雰囲気を感じています。ただ、OpenAI 社もリソースが厳しくなる・競争が無くなると将来的には厳しくなる・サブスクが無くなる可能性も十分にあり得ると思うので、今後どうなることやら、未来は読めませんね。

Linderaを使うアプローチもあるようですが、今回は Rust で実装されている軽量高速なトークナイザの Vaporetto を組み込んで動く拡張機能を作ってみました。

• SQLite + Vaporetto
  • https://github.com/hotchpotch/sqlite-vaporetto
• DuckDB + Vaporetto
  • https://github.com/hotchpotch/duckdb-vaporetto

Vaporetto は、点予測法で文字境界を線形分類モデルで判定するため、辞書なしモデル(辞書ありモデルもある)で利用可能なため、サイズを小さく保つこともできるので用途によっては便利そうですね。ので、Web ブラウザー上で完結する、DuckDB + Vaporetto の組み合わせで bm25 関連度スコアでソートする全文検索を行える技術デモを作ってみました。ただ対象テキストの件数が少ないと、全文検索(件数が増えても高速に検索が可能)やbm25(単語の出現回数や文章長を加味)の嬉しさが少ないのですが…。

• https://duckdb-vaporetto-wasm-demo.surge.sh/

また例えば、この blog(secon.dev) の記事検索を SQLite + FTS5 + vaporetto の組み合わせで試しに作ってみたところ、約2700記事の bm25 検索で、大体3ms前後の速度で検索が可能になりました。

SQLite, DuckDB などでカジュアルに日本語全文検索ができるようになるので、使い所がハマれば便利そうな気がしています。

追記: 形態素解析の第一人者である、Kudo さんよりコメントをいただく、ありがたい。全文検索では点予測による単語分割は、一貫性の無さが不向きと。なるほど〜。

点予測の単語分割は全文検索には不向きです。特に辞書なしだと、文脈依存分割が避けられず検索漏れのリスクが増えます。拙書の形態素解析本に解説あります。

• https://x.com/taku910/status/2048676651517768163

文脈依存性とは、例えば「形態素解析」というフレーズの分割が、その前後文脈に左右されず、一意に決まることを指します。クエリの分割が文書中で再現されることが重要であり、Unigram言語モデルはこの条件を満たします。精度は犠牲になるものの、一貫性が保証されます。

• https://x.com/taku910/status/2048695518176665637

ただ、もうちょっと学習速度が欲しいことがあったり、また複数GPU環境での学習の知見を得たい為、今回 RTX5090 x2 構成の自作PCを作ってみた。その際、最近はコンシューマ向けGPUからNVLinkが廃止され、かつ電力消費も上がったため意外と RTX5090 2枚を使った事例がなく少々調べるのに苦労したため、まとめてみた。なおこの自作例は2025年末時点の例である。

電源

RTX5090 x2 で苦労する点といえば、まず電源である。RTX5090のTBPは最大575Wで、それが2機。CPUその他諸々の消費電力を考えると、最低1600W電源以上は欲しい。しかしながら、日本のご家庭用コンセントの100Vでは最大1500Wとなっているし、調べる限り一般的なPC用電源は100Vでは1300Wまでしか販売されていない。

なので、1300W電源までは多彩なラインナップがあるのだが、それ以上の電源になると極端に少なくなる。それ以上の電源は、電源の入力コネクタの口が一般的なPC電源のC13ではなく、C19という形状に変わる。そこに200V電源を供給することで1300W以上の出力を得ることができる。

というわけで、電源を繋げるべくNEMA規格の20A250V対応の壁コンセント(パナソニックのWF2520Bを選んだ)を工事して設置し、そこから200V20A供給(最大4000W)を可能とした。電源ケーブルはNEMA L6-20P → IEC 60320 C19のものが必要になるので、Schneider Electric AP8753J Power Cord, Locking C19 to L6‑20P を利用。なお、このコンセントにはブレーカーから単独で給電している。

また電源は評判が良さそうな1650WのASRockのTaichi TC-1650Tを選択した。GPUに大きな電力を供給する12V-2x6コネクタの安全性を考慮したATX3.1に対応している。またこの電源は、標準で100V用の電源ケーブル（C19-C20）に挿せる電源ケーブルがついてくる。これを使うと1300Wまでだが、このケーブル自体が市場にほぼ出回っていないので、テスト起動などで活用できて好感度高し。

追記:電源 x2 が設置できるケースを使い、1300W電源x2を各々100V電源に繋ぐ、という方法もあるようだ

GPU

RTX5090は膨大な発熱処理のため、空冷モデルではPCIスロット3〜4個分を占める厚さのものがほとんどだ。この厚さのGPUを2枚使う場合は、ライザーケーブルを使って物理的に離して設置しないと、ケースやマザーボードでぶつかって装着できないという問題が起きることが多いだろう。

このため選択肢として

• 3スロット以下の空冷モデルを使う（隙間なくみっちり挿すことになり熱が心配だが）
• 2枚のGPUとも簡易水冷にする
• 1枚を空冷、1枚を簡易水冷にする
• ライザーケーブルを使ってどうにかする

あたりが考えられる。すでに自分は厚さ約3.5スロットのRTX5090を保持していたため、1枚を簡易水冷、もう1枚を空冷とし、以下の2つのGPUの選択となった。なお、もしRTX5090を1枚も持っていなければ、価格が少々高くなるが、GPUを2枚とも簡易水冷とし、CPUを空冷としたほうが、ケース内部の配置に余裕が出て楽になるし、GPU温度もさらに下げることが可能なので、そちらにしたと思う。

なお今回使ったGPUは以下。

• MSI GeForce RTX 5090 32G VENTUS 3X OC
  • 約3.5スロットの厚みがある空冷（元々持っていた）
• MSI GeForce RTX 5090 32G SUPRIM LIQUID SOC
  • 厚さ2スロット強の空冷 + 120x360の水冷ラジエータ

また、お金に余裕があれば、RTX 6000 Pro (RTX5090と同じBlackwellアーキテクチャでメモリが96GB)や、性能は少々落ちるが消費電力がかなり下がって300WのRTX PRO 6000 Blackwell Max-Q を選ぶという手もある。Max-Qは排熱の考慮もだいぶ減りそうなので、設置が楽そうだ。

マザーボード

マザーボードに求める要件は、PCIe 5.0 x8 の速度で二枚刺さること、上部に刺すGPU1(水冷)と、下部にさすGPU2(空冷)の間が2レーンあって問題ないことである。実際に海外で RTX5090x2 の組み立て済みPCとして販売されている実績を評価し、Ryzen が乗るASUS ProArt X870E-CREATOR WiFi AMD AM5 X870E ATXを選択した。

なおオンボードWiFi 7チップが載っているが、Linuxのカーネルドライバーが現状無さそうなので、オンボードWiFi で繋ごうと思ってる人は注意が必要かもしれない。自分の用途では無線は使わず有線LAN接続なので特に困っていない。

ケース

ケースは、下部に3.5レーン分の厚さがあるGPUを差した時、問題なくある程度の空間があり、簡易水冷のラジエータを2機(CPUとGPU1)を問題なく設置できるもので検討した結果、CORSAIR 7000D AIRFLOWとなった。通常のケースより一回り大きいが、ケース内空間が大きいことも冷却においてはメリットが大きい。PC内部が見れるガラスパネルは不要なのだが、いざ作ってみたら結構かっこ良くて満足。

エアフロー（空気の流れ）

ケース内で最大1650W程度の電力消費が発生し、その時発生する熱は相当なものなので、良い形で空気を循環させねばならない。

簡易水冷はCPUとGPU1、空冷はGPU2で使うので、どのように外気を取り込み・排出すると良いのかを考える必要がある。PCの冷却ファンは、表裏をひっくり返すことで、吸気・排気を簡単に変更することができる。AIに壁打ちしながらベストを考えた結果、以下のエアフローになった。ただこの辺は素人なので、もっと良い配置があるかもしれない。

• フロント・吸気
  • 140mm ファンx2(ケース付属、本当は140mmをもう一つ追加したほうが良い)
  • GPU2(空冷)に当たる位置に配置
• サイド（ケース横）・吸気
  • GPU1の水冷・120mm x3
• トップ・排気
  • CPUの水冷・120mm x3
• リア・排気
  • ケース付属・140mm x1

この辺までが、組み立てる上であまり情報がなかったので苦労したところだ。続いて以下は好みで選べば良いと思うが、機械学習マシン視点からコメント入りで組み立てたパーツを紹介する。

CPU

16コア32スレッドのAMD Ryzen9 9950X。9950X3Dも出ていたが、ゲームをしない環境では誤差程度の性能差であり、差額も2万円ほど9950Xの方が安かったので9950Xを。データ加工などの処理は並列で行うことがほとんどなため、CPUコアはあればあるほど良いが、これ以上のコア数になるとThreadripperになってしまうため、16コアで。

RAM

せっかくなので上限の192GBを、と思っていたが、AI関連データセンタによるメモリ需要急増のため、2025年9月と比べると4-5倍ぐらいの値段で高止まりしていて、いくらなんでも高すぎるので DDR5-5600 32x2=64GBで。本当はECCにしたかったがこちらも高すぎるので…。自分の使い方の場合、容量は64GBだと時々swapにアクセスが発生する程度・かつswapがNVMe書き込み読み込みともに結構速いものを使っていることもあり、RAM はもっとあったら嬉しいが、64GBでも困ったことがほとんどない。

今回、中国のAcclamatorというブランドのメモリが、他のブランドの同容量のメモリの60%ぐらいの価格で売っていた(今はそこそこ高くなってしまったようだが)ので、DDR5 5600MHz 32GBx2 を購入。5600MHzでmemtest86やstresstest-cliで12時間ほど負荷をかけてみたが、とりわけエラーなく使えている。長期の耐久性や暑さ本番の夏(現在は冬で寒い)はわからない。GPU学習時にRAM速度の影響はほとんどないので、さらに安定すべく4800Mhzにクロックを落とし使っている。推論時にCPUオフロードする場合など、RAM速度も重要になるケースもあるのだけど、自分はやる予定がないので。

追記: 結局メモリ不足を感じ、もう32GBx2を増やして合計128GBへ。

ストレージ・NVMe

学習に使うデータは、雑にやるとデータがシャッフルされしてランダムアクセスが発生するため(たとえばHuggingFace Transformers も標準では学習時必ず shuffle する)。そのため容量が巨大なNVMe(SSD)を。容量はあるだけ良い。

• Sandisk SN850X NVMe SSD WDS800T2X0E 8TB
  • PCIe のCPU直結レーン。8TB でも足りない（データを削除しながら使っている）ので本当はもっと容量が欲しい。
• Samsung 980 Pro 2TB
  • これは余っていたので追加
  • チップセット共有レーン

ストレージ・HDD

生ダウンロードデータの一時的なファイル置き場として 14TB のHDDを使っている。ランダムアクセスが発生する用途には遅すぎて使えないのだけど、たとえば実運用面では、 HuggingFace datasets ライブラリはまず環境変数 HF_HUB_CACHE にデータをダウンロードするのだが、実際にライブラリがロードする際は、parquet ファイルから arrow 形式に変換されるため、後者の方が NVMe でアクセスできれば良いので、HF_HUB_CACHE のディレクトリだけHDDに指定することで、切り分けて使えている。

• TOSHIBA MG07ACA14TE 14TB

CPUクーラー

120x3 のラジエータの簡易水冷モデルなら特にこだわりがなかったので、CORSAIR NAUTILUS 360 RS LCDを利用。CPUクーラーの表面に液晶があるモデルで、液晶にCPU温度表示できるのいいじゃん、と購入してからこの制御はUSB経由で行われるため、Linuxからだと制御が難しい(OSSでできるが、サクッと温度表示などは難しそう)ことの気づく。ので、今ならLCD無しモデルを買ったかな…。

組み立て

ケースや電源や空冷が重い(筋肉痛)、自分のミスでしょっちゅうファンの前後ろを間違える、ラジエータの上下を間違える、など以外は特に困らず組み立てられ、一発で起動し問題無く動いている。

OS

使い慣れている Ubuntu Server 24 LTS で。ssh で繋ぐだけなので、GUIは一切使っていない。

RTX5090 x2 PCを作ってみての感想

実際に作ってから1ヶ月ほど経ったが、冬場だからかもしれないが、GPU二枚をフルで使っても特に問題なく安定して動いている。良かったところとしては、PCIe がボトルネックにならない場合、例えばMLMでのbi-encoderモデルの学習速度が RTX5090x1 に比べ x1.8程度の速度になり、だいぶ速くなった。また、推論も水平処理ができる場合、例えば vLLM に Qwen3-8B モデルを載せて1000万件処理する、みたいな処理もほぼ2倍速で処理できるので便利だ。

CUDAは環境変数 CUDA_VISIBLE_DEVICES でプログラムから見えるGPUを簡単に切り替えできるので、たとえばGPU2を使いたい場合は CUDA_VISIBLE_DEVICES=1 とするだけで、プログラムには一切手を入れずに1枚のGPUとして認識させることできるのも便利。簡単にGPUを切り替えつつ使うことができている。

また、マルチGPU周りの知見を得るという点でも、今までずっと1GPUしか使ってこなかったため、複数GPU環境で学習・推論の方法や考え方を知ることができて勉強になり、こちらの点でも良かった。

ただ、PCIe 5.0 x8 の速度がボトルネックに感じることが割とあって、例えば PyTorch DDP では学習stepごとに GPU間のデータを同期する All-Reduce が発生するが、学習方法によっては非常に時間がかかる。巨大バッチでのコントラスト学習とかね。すると GPU SMの idle 時間がグッと増えて、速度向上がせいぜい1.2倍程度、場合によっては1 GPUの方が速いみたいなケースすらある。

B200、H200 などのデータセンター向けGPUではNVLinkを使うと、構成によっては GPU間で 数百GB/s〜TB/sの速度が出るため、高速な転送速度が確保できるが、PCIe 5.0 x8 では実効速度は 約20-30GB/s ほどのため、NVLink に比べると圧倒的に遅かったりする。高いGPUはよくできているなぁ(B200 x8 なマシン1つで8000万円程度かな…)。

というわけで、作ってみての満足度は高い。パーツを購入したタイミングも、メモリは高くなっていたが、2026年1月中旬はさらにストレージもメモリもGPU(RTX5090)も高くなってしまったので、まだマシだったタイミングであった。AI需要・そして円安もあり色々と高くなってしまったなぁ…。

子供

子供がうまれた。人生で一番大きな変化は子供が生まれた時、とはよく聞くが、当事者になってみると全くその通りだと思う。何もかも子供主体な考え方に変わる。それにしても子供はかわいい。かわいすぎる。子供を育てられる幸せを噛み締める。リモートワークで、しょっちゅう子の顔を見れる、ありがたさもある。

産まれる前は妻が持病関連で体を悪くし、長期入院になったり、出産後もどうなるかわからずだいぶ不安だったが、その後の回復は良好で、問題無く日常生活を過ごせている。健康のありがたさよ。私は(四|五)十肩、以外はだいたい元気。

家

昨年建てて、昨年末から新しく住み出した家、すこぶる快適。冬はそれなりに寒いし、周りが農地なので夏は虫が多いが、それらをさっ引いても大変暮らしやすい。子も増えたことだし、建てて良かった。

車

テスラのモデルY ジュニパー ロングレンジをお迎え入れした。BEVのエンジンがない快適さ(静か、あっという間に速度が上がる)もさることながら、ソフトウェア・UX周辺、ほんとよくできている。ほとんどの車が、過去の車の延長線上なUXだが、新興の会社は過去を踏襲する必要がないので、新しい体験設計ができ、それをひしひしと感じる。車移動（というのは田舎において移動手段のほぼ全てある）が非常に楽に・快適になった。

現在のオートパイロット運転アシストでさえもかなり快適なのに、将来はFSD(完全自動運転、という名の、いい感じの自動運転支援)が日本でも使えるようになるだろうから、そちらもとても楽しみである。

技術

引き続き、情報検索周りを主に、技術的なあれこれやプロダクトづくりをやっていた。コーディングエージェントが台頭した年で、ほぼ全ての技術作業はエーアイさんにやってもらっているが、打ち手が増えて、できることが大きく広がったと感じる。通常のソフトウェア開発に限らず、例えば情報検索モデル開発関連も、エーアイが全部やってくれ、今までだったら手を動かす時間がかかりすぎていて大変だったことも、エーアイYOLO、ですんで最高だ。

エーアイが代替できない・代替しない技術をちゃんとやる、というのが正解プロダクト不定の時代の仕込みとしては大事だと思っているのだけど、その技術的なところを色々やれているので、楽しいね。バイアスがかかってるので、自分がそう思ってるだけで、簡単に代替される可能性はもちろんあるのだけど。

仕事周りでも今年はメインで作っていたエーアイプロダクトが世に出て、世の中的にも会社的にも一定の評価をいただけたようで、ありがたい限り。チーム開発のやりやすさの賜物でもあるので、関係者各位ありがとうございます。来年もまたチーム、エーアイさんの手を大いに借りて、技術的なことをやりつつも、新しいプロダクトを作っていきたい。

2025年はいろいろあったが、子が産まれたに尽きる。毎度のことだが、さまざまなことをサポートしてくれる妻に感謝だ。というわけで、皆様2026年もよろしくお願いいたします。

• 振り返り2024年
• 振り返り2023年
• 振り返り2022年
• 振り返り2021年
• 2020年の振り返り

しかしながら、大量に検索を行うと「検索結果」の情報も同時に増加していきます。そのため、本当に必要な情報の抽出をLLMが間違えたり、ハルシネーションが起きたり、入力情報の増加により処理が遅くなったり、LLM利用費用が増加したりと、大量の検索が難しかったりもします。

そこで、検索結果をLLMに渡す前に、関連しない情報は削除しちゃおう、ついでに関連度スコアもつけちゃおう、というアプローチが Provence です。このアプローチでは、検索でヒットした文章のうち、関連しない部分を削除することが可能です。実際にデルの性能を測定したところ、長文の質問・回答データセットを用いた評価(MLDR + LLM eval)では、80-95%ほど文章を削除できました。10000文字の文章なら500-2000字程度にLLMに渡す前に減らせる、ということですね。かなりの入力データの削減が期待できますね。短い文章に分割されたような短文が多いデータセットでも、ドメインによりますが30〜70%の文の削除が行われています。

ただ研究開発として公開されている Provence 実装やモデルは非商用で、日本語のデータセットも公開されていなかったので、今回 OpenProvence というプロジェクトを作成し、で学習推論などのソースコードやモデルの重みなどを "オープン" なライセンスで公開しました。日本語データセットも作成して公開しています(データセットは大元のライセンスがあるため、オープンなライセンスではないものが多いですが)。

OpenProvence の試し方

以下の URL に huggingface spaces (CPU) 環境で動くデモを用意したのでお試しください。デモのサンプルにあるWikipediaの情報検索のページ情報をもとに「ベクトル検索は？」をクエリに文削除を実行すると、約5000文字の記事が400文字に削減され、かつベクトル検索についての情報のみが残った形で出力さると思います。

• 🤗 https://huggingface.co/spaces/hotchpotch/open_provence_demo

またデモは以下の手順でローカルマシンでも手軽に動かせます。最近の MacBook でしたら、かなり高速に推論することも可能でしょう。

git clone https://huggingface.co/spaces/hotchpotch/open_provence_demo
cd open_provence_demo
uv sync
uv run python app.py

python からの利用方法

python からは以下の感じで利用できます。小型のxsmallモデルならCPU環境でも推論可能です。また GPU 環境(NVIDIA + flash attention2)では、即座にで推論が完了し、文章の削除が行われるでしょう。本番検索環境に組み込んでも、問題ない速度で処理できると思っています。

from transformers import AutoModel

# 利用モデルに合わせて変更
model_name = "hotchpotch/open-provence-reranker-xsmall-v1"
provence = AutoModel.from_pretrained(model_name, trust_remote_code=True)

question:str = "日本の首都について"
context:str = """
今日は学校に行き、さまざまなことを学んだり、友達と学食でたらふく食べた。
日本の首都は東京で、東京は日本の政治、経済、文化の中心地らしい。この都市は約1,400万人の人口を抱える世界有数の大都市らしい。
夜は飲み会に誘われたが、参加せずに帰宅した、今月そんなにお金が残ってないからなぁ、残念だ。
"""

result = provence.process(question, context, threshold=0.1)
print(f"Reranking Score: {result['reranking_score']:.4f}")
print(f"Compression Rate: {result['compression_rate']:.1f}%")
print(f"Pruned Context:\n{result['pruned_context']}")

# 出力例:
# Reranking Score: 0.7043
# Compression Rate: 62.5%
# Pruned Context:
# 日本の首都は東京で、東京は日本の政治、経済、文化の中心地らしい。
# この都市は約1,400万人の人口を抱える世界有数の大都市らしい。

コーディングエージェントの活用

OpenProvence は、推論・学習モデル実装、評価実装、データセット作成実装など、私は一行もコードを書かない縛りで、全ての実装はコーディングエージェント(Claude Code, Codex) によって行いました。かなり修正の指示は必要でしたが、隙間時間に進めたプロジェクトとしてはなかなかのものが、コーディングエージェントを活用することで出来上がったのかな、と思っています。出来上がった成果物のコードを見ると、もっとシンプルなコードにすることはできそうですが、現状のLLMが理解しやすい形・LLMが修正しやすい形だと、これぐらいの冗長なコードが丁度良いのかもしれません。

適切な指示と開発指針、AIが自身で開発、改善し続けられる環境等を作り続けることで、プロダクションレベルの品質のソフトウェアをAIと協調しながら作成する、Vibe engineering という言葉も生まれました。

開発指針やユニットテスト、CI、コードレビュー環境といった通常のコーディングエージェントを用いたソフトウェア開発に加え、モデル学習時の学習を短時間で行える最小ベースラインと評価データの用意(これが意図せず変化するとバグ)、データセットについての詳細な説明等々を用意することで、ある程度の規模の機械学習モデル・プロジェクトも開発できることを実感しています。

おわりに

OpenProvence のような、質問と関連しない文章を削除するアプローチは、とりわけ巨大な文章を処理するようなプロダクトととても相性が良いでしょう。

2024年はRAGが話題でしたが、2025年のAI Agent、DeepResearch、Context Engineering のような流行を先取りし、技術的に重要なポイントを研究開発した Naver Labs Europe の Provence チームの先見の明(Provenceは2025年1月公開!)に驚きと感謝を。

昨今、LLMを活用するプロダクトでは、裏側で情報検索を活用することで価値を高められ、情報検索技術は引き続きとても面白いです。このプロジェクトが少しでもプロダクトや研究で活用していただけたら幸いです。

• https://github.com/hotchpotch/open_provence/
• https://huggingface.co/collections/hotchpotch/openprovence

結論から言うと日本語においては、EmbeddingGemma はとても性能が低かったです。

JMTEB v1 ベンチマーク評価

注：MTEB v1の16の日本語タスクのマイクロ平均（単純平均）で算出

なお、JMTEBの設定はこちらで、各種 prefix などはつけているはずです。また結果の json である summary.json はこちら(gist)。再現方法も gist に記載してます。私の測定結果がおかしかったら教えてください。

2025/10/03追記: transformersのバグの影響で、最新版だと ruri-base 並に性能が向上するとのこと。LM8(@ShengzheLi) さん、情報ありがとうございます!

JQaRA / JaCWIR

JMTEB v1 でのスコアが低すぎるので、別途 JQaRA / JaCWIR でも評価してみましたが、やはりかなり低い結果となりました。

MTEB 高性能 ≠ 日本語高性能

先日評価した Qwen3 Embedding (Qwen3 Embedding 文章ベクトルの日本語性能を JMTEB で測る)もですが、最近の MTEB 高評価マルチリンガル embedding モデルは、日本語性能が低いことが多いですね。なんでだろうと、MTEB Leaderboard の Language-specific の Japanese を見ると、Qwen3 Embeddings, Embedding Gemma 共に Pair Classification しか日本語結果では載っていないので、ほぼ参考になりません。マルチリンガル性能とは…。

またこの Qwen3 Embedding, Embedding Gemma の2モデルは decoder モデルベースのアーキテクチャです。embeddinggemma-300m の中身を見ると、埋め込み用の HEAD (pooling + 2層dense) を mean pooling して使っていますね。

decoder + 小さなパラメータサイズの場合、少なくとも日本語における性能は他の encoder マルチリンガルモデルよりだいぶ低い結果でした。この辺は、そもそも日本語を embeddings タスクでほとんど学習させてないからなのか、それとも大元の小さな decoder の時点で日本語汎化性能が低いのか…。

今回公開した JFWIR (Japanese FineWeb Information Retrieval) は、この課題に取り組むために作成した約6,400万件の大規模な日本語情報検索に活用できるデータセットです。このデータセットは、高品質な教育的コンテンツを含むWebクロールデータ「fineweb-2-edu-japanese」を基に構築されています。

• https://huggingface.co/datasets/hotchpotch/JFWIR

JFWIRの特徴

1. 大規模かつ多様性の高いデータセット

JFWIRは以下の特徴を持つデータセットです：

• 6,400万件以上の文書-クエリペア: 各文書に対して7種類の異なるタイプのクエリ（keywords, synonym_keywords, query, alt_query, title, faq, summary）を生成
• 実際のWeb文章: Wikipedia以外の教育的価値の高いWebコンテンツを収録
• ハードネガティブ付き: 効果的な学習のための類似しているネガティブ文書

2. ベンチマーク評価結果

JFWIRを使用して学習させたリランキングモデルの性能を、主要な日本語情報検索ベンチマークで評価しました。以下の4つのベンチマークで比較を行いました：

特に、Web文章を対象とするJaCWIRでは0.9339から0.9586への改善が見られました。

使い方

JFWIRはHugging Face Datasetsから簡単に利用できます。以下に基本的な使用例を示します：

from datasets import load_dataset

# メインデータセットの読み込み
train_ds = load_dataset("hotchpotch/JFWIR", split="train", name="small_tokens_cleaned")

# サンプルデータの確認
for i in range(3):
    sample = train_ds[i]
    print(f"Query: {sample['query']}")
    print(f"Document: {sample['text'][:100]}...")

# ハードネガティブ付きデータセットの読み込み
hard_negatives_ds = load_dataset("hotchpotch/JFWIR", split="train", name="hard_negatives")

# ハードネガティブの使用例
for i in range(3):
    hn_sample = hard_negatives_ds[i]
    pos_id = hn_sample['pos_id']
    pos_doc = train_ds[pos_id]
    
    print(f"Query: {pos_doc['query']}")
    print(f"Positive (score: {hn_sample['pos_score']:.3f}): {pos_doc['text'][:100]}...")
    
    # ネガティブ文書をスコア順にソート
    neg_pairs = list(zip(hn_sample['neg_ids'], hn_sample['neg_scores']))
    neg_pairs.sort(key=lambda x: x[1])
    
    print("Negatives (lowest scores):")
    for neg_id, score in neg_pairs[:2]:
        print(f"  Score {score:.3f}: {train_ds[neg_id]['text'][:80]}...")

データセットの作成プロセス

1. 高品質な日本語Web文章の収集

まず、大規模なWebクロールデータセット「FineWeb-2」から、教育的価値の高い日本語コンテンツを抽出して「fineweb-2-edu-japanese」を作成しました。さらに、Web文章特有のノイズを除去し、適切な文章長に調整した「small_tokens_cleaned」サブセットを作成しました。

2. 多様なクエリの生成

6,400万件のデータセットに対してクエリを生成するため、軽量なクエリ生成モデル「query-crafter-japanese」を使用しました。多様性を確保するため、以下の3つのモデルを組み合わせて使用しています：

• hotchpotch/query-crafter-japanese-Qwen3-1.7B
• hotchpotch/query-crafter-japanese-Qwen3-4B
• hotchpotch/query-crafter-japanese-sarashina2.2-3b-instruct-v0.1

各文書に対して7種類のクエリタイプ（keywords, synonym_keywords, query, alt_query, title, faq, summary）を生成することで、多角的な検索ニーズに対応できるデータセットを構築しました。

3. ハードネガティブの作成

情報検索モデルの性能を向上させるため、ハードネガティブ（クエリに類似しているが正解ではない文書）を含むデータセットも作成しました：

1. 埋め込みモデルによる類似文書検索: ruri-v3-30mモデルを使用して6,400万件の文書をベクトル化し、各文書に対して類似度の高い文書を検索
2. 適切なネガティブの選定: 類似度top10-50とtop50-200からランダムサンプリング
3. リランカースコアの付与: japanese-reranker-xsmall-v2を使用してスコアリングしています。たとえば正例として不適切なもの（スコア<0.6など）や負例として不適切なもの（スコア>0.4など）を除外して利用することで、より適切な正例・負例を選択できます。

今後の展望

JFWIRは、日本語情報検索分野の発展に貢献することを目的として公開されました。しかしながら、query-crafter-japanese は文章からのある程度単純なクエリ生成にとどまり、もっと多様な価値のある質問文を作成することで、より様々な情報検索精度の向上が可能になると思っております。

まとめ

JFWIRは、Wikipediaに偏重していた従来の日本語IRデータセットとは異なるアプローチとして、実際のWeb文章を対象とした情報検索データセットです。約6,400万件のデータ、7種類のクエリタイプ、対照学習用のハードネガティブなど、情報検索システムの開発に活用いただける要素を含んでおります。

データセットはHugging Faceで公開されており、ODC-byライセンスの下で自由に利用できます。日本語情報検索分野の発展に、このデータセットが少しでも貢献できれば幸いです。

関連リンク

データセット

• JFWIRデータセット: hotchpotch/JFWIR (Hugging Face Datasets)
• fineweb-2-edu-japanese: https://huggingface.co/datasets/hotchpotch/fineweb-2-edu-japanese
• FineWeb-2: https://huggingface.co/datasets/HuggingFaceFW/fineweb-2

モデル

• ruri-v3-30m（埋め込みモデル）: https://huggingface.co/cl-nagoya/ruri-v3-30m
• ruri-v3-pt-70m（事前学習モデル）: https://huggingface.co/cl-nagoya/ruri-v3-pt-70m
• japanese-reranker-xsmall-v2: https://huggingface.co/hotchpotch/japanese-reranker-xsmall-v2
• query-crafter-japanese（クエリ生成モデル）:
  • hotchpotch/query-crafter-japanese-Qwen3-1.7B
  • hotchpotch/query-crafter-japanese-Qwen3-4B
  • hotchpotch/query-crafter-japanese-sarashina2.2-3b-instruct-v0.1

記事・論文

• query-crafter-japanese記事
• 日本語言語理解ベンチマークJGLUEの構築 〜 自然言語処理モデルの評価用データセットを公開しました
• MIRACL: A Multilingual Retrieval Dataset Covering 18 Diverse Languages
• FineWeb-Edu: The Finest Collection of Educational Content the Web Has to Offer
• Ruri: Japanese General Text Embeddings

作者: Yuichi Tateno (@hotchpotch)

ライセンス

本データセットは、元の FineWeb2 と同様に Open Data Commons Attribution License (ODC-By) v1.0 の下で公開します。また、使用にあたっては CommonCrawlの利用規約 も適用されます

Citation Information

JFWIRデータセットを研究や開発に使用される場合は、以下の引用情報をご利用ください

@misc{tateno2025jfwir,
  author = {Yuichi Tateno},
  title = {JFWIR: Japanese FineWeb Information Retrieval Dataset},
  year = {2025},
  url = {https://huggingface.co/datasets/hotchpotch/JFWIR},
  note = {A large-scale Japanese information retrieval dataset with 60+ million document-query pairs}
}

ただ、マルチリンガルモデルはあまり日本語が重視されない傾向にあるので、JMTEB: Japanese Massive Text Embedding Benchmarkで Qwen3-Embedding-0.6B の性能を計測してみました。なお、jsick, jsts がエラーになったため、STSタスクは除いてあります。

JMTEB 計測結果

結果はこちらです。日本語のタスクがあまり学習されていないからなのか、日本語の結果は振るわない結果でした。ruri-v3 シリーズはモデルサイズも小さく、かつ日本語では圧倒的に高性能ですね。

なお Retrieval, Reranking タスクでは、Query の prefix に Instruct: Given a web search query, retrieve relevant passages that answer the query\nQuery: を追加しています。

また計測に使った、JMTEB用の設定(jsonnet)や結果の summary.json、実行コマンドは以下においてあります。Qwen3-Embedding-0.6B の性能が低すぎる気もするので、何か間違っていたら教えてください。

• https://gist.github.com/hotchpotch/f6be186010e70d6eb6e46447cea258f9

おまけ: Qwen3 Embedding 論文を読む

Qwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Modelsが公開されたのでざっくり読んでみました。とりわけ合成データセット作成あたりが個人的に面白かったです。

以下は私の興味範囲のメモ書きです。

• LLM2Vec のような decoder → encoder ではなく、casual attention をそのまま利用
• Embedding モデルは最終層の[EOS] トークンの hidden state から最終埋め込みを取得
  • Query は Instruction + Query で作成。Doc はそのまま。
  • InfoNCE を改良したスコア(単純な対照学習ではなく、ハードネガティブを複数含めたり、類似度のポジネガを調整した偽陰性の調整など)
• Reranking は chat template をそのまま使って、"yes", "no" トークンの確率で、関連性スコアとして計算
  • decoder model のラベル分類の解き方(該当ラベルトークンの確率を見る)のアプローチをママ適用
  • SFT で学習できる
• 1st stage で Qwen3-32B で作った合成データセットをもとに学習
  • 情報検索, 対訳マイニング(Bitext Mining), 意味的類似性, 分類 の4つのタイプを作成
  • 情報検索の合成データセットの場合、詳細な設定を作り、それをもとにQwen3の事前訓練コーパスの文章からクエリを生成
• 2nd stage で 700万の既存データセット(MS Marco, MIRACLなどなど)と、1st stage のコサイン類似度でフィルタリングした1200万件のデータをもとに学習
• 最後に多様性考慮のモデルマージ
  • 詳細は記されてないので推察だが、2nd stage の複数のチェックポイントは、タスク特化学習させたもの、特定言語にフォーカスして学習させたもの、などが考えられそう
  • モデルマージは適当にマージして、ベンチマーク走らせると結果が向上することを、少ないコンピューティングリソースで観測できるので、たくさんチェックポイントがあるならいろいろ試した方が良さそう。

🆕 2025-07-10 まぁまぁ小さなリランカー japanese-reranker-small-v2 と japanese-reranker-base-v2 も追加しました。

本モデルは最小限のレイヤー数とパラメータ数で作成されており、CPUやAppleシリコン環境でも実用的な速度で動作します。これにより、高価なGPUリソースなしでもRAGシステムの精度向上が可能になり、エッジデバイスでの展開や低レイテンシが要求される本番環境で活用できるでしょう。性能評価では、大型モデルと比較しても競争力のあるスコアを出しています。

• https://huggingface.co/hotchpotch/japanese-reranker-tiny-v2
• https://huggingface.co/hotchpotch/japanese-reranker-xsmall-v2
• https://huggingface.co/hotchpotch/japanese-reranker-small-v2
• https://huggingface.co/hotchpotch/japanese-reranker-base-v2

リランカーとは何か、そして小さなリランカーの重要性

リランカーとは、検索システムにおいて、質問（クエリ）と文書の関連性を評価し、最も関連性の高い順に並べ替える（ランキング）するモデルです。従来の文ベクトル（埋め込み）検索だけでは捉えきれない複雑な関連性を評価できる点が強みです。特にCrossEncoderと呼ばれるアーキテクチャを用いることで、質問と文書を一つのペアとして入力し、より細かなニュアンスや文脈的理解を実現します。

• 日本語最高性能のRerankerをリリース / そもそも Reranker とは?

小さなリランカーモデルが重要な理由はいくつかあります。まず、リランカーは質問と候補文書のすべての組み合わせを評価する必要があるため、計算量が非常に多くなります。例えば100件の候補文書をリランクする場合、100回のモデル推論が必要です。そのため、モデルが小さいほど処理速度が向上し、レイテンシが低減します。

また、小型モデルは限られたリソース環境での実行も可能です。CPUのみの環境やエッジデバイス、モバイルデバイスでも現実的な速度で動作でき、RAG（検索拡張生成）システムの実用性を大きく高めます。同時に、クラウド等のサーバ環境ではGPUメモリ使用量の削減により、GPUリソースの共有が可能となりコスト効率が大幅に向上します。

• Ask! NIKKEI RAG検索技術の深層

このように、小型リランカーは速度、コスト、リソース効率の面で大きなメリットをもたらし、実用的なRAGシステム構築において大切な役割を果たすでしょう。

ベンチマーク性能

ベンチマーク結果は以下です。小さなな tiny, xsmall v2 の性能はモデルサイズを考えるとかなり高く、大きいモデルとしては ruri-v3-reranker-310m が圧倒的ですね。これらの高性能なモデルは、ベースがどれも高性能な ModernBert になったことも、性能向上に寄与しているでしょう。

なお、日本語モデルはどれもJQaRA(クイズ形式)の傾向を学んでおり、bge-reranker-v2-m3 は不利になります。これはリランカーが適切にドメイン課題を学習すれば、だいぶスコアが上がることの例でもあります。

推論速度

こちらは、HuggingFace transformers ライブラリを使った、約15万ペアをリランキングした推論速度結果(トークナイズ時間は除いていて、純粋なモデルでの推論時間)です。MPS(Appleシリコン),CPUの計測にはM4 Maxを、GPUにはRTX5090を用い、かつ ModernBert 系列モデルでは GPU 処理時に flash-attention2 を使っています。

japanese-reranker-tiny-v2, xsmall-v2 は速度面で圧倒的ですね。ruri-v3-reranker-310m もモデルサイズを考えるとかなり速く、これらは flash-attention2 が効いているからでしょう。なお、text-embeddings-inference等を使うことで、他のモデルも flash-attention2 を使うことができ、その場合はこの評価以上の速度が出ると思います。

なお、推論速度のベンチマークに用いたスクリプトはこちらです。

また CPU用に onnx に変換したモデルも公開しているため、例えばラズパイ環境などで、onnx + arm向け量子化モデルを使うことで、実際にエッジ環境でも動くでしょう。

モデル作成の簡易テクニカルレポート

japanese-reranker-tiny-v2, xsmall-v2, small-v2, base-v2 の学習データ元として、hotchpotch/japanese-splade-v2 学習で用いたデータセット + ハードネガティブ + 若干の独自データを用いて学習させています。v1と比べて大幅に性能が上がったのは、ModernBert ベースで事前対象学習を行った ruri-v3-pt-30mを用いてることと、v1よりも数倍のデータセットを用いたこと、またハードネガティブでの良質なデータの抽出(各種rerankerのスコアを用い、正しい・正しくないでフィルタリング)を行ったことも大きいでしょう。

また、Tiny モデルのモデルパラメータ抽出元として、sbintuitions/modernbert-ja-30mとcl-nagoya/ruri-v3-pt-30mを利用・評価しました。ModernBert アーキテクチャは、グローバルアテンションとローカルアテンションのレイヤーを交互に含みます。例えば modernbert-ja-30m モデルは10層のレイヤーで、[0,3,6,9]層がグローバルアテンションで、それ以外がローカルアテンションとなっています。

最初は全てグローバルアテンションの方が良いだろうと思ったのですが、3,6,9層を含むと基本悪くなり、また出力層に近い層を含むと、こちらも結果が悪くなりました。以下のグラフは同じデータセットで学習したrerankerのrerank評価結果です。出力層に近い6,9などを含むとだいぶ悪くなり学習早期で止めたので、以下の結果には含めてません。また、layer 0 のみは流石に全く性能が出ませんでした。

この中から、最も良質な結果になった ruri-v3-pt-30m を xsmall として、tiny モデルとしては ruri-v3-pt-30m + layer 0,2,4 を公開しました。また、small-v2 と base-v2 は ruri-v3-pt-70m と ruri-v3-pt-130m をベースにそれぞれ作成されています。なお、モデルマージすると性能は少々上がりますが、今回は行っていません。

おわりに

本エントリーでは、非常に小型軽量で実用的な日本語リランカーモデルjapanese-reranker-tiny-v2、japanese-reranker-xsmall-v2、japanese-reranker-small-v2、japanese-reranker-base-v2 についての紹介をしました。これらのモデルのうちtinyやxsmallは、CPUやAppleシリコンといった環境でも実用的な速度で動作し、高価なGPUリソースを必要とせずにとも、とりわけローカルなRAGシステムなどの検索精度の向上に寄与します。またGPU上で動かすことで、高速なレスポンスも実現可能です。

近年の高性能な ModernBert 等の Encoder モデルの登場により、より高性能な実用的な性能を持つモデルの開発を後押ししています。本記事が、日本語処理技術のさらなる発展に貢献できれば幸いです。

しかし、合成データセットを作成して広く公開したい場合、OpenAIやGeminiなどの商用LLMでは、利用規約によってライセンスの問題が発生します。また、大量の文章を処理したい場合は時間・費用もかなりかかります。

そのため、1.7B〜4B という小型サイズのモデルで高速に動作しながらも、DeepSeek-R1で生成した質問文と同レベルの情報検索用の質問文（クエリ文）を自動作成でき、さらに出力ライセンスに制限がないquery-crafter-japanese モデルを作成しApache 2.0ライセンスで公開しました。

• query-crafter-japanese-Qwen3-1.7B
  • ⭐️:👆速度・性能の面でおすすめです
• query-crafter-japanese-Qwen3-4B
• query-crafter-japanese-sarashina2.2-3b-instruct-v0.1

query-crafter は7つのカテゴリーを生成できます。

• keywords: スペース区切りのキーワード
• synonym_keywords: 類義語をもちいた特徴的なキーワード
• query: 文章の内容に基づいた質問文
• alt_query: BM25でマッチしない表現を使った質問文
• title: 文章全体を表現するタイトル
• faq: 文章をFAQの回答とした場合の質問文
• summary: 文章の短い要約

では、以下の文章を用いて、各々のカテゴリーに対する質問文を作成してみましょう。

• query-crafter-japanese-example.py

夕方、開発合宿の成果発表会。私以外は、AI関連のちゃんとしたテーマに取り組んで、クオリティも高く、いやー面白い。I氏はエンジニアでもないのに、Figmaプラグインを作ったり、vercelにデプロイしてたり(ほぼcursorが書いた)して、AIによって大きく幅が広がる一例を間近に見る。私は何かのテーマに取り組んだわけではなく、Vibe Cording を一度もしたことがなかったので、cursor でコードをいかに触らず・見ずに作れるかを試した。

毎年のこの日記を要約してdiscordなどに投稿するツール（以前も作ったものの仕様を書いて新機能などを追加）を作成したり、この日記のタイトルがないものに自動でタイトルをつけたりするツールを作成する。Vibe Cording は思った通りの感じで、なるほど便利。

コードは見ずにブラックボックス的な開発（出力成果物だけをみる）をしたので、出来上がったコードを後で見ると本番運用前提のコードでは全くないが、書き殴りのツールを作るには十分。また自分が指示するのは仕様のみで、仕様書も随時アップデートされるようにしてるので、機能を変えたくなったら仕様変更・追加するだけでいいし、楽で良いね。

query-crafter-japanese-Qwen3-1.7B を用いてカテゴリーごとに質問文を生成した結果はこちらです。keywords, query, title, summary あたりは特色が分かりやすく出ていますが、synonym_keywords は完璧な類義語でないことも多かったり、alt_query, faq は query とそれほど変わらなかったりすることもあります。

keywords: Vibe Cording ブラックボックス開発 仕様変更
synonym_keywords: AI活用開発プロジェクト 発表会 仕様変更追加
query: 開発合宿で作成したツールの具体的な機能は？
alt_query: 開発者向けツール開発でコード見ない開発手法の利点は？
title: AI活用で拓く開発の新領域：Vibe Cordingとブラックボックス開発の可能性
faq: 開発合宿で実現した新機能や成果は？
summary: AI活用の開発成果発表会で、Vibe Cordingや日記ツール開発、コード見ずに開発を実施

また動作速度も vllm + RTX5090 環境で、入力トークンが 48,000 toks/s、出力トークンが 2200 toks/s で動作します。〜1000文字程度の文章1万件から質問文1万件を生成した場合、100秒弱で作成できます。対象文章が1億件あったとしても、約140時間程度で全てを処理することができます。

なお、DeepSeek-R1 を夜間ディスカウント時間帯(input: 1M toks 0.135USD, output: 1M toks 0.55USD)で実際に10万件の文章を並列100のAPIリクエストで処理した場合、約7時間と40USD程度の費用がかかりました。もし、DeepSeek-R1 APIで1億件を処理した場合、約7,000時間(実際には夜間ディスカウント時間を狙うと、そのタイミングでしか処理できないので、もっと時間がかかります。また並列リクエストの最大数はDeepSeekサイドのリソースによって変動します)と、40,000USDほどの費用が発生するでしょう。

このように、query-crafter は、特に大量の文章から質問文を作成したい場合、処理速度的にも費用的にも大きなメリットがあります。

query-crafter-japanese モデルの学習

学習には、出力結果利用に制限がない DeepSeek-R1 を使い fineweb-2-edu-japaneseのデータをもとに、質問文となる教師データを、合成データセットとして作成しました。

例えば title については '文章全体をうまく表現した、タイトルを考え作成しなさい。考えたタイトルは30文字以内で出力すること。出力は厳密な JSON 形式で {"query": "タイトル"} とする。他に一切余計な出力はしないこと。' といった指示文を用いて作成しています。

• https://huggingface.co/datasets/hotchpotch/japanese-query-crafter-reasoning-80k

続いてこのデータを教師データとし、SFT(Supervised Fine-tuning)で、Qwen3-4B, Qwen3-1.7B, sarashina2.2-3b-instruct-v0.1, TinySwallow-1.5B-Instruct を学習させました。

SFT時に使ったフォーマットはシンプルに

{
  "system": "{category名}",
  "user": "{text}",
  "assistant": "{query}",
}

といった内容です。systemプロンプトに title などの指示カテゴリを、user 入力文に文章テキストを、そしてmodelの出力に query を設定しています。何かの用途に特化したSFTの場合、冗長なプロンプトを書く必要はなく、短い指示(今回は各種カテゴリー)のみで、うまく学習できます。

query-crafter-japanese モデルの評価

query-crafter の評価は、japanese-query-crafter-reasoning-80k の testデータを用いました。このデータのtextを元に、各種SFTで学習させたquery-crafterモデルを使って質問文を作成します。

そしてこれらの質問文とテキストをペアに、リランカーBAAI/bge-reranker-v2-m3で評価させたスコアの結果が以下です。このリランカーは、文章とテキストの関連性が高いと1.0になり、関連性がないと0.0となります。そのため、質問文とテキストが関連しているかどうかの目安になります。

パーセンタイルをプロットしたグラフは以下です。

結果、TinySwallow-1.5B 以外は、ほとんどのケースでDeepSeek-R1以上のスコアとなりました。特に、Qwen3-1.7B は日本語に特化しているわけではないマルチリンガルモデルですが、SFTするとQwen3-4Bとほとんどスコアが変わらず、性能の高さは驚くべきものです。そのため、特にこだわりがなければ、query-crafter-japanese-Qwen3-1.7B を利用するとよいでしょう。

なお、DeepSeek-R1 他よりスコアが低いからといって必ずしもDeepSeek-R1の質問文の質が悪いというわけではなく、リランカーでも判別が難しいような「正しく難しい質問文」を作成しているケースもあります。TinySwallow-1.5B はちょこちょこ全く関連がない質問文を作成してしまうケースがあり、他のモデルよりスコアが低くなりました。TinySwallow-1.5B-Instruct は TAID でモデル蒸留されているため、その後の SFT には不向きなのかもしれません。

おわりに

大量の質問文章を作りたい場合において、速度的にも費用的にも大きなメリットがある、query-crafter-japanese モデルを作成し公開しました。高性能かつ出力結果に制限がない DeepSeek-R1 の登場以降、様々な方法でデータセットの作成・公開・それを教師データとして利用したモデルの作成がしやすくなりました。また、Qwen などの小型サイズのモデルといった、ライセンスが使いやすいオープンウェイトなLLMの登場・性能進化により、ファインチューンした用途特化の小型モデルも作成・公開しやすくなり、幅広い応用が可能になってきたことを実感しています。もし半年前なら、このモデルを個人で作成することはリソース的にも不可能だったでしょう。

このモデルが、質問文を作りたい方の助けになれば幸いです。

• https://huggingface.co/datasets/hotchpotch/fineweb-2-edu-japanese

以下の内容は、上記ページの日本語訳です。

本データセットは、FineWeb2 の日本語データ（376M件）のうち、教育向けコンテンツと判断した120M件（約89.3Bトークン）の文章をフィルタしたものです。以下のサブセットも提供しています。

• default: 約120M件（1.2億件）のデータ・約89.3Bトークン
• sample_10BT: default からランダムサンプリングした約10Bトークンのデータ
• small_tokens: トークン数が512以下の短い文章のみから構成されるデータ
• small_tokens_cleaned: small_tokens から Web 特有のテキストノイズを除去したデータ

データセット作成の背景

FineWeb（英語のみ）は、Webデータの重複除去と高品質テキスト抽出を目的として作成されました。さらに、教育向けに質の高いテキストを抽出した FineWeb-Edu により、より少ないトークン数でも効率的な学習が実現可能となっています。

2024年12月に公開された FineWeb2 は多言語対応（日本語を含む）の高品質データセットですが、2025年2月現在、教育向けに価値が高い「Edu」データセットは未公開です。そこで、本プロジェクトでは FineWeb2 Edu Japanese データセット を作成し、公開しました。

教育的データのフィルタリング

本データセットの構築には、FineWeb2 日本語データから、教育向け文章を判定するためのモデル fineweb-2-edu-japanese-classifier を利用してフィルタリングしました。判定モデルのスコアリングの教師データには、DeepSeek-API (deepseek-chat) によって評価された fineweb-2-edu-japanese-scores を使っています。なお、本データセットでは、スコアが2.5以上の文章のみを抽出しており、そのスコアは score カラムに記載しています。

トークンカウントの付与

ModernBERT-Ja-130M のトークナイザを用いてカウントしたトークン数が token_count カラムとして付与されています。

Web特有のノイズ除去

FineWeb2 の日本語データには、Web特有のボイラープレートや不要なノイズが含まれることがあります。例えば、以下のような文章が含まれます。

この文章は90日以上更新の無いサイトに表示されています。
ログイン ログアウト

本当に必要な文章以外にも、さまざまなノイズが含まれていることがあります。例えば、この文章もその一例です。本来不要なテキストが入ってしまうことがこのようにあるでしょう。

今なら50%オフ！クリックしてリンク先の商品を表示

とりわけ文章長が短い場合、文章のほとんどがノイズを含む可能性があります。それらを取り除くことで、より高品質の文章を抽出できないかと考えています。

前のページ  次のページ

このような不要なテキストを取り除くためのモデル、fineweb-2-japanese-text-cleaner を開発しました。ノイズ判定の教師データとしては、fineweb-2-japanese-noise-spans を利用しています。この教師データはcyberagent/DeepSeek-R1-Distill-Qwen-32B-Japanese を活用して作られました。

このモデルにより、以下のようにノイズ箇所が検出されます。

[NOISE]この文章は90日以上更新の無いサイトに表示されています。[/NOISE]
[NOISE]ログイン[/NOISE] [NOISE]ログアウト[/NOISE]

本当に必要な文章以外にも、さまざまなノイズが含まれていることがあります。例えば、この文章もその一例です。本来不要なテキストが入ってしまうことがこのようにあるでしょう。
[NOISE]
今なら50%オフ！クリックしてリンク先の商品を表示[/NOISE]

とりわけ文章長が短い場合、文章のほとんどがノイズを含む可能性があります。それらを取り除くことで、より高品質の文章を抽出できないかと考えています。

[NOISE]前のページ[/NOISE]  [NOISE]次のページ[/NOISE]

本データセットに含まれるsmall_tokens_cleaned サブセットは、small_tokens からさらに fineweb-2-japanese-text-cleaner モデルを適用し、ノイズを除去したデータとなります。なお、モデルを使ってノイズ検出をした生データは fineweb-2-edu-japanese-noise-detect-raw で公開しています。

なおノイズ検出は完璧ではないため、場合によっては正しい文章の一部が誤って除外されている可能性がありますのでご注意ください。

注意事項

本データセット「FineWeb2 Edu Japanese」と、Eduフィルタリングを実施していない大元の「FineWeb2」データセットとの比較実験は行っておりません。そのため、実際のLLM学習においてどの程度の効果差が生じるかは未検証です。

また、教育向けテキストかどうかの分類精度も完璧ではなく、一部教育向けではないテキストも含まれます。

ライセンス

本データセットは、元の FineWeb2 と同様に Open Data Commons Attribution License (ODC-By) v1.0 の下で公開します。また、使用にあたっては CommonCrawlの利用規約 も適用されます。

Citation Information

@software{yuichi2025fineweb-2-edu-japanese,
  author = {Yuichi Tateno},
  title = {FineWeb2 Edu Japanese},
  month = feb,
  year = 2025,
  url = {https://huggingface.co/datasets/hotchpotch/fineweb-2-edu-japanese/}
}