RAG / Context Engineering 完全ガイド¶
LLMに「検索（Retrieval）」を組み合わせて根拠のある回答や社内知識の活用を可能にする設計パターン。
現在は長文コンテキスト、MCP、Agentic Search、コード探索も選択肢に入るため、「何を検索し、何をコンテキストに載せ、何をツール化するか」を分けて設計する。
対象: 社内知識をAIへ渡す設計を比較したい人
論文・OSS・実装記事を読む前に、RAG、長文コンテキスト、MCP、Agentic Searchを同じ「根拠を渡す設計」として整理する。個別技術の紹介だけでなく、どの条件でどれを選ぶかを見る。
この記事のポイント¶
- RAGは検索だけでなく、権限、更新、根拠提示、評価まで含む設計だ
- 長文コンテキスト、MCP、Agentic Searchとは根拠の渡し方が異なる
- PDFなどの入力整備と、検索結果・回答の評価を別工程として考える
RAGとは¶
RAG（Retrieval-Augmented Generation）は、モデルにすべてを記憶させず、回答時に必要な文書やデータを取り出してコンテキストとして渡す設計だ。 重要なのは「ベクターDBを使うか」だけではない。検索対象、権限、更新頻度、根拠提示、評価方法まで含めて設計する。
まず読む記事¶
Classic RAG / Graph RAG / Agentic RAGを「取ってくる・つなぐ・考える」で整理する入門記事。
RAGの回答ズレを、検索順位と「読み直す」rerankerの考え方から整理する初心者向け記事。
RAG・MCP・Agent Skills・ロングコンテキストをどう使い分けるか。
RAGを毎回の検索ではなく、永続的なwiki更新として扱うコンテキスト設計。
図表や数式を含むPDFをMarkdown化し、欠落を検査してRAGへ渡す前処理を整理する。
ベクターDB依存型RAGの限界と、Agentic Searchやコード探索の位置づけ。
社内知識をAIに渡すときの業務・権限・運用設計。
設計で見るポイント¶
| 観点 | 問い |
|---|---|
| 検索対象 | どの文書・DB・コードを参照させるか |
| コンテキスト | 検索結果をどの粒度で渡すか |
| 権限 | ユーザーごとに見せてよい情報をどう制御するか |
| 更新 | 文書やインデックスをどの頻度で更新するか |
| 評価 | 検索品質と回答品質をどう分けて測るか |
まとめ¶
RAGの選択は、ベクターDB製品の比較から始めるものではない。 根拠の所在、利用者の権限、更新頻度、失敗を測る評価方法を先に決めると、長文コンテキストやMCPとの役割分担も見えやすくなる。
関連記事¶
以下は過去の実装寄り記事だ。SageMaker前提の内容を含むため、まずは上の設計記事から読む方が安全である。
