ローカルベクトルDB｜ローカルLLM

← ローカルLLM 一覧

🎓 レベル：標準　|　重要度：B（推奨） 📎 前提：ローカルRAGの構成　|　原理：検索拡張生成（機械学習）

要点（結論先出し）

ベクトルDB＝埋め込みベクトルを保存し、クエリに**近いものを高速に探す（近傍検索）**ための保管庫。
ローカルなら組み込み型が手軽：Chroma（プロセス内・SQLite永続化）、FAISS（高速ライブラリ）など（要最新確認）。
規模が小さいうちはnumpyで総当たりでも動く。数万〜十万件規模になったら近似最近傍探索（ANN）を持つDBへ。

概念 ── 「近いベクトルを速く探す」

RAGの検索段は「質問ベクトルに最も近いチャンクベクトルを取る」処理。件数が少なければ全ベクトルとの距離を総当たり（厳密）で十分。増えると遅くなるので、**ANN（近似最近傍）**で速度を稼ぎます。

選択肢（要最新確認）：

Chroma：プロセス内で動き、SQLiteにディスク永続化。サーバ不要。初学・中規模に好適。
FAISS：検索が高速なライブラリ。インデックス種別を選べる。性能重視。
サーバ型（Milvus等）：大規模・本番向け。ローカル単機ではオーバースペックになりがち。

仕組み ── 保存と検索

flowchart LR
  EMB["チャンクのベクトル＋メタデータ"] --> STORE["ベクトルDBに保存（永続化）"]
  Q["質問ベクトル"] --> SEARCH["近傍検索（厳密 or ANN）"]
  STORE --> SEARCH
  SEARCH --> TOPK["上位k件のチャンクを返す"]

メタデータ（出典・章）も一緒に保存し、検索結果に根拠を付けられるようにします。

選択の目安（要最新確認）

規模・用途	目安
数百〜数千件・学習用	numpy総当たり or Chroma
数千〜十万件	Chroma / FAISS（ANN）
大規模・多人数・本番	サーバ型（ローカル特化の範囲外）

運用の勘所

埋め込みモデルを固定：DBに入れたベクトルはそのモデル前提。変えたら再構築（→ 埋め込みモデルのローカル運用）。
永続化先を決める：再起動でインデックスが消えないように（Chromaはディスク永続）。
メタデータ設計：出典・更新日・章を持たせると、回答の検証と更新が楽。
まずは小さく組み込み型で。必要になってからスケールする。

なぜそうするか

ローカルRAGの肝は「検索対象の文書も手元に置く」こと。組み込み型ベクトルDBはサーバを立てずに永続検索を実現し、完全オフラインのアプリと相性が良い。最初から大規模DBを入れるのは過剰で、規模が要求してから移行するのが堅実です。

⚠️ よくある落とし穴

最初から重いサーバ型を導入：単機・少件数ではオーバースペック。組み込み型で十分。
永続化を忘れる：メモリ上だけだと再起動で消える。ディスク保存を確認。
次元・正規化の不一致：埋め込みの次元/正規化方針をDB側と揃える。
メタデータ無しで運用：根拠提示・更新ができず後で苦労する。

対応lab

local-llm-study/labs/rag_local.py … numpy総当たり検索の最小例（後でChroma等へ置換可能）。