RAG = 「AIに答えさせる前に、社内資料を検索して手渡してから答えさせる」仕組み。Retrieval（検索）+ Augmented（拡張）+ Generation（生成）の頭文字。
- LLM単体は「学習した時点の一般知識」しか持たない。あなたの会社の資料は知らない
- RAG は質問のたびに 関連する社内文書を探し出し、それをLLMに読ませてから回答させる
- つまり「オープンブック試験」。カンニングOKにすることで、正確で最新の答えを出させる
なぜRAGが必要か（LLM単体では解決できない問題）
| LLM単体の問題 | RAGでどう解決するか | |---|---| | 社内の非公開情報を知らない | 社内文書を検索して渡す | | 知らないことも自信満々に嘘をつく（ハルシネーション） | 実在する資料に基づかせる（グラウンディング） | | 学習後の新しい情報を知らない | 最新の資料を都度検索する | | 全資料をプロンプトに貼ると高コスト・上限超過 | 必要な断片だけ渡すので安く速い |
別解として「ファインチューニング（追加学習）」もあるが、資料が変わるたび再学習が必要でコスト高。
多くの業務では RAG の方が安く・速く・更新が楽。
RAGの仕組み（埋め込み → 検索 → 生成）
RAGは大きく5段階のパイプラインで動く。
` ① 取り込み(Ingestion) 社内文書を集める ② 埋め込み(Embedding) 文書を「意味のベクトル（数値の列）」に変換 ③ 検索(Retrieval) 質問も数値化し、意味が近い文書を探す ④ 拡張(Augmentation) 見つけた文書を質問にくっつける ⑤ 生成(Generation) LLMがその文書を読んで回答する `
事前準備（①②）は一度だけ。ユーザーが質問するたびに走るのは③④⑤。
3つの基礎部品
チャンキング（Chunking）
長い文書を「検索しやすい小さな塊」に分ける作業。
- 1つのマニュアル全体では大きすぎて的外れな検索になる → 段落・章単位に割る
- 小さすぎると文脈が切れ、大きすぎるとノイズが増える。塊の大きさが精度を左右する
埋め込みモデル（Embedding Model）
文章を「意味を表す数値のベクトル」に変換するモデル。
- 意味が近い文章はベクトルも近くなる → 「猫」と「ネコ」が近い数値になる
- OpenAI の
text-embedding-3-largeは最大 3,072 次元のベクトルを作れる - Cohere・BGE 等のオープンモデルもあり、精度は MTEB というランキングで比較される
ベクトルDB（Vector Database）
数値化した文書を大量に保管し、「意味が近いもの」を高速に探し出す専用データベース。
- コサイン類似度などの距離計算で「質問に一番近い文書」を返す
- 003 では PostgreSQL の拡張 pgvector（Supabase）を使う
Dify を使ったRAG実装との接続
上の①〜⑤を自前でコードする代わりに、Dify がRAGパイプラインを丸ごと提供する。
- 文書をアップロード → Dify が自動でチャンキング・埋め込み・ベクトルDB保存まで実行
- ノーコードで「知識ベース（ナレッジ）」を作り、チャットBotに接続できる
- 003 の分身AIは Dify のRAG機能 + Claude（生成担当）+ Supabase/pgvector（保管） の組み合わせで動く
ビジネス活用の観点（003で使う場面）
- 分身AIの本体 — 社長の判断データ・業務ナレッジをRAGで検索させ、社長の考え方で回答する
- 顧客サポートBot — 顧客のマニュアル・FAQを取り込み、問い合わせに一次回答
- セキュリティ前提 — 顧客ごとにナレッジを物理分離（1顧客=1環境）。RAGの検索対象が顧客間で混ざらない設計が絶対条件（003セキュリティ方針）