大規模言語モデル（LLM）は強力ですが、社内ドキュメントや最新情報を知りません。RAG（Retrieval-Augmented Generation、検索拡張生成）は、質問に答える前に関連ドキュメントを検索してLLMに渡す仕組みで、これを補います。

RAGは「Embedding（テキストをベクトル化）→ Index（ベクトルDBに保存）→ Retrieval（質問に近い文書を検索）→ Generation（LLMに渡して回答生成）」の4段階で動きます。「LLMにSQL を書かせるとデタラメ」「社内データを学習させる必要があるのでは」といった誤解の多くは、RAGの存在を知れば解けます。

生成AIは魔法ではなく、向く業務と向かない業務がはっきり分かれます。ざっくり言うと「正解が一つに決まらない」「人間がレビューしてから使う」業務に向き、「正解が一意に決まる」「責任を伴う即時自動判断」に向きません。

最初の社内ユースケースは、業務インパクトの大小よりも「成功確率の高さ」で選びます。問い合わせメール下書き、議事録の要約、社内FAQへの自然言語検索などが定番です。「全社で使えるすごいもの」を目指すと頓挫します。

RAGが失敗する最大の理由は「読ませる元データが汚い」ことです。PDFのレイアウト崩れ、社内Wikiの古い情報、PowerPointの画像内テキスト、Excelの結合セル。LLMは元データ以上の答えを出せません。「Garbage in, garbage out」が容赦なく効きます。

チャンキング戦略（文書をどう分割するか）も品質を左右します。固定長で切るのが一番楽ですが、見出し単位で意味のまとまりを保つ方が検索品質が上がります。「データの形をLLM向けに整える」のが、RAG実装の半分以上の工数です。

ベクトルDBは「意味の近さで検索できるデータベース」です。テキストをEmbeddingモデル（OpenAI text-embedding-3、Cohereなど）で数値配列に変換し、その配列の類似度（cosine、Euclideanなど）で検索します。キーワード一致では取れない「言い換え」「同義語」を拾えるのが本質です。

「ベクトルDBが要るのか、PostgreSQLで足りるのか」は規模次第です。中規模まではpgvector拡張で十分、数千万ベクトルを超えるなら専用ベクトルDB（Pinecone、Weaviate等）を検討します。

3つの代表的選択肢は性格が違います。Pineconeは完全マネージドSaaSで「APIを呼ぶだけ」、運用負担ゼロですが商用ロックインがあります。WeaviateはOSSで自社運用も可能、機能カスタマイズの自由度が高い反面、Kubernetes運用力が要ります。pgvectorは既存PostgreSQLに足せる拡張で、中規模までならこれで十分です。

選定の起点は「規模」と「既存インフラ」です。PoCならpgvector、本格スケールでマネージドが欲しいならPinecone、OSS志向でカスタムしたいならWeaviate、と覚えれば外しません。

RAGを本番投入する前に、組織として最低限決めておくべきことがあります。情報漏洩リスク（プロンプトに社外秘が混入しないか）、ハルシネーション対応（誤情報をどう識別するか）、責任分界（AIの回答で事故が起きたら誰の責任か）の3点が中心です。

「とりあえずChatGPT」で始めてしまった組織が後から困るのは、データの持ち出し許可とログ保管の設計です。OpenAI APIに送られたデータが学習に使われるか、ログを誰が見られるか、を最初に決めておくと事故を未然に防げます。