RAGとは?仕組みと構築の流れをベクトル検索の基礎から徹底解説【2026年版】

生成AIを業務に組み込もうとしたとき、多くのチームが最初にぶつかる壁は「LLMは賢いが、自社の最新情報も社内文書の中身も知らない」という事実である。LLMは学習データの時点で知識が止まっており(knowledge cutoff)、知らないことを聞かれても自信満々に誤った答えを返すことがある(ハルシネーション、hallucination)。この2つの問題に対する最も実務的な解が RAG(Retrieval-Augmented Generation、検索拡張生成) である。RAGは一言でいえば、LLMに答えさせる前に外部知識源から関連情報を検索し、その情報をプロンプトに含めたうえで生成させる仕組みである。LLM自身のパラメータ(parametric memory)だけに頼らず、検索可能な外部データ(non-parametric memory)を都度参照することで、根拠のある最新の回答を返せるようにする。

この考え方を最初に定式化したのが、Patrick Lewisらが2020年に発表した論文である。RAGは「事前学習済みのパラメトリックメモリ(BARTのようなseq2seqモデル)と、非パラメトリックメモリ(DPRで検索する密ベクトル索引化されたWikipedia)を組み合わせたモデル」として定義され、検索結果全体を通じて1つの生成をする RAG-Sequence と、生成トークンごとに異なる検索結果を参照できる RAG-Token の2方式が提案されている( Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, NeurIPS 2020, arXiv:2005.11401 )。この論文が示した「検索と生成を組み合わせる」という発想は、当初は学術的なオープンドメインQAのための手法だったが、2023年以降のLLM実用化ブームの中で、企業が自社データをLLMに扱わせるための最も基本的な設計パターンへと転用された。

本記事はこのRAGを、実装の視点から基礎から解説する入門記事である。すでに当ブログでは、RAGを支える中核技術であるベクトル検索・ANN(近似最近傍探索)について、原理から ANN基礎編で、実装についてMilvus編・OpenSearch編でそれぞれ深掘りしている。本記事はその「入口」として、RAG全体のパイプラインを俯瞰し、各要素技術がどう組み合わさって1つのシステムになるのかを示す。ベクトル検索そのものの詳細アルゴリズムや距離計算については適宜シリーズ既存記事に譲り、本記事ではRAG特有の関心事——チャンキング、検索品質の改善、生成側の設計、評価、そして基盤選定——に絞って掘り下げる。

1. RAG(検索拡張生成)とは

なぜRAGが必要か

LLMが抱える構造的な限界は主に3つある。1つ目は知識カットオフで、LLMは学習データが収集された時点までの情報しか持たず、それ以降に起きた出来事や更新された事実には対応できない。2つ目はハルシネーションで、LLMは統計的にもっともらしい文を生成する仕組み上、事実として検証されていない内容でも流暢に生成してしまうことがある。RAGは外部知識ベースを検索し関連情報を取得することでこの知識限界を緩和する仕組みであり、生成内容を検証可能な情報源に紐づけることでハルシネーションの抑制にも寄与するとされている( Hallucination Mitigation for Retrieval-Augmented Large Language Models: A Review, MDPI 2025 )。3つ目は社内データで、契約書・議事録・仕様書・サポート履歴のような組織固有の情報はそもそもLLMの学習データに含まれておらず、ファインチューニングでこれを都度反映させるのはコストが高く現実的でない。RAGはこれらのデータをベクトルデータベースなどの外部索引として保持し、必要なときだけ検索して読ませることで、LLM本体を再学習せずに知識を拡張できる。

RAGの一言定義

RAGとは、ユーザーの質問に対してまず外部の知識源から関連文書を検索(Retrieval)し、その検索結果をプロンプトのコンテキストとしてLLMに渡した上で回答を生成(Generation)させる、検索と生成を組み合わせたアーキテクチャである。生成そのものはLLMの能力に委ねつつ、「何を知っているか」の部分を検索可能な外部データに置き換えることで、更新性・検証可能性・スコープの限定という3つの利点を同時に得られる点が、ファインチューニングにはない強みである(ファインチューニングとの使い分けはFAQで扱う)。

2. RAGの仕組み: 4つのステップ

RAGのパイプラインは、実行タイミングの異なる2つの経路からなる。1つは事前に一度だけ(あるいはデータ更新のたびに)実行される 取り込みパイプライン、もう1つはユーザーがクエリを投げるたびに実行される クエリパイプライン である。図2-1がこの全体像である。

RAGの全体フローを示す図。上段は取り込みパイプラインで元データ→チャンキング→埋め込み→索引化の順に処理し、下段はクエリパイプラインでユーザークエリ→クエリ埋め込み→ベクトル検索→コンテキスト合成→LLMが生成の順に処理する。索引化されたデータはベクトル検索から参照される。

図2-1: RAGの全体フロー。取り込みパイプライン(オフライン)で構築した索引を、クエリパイプライン(オンライン)が繰り返し検索する。

取り込みパイプラインは次のように進む。まず元データ(社内文書・PDF・Wikiページなど)を集め、扱いやすい単位に チャンキング(分割) する。次に各チャンクを 埋め込みモデル によって固定長のベクトルに変換し、そのベクトルをベクトルデータベースに 索引化 する。ここまでがオフラインで完結する準備作業である。

クエリパイプラインはユーザーが実際に質問したときに動く。ユーザーのクエリを取り込み時と同じ埋め込みモデルでベクトル化し、索引に対して ベクトル検索(ANN) を行って関連度の高いチャンクを取得する。取得したチャンクを コンテキストとしてプロンプトに合成 し、それをLLMに渡すことで根拠付きの回答を生成させる。「文書側」と「クエリ側」を同一の埋め込みモデルで同じベクトル空間に写像することが、この2つのパイプラインをつなぐ鍵であり、モデルを変更する際は原則として索引の再構築(再埋め込み)が必要になる点に注意したい。

以降の章では、この4ステップ——チャンキング(第3章)、埋め込みとベクトル検索(第4章)、検索品質の改善(第5章)、生成側の設計(第6章)——を順に掘り下げ、最後に評価(第7章)とベクトルDB選定(第8章)を扱う。

3. チャンキング戦略: 固定長・意味単位・オーバーラップ

チャンキングとは、元の文書を検索・埋め込みに適した単位に分割する処理である。埋め込みモデルには最大入力長の制約があり、また検索の粒度が粗すぎると無関係な情報が混ざり、細かすぎると文脈が失われるため、チャンキングの設計はRAGの精度に直結する。

固定長チャンキング

最も単純な方法は、文字数やトークン数を基準に一定の長さで区切る固定長チャンキングである。実務では200〜500トークン程度のチャンクサイズがよく使われ、文の途中で意味が分断されるのを防ぐために、隣接チャンク間に10〜20%程度のオーバーラップ(重複)を持たせるのが一般的な出発点とされる( Weaviate: Chunking Strategies for LLM Applications )。オーバーラップを設けると、ある文がちょうどチャンクの境界をまたいでいても、少なくとも片方のチャンクには文全体が収まる可能性が高くなる。単純な固定長分割の弱点は、意味的に連続する情報が機械的に分断されてしまうことで、これを緩和する改良として、見出しや段落などの構造的な区切りを優先しつつ長さの上限を守る再帰的チャンキング(recursive chunking)もよく使われる。

意味単位チャンキング

意味単位チャンキング(semantic chunking)は、文単位の埋め込みを計算し、隣接する文同士の埋め込み類似度が閾値を下回った(=話題が変わった)地点でチャンクを区切る手法である。文字数ではなく意味的なまとまりで分割するため、複数の話題を含む長い文書(論文やレポートなど)では固定長分割より高い検索精度が期待できる。一方で、文ごとに埋め込み計算が必要になるぶん前処理コストが高く、また閾値の設定次第でチャンクサイズが不安定になりやすいという運用上の難しさもある。

トレードオフと実務的な指針

チャンキング戦略の選定は、常に「文脈の保持」と「検索の精度」のトレードオフである。チャンクを大きくすると1チャンクに含まれる文脈は豊かになるが、無関係な情報が混入しやすくなり、埋め込みベクトルが「薄まって」検索の的中率が下がる。逆にチャンクを小さくすると検索の的中率は上がりやすいが、1チャンクだけでは意味が完結せず、生成時に文脈不足を起こしやすい。ログや会話履歴のような構造の薄いデータには固定長・トークンベースの分割が扱いやすく、論文やマニュアルのように話題の切り替わりがはっきりしたデータには意味単位チャンキングが向く、という使い分けが一般的な指針とされる。実務では、まず固定長+オーバーラップというシンプルな構成でベースラインを作り、検索精度が伸び悩む箇所だけ意味単位チャンキングや構造認識分割(見出し・表・コードブロックを尊重する分割)に切り替えていくのが手戻りの少ない進め方である。

4. 埋め込みとベクトル検索

埋め込みモデルの役割

チャンキングで作られた各チャンクは、埋め込みモデルによって固定長の実数ベクトルに変換される。埋め込みモデルは「意味的に近い文章は、ベクトル空間上でも近い点に写像される」ように学習されており、この性質があって初めて「ベクトルの近さ」で「意味の近さ」を近似できる。次元数はモデルによって異なり、例えばOpenAIのtext-embedding-3-smallは1536次元、多言語対応のBAAI/bge-m3は1024次元のベクトルを出力する( OpenAI: New embedding models and API updates 、 BGE-M3 model card, NVIDIA Build )。次元数が大きいほど表現力は高くなりやすい一方、索引のメモリ使用量も比例して増える。

2つのベクトル \(\mathbf{a}, \mathbf{b}\) の意味的な近さは、多くの場合コサイン類似度で測る。

\[ \text{sim}(\mathbf{a}, \mathbf{b}) = \frac{\mathbf{a} \cdot \mathbf{b}}{\|\mathbf{a}\| \, \|\mathbf{b}\|} \]

これはベクトルの向きだけを比較し大きさ(ノルム)を無視する指標で、文章の長さの違いに左右されにくいという性質から埋め込み検索でよく採用される。ベクトルが正規化済み(ノルムが1)であれば、コサイン類似度は内積計算と等価になり計算コストを削減できる。

ANNによる近似探索

チャンク数が数百万を超える規模になると、クエリベクトルと全チャンクのベクトルとの距離を総当たりで計算する厳密探索(brute-force kNN)は計算コストの面で非現実的になる。そこで実務では、真の最近傍を保証する代わりに高い確率でそれに近い集合を大幅に少ない計算量で返す ANN(Approximate Nearest Neighbor: 近似最近傍探索) が使われる。HNSW・IVF・PQ・DiskANNといった代表的なANNアルゴリズムの仕組み、curse of dimensionality(次元の呪い)がなぜ近似探索を必要にするのか、そしてrecall(再現率)やQPS(1秒あたりのクエリ処理数)の測り方については、 ANN基礎編で数式とアルゴリズムのレベルまで掘り下げているので、詳しく学びたい読者はそちらを参照してほしい。本記事では「RAGの検索ステップは、内部的にはANNによる近似最近傍探索である」という関係だけ押さえておけば十分である。

5. 検索品質の改善: ハイブリッド検索・リランキング・クエリ変換

素朴なベクトル検索だけでは、実務のクエリに対して十分な精度が出ないことが多い。ここでは代表的な3つの改善手法——ハイブリッド検索、リランキング、クエリ変換——を扱う。図5-1がこれらを組み合わせた典型的なパイプラインである。

検索品質改善の流れを示す図。クエリがBM25検索とベクトル検索の両方に渡され、それぞれの結果がRRFで統合されて上位候補となり、cross-encoderによるリランキングでさらに並べ替えられる。

図5-1: ハイブリッド検索(BM25+ベクトル検索をRRFで統合)とcross-encoderリランキングを組み合わせた検索品質改善パイプライン。

ハイブリッド検索とRRF

ベクトル検索は意味的な近さに強い一方、固有名詞や型番のような「表記の完全一致」が重要な検索には弱い。逆にBM25のような全文検索は完全一致に強いが語彙のミスマッチに弱い(この対比の詳細は ANN基礎編第1章を参照)。この相補性を活かし、両方の検索を実行して結果を統合するのがハイブリッド検索である。統合方法としてよく使われるのが Reciprocal Rank Fusion(RRF) で、各検索結果リストの「生スコア」ではなく「順位」だけを使って文書 \(d\) の統合スコアを次式で計算する。

\[ \text{RRF}(d) = \sum_{i} \frac{1}{k + \text{rank}_i(d)} \]

ここで \(\text{rank}_i(d)\) は \(i\) 番目の検索結果リストにおける \(d\) の順位、\(k\) は平滑化パラメータで経験的に \(k=60\) が広く使われる( Cormack et al., “Reciprocal Rank Fusion outperforms Condorcet and Individual Rank Learning Methods”, SIGIR 2009 、 Milvus: RRF Ranker )。RRFはスコアのスケールが全く異なるBM25とベクトル検索の結果を、順位という共通のものさしだけで公平に統合できる点が実務上の強みである。

リランキング(cross-encoder)

ベクトル検索やハイブリッド検索は「クエリと文書を別々に埋め込んでから比較する」ため、大規模な索引に対しても高速だが、両者を独立にベクトル化する(bi-encoder方式)ぶん精度には限界がある。これに対し cross-encoder は、クエリと文書のペアを同時に1つのモデルに入力し、その組み合わせに特化したスコアを直接出力する。cross-encoderはクエリと文書のペアごとにモデルの順伝播が必要になるため索引全体には使えないが、実務では第一段階の検索(ベクトル検索やハイブリッド検索)で上位50〜100件程度まで候補を絞り込んだあと、その候補だけをcross-encoderで精査して並べ替える2段階構成(two-stage retrieval)が定石になっている( Pinecone: Rerankers and Two-Stage Retrieval )。この一手間により、LLMに渡す最終的な上位k件の精度を大きく引き上げられる。

クエリ変換

ユーザーの入力するクエリは曖昧・短すぎる・専門用語とずれているといった理由でそのまま検索に使うと精度が出ないことがある。そこで、検索前にLLM自身にクエリを書き換えさせる クエリ変換(query transformation) もよく併用される。代表的な手法が HyDE(Hypothetical Document Embeddings) で、クエリに対してLLMにいったん「回答になりそうな仮想文書」を生成させ、その仮想文書を埋め込んでベクトル検索のクエリとして使う。生成された仮想文書の事実関係が正しいかどうかは問わず、意味的なパターンが実際の関連文書と一致しやすいことを利用した手法である( Gao et al., “Precise Zero-Shot Dense Retrieval without Relevance Labels”, arXiv:2212.10496 )。ほかにも、複数の言い換えクエリを生成して結果を統合するマルチクエリや、複雑な質問をより単純なサブクエリに分解するクエリ分解も、実務でよく使われるクエリ変換の一種である。

ベクトル検索実践入門(真鍋知博、技術評論社)

Yahoo!ショッピングで見る楽天ブックスで見る Amazonで見る

6. 生成側の設計: コンテキストの詰め込み方と引用

検索がどれほど高精度でも、取得したチャンクをLLMにどう渡すかによって最終的な回答品質は大きく変わる。

コンテキストへの詰め込み方

検索で得た上位k件のチャンクは、そのままプロンプトに列挙するのが基本形だが、順序にも注意が必要である。長いコンテキストを扱う言語モデルは、関連情報がコンテキストの先頭または末尾にあるときに性能が高く、中間に埋もれていると著しく性能が落ちるU字型の傾向を示すことが報告されている(いわゆる “lost in the middle” 現象、 Liu et al., “Lost in the Middle: How Language Models Use Long Contexts”, TACL 2024, arXiv:2307.03172 )。この知見を踏まえると、リランキングで得た最重要のチャンクをコンテキストの先頭または末尾に配置する、関連度の低い順から高い順へ並べる(最も重要な情報を末尾=クエリの直前に置く)といった並べ替えの工夫が、同じ検索結果からでも回答品質を引き上げる手段になる。

引用の付け方

RAGの実務的な利点の1つは、回答の根拠を提示できることである。プロンプト側で各チャンクに文書ID・出典URL・ページ番号などのメタデータを付与し、「回答するときは参照した番号を明記すること」という指示をシステムプロンプトに含めることで、LLMに脚注形式の引用を出力させられる。これにより、ユーザーは回答の裏付けとなった一次情報に遡って確認でき、生成内容が検証可能になるというRAGの本来の狙いが実現される。

コンテキストウィンドウとの付き合い方

コンテキストウィンドウが大きいモデルほど多くのチャンクを詰め込めるが、これは「詰め込めば詰め込むほど良い」という意味ではない。トークン数が増えれば推論コストとレイテンシが増加するうえ、前述のlost in the middle現象のように無関係なチャンクの混入がかえって回答品質を下げることもある。実務では「検索で広めに候補を取り、リランキングで絞り込み、最終的にコンテキストへ渡すのは精査後の上位数件」という第5章の2段階構成が、コンテキストウィンドウの使い方としても合理的な設計になる。

7. RAGの評価: retrieval評価とgeneration評価

RAGの評価は「検索は正しく機能しているか」と「生成は検索結果に忠実か」という、性質の異なる2つの問いに分けて考える必要がある。

retrieval評価: recall@k

検索ステップの評価では、上位k件の検索結果の中に正解(関連)文書がどれだけ含まれているかを表す recall@k が基本指標になる。recallの厳密な定義や、候補数パラメータを振りながらrecallと検索速度(QPS)を同時に測定するrecall-QPSトレードオフ曲線の描き方、ベンチマーク設計時の注意点(ウォームアップ、キャッシュ状態の統制など)については、 ANN基礎編の評価に関する章で詳しく扱っているので参照してほしい。RAGにおいては、この検索精度がそもそも低ければ、後段の生成がどれだけ優れていても正しい回答は望めない点に注意が必要である。

generation評価: faithfulness・answer relevancy

生成ステップの評価には、検索評価とは異なる指標が必要になる。この領域で広く使われるオープンソースの評価フレームワークがRAGAS(RAG Assessment)で、代表的な指標として次の4つを定義している( Ragas: Metrics )。

Faithfulness(忠実性): 生成された回答が、検索されたコンテキストの内容にどれだけ忠実か。コンテキストにない情報を回答に含めていないかを測る、ハルシネーション検出に直結する指標。
Answer Relevancy(回答関連性): 生成された回答が、ユーザーの質問にどれだけ的確に答えているか。
Context Precision(コンテキスト精度): 検索されたコンテキストのうち、実際に回答生成に関連していた割合。
Context Recall(コンテキスト再現率): 正解を導くために必要な情報が、検索されたコンテキストにどれだけ網羅されていたか。

このうちContext PrecisionとContext Recallは検索の質を、FaithfulnessとAnswer Relevancyは生成の質を評価する指標であり、多くはLLM自身を評価者として使う(LLM-as-judge)ことでスコアを算出する。人手評価に比べて低コストで反復実行できる一方、評価に使うLLM自体の癖やバイアスがスコアに混入しうる点は留意しておきたい。実務では、まずrecall@kで検索段階のボトルネックがないかを切り分け、そのうえでFaithfulnessとAnswer Relevancyで生成段階の品質を継続的にモニタリングするという2段構えの評価体制が現実的である。

8. ベクトルDBの選定と2026年の潮流

Milvus・OpenSearchという2つの選択肢

RAGの索引を実際にどこに置くかという問いに対して、実務でよく候補に挙がるのが、専用ベクトルデータベースの代表格である Milvus と、全文検索エンジンにベクトル検索機能を統合した OpenSearch である。両者はどちらも内部的にはHNSWやIVFといった同じANNアルゴリズムを実装しているが、「ベクトル検索専業の分散システム」として生まれたMilvusと、「全文検索エンジンにベクトル検索を後付けした」OpenSearchでは、書き込み直後のデータがいつ検索に反映されるかという鮮度・一貫性の設計や、運用に必要なスキルセットが大きく異なる。既存資産の有無・一貫性要件・フィルタ選択率・運用チームのスキルセットという4つの軸で判断するフレームについては、 Milvus内部構造編と OpenSearch内部構造編でそれぞれのアーキテクチャを掘り下げたうえで、 ANN基礎編の比較章で詳しく整理している。RAGの索引としてどちらを選ぶ場合も、まずはrecallを揃えたうえで自分たちのデータとクエリパターンでPoCを行い、実測で確かめることが最終的な判断の拠り所になる。

2026年の潮流: agentic RAG

2026年時点でRAGの議論の中心にあるのが agentic RAG という潮流である。従来のRAGは「検索して生成して終わり」という一方向のパイプラインだったが、agentic RAGでは、質問の複雑さに応じて検索戦略そのものを動的に切り替えたり(質問の難易度を分類するクラシファイアで、検索なし・単発検索・複数ステップ検索を使い分けるAdaptive-RAGはその代表例、 Jeong et al., “Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity”, NAACL 2024, arXiv:2403.14403 )、1回の検索で不十分だと判断したエージェントが自ら検索クエリを立て直して再検索を繰り返す(マルチホップ検索)構成が主流になりつつある。「検索→生成」という単発の処理ではなく、「思考→検索→再考→再検索→行動」というループとしてRAGを組み込むこの発想は、単純なFAQ応答を超えて、複数文書にまたがる根拠を集めて回答する複雑なタスクへとRAGの適用範囲を広げている。

まとめ

RAGは、LLMのハルシネーションと知識カットオフという構造的な限界を、外部の検索可能な知識源で補うアーキテクチャである。その仕組みは、チャンキングと埋め込みによってデータを検索可能な形に変換する取り込みパイプラインと、クエリを検索してコンテキストを合成し生成させるクエリパイプラインという2段構成に整理できる。素朴なベクトル検索だけでは実務水準の精度が出にくいため、BM25とベクトル検索を組み合わせるハイブリッド検索、少数の上位候補をcross-encoderで精査するリランキング、クエリそのものを書き換えるクエリ変換といった改善手法を組み合わせるのが実務の定石である。評価はretrieval(recall@k)とgeneration(faithfulness・answer relevancyなど)を分けて考え、最後にどの基盤にこの仕組みを載せるかは、既存資産・一貫性要件・運用スキルに照らして判断する。RAGの核心にあるベクトル検索・ANNの原理をさらに深く理解したい読者は、ぜひ ANN基礎編から読み進めてほしい。

よくある質問(FAQ)

Q. RAGとファインチューニングの違いは何ですか?

ファインチューニングはLLMのパラメータ自体を追加データで再学習させる手法で、モデルに新しい「振る舞い」や「文体」を覚えさせるのには向くが、事実知識を頻繁に更新したい用途にはコストと鮮度の両面で不利になりやすい。RAGはLLM本体を変更せず、外部の検索索引を更新するだけで最新情報を反映できるため、更新頻度の高いデータや検証可能性が求められる用途に向く。両者は排他的ではなく、出力形式や振る舞いをファインチューニングで整えつつ、事実知識はRAGで供給するという併用も実務では一般的である。

Q. RAGに向くデータ・向かないデータは何ですか?

社内文書・マニュアル・FAQ・議事録のように、テキストとして検索可能で、かつ更新頻度が高い、あるいはLLMの学習データに含まれていないデータはRAGに向く。逆に、単純な四則演算や厳密な手順に基づく処理のように「検索」ではなく「計算・実行」が必要なタスク、あるいは文書化されておらず暗黙知としてしか存在しない情報はRAGだけでは対応できない。

Q. 精度が出ない時にまず見るべきポイントは何ですか?

まず切り分けるべきは、検索(retrieval)と生成(generation)のどちらに問題があるかである。第7章で触れた通り、検索段階のrecall@kが低ければ、そもそも正解に必要な情報がLLMに渡っていないので生成側をいくら調整しても改善しない。次に疑うべきはチャンキングで、チャンクサイズやオーバーラップが不適切だと、情報はあるのに検索でヒットしない、あるいはヒットしても文脈が欠落しているという状態になりやすい。検索精度が確保できているのにFaithfulnessが低い場合は、コンテキストの詰め込み方(第6章)やプロンプトの指示文を見直すのが次の一手になる。

Q. ベクトルDBはどれを選べばいいですか?

万能の正解はなく、既存のインフラ資産、書き込み直後データの一貫性要件、フィルタ検索の選択率、運用チームのスキルセットという軸で判断する。すでにOpenSearch/Elasticsearchの運用資産があるならOpenSearchへの統合コストが低く、書き込み直後の一貫性を厳密に制御したい、あるいはベクトル検索の性能を突き詰めたい場合はMilvusが有力になりやすい。詳しい判断フレームは ANN基礎編、それぞれの内部構造は Milvus内部構造編・ OpenSearch内部構造編を参照してほしい。