目次 › 第5章 › 5-3

第5章 評価とモニタリング / 想定学習時間:30〜40分 / 最終確認:2026年8月

5-3. カスタムスコアラーの実装

1. なぜカスタムスコアラーが必要か

5-2で見た組み込みジャッジ(relevance、groundedness など)は汎用的な観点をカバーしますが、実際のアプリにはドメイン固有の品質基準があります。

• 社内用語・製品名を正しい正式名称で使っているか
• 回答に出典URLが含まれているか(根拠の明示が業務要件)
• 指定のJSONスキーマ・フォーマットに従っているか
• 回答の文字数が上限(例:チャットUIの表示制限)以内か
• 医療・金融など、業界特有の禁止表現を含んでいないか

こうした基準は組み込みジャッジには存在しないため、カスタムスコアラーとして自分で定義します。MLflow 3 の統合評価フレームワークでは、スコアラーを普通の Python 関数として書き、組み込みジャッジと同じ仕組みで mlflow.genai.evaluate() に渡せます。開発時の一括評価にも、本番トレースに対するオンライン評価(5-5)にも、同じスコアラーをそのまま使えるのが MLflow 3 の設計です。

2. @scorer デコレータによる実装

カスタムスコアラーは、MLflow 3 の @scorer デコレータ(mlflow.genai.scorers)を付けた Python 関数として実装します。関数は評価ケースごとに呼ばれ、次の引数を(必要なものだけ)受け取れます。

戻り値は数値・bool・Feedback オブジェクトのいずれかです。Feedback を使うと、スコアに加えて判定理由(rationale)を残せます。

from mlflow.genai.scorers import scorer

@scorer
def has_source_url(outputs) -> bool:
    """回答に出典URL(http/https)が含まれているかを判定する"""
    return "http://" in outputs or "https://" in outputs

from mlflow.entities import Feedback
from mlflow.genai.scorers import scorer

@scorer
def answer_length_check(outputs) -> Feedback:
    n = len(outputs)
    return Feedback(
        value=n <= 500,
        rationale=f"回答は{n}文字(上限500文字)",
    )

results = mlflow.genai.evaluate(
    data=eval_data,
    predict_fn=my_rag_app,
    scorers=[Correctness(), has_source_url, answer_length_check],
)

3. 2系統のカスタムスコアラー:ヒューリスティック型とLLM判定型

カスタムスコアラーの中身は、大きく2系統に分かれます。

ヒューリスティック型(コードで判定)

正規表現・完全一致・長さチェック・JSONパースなど、決定的なコードで判定します。

• 長所:高速・無料(LLM呼び出しなし)・完全に再現可能
• 短所:意味の判定はできない(「丁寧な文体か」は正規表現では測れない)
• 例:出典URLの有無、JSONスキーマ準拠、禁止ワードの機械的チェック、文字数制限

LLM判定型(カスタムプロンプトのジャッジ)

組み込みジャッジにない意味的な基準を、独自のプロンプトを与えたLLMジャッジとして実装します。MLflow 3 には2つの経路があります。基準を自然言語の文章で表現できるなら Guidelines スコアラーに基準文(guidelines)を渡すのが最も手軽です(5-2)。合否の2択に収まらない多段階の判定など、より細かく制御したい場合は、カスタムプロンプトからジャッジを作る仕組み(custom prompt judge)で独自ジャッジを定義し、スコアラー関数の中から呼び出して使えます。

• 長所:意味・ニュアンスを判定できる
• 短所:LLM推論コストがかかり、判定に揺らぎが残る
• 例:「社内用語を正式名称で使っているか」「専門家として適切なトーンか」「回答が推奨手順の順序どおりに説明しているか」

4. 評価の再現性:スコアラーとデータセットのバージョン管理

評価は「一度きりの測定」ではなく、変更のたびに繰り返す回帰テストとして運用します。そのとき比較を意味のあるものにするには、再現性が不可欠です。

• 評価データセットのバージョン管理 — 評価ケースを Delta テーブルなどで管理し、いつどのバージョンで評価したかを記録する。データセットが変わればスコアは当然変わるため、「モデルAとモデルBの比較」は同じデータセットバージョンで行う
• スコアラーのバージョン管理 — スコアラーのコード(判定ロジック、ジャッジ用プロンプト)もコードとして管理する。判定基準が変われば過去のスコアと比較できなくなる
• 結果の記録 — mlflow.genai.evaluate() の結果は MLflow Run として残り、どのアプリバージョン・どの評価データに対するスコアかを追跡できる

「先週より品質が上がった」と主張するには、同じ物差し(スコアラー)と同じ試験問題(データセット)で測っている必要がある、と覚えてください。

練習問題