技術的サマリー：評価工学への道：実環境における機械学習評価ハarnessの実証研究

1. 問題提起

機械学習（ML）の評価は AI の進展を支える基盤であるが、これらの評価を実行するソフトウェアインフラ、すなわち評価ハarnessは、ソフトウェア工学（SE）の観点からは限定的な注目しか集めていない。既存の文献は「何を」評価するか（指標、ベンチマーク、能力）に焦点を当てているが、ハarness自体を、固有の運用ワークフロー、失敗モード、設計上のトレードオフを持つエンジニアリングされたソフトウェア製品としてではなく、透過的なツールとして扱っている。

このギャップにより、評価を実用化する際に生じる SE 上の課題、すなわちハarness設計、依存関係管理、スコアリングの正確性、結果の完全性を含む**評価工学（EvalEng）**に関する理解が欠如している。この理解が欠如しているため、ML 評価の信頼性は、ベンチマーク汚染、再現性の欠如、複雑なインフラにおいて検出が困難なサイレントなスコアリングエラーなどの問題によって損なわれている。

2. 手法

著者らは、2026 年 1 月 6 日までに収集された 57 のオープンソース評価ハarnessと 19,638 件の GitHub イシュー（バグレポート、機能リクエスト、利用に関する質問）を対象とした大規模な実証研究を実施した。本研究は 4 段階の手法を採用した。

1. ハarnessの収集: 研究者らは、キュレーションされたソース（例：Awesome Production ML List）から 57 のハarnessを特定し、キーワードベースの GitHub 検索を通じてカバレッジを拡大した。採用基準には、明示的な評価/ベンチマーク機能、モデルの呼び出し、そして活発なメンテナンス（500 以上のスター、過去 12 ヶ月での活動）が含まれていた。
2. ワークフローの抽出: ドキュメントとローカル実行に対する反復的なオープンカードソーティングと定常比較を用いて、階層的なワークフローモデルを導出した。このプロセスは 51 番目のハarnessで理論的飽和に達した。
3. イシューのマイニング: チームは 57 のハarness（59 のリポジトリにまたがる）から 19,638 件のイシューを取得した。
4. 分類: ハイブリッドアプローチにより、手動アノテーションと大規模言語モデル（LLM）による分類を組み合わせた。
   • 手動アノテーション: ワークフロー段階と根本原因のための分類体系を確立するため、統計的に有意な 377 件のイシューのサンプルを 2 名の著者が手動でラベル付けした。評価者間信頼性は高かった（Cohen's $\kappa > 0.87$）。
   • LLM の較正: Claude Haiku 4.5 ベースの分類器を人間のコンセンサスラベルに対して較正し、全コーパスに適用して、イシューをワークフロー段階と根本原因のカテゴリにマッピングした。

3. 主要な貢献

本論文は、以下の 4 つの主要な貢献を通じて EvalEng の実証的基盤を確立する。

1. 統合ワークフローモデル: ML 評価の運用ライフサイクルを記述する 5 段階、9 ステップ、34 戦略のモデル（プロビジョニング $\to$ 仕様定義 $\to$ 実行 $\to$ 評価 $\to$ 報告）。
2. 実証的イシューマッピング: 57 のハarness全体にわたる 16,560 件のワークフロー関連 GitHub イシューの分類により、運用上の摩擦が発生する箇所を特定した。
3. 根本原因の分類体系: ソフトウェア欠陥（例：アルゴリズム的エラー）と機能ギャップ（例：実装されていない機能）を区別する、運用上の課題に関する 10 分類の分類体系。
4. 採用ギャップの特定: 不確実性の定量化や回帰アラートなど、生産指向の能力における顕著なギャップを明らかにする分析。

4. 主要な結果

RQ1: 運用ワークフロー

本研究は以下の 5 段階のワークフローを特定した。

• プロビジョニング: 環境設定と認証情報の構成。
• 仕様定義: 入力（モデル、データセット）とスコアリングジャッジの定義。
• 実行: テスト対象システム（SUT）の実行。
• 評価: 指標の計算とスコアの集約。
• 報告: 結果の可視化と回帰に関するアラート。

知見:

• オフラインの支配: ほとんどのハarness（標準化された LLM スイートで 40.4%、狭域ドメインライブラリで 21.1%）は、静的なオフラインワークフローに制限されている。5 つの段階すべてを網羅するのは 17.5%（フルスタック LLM プラットフォーム）のみである。
• 戦略のギャップ: インストール（git clone、Python パッケージ）はほぼ普遍的であるが、コンテナ化されたデプロイは稀である（21.1%）。生産トラフィックのサンプリングはハarnessの 7.0% によってのみサポートされている。
• 報告の欠如: 報告は最もサポートが乏しい段階である。ハarnessの 22.8% だけが不確実性を定量化し、8.8% だけが回帰アラートを提供している。

RQ2: 運用上の課題の根本原因

本研究は 16,560 件のイシューを 10 の根本原因に分類した。上位 3 つの原因は全イシューの**61.7%**を占める。

1. 未実装機能ギャップ（24.3%）: 必要な機能が欠落している。
2. ドキュメントの不足（20.3%）: 指示が欠落しているか、古くなっている。
3. 検証ギャップ（17.2%）: 入力/出力検証が欠落している。

アーキタイプ固有のパターン:

• 標準化された LLM スイート: イシューの数が多く、二次的な根本原因は、変化するアップストリームデータセットへの依存による外部依存関係の破綻（8.9%）である。
• タスク固有のプローブ: 二次的な根本原因は、ドメインに特化したスコアリングに参照実装が欠如しているため、アルゴリズム的エラー（11.9%）である。
• フルスタックプラットフォーム: 二次的な根本原因は、複雑なマルチコンポーネント統合によるインターフェース契約の不一致（10.6%）である。
• 狭域ドメインライブラリ: ドキュメントの不足（31.8%）が主要な根本原因であり、機能ギャップを上回っている。

RQ3: 段階全体にわたる根本原因の分布

根本原因は均等に分布しているわけではなく、特定の段階に集中している。

• プロビジョニング: 環境の互換性問題（16.1%）と外部依存関係の破綻（20.1%）が支配的。
• 仕様定義: 未実装機能ギャップ（32.8%）とドキュメントの不足（27.1%）に集中。
• 評価: アルゴリズム的エラー（25.9%）と検証ギャップ（22.5%）が支配的。
• 横断的: 検証ギャップは 5 つのすべての段階で 10% 以上出現する唯一の根本原因であり、より良い意味論的検証の体系的な必要性を示している。

ワークフローのシフト: 課題は、初期段階では環境関連の問題から、後期段階ではスコアリング関連の問題へと移行する。

5. 意義と示唆

本論文は、評価の信頼性が指標設計を超えて注意を要する固有のソフトウェア工学上の課題であると主張する。

• 開発者向け:

  • シーマ検証を超えて意味論的 API 契約に移行し、サイレントな失敗（例：型は正しいが意味が誤っている場合など）を防止する。
  • ハarnessの出力には独立した正解ラベルが欠如することが多いため、スコアリングパイプラインに対してオラクル非依存の検証（メタモルフィックテスト、差分テストなど）を実装する。
  • アーキタイプ固有の失敗モードに合わせたメンテナンスを行う（例：ベンチマークスイートでは依存関係を固定し、フルスタックプラットフォームでは契約テストを行う）。
  • ワークフローのカバレッジ、依存関係、既知の課題パターンを宣言する機械可読の仕様ドキュメント（モデルカードに類似）をリリースする。

• ユーザー向け:

  • 設計されたベンチマーク構成から逸脱する場合など、独立した検証なしにハarnessの出力を正解ラベルとして扱わないこと。
  • ほとんどのハ Harness が不確実性の定量化を欠いているため、真の能力ギャップとハHarnessのアーティファクトを区別することが困難であることを認識すること。

• 研究者向け:

  • 評価工学を SE 研究課題として扱うこと。既存の MLOps およびテストフレームワークは、評価ハHarnessの固有の制約（プロンプトの感度、変化するベースライン、静的対生産トラフィック分布のシフトなど）を処理するために構造的な適応を必要とする。
  • ベースラインが安定していない環境において、回帰閾値と統計的有意性をどのように定義するかを調査すること。

本研究は、評価の信頼性を向上させるためには、指標やベンチマークの個別の改善ではなく、すべての段階におけるワークフロー設計への包括的なアプローチが必要であると結論づけている。提供されたワークフローモデルと根本原因の分類体系は、評価インフラの成熟を追跡するための縦断的研究の基準となる。