AI Evals のご紹介: 推測ではなく測定

LLM の魔法に誘われてテストをスキップしたくなるかもしれませんが、評価は自信を持ってリリースするための鍵となります。

ウェブベースのテーマビルダーのプロトタイプを作成しているとします。これは楽しいツールです。ウェブ アプリケーションで、ユーザーが会社名と説明、ターゲット ユーザー、トーンとムードを入力します。フロントエンドはこれをサーバーに送信します。サーバーは、大規模言語モデル(LLM)を使用して、期待されるトーンやムードに合ったクリエイティブなモットーと、ブランドに沿ったアクセシブルなカラーパレットを生成します。このデータは小さな JSON オブジェクトとして返されます。

このアプリケーションを ThemeBuilder と呼びます。

ThemeBuilder の入力と出力。
ThemeBuilder に、Midnight Coffee という会社のテーマの例が表示されています。このアプリケーションは、会社名、説明、オーディエンス、トーンを使用して、モットーとカラーパレットを出力します。

基盤となる LLM を選択し、プロンプトを反復処理します。社内デザイナーはカラーパレットを気に入っており、モットーもキャッチーです。

ここで、次の質問をします。

  1. 本番環境に対応していますか?アプリケーションの出力品質が十分に一貫しているかどうかを判断できません。一部の内部テスターから、パレットの破損やブランド以外のモットーに関する報告が寄せられています。1 つのケースを修正すると、さらに 2 つのバグが発生します。
  2. モデルを変更できますか?レイテンシを削減するために同じ LLM の最新バージョンにアップグレードしたり、費用を削減するためにマネージド サービスからセルフホスト モデルに切り替えたりすることがあります。アプリケーションの出力が改善されるか悪化するかはわからず、回帰をテストする方法もありません。
  3. 発送しても安全ですか?有害な出力が 1 回報告されましたが、再現できません。偶発的なものか、リリースをブロックすべきか。

LLM の出力品質のばらつきが大きすぎるため、チームはリリースを中止します。テストなしでリリースする自信を持つのは難しいでしょう。

テストではなく推測する理由

AI を初めて構築するときは、いくつかの出力を確認して問題ないと判断し、次のステップに進みたくなるかもしれません。測定やデータではなく、直感に頼る理由は何ですか?

決定論的アルゴリズムでは、入力ごとに 1 つの出力があります。確率的アルゴリズムでは、入力ごとに複数の出力が考えられます。

これは、LLM が決定的ではなく確率的であるためです。つまり、同じ会社名、説明、オーディエンス、トーンを指定しても、ThemeBuilder から異なるモットーとカラーパレットが出力される可能性があります。

キャッチーなモットーやブランドに合ったカラーパレットの正解は 1 つではありません。

LLM の創造性は優れています。しかし、非決定論はエンジニアリングの概念と矛盾しているように感じられます。したがって、LLM ベースのアプリケーションはテストできないと結論付けるかもしれません。

Evals を活用する

LLM の世界でも、開発のベスト プラクティスは有効です。LLM ベースのアプリケーションはテストできますし、テストすべきです。必要なのは、異なる手法だけです。これらの手法は評価(eval)と呼ばれます。評価には新しいワークフローが必要ですが、既存のテストの専門知識は優れた評価の構築に直接活かすことができます。

評価は AI 機能のテストです。これらのテストは、重要なフィードバック ループの作成に役立ちます。堅牢な評価パイプラインを構築すると、LLM ベースの機能がユーザーにとって使いやすくなります。これにより、チームは自信を持って機能をリリースできます。

LLM を使用して構築している場合は、堅牢な評価を実装する方法を学ぶことが、時間を有効に使う最良の方法の一つです。

それでは、評価について学びましょう。