第1章 — RAGアーキテクチャの進化

LLM Primer III: RAGで強化するエンタープライズAI を章ごとに紹介していくウォークスルー、第1回です。固定コーパスで学習したトランスフォーマーが抱える、追加学習では消しきれない2つの制約 — 知識の凍結と、出典の不在 — に対するアーキテクチャ的な答えがひとつ存在し、その答えが3年で4つの顔を獲得した。今回はその物語からはじめます。

この章がなぜあるのか

固定コーパスで学習したトランスフォーマーには、どれだけ追加学習しても消しきれない2つの限界があります。知識はコーパスの最終日で止まる。そして、ある文がどの文書に由来するのかを答えられない — 文は多数の出典の統計的な平均であって、どれか一文書からの引用ではないからです。1つ目の失敗は、新しい話題に対して自信を持って間違える、という形で現れます。2つ目は、自信を持って間違った引用を返す、という形で。両者があわさって、今ではすっかり見慣れたエンタープライズの病理 — 権威ありげな回答が、存在しない条文へのリンクを伴って返ってくる — を生みます。

RAGは、その両方に同時に答えるアーキテクチャです。モデルにすべてを事前に知らせるのをやめて、推論時に、自分が制御するコーパスから関連する素材を取り出して渡す。コーパスは再学習なしで更新できます。取り出された箇所は、こちらが意図的に取りに行ったからこそ、引用として機能します。モデルの仕事は記憶から合成へと縮小します。この章の残りは、その単純な一手が3年でどう成長し、4つの段階的に強力なアーキテクチャになったかを追います。

1.1 Naive RAG — 埋め込み、検索、詰め込み

もっとも単純な形は、いまも公開チュートリアルが描いているとおりです。オフラインで、コーパスをチャンクに分割し、各チャンクを埋め込み、ベクトルをインデックスに書く。オンラインで、クエリを埋め込み、上位kの近傍チャンクを取り、プロンプトに連結し、モデルに送り、チャンクを引用として並べて回答を返す。関数呼び出し2回とベクトル検索1回。

デモは動きます。プロダクトはたいてい動きません。最近傍類似度は関連性の代理であって測定ではなく、ウェブの一般テキストで訓練された埋め込みモデルは apple orchard yields と Apple の四半期業績 をしばしば混同します。チャンカーには、文がどこで終わり表がどこから始まるかを知る手がかりがありません。答えが3つの文書にまたがる問いに、1回の検索で応えることはできません。そして検索が外れたとき、モデルは返ってきたもので合成します — 引用は本物ですが、回答のどこも支えていない、という状態が起きます。

1.2 Advanced RAG — 同じパイプラインを囲むヒューリスティクス

2つ目の姿勢は、埋め込み—検索—生成の骨格を残したまま、検索の前後に処理を追加します。検索前の強化はクエリ側 — 書き換え、拡張、分解、HyDE(仮想的な答えを下書きし、その埋め込みをクエリにする)。検索後の強化は候補側 — クエリと文章をまとめてスコアリングするクロスエンコーダ・リランカー、重複除去、メタデータフィルタ、コンテキスト圧縮。

得られる改善は小さくありません。ベクトル検索の上にクロスエンコーダ・リランカーを置くだけで、top-5の関連性が 50〜70% 帯から 75〜90% 帯へ動くのが普通です。クエリ書き換えは、元の表現が曖昧な場合にさらに5〜10点を上乗せします。今日「RAG」と呼ばれている本番システムのほとんどはこのアーキテクチャで動いていて、内部ドキュメント Q&A、サポート対応の自動化、ナレッジベース検索といった広いクラスのエンタープライズ課題に対しては、これが適切な投資水準です。得られないのは柔軟性で、すべてのクエリが同じパイプラインを通ります。

1.3 Modular RAG — 組み立て可能なコンポーネント、明示的なルーティング

2024年あたりで、研究とツールの両方が Modular RAG に収斂しました。同じ手法群は健在ですが、それらが離散的で差し替え可能なコンポーネントとして公開され、パイプラインはリクエスト単位で組まれます。ルータがどの検索器を呼ぶか決め — 密ベクトルインデックス、BM25、SQLストア、外部API — その結果は、しばしば Reciprocal Rank Fusion で融合されます。リランカーはクエリの種類で選ばれ、生成器は要求される品質階層で選ばれる。アーキテクチャは段階の直列ではなく、コンポーネントのグラフになりました。

実務上の帰結は2つあります。第一に、システムが過去の姿勢ではできなかった形でテスト可能になる — コンポーネントは独立に評価し差し替えられます。第二に、システムがクエリの種類ごとにチューニング可能になる。事実型のルックアップは速い検索器と小さな生成器、複数文書の合成は複数の検索器と大きな生成器、いずれも同じコンポーネントライブラリから提供される。代償は運用です。回答が外れたとき、どこで外れたのか の答えが複数ありえて、チームは失敗をひとつのコンポーネントに局所化できる計装が要ります。Modular に行く前に、可観測性に先行投資してください。あとからではうまくいかないことが多いです。

1.4 Agentic RAG — パイプラインを回すのはLLM

4つ目の姿勢は、前の3つが暗黙に共有していた前提 — LLMが最後のステップであるという前提 — を反転させます。Agentic RAG では、LLMがパイプラインを回します。ツールのカタログ(ベクトル検索、SQL、ウェブ取得、リランカー、計算機)が与えられたら、モデルは考え、ツールを選び、結果を観察し、また考え、答えに辿り着くかステップ上限に当たったら停止する。アーキテクチャは固定パイプラインではなく、クエリのたびにモデルが書き起こす小さなプログラムに変わります。

これにより、多段の計画、動的なツール選択、プランナー/検索器/批評役/書き手のようなマルチエージェントの調整パターンが手に入ります。代価は、レイテンシ、トークン消費、再現性です — 単一クエリが固定列ではなく判断の木になり、病的なクエリは答えに辿り着く前に何ターンも空回りすることがあります。本番のエージェント系には、固定パイプラインなら考えなくてよかった予算制御、ステップ上限、タイムアウトポリシーが必要になります。適しているのは、深さが可変で予測しにくい問い — 調査の合成、判例検索、文献レビュー。不向きなのは静的なサポートボットで、ワークロードが必要としていないばらつきをエージェントループが加えてしまいます。

1.5 RAG とファインチューニング

遅かれ早かれ、どのチームも訊ねる問いです。誠実な構図は、両者は別の問題を解いているということです。RAGは知識の問題に向かいます — モデルがXを知らない、Xが変わる、ユーザーは引用を必要としている。ファインチューニングは振る舞いの問題に向かいます — モデルは答えを知っているが形式が違う、社内テンプレートに従わない、簡潔にすべきところでだらだら書く。RAGはセットアップが安価でクエリ単位は高い。ファインチューニングは初回が高くクエリ単位は安い。RAGは数分で反復できます(文書を変えるだけ)。ファインチューニングは数日です。役に立つ目安: モデルが知らない ことが失敗なら、RAG。知っているが間違うやり方をする ことが失敗なら、ファインチューニング。成熟したシステムは最終的に両方を併用しますが、まずは RAG から。エンタープライズの失敗の多くは、振る舞いではなく知識の失敗です。

第1章を踏まえて

どのRAGアーキテクチャを選ぼうと — 4つのうちのどれを選ぼうと — それは、自分の元文書をどれくらい正確に読めるかの下流にあります。最先端の Modular パイプラインに Agentic オーケストレータを載せても、上流のパース工程から出てきたチャンクの上で推論しているのは変わりません。その工程が表の構造を失い、多段組の読み順を入れ替え、図のキャプションを文字化けOCRに置き換えていたら、下流のすべてのコンポーネントは壊れた入力の上で推論することになります。アーキテクチャはシステムの天井を決めます。パーサーは床を決めます。本番のほとんどでは床のほうが重要です — 多くのシステムは、天井からは程遠いところで動いているからです。

次回 — 第2章: インテリジェント文書パース。 素朴な PDF→テキスト変換が検索品質をどう静かに壊すか、レイアウト認識パースが実際に保つもの、そしてページ画像を直接検索するマルチモーダルの選択肢。