目次
RAGとは何かは分かった。だが実際に作ってみると、多くの人が 「なんとなく動くけど、肝心の答えがズレる」壁にぶつかる。原因はほぼ決まっている——「文書を雑に切って・素朴にベクトル検索しただけ」の『素朴RAG』のままだからだ。
2026年の実用RAGは、そこから明確に進化している。鍵は 「賢いチャンク分割 → 適切な埋め込み → ハイブリッド検索（キーワード＋ベクトル）→ 再ランク（reranking）」という多段パイプライン。本記事は030の 実装編として、各工程の具体的なやり方、ベクトルDBの選び方（Chroma/pgvector/Qdrant/Pinecone/Weaviate/Milvus）、フレームワーク、そして 「1Mトークン時代にRAGはまだ要るのか」まで、一歩進んだ実装の勘所を解説する。
現代的RAGの5工程
— 素朴RAGから「本番で効く」RAGへ
精度を上げる二大施策：ハイブリッド検索（BM25＋ベクトル）と再ランク。
この2つを足すだけで、素朴RAGの「答えがズレる」問題は大きく改善する。
※ツール名・手法・ベンチ数値は各公式および複数の技術メディア（2026年時点）に基づく。この分野は進化が速く、最適解は更新され得る。ベンチ値は出典の公称で、データ・条件により変動する。自分のデータで評価（後述）して選ぶこと。
1. 復習：素朴RAGの限界
RAGの最小構成は 「文書を切る → 埋め込みでベクトル化 → ベクトルDBに保存 → 質問もベクトル化して近いチャンクを取得 → LLMに渡して回答」。これが RAGの基本だ。だがこの「素朴RAG（naive RAG）」には典型的な弱点がある。
- チャンクが雑：文の途中で切れ、意味が分断される。
- ベクトル検索だけ：「製品名」「型番」などの正確な語に弱い（意味は近いが語が違うものを拾う/逃す）。
- 上位N件をそのまま渡す：本当に関連の高いものが埋もれる。
2026年の実用RAGは、この3点を 「賢い分割」「ハイブリッド検索」「再ランク」で潰す。順に見ていく。
2. 現代的RAGパイプラインの全体像
本番RAGのデータフローは2系統ある。事前準備（インデックス作成）と クエリ時（検索＆生成）だ。
2つのフェーズ
準備（オフライン）：文書を 賢くチャンク分割 → 埋め込みでベクトル化 → ベクトルDBに格納（キーワード索引も同時に作る）。
クエリ時（オンライン）：質問を ハイブリッド検索（BM25＋ベクトル）で上位50〜100件取得 → 再ランクで上位数件に精選 → LLMに渡して回答生成。
素朴RAGとの差は 「④ハイブリッド検索」と「⑤再ランク」が入っているか。この2工程が、検索の精度を実務レベルに引き上げる。
3. ① チャンク分割（最重要）
RAGの品質は チャンク分割で半分決まると言っていい。代表的な戦略を整理する。
| 戦略 | 内容 | 向いている文書 |
|---|---|---|
| recursive（再帰）512トークン | 実用的なデフォルト。2026年2月のベンチで7戦略中1位の報告 | まず迷ったらこれ |
| semantic（意味） | 文の意味が変わる箇所で区切る。各チャンクが話題的に一貫 | 密度の高い技術文書 |
| structural（構造） | 見出し・コードブロック・HTMLセクションを尊重 | ドキュメント・コード |
| parent-child（階層） | 小チャンクで精密に検索し、回答時は周囲の親チャンクを返す | 精度と文脈を両立したい |
境界での文脈欠落が課題なら、Contextual Retrieval（各チャンクに文書全体の文脈を付与）や Late Chunking が効く。Anthropicによれば Contextual Retrieval ＋ 再ランクで上位20件の検索失敗を最大67%削減したと報告されている（※公称値）。実装の起点は「recursive 512」、精度が足りなければ semantic / parent-child / Contextual Retrieval を足す——この順が現実的だ。
4. ② 埋め込みモデルの選び方
チャンクをベクトルに変換する 埋め込み（embedding）モデル。検索精度の土台になる。
- 無難な定番：OpenAI text-embedding-3-large。検索品質と導入しやすさのバランスが良い。
- 他の選択肢：Cohere・Voyage・Gemini の埋め込み、各種OSSモデル。
- 重要：多くのOSS埋め込みも、ハイブリッド検索＋再ランクと組み合わせれば本番で十分。埋め込み単体の優劣に固執しすぎない。
ポイントは 「埋め込みは検索パイプライン全体の一部品」と捉えること。高価な埋め込みに替えるより、ハイブリッド化と再ランクを足すほうが費用対効果が高いことが多い。
5. ③ ベクトルDBの選び方（比較表）
ベクトルを格納・検索する ベクトルDB。2026年の主要どころを性格別に。
| DB | 性格・強み | 向いている人 |
|---|---|---|
| Chroma | AIネイティブ・ローカル優先・シンプルなPython API | RAGを最速で試作したい個人/PoC |
| pgvector | Postgres拡張。第二のDBが不要、トランザクション整合 | 既にPostgresを使っている |
| Qdrant | 低レイテンシ（p50 約4ms、Milvus約6ms/Pinecone約8msとの比較報告） | 速度重視・本番 |
| Pinecone | フルマネージド。インフラ管理ゼロ、APIキーだけで開始 | 運用を任せたい・クラウド前提 |
| Weaviate | ハイブリッド検索の王者（BM25＋ベクトル＋メタデータを1クエリで） | ハイブリッド検索を厚く使う |
| Milvus | エンタープライズ級。数十億ベクトルを扱える | 超大規模 |
選定軸は 「規模・マネージド or 自前・既存スタック・予算」。迷ったら——試作は Chroma、Postgres があれば pgvector、本番でバランス重視なら Qdrant / Pinecone、ハイブリッド重視なら Weaviate。多くのRAGワークロードでは Pinecone / Weaviate / Qdrant が有力とされる。
6. ④ ハイブリッド検索（BM25＋ベクトル）
素朴RAGの最大の弱点「正確な語に弱い」を直すのが ハイブリッド検索だ。BM25（キーワード/語彙検索）と密ベクトル検索を融合する。
語彙 ＋ 意味 を融合する
2つを Reciprocal Rank Fusion（RRF） で合成すると、
どちらか単独より一貫して高い精度（NDCG）が出る、と報告されている。
実装上は、Weaviate のように 1クエリでハイブリッドを返すDBを使うのが楽。難しいスコア調整は RRF（順位ベースで融合）に任せれば、壊れにくい。「正確な語にも、言い換えにも強い」検索が、これで手に入る。
7. ⑤ 再ランク（retrieve-then-rerank）
2026年の標準は 「2段階：まず広く取得 → 次に精選（rerank）」だ。
- 1段階目（retrieve）：bi-encoder（埋め込み）で 上位50〜100件を高速に取得。
- 2段階目（rerank）：cross-encoder で (質問, チャンク) を一緒に採点し、本当に関連の高い数件に絞る。
代表的な再ランカーは Cohere Rerank 3.5・Voyage rerank-2.5・BGE reranker-v2・Jina Reranker v2。再ランクは50〜200msほどの遅延とコストを足すが、LLMに渡すチャンクが少数精鋭になるため、結果的に LLMのトークン消費が減り、総コストはむしろ下がることが多い。精度・コストの両面で、再ランクは「入れない理由がない」工程になりつつある。
8. フレームワーク（LlamaIndex/LangChain）
自前で全部書くより、フレームワークを使うのが速い。2026年の住み分けはこうだ。
- LlamaIndex：検索（retrieval）特化。文書インデックス・検索品質・RAGの素早い反復に強い。
- LangChain / LangGraph：オーケストレーション（制御）側。複雑なワークフローやエージェント連携。
- 併用パターン：LlamaIndex を検索層、LangGraph を制御層に組む構成が実務で多い。
なお近年は、MCP によるツール標準化や Agent SDK の台頭で、重厚なLLMフレームワークを使わず、エージェントがパイプラインをその場で組む流れも出てきた。とはいえ 検索品質を作り込むなら LlamaIndex 系は依然有力だ。エージェント構築全般は AIエージェントの作り方 も参照。
9. RAG vs ロングコンテキスト
「1Mトークンの文脈窓があれば、全部突っ込めばRAGは要らないのでは？」——よくある疑問だ。答えは 「ノー、RAGは置き換わらない」。
「全部突っ込む」の落とし穴
- トークン非効率：巨大で冗長な文脈を毎回送るのは高コスト。
- lost in the middle：長文の中盤の情報が無視されやすい。
- 注意の散漫化：無関係な情報が増えるほど回答品質が落ちる。
使い分けの指針：小さなコーパス・素早い試作はロングコンテキストで、安定して繰り返す文脈には プロンプトキャッシュを早めに、そして 「鮮度・規模・出典（provenance）」が要件になった瞬間にRAGを足す。「とりあえず文脈窓に突っ込む」は、かつての「とりあえずベクトルDB」と同じ——万能ではない。コンテキストウィンドウの理解も併せて。
10. 本番化の注意点
- 評価（eval）を最初に作る：「なんとなく良くなった」では改善できない。代表質問×期待出典のセットで検索精度を数値化し、施策ごとに比較する。
- 監視（monitoring）：検索ヒット率・再ランク後の関連度・回答の根拠を継続観測。
- コスト設計：埋め込み・再ランク・LLMの3つで課金が発生。再ランクでLLMトークンを減らすのがコスト削減の定石。トークン節約術参照。
- 鮮度と出典：データ更新の反映（再インデックス）と、回答に 出典（どの文書か）を必ず添える設計を。ハルシネーション対策の要。
- 機密データ：社内文書をベクトル化して外部に置く場合の取扱いに注意。企業のAI利用ガイドライン参照。
まとめ
実用RAGは、素朴な「切って・ベクトル検索」から 「賢い分割 → 埋め込み → ベクトルDB → ハイブリッド検索 → 再ランク」の多段パイプラインへ進化した。精度を一気に引き上げる二大施策は ハイブリッド検索（BM25＋ベクトルをRRFで融合）と 再ランク（retrieve-then-rerank）——この2つを足すだけで「答えがズレる」は大きく改善する。
ベクトルDBは 試作=Chroma、Postgres有=pgvector、本番=Qdrant/Pinecone、ハイブリッド重視=Weaviate。フレームワークは 検索=LlamaIndex、制御=LangChain/LangGraph。そして 1MトークンでもRAGは置き換わらない——鮮度・規模・出典が要るならRAGだ。最後に最重要を1つ:「評価セットを最初に作る」。測れないものは改善できない。これさえ守れば、あなたのRAGは「なんとなく」から「本番で効く」へ確実に進化する。
関連記事：RAGとは（基礎）、コンテキストウィンドウとは、AIエージェントの作り方、Claude Agent SDK、MCPとは も併読を。
FAQ
Q. RAGの精度が低いです。まず何を直すべき？
A. 「ハイブリッド検索」と「再ランク」の2つを足すのが最も効きます。素朴なベクトル検索だけだと、型番や固有名詞などの正確な語に弱く、関連の高いチャンクも埋もれがち。BM25との融合（RRF）＋ cross-encoder の再ランクで、検索品質が実務レベルに上がります。それでも足りなければチャンク分割を見直してください。
Q. ベクトルDBはどれを選べばいい？
A. 試作なら Chroma、既にPostgresがあるなら pgvectorが手軽。本番でバランス重視なら Qdrant（低レイテンシ）や Pinecone（フルマネージド）、ハイブリッド検索を厚く使うなら Weaviate、超大規模なら Milvus。規模・運用方針・既存スタック・予算で選びます。
Q. チャンクサイズはどれくらいが良い？
A. recursive 分割で512トークン前後が実用的なデフォルト（2026年のベンチで上位の報告）。技術文書なら semantic（意味で区切る）、ドキュメント/コードなら structural（見出し・コード尊重）、精度と文脈の両立なら parent-child が有効です。まず512で作り、評価しながら調整してください。
Q. 文脈窓が1Mトークンあれば、RAGは不要では？
A. 不要にはなりません。全部を文脈に突っ込むと、トークン非効率・「lost in the middle」・注意の散漫化で品質が落ちます。小さなコーパスや試作はロングコンテキスト、鮮度・規模・出典が要件になったらRAG、という使い分けが現実解です。
Q. LangChainとLlamaIndex、どちらを使う？
A. 検索品質を作り込むなら LlamaIndex、複雑な制御・エージェント連携なら LangChain/LangGraph。実務では「LlamaIndexを検索層、LangGraphを制御層」と併用する構成も多いです。近年はAgent SDKで軽量に組む流れもあるので、要件に応じて選んでください。
