一言でいうと

RAG（Retrieval-Augmented Generation：検索拡張生成）は、LLMが回答を生成する前に、外部の文書やデータベースから関連情報を検索し、その内容を根拠として回答させる構成です。

図書館に例えるなら、司書（検索システム）が質問に関係する本を探して机に積み、専門家（LLM）がその本を読みながら答える仕組みです。モデルの記憶だけに頼らないため、社内文書や最新情報にも対応できます。

なぜ必要なのか

LLMには、業務利用で特に問題になる弱点が2つあります。

1つ目は、学習時点の知識しか持っていないことです。昨日更新された社内規程や今月の価格表は、モデルの中に存在しません。

2つ目は、知らないことでも、もっともらしく答えてしまうことです。これはハルシネーション（幻覚）と呼ばれ、根拠のない回答が事実のような文体で出力されます。

RAGはこの2つを同時に緩和します。回答の根拠を「モデルの記憶」から「検索で取得した実際の文書」へ移すことで、社内知識や最新情報に基づく回答が可能になります。根拠となった文書を出典として提示できる点も、業務利用では重要です。

仕組み

RAGの処理は、「事前準備」と「回答時」の2段階に分かれます。

事前準備：インデックス構築

まず社内文書を検索可能な形に変換します。文書を適切な長さの断片（チャンク）に分割し、それぞれをEmbedding（文章の意味を数値ベクトルに変換する技術）によってベクトル化し、ベクトルデータベースに格納します。

回答時

ユーザーの質問を受けると、次の流れで処理します。

  1. ユーザーの質問をベクトル化する
  2. ベクトルデータベースから、質問と意味的に近い文書チャンクを検索する
  3. 取得したチャンクを質問と一緒にLLMへ渡す
  4. LLMが、渡された文書を根拠に回答を生成する

重要なのは、RAGが単独のAIモデルではなく、検索システムとLLMを組み合わせた構成（アーキテクチャ）だという点です。品質はLLMの性能だけでなく、文書の分割方法、検索精度、文書自体の整備状況にも左右されます。

使うべきケース

RAGが向いているのは、「知識」の問題を解決したい場合です。

  • 社内規程、マニュアル、議事録、過去の提案書などに答えるAIを作りたい
  • 価格、在庫、規程などの情報が頻繁に更新される
  • 回答に出典や根拠の提示が求められる
  • ファインチューニングするほどのデータや予算はないが、自社情報を扱わせたい

特に「情報の更新に強い」点は実務上の大きな利点です。文書を差し替えれば回答も変わるため、モデルを再学習する必要がありません。

使わない方がいいケース・失敗しやすい理由

RAGは「社内文書を入れるだけ」で完成するものではありません。期待した精度が出ない原因の多くは、RAGの手前にあります。

  • 文書が整備されていない：同じ規程の新旧版が混在している、口頭ルールが文書化されていない、表や図に情報が埋まっている状態では、正しい文書を検索できない
  • 解きたい課題が振る舞いの問題：回答の文体・フォーマット・タスク精度を変えたいなら、SFTやLoRAの領域であり、RAGだけでは解決しにくい
  • 横断的な集計・推論が必要：「過去3年の議事録から傾向を分析して」のような、多数の文書をまたぐ集計は、RAGの基本構成だけでは苦手
  • 評価の仕組みがない：想定質問と期待回答のセットがなければ、精度を測定・改善できない

RAG導入の実態は、AI構築プロジェクトである以前に、ナレッジ（文書）整備プロジェクトです。ここを見誤ると、検証段階から先へ進めないことがあります。

RAG・SFT・LoRAの違い

3つの用語の関係を整理します。

手法 位置づけ 解決する課題
RAG 検索とLLMを組み合わせた構成 知識（社内情報・最新情報）の問題
SFT 教師データで振る舞いを学習させる工程 振る舞い（型・精度・文体）の問題
LoRA SFTを低コストで実行する学習テクニック SFTと同じ目的を少ない計算資源で実現

RAGとファインチューニング（SFT・LoRA）は競合する選択肢ではなく、解決する課題が異なります。「知識はRAG、振る舞いはファインチューニング」と役割分担し、併用する構成も一般的です。

中小企業での活用例

  • 社内ヘルプデスク：就業規則・経費規程・システムマニュアルへの問い合わせにAIが一次回答し、総務や情シスの負荷を削減する
  • カスタマーサポート：製品マニュアルやFAQを根拠に、出典付きの回答案を生成してオペレーターを支援する
  • 営業：過去の提案書や事例集から類似案件を検索し、提案書ドラフトの材料を集める
  • 製造・建設：技術基準書や過去の不具合報告を検索し、設計・検査時の参照を高速化する

いずれも、答えの根拠となる文書が社内に存在することが前提です。文書化されていない暗黙知には、RAGは無力です。

参考文献

  • Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv:2005.11401
  • Gao, Y. et al. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997

当社の見解

RAGは、LLMに外部知識を接続し、社内文書や最新情報に基づく回答を可能にする標準的な構成です。モデルを再学習せずに知識を更新でき、出典提示によって回答を検証しやすくなるため、企業のLLM活用では最初に検討しやすい選択肢です。

ただし、文書を放り込めば動くものではありません。対象業務と想定質問を絞り、根拠となる文書を整備し、評価用の質問・回答セットを用意したうえで、小さく構築・検証することを推奨します。知識の問題はRAG、振る舞いの問題はSFTやLoRAという切り分けを押さえることが、技術選定の失敗を防ぐ第一歩です。