RAGはあくま概念でKnowledge Baseは必須でAgents は選択可能です。
- Knowledge Baseを使うこと = RAGを実践していること です。両者は切り離せません。
- Agentは、Knowledge Baseを含む複数の道具を使い分ける司令塔です。
- 道具がKnowledge Baseだけで良い場合、Agentは不要です。その際は
RetrieveAndGenerate
API を使うことで、シンプルかつ強力なQ&Aシステムを構築できます。
3つの概念の要点
まず、一言でそれぞれの役割を表現するとこのようになります。
- RAG (Retrieval Augmented Generation):
- 役割: **「手法・概念」**です。LLM(大規模言語モデル)がより正確な回答を生成するための「やり方」や「考え方」そのものを指します。
- 例えるなら: 「オープンブック試験の解き方」。質問に対して、まず教科書(社内文書など)で関連箇所を探し、その内容を参考にして回答を作成する、という一連のプロセスです。
- Knowledge Base for Amazon Bedrock:
- 役割: **「RAGを実現するためのマネージドサービス・道具」**です。RAGという手法を、AWS上で簡単に実現してくれる便利なツールキットです。
- 例えるなら: 「完璧に整理・索引化された教科書と、それを高速で検索できるシステム」。オープンブック試験のために、教科書を読み込んで、重要な部分に付箋を貼り、どこに何が書いてあるか瞬時に引けるように準備してくれる仕組み全体です。
- Agents for Amazon Bedrock:
- 役割: **「思考し、行動する司令塔(オーケストレーター)」**です。ユーザーの複雑な要求を理解し、Knowledge Baseを含む様々なツールを自律的に使い分けて、タスクを遂行します。
- 例えるなら: 「優秀なアシスタント」。単に教科書(Knowledge Base)を調べるだけでなく、「この計算は電卓(=データベースへのSQL問い合わせ)を使った方が早いな」「この件は〇〇さん(=外部API)に聞いた方が確実だ」と判断し、複数の道具を組み合わせて最終的な報告書を作成してくれます。
なぜ「RAGなし」で「Knowledge Base」は使えないのか?
これは、2つの関係性を理解すると明確になります。
- RAG (Retrieval Augmented Generation): これは**「手法・概念」です。LLMが知らない情報(社内文書など)について答えるために、「まず情報を検索(Retrieve)し、見つかった情報を基に回答を生成(Generate)する」という一連のやり方**のことです。
- Knowledge Base: これは**「RAGを実現するためのAWSのサービス・道具」**です。
つまり、Knowledge Baseは、RAGという手法をAWS上で簡単かつ効率的に実現するために作られたマネージドサービスです。
料理に例えるなら:
- RAGは「野菜を切って、炒めて、味付けする」という**「炒め物という調理法」**です。
- Knowledge Baseは「自動で野菜を切り、最適な火加減で炒め、味付けまでしてくれる高機能な自動調理器」です。
この自動調理器(Knowledge Base)を使うこと自体が、「炒め物」(RAG)という調理法を実践して
簡単な構成図と処理フロー
この3つの関係性を、2つの構成パターンで見てみましょう。
パターンA:シンプルなQ&Aシステム(Knowledge Baseのみを利用)
社内文書に関する質問に答えるだけの、最もシンプルな構成です。
構成図:
[ユーザー] <=> [アプリケーション] <=> [Bedrock API]
|
+-----> [Knowledge Base] (文書を検索)
| |
| V
+-----> [LLM (基盤モデル)] (検索結果を元に回答生成)
処理フロー:
- ユーザーが「昨年度のセキュリティ規定について教えて」と質問します。
- アプリケーションは、その質問をBedrockの
RetrieveAndGenerate
APIに送ります。 - Bedrockは内部でKnowledge Baseにアクセスし、質問に関連する社内文書の箇所(例:「セキュリティ規定 v3.1」のPDF)を検索して見つけ出します。
- 「ユーザーの質問」と「見つかった文書の内容」をセットにして、**LLM(基盤モデル)**に渡します。
- LLMは、見つかった文書の内容を元に、「昨年度のセキュリティ規定はv3.1で、主な変更点は…」という正確な回答を生成します。
この構成では、RAGという手法をKnowledge Baseというサービスを使って実現しています。
パターンB:高度なタスク処理システム(Agentが司令塔となる)
データベース検索や外部API呼び出しも含む、より複雑なタスクを実行する構成です。
構成図:
[ユーザー] <=> [アプリケーション] <=> [Agents for Amazon Bedrock]
|
(ユーザーの要求を解釈し、思考・判断)
|
+----------------------------------+------------------------------------+
| (A: 文書情報が必要と判断) | (B: DBのデータが必要と判断) | (C: 外部情報が必要と判断)
V V V
[Knowledge Base] [Lambda関数 (SQL実行)] [Lambda関数 (外部API呼び出し)]
| | |
+----------------------------------+------------------------------------+
| (各ツールからの結果を統合)
V
[LLM (基盤モデル)] (最終的な回答を生成)
処理フロー:
- ユーザーが「先月の薬の受け取りサービスを利用した東京在住の人数を調べて、その結果を要約したレポートを提出して」と、複雑な指示をします。
- Agentは、この指示を複数のステップに分解します。
- ステップ1: 「薬の受け取りサービスを利用した人数」→ これはデータベースを調べる必要があるな。
- ステップ2: 「東京在住」→ データベースの条件にこれも加えよう。
- ステップ3: 「結果を要約したレポート」→ 最終的な回答の形式だな。
- Agentは、ステップ1と2を実行するために、ツールの中から**「Lambda関数(SQL実行)」を選択**して呼び出します。Lambda関数がデータベースから利用者数を取得し、結果をAgentに返します。
- もしユーザーの指示に「当社のプライバシーポリシーも記載して」といった内容が含まれていれば、Agentは追加でKnowledge Baseを呼び出して関連文書を検索します。
- Agentは、各ツールから得られた情報(DBからの利用者数、Knowledge Baseからの文書など)をすべて統合し、LLMに渡して最終的なレポートを作成させ、ユーザーに回答します。
まとめ
このように、RAGという考え方を実現するのがKnowledge Baseであり、そのKnowledge Baseや他の様々な機能を賢く使いこなすのがAgentである、と理解していただくと非常に分かりやすいかと思います。
項目 | RAG (手法・概念) | Knowledge Base (サービス・道具) | Agent (司令塔・アシスタント) |
位置付け | 「How / やり方」 | 「What / RAGをやる道具」 | 「Who / 道具を使いこなす実行者」 |
役割 | LLMの回答精度を向上させるための考え方 | 文書データを準備・検索可能にする仕組み | ユーザーの要求を解釈し、ツール群を使い分ける |
関係性 | – | RAGという手法を実現するためのサービス | Knowledge Baseを数ある道具の一つとして利用することができる |
コメント