MLflow 3.15.2が複数スコアラーのアンサンブルを導入、データセットのイミュータブルなバージョンは現時点でDatabricks限定

MLflow 3.15.2では、複数スコアラーの組み合わせがGenAI評価インターフェースに追加された。新しい実験的API `make_scorer_ensemble`は、複数の単一ターンまたはsession-level scorerを実行し、その後、ブール値、数値、またはカテゴリの結果を1件の`Feedback`に集約できる。組み込み関数には`majority_vote`、`mean`、`minimum`、`maximum`、`agg_all`、`agg_any`があり、カスタム集約関数を渡すこともできる。

これは単に数値の平均を取るだけの機能ではない。インターフェースはまずサブスコアラーの出力型を検証し、たとえばyes／noカテゴリを数値平均で処理することを拒否する。また、単一ターンのスコアラーとsession-level scorerを同じensemble内で混在させることもできない。集約結果のmetadataには、各サブスコアの値、根拠、judgeの出典が保存されるため、安全性、関連性、正確性に関する投票も追跡可能だ。名前付きの組み込み関数を使用した場合、scorerのセット全体を再帰的にシリアライズして登録できる。一方、カスタムcallableでは同じシリアライズのround-tripを実行できない。

もう一つの更新は、イミュータブルなevaluation dataset versionである。評価の実行時に特定のバージョンを解決し、そのバージョン座標を入力レコードに保存できる。これにより、チームが後からテストケースを変更しても、過去のrunで実際に使われたデータを復元できなくなる事態を防げる。これはエージェントの回帰テストにとって重要だ。モデル、プロンプト、judge、データセットが一体としてバージョン管理されていなければ、スコア変動の原因を特定するのは難しい。

ただし、公式の簡潔なリリースノートは、すべてのバックエンドですでにサポートされているという誤解を招きやすい。マージされた実装はDatabricks evaluation datasetsに明確に限定されており、MLflowのドキュメントにも、Databricks以外の環境ではバージョンを指定できないと記載されている。オープンソースバックエンド向けの対応機能は、依然として今後の提案段階にある。さらに、ensemble APIはexperimentalとされており、予告なく変更される可能性がある。公式に開示されているのは3件のデータを使った手動のend-to-endテストのみで、複数のjudgeによって生じるレイテンシ、tokenコスト、評価の安定性は測定されていない。エンジニアリングチームはアップグレード後、まずAPI、データバックエンド、tie-breakingの挙動を固定したうえで、CIゲートに組み込むべきだ。