RAG実装のベストプラクティス

RAG実装のベストプラクティス ── 精度を高めるための設計と実装の勘所

「RAGを導入すれば、社内データを活用した高精度なAIチャットボットが作れる」

そんな期待を持ってプロジェクトを始めたものの、いざ実装してみると思うような精度が出ない。検索結果が的外れだったり、ハルシネーションが発生したり、ユーザーからの評価が芳しくない。こうした壁に直面しているチームは少なくありません。

RAGは概念としてはシンプルですが、本番運用に耐える精度を出すには、各フェーズでの丁寧な設計と最適化が必要です。本記事では、RAGの基本を簡潔に振り返ったうえで、実装・運用で押さえるべきベストプラクティスを解説します。PoCから本番運用への移行を目指す方、既存のRAGシステムの精度改善に取り組む方の参考になれば幸いです。

RAGとは何か ── 改めて基本を押さえる

なぜRAGが必要なのか

RAG（Retrieval-Augmented Generation）は、外部の知識ベースから関連情報を検索し、その情報をLLM（大規模言語モデル）に与えることで回答精度を向上させる技術です。

LLM単体には、いくつかの本質的な限界があります。学習データの時点での知識しか持たないため、最新情報に対応できません。社内の独自情報やドメイン固有の知識を持っていません。そして、知らないことについても自信を持って回答してしまう「ハルシネーション」を起こします。

RAGは、これらの限界を補完するアプローチです。ユーザーのクエリに関連する情報を外部データベースから検索し、その情報をコンテキストとしてLLMに渡すことで、より正確で根拠のある回答を生成させます。

基本的なフローは、クエリの受け取り、関連情報の検索、検索結果のコンテキスト付与、LLMによる回答生成という4つのステップで構成されます。シンプルに見えますが、各ステップでの設計と最適化が、最終的な精度を大きく左右します。

RAGの精度を左右する3つのフェーズ

どこで精度が決まるのかを理解する

RAGシステムの精度は、大きく3つのフェーズで決まります。

フェーズ1：データ準備（Indexing） では、データの取り込み、前処理、チャンク分割、埋め込み（Embedding）、インデックス構築を行います。ここでの設計が検索精度の土台を作ります。

フェーズ2：検索（Retrieval） では、ユーザーのクエリを処理し、ベクトル検索やハイブリッド検索で関連情報を取得します。リランキングによる精度向上もこのフェーズに含まれます。

フェーズ3：生成（Generation） では、検索結果をコンテキストとして構成し、プロンプトを設計し、LLMに回答を生成させます。

これら3つのフェーズは連鎖しており、どこかが弱いと全体の精度が下がります。「検索は良いのに回答がおかしい」「回答生成は問題ないが、そもそも必要な情報が検索できていない」といった問題を切り分けるためにも、各フェーズを独立して評価・改善できる設計が重要です。

データ準備フェーズのベストプラクティス

検索精度の8割はここで決まる

RAGの精度問題の多くは、実はデータ準備フェーズに起因しています。「Garbage In, Garbage Out」の格言の通り、質の低いデータからは質の高い検索結果は得られません。

データクレンジングの重要性

最初に取り組むべきは、データの品質確保です。重複コンテンツの除去は基本中の基本です。同じ内容が複数登録されていると、検索結果に重複が発生し、コンテキストの質が下がります。

フォーマットの統一も重要で、日付表記、数値表記、用語の表記揺れなどを整理します。PDFやWordなどからテキストを抽出する際は、抽出品質の確認が必要です。表やグラフの情報が欠落していないか、ヘッダー・フッター・ページ番号などの不要な情報が混入していないか、レイアウトの崩れで文章の順序がおかしくなっていないかをチェックします。

地味な作業ですが、ここを疎かにすると後工程でいくら最適化しても限界があります。

チャンク分割の設計

チャンク分割は、RAG実装で最も重要な設計判断の一つです。

チャンクサイズの選定には、トレードオフがあります。チャンクが小さすぎると、一つのチャンクに含まれる文脈が不足し、検索でヒットしても回答に必要な情報が欠けることがあります。逆にチャンクが大きすぎると、検索精度が下がり、関係のない情報がノイズとして混入しやすくなります。

一般的な目安としては、256〜512トークン程度が出発点となりますが、これはドメインやユースケースによって調整が必要です。FAQのような短い回答を扱う場合は小さめに、技術文書のように文脈が重要な場合は大きめに設定することが多いです。

オーバーラップの活用も有効です。隣接するチャンク間で10〜20%程度のオーバーラップを設けることで、チャンク境界での文脈の断絶を防げます。わずかなストレージ増加と引き換えに、検索漏れを減らせるため、多くの本番環境で採用されています。

より高度なアプローチとして、セマンティックチャンキングがあります。固定長ではなく、意味のまとまり（段落、セクション、トピック）で分割する手法です。文書の構造を活かせる場合に有効ですが、実装の複雑さは増します。

また、メタデータの付与を忘れないでください。ソースファイル名、作成日、カテゴリ、著者などのメタデータをチャンクに付与しておくと、検索時のフィルタリングに活用できます。「2024年以降のドキュメントのみ検索」「製品Aに関するドキュメントのみ検索」といった絞り込みが可能になり、精度向上に寄与します。

埋め込みモデルの選定

チャンクをベクトル化する埋め込みモデルの選定も重要です。代表的な選択肢として、OpenAIのtext-embedding-3-large、Cohereのembed-multilingual、オープンソース系のmultilingual-e5-largeやBGE-M3などがあります。

日本語を扱う場合は、多言語対応モデルか日本語に強いモデルを選ぶ必要があります。英語中心のモデルでは、日本語の意味的な類似性をうまく捉えられないことがあります。

モデルの次元数は、精度とコスト・レイテンシのトレードオフに影響します。次元数が大きいほど表現力は高まりますが、ストレージと検索コストが増加します。

ドメイン固有の用語や概念が多い場合は、埋め込みモデルのファインチューニングも検討に値します。ただし、実装・運用のコストが増えるため、まずは汎用モデルで十分な精度が出るかを検証してからの判断をおすすめします。

検索フェーズのベストプラクティス

必要な情報を、必要な順で取得する

データ準備ができたら、次は検索フェーズの最適化です。

ベクトル検索の基本と限界

ベクトル検索（セマンティック検索）は、クエリとドキュメントの意味的な類似性に基づいて検索する手法です。「売上を伸ばす方法」というクエリに対して、「収益を向上させるアプローチ」という表現のドキュメントもヒットさせられる点が強みです。

しかし、ベクトル検索にも限界があります。キーワードの完全一致が必要な場合、例えば製品型番や固有名詞の検索では、ベクトル検索は必ずしも正確ではありません。「ABC-123」という型番を検索したいのに、意味的に近い別の型番がヒットしてしまうことがあります。

ハイブリッド検索の導入

こうした限界を補うのが、ハイブリッド検索です。ベクトル検索とキーワード検索（BM25など）を組み合わせ、両者のスコアを統合して最終的なランキングを決定します。

スコアの統合方法としては、Reciprocal Rank Fusion（RRF）がよく使われます。両方の検索結果の順位を基にスコアを計算し、統合する手法です。

ハイブリッド検索は、多くの本番環境で採用されているアプローチです。ベクトル検索の意味理解の強みと、キーワード検索の正確性を組み合わせることで、単独の手法よりも高い精度を実現できます。

リランキングの活用

初期検索で取得した結果を、より精度の高いモデルで並び替えるのがリランキングです。

ベクトル検索で使う埋め込みモデル（Bi-Encoder）は、クエリとドキュメントを個別にベクトル化するため、高速ですが精度には限界があります。一方、リランキングで使うCross-Encoderは、クエリとドキュメントを一緒に入力して関連度を判定するため、より高精度な判定が可能です。

Cohere Rerank、BGE Reranker、JINAのRerankerなどが代表的なソリューションです。リランキングは計算コストが高いため、全件に適用するのではなく、初期検索のTop-20〜50件に対してのみ適用し、上位5〜10件を最終結果とするのが一般的です。

クエリの前処理と拡張

ユーザーのクエリをそのまま使うのではなく、前処理や拡張を行うことで検索精度を向上させる手法もあります。

クエリリライティングは、ユーザーの曖昧なクエリをより明確な形に書き換える手法です。LLMを使って「このクエリの意図は何か」を解釈させ、検索に適した形に変換します。

HyDE（Hypothetical Document Embeddings）は、クエリに対する仮想的な回答文書をLLMに生成させ、その文書のベクトルで検索する手法です。クエリよりも回答に近い文書で検索することで、関連文書をヒットさせやすくなります。

複合的な質問の場合は、クエリ分解が有効です。「製品Aの価格と、競合製品Bとの比較を教えて」というクエリを、「製品Aの価格」「製品Aと製品Bの比較」に分解して個別に検索し、結果を統合します。

生成フェーズのベストプラクティス

検索結果をどうLLMに渡すか

良い検索結果が得られても、それをLLMに適切に渡さなければ、良い回答は生成されません。

コンテキストの構成

検索で取得したチャンクを、どのような順序でコンテキストに配置するかは、回答品質に影響します。

「Lost in the Middle」と呼ばれる現象があります。LLMは、コンテキストの先頭と末尾の情報は比較的よく参照しますが、中間部分の情報を見落としやすい傾向があります。そのため、最も重要な情報は先頭または末尾に配置することが推奨されます。

コンテキストウィンドウの制約も考慮が必要です。LLMには入力トークン数の上限があり、多くのチャンクを詰め込みすぎるとコストが増加し、かえって精度が下がることもあります。取得件数とトークン数のバランスを調整します。

プロンプト設計

プロンプトの設計は、ハルシネーション抑制と回答品質に直結します。

システムプロンプトで、モデルの役割と制約を明確に定義します。「あなたは社内ナレッジに基づいて回答するアシスタントです」「提供された情報に基づいてのみ回答してください」「情報が見つからない場合は『該当する情報が見つかりませんでした』と回答してください」といった指示を含めます。

出典の明示を求める指示も有効です。「回答の根拠となる情報のソースを明記してください」と指示することで、ユーザーが回答の信頼性を確認でき、ハルシネーションの検出も容易になります。

LLMの選定

タスクの複雑さに応じて、適切なモデルを選定します。単純なQ&Aであれば、軽量なモデルでも十分な精度が出ることがあります。複雑な推論や要約が必要な場合は、より高性能なモデルが必要です。コスト、レイテンシ、精度のバランスを考慮して選定します。

ユーザー体験の観点では、ストリーミング出力の活用も検討します。回答全体が生成されるまで待つのではなく、逐次的に出力することで、体感の待ち時間を短縮できます。

評価と継続的改善

測定できないものは改善できない

RAGシステムを継続的に改善するには、適切な評価の仕組みが不可欠です。

RAGの評価指標

RAGの評価は、検索と生成の両面から行います。

検索の評価指標としては、Recall@K（上位K件に正解が含まれる割合）、Precision@K（上位K件のうち正解の割合）、MRR（Mean Reciprocal Rank、正解の順位の逆数の平均）などがあります。

生成の評価指標としては、Faithfulness（忠実性：回答がコンテキストに基づいているか）、Relevance（関連性：回答がクエリに対して適切か）、Hallucination率（コンテキストにない情報を生成している割合）などがあります。

End-to-Endの評価としては、人間による評価が最も信頼性が高いですが、コストがかかります。LLM-as-a-Judge（LLMに回答を評価させる手法）も、スケーラブルな評価方法として活用されています。

評価データセットの構築

汎用のベンチマークだけでなく、自社ドメインに即した評価データセットを構築することが重要です。実際のユースケースを想定した質問と、期待される回答（または回答の根拠となるドキュメント）のペアを用意します。

最初は10〜30問程度の小規模なデータセットでも、改善の方向性を判断するには十分です。定期的に評価を実施し、ベースラインとの比較を行うことで、改善の効果を定量的に測定できます。

継続的改善のサイクル

本番運用後も、継続的な改善が必要です。ユーザーフィードバックの収集は、最も直接的な品質シグナルです。「この回答は役に立ちましたか？」といった簡単なフィードバック機能を設けます。

低評価の回答を分析する際は、問題のフェーズを特定することが重要です。検索結果を確認し、そもそも必要な情報が取得できていたのか、それとも情報はあったが生成で失敗したのかを切り分けます。

改善施策を実施する際は、A/Bテストで効果を検証します。感覚的な改善ではなく、データに基づいた意思決定を行うことで、着実に精度を向上させられます。

よくある失敗パターンと回避策

実装で躓くポイント

最後に、RAG実装でよくある失敗パターンとその回避策を整理します。

まとめ

本記事で解説したRAG実装のベストプラクティスを振り返ります。

• RAGの精度はデータ準備・検索・生成の3フェーズの連鎖で決まる。各フェーズを独立して評価・改善できる設計が重要
• データ準備フェーズが精度の土台。チャンク分割の設計、メタデータの付与、埋め込みモデルの選定を丁寧に行う
• ハイブリッド検索とリランキングの組み合わせが、多くの本番環境で採用される実践的なアプローチ
• クエリリライティングやHyDEなどの前処理は、ユーザーの曖昧なクエリを補完し検索精度を底上げする
• プロンプト設計でハルシネーションを抑制し、出典の明示を求めることで回答の信頼性を担保する
• 評価パイプラインを先に構築し、定量的な改善サイクルを回すことが継続的な精度向上の鍵

RAGは「導入すれば終わり」の技術ではなく、運用しながら磨き続けるシステムです。PoCで手応えを掴んだら、本記事で整理した設計判断と最適化ポイントを一つずつ積み上げていくことが、本番運用に耐える精度への最短経路です。