AWS、BedrockにシングルショットRAGと検索のみのモードを追加

Amazon Web Servicesは発表しました。2026年11月9日、Amazon Bedrock Managed Knowledge Baseが、シングルショットの検索拡張生成（RAG）とパッセージのみを返すリクエストを新たにサポートし、…を通じて AgenticRetrieveStream。…の設定範囲が0～5に拡張され、 maxAgentIteration これにより、アプリケーションはソースの検索、検索1回での回答生成、または従来の複数ステップによるエージェント型検索を選択できます。

今回のアップデートにより、検索を1回行ってから回答を生成する基本的なRAGのパターンを、複雑な検索に使われているものと同じストリーミングAPIで利用できるようになります。シングルショットRAGでは、生成に基盤モデルを1回呼び出しますが、検索のみのリクエストではモデルを呼び出しません。AWSによると、シングルショット方式ではエージェント型検索に比べてレイテンシーとモデル使用量を削減できます。ただし、発表にはレイテンシーやコストの測定比較は示されていません。

1つのパラメーターで検索モードを選択

値が0の場合、回答を生成せず、一致するパッセージを返します。1の場合は検索を1回行い、…を用いて回答を生成します generateResponse=true。また、2～5では従来のエージェント型の動作が維持されます。どのモードでも複数のナレッジベースに対応します。したがって、シングルショットとは検索が1回という意味であり、ナレッジベースを1つに限定するものではありません。

1イテレーションは、基盤モデルの呼び出し1回を表します。回答生成を有効にしている場合、上限を…にすると、最後の呼び出しが回答生成に割り当てられ、最大…回の n は最後の呼び出しを回答生成に割り当て、最大…回の n から1を引いた回数の計画ラウンドが可能になります。各計画ラウンドでは、クエリの書き換えと検索をそれぞれ1回行います。初回の投機的検索は計画の前に実行され、上限には含まれません。

値が0の場合、回答生成をオフにする必要があります。有効にすると、回答の生成にはモデル呼び出しが必要なため、4xxエラーが発生します。値が1の場合、ストリームには検索結果と、根拠に基づく回答がそれぞれ1つ含まれ、計画のトレースイベントは含まれません。2～5を使う既存のリクエストに変更はありません。

ストリーミングの動作と運用上の制限

AgenticRetrieveStream APIのリファレンスには、…が messages, retrievers、また…が agenticRetrieveConfiguration 必須のリクエスト入力として示されている一方、…は generateResponse 任意です。回答生成が有効な場合に限り、生成された回答のチャンクが出力されます。最終結果には、検索された項目、統合された回答、および回答の各部分と根拠となる検索結果を結び付ける引用情報が含まれることがあります。

検索のみの処理は、…を直接呼び出すのと同等ですが、 Retrieve 直接呼び出す場合とは応答形式が異なります。パッセージはストリームの…に現れ、 result イベントには…が含まれず、 score または…のフィールドもありません。 location すでに…を使用しているアプリケーションは、 AgenticRetrieveStream そのため、…を利用できます。 Retrieve別のAPIを統合する代わりにパラメーターを変更するだけで、…方式の動作を実現できます。

複雑な質問について、Amazon Bedrockユーザーガイドでは、クエリをサブクエリに分解し、取得した根拠が十分かどうかを確認し、追加検索を行い、必要に応じて対象を文書全体に広げるワークフローが説明されています。エージェント型検索が対応するのは、Bedrockのフルマネージド型ナレッジベースのみで、1リクエストにつき最大5つの検索対象を指定できます。イテレーションの上限を下げると、エージェントがより早く処理を終了し、複雑な質問への回答精度が低下する可能性があります。

アプリケーションチームがモードを選択してテスト

AWSが設定例として示しているのは、架空の銀行の社内ポリシーアシスタントであり、顧客環境への導入事例ではありません。個人事業主に関する文書の質問には…を使い、 maxAgentIteration=1、一方、個人事業主とLLCの要件を比較し、非居住者の所有者に関する規則も確認する場合には4を使います。これにより、最大3回の計画ラウンドが可能になります。ポリシーの文言を確認するリクエストには0を使い、要約を行わずにソースのパッセージを返します。

アプリケーション側でモードを選択する必要があり、 maxAgentIteration リクエストを自動的に振り分けることはありません。このアシスタントの例では、ポリシーの検索と比較を行いますが、口座の承認や銀行による審査・承認に代わるものではありません。

導入にあたってAWSは、同じナレッジベースを使い、代表的な質問と想定される回答を用いて、シングルショットのRAGと既存のエージェント型設定を比較することを推奨しています。評価では、レイテンシーとリクエストコストを測定し、回答の正しさと検索されたパッセージによる裏付けを確認するとともに、複数文書にまたがる質問や回答不能な質問も含める必要があります。その結果をもとに、各ワークフローの品質要件を満たす最小のイテレーション上限を選べます。

今回の変更により、検索の深さがリクエストごとに明示的に決めるインフラ上の選択肢になります。直接的な検索では計画のための呼び出しを省ける一方、複雑なクエリでは根拠を段階的に集められます。企業にとって重要なのは、モデル使用量を減らしても、自社文書に基づく網羅的で裏付けのある回答を維持できるかどうかです。イテレーションの上限を高くすれば常に良い結果が得られると決めつけるべきではありません。