実運用に耐えるRAG——検索、根拠、そして評価

「LLMだと事実誤認するので、社内のドキュメントを検索させて根拠付きで答えさせたい」——ここ数年、私たちが最も多く受け取ったのは、この方向の相談だ。技法自体はRAG（Retrieval-Augmented Generation）と呼ばれる、LLMに検索基盤を組み合わせるパターンで、既に一般的な選択肢になっている。

ただし、動くデモを見せることと、本番運用に耐えるRAGを構築することの間には、また別の距離がある。この記事では、実運用で観測されたつまずきどころと、そこを乗り越えるための設計判断を整理する。

チャンクをどう切るかは、ドキュメント種別で変える

RAGの前段で必要になるのが、原文のチャンク分割（chunking）だ。「一定文字数で切る」だけの実装が広く出回っているが、これは多くの場合、検索品質を大きく損なう。

編集部が観測してきた範囲では、少なくとも次の3種類は別々に扱う価値がある。契約書や規約のような構造化された文書は、条項単位で切る。技術ドキュメントは見出し単位で、コード例は分割せず1チャンクとして扱う。会議録や自由記述の議事メモは、話題の切り替わり（トピックシフト）を検知して切る。同じ「切る」でも、必要な粒度が違う。

キーワード検索を捨てない

ベクトル検索は意味的な近さを取れるが、固有名詞・型番・製品コードのような「まったく同じ文字列」を確実に引くのが苦手だ。純粋なベクトル検索だけに寄せた実装は、「AW-100Xの取扱説明書を出せ」で見当違いのドキュメントを返しがちになる。

この失敗パターンを避けるためには、キーワード検索（BM25等）とベクトル検索を並行して走らせるハイブリッド検索が有効になる。両方の結果をリランキングモデル（例：Cohere RerankやBGE-Reranker系）で並べ直すと、単一手法よりも上位K件の妥当性が明らかに上がる、というのが複数の運用チームからの一致した観測だ。

引用可能性を、最初から設計する

本番のRAGでよく問われるのは、「その回答は、どの原文のどこから来たのか」だ。この情報を返せない検索は、社内でも信用されない。

チャンクにIDを振り、原文のパス・ページ番号・行番号などのメタデータを検索結果と一緒に返す設計にしておく。LLMが根拠として使ったチャンクをUIに引用表示できるようにしておけば、間違いの検証コストが劇的に下がる。「答えは合っている、根拠は違う」ケースも意外と多い。

評価はゴールデンQAセットで

RAGの改善は、しばしば「直近で目についた問題」を直すことに集中しがちだ。しかしインデックスやチャンク分割を触ると、他の質問の品質が下がることがある。

編集部が推奨するのは、代表的な質問と正解のペアを50〜200件用意したゴールデンQAセットを最初に作ることだ。評価と成果の測定に関する別記事でも触れたが、改善のたびにこのセット全体で評価し、平均正解率・平均引用率・応答時間の推移を記録する。すべてを人手で採点する必要はない。「答えの中に指定のキーワードが含まれているか」「引用元が正解の文書か」など、機械採点可能な軸だけでもかなり実用になる。

もっとも、RAGですべては解けない

ただし、RAG構成が万能ではないケースもある。集計や比較のように、複数のドキュメントをまたぐ演算が必要な質問には弱い。「先月の相談件数を業種別に集計して」のような質問は、RAGよりも先にデータベースクエリを組んだほうが良い。文書検索と構造化データ問い合わせを併用する設計（agent + tools）が、業務全体としては現実的なことが多い。

参考にした一次資料

• Lewis, P. et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” arXiv:2005.11401.
• Robertson, S., Zaragoza, H. “The Probabilistic Relevance Framework: BM25 and Beyond.” Foundations and Trends in Information Retrieval, 2009.

関連する話題として、ベクトルデータベース選定の比較記事と、LLM出力の評価に関する記事もあわせてお読みください。