RAG構築の手順 — 「1日でできる最小構成」と本番品質の間を、4層で埋める

RAG（Retrieval-Augmented Generation＝検索拡張生成）を「とりあえず動く」ところまで作るのは、もう難しいことではありません。フレームワークのチュートリアルに沿えば、手元の文書に答えるチャットは1日で立ち上がります。私たちも最初の一歩はそこからでした。

問題は、そこから業務で「使える」までの距離です。デモを見た現場が期待して使い始め、普段どおりの質問を投げた途端に外し始める——この間には、チュートリアルが扱わない工程がいくつも挟まっています。この記事では、私たちが実案件で繰り返してきたRAG構築の手順を、「何から作り、どの順で測るか」という実務の順番で書きます。個別の工程の深掘りは各記事に譲り、ここでは全体の設計図を示します。

構築の全体像 — モデル選定から始めない

RAG構築というとモデルやフレームワークの選定から入りたくなりますが、精度を決めるのはそこではありません。私たちの経験では、本番の精度はデータの質、検索の設計、評価の仕組み、運用の体制の順に効きます。モデルの差が効いてくるのは、この4層が整ってからです。

順に見ていきます。

手順0: 「何に答えられれば合格か」を先に決める

最初に作るのはコードではなく、合格の定義です。対象の文書群を絞り、「この質問に答えられれば業務で使える」という質問を現場から集める。私たちは商社の文書検索案件で、業務シナリオに沿った49問の評価セットを起点にしました。この最初の質問集めが、後のすべての工程の物差しになります。

ここを飛ばすと、改善が「なんとなく良くなった気がする」の繰り返しになります。逆に言えば、質問セットさえあれば、構築は「外している質問を減らす作業」という測れる仕事に変わります。

手順1: データ整備 — 精度の土台で、一番地味な工程

固定長で機械的に切らず、文書の構造（条文・見出し・表）に沿って分割する。どの版が最新かをメタデータで持つ。廃止された規程や古い版を検索対象から外す。——派手さのない工程ですが、私たちの経験では精度への効きが最も大きい層です。ここで手を抜くと、後段の検索や生成をどれだけ工夫しても、壊れた素材から正しい答えは出ません。詳細はチャンク設計とデータ整備に書きました。

手順2: 検索設計 — まず素のベクトル、外し方を見てハイブリッド

検索は素のベクトル検索から始めて構いません。ただし、固有名詞や型番で外し始めたら、それはベクトル検索の性質上どうしても起きることなので、キーワード検索（BM25）を並走させて統合するハイブリッド構成に進みます。記号の正規化や略称の展開のような一意に決まる処理は、LLMではなく辞書とルールで先に解く。決まりきった処理をルール側へ寄せておくほど、検索の土台はぐらつきません。設計の詳細はハイブリッド検索の設計へ。

法令・規程のように参照関係を持つ文書ならGraph拡張、検索結果を見て問い直しが要る業務ならAgentic化——ここから先は、文書と症状に応じた系統選びになります。どこまで必要かの見立ては診断ガイドの系統ラダーにまとめています。

手順3: 生成 — 出典を示し、「無い」と言える設計に

生成側で最初に固めるのは、答えの正しさより答え方です。回答には必ず出典（どの文書のどの箇所か）を付ける。検索結果に根拠が無ければ、それらしく埋めずに「見つからなかった」と返す。この2つが守られているだけで、現場からの信頼は大きく変わります。うまく答えた1問より、堂々と間違えた1問のほうが強く記憶されるからです。

手順4: 評価 — 「測れる状態」を作ってから改善を回す

手順0で集めた質問セットを、自動で回せる評価にします。要点は検索と生成を分けて測ること。正解文書が上位に入っているか（検索）と、入っていたときに正しく答えられたか（生成）は別の故障なので、混ぜて測ると打ち手を誤ります。決定的に採点できる項目はルールで、文章の質のような曖昧な項目だけLLM-as-a-Judgeと人手で。作り方は評価セットの設計に書きました。

商社の案件で正答率を38.8%から93.6%まで運べたのは、この物差しがあって、外した質問を層ごとに潰していけたからです。先に作り込んで後から測る逆順だと、どの改善が効いたのか分からなくなります。

手順5: 運用 — 人間監査から始めて、卒業する

本番投入の初期は、AIの回答を人が確認してから使う（human-in-the-loop）体制で始めます。これは暫定の妥協ではなく、設計の一部です。監査の記録が貯まり、評価セット上で品質が基準を満たし続けたら、監査を段階的に外し、利用ログからのフィードバックが自動で回る状態へ移行する。この「監査の卒業」までを最初から設計しておくと、運用コストが線形に増え続けるのを防げます。新しい文書が出たら誰がいつ取り込むかという更新フローも、この段階で決めます。

どこまで作り込むか — 過剰設計の回避

構築ガイドの締めとして逆向きのことを言いますが、全部を作り込む必要はありません。参照関係のない文書にGraphを重ねても、効果のないまま構成だけが複雑になります。判断の順番は「症状が出てから、その症状に効く系統を足す」。過剰設計は精度ではなく、保守コストに跳ね返ります。

構築チェックリスト

• 「この質問に答えられれば合格」という質問セットを、コードより先に作ったか。
• 文書の構造に沿った分割・メタデータ・版の整理ができているか。
• 固有名詞・型番の一致をキーワード検索（BM25）で押さえているか。一意な処理をルールで先に解いているか。
• 回答に出典が付き、根拠が無いときは「無い」と言えるか。
• 検索と生成を分けて測る評価が、自動で回るか。
• 人間監査から始めて「卒業」するまでの道筋と、文書更新のフローを決めたか。

最小構成と本番品質の間を、一緒に埋めませんか

チュートリアルと本番の間にある4層は、どれも特別な発明ではなく、順番どおりに積めば届く工程です。いまどの手順で止まっているかを聞かせていただければ、次に積むべき層をお伝えします。この手順で実際に数字が動いた記録は商社の文書検索事例にあります。

参考文献

• Lewis et al. (2020) Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS — arXiv:2005.11401
• Gao et al. (2023) Retrieval-Augmented Generation for Large Language Models: A Survey — arXiv:2312.10997

この記事は、AIツールを活用して作成し、Cognisant 工藤大地がファクトチェック・編集・監修を行っています。事例の数値はすべて公開済みの実案件既出値です。