【2025年5月完全版】RAG の教科書

昨今、AI の進化により、様々な分野での応用が進んでいます。特に、自然言語処理(NLP)の分野では、RAG( Retrieval-Augmented Generation)が注目されています。RAG は、情報検索と生成を組み合わせた手法であり、特に大規模言語モデル(LLM)と組み合わせることで、その性能を大幅に向上させることができます。

また、NativeRAG や GraphRAG, AgentRAG などさまざまな RAG のバリエーションが登場しており、これらは特定のユースケースやデータセットに対して最適化されています。

今回は、RAG の基本的な概念から、RAG のプロジェクトの進め方、精度向上の方法に至るまで詳しく解説します。

みなさんの GenAI Application の開発に役立てていただければ幸いです。

本記事は 5 万文字を超える大作となっております。
お時間ある方は参考文献含めて一読いただければ、お忙しい方は目次からジャンプ出来るようにしておりますので、プロジェクトのフェーズに合わせて必要な箇所をご参照ください。

それでは行きましょう 🚀

RAG とはRetrieval-Augmented Generationの略で、情報検索と生成を組み合わせた手法です。
RAG は特に大規模言語モデル(LLM)と組み合わせることで、その性能を大幅に向上させることができます。

歴史的にはMeta の研究者が提案した、LLM のハルシネーション（誤情報生成）を低減する手法で、LLM だけの思考ではなく、外部リソースに検索をかけながら正しい答えを生成する言わば 「ナレッジベースの外部化」 が実現出来る手法です。

ユーザーからの問いに対し、バックエンドのナレッジベース（例: Azure AI Search）で検索し、その結果をプロンプトに追加して回答を生成するような流れが一般的な流れになります。

RAG の概要のフローは以下のようになっています。

1. Store で各種データをチャンク分割し、ベクトル化してデータストア(Azure AI Search 等)に格納します。
2. ユーザーからの質問を Application 側で受け取ります。
3. Retrieve と記載されている場所で、キーワード検索やベクトル検索を実施します。
4. 関連する情報をデータストアから取得します。
5. ユーザーからの質問とデータストアから取得した関連情報を、Augment の箇所でビルドします。
6. 生成 AI の API(Azure OpenAI Service 等)に、ユーザーからの質問とデータストアから取得した関連情報をプロンプトとして渡します。
7. 質問と関連情報を元に回答を生成します。
8. 生成された回答をユーザーに返します。

このように RAG は以下 4 つの箇所に分割することが出来ます。

• Store : データの格納
• Retrieve : データの検索
• Augment : プロンプトのビルド
• Generation : 回答の生成

RAG のアプローチ

RAG の精度をあげるための手法の研究は進んでおり、キーワード/ベクトル検索に基づく NativeRAG、KG（ナレッジグラフ）を活用する GraphRAG、そして両者を組み合わせる HybridRAG が主要な選択肢として挙げられます。

また、昨今注目されているのはAgenticRAGと呼ばれる手法で、従来の RAG が抱える「静的なワークフロー」「単一ステップ推論」等の限界を乗り越えるべく、LLM をエージェント化（計画・再試行・ツール活用・他エージェントとの協調など）。クエリごとに動的に検索戦略を変えたり、回答途中に不足情報を再検索したり、複数のエージェント間でタスクを分担して協調する。

RAG の比較をまとめてみました。

アプローチ	ユースケース	検索手法	強み	弱み
🧠 NativeRAG	・幅広いドキュメント検索 ・FAQ やカスタマーサポート ・表現のゆらぎへの対応	・キーワード検索 ・ベクトル検索 ・セマンティックリランキング	・スキーマ不要で実装が容易 ・大規模非構造テキストを取り込みやすい ・柔軟性が高い	・関係性の厳密な推論には弱い ・ノイズが多い場合、回答の正確性が下がる
📈 GraphRAG	・エンティティの厳密な関係性の追跡 ・因果関係の分析 ・説明責任が求められる場面	・ナレッジグラフを用いた構造的な検索 ・エンティティ・リレーションに基づく問い合わせ	・一貫性・説明可能性が高い ・ドメイン知識の活用に強み	・ナレッジグラフ構築コストが高い ・エンティティが直接登場しない抽象質問に弱い
🔗 HybridRAG	・抽象的な質問にも対応しつつ関係性も正確に捉えたいケース ・非構造化データと構造化データが混在する複雑ドメイン	・NativeRAG と GraphRAG の両方を実施 ・ベクトル検索の文脈 & ナレッジグラフのサブグラフ情報を併用	・NativeRAG と GraphRAG の長所を活かし精度と柔軟性を両立 ・抽象的質問 & エンティティ重視の質問両方に強い	・両方の結果をマージする分コンテキストが増大しがち ・実装・運用が複雑化しやすい
🤖 AgenticRAG	・マルチソース横断のリアルタイム Q&A／データ統合チャットボット ・ステップ分解が必要な複雑タスク（法務調査・コーディング支援等） ・カスタマーサポート一次対応自動化とエスカレーション判定 ・部門横断のナレッジ発見・データマネジメント	・ルーティング／プランニングエージェントでツール選択（ベクトル検索・キーワード検索・Web 検索・API 呼び出し等） ・ReAct／Plan-and-Execute などのマルチステップ推論ループ ・専用リトリーバーを複数連携するマルチエージェント構成	・柔軟性・適応性が高く、動的にデータソース／ツールを切替可能 ・自己検証ループでノイズを低減し精度向上 ・マルチエージェント拡張で異種データ・マルチモーダル対応が容易 ・単一ベクトル DB 依存より網羅性が高い	・複数エージェントによる追加推論でコスト・レイテンシ増大 ・エージェント行き詰まり／ハルシネーション対策が必須 ・オーケストレーションや権限制御など実装・運用が複雑 ・協調失敗時に処理が非効率になるリスク

Agent 時代の RAG

特に最近注目されている AgenticRAG について深掘りしていきたいと思います。

以下に AgenticRAG の調査もまとめられています。

https://arxiv.org/abs/2501.09136

エージェント検索拡張生成 (AgenticRAG) は、自律型 AI エージェントを RAG パイプラインに組み込み、エージェント設計パターンの反映、計画、ツールの使用、およびマルチエージェント コラボレーションを活用して、検索戦略を動的に管理し、コンテキスト理解を反復的に改善し、複雑なタスク要件を満たすようにワークフローを適応させます。
この統合により、AgenticRAG システムは、多様なアプリケーションにおいて比類のない柔軟性、拡張性、そしてコンテキスト認識を実現します。

AI Agent の要素は以下のものが挙げられます。

マルチエージェントで強調することや、LLM、メモリ、計画、ツール活用などの要素を組み合わせて、より高度なタスク解決を目指します。

実際に、AgenticRAG の処理プロセスの例は以下のようになります。

クエリ送信後、クエリの分析・検索戦略の決定を行い、外部ソース（データベース、ベクトル検索、Web など）から情報を取得します。その後、初期回答を生成し、その妥当性や根拠を評価します。
もし回答が不十分であれば、再度検索を行い追加情報を取得し、改善された回答を生成します。最終的に、ユーザーに最終回答を返却します。

今までの RAG では、Retrieve の結果をそのままプロンプトに追加して回答を生成していましたが、AgenticRAG では、クエリの分析や検索戦略の決定、回答の妥当性評価などのステップが追加され、より動的で柔軟な対応が可能になります。

そして、一口に AgenticRAG と言っても、様々なアプローチが存在します。
今回は以下の 6 つのアプローチを紹介・比較します。

• シングルエージェント RAG
• マルチエージェント RAG
• 階層型エージェント RAG
• Corrective RAG
• Adaptive RAG
• Graph ベース RAG
• Agentic Document Workflows (ADW)

分類	概要	利点	注意点・課題	主な用途・事例
シングルエージェント RAG	RAG の一連のタスクを、単一のエージェントがまとめて管理	すべて 1 エージェントで完結するため、エージェント間の連携不要	・高度な並列処理・専門化には限界 ・大規模・複雑な処理には不向き	カスタマーサポートなど比較的単純な問い合わせ対応
マルチエージェント RAG	コーディネーター役のエージェントがクエリを受け取り、複数の専門エージェントにサブタスクを振り分け、結果を統合	機能を専門化できるため、高度・複雑なタスクに対応しやすい。並列処理で高速化が可能	エージェント間連携の設計が複雑化	大規模システムでの高度な情報検索・集約
階層型エージェント RAG	上位エージェントが戦略レベルの判断を行い、下位エージェントが実務的な検索や解析を担う	大規模・複雑な意思決定を効果的に管理	階層設計が不十分だとボトルネックを起こしやすい	分析チーム・検索チームなど、複数部門をまたぐワークフロー制御
CorrectiveRAG	検索結果が不正確・不足がある場合に自動で修正検索やクエリ再生成を行う仕組み	ハルシネーションや検索ミスを低減	エージェントの評価・修正プロセスを設計する必要。再検索や情報取得の手数が増え、処理コストが増大	FAQ システムの回答精度向上、ファクトベースのレポーティングやカスタマーサポート
AdaptiveRAG	クエリの難易度（簡易・中程度・複雑など）に応じて検索・推論の手順を切り替える	不要な大規模処理を行わずに済むため効率が良い。シンプルな問題は高速に処理し、複雑な問題には多段階処理を適用	クエリ分類の精度がシステム全体の性能に影響。過小評価・過大評価による処理パスのミスマッチ	ユーザーからの多様な質問に対し最適な処理を選択するチャットボット
Graph ベース RAG	ナレッジグラフとテキスト検索を組み合わせ、結果をクリティックモジュールなどで評価しながら精緻化	リレーショナルな知識構造を活かした多段階推論が可能	グラフ DB の構築や更新が必要	医療や学術分野など、複雑なエンティティ関係を扱うシステム
Agentic Document Workflows (ADW)	文書処理（インボイス、契約書、レポートなど）に特化したワークフロー	複数ステップの文書処理を一元化できる	文書形式ごとの細かな設定やテンプレート設計	契約書の審査、自動請求処理、保険金請求管理など

AI Agent の Application の開発においては、開発するプロダクトが達成したい目標や、解決したい課題に応じて、適切なアプローチを選択することが重要です。

それぞれの利点や課題を正確に抑えながら、Agent の設計を行うことで、より効果的な AI Agent の開発が可能になります。

ここからは NativeRAG をベースに RAG を構築する上でのプロジェクトの進め方について紹介します。

RAG アプリ全体プロセス

大まかな進め方は以下になります。
要件整理 → POC／改善 → 本番構築 → 継続的改善

個人的に最も大事だと思うポイントは要件定義から PoC に入るスピードとクオリティです。
決して高いクオリティを求めるのではなく、とりあえずやってみる精神で作っていくことが重要と感じています。

フェーズ	概要	準備物	想定期間
要件整理	RAG における要件整理。例・想定ユーザ／使用方法・データ整理、データの持ち方・開発スケジュール・コスト／評価基準（本番化への）など	・ヒアリング／要件整理シート ※1	1〜2 週間
POC／改善	一定の RAG 手法を含むベースラインアプリを利用したクイック POC。・検証／評価（質問・回答のセットを事前に準備）・課題把握（×× サイクル）・本番構築への意思決定	・RAG サンプルアプリ ※1・評価機能 ※1・課題–ソリューションマップ ※1	1 か月〜2 か月
本番構築	本番運用向けアーキテクチャ設計と構築。・リファレンスアーキテクチャ × 顧客環境ポリシーに基づく最終アーキテクチャ整理・構築／責任ある AI	・リファレンスアーキテクチャ・構築パートナー選定	2 か月〜3 か月
継続的改善	本番展開時に発生した課題／要望への対応。・新たなデータ、質問等の新規要望に対する継続的な改善・継続的な会話ログ分析	・LLMOps／精度モニタリング・課題–ソリューションマップ	継続

継続的な改善を進め、3 度目のリリースぐらいでいい形のプロダクトになることが多いです。
前述しましたが、初めから完璧を求めるのではなく、まずはやってみることが重要です。

PoC としては以下機能ぐらいあれば効果測定には十分です。

■ サンプルアプリ主要機能

• 【フロント UI】
  • ファイルアップロード機能
  • 検索パラメータ変更
  • ハイブリッドセマンティック検索等の複数検索手法
  • システムロール変更機能
  • プロンプト表示機能(with 検索結果)
  • 検索パラメータ / GPT パラメータ
  • AI 回答内での参照ファイル表示
• 【バックエンド】
  • AI-OCR (表対応)
  • セマンティックチャンキング
  • チャンクエンリッチメント(タイトル、要約、キーワード抽出)
  • 評価機能

Azure において図示すると以下のようなイメージになります。

データ準備・ナレッジ活用・評価のサイクルをぐるぐる回すことで、RAG の精度を向上させていきます。

RAG の精度改善箇所は大きく分けて４項目に分かれます。

• Store : データの格納
• Retrieve : 検索
• Augment : プロンプトのビルド
• Generate : 生成

上記４項目からさらに細分化して、精度改善の方法を考えていきます。

それぞれの箇所で精度改善を行えそうなポイントをざっくりと挙げてみました。

1. 非構造化データのテキスト抽出精度の向上 など
2. チャンク分割の最適化 (分割戦略, 分割サイズ, オーバラップサイズ) など
3. 検索ドキュメントのエンリッチメント など
4. ドキュメント検索精度のチューニング など
5. Prompt Engineering, クエリ拡張, 最適モデルの使用 など
6. RAG アプリ利用の UI の改善 など

Store、Retrieve、Augment、Generate の各ステップでの精度向上の方法は以下になります。

Store	Retrieve	Augment	Generate
PDF ファイルのテキスト化	検索アルゴリズム	システムメッセージ定義	モデル選択（回答生成）
Office ファイルのテキスト化	アルゴリズムのパラメータチューニング	ユーザメッセージ定義	モデル選択（埋め込みモデル）
音声データのテキスト化	スコアリングプロファイル	検索クエリ生成	マルチモーダル
動画データのテキスト化	カスタムアナライザ	ユーザへの聞き返し	ファインチューニング
画像データのテキスト化	類似度チューニング	仮説的文書埋め込み	—
チャンク分割（チャンクチューニング）	—	Function Calling	—
オーバラップ	—	—	—
テーブル構造抽出	—	—	—
エンリッチメント	—	—	—
カテゴリ付け	—	—	—

上記に加え、４項目すべてで評価していきながら進めていくことが重要です。
では、それぞれの項目について詳しく見ていきましょう。

非構造化データのテキスト化

Store に格納する際、やはりテキスト化すると精度が向上します。
理想を言うと、すべての非構造化データ(PDF, Office, 音声, 動画, 画像)をテキスト化して、RAG の Store に格納することが望ましいです。

よくあるパターンのとしては、以下のようなデータとテキスト化の手法が考えられます。

データ種別	主なサービス / ライブラリ
PDF ファイルのテキスト化	– Azure AI Vision – OCR – Azure AI Document Intelligence（+ Azure OpenAI Service – GPT-4o） – その他のライブラリ（PyMuPDF, PDFMiner など）
Office ファイルのテキスト化	– Azure AI Search – ドキュメント抽出スキル – Microsoft Office SDK（Microsoft.Office.Interop） – その他のライブラリ（python-docx, python-pptx など）
音声データのテキスト化	– Azure AI Speech – Recognition API – Azure OpenAI Service – Whisper API
動画データのテキスト化	– Azure Video Indexer
画像データのテキスト化	– Azure AI Vision – Image Descriptions API – Azure OpenAI Service – GPT-4o

PDF/Office などのドキュメント分析によく使われるサービスとしては、Azure AI Document Intelligence がよく使われます。
Azure AI Document Intelligence は、ドキュメントのテキスト抽出や構造化、分類、エンリッチメントなどを行うことができるサービスです。

また、Azure AI Vision の OCR 機能を使うことで、画像や PDF からのテキスト抽出も行うことができます。こちらは比較的安価に利用出来る為、手軽に試すことができます。

チャンク戦略

まずはチャンク分割について前提知識を押さえておきましょう。

ドキュメントをそのまま LLM（GPT など）に渡すと トークン上限 にすぐ達してしまい、
「ピンポイントに役立つ情報」 を抽出できません。
そのため検索エンジンやベクトルストアに格納する前処理として チャンク分割 (chunking) が不可欠になります。

なぜドキュメントは「チャンク化」が必須なのかまとめると以下になります。

チャンク化で解決する 3 つの課題	説明
① LLM のコンテキスト制限	取得した複数文書を トークン上限内 で渡せるようになる
② 検索ランキングの精度	文書内で 最も関連性の高い部分 を優先的にヒットさせられる
③ 埋め込みモデルの制限	1 ベクトルに入れられるトークン数が限られている（多くのモデルで 512、Ada-002 でも 8,192）

ポイントとしては、以下になります。

• 中規模 PDF でも数万トークンに達する。後半に答えがあると “切り捨て” でロストする
• 長い文書ほど チャンク化の効果 が大きい

チャンク化の効果を検証 (Recall@50)

文書を「ベクトル」で扱う vs. チャンク化

クエリ種別	単一ベクトル (最初の 4,096 トークンのみ)	チャンク化 512 トークン (+25% 重複)	改善幅
回答が長い文書にある	28.2	45.7	+17.5
回答が文書の奥深くにある	28.7	51.4	+22.7

チャンクサイズを大きくするとどうなる？

チャンクサイズ (トークン)	Recall@50
512	42.4
1,024	37.5
4,096	36.4
8,191	34.9

結論: 大き過ぎるチャンクは検索性能を劣化 させる。
512〜1,000 トークン程度がバランス良。

境界戦略とオーバーラップの効果

境界戦略 (512 トークン)	Recall@50
トークン境界で単純切断	40.9
文の境界を保持	42.4
+10% 重複	43.1
+25% 重複	43.9

• 文や段落単位で切る → 文脈保持に有効
• 10〜25% のオーバーラップ でさらにリコール向上
• 重複率を上げるとストレージ・トークンコストも増えるので、Evaluation フェーズで最適化 する

実装で使える Tips

1. チャンクサイズは 512〜1,024 トークンから試し、メトリクスで調整
2. 境界は文／段落ベース、必要なら表やコードブロックも考慮
3. オーバーラップは 10〜20% をデフォルトに、リコール不足で増やす
4. メタ情報付与（タイトル・キーワード）で検索精度をさらに改善
5. 必ず Evaluation（Precision / Recall / コスト）を回して継続チューニング

チャンク戦略のポイントは、適切な粒度・境界・オーバーラップ設定 です。
以下にまとめを示します。

• チャンク分割戦略は RAG 成功のカギ
• 適切な粒度・境界・オーバーラップ設定で 検索リコールが 1.5〜2 倍 向上
• 大きすぎるチャンクや無秩序な境界は 性能低下 & コスト増大 の元
• 小さく始めて、計測 → 改善 がベストプラクティス

フィルタリング

カテゴリ＋フィルタリングとは？

RAG でベクトル検索を行う前に メタデータ (category, tag, language, date etc.) で 検索空間を先に絞り込む テクニックです。
Azure AI Search や Elasticsearch などは 構造化フィールドでのフィルタ をサポートしているため、

1. LLM でクエリをカテゴリ分類
2. 該当カテゴリに限定してベクトル検索

という 2 段階にすることで 高速化・コスト削減・精度向上 を実現できます。

ざっくり説明すると…

ステップ	処理内容	目的
① ユーザクエリ受信	例：「MLB の歴史を知りたい」	—
② クエリを分類	LLM / ルールベースで 「野球」 と判定	検索空間を縮小
③ メタデータでフィルタ	category eq '野球' などを検索 API に付与	無関係な文書を除外
④ ベクトル検索	残った数千〜数万件を ANN 検索	リコール・速度を両立
⑤ RAG パイプラインへ	関連チャンクを LLM に渡す	コンテキスト最適化

---

フィルタリングの効果

指標	フィルタなし	フィルタあり	改善理由
検索速度	100 ms	30 ms	文書候補数を先に削減
コスト (Azure AI Search 呼び出し数)	1.0×	0.3×	トークン＆ I/O が減る
回答精度 (Precision@10)	0.65	0.83	無関係カテゴリが除外されハルシネ減

フォールバック戦略 と メタフィールド設計

フォールバック戦略 (Fallback Strategy)

「検索が“当たらない”ときに、どう段階的に広げるか？」 を決めておく手順

レイヤー	条件	具体例	目的
Level 0 Strict Filter	フィルタ適用＋ベクトル検索	category eq '野球' and year gt 2020	最速・最安でヒットを狙う
Level 1 Relax Filter	フィルタを 1 つ緩める	category eq '野球' のみ	リコールを少し回復
Level 2 No Filter + Vector	フィルタ解除しベクトルのみ	全文書ベクトル検索	見落とし防止
Level 3 Lexical Search	キーワード or BM25 に切替	"MLB 歴史" キーワード検索	ロングテール対策
Level 4 LLM Q&A	外部検索 → 検索なしで生成	「答えなし」or Web 検索で生成	フルバックアップ

実装ポイント

1. 閾値設定
   • top_k が 0 件、または上位スコア threshold なら次レベルへ
2. タイムアウト／コスト管理
   • レベルが上がるほどコスト・遅延が増えるので上限設定
3. ユーザ通知
   • 最終レベルでも答えが出ない場合は 「該当記事が見つかりませんでした」 を返す

メタフィールド設計 (Metadata Field Design)

「どんなメタデータを、どの型で、どうインデックスに持たせるか？」 の設計指針

チェック項目	ベストプラクティス	例
フィールド選定	検索軸になる属性を洗い出す	category, language, year, owner, securityLevel
データ型	文字列 / 数値 / 日付 を正しく設定	year → Edm.Int32、publishDate → Edm.DateTimeOffset
属性設定	filterable, sortable, facetable を必要最小限	category = filterable+facetable / title = searchable
正規化	ケバブケース or snake_case で統一しスペル揺れ防止	security_level など
階層タグ	"sports > baseball > MLB" のように階層構造で保存し、クエリで prefix 検索	startswith(category,'sports/baseball')
セキュリティ	ACL / テナント ID もメタフィールドに持ち検索時に必ずフィルタ	tenantId eq 'xyz'
計算フィールド	事前集計（トークン数、チャンク ID など）はインデックス時に追加	tokenLength で長文除外
多値フィールド	タグはコレクション型 (Collection(Edm.String)) にして OR 検索を高速化	tags = [“MLB”,”history”,”US”]

設計フロー

1. ユースケース → クエリパターン を列挙
2. パターンに必要な フィルタ条件 を抽出
3. 検索エンジンの制約（1 インデックスあたりのフィールド数、型サポート）を確認
4. filterable を付けすぎるとインデックスが大きくなる → 必要最小限に
5. 実データで スキーマ・クエリを負荷テスト → 字段調整

ざっくりまとめると以下になります。

• フォールバック戦略
  • “ヒットなし” を防ぐ保険階層
  • レベルごとに 速度 ⇔ 精度 ⇔ コスト を段階的にトレードオフ
• メタフィールド設計
  • フィルタ性能の根幹。検索軸・データ型・属性設定 を丁寧に設計
  • 過剰な filterable はインデックス肥大化を招くので 最小限 + 拡張性 が鍵

両者をセットで考えることで、高速・高精度かつ堅牢 な RAG 検索基盤を構築できます。

使いどころ & ベストプラクティス

使い所やベストプラクティスは以下になります。

• ドメインが多岐にわたるナレッジベース
• スポーツ情報、技術製品カタログ、社内ナレッジなど
• 時系列・国別など複数軸フィルタ
• category eq ‘finance’ and year gt 2020
• 分類信頼度が低い場合はフォールバック
• フィルタ検索でヒット 0 件 → 全体検索へ切替
• 適切なインデックス設計
• filterable, facetable フィールドを事前設定しておく
• テストは Precision / Recall の両面で評価
• 絞り込み過ぎてリコールが落ちないか確認

フィルタリングすることで、RAG の精度と速度を大幅に向上させることが出来、メタデータで前段フィルタリングをかけることが出来ます。
実運用ではフォールバック戦略 と メタフィールド設計が成功のカギになります。

RAG の検索には 5 つの検索方式があります。
以下にまとめます。

#	検索方式	構成要素	ひと言で説明
①	フルテキスト検索	テキスト検索	キーワード一致だけで順位付け
②	ベクトル検索	ベクトル検索	文章の意味ベクトルで類似度検索
③	ハイブリッド検索	テキスト検索 × ベクトル検索	キーワードと意味ベクトルを合算してスコアリング
④	セマンティック検索	テキスト検索 × セマンティックランカー	キーワードヒット後、BERT などのランカーで語義ベース再順位付け
⑤	セマンティックハイブリッド検索	テキスト検索 × ベクトル検索 × セマンティックランカー	ハイブリッド検索結果をさらにセマンティックランカーで再ランキング

①→⑤ にいけばいくほど、検索精度が高くなり、コストも高くなる傾向にあります。

フルテキスト検索

そもそものフルテキスト検索の仕組みは入力クエリと文書の “文字列” を突き合わせて 関連度スコア を付け、 スコア順にソートして返す ―― これがフルテキスト検索（英: Full-Text Search, FTS）。

検索内部では以下のような処理が行われます。

• 全文解析 (tokenization)
  • 空白・句読点で分割 → 正規化 (小文字化・ステミングなど)
• インデックス化
  • 1 文書 = 多数の トークン（単語） を持つ逆引き辞書を作成
• 検索 (ranking)
  • クエリのトークンとインデックスを照合し“どれだけ一致したか”を点数化

また、フルテキスト検索における主要スコアリング指標というものもあります。

指標	意味	公式 (概要)
TF (Term Frequency)	その文書で単語が 何回 出たか	tf = 出現回数
DF (Document Frequency)	単語を含む 文書数	df = その単語が含まれる文書数
IDF (Inverse DF)	まれな単語ほど価値が高い	idf = log(N / df) (N = 全文書数)
TF-IDF	TF × IDF で重み付け	score = tf × idf
BM25	TF-IDF を改良：文書長パラメータなど調整	score = Σ idf × ((tf·(k+1))/(tf+k·(1-b+b·(docLen/avgLen))))

• 実際の Azure AI Search / OpenSearch / Lucene では BM25 がデフォルト。
• 長い文書でも単語出現が過大評価されないよう、文書長 (docLen) を補正します。

以下が動作イメージになります。

1. 検索クエリの実行
   • 検索クエリ「RAG の教科書を生成 AI アプリ開発に取り組む皆様へ提供」
2. アナライザ処理 → トークン列
   • ["RAG", "教科書", "生成", "AI", "アプリ", "開発", "取り組む", "皆様", "提供"]
3. インデックス照合
   • 文書 ①: … rag 教科書 ベストプラクティス …
   • 文書 ②: … ai アプリ 開発 ガイド …
4. TF & DF 計算
   • 文書 ① 内 rag: tf=2, df=3
   • 文書 ① 内 ai: tf=1, df=4
   • idf(rag) = log(N/df)=log(3/3)=0
   • idf(ai) = log(3/4)≈-0.29
   • TF-IDF = (tf×idf) 合算 → 0 − 0.29 + 1.10 ≈ 0.81
5. スコア順でソート → 上位 k 件返却

そんなフルテキスト検索にも、得意・苦手があります。
以下にまとめてみました。

得意	苦手
キーワード厳密一致 (コード検索・ログ検索)	類義語, 長文の“意味的” 検索
ブール演算 (AND/OR/NOT)	語順入れ替えや言い換え対応
部分一致・ワイルドカード (rag*)	曖昧検索 → ベクトル/セマンティックの方が強い

要件がフルテキスト検索の得意に収まるような場合は選定しても良いですね。

ベクトル検索

ベクトル検索の仕組みは以下になります。

クエリと文書をどちらも “数値ベクトル” に変換し、
ベクトル空間で “どれだけ近いか” を計算して返す ―― これがベクトル検索（Vector Search）。

ベクトル検索内部では以下のような処理が行われます。

• Embedding（数値化）
  • 画像・音声・動画・テキストを 固定長ベクトル にエンコード
• インデックス化
  • ベクトルを 近似最近傍検索 (ANN) 構造に格納（HNSW など）
• 検索 (similarity)
  • クエリもベクトル化し コサイン類似度・内積 などで距離計算
  • 全件走査せず 「あたり」を付けて高速探索

数値ベクトルに変換した後のベクトル空間でどれだけ近いかを表す類似度関数は以下のようなものがあります。

類似度関数	数式（概要）	特徴
コサイン類似度	1 − cosθ = 1 − (u·v / |u||v|)	向きの類似度。長さに影響されない
内積 (Dot Product)	u·v	コサインに長さの影響も加味（スコアが大きくなる傾向）
ユークリッド距離	|u−v|₂	“距離” として直感的。実装により平方根は省略可

• Tip: Azure AI Search / Pinecone / Milvus などのエンジンはコサインと内積をサポート。
• コサインはスケール不変なので扱いやすく、RAG の多くはコサインを採用。

以下が動作イメージになります。

1. データソース → Embedding
   • PDF/画像/音声などを Transform into embeddings でベクトル化
   • 例：[ -2, -1, 0, 1 ]
2. インデックス投入
   • HNSW グラフにベクトルを登録 → “ノード同士の近さ” を保存
3. 検索クエリ
   • 検索クエリ「RAG の教科書を生成 AI アプリ開発に取り組む皆様へ提供」をベクトル化ベクトル化 → [ 2, 3, 4, 5 ]
4. ANN 探索
   • HNSW で “近いノード” を段階的に探索
   • 近い文書ベクトルが返る
5. アプリ/UI に結果を返却
   • 上位 k 件のチャンクを RAG パイプラインへ

そんなベクトル検索にも、得意・苦手があります。
以下にまとめてみました。

得意	苦手
類語・言い換え・翻訳 (semantic match)	厳密なキーワード一致
長文 vs. 要約 / パラフレーズ検出	AND/OR など論理検索
画像 → テキスト、音声 → テキストなど クロスモーダル	正規表現・部分一致 ("RAG*" 等)
意味的クラスタリング・推薦システム	頻出語のフレーズ限定検索

こちらの検索方法も要件に合わせてご利用ください。

ベクトル検索のチューニング

ベクトル検索でのチューニングについて、以下のポイントを押さえてください。

• 検索アルゴリズムの選択

  アルゴリズム	特徴	いつ選ぶ？
  KNN (Exact)	全件走査 → 精度は最も高い だが検索速度が遅く、コスト・メモリ大	データセットが極小の場合のみ
  HNSW (Approximate)	事前に 近傍グラフ を構築 → 高速 に近似検索 精度と速度のバランス良	一般的にはこちらを推奨

• 結論: 実運用ではほぼ HNSW 一択。

• KNN は PoC や小データセットでの “理論値確認” 用。

• HNSW パラメータのチューニング

パラメータ	推奨範囲	効果	トレードオフ
m	4–10	各ノードのリンク数	大きい: 精度 ↑ 速度 ↓ インデックスサイズ ↑
efConstruction	100–1000	グラフ構築時の近傍探索数	大きい: 精度 ↑ 速度 ↓ インデックスサイズ ↑
efSearch	100–1000	検索時の近傍探索数	大きい: 精度 ↑ 速度 ↓

• 精度が足りないと感じたら 各値を段階的に上げる
• 逆に レイテンシが厳しい場合は efSearch を先に下げる

類似度メトリックの選択についても以下のポイントを押さえてください。

メトリック	数式（イメージ）	長所	短所	主なユースケース
Cosine Similarity 1 - cos θ = 1 - (u·v / ‖u‖‖v‖)	向き（角度）だけを比較するため、 ベクトル長の影響を受けにくい	– スケール不変で扱いやすい – 埋め込みモデルとの相性が良い	– スコアをそのまま「関連度」として使いにくい	自然言語 RAG、画像検索、Azure OpenAI の埋め込み
Dot Product (内積) u·v	コサイン類似度に 長さ（ベクトルの大きさ）の情報も含む	– 推薦システムで「スコア」を直接利用可	– 長い文ほどスコアが大きくなりやすい	レコメンド、ランキング (MRR/CTR 最適化)
Euclidean Distance ‖u - v‖₂	ベクトル間の直線距離をそのまま使用	– 値の解釈が直感的 (距離 = 0 が完全一致)	– 高次元で距離が均一化しやすい (ハブネス問題)	数値特徴量クラスタリング、 ログ類似度（低次元）

Azure OpenAI 埋め込みを使う場合は cosine が必須 (モデル側が正規化前提)。
内積 or ユークリッドを使いたい場合は 自前で正規化 するか、OSS 埋め込みモデルを検討すると良いでしょう。

埋め込みモデルの選択についても以下のポイントを押さえてください。

モデル名	次元数	精度	推論コスト / 速度	特記事項
text-embedding-3-large	5,120	★★★★★	★★☆☆☆ (コスト高・少し遅い)	精度最良。長文 2000 tok まで入力可
text-embedding-3-small	3,072	★★★★	★★★☆	小〜中規模 RAG に “バランス型”
text-embedding-ada-002	1,536	★★★	★★★★	低コスト・8k tok 対応。大量チャンク向き
multilingual-e5-large (OSS)	1,024	★★★★	★★★	100+ 言語対応。ベクトル長やランタイムを自前で用意
distiluse-base-multilingual (OSS)	512	★★☆	★★★★★	超軽量・多言語。リアルタイム API に好適

選び方の目安

1. 精度重視 → text-embedding-3-large
2. コスト／速度重視 → ada-002
3. 多言語 or ローカル推論 → e5 / sentence-transformers
4. 社内 GPU クラスタ がある場合は OSS を finetune する選択肢も

チューニングの進め方フローとしては以下になります。

フェーズ	やること	チェック指標	Go / No-Go 判定
① ベースライン構築	– text-embedding-3-small + HNSW + cosine – efSearch = 100 – チャンク 512 tok (15% overlap)	Recall@50, Latency p95, コスト/万リクエスト	OK なら次フェーズへ
② 精度改善	– efSearch を 300→500 と段階 UP – m = 4→8 で精度確認 – 必要ならモデルを small → large	Recall, Precision, ユーザ評価	指標向上 or コスト許容なら Fix
③ 速度 / コスト調整	– efSearch を最小化 (300→150) し P99 を測定 – インデックス sharding／キャッシュ導入	Latency	高速化と精度低下をトレード
④ 多言語 / 特定ドメイン対応	– 英語以外 → e5-large を追加発行 – 特定業種 → ada-002 ファインチューニング	マルチ言語 Recall, ドメイン BLEU	OSS or Fine-tune 成果 > baseline
⑤ 運用・モニタリング	– メトリクスダッシュボード (Recall@50, Latency, コスト) – efSearch/モデル Ver を Feature Flag で切替	週次 KPI, アラート閾値	異常値で自動 Rollback

Tips

• 1 つずつパラメータを動かし、AB テストで効果を確認
• ベクトル長とインデックスサイズは比例 → ストレージ見積もりを忘れずに
• モデル更新時は 再インデックス が必要。ブルー/グリーン方式でダウンタイム回避

まとめると、埋め込みモデルは 精度・次元数・多言語対応・コスト の 4 軸で選択し、チューニングは ベースライン → 精度向上 → 速度・コスト調整 の順が王道です。

セマンティックハイブリッド検索

セマンティックハイブリッド検索とは、テキスト検索 (キーワード) + ベクトル検索 (意味ベクトル) + セマンティックランカー (BERT 系再ランキング) を 三位一体 で組み合わせ、 リコール・精度・速度 をバランス良く最大化する検索方式。

3 層アーキテクチャとしては以下のような構成になります。

層	役割	主なエンジン / モデル
① 予備フィルタ (Keyword)	– ブール / BM25 / ワイルドカード – メタデータ (category eq 'AI')	Lucene, Azure AI Search Text, OpenSearch
② 意味検索 (Vector)	– クエリ & 文書を Embedding – HNSW など近似最近傍で候補 100〜300 件取得	Azure AI Search Vector, Pinecone, Milvus
③ セマンティックランカー	– 候補を BERT / Cross-Encoder で再スコア – 上位 10〜20 件を最終結果に	Azure Semantic Ranker, Cohere Rerank, OSS cross-encoder/ms-marco-*

動作フローとしては以下のようになります。

1. クエリ受信：「RAG の教科書　チャンク分割 理由」
2. Keyword Search：BM25 でトークン一致（高速・高リコール）
3. Vector Search：同時に意味ベクトルで ANN 検索（曖昧・同義語を補完）
4. Union & 重複除去：両結果をマージ (OR) or Weighted Merge
5. Semantic Re-ranking：BERT 系で文脈を読み取り最終順位付け
6. Top-k を返却：検索 UI or RAG パイプラインへ

動作イメージとしては以下

フルテキスト検索やベクトル検索単体と比べ、なぜ強いのかまとめてみました。

観点	従来	セマンティックハイブリッド
リコール	Keyword だけ：語形揺れに弱い	Vector が 同義語 を補完
プレシジョン	Vector だけ：ノイズ混入	Keyword で 正確一致、ランカーで誤ヒット排除
速度	Keyword◎ / Vector○ / BERT△	Keyword 先行で 高速フィルタ、ランカーは少量
コスト	Vector + BERT を全件に適用 → 高	再ランク対象を 数百件 に絞るため低コスト

キーワード検索 + ベクトル検索 + セマンティックランカーの組み合わせが最も高い精度が出せることが分かります。

Prompt Engineering のポイント

RAG では Prompt Engineering が重要なポイントになります。
特に以下のポイントを押さえておくと良いでしょう。

Prompt Engineering がなぜ必要か

Prompt Engineering が必要とされる理由は以下の通りです。

観点	なぜ重要か	具体例
品質向上	LLM は「曖昧な指示」だと⾼確率で曖昧な出⼒を返すため、意図を明確に与えることで精度が上がる	「◯◯ について教えて」よりも「◯◯ のメリットとデメリットを 3 点ずつ、200 字以内で列挙して」と指示した方がブレが減る
制御性	出⼒フォーマット・スタイル・分量を統⼀できるので、後段処理や UI で扱いやすい	JSON で返す、Markdown で箇条書き、などの指定
業務要件への適合	ドメイン語彙・社内ルール・禁⽌ワードを prompt でガイドしてコンプライアンスを守る	「＊＊株式会社」と必ず記載する、特許内容は要約のみ出力など
コスト最適化	無駄なトークンを削り、推論コストやレイテンシを削減できる	不要な前置きや長文回答を禁止する制約を入れる
安全性（ガードレール）	有害・機密情報の漏えいを抑制し、期待外の挙動を防ぐ	“Do not output personal data” などを system prompt に埋め込む
モデルの弱点補完	💬「Chain-of-Thought」や RAG などで 分解／検索／根拠提示を誘導し、推論能力を補強する	RAG で根拠ドキュメントを渡し「以下の context のみ参照して答えよ」と明示
再現性	テスト・評価の際に同じ prompt ⇒ 同じ出力傾向を得られるため、品質保証がしやすい	A/B テストや自動評価で差分を計測可能
自動化・連携	Function Calling など API 連携において、パラメータ抽出やツール選択をモデルに委ねられる	自社 KB 検索／SQL 実⾏など外部ツール呼び出しを指示

LLM は「暗黙知」を埋め込んだ強⼒な汎⽤モデルだが、**“何を・どのように”**させたいかを言語で細かく指定しないと期待値どおりには動かないという点もある。

Prompt Engineering は UI/UX・品質・安全性・コストを横断的に最適化する “仕様書” の役割を果たす。

Azure OpenAI + RAG の場合は、
① 検索クエリ生成 → ② 根拠注入 → ③ 回答生成 の各段階で prompt を設計し、全体フローを “言語” で制御することで初めてエンタープライズ品質が実現できる

LLM のモデルの選択について

. テキスト生成モデルの選択

• 回答精度向上のためには最新で大きなモデルを使用
• (現時点では gpt-4o、もしくは、丁寧な回答、複雑な推論が必要な場合は o1 推奨)
• 回答速度も重要な場合は軽量なモデルを使用することも (gpt-4o mini や o3-mini など)
• AI Studio モデルカタログにて他モデルが選択可能 (Llama 3.1, Mistral, Databricks Dolly など)
• ”Garbage In, Garbage Out”, Retrieve したデータに回答に必要な情報が含まれていないと、
• どんなモデルを使っても正しい回答ができない (検索精度が最重要)

. 埋め込みモデルの選択

• ベクトル検索の精度に影響
• 基本的に text-embedding-3-large を使用する (埋め込みモデル最高価だが非常に安価)
• その他の選択肢
• AI Studio モデルカタログにて Cohere-embed-v3-multilingual が利用可能
• その他 OSS の埋め込みモデルを Azure ML 上で稼働させて利用する
• 既存 OSS 埋め込みモデルをファインチューニングして使用する

LLN の特性と使い分け – “Inference”モデルと“Reasoning”モデル

項目	Inference 系 (GPT-4o / GPT-4.1 / GPT-3.5 など)	Reasoning 系 (o1 / o3 / o4-mini など)
主目的	高速・低コストで汎用生成 翻訳 / 要約 / 文章生成 / チャット	複雑な論理推論・マルチステップ問題解決 数学・コード・科学・計画立案
思考スタイル	1 パスで即座に出力 ― “答えだけ” （チェーン・オブ・ソートは内部で最小限）	考えてから答える ― 内部／外部に CoT を持ち、必要に応じて“推論 effort”を増減
速度・コスト	低レイテンシ / 安価（トークン単価が安い）	同じトークン量でも3 ～ 30 倍程度遅く高価（推論計算を多く回すため）:contentReference[oaicite:0]{index=0}
精度の傾向	パターン認識系の質問や “日常業務” に強い 例: メール下書き、SNS 投稿作成	Chain-of-Thought を要する数式・アルゴリズム・長い計画に強い:contentReference[oaicite:1]{index=1}
機能	マルチモーダル (GPT-4o)・⻑コンテキスト・Function Calling	同上 + reasoning effort パラメータ Parallel tool calling が最適化
代表モデル	GPT-4o, GPT-4.1, GPT-4o-mini, GPT-3.5-Turbo	o1 / o1-mini, o3 / o3-mini, o4-mini:contentReference[oaicite:2]{index=2}
ベンチマーク	MMLU ~85 – 90, AIME ~10 %	GPQA / AIME で 大幅超え 例: o1 が AIME 74 % (pass@1) で GPT-4o を圧倒:contentReference[oaicite:3]{index=3}
典型ユースケース	– FAQ ボット – コンテンツ生成 – 低遅延チャット UI	– 数理最適化・ファイナンス計算 – コード自動修正 & 単体テスト生成 – 社内ナレッジから “根拠付き” 戦略レポート

---

選択ガイドライン

1. まず Inference モデルをデフォルトに

   • 速度／コスト優先のフロントエンド、RAG の“回答生成”フェーズなど。
   • 十分な精度が得られない or 論理飛躍が目立つ場合に Reasoning へスイッチ。

2. Reasoning モデルを初手で選ぶ場面

   • 数学証明、会計ロジック、複雑なコード生成のように 間違うと致命的 なドメイン。
   • ツール呼び出しやマルチステップ思考を “エージェント” に丸投げしたい場合。

3. ハイブリッド戦略

   • Planner 役に Reasoning (o3) を使って手順や API 呼び出しパラメータを作成 →
     Executor 役に Inference (GPT-4o-mini) で高速に文章生成。
   • Azure では同一 API でモデル切替えが可能。model_router を使うと動的ルーティングも可。

まとめ としては以下のようになります。

• Inference = 汎用・高速・安価
  「どんな文章でもそこそこ良い答え」を即返したい場合はこちら。
• Reasoning = 深い論理・多段思考
  正しさ重視 or 複雑手順の自動化で威力を発揮。
• 迷ったら: まず Inference → テストで限界を感じたら Reasoning に切替え or ハイブリッド構成で両立。

RAG の評価では、大きく分けて２種類の精度評価が可能

• 検索精度の評価 (Store~Retrieve 箇所の評価)
• 回答精度の評価 (Store~Generation 全体の評価)

それぞれの項目の評価方法について解説します。

検索精度

検索精度については、評価用データの準備、評価指標の設定が必要になります。
以下に観測ポイントをまとめます。

• 評価用データの準備
  • [検索クエリ], [検索ドキュメント ID], [関連度] のリストを用意する(100 件~)
  • 検索ドキュメントは検索エンジンに格納されているものであるためチャンクとなりえる
  • チャンクサイズが変われば検索ドキュメント ID も変わるため、当該箇所の正規表現を使って評価する方法も考え
  • られる
• 評価指標
  • ヒットレート(HitRate@N): 関連ドキュメントが 1 件でも上位 N 位にランクしている割合
  • 平均逆数順位(MRR@N): 検索結果において最初に正解が出現する順位の逆数の平均
  • 平均適合率(mAP@N):複数の検索クエリに対する適合率 (Precision) の平均
  • nDCG@N: 検索結果の順位に基づいて関連性の高い結果が上位であるほど高いスコアを得る指標
• 検索精度の重要性
  • 定量的評価が可能 (生成精度評価は LLM に依存した評価なので定性的評価に近い)
  • 検索精度が回答精度に直結するため、非常に重要な評価

回答制度

回答精度についても評価用のデータと評価方法が必要になります。
こちらについても観測ポイントをまとめます。

• 評価用データの準備
  • [質問], [想定回答]のリストを用意する
  • 評価処理にて、各質問への[生成した回答]と[取得したドキュメント]ができる
• 精度の評価方法
  • ROUNGE: 生成されたテキストの品質を評価するためのメトリック, n-gram を使用
  • BLEU: 機械翻訳やテキスト生成の品質を評価するためのメトリック (n-gram を使用)
  • BertScore: 生成文章と正解文章の類似度を埋め込みを利用して評価
  • LLM as a Judge: LLM を使用して生成文章を評価

LLM as a Judge での評価指標で主要なものは以下になります。

• 一貫性 (Consistency)
• 関連性 (Relevance)
• 流暢さ (Fluency)
• カバレッジ (Coverage)
• 多様性 (Diversity)
• 詳細度 (Detail) など

上記のような観点から、RAG の精度を評価することができます。

よく聞かれる質問に RAG と Fine-Tuning の違いがあります。
RAG (Retrieval-Augmented Generation) と Fine-Tuning は、どちらも LLM の精度を向上させるための手法ですが、アプローチが異なります。

RAG は、外部の知識ベースやドキュメントを活用して、生成する回答の精度を向上させる手法です。具体的には、以下のような特徴があります。

• 外部知識の活用: RAG は、事前に用意されたドキュメントや知識ベースから情報を取得し、それを基に回答を生成します。これにより、モデルが持つ知識の範囲を超えた情報を利用できます。
• 動的な情報取得: RAG は、ユーザの質問に応じてリアルタイムで関連する情報を検索し、回答に組み込むことができます。これにより、最新の情報や特定のドメインに特化した知識を活用できます。

Fine-Tuning は、既存の LLM を特定のタスクやドメインに適応させるための手法です。具体的には、以下のような特徴があります。

• モデルの適応: Fine-Tuning は、特定のタスクやドメインに対してモデルを再学習させることで、モデルのパラメータを調整します。これにより、特定のタスクに対する精度を向上させることができます。
• データセットの必要性: Fine-Tuning には、特定のタスクやドメインに関連する大量のトレーニングデータが必要です。これにより、モデルはそのデータセットに基づいて学習し、特定の知識を獲得します。
• 静的な知識の強化: Fine-Tuning は、特定のドメインやタスクに特化した知識をモデルに組み込むことができますが、RAG のようにリアルタイムで情報を取得することはできません。
• モデルの再学習: Fine-Tuning は、既存のモデルを再学習させるため、計算リソースや時間が必要です。
• 特定のタスクに特化: Fine-Tuning は、特定のタスクやドメインに対してモデルを最適化するため、汎用性が低くなる可能性があります。
• モデルのサイズ: Fine-Tuning は、モデルのサイズを大きくすることができるため、より多くのパラメータを持つモデルを使用できます。
• モデルの更新: Fine-Tuning は、特定のタスクやドメインに対してモデルを更新するため、モデルのバージョン管理が必要です。
• モデルの再利用性: Fine-Tuning は、特定のタスクやドメインに対してモデルを最適化するため、他のタスクやドメインに再利用することが難しい場合があります。

RAG と Fine-Tuning の違いをまとめると以下のようになります。

観点	Fine tuning（API 経由）	RAG
推奨用途	① 出力形式・トーンの調整 ② タスク精度の強化 ③ トークン節約（フルチューニングなら語彙拡張も可）	知識やロジックの獲得
コスト	① GPU 学習時間に応じたコスト ② 専用エンドポイント稼働時間に応じたコスト	① 検索エンジン利用料 ② 入力情報追加による 毎リクエストのトークンコスト増
生成速度への影響	入力トークン量が減るため 速度への影響ほぼ無し	検索アクセス & プロンプト増大で Fine tuning より遅い
データ取り込み時間	データサイズに依存し 数分〜数時間 の学習が必要	検索エンジンにデータ投入後 即時反映
リソース調達	GPU が必要なため 利用リージョンが限定	検索エンジンは多リージョン対応で 調達容易
技術	NN 学習手法の知見 + トレーニングデータ作成／品質確保	チャンク設計・ベクトル検索・Prompting の知識

RAFT (Retrieval Augmented Fine Tuning) という手法

RAFT (Retrieval Augmented Fine Tuning) は、RAG のアプローチを Fine-Tuning に組み合わせた手法です。
RAFT の特徴は以下の通りです。

• RAG の活用: RAFT は、RAG の Retrieve フェーズを活用して、外部の知識ベースやドキュメントから情報を取得します。
• Fine-Tuning の適用: 取得した情報を基に、モデルを Fine-Tuning することで、特定のタスクやドメインに対する精度を向上させます。
• 動的な情報取得と適応: RAFT は、ユーザの質問に応じてリアルタイムで関連する情報を検索し、その情報を基にモデルを Fine-Tuning します。これにより、最新の情報や特定のドメインに特化した知識を活用できます。

https://techcommunity.microsoft.com/blog/aiplatformblog/retrieval-augmented-fine-tuning-use-gpt-4o-to-fine-tune-gpt-4o-mini-for-domain-s/4248861

端的に言うと、RAG の Retrieve フェーズで情報を取得し、その情報を基にモデルを Fine-Tuning することで、特定のタスクやドメインに対する精度を向上させる手法です。

RAG と Fine-Tuning のいいとこどりができますね。

CAG ( Cache-Augmented Generation )とは

Cache-Augmented Generation は、Retrieval-Augmented Generation（RAG）の“検索”ステップを丸ごとスキップし、事前にモデルへ読み込んだ知識と KV-cache（推論時に生成されるキー・バリューキャッシュ）だけで回答を生成する手法です。

RAG では実行時に都度外部リソースを検索・取得 (retrieval) してから生成モデルへ入力するのに対し、CAG では「関連するドキュメントや知識をあらかじめ長いコンテキストウィンドウへ読み込み (preload)」し、さらに生成モデルのキー・バリュー(KV)キャッシュを事前に用意しておくことで、推論中のリアルタイムな検索を完全に省略する手法を示しています。

CAG のメリット

1. 検索時間削減：推論時に検索が不要なので、リアルタイムの遅延を削減
2. 統合的なコンテキスト：すべてのドキュメントを一度に読み込むため、モデル
   が全体を俯瞰した上で回答を生成可能。部分的な文書取得の失敗や欠
   落が起こらない
3. システムの単純化：検索エンジンと LLM を組み合わせる複雑なパイプライ
   ンが不要になり、開発・保守コストが低減する。

https://arxiv.org/abs/2412.15605

最近はあまり聞きませんが、要件によっては活躍しどころがあるかもしれません。

今回の RAG の知見もそうですが、Microsoft から RAG に関する知見が公開されています。

https://github.com/microsoft/RAG-Knowledge

RAG のプロジェクトに関わる方には是非ご一読していただけますと、アウトプットの質が向上するかと思いますので、是非ご参照ください。

また、本記事でご紹介した AgenticRAG は今後のかなり重要なトピックとなると考えています。
一通りキャッチアップしたい方は以下のリンクをご参照ください。

https://github.com/microsoft/ai-agents-for-beginners/blob/main/05-agentic-rag/README.md

RAG とはなにかという基本的なところから、どのように精度を高めていくかという発展的な内容まで取り扱いました。
もう一度まとめると RAG は Store, Retrieve, Augment, Generate の 4 つのフェーズで構成されており、それぞれのフェーズでのチューニングが重要です。

現在取り組まれている RAG プロジェクトの状況を正確に把握しつつ、各フェーズでのチューニングを行うことで、RAG の精度を高め、質の高い GenAI アプリケーションを構築していただければと存じます。

Store	Retrieve	Augment	Generate
PDF ファイルのテキスト化	検索アルゴリズム	システムメッセージ定義	モデル選択（回答生成）
Office ファイルのテキスト化	アルゴリズムのパラメータチューニング	ユーザメッセージ定義	モデル選択（埋め込みモデル）
音声データのテキスト化	スコアリングプロファイル	検索クエリ生成	マルチモーダル
動画データのテキスト化	カスタムアナライザ	ユーザへの聞き返し	ファインチューニング
画像データのテキスト化	類似度チューニング	仮説的文書埋め込み	—
チャンク分割（チャンクチューニング）	—	Function Calling	—
オーバラップ	—	—	—
テーブル構造抽出	—	—	—
エンリッチメント	—	—	—
カテゴリ付け	—	—	—

それでは 🖐️

https://github.com/microsoft/RAG-Knowledge

https://ai.meta.com/blog/retrieval-augmented-generation-streamlining-the-creation-of-intelligent-natural-language-processing-models/

https://www.promptingguide.ai/jp/techniques/rag

https://ja.wikipedia.org/wiki/ハルシネーション_(人工知能)

https://arxiv.org/abs/2501.09136

https://github.com/microsoft/ai-agents-for-beginners/tree/main

https://speakerdeck.com/hirosatogamo/chatgpt-azure-openai-da-quan

https://techcommunity.microsoft.com/blog/azure-ai-services-blog/azure-ai-search-outperforming-vector-search-with-hybrid-retrieval-and-reranking/3929167