こんにちは、クラウド活用推進担当の新倉です。
先日、Amazon BedrockのMulti Agentで「チェックリストの確認自動化」のための検証を行っていたところ、約100USDの予期しないコストが発生していたという問題が発生しました。
いろいろと調べているうちに原因がわかったので共有します。
以下が今回作成したAgentの構成図になります。
チェック項目を取得するAgentと、取得したチェック項目に準拠しているか確認するAgentの2つのAgentとそれを統括するSuperVisor Agentの3つのAgentによるMulti Agent構成を作成しました。
チェック項目は全部で100個以上あり、このAgentは一回の処理で最大6項目のチェックを行うことができるようになっています。
6項目以上のチェックができない理由はAmazon Bedrockの仕様です。(*後ほど説明しますが、この制限がなかったら100USDじゃすまなかったと思います..)
6項目のチェックを依頼するごとに、毎回120万tokenが消費されていました。
具体的には
1項目目は100,000token
2項目目は130,000token
3項目目は200,000token
といったように一回の依頼で処理する項目が後半になればなるほど消費token数も上昇していってしまいました。
当初の想定では26万token程度の消費を想定していたため、想定の約5倍ほどのtoken数が消費されていたことになります。
Amazon Bedrock Agentでは一回の依頼を「トレース」というステップに分けて処理を行います。
今回の例で考えると、「項目番号1のチェックをお願いします。」と依頼すると
のように一回の依頼を、複数のトレースというタスクに分解して処理をしています。
この時、トレース1でinputした内容をトレース2に引き継ぎます。
トレース2以降でも、それ以前のトレースで利用されたinput tokenが累積されていきます。
例えば、
トレース1~4でそれぞれ100tokenの新たなinputがあった場合
のような形でinput tokenが累積されます。
今回6項目をチェックするために約40トレースステップがかかっていました。
この仕様の影響で項目番号が後半になればなるほど消費するInput tokenは増加していき
結果として想定以上のtokenが消費され、コストが増加してしまいました。
AWSのサポートに問い合わせたところ、
「マルチエージェントの各ステップでは前段のステップでの内容を引き継ぐことで高度なタスク処理を実現しております。そのため、ステップ数を重ねるごとに、それまでの入力内容が累積的に保持される仕様となっております。」
とのことでした。
つまり、Multi Agentに依頼する際、できるだけユーザー側でタスクを細分化した後にAgentに依頼を行うことでtokenのスパイクを防ぐことができるということです。
今回の事例では一回で6項目のチェックを依頼するのではなく、1項目ずつ依頼を行うことで防ぐことが可能になります。
Amazon Bedrock Multi Agentを使用したチェックリスト自動化において、想定外の高額な料金が発生した事例とその対策について解説しました。
これからBedrock Agentを触ってみようと考えている方の参考になれば幸いです。
