Dify入門3：RAGをわかりやすく解説 - クラウド総合支援 Cloud Assist

近年、ChatGPTなどの大規模言語モデル（LLM）が飛躍的に進化したことで、「文章生成」や「高度な質問応答」がこれまで以上に身近になりました。しかし、LLMはあくまでも学習時点までの公開データや一般知識がベース。クローズドな社内データなど最新・独自の情報を活かした回答が必要な場合、LLMだけではどうしても限界が生じてしまいます。

そこで注目を集めているのがRAG（Retrieval-Augmented Generation）です。本記事では、RAGの仕組みからファインチューニングとの違いまで、できる限りやさしく解説します。

1. RAG（Retrieval-Augmented Generation）とは？

RAGは「Retrieval + Augmented Generation」の略で、直訳すると「検索拡張生成」という意味です。
その流れを超シンプルに言うと、次の手順になります。

ユーザーの質問を受け取る。
データベースから関連情報を検索する（情報をベクトル化しておく場合が多い）。
見つかった関連情報を“コンテキスト”としてLLMに渡す。
LLMが回答を生成し、ユーザーに返す。

つまり、普段は（公開情報しか知らない）LLMに対して、外部の必要な情報を「一時的に読み込ませる」イメージです。これにより、通常のLLM単体よりも正確かつ自社専用の回答を生成できるようになります。

2. なぜRAGが必要なのか？

LLMは大規模なテキストデータを学習しているため、「一般知識」に関する回答は優れています。しかし、以下のような情報は通常のLLMでは回答が困難です。

自社独自の売上や顧客データ
最新の業界レポート
社内のマニュアルやドキュメント

例えば、社内向けチャットボットに「2024年の第1事業部の売上はどれくらい？」と質問しても、一般公開されていないデータであればLLMは回答できません。

一方、RAGであれば、

社内データベースを検索して必要な売上データを取得し、
そのデータをLLMにコンテキストとして渡して質問に答えさせる
ことができます。
これにより、常に最新かつ正確な情報を踏まえた回答が期待できるのです。

3. RAGの仕組みをもう少し詳しく

ここでは、具体的なチャットボットの例を使って見てみましょう。将棋専用のRAGを組んだ場合で考えてみます。

ユーザーが質問する
- 例：将棋で「金将」の動きを教えて
検索エンジン（リトリーバ）によるデータベース検索
- 質問に関連するナレッジベースを探し出す。
- 質問・ドキュメント双方をベクトル化して、類似度が高いデータを複数件取り出す。
- 例：
  - 金将は、縦・横・前斜めの合計6方向に1マス進める。
  - 金将は敵陣に入っても「成る（駒が裏返る）」ことはできない。
  - 金将は玉将や王将の次に価値の高い駒とされる。
    など、関連度が高そうな情報を引っ張ってくる。
抽出した情報をLLMに投げる
- プロンプト（入力）として、
  1. ユーザーの質問
  2. データベースから取得した関連情報
- をまとめてLLMに渡す。
LLMが回答を生成
- RAGで渡された社内データをもとに、ユーザーの質問に合った回答を出す。
- 例：「金将は、前後左右と前斜めの6方向に1マス動ける駒です（後ろ斜めには進めません）。敵陣に入っても「成る」ことはなく、最初から最後まで動きは変わりません。玉将（王将）の次に価値が高く、守りや終盤戦で重要な駒です。」

このように、あらかじめ社内データやドキュメントを整理・ベクトル化しておくことがRAG導入の要となります。

4. RAGとファインチューニングの違い

ファインチューニングとは？

すでに学習済みのLLMに対し、自前のデータセットを使って再学習させるアプローチ。
新しいタスク向けにモデルのパラメータ自体を調整するため、それなりの学習コストや専門知識が必要になる。
ベースモデルを変えるごとに、再度ファインチューニングが必要になる点も手間。

RAGの特徴

基本的にモデル自体を再学習する必要がない。
必要に応じてデータベース検索で外部データを引っ張ってきて、それをLLMにコンテキストとして渡すだけ。
常に最新のモデルや最新のデータベースを組み合わせられる。
Microsoftの論文でも、ファインチューニングよりRAGの方が精度が高いケースが示唆されている。

どちらを使うべきか？

機密情報や独自データに基づく高精度な回答を、常に最新化しながら求めたい場合はRAGがおすすめ。
一方で、特定のタスクに特化したモデルを作りたい場合やオフラインでの推論環境が求められる場合などは、ファインチューニングが適するケースもある。

5. RAG導入のポイント

データの整理・構造化
- 必要なデータをテキスト化しておき、ベクトル化に対応できる形で管理する。
- 文書が乱雑な状態だと正確な検索が難しい。
検索ロジック（ベクトル検索）の設定
- 質問と文書を同じ埋め込み空間でベクトル化し、類似度を高い順で検索する仕組みが一般的。
- ベクトル検索エンジン（例：Faiss、Milvus、Elasticsearch＋プラグインなど）の利用を検討。
プロンプト設計
- LLMへの入力（プロンプト）をどのように構築するかで回答品質が左右される。
- 「使用してよいデータ」「回答フォーマット」「口調・文体」など、細かい指定が必要な場合はプロンプトに明記するとよい。
セキュリティ・権限管理
- 社内の機密情報を含むことも多いので、検索結果として取得できる情報や閲覧権限を厳密に制御する。

6. まとめ

RAG（Retrieval-Augmented Generation）は、外部データベースからの検索結果をLLMに渡すことで、クローズドな独自情報を使った回答を生成できる手法です。ファインチューニングと比べてモデルの再学習が不要なので、最新のモデルと組み合わせて使いやすいのが特徴です。ただし、実運用ではデータ整理・検索ロジック・プロンプト設計など事前準備が大切となります。

RAGを使うことで、一般知識ベースのAIでは難しかった「自社や自組織に特化したチャットボット・検索サービス」が実現可能になります。
一方で、ファインチューニングが活きるシーンもあるため、状況に応じてどちらを採用すべきかを検討してみてください。