# RAGとは — 検索で根拠を渡す構成の設計と限界

> RAGの定義、Fine-tuningやWeb検索機能との違い、Chunking・Embedding・Rerank・権限フィルタの構成と、検索と生成を分けて評価する方法を整理します。

Canonical URL: https://labs.eastbraver.com/guides/rag
Published: 2026-07-14
Updated: 2026-07-24
Category: field-guide
Tags: llm-inference, software-engineering, infrastructure

RAGはRetrieval-Augmented Generationの略です。[LLM](/guides/llm)の学習済み知識だけに頼らず、Requestのたびに外部から関連情報を検索して[Context](/guides/context)へ渡し、その根拠をもとに生成する構成を指します。

[RAGの原論文](https://arxiv.org/abs/2005.11401)は、モデルの重みに入った知識 (Parametric) と、検索で取り出す知識 (Non-parametric) を組み合わせることで、より具体的で事実に基づく生成ができることを示しました。

このGuideは、2026年7月14日時点の一次情報を基準にしています。検索手法とManaged Serviceの機能は更新が速い領域のため、構成の判断時には最新のドキュメントも確認してください。

## RAGの持ち場は「鮮度と出典」

| 手段 | 知識の置き場所 | 向いている課題 |
| --- | --- | --- |
| 学習済み知識 | モデルの重み | 一般知識、言語能力 |
| RAG | 検索できる文書・データ | 自社文書、鮮度、出典の提示 |
| [Fine-tuning](/guides/fine-tuning) | モデルの重み | 形式・文体・分類の一貫性 |
| [Tool](/guides/tool)呼び出し | 外部システムの現在状態 | 在庫、注文、リアルタイムの値 |

「最新の状態を一件取る」ならToolで直接取得する方が確実です。RAGが向くのは、大量の文書から関連する根拠を探し、出典つきで答えたい場合です。

## 構成は取り込み、検索、生成の三段階

### RAGのindexingと回答生成

DocumentsはChunkingとEmbeddingを経てIndexへ登録され、User queryに応じて関連情報をRetrieveします。取得結果をRerankまたはFilterしてContextへまとめ、LLMがCitation付きのAnswerを生成します。

- DocumentsやDataをChunkingし、Embeddingを作ってIndexへ登録します。
- User queryに対してIndexから候補をRetrieveします。
- 候補をRerankまたはFilterしてContextへまとめます。
- LLMがContextを使い、Citation付きのAnswerを返します。

*Documentsのindexingから検索結果を使った回答生成までの流れ*

[Amazon Bedrock Knowledge Bases](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html)のようなManaged Serviceは、この取り込み・Index・検索・引用の流れを提供します。自前で組む場合も、各段階の設計判断は同じです。

- Chunking: 文書をどの単位で分割するか
- Embedding: どのモデルでベクトル化するか
- 検索: ベクトルだけか、キーワードやメタデータを併用するか
- Rerank: 取得候補をどう並べ直すか
- 引用: 回答へ出典をどう付けるか

分割は情報を失う処理でもあります。[AnthropicのContextual Retrieval](https://www.anthropic.com/news/contextual-retrieval)は、Chunk単体では前後の文脈が消えて検索に失敗する問題に対し、各Chunkへ文脈を付与してから索引化する手法で、検索失敗を49パーセント、Rerank併用で67パーセント削減したと報告しています。手法の細部より、**Chunkは文脈を失うという前提**を持っておくことが重要だと思います。

## 検索Indexは第二のデータベース

RAGを入れると、本番データの写しがもう一つ増えます。Webエンジニアとして確認したいのは、検索精度より先にこちらです。

- 権限: 利用者が読めない文書を、検索経由で返していないか。文書レベルの権限フィルタを検索時に強制できるか
- 鮮度: 元データの更新・削除がIndexへ反映されるまでの遅延
- 個人情報: Embeddingと検索ログに何が残るか、保持期間はどうか
- 信頼境界: 取得した文書は未信頼の入力であり、[Prompt Injection](/guides/prompt-injection)の経路になる

特に権限は、生成側では守れません。Contextへ入った時点でモデルは読めるので、権限フィルタは検索層で強制します。

## 検索と生成を分けて評価する

RAGの失敗は一種類ではありません。

| 失敗 | 起きていること | 主な改善先 |
| --- | --- | --- |
| 根拠が見つからない | 検索の再現率不足 | Chunking、Embedding、検索方式 |
| 無関係な根拠を渡す | 検索の適合率不足 | Rerank、フィルタ、Query設計 |
| 根拠を読み違える | 生成の忠実性不足 | Prompt、モデル、引用の強制 |
| 根拠に無いことを補う | 根拠外の生成 | 忠実性の評価、出典必須の契約 |

回答だけを見ると、どこで失敗したか分かりません。検索の再現率・適合率と、生成の忠実性を分けて測り、[評価](/guides/ai-agent-evaluation)セットには「根拠が存在しない質問」も含めます。正しい振る舞いは「分かりません」だからです。

## よくある誤解

### RAGにすればHallucinationは無くなる

減らせますが、消えません。根拠の読み違え、根拠外の補完、検索失敗時の推測は残ります。出典の提示と忠実性の評価を組み合わせます。

### 文書を全部入れれば精度が上がる

無関係な文書は検索ノイズと[Context](/guides/context)の浪費になります。対象範囲を決め、検索品質を測ってから広げます。

### Embedding検索だけで十分

固有名詞・型番・日付はキーワード検索の方が強い場合があります。ベクトル・キーワード・メタデータの併用とRerankを検討します。

### RAGはFine-tuningの代わりになる

目的が違います。知識の鮮度と出典はRAG、形式や文体の一貫性は[Fine-tuning](/guides/fine-tuning)。両方使う構成もあります。

### 検索できていれば答えも正しい

検索の成功と生成の成功は別の評価軸です。根拠を渡しても、読み違えれば誤答になります。

## EastBraver Labsの判断基準

EastBraver Labsでは、RAGを「精度を上げる魔法」ではなく、**回答へ出典を付けるための構成**として扱います。

導入前に確認するのは、答えの根拠となる文書を人間が特定できるかどうかです。人が探せない根拠は、検索でも安定して見つかりません。人が特定した質問と根拠の組が、そのまま最初の評価セットになります。

権限フィルタは検索層で強制し、取得文書は未信頼データとみなします。検索と生成は別々に評価し、根拠が無いときに黙って推測しない振る舞いを確認してから本番へ出します。

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [モデル運用の選択肢が広がる](/digest/ai-digest-20260707)
- [エージェント運用の境界が具体化](/digest/ai-digest-20260709)

## 検証範囲

- 一次情報: 公式ドキュメント / 研究論文 / 設計面からの分析
- ローカル検証: コードは動かしていません
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-14: 初版公開