RAG構築の進め方｜FDEが実務で使う5ステップと評価設計

RAG構築の進め方は？着手前に決めるべき論点は何か？

RAG構築は、回答すべき質問と評価基準を先に決め、検索対象の文書範囲を絞ってから着手します。

RAG（Retrieval-Augmented Generation／検索拡張生成）は、社内文書などの外部知識を検索して、その内容を根拠に大規模言語モデルへ回答を生成させる構成です。手法としては2020年のLewisらの論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」（NeurIPS 2020）で定式化され、現在は社内ナレッジ検索や問い合わせ対応の標準構成になっています。

実務で失敗するRAGの多くは、モデル選定やベクトルデータベースの比較から着手しています。FDE（Forward Deployed Engineer）が企業の現場に入るとき最初に固定するのは、技術要素ではなく「誰のどの質問に、どの精度で答えれば業務が変わるのか」です。ここが曖昧なまま作ると、それらしい回答は返るが誰も使わない、という状態に着地しやすいという印象があります。

RAGで何を解くのかはどう決めるのか？

解く対象は、業務で繰り返し発生する質問に限定します。問い合わせ履歴から頻度上位の質問を20〜50件抜き出し、着手範囲を固定します。

絞り込みの実務的な基準は次の3点です。

1. 繰り返し発生している — 同種の質問が週に何件来ているかを数えられる業務を選びます。単発の調査依頼はRAGの効果を測りにくい対象です。
2. 答えが文書に存在する — 既存文書に答えが書かれていない質問は、RAG構築ではなく文書整備の課題です。ここを取り違えると、検索を何度改善しても精度は上がりません。
3. 正解を人が判定できる — 担当者が「この回答は正しい／誤り」と即答できる領域から始めます。判定できない質問は評価セットを作れず、改善のループが回りません。

RAGとファインチューニングはどちらを選ぶのか？

知識の更新頻度が高く出典提示が必要ならRAG、出力の形式や文体を固定したいならファインチューニングを選びます。

実務では二者択一ではなく、「知識はRAG、出力形式はプロンプトで固定」という組み合わせが最初の選択になることが多いと感じます。対象文書が数十ページに収まるなら、RAGを組まずにコンテキストへ全文を入れる構成のほうが速く、精度も安定します。RAGは文書量が増えて全文投入が現実的でなくなった時点で必要になる仕組みだ、と整理しておくと判断がぶれません。

着手前に合意しておく非機能要件は何か？

合意すべきは、権限分離・応答時間・更新頻度・誤答時の扱いの4点です。後から足すと設計のやり直しになります。

特に権限分離は最優先です。人事文書や契約書を含むRAGでは、「検索結果に含めてよい文書かどうか」を検索の段階で絞り込む必要があります。生成後にフィルタする設計にすると、見えてはいけない情報がモデルの回答に混ざる事故が起こり得ます。FDEの現場では、ユーザーの所属・職位をメタデータ条件として検索クエリに必ず結合する設計を、初期構成の時点で入れておく形が一般的です。

RAGの構築ステップはどう分けるのが実務的か？

実務では、対象選定→文書整備→検索実装→生成設計→評価と運用の5ステップに分けて進めます。

ステップを分ける目的は、進捗を測ることではなく「どこで詰まっているか」を切り分けられるようにすることです。RAGは検索と生成が連なる構成のため、一体で見ていると精度不足の原因が特定できません。

各ステップの成果物と終了条件は何か？

各ステップに成果物と終了条件を置き、業務側の合意を得てから次へ進みます。期間は文書量と権限調整の重さで変動します。

ステップ2の文書整備が最も読みにくい工程です。「社内文書は整っている」という前提で見積もると、旧版と現行版が混在していた、部署ごとに別のフォルダに写しがあった、といった事情が実装段階で表面化します。検索が古い版を引いてくれば、モデルがどれだけ優秀でも回答は誤ります。

チャンク分割と埋め込みはどう設計するのか？

チャンクは意味のまとまりで切り、前後の文脈を重複させます。見出し構造を保持できる文書は、見出し単位の分割が扱いやすい方法です。

実務での設計指針は次のとおりです。

• 分割単位 — 固定長よりも、見出し・条項・Q&Aといった文書の構造に沿って切るほうが精度が安定します。構造が取れない文書は数百トークン程度を目安に、前後を一定量重複（オーバーラップ）させます。
• メタデータ付与 — 文書名、最終更新日、部署、公開範囲をチャンクに必ず持たせます。検索の絞り込みにも、回答の出典表示にも使います。
• 文脈の補完 — チャンク単体では「これ」「同社」が何を指すか失われます。Anthropicが2024年9月に公開した「Contextual Retrieval」では、各チャンクに文書全体から見た短い文脈説明を付けたうえでBM25を併用する手法により、検索失敗率が約49%減少し、リランキングを加えると約67%減少したと報告されています（Anthropic公式ブログ）。
• 埋め込みモデル — 日本語文書では、多言語対応モデルの実効性能が対象ドメインで大きく変わります。評価セットで2〜3種類を比較してから固定するのが無難です。

最初のリリースはどこまで作るのか？

最初のリリースは、対象を1業務・1文書群に限定し、社内の数名が毎日使う状態までを範囲とします。

全社公開を初手に置くと、質問の分布が広がりすぎて評価セットが機能しません。限定公開で数週間運用し、実際に投げられた質問ログを評価セットへ還流させる流れを作るほうが、結果的に改善が速く進みます。FDEの進め方では、この「使われ方を観測できる状態」を最優先の成果物として扱います。

RAGの精度が出ないときは何を改善するのか？

精度不足はまず検索側を疑います。生成の改善より、検索で正解文書が上位に来ているかの確認が先です。

プロンプトを書き換えても改善しない場合、そもそも正解の文書がモデルに渡っていない可能性が高い、というのが実務での定石です。切り分け手順は単純で、評価セットの質問に対して検索結果の上位k件を人が目視し、正解文書が含まれているかを数えます。含まれていなければ検索の課題、含まれているのに誤答するなら生成の課題です。

検索が外れる原因はどこにあるのか？

原因の多くは、表記ゆれ・チャンクの粒度・文書の重複と旧版混在の3つに集約されます。

ハイブリッド検索とリランキングは、追加実装の労力に対して効果が出やすい改善です。一方でリランキングは推論コストと応答時間を増やすため、上位何件に適用するかは応答時間の要件と合わせて決めます。

生成が事実からずれるときはどう直すのか？

渡した文書の範囲で答えるよう制約し、根拠がないときは「わからない」と返す設計にします。

具体的には、プロンプトで参照文書の引用を必須にし、引用できない場合は回答を拒否させる形です。加えて、出典としてチャンク元の文書名と該当箇所を必ず画面に表示します。出典表示は正確性の担保だけでなく、利用者が自分で検証できる状態を作る点で効きます。

現場で観察していて感じるのは、回答の正しさよりも「誤ったときに気づけるか」が業務利用の可否を分けている、という点です。出典が出ていれば、利用者は不審な回答を自分で潰せます。出典がないと、一度の誤答でツール全体が信用されなくなります。

RAGの評価はどう設計すればよいのか？

評価は検索と生成を分けて測ります。正解文書を付けた評価セットを50〜100件用意し、変更のたびに回します。

評価を後回しにしたRAGは、改善が主観になります。チャンクサイズを変えた、プロンプトを変えた、という変更が良かったのか悪かったのかを判定できず、作業が試行錯誤に終始します。評価セットは、ステップ1で作る最初の成果物です。

評価セットはどう作るのか？

実際の問い合わせ履歴から質問を抜き出し、業務担当者に正解文書と模範回答を付けてもらいます。

• 質問は、モデル生成ではなく実際に投げられた文面をそのまま使います。言い回しの崩れや略語こそが検索の難所だからです。
• 1問につき「正解が書かれている文書とその箇所」を記録します。これが検索指標の測定根拠になります。
• 「答えられないべき質問」を1〜2割混ぜます。対象外の質問に無理やり答えていないかを検出するためです。
• 運用開始後は、実ログから毎月10〜20件を追加し、評価セットを更新し続けます。

50〜100件という規模は、業務担当者が現実的に正解付けできる上限としての目安です。少なすぎると指標が数件の当たり外れで動き、多すぎると更新が止まります。

どの指標を見ればよいのか？

検索はRecall@kとMRR、生成は忠実性（Faithfulness）と回答関連性を見ます。指標は絶対値より変更前後の差で判断します。

生成側の評価は、LLMを判定者に使う方式（LLM-as-a-judge）が実務的です。Ragasなどのオープンソース評価フレームワークは、忠実性や回答関連性の算出を実装しています（Ragas公式ドキュメント）。ただし判定者も誤るため、最初の数十件は人の判定と突き合わせ、判定のずれ方を把握してから自動化する順序が安全です。

運用後の継続評価はどうするのか？

文書更新のたびに評価を自動実行し、指標の下落を検知します。加えて、利用者のフィードバックをログとして蓄積します。

RAGの精度は、モデルを変えなくても劣化します。文書が増え、組織が変わり、質問の傾向が動くためです。CI上で評価セットを定期実行し、Recall@kやFaithfulnessが閾値を下回ったら通知する仕組みを、運用移管の前に組み込んでおきます。画面側には「役に立った／立たなかった」の簡易フィードバックと自由記述を置き、否定的な回答を毎週レビューする運用が回しやすい形です。

FDEは企業のRAG構築をどう進めるのか？

FDEは現場に入り、質問の収集から評価設計、運用移管までを業務担当者と往復しながら進めます。

RAG構築が受発注型の開発と噛み合いにくいのは、要件が「何を聞かれるか」に依存しており、仕様書として事前に固定できないためです。実際の質問ログを見て初めて、必要なチャンク設計も権限条件も決まります。FDEが現場に常駐して短い周期で作り替える進め方は、この性質に対する現実的な対応策として機能します。

FDEはRAG構築で何を担当するのか？

FDEは、業務担当者への聞き取り、評価セットの整備、検索・生成の実装、運用手順の作成までを一貫して担当します。

• 質問の収集 — 問い合わせ窓口やチャットの履歴を業務担当者と一緒に読み、答えるべき質問を確定します。
• 文書の棚卸し — どの文書が正で、誰が更新しているかを特定します。ここで「正」が決まらない文書は、RAGの前に管理責任の整理が必要になります。
• 評価の運用設計 — 評価セットの正解付けを業務担当者の作業として設計に組み込みます。外部の技術者だけでは正解を判定できないためです。
• 実装と反復 — 週次で評価結果を業務担当者に見せ、次に直す点を合意します。改善の優先順位を技術者だけで決めない点が要点です。

Palantirが定義したFDEという職種は、顧客の業務に入り込んで課題定義から実装までを担う役割として知られています（Palantir公式サイト）。RAGのように業務知識と実装が不可分な領域は、この働き方が特に噛み合う対象だと言えます。VACAN Technologiesでも、社内文書を対象としたRAGの検討では、技術選定より前に「どの質問を、誰の判定で正解とするか」を決める工程に時間を割く形を取っています。

内製チームへの移管はどう進めるのか？

移管は、社内担当が単独で「文書追加→評価実行→改善判断」を1周できる状態を到達点とします。

移管で引き渡すべきは、コードよりも運用の手順です。具体的には、文書を追加・更新したときのインデックス再構築手順、評価セットの更新ルール、指標が下がったときの切り分け手順（検索か生成か）、そして誤答報告を受けたときの対応フローです。

構築期間中から社内担当を評価の正解付けに参加させておくと、移管時の断絶が小さくなります。逆に、構築が終わってから引き継ぎを始めると、評価セットの意図が伝わらず、更新が止まったまま精度だけが静かに劣化していきます。RAGは作って終わりの仕組みではなく、文書と質問の変化に追従し続ける運用資産である——この前提を移管時点で共有できているかどうかが、その後1年の使われ方を左右します。

関連する実務の考え方は、実務ナレッジおよび導入検討の各記事でも整理しています。

姉妹メディアの関連記事