Bedrock agensをAWS ChatbotでSlackにつなげてみる
kun432
本日以前は、お客様は Bedrock エージェントを Microsoft Teams および Slack と統合するために、独自の臨時的な方法を実装する必要がありました。 カスタムチャットアプリケーションを開発し、それを Bedrock エージェントと統合する必要がありました。今回の発表により、BedrockエージェントのエイリアスをAWSチャットボットのチャネル構成に接続することで、チャットチャネルからBedrockエージェントを呼び出すことができるようになりました。接続が完了すると、チャネルのメンバーは「@aws ask connectorname ...」のようにエージェントをタグ付けすることで、エージェントの使用を開始できます。
kun432すでに試された方の記事を見ればできるはずなので、自分のはあくまでもメモ。
AWS公式のドキュメントはこちら
kun432ちょっと下調べ。全部デフォルトで作成させた場合のIAMポリシーやIAMロールの中身を確認しておく。
Bedrock agents
IAMポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AmazonBedrockAgentBedrockFoundationModelPolicyProd",
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": [
"arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-haiku-20240307-v1:0"
]
}
]
}
上記ポリシーがアタッチされたIAMロール
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AmazonBedrockAgentBedrockFoundationModelPolicyProd",
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:bedrock:ap-northeast-1:123456789012:agent/*"
}
}
}
]
}
AWS Chatbot
デフォルトだと
- ポリシーテンプレートに「通知のアクセス許可（
AWS-Chatbot-NotificationsOnly-Policy-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX）」「Resource Explorerのアクセス許可（AWSResourceExplorerReadOnlyAccess）」が追加 - チャネルガードレールポリシーに
ReadOnlyAccessが追加
になるが、Bedrock agentsにだけアクセス限定させるには全部不要で、公式ドキュメントにあるようなIAMポリシー＆ロールを用意する方が良い。
kun432ドキュメントや日本語で紹介していただいている方の記事を読めば簡単にできると思うので、実際にやってみて気づいたことなどを記載。
kun432slackで呼び出す場合はこんな感じで呼び出す必要がある。
@aws ask test-agent - 今日の天気は？
するとスレッドが作成されて、回答はスレッド内で行われるのだが、
そう、自分もこれを思った。エイリアスでなんとかできないものかとか。で、レスがついていた。
つまり、スレッド内では以下だけで良いということになる。
@aws 明日の天気を教えて
タイプ数が減るのはだいぶありがたい。後エージェント名はSlack上の名前として自由につけれるので、なるべく短いものにしておくと良さそう。
ただし、スレッド内でもメンションは常に必要になる。
kun432あと、LLMとSlackインテグレーションしてるものを見ていると、Webのようなストリーミング出力を実現している例はとても少ないのだが（Slack API的に面倒なのかもね）、入力中であることを示す表示にしていたりするものはある。例えば
Typing....
とか
入力中...
とか。
今回のAWS Slackアプリによるインテグレーションではそういった出力が一切なく、結果が出力されるまではだんまりである。レスポンスに時間がかかるようなケースだとたまに「止まってるんじゃないか？」とか思うことがある。
チャットに特化した専用のSlackアプリというわけではないので、そのあたりはしょうがない面もあるのかもしれない。
kun432あと、これはChatbot＆Slackに関係ないのだが、AgentにKnowledge baseを与えてRAGエージェント的に試してみたのだが、どうも検索結果が少ないように思える。ざっと見た感じ、5件未満のデータしかKnowledge baseから引っ張ってこれていなかった。
ここの検索結果の件数を指定したいなぁと思って調べてみたのが、
エージェントに対してInvokeAgentで指定することはできるのだが、今回の例だと
Slack -> Chatbot -> Agent -> Knowledge base
とノーコードで実現できてしまうため、InvokeAgentを自分で叩く余地がないんだよね。。。。
やるとするならば、LambdaからKnowledge baseを検索できるようにして、アクションタイプでAgentに与える、とかになるのかなー、とか思っているけど、せっかくノーコード・ポチポチでできるのにLambda書いちゃうとお手軽感が減ってしまう。この流れでやるならばコンソールで設定したいよね。
個人的にはBedrockのEmbeddingモデルには物足りなさを感じている（性能が低い or 入力トークンが小さい）と感じているので、件数でカバーしたいんだよね。。。。
kun432BedrockのEmbeddingモデルの検索性能を改善するために、以下のような機能が今はある。
今回のアップデートにより、新たに追加された2つチャンキング戦略が追加されました。
これらは最大トークン数以外の要素を考慮したチャンキング戦略となっており、より高度な分割が可能になっています。
階層的チャンキングは、いわゆるRecursive Retrieverとかsmall-to-bigと呼ばれるものだと思うけど、一般的に
- 検索したいドキュメントよりもクエリは圧倒的に小さいので、検索するにはチャンクが小さいほうが精度が良くなる
- が、逆に小さすぎるチャンクは、リッチな回答を生成するための情報量が少なくなってしまい、回答の質が下がる。
を改善できると思っているのだけど、ベクトルDBにPineconeを使っている場合、ドキュメントによってはエラーになってしまう。
おそらく、Pineconeとのインテグレーションが完全ではない模様。
他にもこんなのもある様子だが、どちらもドキュメントには記載が探させなかった。
knowledge baseのベクトルDBとしてはPineconeが一番安価に始めやすい（というか他が高すぎるんだよね・・・）ので、ここは改善してほしいなぁ。せめて、対応しない・できていないにしても、ドキュメントに記載しておいてほしいところ。
kun432もう一つ。エージェント作成時にこんなメッセージが出る場合がある。
エージェントのパフォーマンスを最適化するために、以下の条件がすべて満たされる場合、エージェントは指示を使用しません。
- このエージェントにはアクショングループがありません。
- このエージェントに関連付けられているナレッジベースは1つだけです。
- 高度なプロンプトがオーバーライドされていません。
- ユーザー入力とコードインタープリタが無効になっています。
上記の条件のいずれかが満たされない場合、エージェントは指示を使用します。詳細はこちら
なるほど、「エージェント向けの指示」を入力したとしても、使われない場合があるってことね。入力した指示が使われるようにするには、
- アクショングループを追加する
- ナレッジベースを２つ以上追加する
- 高度なプロンプト（マネージメントコンソールだと「詳細プロンプト」）を上書きする
- ユーザー入力かCode Interpreterを有効化する
のどれかを満たす必要があるということになる。
ユーザー入力はこれ。
なお、Code Interpreterは、2024/09/24時点では以下リージョンのみで、東京リージョンには来ていない。
- 米国東部 (バージニア北部)
- 米国西部 (オレゴン)
- 欧州 (フランクフルト)
kun432まとめ
少し脱線したけども、Slackインテグレーション自体は簡単に設定できるのでとても良いと思う。Bedrock
AgentやKnowledge base自体もとても簡単に構築できて、運用もかなり楽。AWSの他のリソースとの連携などを考えると、広がりもたくさんありそう。
ただ、個人的に以前から感じているのは、
- BedrockのKnowledge baseの検索精度には、基本的に物足りなさを感じている。
- BedrockのEmbeddingモデルのラインアップには、基本的に物足りなさを感じている。
- 検索精度を上げようと思うと、料金が高いベクトルDBを選択せざるを得ないというところでハードルも高い。
あたりで、あくまでも個人の意見ではあるけど、社内でほぼ運用しない・精度割り切って使う分にはいいんだけど、外向けサービスの基盤として使うっていうイメージは持てないんだよな、少なくとも現時点では。また、同じようなSlackインテグレーションできるRAG・エージェント構築サービスも複数あるし、自分もいくつか試してみた限り、UXや精度的にもそっちのほうがぜんぜんイケてる印象がある。
ただ、それだけで使う使わないが決まるものではないと思うし、特に企業内ユースで考えるならば、データ管理がコントロールしやすいとか支払いが１本化しやすいとか、AWSがやってることの強みはあると思う。なので、今回のインテグレーションには納得感もあるし、ぜひ社内で使いたい！みたいなニーズを満たすような施策を進めてほしい。
ただコストはなるべくお安めでお願いしたいところ・・・・