RAGとは？「自社の知識で答えさせる」ための現実的アプローチ
RAG（Retrieval-Augmented Generation）は、生成AI（LLM）に社内ドキュメントやナレッジを検索させ、その結果を材料に回答を生成させる仕組みです。モデル自体を学習し直す（ファインチューニング）よりも、速く・安く・安全に「自社向けAI」を作りやすいのが魅力です。
ざっくり言うと、RAGは次の2段構えです。
- Retrieval（検索）：質問に関連する社内データ断片を探す
- Generation（生成）：見つけた断片を根拠としてLLMが回答を作る
ポイントは、LLMが“知ったかぶり”をしやすい領域（規程、製品仕様、契約、FAQ、手順書など）ほどRAGが効くこと。逆に、社内データに存在しない情報まで正確に当てる用途には向きません。
まず押さえたい全体像：RAGの標準アーキテクチャ
典型的なRAGは次の流れです。
- データ収集（PDF / Confluence / Notion / SharePoint / Google Drive / DB など）
- 前処理（OCR、不要部分除去、正規化、メタデータ付与）
- チャンク化（文章を適切な長さに分割）
- 埋め込み（Embedding）（チャンクをベクトル化）
- ベクトルDBに格納（検索できる形にする）
- 検索（類似検索＋フィルタ、必要なら再ランキング）
- プロンプト合成（検索結果を根拠としてLLMへ投入）
- 回答生成（引用・根拠・注意書きなどを整形）
- 評価・監視（精度、幻覚、漏えい、コスト、レイテンシ）
失敗しないコツ①：ユースケースを「質問の型」で決める
RAGは万能ではないので、最初に質問の型を定義すると成功率が上がります。おすすめは以下のように3分類することです。
- 検索型：該当箇所を探して要約（例：経費精算のルールは？）
- 手順型：社内手順をステップ化（例：障害時の一次対応は？）
- 判断支援型：規程や仕様を根拠に条件分岐（例：このケースは返品対象？）
最初は「検索型」から始めるのが鉄板です。評価もしやすく、社内の信頼も取りやすいです。
失敗しないコツ②：データ整備は“AIのため”にやりすぎない
「データを完璧にクレンジングしてから…」とやりがちですが、RAGでは価値の高いデータから小さく始めるほうが進みます。おすすめの優先順位は次の通りです。
- FAQ・問い合わせ履歴（質問文がそのまま検索キーになる）
- 規程・マニュアル（根拠が明確で評価しやすい）
- 製品仕様・リリースノート（更新頻度が高いほどRAGが効く）
- 議事録・チャットログ（ノイズも多いので後回し推奨）
PDFが多い場合はOCR品質がボトルネックになります。スキャンPDFが混じるなら、まずは文字が取れる状態になっているかを確認しましょう。
