RAGとは何か

RAG（Retrieval-Augmented Generation）は、LLMの回答生成に外部の知識ベースを組み合わせる手法だ。LLMは学習データのカットオフ以降の情報を知らず、社内文書や独自データにはアクセスできない。RAGはこの限界を克服し、「根拠のある回答」を生成できるようにする。

基本的な流れは「検索→文脈付与→生成」だ。ユーザーの質問に関連するドキュメントをベクトルデータベースから検索し、それをコンテキストとしてLLMに渡し、根拠に基づいた回答を生成させる。

しかし一口にRAGといっても、シンプルな実装から精度を追求した複雑な実装まで、いくつかの段階がある。

Naive RAG——基本の実装

構成

Naive RAGは最もシンプルなRAGの実装形態だ。構成要素は3つ。ドキュメントをチャンク分割してエンベディングし、ベクトルDBに保存する「インデックス化」、クエリをエンベディングして近いチャンクを取り出す「検索」、取り出したチャンクをコンテキストとしてLLMに渡して回答を生成する「生成」だ。

弱点

シンプルゆえの限界もある。主な問題点は3つある。

  1. 検索精度が低い: チャンクの粒度が合っていないと、関連情報を取り逃がす
  2. ランキングの問題: ベクトル類似度が高くても、実際に回答に有益でないチャンクが上位に来ることがある
  3. 冗長な情報: 同じような内容のチャンクが複数ヒットし、コンテキストを無駄に消費する

Modular RAG——部品を入れ替えられる設計

Modular RAGはNaive RAGの各ステップを独立したモジュールとして設計し、差し替え・組み合わせを容易にした考え方だ。検索エンジンをベクトル検索からキーワード検索やハイブリッド検索に変えたり、チャンキング戦略を変えたりといったA/Bテストがしやすくなる。

LangChainなどのフレームワークはこのModular RAGの思想で設計されており、各モジュールを差し替えながら最適な組み合わせを探れる。

Advanced RAG——精度を高めるチューニング手法

Pre-Retrieval（検索前の改善）

クエリ変換

ユーザーの質問をそのままベクトル検索すると、うまく関連文書を引っ張れないことがある。クエリ変換はこの問題に対処する。

「Multi-Query」は、一つの質問から複数の異なる表現のクエリを生成し、それぞれで検索して結果を統合する方法だ。ユーザーの意図を多角的にカバーできる。

「HyDE（Hypothetical Document Embedding）」は、質問に対してLLMが「もしこんな文書があれば答えになる」という仮想的な答えを生成し、その答えのエンベディングで検索する手法だ。実際の答えに近い文書が検索されやすくなる。

チャンキング戦略の最適化

ドキュメントをどのサイズで分割するかは、検索精度に大きく影響する。チャンクが大きすぎると不要な情報が多く含まれ、小さすぎると文脈が失われる。

「Semantic Chunking」はテキストの意味的なまとまりを考慮して分割する。段落や節の区切りを尊重し、意味が途切れないように分割することで、チャンク一つひとつの情報密度が上がる。

Retrieval（検索の改善）

ハイブリッド検索

ベクトル検索（セマンティック検索）とキーワード検索（BM25など）を組み合わせる手法だ。セマンティック検索は意味的な類似性に強いが、固有名詞や専門用語の完全一致に弱い。キーワード検索はその逆だ。両者を組み合わせることで、補完的な効果が得られる。

Post-Retrieval（検索後の改善）

Reranking（再ランキング）

検索で取り出した上位20チャンクを、専用のRerankerモデルで再評価して上位5件に絞る手法だ。CohereのReranker APIやCross-Encoderモデルを使うと、ベクトル類似度だけでは測れない関連度を考慮した再ランキングが可能になる。検索精度の改善効果が大きく、多くのRAGシステムで採用されている。

Context Compression

取り出したチャンクから、質問に関係する部分だけを抽出して圧縮する手法だ。100トークンのチャンクから20トークンの要点だけを取り出すことで、コンテキストウィンドウを効率的に使える。LLMへの入力が減るため、コストと速度も改善する。

生成の品質を上げる工夫

回答の根拠を明示させる

「以下のドキュメントだけを根拠に答えてください。ドキュメントに答えがない場合は『わかりません』と答えてください」というプロンプト設計は、ハルシネーション（事実と異なる情報の生成）を減らすうえで有効だ。参照したチャンクの番号を引用させることで、回答の根拠をトレースできるシステムにもなる。

Self-RAG

Self-RAGはLLM自身が「検索が必要かどうか」「取り出した情報が十分かどうか」を判断しながら、必要に応じて複数回の検索と生成を繰り返す高度な手法だ。複雑な質問への対応精度が上がるが、実装の複雑さとレイテンシが増す。

実装の進め方

精度向上のための選択肢は多いが、一度にすべてを実装しようとすると複雑さが制御不能になる。まずNaive RAGで動くシステムを作り、精度を評価したうえで「どこがボトルネックか」を特定し、そこに絞ってAdvanced RAGの手法を適用するのが現実的なアプローチだ。

評価には、RAGASなどの評価フレームワークを使うと、忠実性・回答の関連性・文脈の適合度などを定量的に測れる。

まとめ

RAGはNaive RAGから始まり、Modular・Advancedと段階的に精度を高められる設計だ。検索前のクエリ変換やチャンキング最適化、検索後のRerankerや文脈圧縮といった手法を組み合わせることで、精度を大幅に改善できる。まず動くNaive RAGを構築し、精度の評価と改善サイクルを回しながら段階的にAdvanced RAGへ進化させるアプローチが、実務では最も効果的だ。