RAGシステムで多言語コンテンツ（中国語の契約書、日本語の技術マニュアル、ドイツ語の特許文書）を扱う場合、検索に使う埋め込みモデルのコンテキストウィンドウがわずか512トークンしかないという、厄介な事実に気づくだろう。一方、LLM自体はすでに128K、あるいは200Kトークンを処理できる。
つまり、ドキュメントをインデックスする際、実際に見ているのは最初の1ページだけかもしれないということだ。後続の内容は「無視される」のではなく、ベクトル空間にそもそも存在しない。検索の再現率の上限は、埋め込みモデルを選んだ瞬間に固定されてしまうのだ。
5月14日、IBMはGranite Embedding Multilingual R2シリーズをオープンソース化し、埋め込みモデルのコンテキストウィンドウを512から32Kへと押し上げた。同時に、Apache 2.0ライセンスと小規模なパラメータ数も維持している。これは単なるバージョンアップではない。長らく見過ごされてきたが、影響の大きい工学的なボトルネックに切り込むものだ。
埋め込みモデルのコンテキストウィンドウが重要な理由
RAGの典型的な流れは、ドキュメントをチャンク分割し、各チャンクをベクトル化し、クエリ時に最も類似したチャンクを検索するというものだ。ここには、各チャンクの内容が自己完結しており、完全な情報単位を独立して表現できるという暗黙の前提がある。
埋め込みモデルが512トークン（約380文字の中国語、または400語の英語）しか見られない場合、チャンクサイズは人為的に制限される。ニュースの要約、商品説明、FAQエントリのような短いテキストにはこれで十分だ。しかし、技術文書、法律上の契約書、学術論文のような本来的に長いコンテンツでは、512トークンという制約は、「細かく分割しすぎる」か「コンテキストを超える」かの二者択一を迫ることを意味する。
細かく分割しすぎる問題はより見えにくい。論理的な段落が二つに分割されると、前半部分は結論を失い、後半部分は前提を失う。どちらのベクトルも、ユーザーのクエリにマッチするには不十分となる。古典的なRAGのチュートリアルでは「適切なチャンクサイズとオーバーラップを設定する」ことを教えるが、オーバーラップを最大にしても、埋め込みモデル自体のコンテキストウィンドウこそが真の天井であるとはほとんど語られない。
Granite Embedding R2は、その天井を一気に32Kトークン（R1の512トークンの64倍）へと引き上げた。これは、30ページのPDF技術マニュアルを、分割せずに直接エンコードできることを意味する。さらに重要なのは、検索精度を犠牲にして長文化したわけではない点だ。LongEmbedベンチマークでは、R2はR1から30ポイント以上向上し、34.3点から65.6点（97Mモデル）へと飛躍した。この性能の飛躍は、ほぼ完全にコンテキストウィンドウの拡張によるものだ。以前のモデルは、長文ドキュメントの全文を見ることすらできなかったのだ。
二本柱：97Mの軽量型と311Mのフルサイズ
Granite Embedding R2は、ModernBERTエンコーダーアーキテクチャに基づく2つのモデルをリリースした。ModernBERTは、昨年登場したBERTの現代化改造版であり、絶対位置エンコーディングを回転位置エンコーディングに置き換え（より長いシーケンスへのネイティブな外挿をサポート）、長いシーケンスの計算量を削減する交互アテンション、GPUエンコーディングを高速化するFlash Attention 2.0を統合している。
選択の鍵はパラメータ規模にある。
97Mモデル（granite-embedding-97m-multilingual-r2）の出力次元は384、パラメータはわずか9700万でありながら、多言語MTEB検索で60.3点を達成した。これは、multilingual-e5-base（2億7800万パラメータ、52.7点）やgte-multilingual-base（3億0500万パラメータ、57.2点）を上回る。3倍小さいモデルで、より高いスコアを出したのだ。これは本番環境にとって、同じハードウェア予算でより多くのドキュメントを処理できるか、より小型のインスタンスに埋め込みサービスをデプロイできることを意味する。
311Mモデル（granite-embedding-311m-multilingual-r2）の出力次元は768で、マトリョーシカ埋め込みをサポートしている。つまり、次元を512、384、256、あるいは128に切り詰めても、検索品質はほとんど低下しない。MTEB多言語検索では65.2点を獲得し、5億パラメータ未満のオープンソースモデルの中で第2位にランクされている。
エンコーディング速度では、97Mモデルは単一のH100 GPU上で毎秒2500以上のドキュメントをエンコードでき、311Mモデルは約1800ドキュメント/秒だ。これは、同等の検索品質を持つjina-embeddings-v5-text-nanoよりも5.5倍以上高速である。
多言語サポートの真の実力
「200以上の言語をサポート」というのは、埋め込みモデルの宣伝文句としてもはや珍しくないが、真の品質差は細部にある。Granite Embedding R2は、52言語に対して明示的な検索ペアトレーニングとクロスリンガルトレーニングを施している。つまりこれらの言語では、モデルは単に同じ言語のテキストベクトルを近づけるだけでなく、「関連する」ドキュメントと「関連しない」ドキュメントを区別できるのだ。
工学的な観点から最も重要なのは、トークナイザーのカバレッジである。多くの埋め込みモデルは特定の言語をサポートすると主張していても、その言語でのトークナイザー効率が極めて低い。例えば、タイ語の段落一つでコンテキストウィンドウの半分が消費されてしまうこともある。R2の97Mモデルは、26.2万トークンの語彙から選別した18万トークンの語彙を使用しており、多言語カバレッジを維持しつつ、埋め込みテーブルのサイズを大幅に削減している。311Mモデルは、Gemma 3のトークナイザーである26.2万トークンの語彙をそのまま採用している。
クロスリンガル検索において、311MモデルはBelebele（122言語のクロスリンガルパッセージマッチング）で66.5点、MLQA（7言語のクロスリンガル質問応答検索）で67.1点を獲得した。これはR1からそれぞれ4.3点、4.1点の向上である。
コード検索：過小評価されているRAGシナリオ
多言語能力に加えて、R2はコード検索のサポートも追加した。Python、Go、Java、JavaScript、PHP、Ruby、SQL、C、C++の9言語をカバーし、言語横断的なコード検索にも対応する。
これは実用的なシナリオで非常に有用だ。あなたのチームが国際的なコードベースを管理しており、ドキュメントは英語で書かれ、コメントは中国語、日本語、英語が混在し、あるモジュールはドイツ語のローカライズを専門に処理していると想像してみてほしい。以前の埋め込みモデルを使っていた場合、「handle date format」と「日付フォーマット処理」という検索で、全く異なる結果が得られる可能性がある。クロスリンガルなコード検索能力があれば、両者の意味を類似したベクトル空間に位置づけることができる。
MTEB Codeベンチマークでは、97Mモデルが60.4点、311Mモデルが63.8点で、R1からそれぞれ19.7点、15.3点向上した。
既存のRAGシステムへの統合方法
Granite Embedding R2は、既存のRAGフレームワークの埋め込みモデルをシームレスに置き換えることができる。sentence-transformersユーザーであれば、必要なのはコード1行の変更だけだ。
from sentence_transformers import SentenceTransformer
model = SentenceTransformer(
"ibm-granite/granite-embedding-97m-multilingual-r2"
)LangChainユーザーの場合：
from langchain_huggingface import HuggingFaceEmbeddings
embeddings = HuggingFaceEmbeddings(
model_name="ibm-granite/granite-embedding-97m-multilingual-r2"
)LlamaIndexやHaystackでも同様に、一行の置き換えで対応可能だ。
311Mモデルを使用し、ストレージと計算コストを節約したい場合、マトリョーシカによる次元削減は非常に実用的な機能である。
from sentence_transformers import SentenceTransformer
model = SentenceTransformer(
"ibm-granite/granite-embedding-311m-multilingual-r2"
)
# 256次元に切り詰めても、品質低下は1%未満
embeddings = model.encode(
["example text"], truncate_dim=256
)MTEB多言語検索では、768次元と比較して256次元でのスコア低下はわずか0.5点（65.2→64.7）であり、ストレージと類似度計算のコストは3分の1に削減される。
実装における境界線
Granite Embedding R2のApache 2.0ライセンスは、商用プロジェクトでの制限なしの利用を意味する。しかし、モデルを選択する際にはいくつかの境界線に注意する必要がある。
97Mモデルは、Belebeleのクロスリンガル検索においてR1よりもスコアが低下している（52.9 vs 55.1）。これは、語彙の選別とパラメータ削減によるトレードオフである。より広範な多言語検索では大幅にリードしているものの、狭い範囲のクロスリンガルタスクでは後退しているのだ。非常に多くの言語ペアでの検索が中心的なシナリオである場合は、311Mモデルの方が良い選択となる。
97Mモデルはマトリョーシカによる次元削減をサポートしておらず、ネイティブの384次元である。ベクトル次元数を柔軟に制御する必要がある場合は、必ず311Mモデルを選択しなければならない。
両モデルともエンコーダーモードのみをサポートし、生成には対応していない。純粋な埋め込みモデルであり、LLMの代わりに理解や回答を行うことはできない。埋め込みモデルとLLMはRAGパイプラインにおいてそれぞれの役割を担うものであり、Granite Embedding R2を選択することで向上するのは検索の再現率であり、生成品質ではない。
最後に、32Kのコンテキストは強力だが、長いドキュメントのエンコードにおける遅延と計算コストも線形的に増加する。遅延に敏感なシナリオでは、全ドキュメントのエンコードが本当に必要か、あるいはインテリジェントな分割と32Kウィンドウの組み合わせによってより良い効果が得られないかを評価する必要がある。
進化する埋め込み層
Granite Embedding R2の登場は、明確なシグナルを発している。すなわち、埋め込みモデルはもはやRAGパイプラインにおける静的なコンポーネントではなく、LLMと同様のコンテキスト拡張を経験しているということだ。LLMが数百万トークンレベルでコンテキスト長を競っている今、埋め込み層における512トークンの制限は、すでに現実的なボトルネックとなっている。
本番レベルのRAGシステム、特に多言語コンテンツ、長文ドキュメント、コード検索を処理する必要があるシステムにとって、埋め込みモデルを32Kコンテキストウィンドウにアップグレードすることは、短期的に最も投資対効果の高い最適化の一つとなるだろう。
#RAG #LLM応用工学 #AI応用開発 #埋め込みモデル #多言語検索