Bedrock Knowledge Basesが複数段階のエージェント検索に対応

Amazon Bedrock Managed Knowledge Basesに、質問を分解して反復検索するAgenticRetrieveStream APIが加わりました。

要点

• 複数条件の比較や探索的な質問を小さな検索へ分け、十分な根拠が集まるまで反復します。
• 最大5つのKnowledge Baseを説明文に基づいて使い分け、処理経路を逐次返します。
• 単純検索より費用と遅延が増えるため、質問の複雑さで使い分けます。

今回のブログ記事で語られていること

通常のRetrieve APIは一つの質問を一つのベクトルにし、近い断片を返します。「2020年と2023年の方針を三つの観点で比較する」といった質問では、複数の意図が平均化され、特定の観点や年代へ結果が偏ります。エージェント検索は質問を分解し、各観点を検索し、証拠が十分かを判断して不足分を再検索します。

AgenticRetrieveStreamは、先行検索、計画、検索または文書全体の展開、最終結果を順序付きの事象として返します。最終結果では重複断片を除き、既定では根拠付き回答も生成します。回答生成を無効にして断片だけを受け取り、自社のモデルと規則で文章化することもできます。単一Knowledge Baseでは反復上限3、複数では4〜5を出発点にする案が示されています。

最大5つのKnowledge Baseを一回の要求へ登録し、それぞれの説明文を使って検索先を振り分けます。MuSiQueの複数段階質問では、単発検索より再現率が20ポイント向上し、単段階質問の差は5ポイント未満でした。管理モデル利用時の例では1,000回のエージェント検索が4ドル、基礎となるRetrieve呼び出し1,000回が1ドルで、反復数が費用と遅延を左右します。

権限には検索、文書取得、モデル呼び出しが必要です。保護規則は遮断動作のみ対応し、置換動作は使えないという制約もあります。中間の検索語に機密情報が含まれる可能性があるため、最終回答だけでなく全経路をCloudWatchへ記録し、保持と閲覧を管理する必要があります。

検索先の説明文が曖昧だと、正しいKnowledge Baseが選ばれず、反復回数だけが増えます。各説明を短く具体的にし、誤った振り分けを含む試験を用意します。直接検索と同じ質問を並行実行し、再現率の改善が追加費用と待ち時間に見合う領域だけへ適用するのが現実的です。

今回のブログ記事が関係する人

企業検索やRAGを構築する開発者、複数Knowledge Baseを運用する基盤担当、費用と根拠を監督するチームに関係します。

結局、今回のブログ記事をどう読むべきか

複雑な質問の検索計画を管理サービスへ移す機能です。直接的な質問は従来検索のままにし、比較・探索・複数資料横断へ限定して費用、遅延、根拠の改善を測るのが適切です。