AgenticRetrieveStreamで単発RAG、検索のみ、複数検索を使い分けます。同じAPIから要求ごとに処理量を選べる構成です。 単純な照会と横断比較を分けて評価します。応答生成の有無、反復上限、引用と根拠の確認が費用・品質の焦点です。 質問の難しさに合わせて検索量を変える AWSは11月9日、Bedrock Managed Knowledge Baseの検索方式を拡張したと説明しました。既存の複数段階の検索に加え、一度だけ検索して答える方式と、文章を生成せず根拠だけ返す方式を扱います。APIはAgenticRetrieveStreamです。簡単な確認にも複雑な比較にも同じ仕組みを使い、要求ごとに処理を変えられます。原文は銀行の手続きを例に、単一の確認表で済む問いと、複数の規程を比較する問いを区別しています。この例は説明用であり、特定銀行での導入効果を示す実証ではありません。常に多段階の推論を使うのではなく、必要な探索量を選べる点が今回の変更です。費用と待ち時間を調整する入口になります。 反復数と回答生成を組み合わせる 単発RAGは一度検索し、見つかった内容から基盤モデルが回答を生成します。検索のみでは該当箇所を返し、モデルによる回答生成はしません。複雑な問いには計画、検索、情報不足の評価、追加の探索を行います。応答を生成する場合は引用を付け、追跡イベントから過程を調べられます。設定のmaxAgentIterationで反復の上限を指定し、generateResponseで回答の生成を選びます。検索のみの例は反復数0で生成を無効にし、単発RAGは1を使います。一回の反復は基盤モデルの呼び出し一回に対応します。アプリ担当者には、検索結果を別の画面で確認する用途や、生成を別工程へ渡す用途も関係します。単純な照会のために別APIを作る必要を減らせる構成です。 少ない処理で足りる問いを見極める 検索を一度に抑えると待ち時間やモデル利用を減らせる可能性がありますが、複数の文書に情報が分かれる問いでは不足が残る可能性があります。実務では短い質問かどうかではなく、答えの根拠がどこにあるかで方式を評価することが論点です。生成を止めれば誤った文章の追加を避けられる一方、利用者が原文を読む工程は残ります。複数検索でも、十分な根拠が取れたかは確認が必要です。評価用の問いに単純照会、比較、情報不足を含め、方式ごとの費用、時間、根拠の充足を記録することが判断材料になると見られます。反復の上限が到達したときの表示や、回答できない場合の扱いも運用へ含めます。検索回数を増やせば常に正しくなると考えず、引用元と結論の関係を確認する設計が重要です。方式を切り替えた履歴も残せると、速さと根拠の不足がどこで入れ替わったかを調べやすくなる可能性があります。