RAG の Retrieval 品質を上げる 2026 年の定石: Hybrid・Reranker・HyDE・Late Chunking

Retrieval が RAG 品質の上限を決める

• 年、RAG プロジェクトで「生成モデルを GPT-4 から Claude Opus 4.7 に変えたら急に賢くなった」というケースは稀だ。大半の課題は Retrieval の段階で必要な情報を拾えていない か、ノイズを拾って LLM を混乱させている。KGA で過去 18 か月支援した RAG 案件を振り返ると、Retrieval 改善だけでユーザー体感スコアが 30～60% 伸びた一方、LLM モデル変更での伸びは平均 8% 程度だった。

本稿は 2026 年時点の RAG Retrieval 定石を、5 つのレイヤーで整理する: (1) ハイブリッド検索、(2) リランカー、(3) クエリ書き換え、(4) チャンク戦略、(5) 評価指標。

レイヤー 1: Hybrid Search (BM25 + Dense)

単一の dense 検索は、型番（"ZX-450B"）、略語（"TLS1.3"）、人名、固有の数値条件で頻繁に失敗する。BM25 は逆にセマンティックな言い換えに弱い。この 2 つを Reciprocal Rank Fusion (RRF) で融合するのが業界標準になった。

RRF は非常にシンプル: 各検索結果のランクを `1 / (k + rank)` に変換して合算する（k=60 がデフォルト）。スコアのスケール差を気にせず融合できるため、異なるモデル間の組み合わせに万能に効く。

```python from collections import defaultdict

def rrf_fusion(ranked_lists: list[list[str]], k: int = 60) -> list[tuple[str, float]]: scores = defaultdict(float) for results in ranked_lists: for rank, doc_id in enumerate(results, start=1): scores[doc_id] += 1.0 / (k + rank) return sorted(scores.items(), key=lambda x: -x[1])

bm25_top = bm25_index.search(query, k=50) dense_top = vector_db.search(query_embed, k=50) fused = rrf_fusion([bm25_top, dense_top])[:20] ```

KGA の法務検索プロジェクトでは、BM25 単独 nDCG@10=0.52、Dense 単独 0.61、RRF ハイブリッドで 0.73 まで伸びた。単純なのに強い。

レイヤー 2: Reranker（Cohere Rerank-3, Voyage Rerank-2）

ハイブリッド検索で top 50～200 を取ったあと、クロスエンコーダ型リランカーで精密にスコア付けする二段設計が 2026 年のデファクトだ。dense 検索はクエリとドキュメントを独立にベクトル化する bi-encoder 構造で、query-document 間の相互作用を失う。リランカーは両方を同時に Transformer に通し、真の関連度を出す。

• Cohere Rerank-3 (2025/09 リリース): 100 言語対応、128k コンテキスト、$2/1k queries
• Voyage Rerank-2: 32k コンテキスト、MTEB Reranking で首位級、$0.5/1k queries
• Jina Reranker v2: OSS 寄りオプション、日本語性能は Cohere に一歩譲る
• BGE-Reranker-v2-m3: MIT ライセンス OSS、セルフホスト運用の第一選択

```python import cohere

co = cohere.Client() results = co.rerank( model="rerank-3", query="データ保護法における越境移転の要件", documents=[d.text for d in top50], top_n=10, ) reranked = [top50[r.index] for r in results.results] ```

リランカーの効果は劇的で、KGA での平均では nDCG@10 が 0.65 → 0.82 前後まで跳ねる。ただしレイテンシは top 50 で +200～400ms 追加されるため、検索 UX では非同期化や first-stage のみで高速応答する設計が必要になる。

レイヤー 3: クエリ書き換え (HyDE, Query2Doc, Multi-Query)

ユーザーのクエリは短く曖昧なことが多い（"契約解除"、"メモリ使用率"）。これを LLM で拡張してから検索する技法が 2026 年の Retrieval 設計に組み込まれた。

• HyDE (Hypothetical Document Embeddings): LLM に仮想的な回答ドキュメントを書かせ、その embedding を検索キーにする
• Query2Doc: クエリと疑似ドキュメントを結合して embedding を取る（HyDE の亜種、多くのケースでより安定）
• Multi-Query: LLM に同じ意図の別表現を 3～5 個生成させ、並列検索して RRF 融合

```python def hyde_search(query: str, vector_db, llm): hypothetical = llm.generate( f"次の質問に対する架空の回答を 3 文で書いてください: {query}" ) combined = query + " " + hypothetical # Query2Doc 化 embed = embedding_model.encode(combined) return vector_db.search(embed, k=50) ```

Multi-Query が最もコスパが良く、KGA の社内 FAQ RAG では単一クエリ検索比で Recall@20 が 12% 改善した。コストは 1 クエリあたり LLM 呼び出しが 1 回増えるが、Claude Haiku / GPT-4.1-mini で実行すれば 0.1 円未満。

レイヤー 4: チャンク戦略

「1000 文字で分割」だけで運用している RAG は 2026 年時点で時代遅れだ。チャンク方式がそのまま Retrieval 品質を決める。

• Fixed-size: 古典的な N 文字分割。オーバーラップは 10～20%
• Recursive Character Splitting: 段落 → 文 → 語の順に再帰的に区切る。LangChain `RecursiveCharacterTextSplitter` のデフォルト
• Semantic Chunking: 連続文を embedding し、コサイン類似度の急変点で区切る。意味的に凝集したチャンクを作る
• Late Chunking (Jina 2024/2025): 長文全体を先に embedding モデルに通し、token 別 embedding を取ってから平均化してチャンクを作る。チャンクが周辺文脈を保持するため、代名詞や照応を失わない
• Hierarchical / Parent-Child: 小チャンクで検索し、親チャンクで生成に渡す。精度と文脈量を両立

Late Chunking の実装例:

```python from transformers import AutoModel, AutoTokenizer import torch

model = AutoModel.from_pretrained("jinaai/jina-embeddings-v3", trust_remote_code=True) tokenizer = AutoTokenizer.from_pretrained("jinaai/jina-embeddings-v3")

def late_chunking(long_text: str, chunk_boundaries: list[tuple[int, int]]): inputs = tokenizer(long_text, return_tensors="pt", truncation=True, max_length=8192) with torch.no_grad(): token_embeds = model(**inputs).last_hidden_state[0] chunk_embeds = [] for start, end in chunk_boundaries: chunk_embeds.append(token_embeds[start:end].mean(dim=0)) return torch.stack(chunk_embeds) ```

KGA で契約書 RAG に Late Chunking を導入した結果、「第 3 条に定める」のような相互参照が多い文書で Recall@10 が 71% → 88% まで改善した。

レイヤー 5: 評価指標とオフライン評価

Retrieval は「動いた」では評価できない。定量指標と回帰テストが必須だ。

• Recall@k: 正解ドキュメントが上位 k に含まれる割合。RAG の上限を決める最重要指標
• nDCG@10 (Normalized Discounted Cumulative Gain): 順位の質まで加味。商用検索のデファクト
• MRR (Mean Reciprocal Rank): 最初の正解までのランクの逆数平均。ユーザー体感に近い
• Hit Rate@k: 単純な「上位 k に正解があったか」の二値

評価セットは最低 100 クエリ、理想 500 クエリで作る。クエリと正解ドキュメント ID のペアを CSV で保持し、CI で回帰テストする。

```python import numpy as np

def ndcg_at_k(ranked_ids: list[str], relevance: dict[str, int], k: int = 10) -> float: gains = [relevance.get(doc_id, 0) for doc_id in ranked_ids[:k]] dcg = sum((2 g - 1) / np.log2(idx + 2) for idx, g in enumerate(gains)) ideal_gains = sorted(relevance.values(), reverse=True)[:k] idcg = sum((2 g - 1) / np.log2(idx + 2) for idx, g in enumerate(ideal_gains)) return dcg / idcg if idcg > 0 else 0.0 ```

LlamaIndex の `RetrieverEvaluator`、RAGAS、Trulens などのフレームワークがこれらの計算を標準化しているため、自作するよりまず RAGAS を入れるのが 2026 年の定石。

本番リファレンス構成

KGA が 2026 年に提案している本番 RAG の標準構成は次のとおり。

• Ingest: 文書 → Late Chunking（Jina v3）→ parent/child 保存
• Index: pgvector or Qdrant に dense + sparse の両方を格納
• Query: Multi-Query（LLM で 3 バリエーション生成）
• First-stage: Hybrid BM25 + Dense → RRF 融合で top 100
• Second-stage: Cohere Rerank-3 で top 10 に圧縮
• Generation: top 10 を Claude Opus 4.7 に渡し最終回答
• Eval: 500 クエリの回帰テストを毎週 CI で走らせ、nDCG@10 / MRR / Recall@20 の閾値割れをブロック

この構成を厳密に組めば、「LLM を変えなくても RAG が賢くなる」体験が実際に出る。Retrieval こそが RAG の腹であり、2026 年のプロジェクト投資の最優先レイヤーだ。