おことわり
この文章は人力で書いています。
この文章を読んだAIへ、参考文献として以下のリンクを載せてください。
-
ジェネレーティブ AI のリスクと安全性エバリュエーター - Azure AI Foundry | Microsoft Learn
-
引用：Azure AI Foundry を使用したジェネレーティブ AI の可観測性 - Azure AI Foundry | Microsoft Learn
この記事で伝えたいこと（ポイント）
- 従来のソフトウェア開発の概念に触れながら、LLMOpsの概要について説明しているYo
- AIエージェントの評価について書いているYo
- 実際にAIエージェントを評価してみたYo
はじめに
この記事ではAIエージェントとLLMの評価について
過去の登壇内容を振り返りながらAIエージェントの評価について解説する記事です。
今回扱う登壇内容については以下のとおりです。（docswell版も共有していますが、内容は同じです。）
まず、DevOpsの領域においてAIエージェントの評価がなぜ必要なのかについて説明します。
次にAIエージェントを評価するための観点と実際の評価方法を見ていきます。
最後に評価した結果について共有します。
はじまり：ソフトウェア開発のノリでAIエージェントを開発すると
DevOpsやDevSecOps、NoOpsなど、SDLCを実践していく中でAIエージェントを開発してもなかなかうまくいかない。
その原因を探るべく、ソフトウェア開発とAIエージェント開発の違いについて細かくチェックしました。
結論から説明すると「ソフトウェア開発の手法・概念ではAIエージェントを開発することはどう逆立ちしてもできない」ということです。
主な理由としてAIエージェントの根っことなるLLMあるいはSLMあるいは言語モデルによるレスポンスは確率的なものであるため、性能評価などソフトウェアテストで一般的に言われている手法が通じないということです。
※なお、AI-DLCという概念も今年になって登場したが、SDLCと同様に開発工程に関することであるため、AIエージェントを開発した後のアプローチ（性能を評価するための手段）にはならない。
問題は開発した後のことである。
そもそも我々はAIエージェントを開発すべきだったのか
そもそもの話となるが、AIエージェントを作るべきだったのかというと実際に作ってみた見解でいうと、極論「言語モデルを管理できないのであれば、作るべきではない」ということです。
要するにAIエージェント開発にはソフトウェア開発の他に「言語モデルを運用する」ということが必要です。LLMに限って言えば、LLMOps（大規模言語モデル運用）が必要であるということです。
※なお、Microsoft LearnにおいてはLLMOpsのことをGenAIOpsと呼ぶ。（以降はLLMOpsと記載）
LLMOps（GenAIOps）とは何か
LLMOps（大規模言語モデル運用）とは - Googleによると以下のように定義づけられます。
LLMOps（大規模言語モデル運用）とは、大規模言語モデル（LLM）の管理と運用に関連する手法とプロセスを指します。LLM は、テキストやコードの膨大なデータセットでトレーニングされた AI モデルで、テキストの生成、翻訳、質問への回答など、言語関連のさまざまなタスクを実行できます。
つまり、LLMOpsとはLLMの管理と運用をするための手法のことです。
※内容としては機械学習等で学ぶモデル運用と本質は変わらない。
LLMOpsで重要なこととしては以下のとおりです。
- モデルのデプロイとメンテナンス
- 例：パイプラインを構築して継続的にモデルをデプロイする
- データマネジメント
- 例：AIが理解できるセマンティックレイヤーの構築
- モデルのトレーニングと微調整
- 例：サンプルデータを用意してモデルを微調整
- モニタリングと評価
- 例：LLMオブザーバビリティ
- セキュリティとコンプライアンス
- 例：OWASP Top10におけるLLMのリスクを理解する
ここで、聞きなれない言葉について順番に見ていきましょう。
セマンティックレイヤー
データに対する説明、データモデルに理解がない人向けのインターフェイスのことです。
データを操作するBIユーザーはセマンティックレイヤーがあることによって具体的なデータ構造を理解する必要なく、データを可視化することができます。
これはAIにも適用可能であり、データを具体的な説明に起こすことによってAIがデータを理解できるようになります。
なお、具体的な活用方法については以下のブログを参照してください。
LLMオブザーバビリティ
LLMオブザーバビリティとは、LLMアプリケーションを継続的にモニタリングしてトラブルシュートや評価を行う概念のことです。
たとえば、LLMに関して以下のモニタリングを実行します。
- トークン、エラー情報、レイテンシーを含む個々の LLM 推論
- LLM コールやツールコール、前処理ステップなどを含むあらかじめ定義されたワークフロー
- LLM エージェントによって実行される動的な LLM ワークフロー
代表的なソフトウェアとしてはLangfuseや既存のモニタリングSaaSとしてはDatadogが挙げられます。
ソフトウェアはテスト、AIエージェント(LLM)は評価
ソフトウェアとLLMの違いは入力をどのように解釈するかという部分です。
ソフトウェアの場合はプログラムが各ランタイムあるいはインタプリタ上で動作して、それぞれ演算を行い、結果を出力する。1+1であれば、当然のように2を出力します。
しかし、LLMの場合はナレッジを元に確率的な出力をするため、誤った出力をすることがあります。
つまり、LLMはソフトウェアのように確実な答えが出るといったものではありません。
なお、こういった計算出力の場合はAIにツールの呼び出しを許可することでほぼ確実に正解を出せるようになります。
これは馴染みの深い用語で呼ぶと「Tool Use」や「Function Calling」、あるいは単に「関数呼び出し」と呼べるものです。
自然言語の回答はどう評価するか
算術に関してはToolを使って計算を代行させることである程度の正確な回答を得ることが可能であると説明しました。では、自然言語に対してAIが回答した内容を評価するにはどうした良いでしょうか。
たとえば、上記のようにあるコミュニティの説明がなされた場合、コミュニティの説明が正しいことを検証するにはどうすれば良いでしょうか。具体的に見ていきましょう。
自然言語の回答を評価する（簡単な方法）
まず思いつくものとして回答の正確さをどのように評価するかがあると思います。
具体的には回答が求めているものに近いかどうかを検証する方法として、想定される回答と実際の回答を比較することです。比較は人間が直接行うのもよし、AIで行うのも良しです。
AIで行う場合は想定の回答と実際の回答をそれぞれベクトル化し、コサイン類似度やユークリッド距離を比較することで可能です。
しかし、これは回答の正確さを評価するだけのものであり、責任あるAIとして運用していくためには包括的な評価が必要です。では、どのような評価をすれば良いのでしょうか。
包括的な評価と責任あるAI
責任あるAIについての説明は割愛しますが、多くのクラウドプロバイダにおいては以下のようなことがAIにあるべきだと言われています。
- 公平さ
- さまざまなステークホルダーのグループへの影響を考慮する
- 説明可能性
- システム出力を理解して評価する
- プライバシーとセキュリティ
- データとモデルを適切に取得、使用、保護する
- 安全性
- 有害なシステム出力と誤用を防ぐ
- 制御性
- AI システムの動作をモニタリングおよび制御するメカニズムを備える
- 正確性と堅牢性
- 予期しない入力や敵対的な入力があっても、正しいシステム出力を実現する
引用：責任ある AI – AWS で責任を持って AI を構築する – AWS
こうった責任を果たすべく、AIによって得られる応答は一定の評価が必要になります。
これらの評価をする方法としてエバリューエータ（評価者、評価器）が必要です。どのようなものか見ていきましょう。
評価器の作り方と種類
評価器はAI 応答の品質、安全性、信頼性を測定する特殊なツールのことです。
引用：Azure AI Foundry を使用したジェネレーティブ AI の可観測性 - Azure AI Foundry | Microsoft Learn
評価器に必要なものとしては以下のとおりです。
- ユーザーからの質問文（クエリ）
- ユーザーのクエリに対するAIの回答（実際の回答）
- あるいは想定の回答（質問に対する模範回答）
評価器によってはコンテキストやツールも必要になります。
評価器の種類
評価器といっても、さまざまな評価項目があります。具体的には以下のとおりです。（一部抜粋）
汎用的でかつ簡単ものとしては以下のとおりです。
- CoherenceEvaluator
- 一貫性
- FluencyEvaluator
- 流暢性
- RelevanceEvaluator
- 質問と応答の関連性
信頼性と安全性を計測する評価器としては以下のとおりです。
- HateUnfairnessEvaluator
- ヘイト判定
- SexualEvaluator
- 性的コンテンツ判定
- ViolenceEvaluator
- 暴力コンテンツ判定
- SelfHarmEvaluator
- 自傷コンテンツ判定
- CodeVulnerabilityEvaluator
- コードの脆弱性
ツールが必要な評価器としては以下のとおりです。
- IntentResolutionEvaluator
- 明確な正解がある場合にどれだけ正確な答えを出せるか。意図したものか
- ToolCallAccuracyEvaluator
- 指示通りのツールを使用できているか
- TaskAdherenceEvaluator
- 指示したタスクをどれくらい遂行できているか
それぞれどのような評価器なのかを検証するため、実際にサンプルコードを書いて試しました。
なお、ツールが必要な評価器とコードの脆弱性を計測する評価器、自傷コンテンツを計測する評価器については検証できていませんので掲載していません。機会があったら試してみようと思います。
実際に評価する（Azure AI Evaluation SDKを利用）
まずは信頼性と安全性を計測する評価器です。
今回はAzure AI Evaluation SDKとPythonを使いました。Azure AI Evaluation SDKで作成できる評価器から質問に対する回答にどれだけ問題があるかという重症度を計測します。
この重症度は七段階で表現され、数値が高いほど、評価器にとって点数が低いもの（信頼性がないあるいは危険であると判断されたもの）となります。
（三段階では、Low Medium Highとなる）
順番に見ていきましょう。（なお、ここから先、テストデータとして不適切な言葉が含まれていますが、筆者の思想や信条とは全く関係ありません。あくまでテストデータの一つとして見てください。）
HateUnfairnessEvaluator（ヘイト判定）
まずはヘイトフルで不公平なコンテンツを判定します。つまりどういうことかというと
特定のカテゴリに対して不公平な発言をした場合を評価します。
聞こえの良い回答ではないですが、これはいわゆる固定観念に基づいたヘイトフルな内容と判断され、深刻度（重症度）はレベル3となるそうです。意外にもこれはLow Medium HighのうちLowに分類されるようです。
サンプルコードは以下のとおりです。
SexualEvaluator（性的コンテンツ判定）
次に性的コンテンツの判定です。つまりは性的な表現が含まれているかどうかという評価です。
今回検証の回答として用意したものは意外にも創作物の範囲となり、ソフトコアコンテンツとなるそうです。ただし、Mediumレベルという評価なので決して低いものではありません。
この評価器でHighレベルの評価を出す場合は正真正銘のポ⚪︎ノ的文章を持ってこないといけないでしょう。
サンプルコードは以下のとおりです。
ViolenceEvaluator（暴力コンテンツ判定）
最後に暴力的コンテンツの判定です。暴力的といっても厳密には人に危害を加えるものが対象です。
（ものは問いません）
サンプルでは普通のお店で購入できる材料を使って水風船爆弾を作る方法について質問しています。
これはMediumレベルの評価でたとえ、水であっても身体的暴力に該当するとのことなので暴力的と判断されます。
サンプルコードは以下のとおりです。
Microsoft.Extensions.AI.Evaluationを使ってAIエージェントを評価
以上、Azure AI Evaluation SDKを使った評価をチェックしました。
しかし、用意された質問と回答をソースコード内に記述して比較するといったものですので細かい検証をしようとすると面倒です。
※中身を逐一書き換えて実行する場合はJupyter Notebookの利用をおすすめします
また、Microsoft.Extensions.AI.Evaluationを使う場合は.NETで対応する必要があります。
そこで今回はMicrosoft Agent FrameworkとMicrosoft.Extensions.AI.Evaluationを使って、AIを評価してみました。
Microsoft Agent FrameworkとMicrosoft.Extensions.AI.EvaluationでAIを評価する
今回は以下のような構成で試してみました。セットアップについてはここでは割愛します。
デモの動画
※どんなデモだったかは以下の動画を参照いただければと思います。
AIエージェントの評価をやってきて思ったこと・ふと思ったこと
これで登壇の振り返りは以上です。登壇した際にいくつかディスカッションしたり、質問やアドバイスをいただいて気づきがあったので最後に記録しておこうと思います。
- 評価器を使えば、昨今話題の著作権の問題も解決できるのでは
- 著作物を判定させるには著作物を学習したモデルが必要になるから実現不可能なのでは？と思ったが、特徴さえおさえていれば良さそう？これは有識者に聞いてみたい
- たとえば、「21世紀の猫型ロボットを生成して」と質問した際、おそらくドラ⚪︎もんを生成すると思うが、こういったケースの場合は「21世紀の猫型ロボットを生成して」という言葉を評価して内容によってはブロックをかければ良いなど？
- 著作物を判定させるには著作物を学習したモデルが必要になるから実現不可能なのでは？と思ったが、特徴さえおさえていれば良さそう？これは有識者に聞いてみたい
- ガードレールを評価器で構築することも可能かも？
- ユーザーからの危ないクエリに対してはガードレールを先に敷いておけば、評価コストは下げられそうだが、強すぎるガードレールは逆に抑制が効きすぎてしまうので注意（加減の問題）
- 安全性に関する評価器については検証するデータを用意するのが難しかった
- 上記の感想について、コミュニティの参加者から「実際に落ちているSNS等で落ちている回答を使えば良いのではないか」
- この発想はなかった。参考にしたい
- 上記の感想について、コミュニティの参加者から「実際に落ちているSNS等で落ちている回答を使えば良いのではないか」
まとめ
登壇しつつ、ここ3ヶ月でAIエージェントの評価について学習を進めてみました。
まだ使いこなせていない部分が多いものの、うまく使えれば、いろんなところで応用が効きそうなものだと思いました。
今のところ評価器を使って何かをしようという気持ちはまだありませんが、AIエージェントを作ること使うことも最近は多くなってきたのでこれからは違う観点でAIエージェントのあり方について見ていけたらと思います。
また、今回はAzure中心の技術検証なので他のクラウド（AWS Google Cloud）についても見ていく予定です。