AWSはManaged Knowledge Base、AgentCore、CloudWatchを組み合わせる構成を示しました。2つの知識基盤を選び、再検索して引用付きの回答を生成します。 検索品質と複数回の推論費用を同時に見る構成です。サンプルの地域条件、評価の実行率、実データでの権限を確認することが焦点になります。 一度の検索から必要に応じた再検索へ AWSは10月26日、Managed Amazon Bedrock Knowledge Baseを使う検索エージェントをCDKで構築する手順を公開しました。質問から一度だけ文書を取り出す従来のRAGに対し、エージェントが知識基盤を選び、情報が足りなければ再検索します。記事はAgenticRetrieveStreamによる引用付き回答を、AgentCore Gatewayのツールとして呼び出す構成を説明しています。取り込み、保存、索引は管理サービスが担当し、利用者がベクトルデータベースを別途構築する部分を減らします。今回は新たな一般提供の告知ではなく、検索、実行、監視を結ぶ技術解説です。 検索先の選択と回答品質を別々に観測 サンプルは財務と気象の2つの知識基盤を別のツールとして公開します。財務側の文書は架空企業の合成データで、実在企業の情報ではありません。エージェントがどちらを選び、何度検索したかを追うことで、異なる分野の品質が平均値に埋もれるのを避ける狙いです。CloudWatchの2つのダッシュボードには、取り込み、検索品質、Gateway、実行履歴、トークン、評価など7層の情報を集めます。都度の評価と継続的な評価も含みます。社内検索を開発する担当者には、引用が出たかだけでなく、適切な資料を選んだかを調べる観点が参考になります。回答に至る経路が質問ごとに違うため、画面上の最終回答だけでは不具合を切り分けにくいと見られます。 四つのスタックと継続評価の負担を見積もる 構成は知識基盤、Gateway、エージェント実行、ダッシュボードの4スタックで、参照関係からCDKが展開順を決めます。利用地域には制約があるため、関連する全サービスが対象地域で使えるかを確認する必要があります。実務では管理基盤へ任せる範囲が増えても、文書の公開範囲や検索結果の妥当性を利用側で決める作業は残ると見られます。複数回の推論、検索、ログの保存、評価も総費用に含まれます。サンプルの評価設定を本番へ写す前に、必要な標本数と継続費用を比較することが論点です。導入の判断では単一検索で足りる質問も含め、追加の検索で品質が上がるかを測る必要があります。合成データでの動作確認と、自社の資料での品質や権限の確認を段階的につなぐことが重要です。 引用の存在だけで回答の正しさを決めない 検索で得た文章に出典があっても、質問へ十分に答えているとは限りません。正しい知識基盤を選べたか、取得した情報を適切に使ったかを、それぞれ評価する必要があると見られます。検索を繰り返すほど良いと決めず、必要な情報が揃った段階で止まれるかも確認点です。継続的な評価の結果を、文書の更新や検索構成の変更へつなげる担当を決めることが運用上の論点になります。監視を追加しただけで完了とせず、結果から修正する手順を持つことが重要です。