AWS、Bedrockナレッジベースのエージェント型検索をLangChainから利用可能に

何が公開されたのか

AWSの機械学習ブログで、Amazon Bedrock Managed Knowledge BaseとLangChainを組み合わせたRAGアプリの解説が公開された。同じ複数パートの質問を標準の検索とエージェント型検索の両方に通し、トレースイベントからモデルが生成した計画を読み取る内容になっている。両方式のコストと、安い方を選ぶべき場面にも触れている。

エージェント型検索はAmazon Bedrock Managed Knowledge Base上で利用できる。1回の検索ではなく、質問をサブクエリに分解して実行し、十分な根拠があるかを判断し、足りなければ再検索する仕組みだ。langchain-awsパッケージが標準とエージェント型の両方を公開しているため、LangChainアプリからどちらも呼び出せる。

2つの検索APIの違い

Bedrock Managed Knowledge Basesは2つのAPIを提供する。Retrieve APIは1回のハイブリッド検索を実行してスコア付きのチャンクを返す。AgenticRetrieveStream APIは計画ループを実行し、各ステップをトレースイベントとしてストリームで返す。langchain-awsでは、前者がチェーンに組み込める標準のリトリーバー、後者がナレッジベースから直接呼び出す関数として提供される。

エージェント型が関数になっているのは、基盤のAPIが結果をストリームで返し、同期型のBaseRetrieverインターフェースに収まらないためだ。AmazonKnowledgeBasesRetrieverに切り替えフラグがあるわけではない点は注意したい。

設定ではmanagedSearchConfigurationを使う点も押さえておきたい。vectorSearchConfigurationは自前のベクターストアを使う従来の経路で、既存のサンプルの多くはこちらを示している。

単発検索の限界

原文では、チェックアウトと在庫の2サービスを、オンコールのエスカレーション・バックアップと復元の目標・デプロイのロールバック手順という3つの観点で比較する質問が例に使われている。これは実質6つの意図を含む質問になる。

単発検索では、1つのクエリベクトルが6つの意図すべてをまとめて表そうとする。原文によれば、5件の結果では2つの意図を取りこぼす。10件に増やすと6つすべてをカバーできるが、2つのサブ意図が二重にカバーされ、1つのチャンクはどれも担っていないという無駄が見えるという。

リトリーバーの動作自体は正しく、制約は構造的なものだと筆者は説明する。1つのベクトルは6つの意図を表現できず、返された根拠が十分かを問うステップが存在しない、という指摘である。

導入時の注意点

エージェント型検索を使うにはboto3のバージョンが重要で、agentic_retrieve_streamは1.43.32より前には存在しなかったとされている。原文の検証はPython 3.12以降を前提としている。

権限設計では差が出る。bedrock:AgenticRetrieveStreamとbedrock:InvokeModelWithResponseStreamはナレッジベースのARNに絞れないが、bedrock:Retrieveとbedrock:GetDocumentContentは絞れる。またbedrock:GetDocumentContentは見落とされやすく、FullDocumentExpansionステップが文書全体を必要としたときに呼ばれるため、Retrieveだけのポリシーではクエリの途中で失敗しうる。

検証は米国東部(バージニア北部、us-east-1)で行われており、他リージョンでの可用性はAWSドキュメントの確認が必要とされている。実行にはドキュメントの保存と取り込み、検索呼び出し、基盤モデルの推論のコストがかかりうるとして、料金ページを参照するよう案内している。