Sentence Transformers : エンベディングの提供 ローカル

#埋め込みとは何か、ライブラリは何をするのか

埋め込みモデルは、テキストを数値のリスト、つまりベクトルに変換し、意味が近い2つのテキストのベクトルも近くなるようにします。Sentence Transformersのドキュメントでは、バイエンコーダーと呼ばれるこれらのモデルについて、テキストを固定サイズの表現に変換し、埋め込みの計算は多くの場合効率的で、類似度の計算は非常に高速だと説明しています。これはRAGの土台です。質問をエンコードし、ベクトルが最も近い文章の箇所を検索して、それらを言語モデルに渡します。ここから押さえておくべき点が2つあります。文書と質問のエンコードには同じモデルを使う必要があること、そして、そのモデルの「近さ」の基準は学習によって決まることです。主に英語で学習したモデルは、フランス語の意味の近さを判断するうえではあまり信頼できません。

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")
sentences = [
    "The weather is lovely today.",
    "It's so sunny outside!",
    "He drove to the stadium.",
]
embeddings = model.encode(sentences)
print(embeddings.shape)  # [3, 384]
similarities = model.similarity(embeddings, embeddings)

このモデルは384次元のベクトルを生成し、最初の例として使えますが、英語向けに設計されています。フランス語のコーパスを使用する場合は、後述の説明に従って置き換えてください。ライブラリは、利用可能な最適なデバイス（cuda、mps、cpu）にモデルを自動的に配置します。device パラメータで使用するデバイスを指定することもできます。

#インストールとフランス語コーパスのエンコード

1. 01
   ライブラリのインストール

   Python環境で pip install -U sentence-transformers を実行してください。PyPIによると、2026年9月18日に6.1.0版がリリースされ、Python 3.10以降が必要です。
2. 02
   多言語モデルを選ぶ

   多言語対応とされているモデルを選んでください（下の表を参照）。英語向けに学習されたall-*モデルは選ばないでください。
3. 03
   ドキュメントをまとめてエンコードする

   encode にテキストのリストを渡してください。ライブラリがまとめてバッチ処理するため、テキストごとに呼び出すよりもハードウェアをはるかに効率よく活用できます。
4. 04
   同じモデルで質問をエンコード

   ドキュメントに使用したものと同じモデルと同じプレフィックスを使い、その後 similarity で比較してください。
5. 05
   モデル名をインデックスと一緒に保存する

   モデル名をメタデータに記録してください。モデルを変更した場合は、コーパス全体を再エンコードする必要があります。

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("intfloat/multilingual-e5-large")

docs = [
    "Le contrat peut être résilié avec un préavis de trois mois.",
    "La facture est payable à trente jours fin de mois.",
]
question = "Quel est le délai pour mettre fin au contrat ?"

doc_emb = model.encode(docs, prompt="passage: ", normalize_embeddings=True)
q_emb = model.encode(question, prompt="query: ", normalize_embeddings=True)
print(model.similarity(q_emb, doc_emb))

質問には query:、文書には passage: というプレフィックスを付ける方法が、Sentence Transformersのドキュメントでこのモデルについて示されています。これらを付けないと、エラーメッセージが出ないまま検索性能が低下します。encodeのpromptパラメータは、各テキストにプレフィックスを適用します。

#フランス語を理解できるモデルを選ぶ

ドキュメントでは、元のモデルを提案し、MTEBランキングを参考にするよう促しています。ただし、2つの注意点があります。ハードウェアに対して大きすぎるモデルを除外すること、そして、ランキング上位のモデルが必ずしも独自のタスクで成功するとは限らないため、実験を行うことです。次の表は、ドキュメントが言及しているモデルに関する内容をまとめたものです。

#エラーメッセージを出さずにコーパスを台無しにするミス

フランス語に英語モデルを使う

すべて正常に動作しているのに、検索結果は歪んでしまいます。これは最もよくある誤りです。

モデルの限界を超える長さのセグメント

ドキュメントには、長すぎるテキストは先頭からmax_seq_lengthで指定された数のトークンだけが残るように切り詰められると明記されています。そのため、長い各文章の末尾はモデルから見えなくなります。

ドキュメントと質問に対して異なるモデルを使用する

ベクトルが同じ意味を表さなくなるため、異常な結果が出ます。これは通常、処理の流れの一部だけを更新したときに起こります。

プレフィックスの付け忘れ

一部のモデルでは、質問とドキュメントでそれぞれ異なるプレフィックスが必要です。プレフィックスを省略すると、検索精度が低下します。

正規化されていないベクトルと不適切なスコア

モデルがコサイン類似度を前提としている場合は、ベクトルを正規化するか、対応する類似度指標を使用してください。そうしないと、検索結果の順位付けの精度が低下します。

#近さを測る：正規化とコサイン

2つのベクトルは類似度指標で比較し、最もよく使われるのはコサイン類似度です。Ollamaのドキュメントには、エンドポイントが正規化されたベクトルを返すと記載されており、ほとんどのセマンティック検索にコサイン類似度を推奨しています。正規化されたベクトルでは、コサイン類似度と内積で同じ順位が得られるため、内積用に最適化されたインデックスを利用できます。注意すべきなのは整合性です。ベクトルデータベースで使う類似度指標は、モデルが想定する指標と一致している必要があります。その指標はモデルカードに記載されています。

長期的な観点から、ドキュメントでは目安として、BERT系の多くのモデルで512トークン、英語で300〜400語に相当し、all-MiniLM-L6-v2では256トークンとされています。フランス語は単語あたりのトークン消費量が多いため、制限値に余裕を持たせてテキストを分割し、model.max_seq_length を確認してください。値を下げることができますが、モデルがサポートする範囲を超えて増やすことはできません。ドキュメントでは、短いテキストで学習されたモデルは長いテキストを適切に表現しにくいことも追加されています。

#マシン上で高速にインデックスを構築する

プロセッサまたはGPU

モデルは、利用可能な中で最も適した処理デバイス上で実行されます。GPUは大量データのインデックス作成を高速化しますが、単発のクエリでは効果はわずかです。

数値精度の削減

ドキュメントによると、GPU上ではfloat16またはbfloat16に切り替えることで、精度の低下を最小限に抑えながら推論を高速化できます。

ONNXおよびOpenVINOバックエンド

ドキュメントでは、ハードウェアやバックエンドによっては最大で2〜3倍の高速化が可能とされています。お使いのマシンで試してみてください。

複数のGPUまたはプロセス

encode はデバイスのリストを受け付けるため、大きなコーパスでは有用ですが、小さなコーパスでは起動コストのためあまり効果がありません。

よりコンパクトなベクトル

ベクトルのバイナリ量子化や整数量子化、そして次元数を切り詰められるモデルは、ストレージ使用量と検索コストを削減します。

キャッシュとインデックス化

変更のないドキュメントは再エンコードしないでください。キャッシュキーはファイル名ではなく、内容に基づきます。言語モデルも提供しているマシンでは、誰も利用していない時間帯にインデックスを構築してください。

#ベクトルインデックスの容量

インデックスのサイズは、ベクトル数をその次元数および float32 の場合の 4 バイトで乗算して計算します。384 次元のベクトルは 1,536 バイトを占有します。100万件の文章は約 1.5 GB に相当します。1,024 次元の場合、同じ 100万件の文章は約 4 GB を占有します。これらの値には、ベクトルデータベースのメタデータやインデックス構造は含まれません。したがって、モデルの選択は検索に必要な RAM に直接影響を与え、前述のベクトル量子化はこのフットプリントを削減できます。

#Sentence Transformers または Ollamaの埋め込みAPI

Ollama は埋め込みも公開しています。ドキュメントによると、コマンド ollama run peut はベクトルを生成し、api/embed エンドポイントは L2 正規化されたベクトルを返します。embeddinggemma、qwen3-embedding、all-minilm モデルが推奨されており、ベクトルの次元数は通常 384 から 1 024 次元です。また、二つのルールが示されています。ほとんどの検索にはコサイン類似度を使用すること、インデックス作成と照会には同じモデルを使用することです。

#埋め込みによる選別は一次的なものにすぎません

Sentence Transformersのドキュメントでは、バイエンコーダーは2段階検索の第一段階と説明されています。次にクロスエンコーダー（リランカー）が上位候補を再ランキングします。クロスエンコーダーは質問と各パッセージを一緒に読み取るため、処理は遅くなりますが、少数の候補に対してより正確です。類似度検索で約20件のパッセージを取得し、それらを再ランキングして少数に絞ることは、RAGパイプラインで比較的低コストな改善策の一つです。リランカーの導入方法は専用ガイドで説明しています。採用する前に20件の質問で効果を測ってください。リランカーを加えると各リクエストの遅延が増え、2つ目のモデルの保守と追加のメモリが必要になります。

モデルを比較する前に、まずコーパスに何が含まれているかを確認するとよいでしょう。短く、それぞれ単独で意味が通じる文でしょうか。それとも、長い技術的な段落でしょうか。質問はキーワードを並べた形でしょうか。それとも、完全な文でしょうか。その答えが、長さの上限、分割方法、モデルを選ぶ指針になります。内容の詰まった法律文書のコーパスには、短い質問と回答のデータベースとは異なる設定が必要です。公開ランキングが、こうした事情をあなたに代わって把握してくれるわけではありません。

#インデックス化前にモデルの選定を評価する

1. 01
   二十問を実際に書く

   ユーザーが実際に尋ねるであろう質問を選び、文書中の表現ではなく、ユーザー自身の言葉で書いてください。
2. 02
   検索で得たい箇所を記録する

   各質問について、回答を含む箇所を一つ以上特定してください。
3. 03
   2つまたは3つのモデルを比較する

   同じコーパスを各モデルでエンコードし、適切な文章の一節が検索結果の上位5件に含まれるかを確認してください。
4. 04
   変更ごとに再実行

   モデル、チャンク分割、またはプレフィックスを変更した場合は、再インデックス化する前に、この簡単なテストをもう一度実行してください。

#FAQ

#さらに詳しく

• フランス語向けの最適な埋め込みモデル
• BGE-M3：フランス語をしっかり扱える埋め込み
• パイプラインにリランカーを追加する
• チャンキング戦略
• Qdrant：ローカルRAGのベクトルデータベース
• ローカル RAG：入門

• 出典：Sentence Transformers、クイックスタート
• 出典：Sentence Transformers、埋め込み計算
• ソース：Sentence Transformers、事前学習済みモデル
• ソース：Ollama、エンベディング