RAGのチュートリアルの多くは、デモを見せて終わりです。トークン数でチャンク化し、すべてをベクトルデータベースに詰め込んで、それで完了。クリーンなFAQに対して「返品ポリシーは何ですか？」と質問される程度なら、それで機能するでしょう。しかし、誰かが契約書の半分を貼り付けて「第3条について教えて」と尋ねたり、開発者がドキュメント検索に難解なエラーコードを入力したりすると、その手法は破綻します。
固定のトークンウィンドウでは、法的合意書が文章の途中で切れてしまいます。大きなチャンクは、APIリファレンスを大量のノイズの中に埋もれさせてしまいます。最悪なのは、検索が遅いために、モデルが生成を開始する前にユーザーがクエリを諦めてしまうことです。私たちはこれを身をもって学びました。検索レイヤーを「期待」から「測定」へと移行したとき、レイテンシを40%削減し、再現率（recall）を95%まで向上させることができました。具体的に何を変えたのかを以下に示します。
スマート・チャンキング
チャンクサイズを「魔法の数字」として考えるのはやめましょう。単一の条項が複数の段落にわたるような法的文書において、512トークンのウィンドウは意味をなしません。同様に、関数のシグネチャとその2行の説明がセットであるべきAPIドキュメントにおいても、それは役に立ちません。私たちは「構造を意識した分割（structure-aware splitting）」に切り替えました。
法的文書の場合、再帰的チャンキング（recursive chunking）を用いることで文書の階層構造を尊重し、条項を壊さずに保持できます。APIドキュメントには、シグネチャ、パラメータ、および例を一つの最小単位として保持する「関数認識型分割（function-aware splitting）」を使用しています。サポートチケットや会話データには意味的な境界が必要であり、任意の文字数ではなく、トピックが切り替わる場所で分割する必要があります。その結果、各チャンクは有用な文脈を十分に持ちつつ、信号を希釈してしまうほど過剰な情報を含まない状態になりました。埋め込みモデルの注意（attention）の予算には限りがあります。賢く使いましょう。
ハイブリッド検索
ベクトル検索は、概念的に類似したコンテンツを見つけることに長けています。「データベースのクエリが遅い」と尋ねれば、パフォーマンスチューニングのガイドを提示してくれます。しかし、「Error 0x80070057」と尋ねると、高密度な埋め込み（dense embeddings）は完全一致をうまく扱えないため、意味検索は無関係な領域へと漂流してしまいます。一方でBM25は、完全一致する文字列や稀な用語を正確に捉えますが、「レイテンシ」と「応答時間の遅延」が同じ意味であることを理解していません。
私たちはこれら両方を並列で実行し、Reciprocal Rank Fusion (RRF) でマージしています。RRFはシンプルかつ効果的です。各手法によるランク付けされたリストを受け取り、その順位に基づいてドキュメントをスコアリングすることで、どちらのシステムからの有力な候補にも公平なチャンスを与えます。マージ後、結合された結果に対してクロスエンコーダー・リランカー（cross-encoder reranker）を実行し、上位5件のみを返します。リランカーによって約50ミリ秒のレイテンシが増加しますが、再現率は15%向上しました。このトレードオフは、生成の品質向上によって何度も元が取れるものです。
クエリ拡張
ユーザーのクエリは必ずしも正確ではありません。略語を使ったり、綴りを間違えたり、あるいは一つの長い文章の中に3つの質問を詰め込んだりします。ユーザーが入力した通りに検索してしまうと、彼らが本当に必要としているドキュメントを見逃してしまいます。
現在では、クエリがインデックスに到達する前に、すべてのクエリを変換しています。まず、類義語や異なる言い回しをカバーするために、元の質問の言い換えバージョンを複数生成します。次に、複雑な質問を小さなサブクエリへと分解します。「海外の顧客に対して返金が失敗する理由と、その修正方法は？」というクエリは、「海外への返金失敗について」と「修正手順について」という2つの明確な検索に分解されます。クエリ拡張だけで、再現率は78%から94%へと向上しました。教訓は単純です。ユーザーの最初のドラフトを鵜呑みにせず、彼らを助けてあげましょう。
推測をやめ、検索を始めよう
チャンクサイズ、オーバーラップの割合、top-kのカットオフ、リランカーの深さといったパラメータは、手動で調整するには複雑すぎる方法で相互に影響し合います。私たちは、一貫性を損なっていたオーバーラップ設定を無視したまま、256トークンと512トークンのどちらが良いかといった議論に、あまりにも多くの時間を費やしてしまいました。
私たちは直感に頼るのをやめ、ベイズ最適化（Bayesian optimization）を導入しました。明らかに効率の悪い領域に計算リソースを浪費するグリッドサーチの代わりに、ベイズ法は「何が機能するか」の確率モデルを構築し、レイテンシを最小限に抑えつつ再現率を最大化するパレートの境界（Pareto frontier）を積極的に探索します。私たちのスタックにおいて、これはレイテンシの予算をオーバーすることなく、再現率95%を実現するチャンクサイズ、オーバーラップ、top-kの特定の組み合わせを見つけ出すことを意味しました。ユースケースによって、その境界上の異なる地点に設定が落ち着きます。顧客向けのチャットボットは速度を優先し、社内の法務リサーチは再現率を優先します。自動最適化により、設定ファイルをいちいち手動でコピー＆ペーストすることなく、両方のニーズに応えることが可能になりました。
結果
数字は明白に物語っています。Recall@10は78%から95%へと上昇しました。p95レイテンシは850ミリ秒から320ミリ秒へと低下しました。そして、モデルがノイズではなくようやく関連性の高いコンテキストを受け取れるようになったことで、ハルシネーション率は12%から3%へと減少しました。検索の精度向上は、単に回答を速くするだけではありません。回答を「真実」にするのです。
次に行うべきこと
検索レイヤーを再構築する場合は、ここから始めてください：
- トークン数ではなく、ドキュメントの構造に基づいてチャンク分割を行う。 分割戦略をデータの形状に合わせます。
- ハイブリッド検索を活用する。 ベクトル検索とBM25を組み合わせ、Reciprocal Rank Fusionでマージし、生成前にリランクを行います。
- クエリを拡張してカバレッジを高める。 検索を実行する前に、言い換えや分解を行います。
- テスト用のゴールデンデータセットを構築する。 測定できないものは最適化できません。
- 自動化ツールでパラメータを最適化する。 ベイズ探索は、勘よりも優れた設定を見つけ出してくれます。
検索は、一度設定したら終わりというような設定ファイルではありません。それはインフラストラクチャであり、インフラにはプロダクションコードと同様の厳格さ、すなわちテスト、測定、そして継続的な最適化が求められます。そのように扱うことで、あなたのRAGシステムは単なるデモから、真のプロダクトへと進化します。
オプションの学習コミュニティ: GyaanSetu AI