第11章 — 継続的なアップデートとパイプライン最適化

公開日: 2026-03-28 最終更新日: 2026-06-09 バージョン: 1

第11章 — 継続的なアップデートとパイプライン最適化

LLM Primer III: RAGで強化するエンタープライズAI を章ごとに紹介していくウォークスルー、第11回、最終回です。パイプラインが終わることはありません — 文書は変わり、クエリは流れ、モデルは差し替えられる — それを所有するチームは、3つの時間スケールを同時に考えることを覚えていきます。


この章がなぜあるのか

RAG システムは出荷したら終わり、ではありません。文書は変わり、クエリはドリフトし、モデル自体も数ヶ月で置き換わります。3月にチームが誇りに思っていたパイプラインは、9月には2世代前のモデルが作った古い埋め込みに対して検索し、いつの間にか差し替えられたベースモデルを使い、誰も追っていなかった方向にドリフトした問いの分布に答えている — ということが起こりえます。この章は、現状に追従するための工学の話です。何がコーパスで変わったかを検知し、再構築せずにインデックスを新鮮に保ち、レイテンシが這い上がるのを防ぎ、本番テレメトリとチームが実際に行う変更とのループを閉じる。

ひとことで言うと: RAG システムを生かす機構は3つ — 鮮度のための Change Data Capture、レイテンシとコストのためのセマンティックキャッシュとモデル階層化、そしてテレメトリを3つの別カデンスでのパイプライン変更へと変える4段のフィードバックループ(収集、評価、判断、適用)。

11.1 Change Data Capture とインクリメンタルなインデックス更新

RAG を出荷したチームの最初の本能は、夜間でインデックスを再構築するスケジュールを組むことです。動きます。長期的には間違っています。夜間の再構築は変わっていない文書に対しても埋め込みAPI料金を燃やし、インデックスは最大24時間古く、コーパスが育つと夜間ウィンドウに収まらなくなる。成熟したパターンは、Change Data Capture が駆動するインクリメンタルなインデックス更新です — パイプラインは上流のイベントに反応し、ポーリングをしません。

関係するイベントは3種類です。Insert: 新しい文書を、パースし、チャンクし、埋め込み、インデックスする。Update: 既存文書が変わった。影響を受けたチャンクだけを再埋め込みする。Delete: 文書が削除された。結果に返ってこられる前に対応するベクトルを退去させる — GDPR や CCPA など多くの規制で硬性の要件です。これを扱いやすくする機構が、内容ハッシュです。最初の取り込みで、正規化されたチャンクテキスト上の SHA-256 を、埋め込みと並べて保存する。更新時に、再チャンクし、ハッシュし、比較する: 変わっていないチャンクは留まり、新しいものは埋め込まれ、古いものは退く。1段落の編集が、千の埋め込み呼び出しではなく1つになる。埋め込み料金がコーパス規模ではなく編集活動にスケールするようになります。

難しい問題は順序と整合性です。イベントは順序が崩れて到着し、削除がそれに先行すべき更新を追い越すことがあります。標準的な対処は、文書ごとの単調なバージョン番号と条件付き書き込みで、ファイル上のバージョンを上回るときだけイベントを適用する。これでパイプラインは冪等になり、重複イベントがインデックスを壊せない — これは最適化ではなく、スケールでの正答性の要件です。コンプライアンス文脈ではトンビューンを足します: クエリ時に有効になる論理削除で、物理削除は非同期に完了させる — これで削除は即座に尊重されます。

11.2 レイテンシを管理する — セマンティックキャッシュとモデル階層化

検索拡張の1回の呼び出しは、ホップごとにレイテンシを積みます。守りは、不要だと証明できる仕事はやらないことで、その負荷の大半を2つの手法が担います。従来のキャッシュは正確なクエリ文字列でキーを引き、現実のトラフィックではほとんど当たりません。セマンティックキャッシュ は意味でキーを引きます: 入ってきたクエリを埋め込み、最近のクエリの小さなキャッシュを検索し、最近傍のコサイン類似度が閾値を超えていればキャッシュされた回答を返す。「返金ポリシーは?」と「返金はどう動く?」は文字列の一致はなくても、回答はそっくり同じ場合がある。

重要な選択は3つです。類似度の閾値(一般用埋め込みではコサイン 0.93〜0.97、ホールドアウトトラフィックでチューニング)、TTL(理想は寄与チャンクに紐づける — どれかが再埋め込みされたら無効化する)、そしてスコープ(テナント、アクセスロール、他者の回答が漏れうるあらゆる軸で分割する)。本番展開では30〜60% のヒット率、ヒット時はミリ秒台に対してキャッシュなしは秒台、というレポートが出ています。キャッシュヒットは埋め込みと生成の両方をスキップするので、コスト削減もそれに比例します。

モデル階層化 は、モデルを使わざるをえないけれど最大のモデルを使うべきでないクエリを扱います。2〜3階層: 大量を処理する小さく速く安いモデル、小さいモデルが自信を持てないクエリのための大きいモデル、必要ならロングテール用の3つ目。ルータは、本番展開が初回でいちばん間違える場所です。もっとも素朴な版はクエリ側の信号を使います(短い事実問い vs 分析的問い)。よりよい版は検索側の信号を使います(高く一貫した類似度なら、小さいモデルで足りる)。もっとも洗練された版は、小さいモデルを先に走らせ、較正された信頼度でエスカレーションする — 端で正確、エスカレーションでは追加推論を払う。見るべき数字はエスカレーション率とリグレット率の両方で、片方だけだと誤導します。

11.3 継続的なフィードバックループ

RAG パイプラインはテレメトリを絶え間なく吐きます。ほとんどのチームはそれを集めますが、ループを閉じるチームはとても少ない。ループは4段です。収集: クエリ、検索、生成、引用、ユーザーとのやりとりを、安定したスキーマと、全段を貫く安定したクエリ識別子で記録する — その識別子なしでは、回帰の診断は推測に堕します。評価: 第9章と第10章のトライアドを2つのモードで動かす。正答性のために、参照セットに対してオフラインでサンプル走らせる。網羅のために、オンラインの行動代理(再生成、コピー、追問、放棄)を走らせる。どちらも単独では十分ではなく、両者で三角測量します。

判断 がいちばん難しい段です。同じ信号が複数の異なる手当てを示唆するからです。コンテキスト関連性の低下は、コーパスがトピックを欠いているのかもしれないし、リランカーが劣化したのかもしれないし、埋め込みモデルが新しい語彙にもう合わないのかもしれない。区別には尺度をスライスする必要があります — トピック別、文書年齢別、埋め込み版別、テナント別 — そして集約だけを見るチームは、ひとつのスライスが平均をずっと引き下げていたことを四半期遅れで発見します。

適用 は3つの重みで来ます。設定変更 — top-k、リランカーの重み、ハイブリッドのα、キャッシュ閾値、エスカレーション規則 — は時間単位で A/B、分単位でロールバック、いつでも複数走らせる。再インデックス操作 — 古びたトピックを再埋め込み、新ソースを取り込み、廃止文書を退去 — は週次〜オンデマンドで、本番ではないレプリカで先に走らせて昇格する。モデル変更 — 埋め込みモデル差し替え、ベースモデル差し替え、カスタムリランカーの再訓練 — は四半期単位で、シャドウ展開、並列評価、段階的トラフィック移行、ロールバックの選択肢つき。規律は単一の変更ではなく、カデンスのほうにあります。小さな人手ラベルチャンネル — 週100例ほど、曖昧代理のキューから — を保つと、LLM ジャッジが較正されたままになり、ループが自分の代理に対して最適化していくのを止められます。

覚えておきたいこと: RAG を出荷するときの誘惑は、それを「作って引き渡せる機能」と考えることです。そうではありません。本書のすべてのシステムは、保守を止めた瞬間から劣化します。それがインデックスしている世界が止まらないからです。最初から運用コストを計画してください — 人員、予算、オンコール、評価のカデンス — そうでなければ、システムをそもそも出荷しないでください。

第III巻を踏まえて

純粋な言語モデルが解けない2つの問題 — 鮮度のある知識と、検証可能な出典 — への工学的な答えとして、検索拡張生成を扱うところから始めました。アーキテクチャを、初期の埋め込み—検索—詰め込みのパターンから、いま本番に出ているモジュラーやエージェント系まで辿り、各コンポーネントについて丁寧に — PDFから構造を取り戻すパーサー、意味の単位とは何かを決めるチャンカー、結果を保つベクトルDB、必要なものを見つけるハイブリッド検索器とリランカー、システムを正直に保つアクセス制御と匿名化層、それが動いているかを教えてくれる評価フレームワーク、そしてそれを生かし続ける継続的な更新機構 — 仕事を積んできました。

RAG はプロダクトのカテゴリではありません。十数のサブ分野からなる工学の規律で、それぞれが「動くシステム」と「静かに幻覚を見るシステム」を分けえます。各サブ分野を真面目に扱うチームは、現実のトラフィックに耐えるものを作るでしょう。どれかをブラックボックスとして扱うチームは、そうでないものを作ります。


シリーズは LLM Primer IV — MCPで設計するAI認知 へ続きます。 第III巻が「モデルに正しい知識を持ち込む」だったのに対し、第IV巻は「正しい手」を持ち込みます — Model Context Protocol、それを携えるエージェント、彼らが呼ぶツール、彼らが積み重ねる記憶。同じアーキテクチャの感性、同じ問題の別の表面。仕事は続きます。

全体像を押さえたい方へ: 本書では運用の章をさらに歩きます — Kafka ベースの取り込みパイプライン、コンプライアンス削除のためのトンビューン意味論、高くて凡庸なクエリを捕まえる「コスト×品質」可観測性、そしてひとつの基盤で大きく異なるワークロードを支えるためのテナント別設定モデル。Amazonで『LLM Primer III』を見る

下田 昌平
下田 昌平
開発と設計を担当。1994年からプログラミングを始め、今もなお最新技術への探究心を持ち続けています。