9月4日、vettedconsumer.comが「Local Embedding Models for RAG: What They Are & Which to Use」と題した記事を公開した。ローカルRAGを構築する際、回答が的外れになる原因のほとんどはLLMではなくEmbeddingモデルが間違った断片を渡していることにある——記事はこの見落とされがちな事実を軸に、モデルの仕組みから実践的な選択指針までを体系的に整理している。
RAGの「司書」役——Embeddingモデルとは何か
RAG（Retrieval-Augmented Generation）は、手元のドキュメントをローカルLLMに参照させる標準的な手法だ。チャットに答えるLLMばかりに目が向きがちだが、実はその精度を左右するのはEmbeddingモデルというもう一方の存在である。
Embeddingモデルがやることはシンプルだ。テキストを読み込み、384・768・1024次元といった固定長の数値ベクトルに変換する。意味が近いテキストはベクトル空間上で近い位置に、無関係なテキストは遠い位置に配置される。これだけの仕組みで「質問に関連するドキュメントの断片を探す」という処理が、「最も近いベクトルを探す」という高速な数値計算に変換される。
RAGにおけるEmbeddingモデルの役割は「司書」だ。ドキュメントをインデックス化し、質問が来たときに関連する断片を数個取り出す。LLMはその断片を読んで回答を生成する「書き手」に徹する。この構造はLewis et al.（2020）のRAG論文で定式化され、検索部分はDense Passage Retrieval（Karpukhin et al., 2020）に基づいている。
ローカルRAGの回答が的外れになるとき、原因はLLMではなくEmbeddingモデルが間違った断片を渡していることが多い。 モデル選定とパラメータ設定に注意を払うだけで、同じLLMを使っていても回答精度は大きく変わる。
GPUはほぼ不要——ハードウェア要件の現実
Embeddingモデルはチャット用LLMと比べて圧倒的に小さい。パラメータ数は数億以下が一般的で、CPUで十分に動作し、メモリ消費も数百MB程度だ。LLMと同じマシン上で並走させても負荷はほぼ気にならない。Raspberry Piや小型PCでも動く。
コストはハードウェアではなく、「自分のコンテンツの意味をきちんと捉えるモデルを選べているか」という選択眼の問題だ。
どのモデルを選ぶか——用途別の選択指針
記事では以下の選択指針が示されている。
| 用途 | 推奨モデル系統 |
|---|---|
| 軽量・高速、まず試したい | all-MiniLM系（384次元） |
| 汎用的な品質のデフォルト | BGE / E5系（base または large） |
| 品質最優先、計算資源に余裕あり | 大規模多言語・instruction-tuned系（1024次元） |
| コード検索・取得 | voyage-code-2 / CodeBERT系などコード特化型 |
ベンダーのベンチマーク資料よりも、Hugging Face上のオープンベンチマーク「MTEBリーダーボード」を参照するのが実践的だ。数十の検索・分類タスクでEmbeddingモデルをランキングしており、モデルサイズや言語でフィルタリングして自分のマシンに合うものを選べる。
汎用の出発点として記事が推奨するのはBGEまたはE5系だ。代表的なモデルとしては、Hugging Face上のBAAI/bge-base-en-v1.5（768次元・英語向け）やintfloat/multilingual-e5-base（多言語対応）がある。MTEBリーダーボードでも上位に位置しており、品質と速度のバランスが取れた現実的な選択肢だ。
記事が強調する2つの鉄則がある：
- ドキュメントの言語・ドメインとEmbeddingモデルを一致させる
- 1つのベクターインデックス内では必ず同一のEmbeddingモデルを使う——異なるモデルを混在させると距離計算が意味をなさなくなる
日本語コンテンツへのRAG適用における注意点
※編集部の考察
日本語ドキュメントを扱うRAGを構築する場合、英語特化モデル（all-MiniLM-L6-v2など）をそのまま使うと検索精度が大きく低下することがある。上記の「ドキュメントの言語とモデルを一致させる」という鉄則がここで特に効いてくる。日本語対応を確認する際もMTEBリーダーボードの言語フィルタが役立つ。多言語対応が明示されているE5系（multilingual-e5-baseなど）や、日本語特化モデルを選ぶことを検討するとよい。
見落とされがちな2つの設定パラメータ
モデル選定と同等に品質を左右するのが、以下の2つのパラメータだ。
- チャンクサイズ：ドキュメントを分割する際のトークン数。数百トークン程度で、前後に少しオーバーラップを持たせるのが基本。大きすぎると検索が曖昧になり、小さすぎるとコンテキストが失われる。コンテンツの性質（長文の論文か、短いFAQか）によって最適値は変わるため、実際のドキュメントで試しながら調整するのが現実的だ。
- 取得チャンク数：上位3〜6チャンクが目安。多く取りすぎるとLLMのコンテキストウィンドウが希薄な情報で埋まり、回答の焦点が散漫になる。少なすぎると必要な情報が届かない。このトレードオフを意識してチューニングすることが重要だ。
まとめ
EmbeddingモデルはローカルRAGスタックの地味な半分だが、無視すると回答精度が根本から崩れる。ハードウェア要件は低く、モデルの差し替えも容易だ。BGEまたはE5系から始め、チャンクを整理し、少数ずつ取得し、インデックス全体で同一のEmbeddingモデルを使う——この4点を守るだけで、ローカルRAGの信頼性は大きく変わる。日本語コンテンツを扱う場合は、多言語対応モデルを選ぶことをあわせて検討したい。
詳細はLocal Embedding Models for RAG: What They Are & Which to Useを参照していただきたい。
