RAGパイプライン（アールエージーパイプライン）
RAGパイプラインは、ドキュメントの取り込み（Ingestion）・検索（Retrieval）・生成（Generation）の3段階で構成される処理フローであり、各段階のコンポーネントを最適化・組み合わせることでLLMの回答品質を制御する。
RAGパイプラインの全体像
RAGパイプラインは、非構造化データをLLMが利用可能な形式に変換し、ユーザーのクエリに対して関連情報を検索・取得し、その情報を基にLLMが回答を生成する一連の処理フローである。パイプラインの設計品質がRAGシステム全体の精度を決定するため、各コンポーネントの選択と最適化が極めて重要である。
現代のRAGパイプラインは単純な「検索して生成する」だけではなく、クエリの前処理・検索結果のフィルタリング・回答の後処理・フィードバックループなど、多段階の処理を含む複雑なシステムに進化している。LangChain、LlamaIndex、Haystack、DSPyなどのフレームワークがパイプライン構築を支援している。
Ingestion（取り込み）パイプライン
Ingestionは、RAGパイプラインのオフライン処理部分であり、ドキュメントをベクトルデータベースに格納するまでの一連の処理を指す。
| ステップ | 処理内容 | 使用ツール例 |
|---|---|---|
| Document Loading | PDF/HTML/DOCX等からテキスト抽出 | Unstructured、PyMuPDF、Docling |
| Text Cleaning | ヘッダー/フッター/不要要素の除去 | 正規表現、専用クリーナー |
| Chunking | テキストをセマンティック単位に分割 | RecursiveCharacterTextSplitter、SemanticChunker |
| Metadata Extraction | ソース情報・日時・著者等の付与 | LLMベース抽出、ルールベース |
| Embedding | チャンクをベクトルに変換 | BGE-M3、Voyage-3、text-embedding-3-large |
| Indexing | ベクトルDBへの格納・インデックス構築 | Qdrant、Pinecone、Weaviate、Milvus |
Document Loadingでは、元データの形式に応じた適切なパーサーを選択する。PDFの場合、テーブルや図表の構造を保持できるDoclingやUnstructuredが推奨される。OCR（光学文字認識）が必要な場合はTesseractやAzure Document Intelligenceを組み合わせる。
Chunkingはパイプライン全体の性能に大きく影響するため、固定長分割・セマンティック分割・再帰的分割・ドキュメント構造ベース分割など、データの特性に応じた戦略選択が求められる。詳細は関連用語「RAG向けチャンキング戦略」を参照されたい。
Retrieval（検索）パイプライン
Retrievalは、ユーザーのクエリに対して最も関連性の高いチャンクを取得するオンライン処理部分である。
| ステップ | 処理内容 | 代表的手法 |
|---|---|---|
| Query Processing | クエリの意図解析・書き換え | Query Rewriting、HyDE、Step-back Prompting |
| Initial Retrieval | 候補チャンクの広範囲取得 | ベクトル検索、BM25、ハイブリッド検索 |
| Re-ranking | 取得結果の精度向上 | Cross-Encoder、ColBERT、Cohere Rerank |
| Filtering | メタデータ・スコア閾値でフィルタ | 日時フィルタ、カテゴリフィルタ |
| Context Assembly | LLMに渡すコンテキストの構成 | チャンク結合、要約圧縮 |
Query Processingでは、ユーザーの曖昧なクエリを検索に最適化された形に変換する。HyDE（Hypothetical Document Embeddings）は、LLMに仮の回答を生成させ、その回答の埋め込みベクトルで検索することで、クエリと文書の語彙ギャップを埋める手法である。
ハイブリッド検索は、ベクトル検索（セマンティック類似度）とBM25（キーワード一致）を組み合わせることで、両方の長所を活かす。Reciprocal Rank Fusion（RRF）やConvex Combinationで2つの検索結果をマージするのが一般的である。
Generation（生成）パイプライン
Generationは、取得したコンテキストとユーザーのクエリをLLMに入力し、最終的な回答を生成する段階である。
プロンプト設計が生成品質を大きく左右する。代表的なプロンプトテンプレートは以下の構造を持つ:
- システム指示: 役割定義、回答形式の指定、ハルシネーション防止の制約
- コンテキスト注入: 取得したチャンクの挿入（引用番号付き）
- ユーザークエリ: 元の質問文
- 出力制約: 回答長、引用形式、不明時の対応指示
生成後の後処理として、回答中の事実をコンテキストと照合する「Grounded Verification」や、回答に含まれる引用の正確性を検証する「Citation Verification」を行うことで、ハルシネーションをさらに抑制できる。
パイプラインの評価と最適化
RAGパイプラインの評価は、Retrieval性能とGeneration性能の両面から行う必要がある。
| 評価対象 | メトリクス | 説明 |
|---|---|---|
| Retrieval | Hit Rate@K | 正解チャンクがTop-Kに含まれる割合 |
| Retrieval | MRR（Mean Reciprocal Rank） | 正解チャンクの順位の逆数の平均 |
| Retrieval | nDCG | 順位を考慮した累積利得 |
| Generation | Faithfulness | 回答がコンテキストに忠実か |
| Generation | Answer Relevancy | 回答がクエリに関連しているか |
| E2E | Correctness | 最終回答の正確性 |
RAGASやDeepEvalなどの評価フレームワークを用いて、パイプライン全体のE2E（End-to-End）性能と各コンポーネントの個別性能を継続的にモニタリングすることが推奨される。
よくある質問（FAQ）
Q: RAGパイプラインのレイテンシを改善するにはどうしますか？ A: 主要なボトルネックは検索ステップとLLM生成ステップである。検索側ではHNSWインデックスの最適化（efSearchパラメータ調整）、キャッシュ層の追加（セマンティックキャッシュ）、非同期検索の導入が効果的である。生成側ではストリーミング出力、モデルサイズの縮小（GPT-4o-mini等）、KVキャッシュの活用が有効である。
Q: マルチモーダルRAGは実現可能ですか？ A: 画像・テーブル・グラフなどを含むマルチモーダルRAGは急速に発展している。ColPali/ColQwenのようなビジョンエンコーダベースの検索モデルや、GPT-4oやGemini 1.5 Proのようなマルチモーダルモデルを生成器として使用することで実現できる。Unstructuredのようなツールは、PDFからテーブルや画像のキャプションを自動抽出してマルチモーダルチャンクを生成する機能を提供している。
Q: RAGパイプラインの本番運用で注意すべき点は何ですか？ A: データの鮮度管理（定期的な再インデックス）、チャンクの重複排除、アクセス制御（ユーザーごとに検索可能なドキュメントを制限）、コスト管理（Embeddingとリランキングのトークンコスト）、モニタリング（検索ヒット率、回答品質のドリフト検出）が重要である。LangSmithやPhoenixなどの可観測性ツールを導入して、パイプラインの各段階を監視することが推奨される。