検索拡張生成(RAG)
RAGの仕組み—Google AI Overviews、ChatGPT Search、Perplexityの背後にある「取得してから生成する」パターン—と、それがコンテンツが引用されるために何を意味するか。
言語
RAG(検索拡張生成)は、AI検索の背後にある「取得してから生成する」パターンです。クエリ時に2つのフェーズを実行します—取得(外部インデックスから関連パッセージを見つける)と拡張生成(それらのパッセージをLLMに渡して、根拠のある引用付きの回答を書かせる)—モデルの重みを変更することはありません。これが、AI回答がモデルのトレーニングカットオフを超えた情報をカバーする方法です。取得フェーズは、チャンキング→埋め込み→ベクトル検索→再ランキング→トップkパッセージのチェーンです。RAGは幻覚を減らしますが、排除するわけではありません—そして、取得されたコンテキストが不十分だと、幻覚を悪化させる可能性があります。SEOにとって、別のAIインデックスはありません:クロール可能で、インデックスされ、明確で自己完結したパッセージに構造化されていることが、取得され引用されるための前提条件です。
元のRAGアーキテクチャは、生成中に外部インデックスから取得した情報と言語モデルを組み合わせたものでした。 Evidence for this claim The original RAG paper combined a pretrained sequence-to-sequence model with a non-parametric dense-vector index retrieved during generation. Scope: Lewis et al.'s 2020 RAG architecture and experiments, not every modern retrieval system. Confidence: high · Verified: Lewis et al.: Retrieval-Augmented Generation 現代のプラットフォームドキュメントでは、同じ広義の「取得してから生成する」という考え方が使われています。 Evidence for this claim Google Cloud describes RAG as retrieving relevant information from external knowledge sources and providing it to a model to improve generated responses. Scope: General RAG architecture in Google Cloud documentation; quality depends on retrieval, source quality, and generation. Confidence: high · Verified: Google Cloud: RAG overview
TL;DR — RAG(Retrieval-Augmented Generation、検索拡張生成)は、AI検索エンジンが回答する前に情報を調べる仕組みです。システムは記憶だけで答えるのではなく、まず検索インデックスから関連する文章を取得し、次にその内容に基づいて回答を生成します。だからこそ、Google AI Overviews、ChatGPT Search、Perplexityは新しいウェブページを引用できるのです。そして、インデックスに登録されることが今も重要である理由でもあります。
RAGとは
大規模言語モデル(LLM、ChatGPTなどの背後にあるもの)は、トレーニング中に膨大なテキストから学習します。しかし、そのトレーニングには基準日があり、モデルがすべてを記憶できるわけではありません。そのため、単独では最近の事実やニッチな事実を知らないか、もっともらしく聞こえるでっち上げをしてしまうことがあります。
RAGは、モデルに情報を調べさせることでこれを解決します。 質問をすると、RAGシステムは次の2つのことを順番に行います。
- 取得(Retrieval) — インデックス(GoogleやBingなど)を検索し、質問に最も関連する文章を取得します。
- 拡張生成(Augmented generation) — その文章をLLMに渡し、LLMはそれらに基づいて回答を作成し、通常はソースへのリンクを表示します。
最も簡単なイメージは、AIが記憶だけで答えるのではなく、まず宿題をするということです。
簡単な例
AI検索エンジンに「最新のiPhoneで何が変わった?」と尋ねてみてください。モデルは先週発売された製品についてトレーニングされていません。RAGを使えば、ウェブを検索し、最近の記事をいくつか取得し、それらから回答を作成します。クリックできる引用付きです。RAGがなければ、「知らない」と言うか、推測するかのどちらかでしょう。
あなたにとっての重要性
ここが人々を驚かせる部分です。RAGは別の「AIインデックス」を使いません。 Google AI OverviewsはGoogleの通常の検索インデックスから取得します。ChatGPT SearchはBingのインデックスで開始され、独自のクローラー(OAI-SearchBot)も実行しています。OpenAIは現在、この2つがどのように混在しているかを正確には発表していません。いずれにせよ、これまで常に重要だった基本事項(クロール可能であること、インデックスに登録されること、明確に書くこと)が、まさにあなたのコンテンツがAIの回答で取得・引用されるかどうかを決定します。
もう1つ知っておくべきこと:RAGは誤った回答(幻覚)を減らしますが、完全になくすわけではありません。AIは取得した内容を読み間違える可能性があります。したがって、トピックについて最も明確で、最も直接的な情報源であることが本当に役立ちます。
実際の仕組み(埋め込み、チャンキング、再ランキング、ナイーブRAGとエージェント型RAG、そしてSEOのプレイブック)を知りたいですか? Advancedタブに切り替えてください。
Lewisらによる2020年のシステムは、非パラメトリックインデックスからの高密度検索とシーケンス生成を組み合わせたものでした。 Evidence for this claim The original RAG paper combined a pretrained sequence-to-sequence model with a non-parametric dense-vector index retrieved during generation. Scope: Lewis et al.'s 2020 RAG architecture and experiments, not every modern retrieval system. Confidence: high · Verified: Lewis et al.: Retrieval-Augmented Generation Google Cloudの現在の概要では、RAGを、取得した外部知識をモデルに供給することとしてより広く定義しています。 Evidence for this claim Google Cloud describes RAG as retrieving relevant information from external knowledge sources and providing it to a model to improve generated responses. Scope: General RAG architecture in Google Cloud documentation; quality depends on retrieval, source quality, and generation. Confidence: high · Verified: Google Cloud: RAG overview
TL;DR — RAGは、2段階の推論時パターンです。取得(外部コーパスから関連する文章を見つける)、次に拡張生成(その文章をLLMに渡して、根拠のある引用付きの回答を生成する)です。重みは変わりません。モデルのパラメトリックメモリと、ライブで取得された非パラメトリックメモリを組み合わせます。取得フェーズは、チャンキング → 埋め込み → ベクトル検索 → 再ランキング → top-k の順に連鎖します。「ナイーブ」RAGは取得してから生成するものです。高度なRAGはクエリ書き換えと再ランキングを追加します。エージェント型RAGは、反復的でマルチホップの取得を追加します。取得は回答の根拠を提供できますが、正確性を保証するものではありません。あるGemmaの評価では、不十分なコンテキストが誤った回答の増加と関連していました。SEOにとっては、別のAIインデックスは存在しません。クロール可能性、インデックス登録、文章レベルの明確さが、取得されるための前提条件です。
2つのフェーズ(そして「推論時」がすべてである理由)
Five stages run left to right at inference time. Chunking splits documents into retrievable passages. Embeddings represent each passage as a dense vector. Vector search retrieves candidates and some systems combine it with BM25 keyword search. Re-ranking re-scores and narrows the candidate set. The top surviving passages enter the model context. The model's weights do not change.
© Patrick Stox LLC · CC BY 4.0 ·
Two sources feed one generation step. Parametric memory is knowledge encoded in the model weights during training and is limited by the training data and cutoff. Non-parametric memory consists of passages retrieved from an external index at query time. Generation uses both while the weights remain unchanged, producing an answer that can be grounded in and cite the retrieved sources; this does not guarantee correctness.
© Patrick Stox LLC · CC BY 4.0 ·
頭字語を分解すると、モデルが見えてきます。検索(Retrieval) と 拡張生成(Augmented Generation) です。クエリが入ると、システムは外部コーパスから最も関連性の高いパッセージを取得し、それらをLLMのコンテキストウィンドウに注入し、LLMはそれらに基づいて回答を生成します。
誰もが間違える詳細:これは推論時に行われ、モデルの重みは決して変更されません。 RAGはトレーニングでもファインチューニングでもありません。Facebook AI ResearchのPatrick Lewisらによる2020年の元の論文では、これを2種類のメモリの組み合わせとして位置づけていました。パラメトリックメモリ(トレーニング中に重みに組み込まれる知識)とノンパラメトリックメモリ(インデックスからライブで取得される知識)です。RAGは両方を同時に使用します。AWSは実際的なケースを明確に述べています。新しい知識やドメイン固有の知識を得るために基盤モデルを再トレーニングするのは高コストであり、「RAGはLLMに新しいデータを導入するためのより費用対効果の高いアプローチです。」
(ちなみに、この名前は偶然でした。Lewisは後に認めています:「私たちの研究がこれほど広まるとは知っていたら、名前にもっと考えを込めていたでしょう… 私たちは常にもっと良い名前を計画していましたが、論文を書く時が来たとき、誰も良いアイデアを持っていませんでした。」)
検索フェーズの内部
「関連パッセージを取得する」というのは、その文では多くのことを担っています。実際のシステムでは、これはパイプラインです:
- チャンキング。 ドキュメントは取得可能な断片に分割されます。チャンクサイズは実際のトレードオフです。小さすぎるとパッセージが文脈を失い、大きすぎるとトークン予算を無関係なもので溢れさせます。戦略は、固定トークン数(100/256/512)から再帰的/スライディングウィンドウ、「Small2Big」(小さな文を取得し、生成用に親チャンクを返す)まで多岐にわたります。
- 埋め込み。 各チャンクは密ベクトル(その意味の数値表現)に変換され、類似性はキーワード一致ではなく意味的に計算されます。これが、トピックについてのコンテンツが、正確なクエリ表現を使用していなくても取得される理由です。
- ベクトル検索。 クエリも埋め込まれ、システムはそのベクトルが最も近いチャンクを見つけます。ほとんどの本番スタックはハイブリッド検索(密ベクトル検索プラスBM25キーワード検索)を実行します。なぜなら、それぞれが他方が見逃す再現率を捕捉するからです。
- 再ランキング。 別のモデルがクエリへの関連性によって候補を再スコアリングし、並べ替えます。「全体的なドキュメントプールを効果的に削減します。」 上位の生き残りだけがコンテキストに入ります。
- プロンプトへのTop-k。 最良のパッセージがユーザーのクエリと連結され、生成器に渡されます。
チャンキングは脆弱なリンクです。Anthropicは、*「従来のRAGソリューションは情報をエンコードする際にコンテキストを除去する」*と特定しました。チャンクがドキュメントから取り出されると、それを意味のあるものにしていた周囲のコンテキストを失います。彼らのContextual Retrieval技術(インデックス作成前にチャンク固有のコンテキストを前置する)は、失敗した取得を**49%削減し、再ランキングと組み合わせると67%**削減しました。これは、チャンキング問題が現実であること、そして自己完結型でコンテキスト豊富なパッセージが正しく取得しやすいことを示す強いシグナルです。
ナイーブ、アドバンスト、エージェンティックRAG
調査文献(Gao et al., 2023)はRAGを有用な分類法に分割しています:
- Naive RAG — 「インデックス作成、検索、生成を含む従来のプロセス。」 トップkを一度取得し、一度生成する。「精度と再現率に課題があり、ミスアライメントや無関係なチャンクの選択につながる。」
- Advanced RAG — 「検索前および検索後の戦略」 を追加。検索前: クエリの書き換えとより良いインデックス作成(HyDE を含む。モデルが仮説的な回答を生成し、それ を埋め込み、質問ではなく回答のように見えるドキュメントを取得する)。検索後: 再ランキングとコンテキスト圧縮。
- Modular / agentic RAG — モデルが検索し、まだ欠けているものを推論し、再度検索し、複数ホップ にわたって反復する。これがAI検索の現在の状態です。Michael King氏が述べたように: 「最初の波を定義した一度検索してから生成するパターンは時代遅れです…Agentic RAGが今やデフォルトです。」
これはSEOにとって重要です。なぜなら、コンテンツは単一の検索パスだけでなく、複数 の検索ラウンドと矛盾チェックに耐えなければならないからです。
RAGは幻覚を排除するのか?いいえ。
Two bars report Gemma's incorrect-answer rate in one Google Research evaluation. With no context, the rate is 10.2 percent. With insufficient context, the rate is 66.1 percent. The comparison comes from Google Research's ICLR 2025 sufficient-context study and should not be generalized to every model, dataset, or retrieval system.
RAGは取得したソースに回答を基づかせることができますが、LLMは取得した内容を誤読したり、過剰に解釈したりする可能性があります。Google Research(ICLR 2025)は、ある評価で直感に反する結果を記録しました。Gemmaは、コンテキストなしの質問の10,2%と、コンテキストが不十分な場合の66,1%で誤った回答 を生成しました。研究者らは、モデルが*「十分なコンテキストがあれば優れているが、コンテキストが不十分な場合にそれを認識できない」* と報告しています。これは、検索が普遍的に悪い回答を引き起こすという証拠ではなく、モデルおよび評価固有の警告として扱ってください。実際的な教訓はより狭いものです。検索品質とコンテキストの十分性は、想定するのではなく評価する必要があるということです。Googleはこの発見を、Vertex AI RAG EngineのLLM再ランカーとして実用化しました。
RAGとファインチューニング
これらは常に混同されますが、根本的に異なります:
- RAG はクエリ時に外部情報を取得します。重みは変更されません。最新/変化する情報、引用要件、コストに最適です。調査では、「RAGは、トレーニング中に遭遇した既存の知識と完全に新しい知識の両方において、[教師なしファインチューニング]を一貫して上回る」 ことがわかりました。
- ファインチューニング は、別のトレーニング実行でモデルの重みを変更します。スタイルと動作 の変更、または変化しない安定したドメイン知識の教育に最適です。
モデルに最新の事実を 知らせる ためにはRAGを利用し、モデルの 話し方 を変えるためにはファインチューニングを利用することになるでしょう。
実際のRAG: Google、ChatGPT、Perplexity
- Google AI Overviews. Google は RAG を 「(グラウンディングとも呼ばれる) 手法… 中核となる検索ランキング システムに依存して、検索インデックスから関連性の高い最新の ウェブページを取得する」 と呼んでいます。これには2つの意味があります。第一に、独立した AI インデックスは存在しません — 「Google 検索の生成 AI 機能は、中核となる検索ランキングおよび品質システムに 根ざしています。」 第二に、Google は クエリ ファンアウト を実行します: 「モデルによって生成された、より多くの情報を要求するための並行した関連クエリ。」 1つの質問から複数のサブクエリが生成され、それぞれが異なるコンテンツを取得します — つまり、あなたのコンテンツは、メインのクエリだけでなく、暗黙のサブ質問も満たす必要があります。
- ChatGPT Search. (2024年10月) Bing をデータパートナーとして開始され、 OpenAI 自身のクローラーのドキュメントは、OAI-SearchBot が GPTBot の トレーニング クロールとは別に、検索引用のために独立したフェッチとインデックス作成を行うことを確認しています。OpenAI は Bing と自社インデックス間の現在の取得割合を公開しておらず、OpenAI は ChatGPT Search を Bing のラッパーではなく、Bing に対する独立した競合製品として位置付けています — そのため、「基本的に Bing だ」というのは単純化しすぎです。文書化された実行可能なレバーはより狭く、より耐久性があります: robots.txt で OAI-SearchBot をブロックしないでください。なぜなら、それが OpenAI 自身が検索引用のためにコンテンツをインデックスするクローラーとして挙げているものだからです。
- Perplexity. ハイブリッド検索 (Vespa.ai — BM25 + 密) とカスタム埋め込みモデル、および厳格な再ランキングしきい値に基づいています: 第三者分析によると、取得された60以上のソースのうち上位約30%のみが生成段階まで生き残り、「引用は生成後に後付けされるのではなく、コンテキスト構築中に構造的に割り当てられます。」 Deep Research は、数十の検索にわたってエージェント ループを実行します。
RAG が SEO にとって意味すること
専門用語を除けば、そのプレイブックは具体的です:
- インデックスに含まれることが前提条件です — それ以外はありません。 独立した AI インデックスがないということは、 クロール → インデックス → 取得のチェーンが intact である必要があるということです。ページが クロール およびインデックスされなければ、AI の回答に取得されることはありません。 独自のプールを構築する AI エンジンにも同じことが当てはまります: AI クローラー (OAI-SearchBot や PerplexityBot など) があなたをフェッチすることを許可されなければ、それらの回答からは見えなくなります。
- 自己完結型のパッセージを書く。 RAG はページ全体ではなく 断片 を取得します。 iPullRank の Francine Monahan が述べたように、AI システムは 「ページ全体ではなくページの断片」 を調べます — したがって、特定の質問に単独で答える 「際立ったパッセージやフレーズ」 を作成します。これは、優れた SEO がすでに評価している H2/H3 構造と明確なトピック文とまったく同じです。Google は、AI のためにコンテンツを細かく分割する べきではない と明示的に述べています — 構造化されたコンテンツは自然に適切にチャンク化されます。
- サブトピックをカバーする。 クエリ ファンアウトとは、1つの質問が多くの取得をトリガーできることを意味します。関連するサブ質問にわたる深さは、単一のキーワードに詰め込まれた1つのページよりも優れています。
- 権威はランク位置よりも引用を促進します。 8 000件の引用分析から: 「強力なオーガニック検索プレゼンスと広範なウェブ可視性が AI 引用につながります。その逆ではありません」 — そして 「ランキングが低いページからの非常に権威のあるコンテンツ」 が、信頼性の低い上位ランキングのページよりも引用されることがあります。私自身のデータも一致しています (私の AI Overview 引用調査 から): リンクの多いページでの言及が AI Overview への掲載の最も強い予測因子であり (ρ ≈ 0,70)、ブランドのウェブ言及は 75 000 ブランドにわたって約 0,66 の相関がありました。
- 新しいコンテンツには利点があります。 AI 引用はオーガニック結果よりも有意に新しい傾向があるため、鮮度が重要です。
1文でまとめると: RAG は SEO を置き換えたのではなく、常に見つけやすく明確であることに関する SEO の部分の重要性を高めました。
AIまとめ
Advancedバージョンの簡潔な見解:
- RAG = 検索 + 拡張生成。 推論時の2つのフェーズ: 外部コーパスから関連パッセージを取得し、それをLLMに渡して、根拠のある引用付きの回答を生成します。モデルの重みは決して変更されません — トレーニングでもファインチューニングでもありません。
- 2つのメモリを組み合わせます: パラメトリック(重みに組み込まれる)+ 非パラメトリック(ライブで取得)。これにより、AI回答はトレーニングカットオフ以降の情報もカバーできます。
- 検索はパイプラインです: チャンキング → 埋め込み → ベクトル検索(多くの場合BM25とのハイブリッド)→ 再ランキング → プロンプトへの上位kパッセージ。チャンキングが脆弱なリンクです。文脈豊富なパッセージはより良く取得されます(Anthropicは失敗した取得を49%削減)。
- 3つの種類: ナイーブ(一度だけ取得)、アドバンスト(クエリ書き換え、HyDE、再ランキング)、エージェンティック(反復的なマルチホップ)— エージェンティックが現在のAI検索のデフォルトです。
- 幻覚を減らすが、排除はしません。 不十分な文脈では、あるモデルの幻覚率は10,2% → 66,1%に跳ね上がりました — 悪い検索は検索なしより悪いことがあります。
- RAG vs. ファインチューニング: RAGは新しい/変化する事実 + 引用 + コストに適しています。ファインチューニングはスタイル/動作と安定した知識に適しています。
- エンジン: Google AI Overviewsはコアインデックスから取得し(別のAIインデックスはなし)、クエリファンアウトを使用します。ChatGPT SearchはBingのインデックスで開始し、独自のクローラーOAI-SearchBotも実行します — 正確な現在の構成は公開されていないため、OAI-SearchBotをブロックしないでください。Perplexityは厳格な再ランキングしきい値とコンテキスト組み立て中の引用割り当てを備えたハイブリッド検索を使用します。
- SEO: クロール可能 + インデックス可能であることが前提条件です。自己完結型のパッセージを書き、サブトピックをカバーし(ファンアウト)、権威性/E-E-A-Tはランク位置よりも引用に影響します。新しいコンテンツには優位性があります。
公式ドキュメント
プロバイダーからの一次ソースのドキュメントと定義。
- 生成AI機能向け最適化ガイド — RAGをコア検索インデックスへのグラウンディングとして定義。クエリファンアウトをカバー。
- 検索のAI OverviewsとAIモード — 標準のインデックスとスニペット適格性以外の追加要件がないことを確認。
- Vertex AIでのRAGとグラウンディング — Google Cloudの取得・生成定義(Burak Gokturk)。
- RAGのより深い洞察:十分な文脈の役割 — Google Research(ICLR 2025)による不十分な文脈の失敗モードについて。
Microsoft / Azure
- RAGと生成AI — Azure AI Search — RAGを独自コンテンツへのグラウンディングとして定義。クエリ理解、トークン制約、エージェンティック検索への移行。
OpenAI
- OpenAIクローラーの概要 — OAI-SearchBotがGPTBotのトレーニングクロールとは別に、ChatGPT Searchの引用のために独立したフェッチ/インデックスを行うことを確認。Bingのインデックスとの現在の構成は開示されていない。
Anthropic
- Contextual Retrievalの紹介 — チャンク文脈損失の問題と測定された修正(失敗した取得が49% / 67%減少)。
AWS
- Retrieval-Augmented Generationとは? — 明確な3段階の説明とRAG対再トレーニングのコスト論。
基礎論文
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Lewis et al., NeurIPS 2020(元のRAG論文。パラメトリックメモリと非パラメトリックメモリ)。
- Retrieval-Augmented Generation for LLMs: A Survey — Gao et al.(naive / advanced / modular の分類、HyDE、再ランキング)。
ソースからの引用
プロバイダーと元の研究者による公式発言。利用可能な場合は、ディープリンクは引用箇所にジャンプします。
Google — RAGはグラウンディングであり、コアインデックス上で行われる
- “A technique (also known as grounding) used to improve the quality, accuracy, and freshness of AI responses by relying on our core Search ranking systems to retrieve relevant, up-to-date web pages from our Search index.” (翻訳) 「コア検索ランキングシステムに依存して、検索インデックスから関連性の高い最新のウェブページを取得することで、AI応答の品質、正確性、鮮度を向上させるために使用される手法(グラウンディングとも呼ばれる)。」 — Google Search Central、AI最適化ガイド。 引用にジャンプ
- “Our generative AI features on Google Search are rooted in our core Search ranking and quality systems.” (翻訳) 「Google検索の生成AI機能は、コア検索ランキングおよび品質システムに基づいています。」 — Google Search Central、AI最適化ガイド。
Google Cloud — 取得してから生成するという定義
- “Retrieval Augmented Generation (RAG), a technique developed to mitigate these challenges, first ‘retrieves’ facts about a question, then provides those facts to the model before it ‘generates’ an answer – this is what we mean by grounding.” (翻訳) 「これらの課題を軽減するために開発された手法であるRetrieval Augmented Generation(RAG)は、まず質問に関する事実を『取得』し、モデルが回答を『生成』する前にその事実をモデルに提供します。これが私たちがグラウンディングと呼ぶものです。」 — Burak Gokturk、VP & GM、Cloud AI、Google Cloud(2024年6月27日)。 引用にジャンプ
元のRAG論文 — パラメトリックメモリと非パラメトリックメモリ
- “retrieval-augmented generation (RAG) — models which combine pre-trained parametric and non-parametric memory for language generation.” (翻訳) 「検索拡張生成(RAG)— 言語生成のために、事前学習済みのパラメトリックメモリと非パラメトリックメモリを組み合わせたモデル。」 — Lewis et al., NeurIPS 2020。
Patrick Lewis、筆頭著者 — 名前について (NVIDIAブログ、Rick Merritt経由)
- “We definitely would have put more thought into the name had we known our work would become so widespread.” (翻訳) 「私たちの研究がこれほど広まるとは知っていたら、名前にもっと考えを巡らせていたでしょう。」
- “We always planned to have a nicer sounding name, but when it came time to write the paper, no one had a better idea.” (翻訳) 「私たちは常により良い響きの名前を計画していましたが、論文を書く段階になっても、誰もより良いアイデアを持っていませんでした。」 報道を読む
Microsoft — 自社コンテンツへのグラウンディングとしてのRAG
- “Retrieval-augmented generation (RAG) is a pattern that extends LLM capabilities by grounding responses in your proprietary content.” (翻訳) 「検索拡張生成(RAG)は、応答を独自コンテンツにグラウンディングすることでLLMの機能を拡張するパターンです。」 — Microsoft、Azure AI Searchドキュメント。
Anthropic — チャンキングの問題
- “traditional RAG solutions remove context when encoding information.” (翻訳) 「従来のRAGソリューションは、情報をエンコードする際にコンテキストを除去します。」 — Anthropic、Contextual Retrieval(2024年9月19日)。 投稿を読む
AWS — RAGと再トレーニングの比較
- “Retrieval-Augmented Generation (RAG) is the process of optimizing the output of a large language model, so it references an authoritative knowledge base outside of its training data sources before generating a response.” (翻訳) 「検索拡張生成(RAG)は、大規模言語モデルの出力を最適化するプロセスであり、応答を生成する前に、トレーニングデータソースの外部にある権威ある知識ベースを参照します。」 — AWS。
- “RAG is a more cost-effective approach to introducing new data to the LLM.” (翻訳) 「RAGは、LLMに新しいデータを導入するためのより費用対効果の高いアプローチです。」 — AWS。
OpenAI — ChatGPT検索用の独自クローラー
- “OpenAI uses OAI-SearchBot and GPTBot robots.txt tags to enable webmasters to manage how their sites and content work with AI… a webmaster can allow OAI-SearchBot in order to appear in search results while disallowing GPTBot to indicate that crawled content should not be used for training.” (翻訳) 「OpenAIは、OAI-SearchBotとGPTBotのrobots.txtタグを使用して、ウェブマスターがサイトとコンテンツがAIとどのように連携するかを管理できるようにします…ウェブマスターは、検索結果に表示されるようにOAI-SearchBotを許可し、クロールされたコンテンツがトレーニングに使用されないことを示すためにGPTBotを拒否することができます。」 — OpenAI、OpenAIクローラーの概要。 ドキュメントを読む
Michael King、iPullRank — エージェント型への移行 (Search Engine Land)
- “The retrieve-once-then-generate pattern that defined the first wave is obsolete… Agentic RAG is now the default.” (翻訳) 「最初の波を定義した『一度取得してから生成する』パターンは時代遅れです…エージェント型RAGが今やデフォルトです。」 報道を読む
RAG早見表
エンドツーエンドのパイプライン
query → [retrieval: chunk · embed · vector search (+BM25) · re-rank · top-k] → augment (passages into context) → generate (LLM writes grounded, cited answer)
RAGとファインチューニング
| RAG | ファインチューニング | |
|---|---|---|
| モデルの重みを変更するか? | いいえ | はい |
| いつ発生するか | 推論時(クエリ時) | 別のトレーニング実行 |
| 最適な用途 | 新しい/変化する事実、引用、コスト | スタイル、動作、安定したドメイン知識 |
| 知識の更新方法 | コーパスの再インデックス | 再トレーニング |
RAGの3世代
| 種類 | 機能 | 見られる場所 |
|---|---|---|
| ナイーブ | トップkを一度取得し、一度生成 | 初期のチャットボット、シンプルなQ&A |
| アドバンスト | + クエリ書き換え、HyDE、再ランキング、圧縮 | ほとんどの本番RAG |
| エージェンティック | 反復的なマルチホップ:取得 → 推論 → 再取得 | Google AI Mode、Perplexity Deep Research、ChatGPT Search |
エンジンの取得プールの概要
| エンジン | 取得元 | 注 |
|---|---|---|
| Google AI Overviews | Googleのコアインデックス | 独立したAIインデックスなし。クエリファンアウト |
| ChatGPT Search | Bingインデックス + OpenAI独自のクローラー | OAI-SearchBotをブロックしない。正確な構成は非公開 |
| Perplexity | ハイブリッド(Vespa.ai) | 厳格な再ランクしきい値。引用は組み立て中に割り当てられる |
クイックファクト
- RAG = Retrieval + Augmented Generation。Lewisら(2020年)によって造語。
- 推論時に動作 — 重みは決して変わらない。
- 幻覚は解決されていない:不十分なコンテキストにより、あるモデルは**10,2% → 66,1%**に悪化。
- コンテキストを考慮したチャンキングにより、取得失敗が**49%**削減(再ランキングで67%)。
- AI向けにコンテンツを事前に「チャンク化」しないでください — 明確なH2/H3構造はそれ自体でうまくチャンク化されます。
メンタルモデル
1. 取得 → 拡張 → 生成。 すべてのRAGシステムはこの3つの動作です。AIの回答が間違っている場合、どの 段階で失敗したかを特定します:正しいパッセージを取得したか、十分なコンテキストを渡したか、 それともモデルが良いソースから誤生成したか?ほとんどのAI可視性の問題は 取得の問題であり、生成の問題ではありません。
2. パラメトリックメモリと非パラメトリックメモリ。 モデルにはパラメトリック知識(重みに固定され、トレーニングカットオフで制限される)と 非パラメトリック知識(ライブで取得される)があります。コンテンツを公開しても重みには 触れられません — しかし、ライブの取得には供給できます。これがSEOがAI検索に 依然として適用されるすべての理由です。
3. RAGとファインチューニングは知識と行動の分割です。 モデルに新しいまたは変化する事実を知らせる必要がありますか?RAG。どのように動作または 記述するかを変更する必要がありますか?ファインチューニング。毎週変わる事実を追加するためにファインチューニングしないでください。
4. 取得品質がボトルネック — そしてそれは両刃の剣です。 より良い取得はより大きなモデルに勝ります。そして不十分な取得は何もないよりも悪いことがあります。 したがって、コンテンツの目標は単に「取得される」ことではなく、モデルが明確に回答できる 「十分な、自己完結型のパッセージとして取得される」ことです。
5. クロール → インデックス → 取得のチェーン。 独立したAIインデックスはありません。ページがクロールまたはインデックスで失敗した場合、 取得に到達することはできません — GoogleのRAGまたは独自のプールを構築するAIエンジンの場合も同様です。 まずチェーンを修正し、次にパッセージを最適化します。
自分でテスト:検索拡張生成
時間をかける価値のあるリソース
関連する私の記事と調査
- What We Actually Know About Optimizing for LLM Search — Ahrefs の記事(私のデータを使用): 被リンクの多いページでの言及が AI Overview への掲載の最も強い予測因子(ρ ≈ 0,70)。
- Generative Engine Optimization — RAG を活用した検索環境への SEO の対応。
- GEO? AEO? LLMO? What’s With All This AI SEO Stuff? — Ahrefs Evolve 2025 での AI 検索環境と、インデックス登録という前提条件が変わっていない理由についての私の講演。
基礎となる論文
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Lewis ら、2020年(起源)。
- RAG for LLMs: A Survey — Gao ら(naive/advanced/modular の分類法)。
他の情報源
- How AI Search Engines Work — Ryan Law(Ahrefs)による、RAG を基盤メカニズムとして解説。
- Google AI Overviews: All You Need to Know — Ong & Law(Ahrefs)による、コアインデックス上の RAG について。
- What Is Retrieval-Augmented Generation? — NVIDIA(Lewis の命名に関する逸話を含む)。
- How Retrieval-Augmented Generation is Redefining SEO — Francine Monahan、iPullRank(パッセージレベルの最適化)。
- Beyond RAG: why every AI search platform is now agentic — Michael King、Search Engine Land。
- How Perplexity AI Answers Work — Ishtiaque Ahmed による、検索・ランキング・引用パイプラインの技術的解説。
- How to get cited by AI: SEO insights from 8,000 AI citations — James Allen、Search Engine Land。権威性と E-E-A-T がランキング順位よりも AI の引用を左右する。
- How Perplexity uses Vespa.ai — Vespa.ai による Perplexity のハイブリッド BM25 + 高密度検索アーキテクチャのファーストパーティ解説。
- Retrieval-augmented generation — Wikipedia — 参考になる概要。RAG ポイズニングと幻覚の注意点をカバー。
引用に値する統計
- 10,2% → 66,1% の幻覚の急増 — あるモデルの幻覚率が、不十分な取得コンテキストの場合とコンテキストなしの場合で比較。悪い取得は取得なしよりも悪い結果になる。Google Research、ICLR 2025。 ソース
- コンテキストを考慮したチャンキング(Contextual Embeddings)による取得失敗の 49% 削減。再ランキングと組み合わせると 67% に向上。Anthropic、2024年。 ソース
- ρ ≈ 0,70 — 被リンクの多いページでの言及が、私の調査で Google AI Overview への掲載の最も強い予測因子。ブランドのウェブ言及は 75 000 ブランドで約 0,66 の相関。 ソース
- 約 30% の生存率 — 第三者分析によると、取得された 60 以上のソースのうち上位約 30% だけが Perplexity の再ランキングのしきい値を通過して生成段階に進む。 ソース
- 知識タスクでは RAG が教師なしファインチューニングより優れている — “for both existing knowledge encountered during training and entirely new knowledge.” (翻訳) 「トレーニング中に遭遇した既存の知識と、まったく新しい知識の両方に対して。」 ソース
変更履歴
2026年7月19日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。