Amazon Bedrock Agent Evaluations を試してみた

Amazon Bedrock AgentCore Evaluationsを使い、ふるさと納税アドバイザーのエージェントを評価した試用記事である。エージェントは同じ質問に対して毎回違う文章を返し、呼ばれるツールすら変わることがあるため、Web APIのように応答をassertして合否を決めることはできない。そこでLLMを審判として使い、応答が事実として正しいか、適切なツールを適切な引数で呼べたかといった観点を0〜1のスコアに変換する。Builtin.Helpfulnessのような組み込み評価者はIDを指定するだけで使え、評価用のプロンプトを自分で書く必要はない。記事は、オンデマンド評価、バッチ評価、オンライン評価の三つを一通り試している。題材はStrands Agentsで作られ、計算、Web検索、知識照会のツールを持つエージェントである。 AIの鬼の視点で言えば、評価を「テスト」と呼ぶと誤解が生まれる。テストは合否を出すが、評価は体温計に近い。数字は出るが、熱の原因を突き止めて手当てするのは人間の仕事だ。記事も、返ってくるのはスコアと採点理由であって修正案ではないと明言している。もっと引っかかるのは、ふるさと納税という「数字を答える」題材を選んだことだ。控除上限の表を持つエージェントは、文章が滑らかなほど数字まで正しそうに見えてしまう。文章の出来を採点する審判が、数字の正しさまで見抜けるとは限らない。記事の題材でも、控除上限の表はコード上で簡易テーブルとして作られており、ここは数字と文章を分けて測るべき場面である。 中小企業の実務に落とすなら、社内で業務の数字を答えるAIを作るときは、評価の前に正解表を人間が用意しておくことだ。AIの採点だけでは「良くなった気がする」から抜け出せない。プロンプトを変えるたびに、よく聞かれる質問を二十件ほど決めて同じ質問を投げ、スコアが下がった項目だけ人間が読む。この運用なら、手間は小さく、壊れたことを本番で最初に知る事態は避けられる。料金体系は記事にも触れられているので、導入を決める前にクラウド側の利用料を試算しておくとよい。