RAG 構築の実践ガイド - 精度を上げる設計と評価の手順

社内に蓄積した文書やナレッジを LLM に読ませて、正確に答えさせたい。そう考えて RAG (Retrieval-Augmented Generation) に取り組むと、最初のプロトタイプはすぐ動くのに、いざ実データを入れると「それらしいが間違った答え」を返し始める、という壁にぶつかります。本記事では、RAG 構築をチャンク設計・埋め込み・検索・再ランキング・回答生成・評価という工程に分解し、それぞれで精度を左右する判断基準を実プロジェクトの目線で整理します。「とりあえず動く RAG」から「業務で信頼できる RAG」へ引き上げるための手順書として読んでください。

RAG とは何か - ファインチューニングとの違いと使いどころ

RAG とは、ユーザーの質問に関連する文書を検索で引っ張ってきて、その内容を LLM のプロンプトに渡したうえで回答を生成させる仕組みです。LLM 単体は学習時点の知識しか持たず、社内固有の情報や最新の仕様を知りません。RAG はそこに「外部知識を検索で補う」工程を挟むことで、モデルを再学習させずに回答の根拠を与えます。

似た目的で語られるファインチューニングとは、得意分野が異なります。ファインチューニングはモデルの重みを追加学習で書き換える手法で、文体や出力形式、ドメイン特有の言い回しといった「答え方」を変えるのに向きます。一方 RAG は「何を答えるか」の知識供給を担い、検索対象を差し替えるだけで内容を更新できるのが強みです。

実務での使い分けはおおむね次の軸で決まります。

• 知識が頻繁に変わる・出典を提示したい → RAG
• 出力フォーマットや振る舞いを厳密に揃えたい → ファインチューニング
• 両方必要 → RAG を土台に、必要な振る舞いだけ追加調整する

社内 FAQ、規定・マニュアルの問い合わせ対応、仕様書の横断検索といったユースケースは、内容が更新され続けるうえに「どの文書に書いてあったか」を示せる価値が大きいため、RAG が第一候補になります。RAG はこうした AI エージェント構築の中核技術でもあり、エージェントが業務知識を参照する手段として組み込まれることが増えています。

RAG の基本構成 - インデックス作成から回答生成までの流れ

RAG は大きく「事前のインデックス作成」と「実行時の検索・生成」の 2 つのフェーズに分かれます。

インデックス作成フェーズでは、対象文書を読み込み、見出しや段落といった意味のまとまりを保てる単位に分割 (チャンク化) し、各チャンクを埋め込みモデルでベクトルに変換して、ベクトルデータベースや検索エンジンに格納します。ここで作ったインデックスの質が、後段の精度の上限を決めます。

実行時フェーズでは、ユーザーの質問を同じ埋め込みモデルでベクトル化し、近いチャンクを検索で取得します。取得した複数の候補を再ランキングで絞り込み、上位のチャンクを文脈として組み込んだプロンプトを LLM に渡し、最終的な回答を生成します。

flowchart LR
  D["社内文書 / ナレッジ"] --> C["チャンク分割<br/>+ 前処理"]
  C --> E["埋め込み<br/>(ベクトル化)"]
  E --> VDB[("ベクトル DB<br/>+ 全文検索")]
  Q["ユーザーの質問"] --> S["検索<br/>(ベクトル + キーワード)"]
  VDB --> S
  S --> RR["再ランキング"]
  RR --> P["プロンプト組み立て"]
  P --> LLM["LLM が回答生成"]
  LLM --> A["出典付きの回答"]

重要なのは、精度問題の多くが LLM ではなく上流の検索工程で起きるという点です。検索が正しいチャンクを引けていなければ、どれだけ高性能なモデルを使っても正答にはなりません。以降のセクションは、この流れを上流から順に作り込んでいく構成になっています。

精度を左右するチャンク分割と前処理の設計

RAG の精度で最初に効いてくるのがチャンク分割です。文書をどの単位で区切るかによって、検索でヒットする情報のまとまりが決まります。チャンクが大きすぎると、ひとつのベクトルに複数の話題が混ざって意味がぼやけ、検索の精度が落ちます。逆に小さすぎると、回答に必要な文脈が分断され、断片だけ引いても答えが組み立てられません。

実務では、固定文字数で機械的に切るのではなく、文書構造を尊重した分割が有効です。見出し・段落・箇条書きといった構造の境界で区切ると、意味のまとまりが保たれます。Markdown や HTML の見出し階層、PDF のセクションを手がかりにすると、自然な単位になりやすいです。

加えて、隣接チャンクを少しオーバーラップさせる (前後数十〜百数十文字を重ねる) と、境界をまたぐ文脈の欠落を防げます。粒度は一概に正解がなく、扱う文書とユースケースで変わるため、複数パターンを評価セットで比較して決めるのが確実です。

チャンク分割と同じくらい効くのが前処理です。ここを軽視すると検索が安定しません。実務で効果が大きいのは次のような処理です。

• ヘッダー・フッター・ページ番号・ナビゲーションなど、内容に無関係なノイズの除去
• 表や箇条書きの構造を壊さずテキスト化する (PDF・スプレッドシートは特に崩れやすい)
• 各チャンクに出典・章タイトル・更新日などのメタデータを付与する
• 略語や社内用語の表記ゆれを正規化する

特にメタデータの付与は後段で効きます。出典を回答に添えたり、部署や文書種別で検索範囲を絞り込んだりする運用は、チャンクにメタデータが乗っていて初めて成立します。インデックス作成時に丁寧に設計しておくと、運用に入ってからの調整の幅が大きく広がります。

埋め込みモデル選定とベクトル検索・ハイブリッド検索

チャンクが整ったら、それをベクトルに変換する埋め込みモデルを選びます。選定で見るべき主な観点は、対象言語への対応 (日本語文書なら日本語性能)、ベクトルの次元数とそれに伴う検索コスト、API 利用かセルフホストか、そしてコンテキスト長です。日本語の社内文書を扱うなら、日本語を含む多言語で学習されたモデルか、日本語に強いモデルを選ぶのが前提になります。

ベクトル検索は質問とチャンクの「意味の近さ」で候補を取得する仕組みで、言い回しが違っても意味が近ければ拾える点が強みです。一方で、型番・固有名詞・略語・社内独自の用語のように「その語そのもの」が鍵になる検索には弱く、意味が近いだけの無関係なチャンクを引いてしまうことがあります。

この弱点を補うのがハイブリッド検索です。ベクトル検索とキーワード検索 (BM25 などの全文検索) を併用し、両者のスコアを統合して候補を選びます。

検索方式	得意	苦手
ベクトル検索	言い換え・意味の近い質問	固有名詞・型番・略語の厳密一致
キーワード検索	固有表現・専門用語の確実な一致	表現が異なる同義の質問
ハイブリッド検索	両者の取りこぼしを相互に補完	構成・スコア統合の調整が要る

製品マニュアルや社内規定のように固有表現が多い文書では、ハイブリッド検索の効果が出やすいです。導入手順としては、まずベクトル検索で基準値を取り、ハイブリッド化で検索ヒット率がどれだけ上がるかを評価セットで比較してから採用を判断します。ベクトル検索設計の段階で「意味検索だけで足りるか、キーワードも必要か」をデータの性質から見極めておくと、後戻りが減ります。

再ランキングと回答生成プロンプトの作り込み

検索で取得した候補は、上位に必ずしも最適なチャンクが並ぶとは限りません。そこで、検索で広めに候補を取ってから再ランキング (リランキング) で精密に並べ替える二段構えが有効です。

具体的には、まずベクトル検索やハイブリッド検索で 20〜50 件ほど候補を取得し、再ランキング用のモデルで質問との関連度を改めて採点して上位数件に絞ります。検索の取りこぼしを減らすために候補を広く取り、最終的に LLM へ渡す前に質を上げる、という役割分担です。LLM に渡せる文脈の量には限りがあるため、ここで無関係なチャンクを落としておくほど、回答に余計な情報が混ざりにくくなります。

絞り込んだチャンクは、回答生成プロンプトに組み込みます。ここで精度を大きく左右するのが、プロンプトの作り込みです。実務で効果が安定するのは次のような指示です。

• 提供した文書の範囲内だけで回答し、書かれていないことは「情報がない」と答えさせる
• 回答の根拠として、どのチャンク・どの出典を参照したかを明示させる
• 推測で補わない、断定できない場合は曖昧さを残す、といった態度を指定する

「与えられた文脈にないことは答えない」と明確に縛るだけで、もっともらしい嘘 (ハルシネーション) は大きく減らせます。出典を併記させる設計は、回答の信頼性を高めるだけでなく、誤りが出たときに「検索が悪かったのか、生成が悪かったのか」を切り分ける手がかりにもなります。RAG 以外も含めて誤回答を業務利用で抑える打ち手は ハルシネーション対策の設計 で整理しています。プロンプトはデータと質問の傾向に合わせて反復調整する前提で、評価セットを回しながら詰めていきます。

RAG の精度をどう測るか - 検索精度と回答精度の評価指標

RAG 精度向上で最も重要なのは、精度を数値で測れる状態を作ることです。評価の仕組みがないと、改善が当たっているのか勘で判断することになり、調整が泥沼化します。

RAG の評価は「検索の精度」と「回答の精度」を分けて見るのが鉄則です。両者を混ぜて測ると、どの工程がボトルネックか分からなくなります。

検索の精度では、想定質問に対して「正解を含むチャンクが上位に入っているか」を測ります。代表的な指標は、上位 K 件に正解チャンクが含まれる割合 (検索ヒット率 / Recall@K) や、正解がどれだけ上位に来たかを評価する指標です。検索でそもそも引けていなければ、後段でいくら頑張っても正答は出ません。まずここを固めます。

回答の精度では、生成された回答が正しいか、文脈に忠実か、問いに答えているかを見ます。観点は主に次の 3 つです。

• 正確性: 回答内容が事実として正しいか
• 忠実性: 提供したチャンクの範囲を逸脱していないか (ハルシネーションの有無)
• 関連性: 質問に対して的を射た回答か

評価の進め方としては、まず実際に来そうな質問と期待される回答・根拠チャンクをセットにした評価データセットを 30〜100 件程度作ります。これを使って、チャンク粒度・検索方式・プロンプトを変えるたびに同じ評価を回し、数値で比較します。回答の正確性の判定は、人手レビューに加えて LLM による自動採点 (LLM-as-a-judge) を併用すると、反復のたびに人手をかけずに済み、改善サイクルが速く回ります。評価セットは一度作って終わりではなく、運用で見つかった失敗ケースを足して育てていくものです。

実プロジェクトでの RAG 構築事例と運用上の落とし穴

私たちが手がけた AI エージェントによる運用自動化のプロジェクト では、社内に分散したナレッジをエージェントが参照するために RAG を組み込みました。ここで実感したのは、精度を決めるのはモデルの新しさよりも、チャンク設計・前処理・評価という地味な工程の積み重ねだということです。プロトタイプは数日で動いても、実運用に耐える精度まで引き上げるにはこの工程の反復が要ります。

実務で繰り返し遭遇する落とし穴を挙げておきます。

• 検索が引けていないのに LLM を疑ってしまう。原因の多くは上流の検索にあるので、まず検索ヒット率を測り、検索が取れているかを確認してから生成側を疑う順序を徹底します。
• 文書が更新されてもインデックスが古いまま放置される。元文書は更新されるのに再インデックスの仕組みがなく、古い情報を返し続ける事故です。更新の反映フローを最初に設計へ含めておきます。
• 評価セットがなく勘で調整してしまう。数値の基準がないと改善が積み上がりません。小さくても評価セットを先に用意します。
• アクセス権限を無視して検索してしまう。全文書を区別なく検索対象にすると、本来見せてはいけない情報が回答に混ざります。メタデータで閲覧範囲を絞る設計が要ります。
• チャンクが大きすぎる、または小さすぎる。既定値のまま放置せず、データに合わせて粒度を評価で決めます。

運用フェーズでは、ユーザーが実際に投げた質問と回答のログを定期的に振り返り、失敗ケースを評価セットに取り込んで改善を回す体制が効きます。RAG は「作って終わり」ではなく、文書とユーザーの変化に合わせて育て続ける対象だと捉えるのが、長く使える RAG を作るコツです。こうしたデータと評価を軸に改善を回す進め方は、AI 駆動開発 の考え方そのものでもあります。

AI 駆動開発で RAG を本番導入するなら

RAG は、最初のプロトタイプを動かすことと、業務で信頼できる精度まで仕上げることの間に大きな隔たりがある技術です。チャンク設計・前処理・検索方式・再ランキング・プロンプト・評価という工程を、評価指標を軸に 1 つずつ詰めていく作業が成果を分けます。本記事の手順をなぞれば、どこがボトルネックかを数値で特定しながら改善を回せるはずです。

FIXIT は AI 駆動開発のクリエイティブスタジオとして、RAG や AI エージェントの開発 を実プロジェクトで構築・運用してきました。社内ナレッジを正しく答えさせたい、RAG の精度が頭打ちで困っている、本番運用に耐える設計に作り直したい、といった課題があれば、無料相談 からお気軽にご相談ください。要件と既存データを踏まえ、現実的な構成と進め方を一緒に整理します。