← ローカルLLM 一覧

🎓 レベル：標準　|　重要度：A（必須） 📎 前提：埋め込みモデルのローカル運用　|　原理：検索拡張生成（機械学習）

要点（結論先出し）

• RAG（検索拡張生成）＝質問に関連する文書を検索して文脈に差し込み、それを根拠に生成させる仕組み。微調整より新しい事実の追加に向く。
• ローカルRAGは全段（埋め込み・検索・生成）を手元で回せるので、文書もクエリも外に出ない。
• パイプラインは6段：取り込み → 分割（チャンク）→ 埋め込み → ベクトルDB保存 → 検索 → 文脈注入して生成。

概念 ── なぜRAGか

LLMの知識は学習時点で固定。最新情報や手元の私的文書は知りません。微調整で覚えさせるのは重く、更新も大変。RAGは実行時に関連文書を渡すだけなので、知識の追加・更新が軽い。原理は機械学習へ → 検索拡張生成。

仕組み ── 6段のパイプライン

flowchart LR
  DOC["文書（PDF・md等）"] --> CH["チャンク分割"]
  CH --> EMB["埋め込みモデルでベクトル化"]
  EMB --> DB["ベクトルDBに保存"]
  Q["ユーザーの質問"] --> QE["質問もベクトル化"]
  QE --> SR["近いチャンクを検索"]
  DB --> SR
  SR --> CTX["文脈として差し込む"]
  CTX --> GEN["生成モデルが回答"]

**インデックス作成（取り込み〜保存）と問い合わせ（質問〜生成）**の2フェーズに分かれます。

最小実装の流れ（対応lab）

1. 文書をチャンク（数百トークン程度＋重なり）に切る
2. 各チャンクを埋め込み（→ 埋め込みモデルのローカル運用）
3. ベクトルをDBに保存（→ ローカルベクトルDB）
4. 質問を埋め込み、コサイン類似度で近いチャンクを取得
5. 取得チャンクをプロンプトに入れて生成（→ OpenAI互換API）

コサイン類似度の計算例は対応lab rag_local.py で実行確認できます（cp932安全）。

チャンク設計の勘所

• 大きすぎ：1チャンクに情報が薄まり検索精度が落ち、文脈も食う。
• 小さすぎ：文脈が切れて意味が壊れる。
• **重なり（overlap）**を少し持たせると境界の文意を保てる。
• メタデータ（出典・章）を付けて、回答に根拠を示せるようにする。

なぜそうするか

RAGは知識の更新コストを実行時に移すことで、再学習なしに「最新・私的なデータで答える」を実現します。さらにローカルで完結させれば、検索対象の文書すら外に出ない。微調整＝様式、RAG＝知識と役割分担すると設計が綺麗になります（→ 微調整の選択肢（フル・LoRA・QLoRA））。

⚠️ よくある落とし穴

• チャンク設計を雑に：検索品質はチャンクで大きく変わる。サイズと重なりを調整。
• 埋め込みモデルを途中変更：ベクトル空間が変わり再インデックスが必要 → 埋め込みモデルのローカル運用
• 検索結果を盛りすぎ：大量に詰めるとコンテキスト超過・ノイズ増。上位数件に絞る。
• 根拠を示さない：出典メタデータを持たせ、回答の検証性を確保。

対応lab

• local-llm-study/labs/rag_local.py … チャンク・埋め込み呼び出し・コサイン類似度検索の最小実装。

関連

• ベクトルDB → ローカルベクトルDB
• アプリ化 → オフライン・プライベートなLLMアプリ
• 埋め込み運用 → 埋め込みモデルのローカル運用