RAG運用の成否を分ける文書構造と評価の仕組み 旧索引を止めずに入れ替える再構築の進め方
ニュースの概要
RAG（検索で見つけた文書を材料に、生成AIが回答を作る仕組み）の実運用について、技術解説が公開された。ポイントは、文書を機械的に切るのではなく、見出しや親子関係といった構造を残すことだ。検索には小さな子チャンクを使い、生成モデルには文脈の広い親チャンクを渡す方式が紹介されている。さらに、チャンク設定の版管理、実際の質問と正解文書による検索ヒット率の測定、設定変更のたびの継続テスト、旧索引と新索引を並行で動かすブルーグリーン方式での切り替えも挙げられている。
引用元: RAG運用では文書構造、評価、再インデックス管理が重要に（TechWorld with Sahana）
分析・見解
切る技術より、切った後の構造を残す技術
RAGの失敗原因を調べると、検索そのものより切り方に行き着くことが多い。500字ごとに機械的に区切ると、表の見出しと数値が別々の断片になり、条件文の前提も抜け落ちる。人間は文書を読むとき、章や節、表題といった階層から意味を補っている。その階層を捨てるのは、本から目次と章題を破り取って渡すようなものだ。
親子方式はこの問題への現実的な答えである。検索には小さな子チャンク（＝細かく切った断片）を使って当たりやすさを確保し、生成には親の節をまるごと渡して前後の文脈を補う。当たりやすさと読みやすさという相反する要求を、二段構えで両立させる発想だ。
「体感」ではなく数字で良し悪しを決める
実際の質問と、その答えが載っている正解文書の組を数十から数百件そろえ、上位に正解が入る割合（＝ヒット率）を測る。チャンクの大きさを変えたら、この数字が上がったか下がったかで判断する。担当者の「なんとなく良くなった」は、設定変更が三回重なると当てにならない。通常のソフト開発で回帰テスト（＝変更で既存の動作が壊れていないかの確認）が定着した経緯と同じ道筋である。
再インデックスは本番障害の入り口になる
見落とされやすいのは、チャンク設定や埋め込みモデル（＝文章を数値の並びに変える処理）を変えると、索引の作り直しが必要になる点だ。旧索引を上書きすると、作成途中は検索結果が崩れる。ブルーグリーン方式は新旧を並行で動かし、評価に通ってから切り替えるため、いつでも戻せる。データベース移行で培われた作法を、検索基盤にも持ち込む動きと言える。
切らずに構造ごと読ませる別の道もある
一方で、そもそも断片に切る前提を疑う流れもある。当サイトで扱うCorpus2Skillは、文書を事前に整理してスキルの木として持たせ、必要な枝をたどって読む考え方だ。構造を保つという目標は同じでも、実現手段が違う。ただしどちらを選んでも、評価の仕組みがなければ改善は続かない。構造の保持と評価の習慣は、方式を問わず共通の土台になる。
ビジネスへの影響
導入前に評価用の質問集を先に作る
RAGの案件は、ツール選びから始まりがちだ。順序を逆にして、まず現場で実際に出る質問を50件ほど集め、それぞれの正解文書を担当者に指定してもらうとよい。この作業は一日で終わるが、以後のあらゆる設定変更の物差しになる。ベンダー比較でも同じ質問集で試せば、提案資料の印象に左右されなくなる。
版管理と並行稼働を契約や仕様に入れる
外部に委託する場合は、チャンク設定、埋め込みモデル、索引の版を記録すること、切り替え時に旧索引を一定期間残すことを仕様に明記したい。並行稼働には保管と計算の費用が余分にかかるため、見積もり段階で織り込んでおく。後から追加すると、費用の交渉で揉めやすい。
条文や別表を持つ文書から着手する
最初の対象は、条文番号や別表を持つ社内規程、製品仕様書、契約書が向く。構造を保つ効果が見えやすく、ヒット率の改善幅も経営層に説明しやすい。議事録のように構造の薄い文書は後回しでよい。三か月ごとに質問集を更新し、問い合わせログから外れた例を追加していけば、運用そのものが育っていく。