RAGの精度改善｜文書検索からAgentic RAGへ、設計と評価・運用の順番

RAGを入れたのに、思ったほど賢くならない。社内のマニュアルやPDFを検索させているのに、型番で外したり、集計に答えられなかったりする。もっと文書を増やせばいいのか、別の仕組みが必要なのか。
原因を全部AIの賢さの問題として扱うと、直す場所を見失います。記事を書いた筆者自身、最初は社内のPDFを片っ端から入れただけで、古い答えが返っているのに気づかず使えるつもりになっていたそう。この回は、業務を決めて、検索を強くして、必要な戦略を選び、評価しながら育てる——RAGをどう作るかという設計の順番の話です。

RAGの要点は、知識を全部覚えさせることではなく、答えるその場で必要な資料を渡すこと。記事は「持ち込み禁止の試験を持ち込み可に変える」ことに例えています。流れは検索・拡張・生成。意味の近い文書を探すベクトル検索は部品で、RAGはそれを使って答えまで作る全体。関係のない文書を渡せばAIはその文書をもとに答えてしまうので、答え方の指示を何度直しても、根拠が届いていなければ直りません。答え方の型や口調を固めるファインチューニングとは得意な役割が違い、併用もできます。
検索が外れるとき、最初に疑うのは文書をどこで区切っているか。長い文書を検索できる単位に切り分けたものがチャンクで、小さすぎれば文脈が欠け、大きすぎれば聞いていない内容まで混ざる。見出し単位で切り、見出しの文言も一緒に入れ、部署や日付などの属性で絞れるようにする。
その土台を整えたら、同じ文書検索を二段構えで強くします。一段目はハイブリッド検索。意味検索は言い回しが違っても近い内容を探せる一方、XR-200という型番を探したいのに意味の近い別の型番を拾うことがある。キーワード検索は型番や固有名詞をその語の一致で拾える。両方で候補を探して混ぜる。二段目はリランキングで、候補をやや多めに集めてから専用のモデルで読み直し、本当に関係の高い順へ並べ替える——ざっと集める司書と精読する司書を分けるイメージです。AIへ渡す資料は多ければいいわけではなく、件数と文字数の上限も決める。そして「検索で正解の文書を拾えているか」と「拾った資料の範囲で答えているか」は分けて見ます。

社内の知識は全部が文章の形をしているわけではない。記事は表のデータ、文書、つながりに分けます。「先月の東京エリアの売上合計はいくらか」は似た文章を探す質問ではなく、条件に合う台帳を正確に足し算する仕事で、人の質問をAIがSQLに翻訳するtext-to-SQLの出番。「配送遅延のときの返金ポリシーは」は文書への問い。「この機能を止めたらどこに影響が出るか」はつながりをたどる問いで、点と点の関係を持つグラフが向く——ただしグラフは、関係を何段もたどる必要が本当にあるときに道具として足せばいい。
問いの性質ごとに検索戦略を使い分ける設計を、記事は多面的RAGと呼びます。ここで、知識の種類が分かれるからデータベースも別々に必要とは考えないこと。PostgreSQLにpgvectorを加えれば、SQLの集計とベクトル検索を同じデータベースで扱える。大事なのは箱の数ではなく、問いに合った探し方を選べることです。既知の関係をたどるグラフと、文書から関係を描き起こして俯瞰するGraphRAGも目的が違います。
現実の問いは「顧客Aに去年提案した内容と近いものをもう一度出したい」のように、顧客の特定、去年の提案の検索、似た案件のつながりが混ざっている。そこで問いを小さく分けてどの検索を使うかを選ぶ交通整理をエージェントに任せる。Agentic RAGは振り分けだけでなく、分解し、選び、足りなければ取り直し、根拠で答えられるかを点検するところまでを含みます。人が資料を調べるときに探し直し、答えを見返す手続きを仕組みにするわけで、確率でなんとなく賢くなる話ではない。SQLの集計のように答えが定まる処理は、確実な関数処理の側に残します。

検証では手応えがあったのに業務で使うところまで進まない理由として、記事は精度だけでなく、作ってからの設計を後回しにする問題を挙げます。新しいマニュアルが増え古い規程が廃止されても、検索される側がそのままなら、RAGは自信を持って古い正解を返し続ける。誰がどの文書をどの頻度で入れ直すのかを決め、元の保管場所の更新を検知して自動で入れ直す仕組みも最初から組んでおく。
良くなったかは「触った感じで便利になった」ではなく、同じ質問に答えられるかを繰り返し測る。検索の評価では正解の文書が候補に入ったか、生成の評価では渡された資料の範囲で答えたか。この区別が改善する場所につながります。準備として、利用部門に実際に聞きたい質問を30件書き出してもらう。作る側が考えた質問は答えやすいものに寄りがちだからです。データも入れる前に、古い版と現行版の混在、重複、画像だけのPDF、誰が見てよいかの区別を確認する。見てよい人だけが見られる状態は検索の段階で守る——答えを書くときに隠そうとしても、検索で取り出せた時点でAIに渡っているからです。
知識源に該当する情報がないときは「見つかりませんでした」と返せるようにし、それらしい答えで穴を埋めない。答えられなかった質問は失敗として捨てずに記録すれば、資料に何が足りないかの手がかりになり、想定質問の一覧を育てる材料になる。始める範囲は特定の部署と業務に絞り、何に答えられたら合格かを先に決める。応答件数と解決は同じではないので、ヘルプデスクなら解決率を見る。使ってもらうにはいま使っているチャットや検索窓の中に置く。外部に頼むなら構築の実績だけでなく評価の方法を持っているかを見て、運用と更新を誰が持つかを決めます。

業務を決め、検索を強くし、必要な戦略を選んで、評価しながら育てる。道具の数から考えないこと。文書を入れただけで頭打ちなら、まずは切り方と検索を見直し、道具を増やす判断は結果を測ったあとに置く。運用までが設計です。誰かを責める話ではなく、改善の順番の話として——RAGの構成要素や導入の進め方、チャンクの切り方は元記事にさらに詳しく整理されています。