RAGパイプラインとは？取り込み系と推論系に分ける工程設計と再索引の実装判断

RAGパイプラインは、文書を索引に載せる取り込み系と、質問を受けて回答を返す推論系という、動く時間帯の違う2系統で構成されます。工程の名前を並べるだけでは実装に落ちません。手が止まるのは、各工程が次へ何を引き渡すかという取り決めと、原本の文書が更新されたとき索引をどう追従させるかの部分です。この記事では取り込み系5工程と推論系4工程それぞれの入出力、エイリアス切替による無停止の再索引、工程境界での計測による切り分け順を整理しました。分割せず1プロセスに収めてよい規模の条件も、チャンク数と更新頻度の数値で示します。

まとめ：RAGパイプラインを2系統で捉える設計の要点と分割の判断

RAGパイプラインを設計するとき、最初に引く線は工程の数ではなく「いつ動くか」です。文書の抽出からチャンク分割、埋め込み、索引登録までの取り込み系は、質問リクエストの外で動かす定期ジョブです。クエリ前処理から候補取得、リランク、生成までの推論系は、質問1件ごとに1秒から3秒で終える必要があります。この2系統を同じコードに混ぜると、索引更新中の回答が遅くなり、埋め込みAPIのレート制限が回答失敗として表に出ます。

次に決めるのは、工程間で渡す値の形です。チャンクIDの採番規則、埋め込みの次元数、出典の参照番号の3つは索引スキーマに焼き付くため、後から変えると索引の作り直しになります。運用で効くのは再索引の冪等性で、同じ原本を2回流しても重複が増えない採番と、原本から消えた文書を差集合で検出して落とす仕組みを最初から入れておきます。

分割の判断は規模で決まります。チャンク数1万未満で更新が週1回以下なら、取り込みを1本のスクリプトで回して足ります。ワークフローのオーケストレータを入れる価値が出るのは、データソースが複数に増えて依存が分岐し、部分再実行が要るようになってからです。

RAGパイプラインの定義と取り込み系・推論系に分かれる2系統の構造

用語としてのRAGパイプラインは、検索拡張生成の処理を入力から出力までの連なりとして切り出し、設計と運用の単位にしたものを指します。定義の幅が出るのは範囲の取り方です。

検索拡張生成の処理を工程として並べたときのパイプラインの範囲

範囲の下端は原本データの置き場所、上端は回答と出典の返却になります。ここに評価とログの記録まで含めるかで、後の改善速度が変わります。含めない設計だと、回答が外れたときに原因の工程を特定する材料が残りません。実装単位としては、取り込み系の5工程（抽出・正規化、チャンク分割、埋め込み、索引登録、更新検知）と推論系の4工程（クエリ前処理、候補取得、リランク、生成）の計9工程に分けると、担当と計測点が一致します。発注側の視点でPoCから本番までの進め方や期間感を先に押さえたい場合は、RAG構築の手順とはで全体像を確認してから、本記事の工程設計に戻ると読みやすくなります。

オフラインで動く取り込み系とリクエスト毎に動く推論系の責務境界

2系統は求められる性質がほぼ逆です。取り込み系は遅くてよい代わりに、何度流しても同じ結果になる冪等性が必須になります。推論系は副作用を持たない代わりに、応答時間の上限が厳しい。この違いを表にすると、どちらの系統にコードを置くべきかの判断が付きます。

境界の引き方はひとつだけ守れば足ります。索引に書き込む処理を、質問リクエストの処理系から呼ばないことです。

一般のデータパイプラインとの共通点と検索精度が絡む固有の難所

取り込み系の設計論は、ETL分野で積み上がってきたものがそのまま効きます。冪等な再実行、スキーマ変更への耐性、差分更新の設計といった論点は、データパイプラインの構成要素と冪等性で扱う考え方と共通です。固有の難所は出力の正しさが二値で決まらない点にあります。ジョブは成功しているのに回答が外れる、という状態も珍しくありません。そのため工程ごとに別の品質指標を置き、ジョブの成否とは分けて記録する必要があります。

取り込み系5工程の処理順と次工程へ引き渡すデータ構造の決め方

取り込み系は、原本を検索できる形に変換して索引へ載せるまでを受け持ちます。各工程の出力形式を先に決めておくと、後段の差し替えが局所で済みます。

抽出と正規化でDoclingやunstructuredが担う範囲と版の押さえ方

PDFやOffice文書からテキストと構造を取り出す工程では、Docling 2.119.0（2026-08-10公開）やunstructured 0.25.2（2026-08-03公開、Python 3.11以上3.14未満）のような抽出ライブラリを使います。ここで表が段組みごと崩れると、後段のチャンク分割と検索がまとめて劣化する。抽出の質が上限を決める工程です。運用上の注意は版の固定で、Doclingは2.118.1から2.119.0まで数日間隔で更新が入るため、requirementsで版を止めておきます。抽出結果が変わればチャンク境界も変わるので、版を上げる作業は再索引とセットで計画します。

チャンク分割と埋め込みの選択で先に決まる検索精度の上限と委譲先

分割の手法選びは意味の切れ目で分けるセマンティックチャンキングの側で判断するとして、パイプラインの設計として決めるのはIDと次元の2点です。チャンクIDは文書IDと連番と原本の版を組み合わせ、同じ入力から同じIDが再現される決定的な採番にします。埋め込みの次元数は索引スキーマに書き込まれるため、あとで変更できません。text-embedding-3-smallの1536次元とlargeの3072次元では索引サイズが倍以上変わり、sentence-transformers 5.7.0でローカルモデルを選ぶ場合も同じ制約がかかります。

索引登録の段階で付けるメタデータ項目と権限フィルタの設計方針

索引登録では、ベクトルと本文のほかに運用で必要になる属性を持たせます。後から足せない項目があるため、最初の設計で入れておきます。

• 文書IDと原本の版：更新検知と削除の伝播に使う
• 出典URLと見出しパス：回答に引用元を出すために使う
• 権限識別子：部署やロールで検索範囲を絞るために使う
• 有効期限：改訂された規程を検索対象から外すために使う
• 原文の文字オフセット：引用位置を原本上で特定するために使う

権限は候補取得の段階でフィルタとして効かせます。生成の後で不許可の文書を落とす作りにすると、渡してしまった文脈がプロンプトの記録に残ってしまいます。

推論系4工程でリクエスト単位に受け渡す値の設計とトークン配分

推論系は質問を受けてから回答を返すまでを担当し、工程ごとに責任を持つ指標が違います。どこまでを検索側の仕事とするかを決めておくと、精度改善のときに手戻りが減ります。

クエリ前処理から候補取得・リランクまでの各工程の担当範囲の線引き

候補取得は取りこぼしを減らす再現率、リランクは並び順の適合率を受け持ちます。この分担に合わせて件数を配ると、片側の調整が他方を壊しません。候補取得では50件から100件を広めに拾い、リランクで最終の5件から10件に絞る二段構成が扱いやすい形です。密ベクトル検索の索引方式やハイブリッド検索の合成といった検索工程の内部は、リトリーバルの仕組みと精度改善の判断基準の側で決めてください。パイプラインとして固定するのは、候補取得が返す構造（チャンクIDとスコアと本文）だけです。

プロンプト組み立てで渡す出典情報とトークン予算の配分の基準値

組み立て工程では、コンテキスト窓を指示と文脈と出力余白の3つに割り振ります。順番を間違えないことが肝で、出力余白を先に確保してから文脈を詰めます。回答の上限を800トークンと決めたなら、その分を引いた残りが取得チャンクに使える枠です。渡す単位には chunk_id と見出しパスと本文を含め、文脈内では通し番号を振っておきます。番号で参照させると、次の工程で出典の突き合わせが文字列比較だけで済みます。

生成した回答と出典の突き合わせと回答を返さない判断の実装方法

生成の後に検証工程を1つ置きます。回答文に現れた参照番号が、渡したチャンク集合に実在するかを機械的に確かめる処理です。存在しない番号が混じっていれば、再生成するか回答を保留します。手前側にも閾値を置き、リランク後の最上位スコアが基準を下回る質問は生成へ進めません。「該当する記述が見つかりませんでした」と返す経路を工程として実装しておくことが、誤答の総量を下げる一番安い手です。

再索引の設計と差分更新・削除の伝播を冪等に保つための実装方針

構築時より運用で問題になるのが索引の入れ替えです。原本は動き続けるため、無停止で差し替えられる形を最初から用意します。

索引の全量再構築とエイリアス切替で無停止に入れ替える手順の設計

全量を作り直す場面は、抽出器の版を上げたときと埋め込みモデルを替えたときに必ず来ます。稼働中の索引を直接書き換えるのではなく、別名で作って参照先を切り替えます。

1. 日付を含む新しい索引名を作り、スキーマと次元数を固定する
2. 全量を新索引へ書き込み、件数と次元数を旧索引と突き合わせる
3. 手持ちのサンプル質問で新索引を叩き、上位の顔ぶれを目視で確認する
4. エイリアスの指す先を新索引へ切り替える
5. 旧索引を1世代だけ残し、切り戻せる状態で保持する

Elasticsearchならエイリアス機能がそのまま使えます。pgvector（拡張の最新タグはv0.8.6）でPostgreSQL上に置く構成では、テーブルを新規に作ってからスキーマ名かビューの向き先を切り替えると同じことができます。

文書の更新と削除を索引へ伝播させるキー設計と冪等性の担保方法

文書IDには原本側の不変な識別子を使います。ファイルパスは移動や改名で変わるため、キーには向きません。チャンクは doc_id と連番から決定的に採番し、同じ原本を2回流しても同じIDになる状態を保ちます。これで再実行による重複が構造的に起きません。削除の伝播には自作の処理が必要です。原本の削除はイベントとして届かないことが多いため、取り込みジョブが今回検出した文書IDの集合と索引側の集合を突き合わせ、差集合を消す処理を毎回走らせます。更新は文書単位で旧チャンクを全消しした後に入れ直す方式です。部分更新で済ませるとチャンク数が減ったときに孤児が残り、改訂前の記述が検索に出続けます。

埋め込みモデルを変更する際に索引を作り直す判断と費用の見積り

次元数が変われば索引は作り直しです。判断の前に必要なのは費用の算出です。総チャンク数×平均トークン数が課金対象の総量で、10万チャンク・平均400トークンなら4,000万トークンの再埋め込みになります。処理時間はレート制限で決まるため、並列度と合わせて見積もります。ここでの結論は明確で、検索精度の改善幅を測る仕組みが無い状態ではモデルを差し替えないことです。年に何回まで全量再構築を許容するかを先に決め、その回数に収まる運用手順を作ってから差し替えに進みます。

工程境界での計測により不具合の発生工程を切り分ける手順の設計

回答が外れたという報告から原因工程に辿り着けるかは、事前に何を記録していたかで決まります。工程の境界に計測点を置きます。

各工程で残すログと相関IDの設計で回答の根拠を追跡する実装方法

1つの質問に相関IDを1つ振り、工程を通して引き継ぎます。記録するのは、書き換え後のクエリ、候補取得が返したチャンクIDとスコア、リランク後の順位、生成へ渡したトークン数、そして回答本文です。取り込み側には索引の版とジョブIDを残します。この2つが揃うと「先週と同じ質問で回答が変わった」原因を、索引の入れ替えかモデル更新かに切り分けられます。Apache Airflow 3.3.0やPrefect 3.8.2、Dagster 1.13.17はジョブ側の実行ログを持ちますが、推論系のログは自分で設計する範囲です。

回答が外れたときに取り込み系と推論系のどちらかを切り分ける手順

切り分けは索引の中身を見る順に進めます。上から順に確かめると、2手か3手で担当工程が決まります。

1. 期待する記述が索引に存在するかをチャンクIDの直接取得で確かめる
2. 存在するなら候補取得の上位に入るかを見る（件数を広げて入るなら検索側）
3. 上位に入るのに回答へ出ないなら生成側（文脈の切り詰めか指示文）
4. 索引に無いなら取り込み系（抽出漏れ、チャンク境界、権限フィルタ）

工程ごとにどの指標で合否を判定するかは、検索と生成を分けて測るRAG評価の指標の側で設計しておくと、この切り分けが数値で回るようになります。

パイプラインを分割する条件と1プロセスに収める条件の判断基準

工程を分けるほど運用は堅くなりますが、監視対象とデプロイ単位も増えます。規模に合わない分割は、動かない仕組みを増やすだけで終わります。

文書量と更新頻度から見て取り込み系を別ジョブに切り出す境界線

境界はチャンク数と更新頻度の2軸でほぼ決まります。下の目安から始めて、実測で調整してください。

分けるときは埋め込み工程を独立させます。この工程だけがAPIのレート制限に律速されるため、並列度を他工程と別に持てる形にしておくと全体の所要時間が縮みます。

オーケストレータを導入しない判断が妥当になる規模と運用の条件

cronとロックファイルで足りる条件は3つあります。ジョブが1本、依存関係が直列、そして失敗時に全量を流し直しても実行時間が30分以内に収まること。この範囲ならApache Airflow 3.3.0の導入は過剰で、DAGの記述とスケジューラの運用コストが先に効いてきます。オーケストレータへ移す判断は、データソースが2つ以上に増えて依存が分岐したとき、あるいは部分再実行が業務上必要になったときです。ジョブが1本で日次1回の構成に入れる理由はありません。

失敗パターン：工程を分けずに全量再索引を同期処理で回す構成の問題

実際に破綻する構成をひとつ挙げます。管理画面の「文書を更新」ボタンから、抽出・埋め込み・索引登録を同期処理でその場で走らせる作りです。文書が増えた時点で3つの症状が同時に出ます。処理中の質問応答が遅くなる、埋め込みAPIのレート制限で途中失敗する、そして落ちた地点で索引が半端な状態のまま残る。冪等な採番と差集合による削除が入っていなければ、この半端な索引を人手で直すことになります。全量再索引を同期で回してよいのは初回構築のときだけで、2回目以降はジョブに逃がすのが前提です。

外部へ委託する場合に索引設計と評価基盤の担当を決める際の線引き

受託側に任せるのが妥当なのは、抽出と正規化の作り込み、索引スキーマの設計、再索引ジョブの実装、評価データセットの作り方の提示までです。自社に残すべきものは2つあります。何を正解とみなすかという業務判断と、誰がどの文書を見てよいかという権限の定義です。この2つを渡してしまうと、精度の合否を自社で判定できなくなります。社内文書を対象にした索引設計と再索引の運用まで含めて相談する場合は、RAG構築支援で対応範囲と進め方を確認できます。

よくある質問

RAGパイプラインの設計と運用でよく聞かれる論点を、判断の材料になる形で答えます。

RAGパイプラインとRAGの違いは何ですか？

RAGは検索した情報を添えて回答を生成する方式そのものを指す言葉で、RAGパイプラインはその方式を動かすための工程の連なりを指します。方式として理解するだけなら、検索して渡して生成するという2段構成の説明で十分です。実装や運用の話になると、抽出からチャンク分割、埋め込み、索引登録、更新検知、そして推論側の4工程という単位が必要になります。パイプラインという語が出てくる場面では、工程の境界と受け渡すデータの形が論点になっていると考えて差し支えありません。

取り込み系と推論系は必ず分けるべきですか？

コードの置き場所としては分けてください。プロセスやジョブとして物理的に分けるかは規模次第です。チャンク数が1万未満で更新が週1回以下なら、取り込みを1本のスクリプトにまとめ、cronで夜間に回す形で十分に運用できます。分けるべきでないのは索引への書き込みを質問リクエストの処理内から呼ぶ設計です。これは規模に関係なく避けます。応答時間とレート制限の問題が、利用者から見える回答失敗として表面化します。

文書を更新したら索引はどのタイミングで作り直しますか？

更新の種類で分かれます。文書の追加・改訂・削除は差分更新で追従させ、文書単位で旧チャンクを消してから入れ直します。全量の作り直しが必要になるのは、抽出ライブラリの版を上げたとき、チャンク分割の方針を変えたとき、埋め込みモデルや次元数を変えたときの3つです。この3つはチャンク境界かベクトル空間が変わるため、差分更新では新旧が混在した索引になります。全量再構築はエイリアス切替と組み合わせ、旧索引を1世代残して切り戻せる状態を保ちます。

パイプラインの各工程はどのツールで実装しますか？

2026年8月時点で選択肢が固まっているのは、抽出がDocling 2.119.0やunstructured 0.25.2、工程の結線がlangchain 1.3.15やllama-index 0.14.23、埋め込みが商用APIかsentence-transformers 5.7.0、索引がpgvector（拡張はv0.8.6系）やElasticsearch、評価がragas 0.4.3という組み合わせです。フレームワークを入れるかは工程数で判断します。9工程を素のコードで書いても300行程度に収まるため、小規模なら直接書いたほうが版の追従コストがかかりません。

パイプラインを組む前にどこから着手すればよいですか？

評価用の質問と期待する出典のペアを20件から30件作るところから始めてください。この材料が無いと、チャンクサイズや検索方式を変えたときに良くなったのか悪くなったのかが判定できません。次に決めるのはチャンクIDの採番規則と埋め込みの次元数で、この2つは索引スキーマに焼き付いて後から変えられないためです。抽出や検索方式の作り込みは、この土台ができた後から始めても遅くなりません。

関連記事

• 埋め込みモデルとは：取り込み系で次元数を固定する前に、日本語文書向けのモデル選定の判断基準を確認できます
• RAGASとは：工程別の合否判定を自動化する評価フレームワークの指標カタログと実装手順を扱います
• LlamaIndexとは：9工程の結線をフレームワークに任せる場合の仕組みと採用判断をまとめています
• Agentic RAGのアーキテクチャ：推論系を自律エージェントが繰り返す発展形の構成要素を解説しています
• データパイプラインとは：取り込み系の土台になる冪等性と差分更新の設計判断を一般化して扱います