RAG(Retrieval-Augmented Generation:検索拡張生成)は、大規模言語モデル(LLM)の生成能力と外部知識ベースの検索を組み合わせたアーキテクチャです。LLM単体では学習データに含まれない最新情報や社内固有の知識を扱えませんが、RAGを導入することで、関連するドキュメントを検索しコンテキストとして与えた上でLLMに回答を生成させることが可能になります。
筆者は過去1年間で複数のRAGシステムの設計・構築に携わってきましました。単純なRAGから始めて試行錯誤を重ねた結果、成功するRAGシステムにはいくつかの共通する設計パターンがあることが見えてきましました。本記事ではその知見を体系的にまとめます。
RAGの基本パイプラインは、大きく三つのフェーズで構成されます。
この基本形は理解しやすく実装も容易ですが、実運用では精度の問題に直面することが多いです。筆者の経験では、ナイーブなRAGの回答精度は40〜60%程度にとどまることが珍しくありません。以下で紹介する設計パターンにより、80%以上の精度を目指すことが可能です。
RAGの精度を大きく左右するのが、ドキュメントのチャンキング(分割)戦略です。
最もシンプルな方法ですが、文脈が途中で切れるリスクがあります。トークン数やキャラクター数で機械的に分割するため、意味的な区切りと一致しないことが多いです。
文や段落の意味的なまとまりを考慮して分割する手法です。見出し構造やパラグラフ境界を活用し、意味的に完結したチャンクを生成します。筆者の経験では、固定長チャンキングと比較して検索精度が15〜25%向上することが多いです。
小さなチャンクで検索精度を高めつつ、生成時にはより広い文脈を提供するパターンです。検索用には小さなチャンク(子)を使い、LLMへのコンテキストとしては親チャンク(より大きな範囲)を渡します。これにより、検索精度と文脈の豊かさを両立できます。
ベクトル検索(意味的類似度)とキーワード検索(BM25等)を組み合わせる手法です。ベクトル検索は意味の近い文書を見つけるのに優れていますが、固有名詞や型番などの正確なマッチングは苦手です。BM25との組み合わせにより、両方の弱点を補完できます。
筆者のプロジェクトでは、ベクトル検索のみの場合と比較して、ハイブリッド検索で約20%の精度向上を達成しましました。重み付けはベクトル検索0.7、BM25を0.3とする配分が出発点として適切です。
ユーザーの質問をそのまま検索クエリとして使うと、意図と異なる結果が返される場合があります。以下のクエリ変換テクニックが有効です。
初回検索で取得した候補を、クロスエンコーダモデル等で再順位付けするパターンです。ベクトル検索は高速だが精度に限界があるため、上位候補に対してより精密なスコアリングを行うことで、最終的にLLMに渡すコンテキストの質を向上させます。
検索結果をすべてプロンプトに含めるのではなく、質問に関連する部分のみを抽出してコンテキストを圧縮する手法です。トークン数の削減によるコスト削減と、ノイズ除去による回答精度の向上を同時に実現できます。
LLMが自らの回答を評価し、必要に応じて追加検索を行うパターンです。回答の根拠が不十分だと判断した場合にクエリを再構成して再検索することで、より信頼性の高い回答を生成します。処理時間は増加しますが、精度が重要な場面で特に有効です。
RAGシステムの信頼性を高めるために、回答に引用元を明示する設計が重要です。どのチャンクに基づいて回答を生成したかをユーザーに示すことで、ハルシネーション(幻覚)の検証が可能になります。
RAGシステムの継続的な改善には、適切な評価指標の設定が不可欠です。
RAGASやDeepEvalなどの評価フレームワークを活用すると、これらの指標を体系的に管理できます。
RAGアーキテクチャは、シンプルな構成から始めて段階的に高度化していくアプローチが成功の鍵です。まずは基本パイプラインを構築し、評価指標を設定した上で、チャンキング戦略の最適化、ハイブリッド検索の導入、リランキングの追加と順を追って改善していくことを推奨します。完璧を目指して最初から複雑な構成にするのではなく、計測と改善のサイクルを回すことが、実用的なRAGシステム構築への近道です。