RAG（検索拡張生成）パイプラインをJupyter notebookからライブサービスへと移行して4ヶ月、著者は、単なるデモをユーザーが実際に信頼できるシステムへと変貌させた5つの具体的な選択肢を特定した。その差は数字に表れている。テキストの分割方法を少し変えただけで、検索ヒット率は61%から83%に向上し、200件の実クエリを用いたささやかな評価セットにより、顧客に届く前にほとんどのリグレッションを検知できるようになった。

なぜ重要なのか

RAGのデモは印象的に見える。数秒で一節を抽出し、もっともらしい回答を生成するからだ。しかし本番環境では、同じアプローチでも古い事実を返したり、エラーコードを見逃したり、文章が壊れていたりすることが多く、ユーザーの信頼を損なう。ボトルネックが言語モデルであることは稀であり、問題はコンテンツの取り込み（ingestion）、インデックス作成、および提供（serving）の仕方にあります。パイプラインを正しく構築できるかどうかが、価値を生む製品になるか、負債になるかの分かれ目となる。

1. 固定サイズのチャンクの使用をやめる

多くのプロトタイプは、すべてのドキュメントを512トークンのブロックに分割している。これは短いテキストには有効だが、技術マニュアルやサポートのスレッド、コードスニペットを断片化させてしまう。文章が分断され、見出しが消え、検索エンジンがユーザーの期待するコンテキストを一致させることができなくなる。

構造を意識したチャンキング（見出し、会話の境界、またはコードフェンスで分割する）に切り替え、意味的な単位を保持すること。著者のシステムでは、これだけで関連する一節が見つかるクエリの割合が61%から83%に上昇した。この改善はデータ形式の変更によるものであり、基盤となるモデルは同じままである。

2. ハイブリッド検索を利用する

純粋なベクトル検索（埋め込みベースの類似性）は、同じ意味を持つ一節を見つけることには長けているが、エラーコード、バージョン番号、独自の専門用語といった正確な識別子にはつまずく。例えば「ERR-XXXX」のようなエラーコードを探しているユーザーに対し、意味は似ているがコードが含まれていない段落を返してしまうことがある。

ハイブリッド検索は、密ベクトルインデックスと従来のBM25インデックス（単語頻度ベース）を組み合わせる。これら2つのスコアに重み付けを行うことで、意味的に近く、かつユーザーが入力した正確な用語を含むアイテムを検索できる。本番環境において、ハイブリッド検索は「あれば便利な機能」ではなく、「必須の要件」である。

3. 古いデータを扱う

古くなった価格表、ポリシー文書、ファームウェアのリリースノートなどは、一瞬にして信頼性を失墜させる。インデックスの鮮度を保つための3つの実用的なステップは以下の通りである：

  • すべてのドキュメントにバージョンスタンプまたはタイムスタンプを付与する。
  • スコアリング時に「新しさ（recency）」によるブーストを適用し、新しいアイテムが古いコピーよりも上位に来るようにする。
  • 夜間に増分再インデックスを実行し、ソースシステムからの変更を取り込む。

これらの保護策により、前四半期まで有効だった価格や、すでに置き換えられたポリシーが提供されるのを防ぐことができる。

4. モデルのアップグレードではなくリランクを行う

埋め込みモデルをアップグレードしても品質の向上はわずかだが、クロスエンコーダーによるリランカーを追加すれば、より少ないコストで大幅な品質向上を実現できる。

本番のフローでは、まずハイブリッド検索を使用して20個の安価な候補を取得し、次にそれらをリランカーに通して上位5個を選択する。この2段階のアプローチにより、モデル全体をアップグレードするコストのわずかな一部で、より大きな品質の飛躍が得られる。

5. 実践的な評価セットを構築する

測定できないものは改善できない。著者は、専門家が作成した回答とペアになった200件の実際のユーザークエリからなるテストスイートを構築した。すべてのコード変更はこのスイートに対して実行され、リグレッションはデプロイ前に検知される。

ユーザーから誤った回答の報告があった場合は、すぐにそのクエリを評価セットに追加し、現実世界の失敗を将来の保護策へと変える。生成されたすべての回答を継続的にログに記録することで評価ループにフィードバックし、システムを実際の利用状況に適合させ続ける。

実践的な本番パイプライン

  • Ingest（取り込み）: 構造を意識したチャンキングにより、見出し、コードブロック、会話のターンを保持する。
  • Index（インデックス作成）: 密ベクトル埋め込みとBM25の単語統計の両方を保存する。
  • Retrieve（検索）: ハイブリッド検索により、意味的な類似性と正確な用語の一致のバランスを取りながら、20個の候補を返す。
  • Rerank（リランク）: クロスエンコーダーがリストを最も有望な5つの段落に絞り込む。
  • Generate（生成）: LLMは、最終的な回答を作成するために、これらの上位チャンクとそのメタデータを受け取る。
  • Evaluate（評価）: すべてのレスポンスをログに記録し、失敗したものは200件のクエリテストセットにフィードバックされる。

リスクとトレードオフ

適切に調整されたパイプラインは、ハルシネーションを抑制し、回答の関連性を向上させ、過剰なスペックのモデルを使用するコストを削減します。そのメリットは、ユーザー満足度の向上とサポートコストの低減です。これらのステップを軽視すると、ブランドの信頼を損ない、多大なコストを要する火消し作業を強いるような、脆弱なサービスを生み出すことになります。

今後の注目点

オープンソースのembeddingsやベクトルデータベースが成熟するにつれ、「dense（密）」な検索と「sparse（疎）」な検索の境界は曖昧になっていくでしょう。しかし、セマンティック検索と完全一致検索を組み合わせるという原則は変わりません。

要点: RAGシステムにおいて、言語モデルがボトルネックになることは稀です。真の課題は、基盤となるコンテンツをどのように分割し、インデックス化し、提示するかという点にあります。これらの決定を正しく行うことで、見栄えの良いデモを信頼できる製品へと変えることができるのです。