生成AI（GenAI）は急速に進化しており、もはや楽しいチャットボットや印象的な画像生成だけにとどまりません。2025年は、AIを取り巻くメディアの誇大宣伝を真の価値へと転換することに焦点が当てられる年となるでしょう。世界中の企業が、ユーザーへのサービス向上、効率性の向上、競争力の維持、そして成長促進のために、GenAIを自社の製品やプロセスに統合し活用する方法を模索しています。主要プロバイダーが提供するAPIや事前学習済みモデルのおかげで、GenAIの統合はかつてないほど容易になったように見えます。しかし、落とし穴があります。統合が容易だからといって、AIソリューションが導入後に意図したとおりに機能するとは限らないのです。
予測モデル自体は新しいものではありません。人間は長年にわたり、統計学を皮切りに物事を予測してきました。しかし、GenAIはいくつかの理由から予測に革命をもたらしました。
- AI ソリューションを構築するために、独自のモデルをトレーニングしたり、データ サイエンティストになる必要はありません。
- AI はチャット インターフェースを通じて簡単に使用できるようになり、API を通じて簡単に統合できるようになりました。
- これまでは不可能だった、または非常に困難だった多くのことが可能になります。
これらの要素すべてが、GenAIを非常に魅力的なものにする一方で、リスクも伴います。従来のソフトウェアや古典的な機械学習とは異なり、GenAIは新たなレベルの予測不可能性をもたらします。決定論的なロジックを実装するのではなく、膨大なデータで学習させたモデルを使用し、必要に応じて応答することを期待するのです。では、AIシステムが意図したとおりに動作しているかどうか、また、実用化できる状態にあるかどうかをどのように判断すればよいのでしょうか？その答えは評価です。この記事では、この評価という概念について詳しく見ていきます。
- Genai システムを従来のソフトウェアや従来の機械学習 (ML) と同じ方法でテストできない理由
- AI システムの品質を理解するために評価が不可欠であり、オプションではない理由 (サプライズが好きな場合を除く)
- さまざまな種類の評価とそれを実際に適用するための手法
プロダクト マネージャー、エンジニア、あるいは AI に携わっている方や AI に興味がある方であれば、この記事が AI システムの品質について批判的に考える方法 (そしてその品質を実現するために評価が不可欠である理由) を理解する一助になれば幸いです。
生成 AI は、従来のソフトウェアや従来の機械学習のようにテストすることはできません。
従来のソフトウェア開発では、システムは決定論的な論理に従います。つまり、X が発生すれば Y が必ず発生します。ただし、基盤となるシステムに問題があったり、コードにバグを混入したりした場合は別です。そのため、テスト、監視、アラートが追加されます。単体テストはコードの小さなブロックを検証するために使用され、統合テストはコンポーネントが正しく連携して動作することを確認するために使用され、監視は本番環境で何かが誤動作していないかを検出するために使用されます。従来のソフトウェアのテストは、電卓をチェックするようなものです。2 + 2 と入力して、4 を期待します。明確で決定論的であり、真か偽かのどちらかです。
しかし、機械学習と人工知能は不確定性と確率性を導入します。ルールによって動作を明示的に定義するのではなく、データからパターンを学習するようにモデルを訓練します。AIでは、Xが発生した場合、出力はもはや固定のYではなく、モデルが訓練中に学習した内容に基づいた、一定の確率を持つ予測となります。これは非常に強力ですが、同時に不確実性ももたらします。同一の入力でも時間とともに異なる出力が得られる可能性があり、もっともらしい出力が実際には間違っている可能性があり、まれなシナリオでは予期せぬ動作が発生する可能性もあります。
このため、従来のテスト方法は不十分であり、場合によっては実行不可能です。電卓の例は、自由記述式の試験で生徒の成績を評価しようとするのと似ています。各問題、そしてそれに対する多くの解答方法に対して、提示された解答は正しいでしょうか？生徒が持つべき知識レベルを超えているでしょうか？生徒はすべてを捏造したが、非常に説得力があるように見えるでしょうか？試験の解答と同様に、AIシステムも評価できますが、さまざまな入力、コンテキスト、ユースケース（またはテストの種類）に適応できる、より汎用的で柔軟な方法が必要です。
従来の機械学習（ML）では、評価はプロジェクトライフサイクルの確立された一部となっています。融資承認や疾病検出といった狭いタスクでモデルをトレーニングする場合、精度、再現率、RMSE、MAEなどの指標を用いた評価ステップが必ず含まれます。これは、モデルのパフォーマンスを測定し、異なるモデルオプションを比較し、モデルが展開に十分適しているかどうかを判断するために使用されます。GenAIでは、通常、状況が異なります。チームは、モデルプロバイダーによる内部的な汎用評価と一般的なベンチマークで既にトレーニングされ、合格しているモデルを使用します。これらのモデルは、質問に答えたりメールを作成したりといった一般的なタスクには非常に優れていますが、特定のユースケースで過度に依存してしまうリスクがあります。しかし、「この素晴らしいモデルは、私のユースケースに十分適しているだろうか？」と自問することが重要です。ここで評価が重要になります。予測や生成が、特定のユースケース、コンテキスト、入力、ユーザーに適しているかどうかを評価します。
ML と GenAI の間には、モデルの出力の多様性と複雑さというもう 1 つの大きな違いがあります。カテゴリと確率 (顧客がローンを返済する確率など) や数値 (住宅の特徴に基づいた予想価格など) は返されなくなりました。 GenAI システムは、長さ、トーン、内容、形式が異なるさまざまなタイプの出力を返すことができます。同様に、これらのモデルは、高度に構造化された特定の入力を必要とせず、通常はテキスト、画像、さらには音声やビデオなど、ほぼすべての種類の入力を受け入れます。したがって評価はさらに難しくなります。
評価は必須であり、オプションではない理由（不快なサプライズを好まない限り）
評価プロセスは、AIシステムが実際に意図したとおりに動作しているか、運用準備が整っているか、そしてもしそうであれば、期待どおりのパフォーマンスを維持しているかを判断するのに役立ちます。評価プロセスが重要な理由を以下に分析します。
- 品質評価: 評価は、AI 予測または出力の品質と、それらが全体的なシステムおよびユースケースにどのように統合されるかを理解するための構造化された方法を提供します。回答は正確ですか?役に立つ？凝集性?関連している？
- エラーを定量化する: 評価は、エラーの割合、種類、および大きさを判断するのに役立ちます。エラーはどのくらいの頻度で発生しますか?最も頻繁に発生するエラーの種類は何ですか (例: 誤検知、幻覚、フォーマット エラー)?
- リスク軽減: 有害または偏った行動がユーザーに届く前にそれを検出して防止し、評判リスク、倫理的問題、潜在的な規制問題から企業を保護します。
自由な入力と出力の関係と長文テキスト生成を備えた生成 AI により、評価はより関連性が高く複雑になります。物事がうまくいかないときは、非常に悪い方向に進む可能性があります。チャットボットが危険なアドバイスを提供したり、モデルが偏ったコンテンツを生成したり、AI ツールが誤った事実を幻覚させたりといったニュースの見出しを私たちは皆見たことがあるでしょう。
「人工知能は決して完璧ではありませんが、評価システムを利用することで、金銭的な損失、信用失墜、あるいはTwitterでの炎上といった事態を招く可能性のある、恥をかくリスクを軽減できます。」
AI 評価戦略をどのように定義しますか?
では、AI の評価はどうやって決定するのでしょうか?すべての人に当てはまる評価方法はありません。評価は特定のユースケースによって異なり、AI アプリケーションの特定の目標と一致する必要があります。たとえば、検索エンジンを構築している場合、結果の関連性が重要になるかもしれません。チャットボットの場合は、有用性と安全性を気にするかもしれません。機密情報であれば、正確性と精度が重要になると思われます。複数のステップを含むシステム（検索を実行し、結果に優先順位を付けて、回答を生成する AI システムなど）の場合、多くの場合、各ステップを評価する必要があります。ここでの考え方は、各ステップが全体的な成功指標の達成に役立つかどうかを測定することです (そして、これに基づいて、反復と改善の焦点をどこに置くべきかを理解します)。
一般的な評価領域は次のとおりです。
- 正しさと幻覚: 出力は現実的に正確ですか?システムは不正確な情報や幻覚を生成しますか?
- 関連性: コンテンツはユーザークエリまたは提供されたコンテキストと一致していますか?
- 安全性、偏見、毒性
- 形式： 出力は期待される形式 (JSON、有効な関数呼び出しなど) になっていますか?
- 安全性、バイアス、毒性: システムは有害、偏向的、または有毒なコンテンツを生成しますか?
タスク固有の評価指標。例えば、分類タスクでは精度や適合率などの指標が使用され、要約タスクではROUGEやBLEUが、コード作成タスクでは正規表現やエラーのない実行の検証が用いられます。
評価は実際にはどのように計算されるのでしょうか?
測定対象を決定したら、次のステップはテスト ケースを設計することです。これは、次のような一連の例です (多ければ多いほど良いですが、常に価値とコストのバランスをとります)。
- 入力例:システムが本番稼働に入った後の現実的な紹介。
- 期待される出力 (該当する場合): 重要な事実または望ましい結果の例。
- 評価方法： 結果を評価するための記録メカニズム。
- 結果または成功/失敗: テスト ケースを評価する計算メトリック。
ニーズ、時間、予算に応じて、評価方法として使用できる手法がいくつかあります。
- 次のような統計記録ツール: BLEU、ROUGE、METEOR、または埋め込み間のコサイン類似度測定 – 生成されたテキストを参照出力と比較するのに適しています。
- 従来の機械学習指標としては、 精度、再現率、AUC – ラベル付きデータによる分類に最適です。
- 大規模言語モデルを裁判官として（LLM-as-a-Judge） 大規模な言語モデルを使用して出力を評価します（例：「この回答は正しくて役に立ちますか?（「）」）。特に、分類されていないデータが利用できない場合や、オープンエンド構造を評価する場合に便利です。
コードベースの評価プロセスでは、標準式、論理ルール、またはテストケースの実装を使用してフォーマットを検証します。
結論
具体的な例を挙げてすべてをまとめてみましょう。顧客サポート チームが受信メールの優先順位付けを行えるように、感情分析システムを構築しているとします。
目標は、最も緊急性の高いメッセージや否定的なメッセージに迅速に対応し、フラストレーションを軽減し、満足度を高め、顧客離れを低下させることです。これは比較的単純な使用例ですが、出力が限られているこのようなシステムでも、品質は重要です。予測が間違っていると、電子メールの優先順位がランダムに決定され、チームがコストのかかるシステムで時間を無駄にしてしまう可能性があります。
では、ソリューションが期待どおりに機能しているかどうかをどのように確認すればよいのでしょうか?評価中です。この特定のユースケースで評価する上で関連する可能性がある項目の例をいくつか示します。
- フォーマット検証: 電子メールの感情を予測するための大規模言語モデル (LLM) 呼び出しの出力は、期待される JSON 形式で返されますか?これは、正規表現、スキーマ検証などのコードベースのチェックによって評価できます。
- 感情分類の精度: システムは、短いテキスト、長いテキスト、多言語のテキストなど、さまざまなテキストにわたって感情を正しく分類できますか?これは、従来の機械学習メトリクス (ML メトリクス) を使用してラベル付けされたデータを使用して評価できます。ラベルが利用できない場合は、大規模言語モデル (LLM) を判断基準として使用します。
解決策が明確になったら、その解決策の最終的な影響に最も関連性の高い指標も含めるようにしましょう。
- 優先順位付けの有効性: サポートエージェントは実際に最も重要なメールに誘導されていますか?優先順位は、望ましいビジネスへの影響と一致していますか?
- 最終的なビジネスへの影響: 時間が経つにつれて、このシステムは応答時間を短縮し、顧客離れを減らし、満足度スコアを向上させますか?
評価は、AIシステムが有用で、安全で、価値があり、実運用に耐えうるものであることを保証するために不可欠です。したがって、単純な分類器であろうと、汎用的なチャットボットであろうと、「十分な品質」（最低限許容できる品質）とは何かを明確に定義し、その定義に基づいてパフォーマンスを測定するための評価方法を構築することが重要です。
参照
[1] AI製品には評価が必要です、ハメル・フセイン
[2] LLM評価指標：究極のLLM評価ガイド、Confident AI
[3] AIエージェントの評価、deeplearning.ai + Arize
コメントは締め切りました。