埋め込みモデルのローカル運用

🎓 レベル：標準　|　重要度：A（必須） 📎 前提：OpenAI互換API　|　原理：検索拡張生成（機械学習）

要点（結論先出し）

埋め込みモデル＝テキストを意味を表す数百〜数千次元のベクトルに変換する専用モデル。生成（チャット）モデルとは別物。
ローカルで埋め込みも動かせば、文書の検索・類似判定・RAGを完全オフラインで組める。
生成モデルより軽いことが多く、CPUでも実用的。OpenAI互換の /v1/embeddings で叩ける（要最新確認）。

概念 ── ベクトル化は「意味の座標」を与える

埋め込みは、似た意味の文を近い位置に配置するようテキストをベクトルにします。これにより「キーワード一致」ではなく意味で検索できる。RAG（第7章）の土台であり、原理は機械学習へ → 検索拡張生成。

生成モデルとは目的が違うので、別のモデルを使い分けるのが普通です（例：nomic-embed-text・mxbai-embed-large・bge 系など・要最新確認）。

動くコード（埋め込みAPI・Python）

from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="local")

texts = ["ローカルLLMはオフラインで動く", "犬は散歩が好きだ"]
resp = client.embeddings.create(
    model="nomic-embed-text",   # 埋め込み用モデル。要最新確認
    input=texts,
)
vecs = [d.embedding for d in resp.data]
print("ベクトル次元:", len(vecs[0]))   # 例: 768 など

類似度はコサイン類似度で測ります（計算例は対応lab）。

仕組み ── 生成と埋め込みは別ライン

flowchart LR
  DOC["文書・クエリ"] --> EMB["埋め込みモデル"]
  EMB --> VEC["ベクトル"]
  VEC --> DB["ベクトルDBに保存・検索"]
  DB --> CTX["近い文書を取り出す"]
  CTX --> GEN["生成モデルへ文脈として渡す"]

埋め込み＝検索の足回り、生成＝回答。2つを分けて運用するのがRAGの基本形です（→ ローカルRAGの構成）。

運用の勘所

埋め込みモデルは固定する：途中で変えると過去のベクトルと互換が崩れ、全再計算が必要。
多言語・日本語を扱うなら対応言語のモデルを選ぶ（要最新確認）。
次元数とモデルは後段のベクトルDB設計に直結 → ローカルベクトルDB

なぜそうするか

意味検索を外部APIに投げると、検索対象の文書まで外に出ます。埋め込みをローカルに置けば、文書もクエリも一切外に出さずにRAGが成立する。プライバシー要件の強い用途（社内文書・個人ノート）で、埋め込みのローカル化は生成のローカル化と同じくらい重要です。

⚠️ よくある落とし穴

生成モデルで埋め込みを代用：用途が違う。埋め込み専用モデルを使う。
モデルを途中で変更：ベクトル空間が変わり過去データと不整合。固定するか全再計算。
次元・正規化を無視：類似度計算の前提（正規化の有無）を揃える。
日本語非対応モデルで日本語：精度が出ない。対応を要最新確認。

対応lab

local-llm-study/labs/rag_local.py … 埋め込み生成とコサイン類似度の計算例（RAG最小実装）。