AgenticRetrieveStream開始 Amazon Bedrock Managed Knowledge Basesで

従来のRAGは、質問全体を1つのベクトルに埋め込み、類似度検索で上位チャンクを取得する方式が主流だった。しかし「2つのサービスを3つの観点で比較する」ような質問は、実質的に6つの意図を含む。1つのベクトルではその平均を取るしかなく、上位5件では6つの意図のうち2つを取りこぼすことがAWSの検証で示されている。取得件数を10件に増やせば6つすべてをカバーできるが、同じ観点が重複して取得され、無関係なチャンクも混ざるという無駄が生じる。

エージェント検索は、この構造的な限界に対処する。質問をサブクエリに分解し、それぞれを検索し、得られた証拠が十分かを判断し、足りなければ再度検索する。langchain-awsパッケージはこれを関数として公開しており、LangChainのチェーンに組み込むにはRunnableLambdaで包む必要がある。トレースイベントで計画内容を確認するには、boto3で直接APIを呼び出す。

この仕組みは、単発検索より呼び出しあたりのコストが高く、レイテンシも大きい。複数のモデル呼び出しが発生するためだ。したがって、すべてのトラフィックをエージェント検索に流すのではなく、質問の形状に応じて安価な標準検索と使い分けることが現実的とみられる。エージェント検索が真価を発揮するのは、分解すべき要素がある複合的な質問であり、単純な質問ではコスト増に見合わない可能性がある。