ユーザーは、PDF、スライド、チケット、トランスクリプト、ウェブコンテンツにまたがる複数部分、比較、探索的な質問をよく行います。従来の単発検索はこうした質問には対応できず、回答は文脈を欠き、サポートチケットはエスカレーションし、アナリストは検索を繰り返すのに時間を浪費します。Amazon Bedrock マネージド知識ベースのエージェンティック検索は、こうした質問のために設計されています。
具体例でそのギャップを明確にしましょう。25年分のAmazon株主レターをマネージド知識ベースに取り込んだとします。最初の質問は直接的です：「文書の中で最も重要なメッセージは何ですか？」標準のRetrieve APIはハイブリッドスコアで5つのチャンクを返します。テストコーパスでは、トップ結果はスコアが高いものの価値が低く、Amazonロゴの色スキームに関するものでした。後続のチャンクは採用、構築者、差別化をカバーしています。検索器は仕事をし、クエリ埋め込みとの類似度でランク付けしました。しかし「最も重要なメッセージ」は曖昧で、スコアラーには何が重要かを判断する手がかりがありません。
次に現実的な質問に発展させます：「2020年と2023年で、Amazonが採用、長期投資、顧客重視についてどのように語っているかを比較してください。重点はどこに移りましたか？」単発検索は1つのクエリベクトルで3つの意図と2つの期間に対応しなければなりません。結果は、緩く関連したチャンクの散在か、最も強いシグナルに支配された密なクラスターのどちらかになります。どちらも人間のアナリストが行うことではありません。
人間のアナリストは質問を分解します。まず2020年の採用、次に2023年の採用、そして各年の投資哲学を検索します。結果を読み、ギャップに気づき、検索を改善し、再実行します。十分な証拠が集まったら、統合します。エージェンティック検索はこのワークフローをAPIとして自動化します。
単発検索の欠点には、複数部分質問での埋め込みの不十分さ、比較推論での項目ごとの検索の必要性、複数ソース質問での静的なルーティングの脆弱性、十分性の判断欠如、最初の結果に基づく反復の不能が含まれます。チームはRetrieve API上にカスタムエージェントフレームワークを構築してきましたが、アプリケーションごとに独自の配管が必要で、遅延、コスト、信頼性のリスクがあります。
エージェンティック検索は、Amazon Bedrock マネージド知識ベースの新しい検索モードで、AgenticRetrieveStream APIを通じて利用できます。単一の類似性検索ではなく、基盤モデルによる計画ループを実行します。モデルが質問を分解し、各部分を検索し、十分な証拠があるか判断し、必要に応じて反復します。デフォルトで同じ呼び出し内に根拠のある応答を生成します。generateResponse=Falseを設定すると、応答生成を行わずに検索結果のみを返します。
ループの各ステップは、順序付けられたトレースイベントのストリームとして表示されます：SpeculativeRetrieval（初期検索）、Planning（分析、サブクエリ出力）、Retrieval または FullDocumentExpansion（サブクエリ実行ごと）、Result（最終的な重複除外チャンク）。重複除外は最終結果イベントにのみ適用され、トレースイベントは個々のステップを確認するために利用できます。
主な調整パラメータは2つ：maxAgentIteration（計画と検索の反復回数の上限。単一KBでは3、複数KBまたは比較クエリでは4〜5を推奨）と foundationModelType（サービス管理モデルかカスタムモデル）。価格は呼び出しごとで、管理モデルではエージェンティック検索呼び出し1,000回あたり4ドルに加え、基盤となるRetrieve API呼び出し1,000回あたり1ドル。
APIの実践：単一知識ベースの場合、リクエストを送信しストリームを消費します。トレースイベント、生成応答チャンク、最終結果イベントを受け取ります。複数知識ベースの場合、最大5つのマネージドKB検索器を登録し、それぞれに自然言語の説明を付けます。プランナーはその説明を読んでサブクエリを適切なKBにルーティングします。Retrieve APIは短く明確な質問に、AgenticRetrieveStreamは複雑な多部質問に使用します。エージェンティック検索はベンチマークで良好な結果を示しています（詳細は省略）。