RAG / Context Engineering 完全ガイド¶

LLMに「検索（Retrieval）」を組み合わせて根拠のある回答や社内知識の活用を可能にする設計パターン。
現在は長文コンテキスト、MCP、Agentic Search、コード探索も選択肢に入るため、「何を検索し、何をコンテキストに載せ、何をツール化するか」を分けて設計します。

このハブで扱うこと

論文・OSS・実装記事を読む前に、RAG、長文コンテキスト、MCP、Agentic Searchを同じ「根拠を渡す設計」として整理します。個別技術の紹介だけでなく、どの条件でどれを選ぶかを見ます。

RAGとは¶

RAG（Retrieval-Augmented Generation）は、モデルにすべてを記憶させるのではなく、回答時に必要な文書やデータを取り出してコンテキストとして渡す設計です。重要なのは「ベクターDBを使うか」だけではありません。検索対象、権限、更新頻度、根拠提示、評価方法まで含めて設計します。

まず読む記事¶

RAG三類型入門
Classic RAG / Graph RAG / Agentic RAGを「取ってくる・つなぐ・考える」で整理する入門記事。
RAG順位改善とreranker
RAGの回答ズレを、検索順位と「読み直す」rerankerの考え方から整理する初心者向け記事。
コンテキストエンジニアリングの全体像
RAG・MCP・Agent Skills・ロングコンテキストをどう使い分けるか。
LLM Wiki設計思想
RAGを毎回の検索ではなく、永続的なwiki更新として扱うコンテキスト設計。
RAG不要論争を整理
ベクターDB依存型RAGの限界と、Agentic Searchやコード探索の位置づけ。
企業内AI活用
社内知識をAIに渡すときの業務・権限・運用設計。

設計で見るポイント¶

観点	問い
検索対象	どの文書・DB・コードを参照させるか
コンテキスト	検索結果をどの粒度で渡すか
権限	ユーザーごとに見せてよい情報をどう制御するか
更新	文書やインデックスをどの頻度で更新するか
評価	検索品質と回答品質をどう分けて測るか

実装記事アーカイブ¶

以下は過去の実装寄り記事です。SageMaker前提の内容を含むため、まずは上の設計記事から読む方が安全です。