実用最小限の評価を構築する

このビデオのデモは2026年8月に収録されました。Claude Haiku 4.5、Claude Sonnet 5、Claude Opus 5で実行されています。新しいモデルでは結果が異なります。各レッスンのデモはそれぞれ別の評価実行であるため、スコアとコストは他のレッスンのものとは一致しません。

評価とは、モデルが受ける試験です。 評価には3つの要素があります。現実的な入力、それぞれに対して期待する答え、そして各モデルが返す答えを採点する方法です。各モデルは、すべての入力に対してプロンプトを実行します。入力とその期待される答えを組み合わせたものがケースであり、すべてのケースを採点することでスコアが得られます。

Meridianの抽出プロンプトは、月次プロジェクトレポートごとに3つのフィールドを抽出します。短い値であるプロジェクトIDとスケジュールステータス、そして文章であるトップリスクです。

評価を構築することは、試験を実施することに似ています。あなたが教師で、モデルが生徒です。

LLM判定者とは、答えをチェックして正しいかどうかを判断する2番目のモデルです。答えを採点するものは、それがコードであれ、モデルであれ、人であれ、採点者（grader）と呼ばれます。Meridianの評価を、次の6つのステップで構築していきます。

1. 各フィールドの採点者を選ぶ
2. ケースのセットを設計する
3. 期待される答えを書き留める
4. トップリスク用のLLM判定者をセットアップする
5. モデルを実行し、その答えを採点する
6. 判定者を信頼する前に、サンプルを手作業で採点する

各フィールドの採点者を選ぶ

答えを採点する方法は3つあります。原則は、信頼性があり拡張可能な中で最も手早い方法を選ぶことです。

1. コードベースの採点。 コードが、答えが期待される答えと完全に一致するか、あるいはキーフレーズを含んでいるかをチェックします。これは最も手早く、最も信頼性の高い方法であり、どれだけ多くのケースにも対応できます。
2. LLM判定者。 判定者は、異なる2つの文章がどちらも正しい場合がある答えに適しています。これも手早く、柔軟で、拡張性があります。
3. 人による採点。 人が各答えを読むため、最高の品質が得られますが、遅くコストもかかるため、最後の手段となります。専門性が高くリスクの高い作業や、判断に委ねられる答えについては、依然として人が適切な採点者です。

正確にチェックできるすべてのフィールドにはコードを使い、判定者には残りだけを任せましょう。 Meridianの3つのフィールドについて、あるケース（レポートr032）でこれがどう展開するか見てみましょう。

ただし、レポートがリスクを挙げていない場合、期待されるtop_riskの答えはJSONの空値であるnullになります。これはコードで完全一致チェックできます。

ケースのセットを設計する

4つのルールが、ケースのセット全体の形を決めます。これらは、ドキュメントにある評価設計の原則に基づいています。

1. ケースをタスク固有のものにする。 サンプルデータはモデルがサンプルに対してどう振る舞うかしか示さないため、自分自身の実際のレポートからケースを作りましょう。
2. 採点を自動化する。 このセットは何度も繰り返し実行することになるため、日常的な採点は人手なしで機能する必要があります。
3. 完成度よりも量を優先する。 同じ労力であれば、自動で採点された多くのケースの方が、手作業で丁寧に採点された少数のケースよりも多くのことを教えてくれます。
4. エッジケースを層別化する。 エッジケースとは、スキャンされたレポートのように、本番環境が依然として送ってくる珍しい入力のことです。各種類について、本番環境における割合程度をセットに含めましょう。つまり、スキャンされたレポートが届くものの5%を占めるなら、セットの中でも約5%にします。

何よりも、ケースの構成は本番環境が送ってくるものに似ているべきです。 チームは量というと数百件のケースを意味すると考えがちですが、20〜50件程度のシンプルなセットで十分良いスタートになります。

Meridianは50件のケースに決めました。30件は典型的なレポート、10件は複数のプロジェクトにまたがるもの、そして10件はリスク記載なしケース、つまりリスクの項目がないレポートです。この2つの珍しいパターンは、Meridianに十分な頻度で届くため、カバーしておきたいものです。

期待される答えを書き留める

期待される答えを人が書き留めたケースは、ラベル付きセットと呼ばれます。各期待される答えは、モデルを実行する前に、レポートから自分自身で書きましょう。 コード採点者は、モデルの答えをこれらと比較します。

Meridianは、ラベル付きセットを1つのファイルgolden.jsonに保持しており、ケースごとに1つのレコードがあります。レコードには、ケースのid、そのcategory、そして各フィールドの期待される答えが含まれます。categoryはtypical、multi_project、missing_riskのいずれかです。

トップリスク用のLLM判定者をセットアップする

top_riskフィールドには文章が入ります。コードは、異なる2つの文章が同じリスクを指しているかどうかを判断できないため、このフィールドは判定者に任せます。これは記述式問題であり、採点補助者と同様に、判定者には採点ガイドが必要です。

そのガイドがルーブリックであり、何が正解とみなされ、何が不正解とみなされるかを文書化したルールのセットです。これは詳細で明確であるべきです。

判定者のプロンプトには、レポート、答え、そしてルーブリックが含まれます。それぞれが独自のXMLタグに入ることで、判定者がそれらを混同しにくくなります。あなたの期待される答えはプロンプトには含まれません。判定者はレポート自体から判断するからです。そうすることで、あなたとは異なる言い回しでリスクを表現しただけで答えが減点されることがなくなります。とはいえ、サンプルを手作業で採点する際の正しい答えの記録として、期待される答えは保持しておきましょう。

1つの答えに対する判定者の判断は、判定（verdict）と呼ばれます。判定は、コードが数えられる形で返ってきて初めて役立ちます。 構造化出力が、それを実現してくれます。リクエストとともにJSONスキーマを送ると、レスポンスはそれに一致しなければなりません。JSONスキーマは、JSONがどのフィールドを持つことができ、それぞれに何を入れられるかを記述します。

Meridianのスキーマには、explanationとverdictの2つのフィールドがあります。verdictはcorrect、incorrect、unknownのいずれかでなければなりません。explanationは、判定者がなぜそのように判断したのかを短く説明したもので、答えの何が間違っていたのかを知りたいときに読むものです。

最も重要な値はunknownです。これは判定者に逃げ道を与え、判断できないと言える選択肢を提供します。これがなければ、判定者は確信が持てないときでも、残り2つの選択肢のどちらかを推測で選ばなければなりません。

モデルを実行し、その答えを採点する

何かを採点する前に、まず答えが必要です。テストする各モデルで、すべてのケースに対してプロンプトを実行し、すべての答えをファイルに保存しましょう。Meridianは、Claude Haiku 4.5、Claude Sonnet 5、Claude Opus 5を使って、50件すべてのケースに対して抽出プロンプトを実行しました。

2つの採点者が一致するかどうかを確認するために、コードでも採点できるケースで判定者を一度テストしましょう。 Meridianの最初の判定者実行では、10件のリスク記載なしケースだけを対象にしました。これは3つのモデルで合計30件の答えになります。これらの期待される答えはnullなので、コードでも採点できました。後で手作業で判定者を確認できるように、各判定をその答えの隣に保存しておきましょう。

判定者の最初の実行。コードでも採点できる10件のリスク記載なしケースが対象。

リスクの項目がないレポートについて、Meridianは以前は意見しかなかったところに、各モデルの数値を持てるようになりました。

Haiku 4.5の5件の不正解は、すべて同じ種類の間違いであり、ケースr045がその一例を示しています。

判定者の説明は、その答えが犯した間違いの種類を明示しています。この間違いは、レポートがリスクを挙げていない場合に何をすべきかを一切指示していない抽出プロンプトに起因しています。

判定者を信頼する前に、サンプルを手作業で採点する

判定者は30件すべての答えでコードと一致しましたが、それらはそもそもコードでもチェックできるものでした。判定者の本当の仕事は、コードが手伝えない自由形式のテキストを採点することです。その仕事を任せる前に、信頼できるかどうかをテストしましょう。 2つのプラクティスが役立ちます。

1. サンプルを自分で採点する。 保存した答えをいくつか手作業で採点し、自分の採点と判定者の判定を比較しましょう。判定者は人間の専門家と高い一致を示すべきだからです。あなたと判定者の意見が食い違う場合は、ルーブリックをより明確にして再度実行しましょう。
2. 答えを書いていない判定者を使う。 一般に、出力を書いたものとは異なるモデルで採点するのが最善です。

まとめ

1. 完全一致チェックが機能する場合はコードで、異なる2つの文章がどちらも正しい場合があるときは判定者で、判断に委ねられる場合は人で採点しましょう。
2. モデルを実行する前に期待される答えを書き留め、本番環境に似たケースのセットを構築しましょう。
3. 判定者には、ルーブリック、判定が一致すべきスキーマ、そしてunknownと言える選択肢を与えましょう。
4. 信頼する前に、判定者の仕事のサンプルを手作業で採点しましょう。