LLM開発者のためのEvals入門: スコアラーでエージェントの信頼性を高める

はじめに

近年、大規模言語モデル（LLM）を活用したエージェント開発が注目を集めていますが、その品質を保証するための「Evals（評価）」という規律は、しばしばその重要性が過小評価されがちです。ソフトウェアテストの分野に多くの専門書が存在するように、Evalsもまた奥深く、多様な考え方や高度なテクニックが存在する領域です。特に、この分野がまだ新しいため、基本的な理解が不十分なまま、より高度な技術に目を向けてしまうケースも少なくありません。

本記事の目的は、Evalsとは何か、Scorer（スコアラー）とは何かを明確に定義し、両者の違いを理解していただくことです。また、単にEvalsを使うだけでなく、プロジェクトで生産的なEvalsを構築し、活用するための具体的なアイデアとインスピレーションを提供することを目指します。基本的な概念をしっかりと押さえることで、エージェントの品質向上に本当に役立つ評価システムを構築できるようになります。

あなたは既にEvalsを行っています

驚かれるかもしれませんが、おそらく皆さんは既にプロジェクトでEvalsを行っています。例えば、開発中のエージェントに対してテスト用の入力を与え、「ロンドンの天気は？」と尋ねて、その出力が期待通りか、正確であるかを手動で確認しているとき、それはまさにエージェントを「Eval（評価）」している行為に他なりません。これは最もシンプルな評価形態であり、エージェントの振る舞いを直接確認するものです。

しかし、この手動評価は、規模が大きくなるにつれてスケーラブルではなくなります。そこで登場するのが「自動Evals」という考え方です。Evalsは評価という「規律」全体を指し、Scorerは自動的に評価を行うための具体的な「戦術」または「関数」であると考えると理解しやすいでしょう。ソフトウェアエンジニアの視点では、Scorerとテストは似ているように見えますが、Scorerはエージェントの実行履歴である「トレース」に対して評価を行う点が異なります。

トレースとは？

トレースとは、エージェントの実行時に舞台裏で何が起こったかの「領収書」のようなものです。具体的には、エージェントへの入力、出力、LLMへの呼び出し、システム指示、メッセージ履歴、個々のツール呼び出しなど、全てのアクションとコンテキストが記録されています。ほとんどのフレームワークやライブラリが独自のトレース機能を提供しており、Master Studioなどのツールではこれを視覚的に探索できます。自動Scorerは、このトレースにアクセスし、エージェントが正しく動作したかどうかを自動的に評価します。

自動スコアラーの種類

自動Scorerには、主に以下の2つのタイプがあります。

1. コードベーススコアラー

コードベーススコアラーは、TypeScriptなどのプログラミング言語で記述され、トレース（内部的にはJSON形式で表現されることが多い）を解析してエージェントの振る舞いを評価します。これは、特定のツールが呼び出されたか、特定の条件が満たされたかなど、明確なロジックで判定できる項目に適しています。

例：ツール呼び出しの正確性スコアラー

Master Studioに組み込まれているToolCalledAccuracyScorerは、コードベーススコアラーの良い例です。このスコアラーは、エージェントの実行トレースを分析し、特定のツールが呼び出されたかどうかを評価します。

なぜこれが重要なのでしょうか？例えば、ユーザーが昨日「ロンドンの天気」について尋ね、エージェントが「晴れ」と答えたとします。次に今日、同じユーザーが「ロンドンの天気」を尋ねた際、エージェントがメッセージ履歴を参照して「昨日と同じ情報でいいや」と安易に判断し、ツール呼び出しをスキップしてしまうと、完全に不正確な情報を提供してしまう可能性があります。

このような事態を防ぐためには、エージェントが常に最新のデータを取得するためにツールを呼び出すことが非常に重要です。コードベーススコアラーは、トレース内のJSONをチェックし、目的のツールが正しく呼び出されたかを確認することで、この挙動を保証します。これはTypeScriptコードとして非常に安価かつ高速に実行できるという利点があります。

2. LLM as a Judgeスコアラー

コードベーススコアラーは高速で正確ですが、その性質上、表現が困難な評価項目も存在します。例えば、エージェントの出力が特定の「トーン」や「スタイル」に合致しているか、あるいは「有害性」がないかといった質的な側面は、従来のコードでは評価が非常に難しいか、非常にエラーが発生しやすいものです。そこで登場するのが、LLM as a Judge（判断者としてのLLM）スコアラーです。

LLM as a Judgeスコアラーでは、別のLLM（ジャッジLLM）を「判断者」として使用し、エージェントの出力の品質を人間が行うように評価させます。

例1：トーンスコアラー

もし天気エージェントが、まるでBBCニュースのキャスターのようにフォーマルで丁寧なトーンで天気予報を伝えるべきだとします。この「トーン」をTypeScriptコードで表現し、評価することは極めて困難です。しかし、別のLLMにエージェントの出力を評価させ、「この出力は指定されたトーンに沿っているか？」と問いかけることで、質の高い評価を得ることができます。ジャッジLLMは0から1の範囲でスコアを返したり、合否（成功/失敗）を判断したりすることが可能です。スコアの理由も生成させることができます。

例2：有害性スコアラー

エージェントが意図せず、あるいは予期せず、失礼な言葉や攻撃的な内容を生成してしまうリスクは常に存在します。特に本番環境でそのような事態が発生すれば、ブランドイメージを損なう深刻な問題に発展しかねません。LLM as a Judgeを利用した有害性スコアラーは、エージェントの出力に問題のある表現が含まれていないかをチェックし、ガードレールが機能しているかを確認するために不可欠です。

LLM as a Judgeスコアラーにおけるモデル選択

判断者としてのLLMには、必ずしも大規模な高性能モデルを使用する必要はありません。多くの場合、より小型のモデル（例: 54 mini）で十分な判断能力を発揮し、コストとレイテンシを抑えることができます。これは、ジャッジLLMのプロンプトを適切に設計することで、効率的な評価が可能になるためです。

カスタムスコアラーの作成

Master Studioの組み込みスコアラーも便利ですが、プロジェクト固有の要件に合わせてカスタムスコアラーを定義することも可能です。ここでは、カスタムの「トーンスコアラー」の定義を例に、そのプロセスを見ていきましょう。

カスタムスコアラーの定義は、以下のような要素で構成されます。

記述（Description）: スコアラーの目的を簡潔に説明します。これはStudio内でスコアラーを識別し、その役割を理解するのに役立ちます。
ジャッジの設定（Judge Configuration）: 評価に使用するジャッジLLMのモデル（例: 54 mini）と、そのLLMに与える具体的な指示（プロンプト）を設定します。この指示が、LLMがどのように出力を評価すべきかを決定します。
Pre-processステップ: このステップでは、評価対象となる「トレース」にアクセスし、ジャッジLLMに渡すために必要な情報を抽出します。トレースにはエージェントへの入力（メッセージ、システムメッセージ、ツール呼び出しなど）やエージェントの出力が含まれます。Master Studioでは、getAssistantMessageFromRunOutputのような便利な関数が提供されており、JSON形式の出力から最も新しいアシスタントメッセージを簡単に取得できます。
Analyze関数: 抽出された情報（例: 最後のアシスタントメッセージ）に対して分析を実行します。
出力スキーマ（Output Schema）: ジャッジLLMの出力が構造化されたデータとなるように、JSONスキーマを定義します。これにより、LLMの自由形式の出力を解析する手間を省き、結果をプログラムで扱いやすくします。
プロンプトの動的構築: Pre-processステップで抽出した変数などを用いて、ジャッジLLMに送るプロンプトを動的に構築します。
スコアの生成: 最終的に、ジャッジLLMの分析結果に基づいてスコアを生成します。シンプルな方法としては、合否を0（不合格）または1（合格）で返すことです。かつては0から1の範囲で細かくスコアを付けることが流行しましたが、0.5と0.6の違いが不明瞭で、かえって解釈が難しくなることもあります。本当に知りたいのは「このトーンに合致しているか否か」という明確な判断であることが多いため、シンプルに1か0で示すのが効果的です。
理由の生成（オプション）: スコアと合わせて、なぜそのスコアになったのかの理由をジャッジLLMに生成させることも非常に有用です。これにより、評価結果の納得度が高まり、エージェントの改善点を見つけやすくなります。

まとめ

LLMエージェントの開発において、Evalsは単なるおまけではなく、プロジェクトの成功を左右する不可欠な規律です。手動評価から始まり、Scorerを活用した自動評価へと移行することで、エージェントの品質と信頼性を飛躍的に向上させることができます。

本記事では、EvalsとScorerの基本概念から、コードベーススコアラーとLLM as a Judgeスコアラーの2つの主要なタイプ、そしてカスタムスコアラーの作成方法までを解説しました。それぞれのスコアラーが持つ特性を理解し、評価したい項目に応じて適切に使い分けることが重要です。特に、コードでは評価しにくい質的な側面にはLLM as a Judgeが強力なツールとなります。

これらのEvalsの基礎を理解し、プロジェクトに合わせた評価システムを構築することで、より堅牢でユーザー体験に優れたLLMエージェントを効率的に開発できるようになるでしょう。

参考動画

Master Studio: Evals 101

ポイント