Amazon Bedrock、エージェント型検索機能を追加

ユーザーは、PDF、スライド、チケット、通訳記録、ウェブコンテンツなど複数のソースにまたがる多段階の質問や比較・探索的な問いを投げかけることがよくあります。従来の単発検索（single-shot retrieval）ではこうした質問に対応できず、回答に必要な文脈が欠落したり、サポートチケットのエスカレーションが増えたり、アナリストが何時間も再検索に費やすといった問題が発生します。

「Amazon Bedrock Managed Knowledge Bases」向けのエージェント型検索（Agentic retrieval）は、まさにこれらの複雑な質問のために設計された機能です。

例えば、アナリストが以下のような2つの質問を投げたとしましょう。「2020年と2023年の戦略を比較し、何が変化したのか？」や「製品ライン全体で最も大きなリスクは何か3つあるか？」。これらは単一の検索では対応できません。多目的な問いには、埋め込み空間内でそれを適切に表す単一のポイントが存在しないため、上位 k 個のチャンク（top-k chunks）が競合する複数の意図を平均化したものとして返されてしまいます。

エージェント型検索は、検索計画を立てて反復処理を行いながら、同じ呼び出しの中で回答を生成することが可能です。本稿では、なぜ従来の検索手法が多段階質問に不十分なのか、また AgenticRetrieveStream API の仕組み（リクエストの構築方法やトレースの解析など）について解説し、標準的な Retrieve API と比較していつエージェント型検索を選ぶべきかを説明します。

単発検索が抱える課題

具体的な事例を通じて、そのギャップを明確にしましょう。Amazon の株主書簡を25年分すべて取り込んだ Managed Knowledge Base を想定してください。最初の質問は直接的です。

*「文書の中で最も重要なメッセージは何ですか？」*

標準的な Retrieve API は、ハイブリッドスコアに基づいて 5 つのチャンクを返します。テスト用コーパスでは、上位の結果はスコアが高いものの価値が低く、Amazon のロゴカラーリングに関する内容でした。続くチャンクには採用、ビルダー、差別化についての内容が含まれていますが、検索エンジン自体はクエリ埋め込みとの類似度に基づいて正しくランク付けしています。

しかし、「最も重要なメッセージ」は曖昧であり、スコアリング機能には「何が重要か」を判断する手がかりがありません。

では、より現実的な問いに挑戦してみましょう。

*"2020 年と 2023 年の Amazon の採用、長期投資、顧客至上主義に関する言及を比較し、重点のシフトはどこにあったのか？"*

この場合、単一の検索クエリで 2 つの時期にまたがる 3 つの意図に応える必要があります。結果として得られるのは、関連性の薄いチャンクの散らばりか、最も強い信号によって支配された緊密なクラスタかのどちらかです。どちらも、人間のアナリストが行うような分析ではありません。

人間のアナリストならどうするか

人間は質問を分解します。まず 2020 年の採用について検索し、次に 2023 年の採用を検索し、さらに各年の投資哲学についても調べます。結果を読み込み、不足している部分に気づいて検索を改良し、再度実行します。十分な証拠を手に入れた段階で、それらを統合して結論を導き出します。

アジェンティック・リトリーバル（Agentic retrieval）は、このワークフローを API として自動化するものです。

単一ショット検索が残す課題

• 多部構成の質問: 1 つの埋め込みベクトルでは、複数の意図を持つクエリを十分に表現できないため、上位 k 件の結果が意図同士を混同してしまいます。

比較推論では、「A と B を次元 X について比較せよ」といった指示に対し、アイテムごとに個別に検索を行う必要があります。一度に統合された検索を行っても不十分です。

複数ソースからの質問に対しても、証拠が複数のナレッジベースにまたがる場合、静的なルーティングルールは脆く、クエリごとに柔軟に適応できないことがあります。

情報の充足性についても、従来の検索手法では「十分な情報か」を判断できません。常に k 個のチャンクを返すだけです。

探索的な質問には、最初の結果に基づいて追加検索を行う必要がありますが、単発の検索では反復処理が不可能です。

これらの課題に対し、各チームは Retrieve API を基盤としたカスタムエージェントフレームワークで対応してきました。モデルに計画とループ内の Retrieve API 呼び出しを指示し、サブクエリの管理、重複排除、停止判断を行わせる手法です。機能はしますが、その結果、すべてのアプリケーションで独自の実装が必要となり、それぞれが独自のレイテンシ、コスト、信頼性のリスクを抱えることになります。

エージェント型検索とは

エージェント型検索は、Amazon Bedrock Managed Knowledge Bases で利用可能な新しい検索モードです。AgenticRetrieveStream API を通じて提供されます。従来の類似度検索の代わりに、ファウンデーションモデルが駆動する計画ループを実行します。モデルは質問を分解し、各部分に対して検索を行い、十分な証拠があるかを判断し、必要に応じて反復処理を行います。デフォルトでは、この一連のプロセスを通じて根拠のある回答を生成します。generateResponse=False を設定すると、回答の生成を行わずに検索結果のみを返すことも可能です。

このループの各ステップは、順序立てられたトレースイベントのストリームとして確認できます。各イベントには「ステップ」と「ステータス」が含まれているため、プランナーが何を行い、なぜその判断を下したのかを把握できます。

• SpeculativeRetrieval: 最初の計画ステップを実行する前に実行される初期検索で、エンドツーエンドのレイテンシを削減します。単一の KB の場合は生のユーザークエリを使用し、複数の KB の場合はサブクエリのルーティングに用いるプローブ検索です。この操作は maxAgentIteration のカウントには含まれません。

• Planning: 基盤モデル（FM）がクエリを分析し、過去の結果を確認して、検索可能な意図に沿ったサブクエリを生成します。各反復の間では、モデルが情報の十分性を判断し、停止するか再度検索を行うかを決定する箇所でもあります。

• Retrieval or FullDocumentExpansion: サブクエリの実行ごとに 1 つのイベントが発生し、それぞれに固有のステータスが設定されます。アジェンティック・リトリーバルでは、エージェントが現在の文脈情報だけでは回答できないと判断した場合、このアクション（イベント）によって完全なドキュメントを取得します。要約や要素の列挙、あるいはドキュメント内の複数の箇所からの情報を必要とするクエリは、このアクションを活用することで効果的です。より多くの証拠が必要となる場合、ループは maxAgentIteration で定められた上限まで数回反復されることがあります。

結果：最終イベントです。ここでは、反復処理を通じて収集された重複を除いたソースチャンクが含まれます。複数の KB へのリクエストの場合、各チャンクには sourceRetriever が明記されます。デフォルトで応答生成が有効になっているため、generateResponse=False を設定しない限り、結果イベントには根拠のある回答と引用も含まれます。

重複排除とトレースに関する補足：重複排除は最終結果イベントに対してのみ適用されます。複数のサブクエリが同じチャンクを取得した場合でも、そのチャンクは最終結果には一度だけ表示されます。一方、個別の計画や検索ステップを確認するためのトレースイベントは引き続き利用可能です。

チューニングに寄与するパラメータは主に2つあります。1つ目は maxAgentIteration で、プランニングと検索の反復回数の上限を定義します。単一の知識ベース（KB）を利用する場合は 3 を、複数の KB を対象とする場合や比較照会を行う場合は 4〜5 を設定するのが一般的です。ただし、評価ステップで十分な証拠が確認された場合、プランナーは早期に終了することもあります。

デフォルト値と上限については、クォータと制限 をご確認ください。

2 つ目はファウンデーションモデルの設定です。foundationModelType フィールドは、エージェント型検索でサービス管理型のモデルを使用するか、カスタムモデルを使用するかを決定します。これを CUSTOM に設定する場合は、foundationModelConfiguration を通じてモデルを提供する必要があります。

料金に関する注意: Agentic retrieval は呼び出し単位で課金され、オーケストレーションに使用するモデルによって料率が異なります。マネージドモデルを選択した場合、1,000 回の Agentic retrieval 呼び出しあたり 4 ドルに加え、基盤となる Retrieve API の呼び出しが 1,000 回あたり 1 ドルかかります。Amazon Bedrock で利用可能なモデルを選ぶ場合は、そのモデルの標準的な転送価格（pass-through pricing）に、同じく 1,000 回あたり 1 ドルの基盤となる Retrieve API 料金が加算されます。詳細は 料金ページ をご覧ください。

API のウォークスルー

プランニングループの仕組みを確認したところで、次は AgenticRetrieveStream API の実際の使い方を解説します。

単一のナレッジベース

最もシンプルなケースです。ナレッジベース（KB）が 1 つでクエリも 1 つの場合、プランナーに分解処理を任せるだけで済みます。リクエストを送信し、ストリームを読み取ることで、トレースイベントや（レスポンス生成が有効な場合の）生成された応答チャンク、そして最終的な結果イベントを受け取ることができます。

import boto3
bedrock_agent_runtime = boto3.client(
    "bedrock-agent-runtime",
    region_name=REGION,
)
MODEL_ARN = (
    "arn:aws:bedrock:us-west-2:"
    ":inference-profile/"
)
response = bedrock_agent_runtime.agentic_retrieve_stream(
    messages=[{"role": "user", "content": {"text": QUERY}}],
    retrievers=[
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_ID,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            }
        }
    ],
    agenticRetrieveConfiguration={
        "foundationModelType": "CUSTOM",
        "foundationModelConfiguration": {
            "type": "BEDROCK_FOUNDATION_MODEL",
            "bedrockFoundationModelConfiguration": {
                "modelConfiguration": {
                    "modelArn": MODEL_ARN,
                }
            },
        },
        "maxAgentIteration": 3,
    },
)

# Consume trace events, generated-response chunks, and the final result
for event in response["stream"]:
    if "traceEvent" in event:
        attrs = event["traceEvent"]["attributes"]
        print(f"[TRACE] step={attrs.get('step')} status={attrs.get('status')}")

        if attrs.get("step") == "Retrieval":
            for chunk in attrs.get("retrievalResponse", []):
                preview = chunk.get("content", {}).get("text", "")[:60]
                print(f"    {preview}")

    elif "responseEvent" in event:
        print(event["responseEvent"]["text"], end="", flush=True)

    elif "result" in event:
        print()

        for chunk in event["result"].get("results", []):
            source_retriever = chunk.get(
                "sourceRetriever", {}
            ).get("identifier", "")
            preview = chunk.get("content", {}).get("text", "")[:80]
            print(f"[RESULT] {source_retriever} | {preview}")

これが全体の流れです。1 回のリクエストでオーケストレーションコードは不要で、上から順にストリームを読み取るだけです。トレースイベントからはプランナーが何を行ったかがわかり、結果イベントには重複を除去したチャンクが含まれます。本番環境では、これらのトレースイベントを Amazon CloudWatch にログ出力し、コストの帰属管理、レイテンシ予算の策定、デバッグに活用してください。各イテレーションは 1 回のプランナー呼び出しとそのサブクエリによる検索処理を含むため、コストと実測時間（wall-clock latency）を決めるのはこのイテレーション回数です。

複数のナレッジベース

マルチ KB ルーティングは、他の API では実現できないアジェンティック・リトリバルの機能です。1 つのリクエストで最大 5 つの Managed KB リトリーバーを登録し、それぞれに自然言語による説明を付与します。プランナーがこれらの説明を読み取り、各サブクエリを最も関連性の高い KB にルーティングします。

response = bedrock_agent_runtime.agentic_retrieve_stream(
    messages=[{"role": "user", "content": {"text": QUERY}}],
    retrievers=[
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_PRODUCT_DOCS,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            },
            "description": "Public product documentation and API reference.",
        },
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_SUPPORT_TICKETS,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            },
            "description": "Resolved customer support tickets and runbooks.",
        },
    ],
    agenticRetrieveConfiguration={
        "foundationModelType": "CUSTOM",
        "foundationModelConfiguration": {
            "type": "BEDROCK_FOUNDATION_MODEL",
            "bedrockFoundationModelConfiguration": {
                "modelConfiguration": {
                    "modelArn": MODEL_ARN,
                }
            },
        },
        "maxAgentIteration": 5,
    },
)

ストリームの消費方法は従来通りです。ルーティングの判断結果はレスポンスに含まれ、各チャンクには sourceRetriever ID が付与されるため、どの KB がどのサブクエリを担当したかを追跡できます。説明はプランナーがルーティングを行うための契約書のようなものなので、各 KB に対して 1 文で簡潔にアピールする形で作成してください。曖昧な説明では、ルーティングも曖昧なものになってしまいます。

適切なリトリバル API の選択

Managed Knowledge Bases では、2 つのクエリ表面（Retrieve と AgenticRetrieveStream）が提供されています。質問の性質に応じて使い分けます。

Retrieve は、短く範囲が明確な質問や、単一の類似度検索で十分対応できる場合に使用します。プランナーを備えておらず、1 回あたりのコストが最も低く、レイテンシも最短です。回答生成の方法については、完全に制御できます。

一方、AgenticRetrieveStream は、多段階の質問や比較・探索的な質問、あるいは複数の KB にまたがる質問に対応する場合に適しています。この API は質問を分解し、意図ごとに検索を実行し、情報の充足度を評価します。そして、単一のリクエストで根拠のある回答を生成するか、またはチャンクを返してユーザーが制御するモデルで合成させることも可能です。複数のモデル呼び出しを行うためコストと時間がかかりますが、単一の検索では見逃す可能性のある証拠を発見できるという利点があります。

エージェント型検索のベンチマーク評価結果

エージェント型検索の性能を、多段階質問を対象とした公開ベンチマーク「MuSiQue (Trivedi et al., 2022)」で評価しました。その結果、単発検索と比較して絶対値で 20% の想起率向上が確認され、特に最も難易度の高い問題において大きな改善が見られました。一方、単一ステップの質問では、5 ポイント未満という小さな改善にとどまりました。

MuSiQue の各問題は、2〜4 ステージの検索ステップを必要とするように設計されており、人間のアノテーターが回答に必要な正確な文書チェーンを特定しています。このチェーンは「オラクル分解」と呼ばれ、評価基準となる理想的な検索プランです。

2 つの傾向が際立っています。まず、質問が難解になるほど、その効果は大きくなります。回答に必要なステップが多いほど、単一の検索では見落としが生じますが、エージェント型検索（Agentic Retrieval）はその欠陥を補完します。複数の手順を要する質問は、一度の通しで答えることはできません。

2 つ目は、システムが実際に必要なステップ数とほぼ同じだけ動作することです。ベンチマークでは、各質問に対する理想のステップ数（人間のエキスパートが追跡した連鎖）が示されています。エージェント型検索が自ら行うステップ数は、この理想値からおよそ 1 つの範囲内に収まるため、質問に答えるのに十分な検索を行いながら、無駄な探索には陥りません。

例

ここでは、MuSiQue データセット内の 4 ホップ（4 段階）クエリをエージェント型検索がどのように解決するかを示します。

クエリ：*"探検家が、Brown のレコードレーベルに所属するグループ Study の本部所在地に到達したのはいつか？"*

エージェント型検索の追跡ログ：

以下の t-SNE プロットは、コーパス表現空間における検索プロセスを視覚化したものです。この図では、単一ステップの Retrieve 結果（点線の赤い境界で示される）と、回答ドキュメントに到達する多段階のアジェンティック・リトリバルの比較が示されています。各ホップにおいて、アジェンティック・リトリバルはクエリを分解し、最終的に回答を含むドキュメントへとたどり着きます。

ベストプラクティス

これらの実践は、コスト削減、レイテンシの改善、そして本番環境におけるアジェンティック・リトリバルの予測可能性向上に寄与します。

• 小規模で高速なプランナーモデルから開始する。アジェンティック・リトリバルでは多数の短い呼び出しが行われるため、大規模なプランナーがレイテンシに見合うメリットを持つことは稀です。
• maxAgentIteration はスコープに応じて設定する。単一 KB の場合は 3、複数 KB の場合は 4〜5 を使用し、測定後に調整を行う。
• リトライバーの説明は製品マーケティングのように記述する。具体的で、明確かつ特徴的な内容にする。
• 各リクエストに相関 ID を付与してトレースを Amazon CloudWatch Logs にストリーミングする。これにより、再生やデバッグが可能になる。
• コストはトークン数だけでなく、イテレーション数で計画する。コストと実時間のレイテンシの両方に影響を与えるのはイテレーション数です。

Combine with