RAGの回答が的外れなら、モデルより先に検索を見直す

検索結果が的外れなら、より大きなモデルを導入する前に、文書がどう読み取られ、どう分割されたかを確かめましょう。表の列が入れ替わっていたり、見出しが本文から切り離されていたりすると、検索や生成の段階でその誤りを補うのは困難です。RAGの品質は、パースから評価までの流れの中で決まります。

この記事は企業向けRAGシリーズの第2回です。第1回ではMarkdownのナレッジベースとツール選びを扱い、ここではパース・チャンク分割・検索を見ていきます。最終回では権限、記憶、セキュリティ、運用コストを取り上げます。

パースで保ちたい文書の構造

PDFからテキストだけを取り出すと、読み順が変わったり、表の行や列が分断されたりすることがあります。契約書の条項番号、マニュアルの見出し、表の列名は、本文と同じくらい重要です。パーサーはファイルからテキストやレイアウトを取り出し、検索システムが扱える形に変換します。

Doclingのように文書のレイアウト分析や表処理に対応するツールはありますが、公開ベンチマークの数値が自社文書での結果を保証するわけではありません。Unstructuredの文書分解ツールやLlamaParseのようなマネージド型パースサービスも比較できますが、公開ライブラリーと有料APIでは機能やデータの処理経路が異なります。代表的なスキャンPDF、複数段組の文書、結合セルを含む表を読み込ませ、抽出結果を原本と照らし合わせてください。表題と行・列の対応関係が保たれているか、ページのヘッダーが本文に何度も混ざっていないかを見ると、実務に役立つ判断ができます。

質問に必要な文脈を含むチャンク

文書全体を一度に検索すると、質問に合う箇所を絞りにくくなります。反対に細かく分けすぎると、回答に必要な条件が切り離されてしまいます。まずMarkdownの見出しや段落の境界を確認しつつ、どの文書にも同じ分割ルールが合うとは限らないと考えましょう。表、リスト、FAQ、方針文書では、それぞれ適切な境界が異なることがあります。

たとえば「出張時の食費の上限はいくらですか」という質問なら、金額だけのチャンクよりも、対象者や例外条件も含むチャンクのほうが役立ちます。見出しの階層をチャンクに加えたり、隣接する段落も一緒に渡したりする方法を試せます。チャンクの大きさや重なりの長さに、どの文書にも通用する正解はありません。実際の質問で根拠が途中で切れていないかを見ながら調整します。LangChainのMarkdownHeaderTextSplitterのように、見出しごとに分けたあと、長いセクションをさらに分割するツールも使えます。チャンクには原本の文書ID、見出しの階層、バージョン、出典の位置も残すと、回答の根拠を追いやすくなります。

語句検索と意味検索を組み合わせる理由

ベクトル検索は、表現が違っても意味の近い文書を見つけるのに役立ちます。一方、社内製品のコード、エラーID、条項番号など、正確な一致が必要な語句はBM25のような語句検索のほうが見つけやすいことがあります。両方を使うハイブリッド検索は、異なる検索シグナルを補い合う選択肢です。ただし、あらゆるコーパスや質問で必ず性能が上がるわけではありません。語句検索だけで十分かどうかも含めて評価しましょう。

二つの検索結果でスコアの範囲が異なる場合は、順位を使って統合するRRF（Reciprocal Rank Fusion）が利用できます。各検索エンジンのスコアを直接そろえるのではなく、その結果が何位にあったかを反映する方法です。どの統合方法がよいかは、質問ごとの正解文書や検索候補の数によって変わります。少数の代表的な質問だけで結論を出さず、よくある質問と難しい質問を合わせた評価セットを作りましょう。

韓国語埋め込みモデルを自社で評価する

韓国語の文書には、助詞や語尾、分かち書きの揺れ、英語の略語や製品名が一緒に現れます。BGE-M3やmultilingual E5のように多言語に対応した公開モデルもあれば、APIで提供される埋め込みもあります。モデルカードにある対応言語や出力次元は候補を絞るための情報であり、自社の検索性能を示す順位表ではありません。商用APIとローカルで動かすモデルでは、費用の仕組み、データ処理方法、運用負荷も比較する必要があります。

質問と正解文書の組を集め、Recall@kやnDCGなどの検索指標を確かめると、関連文書が上位に現れるかを比較できます。Recall@kは正解の根拠が上位k件にどれほど含まれるかを、nDCGは関連性の高い結果が前に並んでいるかを見ます。これに応答時間とリクエスト費用を加え、運用条件を確認しましょう。実際の検索ログから、言い方の異なる同じ質問、社内略語、特定の文書番号を選んでテストすると、モデルカードだけではわからない違いを見つけられます。

韓国語の前処理も慎重に適用しましょう。名詞だけを残したり、ストップワードを一律に除去したりすると、否定や条件、時点を表す語が消えて意味が変わることがあります。形態素解析が役立つコーパスもありますが、原文を保った検索を基準にして、改善するかを確かめてから導入するほうが安全です。

リランキングと文書の鮮度を反映する

最初の検索で関連文書を広く集めたら、リランカーが質問と各文書を照らし合わせて順位を付け直せます。候補が多い場合や、意味の似た文書の優先順位が重要な場合に役立ちますが、モデル呼び出しや計算量も増えます。適用前後で正解文書の順位や回答品質を比べ、実際に効果があるかを確かめましょう。候補数や応答時間がどのシステムでも同じだと想定することはできません。

文書の鮮度も、日付だけで決めないようにしましょう。告知日より施行日、改訂状況、廃止されたかどうかが重要な業務もあります。文書に作成日・有効期間・バージョンなどのメタデータを持たせ、業務のルールに合わせて検索結果へ反映できます。古くても有効な資料を評価セットに含めることも大切です。現行の規程を尋ねる質問と、過去の時点の規程を尋ねる質問も分けましょう。廃止状況や有効期間で候補を先に絞るのか、残った候補に鮮度の重みを付けるのかを分けて考えれば、過去の資料を探す質問への影響を抑えられます。

検索の失敗と生成の失敗を分けて評価する

RAGの回答が誤っていたときは、原因を分けて考えると改善につながります。正解の根拠が候補に含まれていなければ、パース・チャンク分割・検索に問題があるかもしれません。候補に含まれていたのに回答で使われなかったなら、文脈の組み立てや生成に原因がある可能性があります。正解文書と回答に必要な根拠箇所を記録し、各段階で何が選ばれたかを確認しましょう。

一つの性能値だけで導入を決めるのではなく、実際の業務質問で根拠を見つけられるか、誤った回答をどれほど簡単に発見できるかを見てください。文書にユーザーごとの権限を付けたり、会話の記憶を加えたりすると、検索の設計はセキュリティの設計と結びつきます。その境界についてはシリーズ最終回で続けて扱います。