実戦投入レベルのRAGパイプライン構築：完全ガイド

2024年、「PDFとチャットする」系のチュートリアルは至る所にあります。テキストを文字数で分割し、OpenAIでエンベディングし、ベクトルDBに保存してクエリを投げる。5ページのドキュメントなら、魔法のように機能します。

しかし、10万のドキュメント、複雑なフォーマット、そしてユーザーの曖昧な質問が飛び交う本番環境にこれをデプロイすると、魔法は解けます。**「Lost in the Middle（情報の埋没）」**現象、無関係なコンテキストによるハルシネーション、そしてUXを破壊するレイテンシのスパイクに直面することになります。

この記事は「Hello World」的なチュートリアルではありません。実戦投入レベル（Production-Ready）のRAG（Retrieval-Augmented Generation）パイプラインを構築するための深層ガイドです。高度なチャンキング戦略、ハイブリッド検索（キーワード＋ベクトル）、リランキングモデル、そしてシステムを体系的に評価する方法について詳しく解説します。

プロダクションRAGシステムの解剖学

単純なRAGパイプラインは一直線です：ドキュメント -> チャンク -> エンベディング -> ベクトルDB -> 検索 -> LLM。

しかし、プロダクションRAGパイプラインは複雑なグラフのようなものです。

取り込みとETL: PDF、表、汚いHTMLの処理。
高度なチャンキング: 意味的分割、親ドキュメント検索（Parent-Document Retrieval）。
ハイブリッド検索: 密（ベクトル）検索と疎（BM25/Splade）検索の結合。
リランキング: Cross-Encoderを使用した結果の精緻化。
生成: 引用（Citation）をサポートするプロンプトエンジニアリング。

各段階を掘り下げていきましょう。

フェーズ1：取り込みとチャンキング戦略

Garbage in, garbage out（ゴミを入れればゴミが出る）。文章が途中で切れていたり、表のコンテキストが失われていれば、リトリーバー（検索器）になす術はありません。

固定サイズチャンキングの罠

多くのチュートリアルでは、RecursiveCharacterTextSplitterを使用してサイズ1000、オーバーラップ200で分割します。プレーンテキストには「十分」かもしれませんが、構造化データでは失敗します。

なぜ失敗するのか？

コンテキストの分断: 概念を説明する段落が2つに分割されると、両方の意味が失われる可能性があります。
ヘッダーの分離: セクションのタイトルがコンテンツとは別のチャンクに入ってしまい、コンテンツが「迷子」になって検索されにくくなります。

戦略1：セマンティックチャンキング

文字数ではなく、意味に基づいて分割します。エンベディングモデルを使用して文間のコサイン類似度を計算し、類似度が閾値を下回った時点で話題が変わったと判断して新しいチャンクを開始します。

# セマンティックチャンキングの概念コード
sentences = split_into_sentences(text)
embeddings = model.encode(sentences)
chunks = []
current_chunk = [sentences[0]]

for i in range(1, len(sentences)):
    similarity = cosine_similarity(embeddings[i-1], embeddings[i])
    if similarity < THRESHOLD:
        chunks.append(" ".join(current_chunk))
        current_chunk = [sentences[i]]
    else:
        current_chunk.append(sentences[i])

戦略2：親ドキュメント検索（Parent-Document Retrieval）

エンベディングは長いテキストよりも短いチャンクの方をうまく表現できます。しかし、LLMが正確に回答するには、より多くのコンテキストが必要です。

解決策:

ドキュメントを小さな「子（Child）」チャンク（例：200トークン）に分割してエンベディングします。
各子チャンクを「親（Parent）」チャンク（例：1000トークン）またはドキュメント全体にリンクします。
検索は子チャンクのベクトルで行いますが、LLMには親チャンクを渡します。

これにより、精密な検索と豊富なコンテキストという、両方のメリットを享受できます。

フェーズ2：検索レイヤー（ベクトル vs ハイブリッド）

ベクトル検索（Dense Retrieval）は、意味的な意図を捉えるのに優れています。ユーザーが「水道管破裂の直し方」と検索すれば、単語が重複していなくても「配管修理ガイド」を見つけ出します。

しかし、ベクトル検索にも弱点があります：

完全一致キーワード: 0x80040115のような特定のエラーコードや製品SKUの検索。
ドメイン固有の専門用語: 汎用的なエンベディングモデルは、特定の業界の略語を理解できない場合があります。

ハイブリッド検索の実装

ハイブリッド検索は、ベクトル検索（意味）とキーワード検索（BM25）を組み合わせます。

ベクトル検索を実行: 上位50件を取得。
BM25検索を実行: 上位50件を取得。
結果の統合: **RRF（Reciprocal Rank Fusion）**のようなアルゴリズムでリストを結合します。

$RRF(d) = \sum_{r \in R} \frac{1}{k + r(d)}$

ここで $r(d)$ は各リストにおけるドキュメント $d$ の順位です。これにより、両方のリストで上位にあるドキュメントのスコアが大幅に高くなります。

フェーズ3：リランキング（秘密のソース）

RAGパイプラインを改善するために今日一つだけやるとしたら、リランカー（Re-ranker）を追加してください。

ベクトルデータベースは高速ですが（近似最近傍探索）、速度のために精度を犠牲にしています。エンベディングは圧縮された表現だからです。

Cross-Encoderモデルは、クエリとドキュメントを一緒に入力として受け取り、類似度スコアを出力します。Bi-encoderエンベディングよりもはるかに正確ですが、計算コストがかかります。

アーキテクチャ:

検索（Retrieve）: ハイブリッド検索で上位100件の候補を取得（高速）。
リランク（Re-rank）: これら100ペア（クエリ＋ドキュメント）をCross-Encoder（例：bge-reranker-v2-m3やCohere Rerank）に通します。
選択（Select）: スコアの高い上位5件をLLMに渡します。

この「2段階検索（Two-stage Retrieval）」パターンは、高精度RAGの業界標準です。

フェーズ4：生成とハルシネーション防止ガードレール

正しいコンテキストを確保しました。では、LLMがそれに従うようにするにはどうすればよいでしょうか？

1. システムプロンプトエンジニアリング

単に「答えて」と言うだけでは不十分です。具体的に指示しましょう。

"あなたは役に立つアシスタントです。提供されたコンテキストのみを使用してユーザーの質問に答えてください。答えがコンテキストにない場合は、「わかりません」と答えてください。外部知識を使用しないでください。すべての主張についてドキュメントIDを引用してください。"

2. 引用検証（Citation Verification）

モデルに引用（例：[Doc 1]）を出力させます。後処理で、引用されたテキストが実際に検索されたチャンク内に存在するか検証します。モデルがドキュメントを引用しているのにその事実がそこにない場合、ハルシネーションの可能性が高いとしてフラグを立てます。

評価：RAGASとTruLens

変更によってシステムが実際に改善されたかどうか、どうやって判断しますか？指標が必要です。

RAGの3大指標（RAG Triad）:

コンテキスト関連性（Context Relevance）: 検索されたコンテキストはクエリに関連しているか？
忠実性（Faithfulness/Groundness）: 回答はコンテキストのみから導き出されているか？
回答関連性（Answer Relevance）: 回答は実際にユーザーの質問に答えているか？

RAGASのようなフレームワークは、LLM（GPT-4など）を審査員として使用し、これらの指標を自動的に評価します。

# RAGASによる評価例
from ragas import evaluate
from ragas.metrics import context_precision, faithfulness

results = evaluate(
    dataset,
    metrics=[context_precision, faithfulness]
)

結論

RAGのプロトタイプは午後あれば作れます。しかし、プロダクションRAGシステムは数ヶ月の反復が必要です。

2025年に向けた重要なポイント：

固定チャンキングを超える: セマンティックまたは親ドキュメント戦略を使用する。
ハイブリッドは必須: ベクトルだけに頼らない。キーワード検索（BM25）は依然として強力です。
リランキングは高ROI: ベクトル検索の精度の問題を解決します。
評価はオプションではない: 測定できないものは改善できません。

「魔法のような」AIの時代は終わりました。これからは、モデルそのものよりも厳格なシステム設計と評価が重要となるAIエンジニアリングの時代です。