第3章 — 検索拡張生成 (RAG)

LLM Primer V: 実運用のLLMアプリケーションを設計する を章ごとに紹介していくウォークスルー、第3回。RAGパイプラインを端から端まで歩き、お気に入りの10文書で動くデモと、実運用のコーパスに耐えるシステムを分ける回です。

なぜこの章があるのか

基盤モデルは、訓練コーパスが見せたもの以上のことは知りません。作っているプロダクトは、まず間違いなく、そのコーパスの外にあるもの — 社内文書、先週のチケット、その顧客の注文履歴、今朝出たばかりのポリシー — についてモデルに考えさせる必要があります。検索拡張生成は、そのギャップを埋める工学的な規律です。クエリ時に、記録の元となるシステムから関係する素材を取ってきて、プロンプトに整形し、モデルにそれを踏まえて生成させる。素朴な版は、埋め込み1回と上位k件のルックアップだけ。本番の版は、チャンキング戦略、クエリ変換、ハイブリッドスコアリング、再ランク、評価ループを備えたパイプラインです。第3章はそのパイプラインを端から端まで歩き、続いてデモパイプラインをデプロイに変える技法を扱います。

ひとことで言うと: RAGは5段のパイプライン — ロード、チャンク、埋め込み、検索、生成 — であり、品質へのほぼすべての苦情は根まで辿るとチャンキングの苦情だと判明する。ハイブリッド検索と再ランクは、本番が収束する形である。

3.1 5段のパイプラインとハイブリッド検索

最小のRAGパイプラインには5つの段があり、それぞれが後から見れば当然な形で相互作用します。ローダーは構造 — 見出し、セクションパス、タイムスタンプ、ソースURL、アクセス制御ラベル — を保存します。以降のすべてはローダーが残したものに依存するからです。チャンカーは、任意のトークン数ではなく、文書の自然な木目に沿って切ります。埋め込みモデルはチャンクを、その幾何がすべて埋め込みモデルの訓練分布で決まる、あるベクトル空間へ射影します。リトリーバーは最近傍を見つけます。ジェネレータは取り出した文脈をつけてプロンプトされ、その枠づけが効きます — 「以下の文脈のみを使って答え、それ以外は『情報を持っていない』と応答してください」は、本番RAGで最も効くハルシネーション低減パターンです。純粋な密検索は言い換えを理解しますが固有識別子を外し、字句検索は識別子を捕らえますが意味を外します。ハイブリッド検索を、Reciprocal Rank Fusionで融合すれば両方の効きが得られ、融合された上位50件へのクロスエンコーダの再ランクが、さらに10〜20%の適合率を買ってきます。

3.2 チャンキングは品質の生死を分ける

「500トークンごとに切り、50トークン重ねる」という既定は、汎用コーパスの意外に大きい割合でうまく動き、専門化されたコーパスのほぼすべてで機能しません。構造的チャンカーは、HTMLやMarkdownを見出しレベルで歩き、末端セクションごとに1チャンクを吐き、先祖見出しのブレッドクラムを接頭辞として付けます。親子チャンカーは、検索精度のために小さな子チャンクを埋め込みますが、ヒットしたらそれを親パラグラフに拡張してからジェネレータに渡し、検索単位と文脈単位を切り離します。セマンティックチャンカーは、文単位の埋め込み列を歩き、話題が転じるところで割ります。合成 — まず構造的、長いセクションの中はセマンティック — で、実運用のコーパスに含まれるほぼすべての情報源に対応できます。そしてどのチャンクにも豊富化されたメタデータ — 出典、URL、タイムスタンプ、見出しパス、言語、可視スコープ — が乗ります。取り出したチャンクを、帰属可能、フィルタ可能、そしてシステムの他の部分から可読なものにするのは、これらのフィールドだからです。

3.3 クエリ変換・マルチモーダル・text-to-SQL

ユーザーのクエリは、検索にとって理想的なクエリであることは稀です。マルチクエリ拡張は、モデルにいくつかの言い換えを求め、それぞれで検索して融合します。HyDE — 仮説的文書埋め込み — は、モデルにもっともらしい答えを作らせ、質問ではなくその答えを埋め込みます。答えは埋め込み空間の質問とは別の領域に住む、という理屈です。Step-backプロンプティングは、質問のより一般化された版を作り、両方に対して検索して、モデルにその枠づけを使って具体ケースを答えさせます。分解は、複合質問をリトリーバーが扱える下位質問群に分けます。反復的検索は、次に何を取るかをモデルに決めさせます — RAGとエージェントの橋になります。RAGはテキストの外へも広がります。CLIP系の画像・テキスト共有埋め込み空間はマルチモーダル検索を支え、text-to-SQLはデータベーススキーマを検索コーパスとして扱い、タイムアウト付きの読み取り専用レプリカにクエリを生成します。クエリごとに適切な変換を選ぶルータが、全部を全部走らせるより勝ります。

覚えておきたいこと: 誤った検索は大声では失敗しない。モデルは間違った文脈から自信ありげな答えを律儀に書き、品質は誰にも気づかれずに削られていく。チューニングの前に、検索段を計測すべし。

この章を踏まえて

RAGは数ある機能の一つに過ぎません。本番のアシスタントが検索だけで生きていることは稀です。顧客の直近の注文を取り、他システムの在庫を確認し、結果を要約し、確認質問をし、いつどれをやるかを自分で決める必要があります。その振る舞いに自然に合う枠は、エージェント型です — モデルがツール群から選び、システムが選ばれたツールを実行し、結果がモデルに戻り、タスクが終わるまでループが続く。その枠では、検索はエージェントが手を伸ばせる一つのツールになります。第4章はラッパーをエージェントに変えます — ReActループ、契約としてのツールスキーマ、そしてエージェントがターンをまたぐ状態を保つための3層のメモリ。

次回 — 第4章: AIエージェントとツール呼び出し。 状態を持たないモデルを、目標を追う行為者に変えるループ — ツール、メモリ、そして暴走への強い境界。

全体像を押さえたい方へ: 紙版の第3章には、完全なハイブリッドリトリーバー、HTMLを意識した構造的チャンカー、親子ストア、CLIPデュアル埋め込みパターン、そしてクエリ検証つきのtext-to-SQLパイプラインが収録されています。第3巻がRAGのメカニクスをより深く扱っており、第5巻はそれを要約して先へ進みます。Amazonで『LLM Primer V』を見る →