RAG の PoC は動いた。しかし本番環境にデプロイした途端、精度が落ち、ユーザーから「使えない」と言われる——このパターンに心当たりがあるなら、本記事はそのギャップを埋めるために書いた。Dense ベクトル検索と BM25 を組み合わせた Hybrid 検索で検索精度を 15〜30% 引き上げ、Agentic RAG でクエリの意図に応じた動的な検索パイプラインを構築する方法を、実装パターンと評価指標の設計まで含めてステップバイステップで解説する。当社がラオス語 RAG チャットボットを構築した際に直面した低リソース言語特有の課題も交えながら、PoC から本番への移行で必要な設計判断を整理していく。

PoC 環境と本番環境の間には、データの質・量・多様性という根本的な違いがある。PoC では「うまくいくデータ」で検証するが、本番では想定外のクエリが大量に飛んでくる。このセクションでは、精度ギャップの構造を分解する。

1つ目はデータの均質性だ。PoC では整形済みの社内文書を数十〜数百件でテストする。しかし本番では PDF、Markdown、HTML、議事録、チャットログなど形式もトーンもバラバラなドキュメントが数万件規模で流れ込む。チャンキングの境界がずれるだけで、回答に必要なコンテキストが欠落する。

2つ目はクエリの多様性。PoC のテストクエリは開発者が書いた「正解があるとわかっている質問」に偏る。本番ユーザーは曖昧な質問、複合的な質問、さらには RAG の守備範囲外の質問も投げてくる。

3つ目は評価の不在。PoC では「なんとなく良さそう」で通ってしまうが、本番では精度の定量指標がなければ劣化に気づけない。当社がラオス語 RAG を構築した際も、PoC では英語ドキュメントの翻訳テストだけで精度を確認していたが、実際のラオス語ユーザーのクエリは口語表現や方言を含み、PoC 時のスコアとは別物だった。

精度劣化は大きく3つのレイヤーで発生する。

検索レイヤーでは、Dense 検索単体の限界が露呈する。専門用語や固有名詞は Embedding 空間で近傍に配置されないことがあり、意味的には関連するドキュメントを取りこぼす。逆に、表面的に類似したが文脈の異なるチャンクを上位に返してしまうケースもある。

チャンキングレイヤーでは、固定長分割による情報の断裂が問題になる。表やリストの途中で切れる、前後の文脈がないと意味が取れないチャンクが生まれる。

生成レイヤーでは、検索結果の質が低いまま LLM に渡すことで、ハルシネーションや的外れな回答が増える。検索精度が悪ければ、どれだけ高性能な LLM を使っても出力は改善しない。RAG の精度はまず検索で決まる。

本記事の手順を実装するにあたり、必要な環境と知識を整理する。

pgvector + PostgreSQL の構成はスモールスタートに向いている。当社のラオス語 RAG でもまず pgvector で始め、スケールに応じて専用ベクトルDBへの移行を検討するアプローチを取った。

以下を理解していれば、本記事の手順をスムーズに進められる。

• ベクトル検索の基本概念（Embedding、コサイン類似度、ANN）
• BM25 の仕組み（TF-IDF ベースのスコアリング）
• LLM の API 呼び出し（プロンプト設計、トークン管理）
• RAG の基本フロー（検索→コンテキスト注入→生成）

これらに不安がある場合は、まずラオス語AIチャットボットのRAGガイドで基礎を押さえることを推奨する。

チャンキングは RAG 精度の土台だ。PoC の「とりあえず500トークンで分割」から脱却し、ドキュメントの構造に合わせた戦略を設計する。

チャンクサイズには万能の正解がない。ただし、実務上の指針はある。

• 短いチャンク（200〜400トークン）: 検索精度が上がるが、コンテキストが不足しやすい。FAQ や定義集に向く
• 長いチャンク（800〜1200トークン）: コンテキストが豊富だが、ノイズも増える。技術文書や契約書に向く
• 重複（overlap）: チャンク間で 10〜20% 重複させることで、境界での情報欠落を緩和する

筆者の経験では、まず 400 トークン・overlap 50 トークンで始め、評価指標を見ながら調整するのが最も効率的だった。最初から最適値を決めようとして2週間消費したプロジェクトも見てきたが、評価パイプラインがない段階でのチューニングは時間の無駄になる。

本番 RAG の精度を大きく左右するのが、チャンクへのメタデータ付与だ。

メタデータによるプレフィルタリングを実装すると、検索対象を絞り込んでから Dense/BM25 検索を実行できる。「情報セキュリティに関する最新の社内規程」というクエリなら、document_type = "policy" かつ section LIKE '%セキュリティ%' でフィルタした後に検索するほうが、全チャンクを対象にするより圧倒的に精度が高い。

当社がラオス語 RAG チャットボットを構築した際、チャンキングで最も苦労したのは単語境界の検出だった。ラオス語はタイ語と同様にスペースで単語を区切らない言語であり、英語向けのトークナイザーではチャンク境界が文の途中で切れてしまう。

最終的に、ラオス語の文区切り記号（。に相当する記号）をプライマリ区切りとし、バイト長でセカンダリ区切りを入れるカスタムスプリッターを実装した。この対応だけで、検索精度（Hit Rate@5）が 0.42 から 0.61 に改善した。低リソース言語では、汎用のチャンキングライブラリをそのまま使うと精度が出ない。言語固有の前処理が本番品質の前提条件になる。

Dense ベクトル検索は意味的な類似性に強いが、固有名詞やキーワードの完全一致には弱い。BM25 はその逆だ。両者を組み合わせる Hybrid 検索は、単体検索に対して 15〜30% の精度向上が複数のベンチマークで報告されている。

実務で最も効果を感じるのは、ユーザーが製品コードや条文番号など固有の識別子を含むクエリを投げたときだ。Dense 検索だけでは「製品コード ABC-1234 の仕様」を取りこぼすことがあるが、BM25 が正確にヒットさせる。一方、「去年のセキュリティインシデントの対応方針に似た文書」のような曖昧なクエリでは Dense 検索が力を発揮する。

Hybrid 検索のスコア統合には主に2つの方式がある。

**Reciprocal Rank Fusion（RRF）**は、各検索結果の順位のみを使ってスコアを統合する。スコアの正規化が不要で、異なるスコア分布を持つ検索エンジンを組み合わせやすい。

k は通常 60 に設定される。このシンプルさが RRF の強みで、チューニングパラメータが少ないぶん安定した結果が得られる。

重み付き線形結合は、各スコアを正規化してから加重平均を取る。

α を 0.7 程度に設定（Dense を重視）するケースが多いが、ドメインやクエリタイプによって最適値が変わる。評価パイプラインで α をグリッドサーチして決めるのが現実的だ。

筆者の推奨は、まず RRF で実装して精度のベースラインを作り、精度改善の余地がある場合に重み付き線形結合への移行を検討するアプローチだ。最初から α のチューニングに時間を使うのは、評価データが十分に溜まってからでいい。

pgvector + pg_bigm を使った PostgreSQL 完結型の Hybrid 検索は、インフラ構成がシンプルで運用コストが低い。

RRF でスコアを統合し、上位 5〜10 件を LLM に渡す。当社の社内ベンチマークでは、Dense 単体の Hit Rate@5 が 0.72 だったのに対し、Hybrid（RRF）で 0.87 まで改善した。特に固有名詞を含むクエリでの改善幅が大きく、0.58 → 0.84 と劇的に向上した。

従来の RAG は「クエリ → 検索 → 生成」の固定パイプラインだ。Agentic RAG はこれを拡張し、LLM エージェントが検索戦略を動的に判断する。Gartner が注目トレンドとして認定したこのアプローチは、複雑なクエリに対する精度を大幅に引き上げる。

従来の RAG（Naive RAG）では、ユーザーのクエリがそのまま検索クエリになる。しかし「昨年度のセキュリティインシデント対応と今年度の予防策を比較して」のような複合クエリは、1回の検索では必要な情報を網羅できない。

Agentic RAG では、LLM エージェントが以下の判断を自律的に行う。

• クエリ分解: 複合クエリを複数のサブクエリに分割
• 検索戦略選択: サブクエリごとに Dense / BM25 / メタデータフィルタのどれを使うか判断
• 結果評価: 検索結果が十分かを評価し、不足なら再検索
• 回答合成: 複数の検索結果を統合して最終回答を生成

これは単なる技術的な改善ではなく、RAG のアーキテクチャパラダイムの転換だ。検索パイプラインが「プログラムで固定するもの」から「エージェントが状況に応じて構成するもの」に変わる。

Agentic RAG のエージェントには、以下のツールを持たせる。

ツール設計で重要なのは、各ツールの description を具体的に書くことだ。エージェントは description を読んでツールを選択するため、曖昧な記述だと誤ったツール選択が頻発する。「検索する」ではなく「Dense + BM25 の Hybrid 検索を実行し、関連度スコア付きのチャンクリストを返す」のように書く。

実際の Agentic RAG のフローを示す。

ユーザー: 「ISO 27001 の管理策のうち、
          当社が未対応のものをリストアップして」

エージェント思考:
  1. ISO 27001 の管理策一覧が必要
     → metadata_filter(doc_type="standard", title="ISO 27001")
  2. 当社の対応状況が必要
     → hybrid_search("情報セキュリティ 対応状況 管理策")
  3. 検索結果を突合して未対応を特定
     → summarize_results(chunks, original_query)
  4. 結果が不十分（対応状況が一部しか見つからない）
     → refine_query("部署別セキュリティ対策 実施状況 報告書")
  5. 追加結果を統合して最終回答を生成

このように、Agentic RAG は1つのクエリに対して複数回の検索と評価を自律的に繰り返す。PoC の固定パイプラインでは「ISO 27001 未対応 管理策」で1回検索して終わりだったところを、文脈に応じた多段階の検索に拡張できる。

ただし、マルチステップ推論はレイテンシとコストが増加する。本番ではステップ数の上限（3〜5 回）を設定し、タイムアウト（30 秒など）を設けることが不可欠だ。

本番 RAG の最大の課題は「精度が劣化しても気づけない」ことだ。評価パイプラインを CI/CD に組み込むことで、デプロイ前に精度劣化を検知する仕組みを作る。

RAG の評価指標は、検索と生成の両面をカバーする必要がある。

筆者が最も重視するのは Faithfulness だ。エンタープライズ用途では、ハルシネーション（事実と異なる回答）が最大のリスクであり、ユーザーの信頼を一瞬で失う。Faithfulness が 0.95 を下回ったらデプロイをブロックする、というルールを設けている。

Ragas や DeepEval を使えば、評価パイプラインを比較的短期間で構築できる。

テストデータセットの作成が最も工数がかかる。PoC で使ったテストケースに加え、本番ログから「回答品質が低かった」とユーザーがフィードバックしたケースを継続的に追加していく。最低 100 件、理想的には 500 件以上のテストケースがあると、統計的に信頼できる評価になる。

CI/CD に組み込む際のポイントは、閾値ベースのゲートを設けることだ。

• PR マージゲート: Faithfulness < 0.95 または Context Relevance < 0.80 ならマージをブロック
• 定期バッチ評価: 日次で本番データのサンプルに対して評価を実行
• アラート: 指標が前週比で 5% 以上低下したら Slack 通知

当社では HITL（Human-in-the-Loop）の仕組みと組み合わせ、自動評価で閾値を下回ったケースを人間がレビューするフローを構築している。自動評価は万能ではないが、劣化の早期検知という点では人間だけのレビューより圧倒的に速い。

PoC → 本番の移行で繰り返し見てきた失敗パターンを3つ紹介する。

英語のベンチマークスコアだけで Embedding モデルを選び、日本語や多言語のドキュメントで精度が出ないケースが多い。当社のラオス語 RAG では、OpenAI の text-embedding-3-large が英語では優秀だったが、ラオス語では Cohere の多言語モデルのほうが Hit Rate で 12 ポイント高かった。

対処法: 自社のドメインデータで必ずベンチマークを取る。公開ベンチマーク（MTEB 等）はあくまで参考値であり、ドメイン固有の用語が多い場合は順位が大きく変わる。

Hybrid 検索の後にリランカー（Cross-Encoder）を挟むと、さらに 5〜15% の精度向上が見込める。しかし「Hybrid だけで十分」と判断し、精度が頭打ちになるプロジェクトがある。

リランカーは検索結果の上位 20〜50 件をクエリとペアで再スコアリングするモデルだ。Bi-Encoder（Embedding）より計算コストが高いが、精度は圧倒的に高い。Cohere Rerank や bge-reranker-v2 が実用的な選択肢になる。

対処法: Hybrid 検索 → リランカー → 上位 5 件を LLM に渡す、という3段パイプラインを標準構成にする。レイテンシの増加は 100〜300ms 程度であり、エンタープライズ用途では許容範囲だ。

検索精度を上げるために大量のチャンクを LLM に渡し始めると、トークン消費が急増する。10 チャンク × 500 トークン = 5,000 トークンのコンテキストは、1リクエストあたりのコストを数セント単位で押し上げ、月間数千ドルの差になる。

対処法: リランカーで上位を厳選し、LLM に渡すチャンクは 3〜5 件に制限する。また、チャンクの要約（Abstractive Summarization）を検索パイプライン内で実行し、トークン数を圧縮する方法も有効だ。コスト最適化は精度チューニングと同時に進める必要がある。

ドメインとデータ特性に依存するが、Dense 単体に比べて Hit Rate@5 で 15〜30% の改善が複数の学術論文および当社の実測で確認されている。特に固有名詞や数値を含むクエリでの改善幅が大きい。ただし、すべてのクエリタイプで均等に改善するわけではなく、意味的に曖昧なクエリでは Dense 単体とほぼ同等の場合もある。

なる。従来の RAG が 1〜3 秒で回答するところ、Agentic RAG は 5〜15 秒かかることがある。対策としては、ストリーミングレスポンスで体感待ち時間を短縮する、ステップ数に上限を設ける、クエリの複雑度を事前判定して単純なクエリは Naive RAG にルーティングする、といった設計が現実的だ。すべてのクエリを Agentic にする必要はない。

実用的だが、追加の工夫が必要だ。当社のラオス語 RAG の経験から言えるのは、Embedding モデルの選定（多言語対応モデル必須）、チャンキングの言語対応（単語境界の検出）、評価データの整備（人手によるアノテーション）の3点が特に重要ということだ。汎用ツールをそのまま使って「精度が出ない」と諦める前に、言語固有の前処理を試す価値がある。詳しくはラオス語AIチャットボットの構築ガイドを参照いただきたい。

PoC から本番への移行で確認すべき設計判断を整理する。

• チャンキングはドメインと言語に最適化されているか？ 固定長分割で妥協していないか？
• Dense 検索だけでなく BM25 との Hybrid 検索を実装しているか？
• リランカーで検索結果を再スコアリングしているか？
• 複合クエリに対して Agentic RAG の導入を検討したか？
• Faithfulness / Context Relevance の評価パイプラインが CI/CD に組み込まれているか？
• コスト（トークン消費）のモニタリングとアラートが設定されているか？

RAG の本番化は、1つの技術で解決する問題ではない。チャンキング、検索、リランキング、生成、評価の各レイヤーで適切な設計判断を積み重ねることで、PoC と本番の精度ギャップを埋められる。まずは Hybrid 検索と評価パイプラインの導入から始め、クエリの複雑度に応じて Agentic RAG への拡張を進めていくのが、最も堅実なアプローチだ。