Retrieval-Augmented Generation (RAG) とは?

Retrieval-Augmented Generation (RAG) is an AI architecture that combines a large language model with an external knowledge retrieval step, so the model can look up relevant documents before producing an answer. This grounding in retrieved, up-to-date sources helps reduce hallucinations and lets the system answer questions about information it was not explicitly trained on.

Retrieval-Augmented Generation(RAG)は、言語モデルが質問に答える前に外部ドキュメントを参照できるようにするAIシステム構築の手法です。学習時に得た知識のみに依存するのではなく、RAGパイプラインはまずユーザーのクエリに関連する箇所を知識ベースから検索し、それらの箇所をコンテキストとしてモデルに渡します。これにより、モデルの内部の重みだけに依存するのではなく、特定の引用可能な情報源に基づく生成された回答が得られます。

Retrieval-Augmented Generationの仕組み

一般的なRAGシステムは、リトリーバー(検索器)とジェネレーター(生成器)の2つの主要コンポーネントで構成されます。リトリーバーは通常、ドキュメント群から構築されたベクトル検索インデックスです。各ドキュメントがインデックスに追加される際に、埋め込みモデルがそのチャンクを数値ベクトルに変換します。同じモデルがユーザーのクエリも埋め込み類似度検索(一般的にはコサイン類似度または内積距離を用いた近傍探索)が行われ、クエリに最も近いベクトルを持つチャンクが返されます。上位にランクされたチャンクは、「提供されたコンテキストのみを使用して回答する」といった指示とともに、大規模言語モデルに送られるプロンプトに挿入されます。

たとえば、ユーザーが社内アシスタントに「当社の育児休業ポリシーはどうなっていますか?」と尋ねた場合、リトリーバーは従業員ハンドブックの関連セクションを見つけ出し、言語モデルはその箇所を引用して正確な回答を作成します。Facebook AI ResearchのLewisらによる2020年の論文で紹介されたこのパターンは、知識(インデックスに保存)と推論(モデルが実行)を分離するため、ソース資料が変更されてもスケーラブルに機能します。

なぜ重要なのか

RAGはスタンドアロンの言語モデルに存在する3つの慢性的な問題に対処します。第一に、モデルが即興で生成するのではなく取得したテキストに固定されるため、ハルシネーションを削減できます。第二に、インデックスを更新するだけで、モデルの学習カットオフ以降に存在しなかった情報や変更された情報をシステムに反映できます。第三に、モデルの回答がより検証しやすくなります。開発者やユーザーは取得したチャンクを確認し、引用し、あらゆる主張をソースドキュメントまでさかのぼることができます。

これらの特性により、RAGはエンタープライズ向け質疑応答、カスタマーサポートのコパイロット、法的・コンプライアンス検索、そして基盤モデルを再トレーニングすることなく非公開または独自データ上で動作する必要があるAIアシスタントのデファクトスタンダードとなっています。

主要な種類とパターン

  • ナイーブ(または「Retrieve-and-Read」)RAG:単一の検索ステップで、上位k件のチャンクをジェネレーターのプロンプトに直接フィードします。
  • Advanced RAG:生成前にクエリ書き換え、再ランキング、チャンクレベルのフィルタリングを追加し、精度を向上させます。
  • Modular RAG:Web検索、SQLルックアップ、API呼び出しなどの交換可能なコンポーネントでパイプラインを構成し、検索と生成の間をループさせることもあります。
  • Graph RAG:コーパスからナレッジグラフを構築し、関連エンティティのサブグラフを取得することで、つながりのあるデータに対してより文脈に即した回答を生成できます。
  • Agentic RAG:言語モデルが、いつ・何を検索するかを複数のツールを横断して判断し、最終的な回答を生成します。

知識の保存を推論エンジンから分離することで、RAGは正確かつ最新かつ監査可能なことが求められる本番運用AIアプリケーションの基本的な構成要素となっています。元の研究はLewisらによる「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」(2020年)で説明されており、現在のベストプラクティスはLlamaIndexLangChainなどのフレームワークでドキュメント化されています。

Frequently Asked Questions

How is RAG different from fine-tuning a language model?
Fine-tuning bakes new knowledge and behavior into a model's weights by continuing training on example data, which is expensive and must be repeated whenever the source material changes. RAG leaves the model unchanged and instead supplies relevant documents at inference time, so knowledge can be updated by simply editing the search index. The two approaches are complementary and are often combined in production systems.
What is a vector database and why does RAG need one?
A vector database stores documents (or chunks of them) as numerical embeddings produced by an embedding model. RAG needs it because retrieving by meaning, rather than exact keywords, requires comparing the query's embedding to every candidate's embedding and returning the nearest matches. Specialized vector stores such as FAISS, Pinecone, Weaviate, and pgvector make this nearest-neighbor search fast at scale.
Does RAG eliminate hallucinations?
No system fully eliminates hallucinations, but RAG significantly reduces them by forcing the model to answer from supplied context. Errors can still occur if the retriever returns irrelevant or low-quality chunks, if the source documents themselves are wrong, or if the model misinterprets the retrieved text. Best-practice pipelines add re-ranking, citation checks, and guardrails to catch these cases.
What kind of data can a RAG system search over?
Almost any text-based corpus: PDFs, wikis, help-center articles, code repositories, product catalogs, legal contracts, internal chat logs, and web pages. After appropriate parsing and chunking, the content is embedded and indexed, and the same RAG pipeline can serve many domains. Multimodal RAG extensions can also retrieve images, tables, and audio.