三値（BitNet系）に量子化したテキスト埋め込みモデルとは｜ローカルRAGの保存量と推論を同時に削る

この記事でわかること

• テキスト埋め込みモデルの「二重のコスト」（ベクトル化の推論と、ベクトルDBの保存・帯域）がどこにあるか
• 重みを三値（−1・0・+1）まで落とすBitNet系の量子化を埋め込みに持ち込むと精度がどうなるか
• 英語ベンチマーク（MMTEB）で報告された精度と、フル精度モデルとの差
• 公開された配布モデルで、いまわかっていること・まだわからないこと
• ローカルRAGでこの種のモデルが向く場面と、向かない場面

RAG（検索拡張生成）やセマンティック検索が実用の中心になり、文章をベクトルへ変換する「埋め込みモデル」を大量に、しかも継続的に動かす場面が増えた。ドキュメントを追加するたびにベクトル化し、質問のたびに問い合わせ文をベクトル化する。この処理は一見地味だが、扱う文書が数万・数百万件と増えるほど、システム全体のコストを静かに押し上げていく。

今回Hugging Faceで公開された「bitnet-embedding-270m」「bitnet-embedding-0.6b」は、この埋め込みのコストに正面から手を入れたモデルである。裏側にあるとみられるのは、北京大学とMicrosoft Researchが公表した埋め込み向けの量子化手法「BITEMBED」だ。モデルの重みを三値（−1・0・+1の3値）まで大胆に落とすBitNet系のアプローチを、テキスト埋め込みに持ち込んだものだ。以下では、この種の「極端に軽い埋め込み」が何を解こうとしていて、精度と速度がどうなり、どんな用途で現実的な選択肢になるのかを整理する。

なぜ埋め込みモデルは「二重に」重いのか

埋め込みモデルのコストは、性格の違う二つに分かれる。

一つ目は推論（ベクトル化）のコストである。近年は大規模言語モデル（LLM）を土台にした埋め込みモデルが精度で先行しているが、土台が大きいぶん、一文をベクトルにするだけでも計算が重い。検索対象の文書をすべてベクトル化する初期処理はもちろん、利用者が問い合わせるたびに走る変換も積み重なる。

二つ目は保存と帯域のコストである。出力されるベクトルは数百〜数千次元あり、これを高い精度（多くは16ビットや32ビットの浮動小数点）で持つと、1件あたりのデータ量が大きくなる。数百万件のベクトルを抱えるインデックスでは、この保存容量とメモリ、そして検索時のデータ移動量が支配的になりやすい。エンコーダ側をいくら速くしても、この保存側のコストは別に効いてくる。

BITEMBEDが狙うのは、この二つを同時に削ることだ。モデル本体（バックボーン）を量子化して推論を軽くし、さらに出力するベクトル側も低ビットで持てるように設計している。

三値（BitNet系）埋め込みの仕組み

通常のニューラルネットワークは、重みを16ビットなどの浮動小数点で持つ。BitNet系のアプローチは、この重みを三値（さんち）に置き換える。三値とは−1・0・+1という3つの値だけで重みを表すことで、これまで小数で細かく持っていた一つひとつの重みを、この3択に割り切ってしまう発想だ（値が2つなら二値、3つなので三値）。三値を区別するための理論上の情報量は、重み1つあたり約1.58ビット（log₂3）に相当する。これにより、重みとの積の主要部分を加算・減算・ゼロのスキップで処理しやすくなる（重みのスケール係数に関する乗算は残る）。さらに重みのデータ量そのものも小さくなるため、対応する低ビット実装や最適化カーネルでは、CPU上の演算とメモリ帯域の負担を減らせる。BITEMBEDはこの考え方を埋め込みモデルの本体に適用し、あわせて層内の活性（中間の値）はトークンごとに8ビットへ量子化している。

ただし、重みをここまで削ると当然そのままでは精度が落ちる。BITEMBEDはそれを取り戻すために、いくつかの工程を重ねている。まず大量の文ペア（論文では10億ペア）で対照学習による事前適応を行い、次に検索形式に整理された教師ありの埋め込み学習データで微調整する。その際、フル精度（16ビット）のまま学習させた「教師モデル」を用意し、教師が出す類似度の分布や注意（アテンション）の関係を、量子化した生徒モデルが真似るように学習させる。量子化で失われがちな細かな構造を、教師から蒸留して補う設計である。

論文の分析では、こうした工程を省くと精度が明確に落ちる。単純に三値化して微調整しただけの版は英語MMTEBの平均で58.92まで下がる一方、事前適応と蒸留、量子化で暴れやすい中間の値を整える正規化を組み合わせた完成版は67.60まで回復する（この内訳はQwen3-0.6Bでの検証）。つまり「三値にしただけ」では不十分で、精度を戻す学習の作り込みが要点になっている、と読み取れる。

精度はどこまで保てるのか（英語MMTEBでの報告値）

論文は、埋め込みの標準的な評価集であるMMTEB（英語・v2）で、同じバックボーンを使い、同じ教師ありデータで直接微調整したフル精度版（FP16）のモデルと、三値化したBITEMBEDを突き合わせている。ただし、両者の違いは量子化の有無だけではない。BITEMBED側には継続事前学習、正規化モジュール、教師モデルからの蒸留など、低ビット化による精度低下を補う工程も含まれる。数値は論文の報告値である。

読み取れるのは二点ある。第一に、精度の落ち込みが小さい。Qwen3-0.6Bを土台にした場合、三値化しても平均67.60で、フル精度版67.95との差は0.35ポイントにとどまる。より小さいGemma3-270Mでも66.10対66.71で、差は0.61ポイントである。これだけ大胆に量子化しても、フル精度版とほぼ変わらない水準を保っている。

第二に、CPU上ではむしろ速い。三値の重みはかけ算が軽くなり、さらにデータ量が小さくメモリからの読み出しも減るため、同じバックボーンでもトークン処理速度が上がっている。Qwen3-0.6Bで364から830へ（約2.3倍）、Gemma3-270Mで1181から2055へ（約1.7倍）と報告されている。ただし論文が示すのはCPU・8スレッドという条件までで、CPU型番や使用ランタイム、入力長・バッチ条件などの詳細は明記されていない。倍率は環境に依存すると見ておくのが妥当だ。

ここで一つ、はっきりさせておくべき制約がある。上表は英語MMTEB（eng, v2）の結果である。一方、論文の付録には多言語MMTEBの総合結果も掲載されており、Qwen3-0.6B系ではBITEMBEDが67.49・フル精度版が69.00、Gemma3-270M系では66.26対66.55だった。ただし、日本語だけを切り出した評価値は示されていない。また、多言語実験は英語版と異なる学習設定を使っており、公開GGUFとの対応関係も明記されていない。そのため、日本語主体のRAGでは独自評価が必要である。

ベクトル側の精度も選べる

BITEMBEDのもう一つの特徴は、出力するベクトル自体の精度を用途に合わせて選べることだ。論文上のBITEMBEDは、出力ベクトルを1・2・4・8・16ビットで量子化して利用できるように学習されている。保存容量を最優先するなら低ビット、精度を優先するなら高ビット、という段階的なトレードオフを想定した設計だ。ただし、公開GGUFから各ビット幅のベクトルを取得する具体的な手順は、配布ページでは説明されていない。

実用上の要点は4ビットの列にある。Qwen3-0.6Bでは4ビットでも67.45で、16ビット時の67.60とほとんど変わらない。ベクトルを16ビットから4ビットへ落とすと、ベクトル値本体の理論上の保存量は約4分の1になる。ただし、量子化スケールやベクトルDBの索引・ID・メタデータなどの容量は別に必要で、データベース全体がそのまま4分の1になるわけではない。1ビットや2ビットまで落とすと精度の低下がはっきり出るため、少なくとも英語MMTEBの平均値を見る限り、4ビットは精度と保存量を両立する有力な検証候補になる。

公開された成果物と、いまわかること

MicrosoftのHugging Faceには、論文で扱われたものと同じ二つのバックボーン構成に対応するモデルが公開されている。公開直後はモデルカードが未整備だったが、2026年8月9日に確認した時点では両リポジトリともモデルカードが用意され、実行手順も載っている。Transformersなら AutoModel.from_pretrained("microsoft/bitnet-embedding-0.6b") で読み込め、bitnet.cpp では llama-embedding に --embd-normalize 2 を渡す例が示されている。llama.cpp・Ollama・LM Studio・Jan・Unsloth Studio・Docker Model Runner 向けの案内もある。ただし、論文で評価されたチェックポイントとの厳密な対応関係は、いまも明示されていない。

• microsoft/bitnet-embedding-270m … Gemma3-270Mが土台。確認時点のHugging Face表示で367MB（i2_s形式のGGUF＝BitNet向けの低ビット重み形式）
• microsoft/bitnet-embedding-0.6b … Qwen3-0.6Bが土台。確認時点のHugging Face表示で428MB（i2_s形式のGGUF）

重みファイル自体はいずれも500MB未満である。BitNet系は低ビット推論による省メモリ化と高速化を狙った設計で、公式推論実装ではCPU向けの最適化も進められているが、実行時に必要なメモリまでは配布ページからは確認できない。文書追加が多い環境や問い合わせ頻度が高いサービスでは、エンコード速度の差が継続的な計算コストに影響する。

一方で、未確定な部分も残る。ライセンスは2026年8月9日時点で両リポジトリともMITと明記されている。なおarXiv論文のCC BY 4.0は論文本文に対するもので、モデルファイルの利用条件とは別物なので、混同しないほうがいい。裏付けの論文も査読前の版で、数値は著者らの報告に基づく。さらに、前掲の精度・速度は論文が評価したモデルでの測定値であり、公開されたGGUF（i2_s）から同じ数値が再現される保証はない。実際に採用を検討する段階では、自分の用途・言語・データで手元環境で小さく試してから判断するのが安全だ。試すなら、GGUFに対応した推論ツールや配布リポジトリの案内から確認することになる。論文が示すEOSトークンの最終隠れ状態を使うプーリングと、タスク指示文の付け方は、モデルカード側にも同じ内容が書かれている（最終の非パディングトークンを取ってL2正規化する、指示文はクエリ側にだけ付けて文書側には付けない）。ただし、出力ベクトルを1・2・4・8ビットのどれで取り出すかを切り替える手順までは書かれておらず、そこは自分で確かめることになる。

どんな用途に向くか

ここで挙げるのは、主に論文で示された手法上の特性から考えられる用途であり、公開GGUFで各機能をすぐ利用できることを意味しない。この種の「極端に軽い埋め込み」が選択肢になりやすいのは、次のような場面だ。

• ローカルやエッジでのRAG … 手元のPCや小さなサーバー、CPU中心の環境で、外部APIに頼らず埋め込みを回したいケース
• 大規模なベクトルインデックス … 数百万件規模で、ベクトルの保存容量とメモリが効いてくる用途。出力ビット幅を下げて容量を削れる利点が大きい
• コストと運用の単純さを最優先する場面 … GPUを用意せずに、そこそこの精度で常時動かし続けたいケース

逆に、無理に選ぶ必要が薄いのは次のような場合だ。日本語や多言語での高い精度が最優先で、まだ検証データが乏しいうちは、実績のある多言語埋め込みモデルのほうが選びやすい。扱う件数が小さく、GPUの余力も保存容量も足りているなら、量子化で得られる利点は相対的に小さい。また、公開直後で情報が揃いきっていない現時点では、本番投入の前に検証工程を挟む前提で見ておきたい。

この種のモデルは、既存のRAG構成に組み込む一部品として捉えると位置づけがはっきりする。ローカルでRAGを構築する具体的な手順はOllamaでローカルRAGパイプラインを構築する方法やローカルRAGとは（Ollama・ChromaDB・Gemma）で扱っており、埋め込みモデルはそうした構成の中で差し替えられる部品にあたる。

まとめ

BITEMBEDは、「LLMベースの埋め込みは精度は高いが重い」という課題に対して、重みを三値まで削るBitNet系の量子化と、教師モデルからの蒸留で精度を戻す学習を組み合わせた手法である。英語のMMTEBでは、フル精度版との差を1ポイント未満に抑えつつ、CPU・8スレッド条件での処理速度をおおむね1.7〜2.3倍に上げ、さらにベクトル側の精度も選べるようにして保存コストにまで踏み込んでいる。

公開されたGGUFはいずれも重みファイルが500MB未満で、CPUローカル環境向けの軽量な埋め込み候補になり得る。なお実行手順・対応ランタイム・ライセンス（MIT）はモデルカードで確認できるが、出力ビット幅の切り替え手順は書かれておらず、そこは手元での確認が前提になる。主要表は英語評価で、多言語の総合評価も報告されているが、日本語単独の性能は示されていない。論文も査読前の版である。日本語主体で使うなら、この記事の数値を出発点にしつつ、自分のデータで小さく試して精度を確かめる——それが、公開直後のこの種のモデルとの現実的な付き合い方になる。

参考資料