AWS BedrockでCDKとマネージドナレッジベースを用いたエージェント型リトリバルを構築
Amazon Web Servicesは、Managed Amazon Bedrock Knowledge BasesとAWS Cloud Development Kitを使用してエンタープライズ向けのエージェント型リトリバルを展開する方法について詳述しています。これにより、手動でのベクトルストア管理が自動化に置き換えられます。
英語の原文から自動翻訳されました。
Amazon Web Servicesは、Managed Amazon Bedrock Knowledge BasesとAWS Cloud Development Kit(CDK)を使用してエンタープライズグレードのエージェント型リトリバルシステムを構築する方法を詳細に説明する技術ガイドを公開しました。2026年10月下旬にリリースされたこのアプローチは、複数のデータドメインにわたって動的に計画、取得、引用を行う推論エージェントを組み込むことで、従来の単発のリトリーバル拡張生成(RAG)を超えています。このソリューションは、マルチターンAIインタラクションに伴う運用の複雑さに対処するため、組み込みの可観測性と評価を重視しています。
何が起きたか
従来のRAGシステムは通常、線形なパスに従います。ユーザーの質問を埋め込み、単一のインデックスから最も近いデータチャンクを取得し、回答を生成します。単純なクエリには有効ですが、回答に複数のコーパスからの情報が必要な場合や、関連するソースが微妙なコンテキストに依存する場合には、この手法は失敗することがよくあります。このような場合、単一のリトリバルステップでは不完全または誤解を招くデータが返されることがあり、流暢だが不正確な応答につながります。これらの制限に対処するため、Amazon BedrockはKnowledge Baseサービスを進化させ、推論エージェントがデータの取得の有無、参照すべきナレッジベース、最終的な回答を作成する前に追加の検索が必要かどうかを決定するエージェント型リトリバルをサポートするようにしました。
新しいアーキテクチャは、取り込み、ストレージ、インデックス作成、リトリバルを自動的に処理するサービス機能であるManaged Knowledge Baseに依存しています。Amazon OpenSearch Serverlessなどのベクトルデータベースのプロビジョニングとスケーリングが必要な顧客管理オプションとは異なり、マネージド版はインフラストラクチャのオーバーヘッドを排除します。これは、マルチターンの計画とツール駆動型リトリバルを可能にするAgenticRetrieveStream APIをサポートしています。この機能はManaged Knowledge Basesでのみ利用可能であり、高度なリトリバル戦略の基盤コンポーネントとなっています。また、このシステムはAmazon Bedrock AgentCoreと統合されており、各ナレッジベースをModel Context Protocol(MCP)ツールとして公開することで、エージェントがブレンドされたインデックスを検索するのではなく、意味的にクエリをルーティングできるようにします。
この展開モデルにおける重要な変化は、可観測性と評価をインフラストラクチャコードに直接統合したことです。以前のイテレーションでは、開発者がスタックのデプロイを手動で順序付けし、事後に監視ツールを追加する必要がありました。新しいCDKアプリケーションは、7層のテレメトリにまたがる2つのAmazon CloudWatchダッシュボードと、オンデマンドおよび継続的な評価指標を提供します。これにより、トークン使用量からリトリバル品質まで、エージェントの推論ループのすべてのステップが最初から計装され、システム動作と回答の根拠に対する可視性が提供されます。
仕組み
このソリューションは、エージェントランタイム、エージェントゲートウェイ、マネージドナレッジベース、可観測性ダッシュボードという4つの主要コンポーネントを含む調整されたワークフローを通じて動作します。ユーザーが質問を送信すると、Amazon Bedrock AgentCore Runtime上でホストされているエージェントが推論プロセスを開始します。財務データや気象データなど、関連するナレッジベースを判断し、AgentCore Gatewayを介して対応するツールを呼び出します。GatewayはIAM認可とSigV4署名を使用して、選択されたManaged Knowledge Base上のAgenticRetrieveStream APIを呼び出します。
Managed Knowledge Base内部では、システムがクエリをサブクエリに分解し、内部管理データストアから関連するパッセージを取得し、引用付きの回答を合成します。初期コンテキストが不十分な場合、エージェントは最終的な応答を確定する前に、より多くの情報を取得するためにループバックします。このプロセス全体を通じて、RuntimeはOpenTelemetryスパン、トークン数、メトリクスをAmazon CloudWatchとAWS X-Rayに出力します。このデータは、KBネイティブメトリクス、取り込みステータス、リトリバル品質、評価スコアなど、7つの可観測性レイヤーに反映され、エンジニアはレイテンシ、コールボリューム、生成された回答の忠実性を監視できます。
主要な詳細
- マネージドインフラストラクチャ: このソリューションはType: MANAGED Knowledge Basesを使用しており、OpenSearch Serverlessなどのベクトルデータベースのプロビジョニング、スケーリング、パッチ適用の必要がありません。
- エージェント型リトリバルAPI: AgenticRetrieveStream APIは、マルチターンの計画と内部リランキングを実行し、マネージドベースでのみ利用可能な合成され、引用された回答を返します。
- CDK自動化: システム全体は、依存関係がコンストラクト参照から自動的に導出される4つのスタックを持つ単一のPython CDKアプリケーションとしてデプロイされます。
- 7つの可観測性レイヤー: テレメトリは、KBメトリクス、取り込み、リトリバル品質、Gatewayメトリクス、OTELスパンツリー、トークン使用量、評価スコアをカバーします。
- 評価メトリクス: システムには、オンデマンド評価と継続的評価が含まれており、忠実性と正しさを測定して回答のドリフトを検出します。
- サンプルデータ: デプロイメントには、テスト用の合成財務データと、竜巻に関する実際の米国議会調査局レポートが含まれています。
なぜ重要なのか
ソフトウェアエンジニアとAIアーキテクトにとって、この変化は生のリトリバルパイプラインの構築から、インテリジェントなエージェントのオーケストレーションへの移行を表しています。ベクトルデータベース管理を抽象化することで、チームはインフラストラクチャのメンテナンスではなく、リトリバルのロジックと回答の品質に集中できます。異なるナレッジベース間でクエリをルーティングできる機能により、回答が正しいドメインに基づいていることが保証され、無関係なコンテキストによるハルシネーションのリスクが軽減されます。これは、データサイロが一般的で精度が極めて重要なエンタープライズ環境において特に重要です。
さらに、可観測性への重点は、本番AIシステムの主要な課題であるエージェント動作のブラックボックス性質に対処します。詳細なテレメトリがなければ、エージェントがなぜ失敗したのかを診断したり、その回答がソース資料によって裏付けられていることを検証したりすることは困難です。アプリケーションとともにダッシュボードと評価メトリクスを提供することで、開発者はシステムパフォーマンスと信頼性に関する即時の洞察を得ます。この組み込まれた透明性は、応答が監査可能であり、その起源を追跡できることを保証することにより、責任あるAIの使用をサポートします。
できること
- 提供されたCDKアプリケーションをデプロイし、マネージドナレッジベースと可観測性ダッシュボードを備えた完全なエージェント型リトリバルシステムを提供します。
config.pyファイルを構成してプロジェクト名、リージョン、埋め込みモデルを設定し、1つのアカウント内で複数の独立したデプロイメントを可能にします。- 含まれているドライバーノートブックを使用してトラフィックを駆動し、リアルタイムのメトリクスと評価スコアで7つの可観測性レイヤーを埋めます。
- バンドルされた財務および気象データセットでシステムをテストし、エージェントが異なるドメイン間でクエリをルーティングし、ソースを引用する方法を理解します。
- CloudWatchダッシュボードを監視してレイテンシ、トークン使用量、リトリバル品質を追跡し、本番ワークロードに応じてエージェントパラメータを調整します。
- 忠実性と正しさのスコアを評価し、回答がソース資料に基づいていることを確認し、モデルパフォーマンスのドリフトを検出します。



