2つのMMLUスコア：ベンチマーク名が固定しないもの

MMLUスコアの二重性：ベンチマーク名が解決しない問題

日付: 2026年9月6日 · 著者: Dmitrii Zatona · 更新: 2026年9月29日

---

TL;DR

• 2つのMMLU精度スコア（0.781と0.79）が、2つの代表的なフィクスチャレコードで1つのベンチマーク名の下に存在します。score-deltaクエリに対して、検証ツールはincomparable（比較不能）を返します（セクション1および5）。
• mmluは名前を固定しますが、分割、実装、プロンプト形式、採点者、ネットワークアクセスは未定義のままであり、公表されている測定値ではこれらの要因が精度を数パーセント単位で変動させることが示されています（セクション2）。
• 2023年6月の比較におけるllama-65bの3つのスコアは、完全なフレームとして記述できません。なぜなら、それらの一次ソースがモデルリビジョンを明記していないため、ここでのフレームはフィクスチャです（セクション2）。
• 結果の比較可能性は、それが追跡可能な参照の性質であり、共有されたベンチマークラベルだけではその参照を提供できません（セクション3）。
• APL AI-Evalプロファイルの下では、主張はそのフレームのハッシュを運び、スコープは正規バイトで比較されるため、subset: "all"と省略されたキーは異なります（セクション4）。
• apl-validは構造のみを記述します。スコアのいずれかが正しいこと、同一の識別子が同一の実行を指すこと、または語彙が安定して維持されることを示しません（セクション6）。

同じテーブルに2つの評価レコードが表示されます。1つはビルド42のmmlu精度0.781を報告し、もう1つはビルド44の0.79を報告します。これらの主張は、同じプロバイダー、モデルファミリー、メトリック識別子、単位、およびベンチマーク名を宣言しています。算術的な差は+0.009です。両方のレコードは構造的に有効であり、それらのフレームは異なるランナー、採点者、およびデータセット分割を宣言しています。共有されているmmluラベルは、測定手順ではなく、データセットファミリーを指します。

この記事では、mmluラベルが未定義のままにしていることと、それらの条件がハッシュ化されたフレームに書き込まれた後にapl-ai-evalクレートの検証ツールが出力するものとを分解して分析します。以下のすべてのフレームと主張は、クレートのテストベクトルからコピーされたものであり、acme-gpt-7bはいかなる実際のモデルも指さず、数値のいずれも評価実行から得られたものではありません。検証ツールの出力は、それらのベクトルに対してクレートの公開検証関数を実行することによって記録されました。

私はAPLとそのapl-ai-evalクレートを開発・保守しており、その出力はセクション5に掲載されています。セクション2と3で説明するmmluが未定義のままにしていることに関する説明は、公表されている情報源に基づいており、その作業とは独立しています。

1. 2つの数値が示すもの

ワイヤー上にある主張Aは、ログエントリのmetadata.apl位置で次のように表示されます。

{"apl":{"version":"0.1","claim":{"kind":"observation","subject":{"type":"model-build","id":"model:acme-gpt-7b-build-42","build_id":"42","artifact_digest":"sha256:4242424242424242424242424242424242424242424242424242424242424242","provider":"acme","model_family":"acme-gpt-7b"},"aspect_refs":["accuracy"],"statement":{"predicate":"score","content":{"benchmark_id":"mmlu","metric_id":"accuracy","value":0.781,"unit":"fraction"}}},"frame_ref":{"hash":"sha256:c7b88426f2676f3653db0fad0bdbd689318f16d589d14a315bdd4cc454bca1ab"}}}

主張Bは、2つのビルド後です。

{"apl":{"version":"0.1","claim":{"kind":"observation","subject":{"type":"model-build","id":"model:acme-gpt-7b-build-44","build_id":"44","artifact_digest":"sha256:4444444444444444444444444444444444444444444444444444444444444444","provider":"acme","model_family":"acme-gpt-7b"},"aspect_refs":["accuracy"],"statement":{"predicate":"score","content":{"benchmark_id":"mmlu","metric_id":"accuracy","value":0.79,"unit":"fraction"}}},"frame_ref":{"hash":"sha256:c93a9c55422ddbd2158a5336caa3a251641cf3937f451fb13387a5f54f0d998e"}}}

サブジェクトが異なりますが、それがポイントです：1つのファミリーの2つのビルドです。各主張はartifact_digestを宣言しており、プロファイルはこの評価対象アーティファクトの不変の識別子アンカーとして扱います。ステートメントは形状と語彙において同一です：述語score、ベンチマークmmlu、メトリックaccuracy、単位fraction。主張Bは値を0.79として書き込んでおり、プレゼンテーションではそのJSON値を0.790として表示する場合があります。RFC 8785の正規数値シリアライゼーションの下では、末尾のゼロは値を変えません。

主張レベルのポインターは異なります：frame_ref.hashは一方のレコードではc7b88426…、もう一方ではc93a9c55…です。2つのフレームを解決すると、手順とスコープの両方に違いが見られます。ハッシュは主張レベルでの完全なシグナルです。

このペアに対して期待される関係もオブジェクトです。

{"left_aspects":["accuracy"],"right_aspects":["accuracy"],"predicate":"score","relation_type":"score-delta"}

score-deltaは減算のリクエストであり、セクション2と3で検討する条件の下でのみ回答があります。

2. 「MMLU」が解決しないこと

benchmark_id: mmluは名前を固定します。5つのことを未定義のままにし、公表されている記録はそれぞれの価値を示しています。

2.1 分割

MMLUの論文は、15,908の質問を、57のサブジェクトにわたる各サブジェクト5つのfew-shot開発セット、1,540の検証セット、および14,079のテストセットに分割しています（Hendrycks et al., arXiv:2009.03300, §3）。lm-evaluation-harnessがロードするHugging Faceデータセットcais/mmluのconfig allは、テスト14,042、検証1,531、開発（dev）285を報告しています（cais/mmlu）。hendrycks/testのREADMEからリンクされているデータアーカイブ（2026年9月29日に取得）は、57のサブジェクトにわたって同じカウントを保持しています：私のCSV行のカウントによると、テスト14,042、検証1,531、開発285の質問です。「MMLUテストセット」は、論文では14,079の質問ですが、ここで確認したすべてのデータコピーでは14,042であり、レビューされたどのドキュメントもその違いを説明していません。

フレームAは、論文が固定few-shot例のソースとして定義している285の質問であるdevでスコアリングします（§4.1）。したがって、それに対するスコアリングは選択であり、フレームが可視化すべき選択の種類です。フレームBはtest-liteでスコアリングします。これはクレート自身のテストベクトルで縮小セットに使用されるラベルです。2026年9月29日にHugging FaceデータセットとモデルAPI、およびGitHub検索を確認したところ、その名前で公開されているMMLUのサブセットまたは分割は見つかりませんでした。また、tinyMMLUでもありません。このラベルは、プライベートなスライスが使用されたことを読者に伝えます。しかし、どの質問が使用されたかは伝えていません。

2.2 実装

実装のばらつきに関する公表された測定値の1つは、2023年6月のHugging FaceのOpen LLM Leaderboardに関する投稿です。3つのハーネス（HELM、Eleutherハーネス、および元のコード）が同じデータセット（すべて5-shot）を実行し、llama-65bを0.637、0.488、0.636でスコアリングします。falcon-40bは0.571、0.527、0.558です。その著者は、ラベルだけでは、他のライブラリの結果と比較してそれらの数値がどうなるかについて「ほとんど情報を提供しない」と結論付けています（What’s going on with the Open LLM Leaderboard?）。メカニズムはスコアリングです。元のコードは4つの回答文字の確率を比較します。HELMは次のトークン出力を生成し、期待されるテキストと比較します。ハーネスはオプションテキストを含む完全な回答シーケンスをスコアリングします。ランク順はそれに伴って移動します：ハーネスの下ではfalcon-40bはllama-65bの上に位置し、他の2つの下では下に位置します。

これらの3つのllama-65bスコアは、それらのフレームが一次ソースから完成できれば、フィクスチャよりも良い例になるでしょう。しかし、それはできません。Hugging Faceの記事は、ハーネスをコミットe46788cに、HELMをコミットcab5d89にピン留めしており、ほとんどの手順はそれらのコミットのコードから読み取ることができます。モデルは「llama-65b」としか名前がなく、リポジトリやリビジョンはありません。また、3つの実行のいずれについても評価された分割を明記していません。元の実装スコアは、BerkeleyコードのHugging Faceポート、pull request 13 on hendrycks/test（2026年9月29日現在も未マージ）を通じて行われましたが、Hugging Faceのテキストはそのブランチのどのコミットが実行されたかを述べていません。3つのいずれかのフレームには、未記入のモデルフィールドが含まれることになります。これが、この記事のフレームがクレートのテストベクトルからのフィクスチャである理由です。

ランナーも1つのオブジェクトではありません。lm-evaluation-harnessのMMLU README（コミットb954108c）は、mmlu、mmlu_continuation（クローズスタイル）、およびmmlu_generative（モデルが回答文字を生成する）を、同じデータに対する3つのタスクとして、それぞれ独自のタスクバージョンとともに説明しています。そのタスクガイドは、YAML設定とコードベースのコミットハッシュを、他の研究者が必要とする再現可能なセットアップの単位として扱います。num_fewshotはデフォルトで0であり、MMLU YAMLは何も設定していません。したがって、「5-shot MMLU」はコマンドラインフラグであり、タスクのプロパティではありません。ハーネスREADMEのバージョン0.3.0ではユーザーに各タスクのバージョンを報告するように求めていましたが、b954108cではそのような要求はありません。

2.3 プロンプト形式

Anthropicの2023年の評価に関する説明によると、フォーマットのみ（オプションラベル、括弧、オプションと回答の間の余分なスペース）でMMLUの精度が約5%変動する可能性があります（Challenges in evaluating AI systems）。回答の位置はさらに変動します。Zhengらによると、MMLUでは、正解をDの位置に移動させるとgpt-3.5-turboの精度が67.2から60.9に低下し、Aに移動させるとllama-30bが15.2ポイント上昇して68.2になり、gpt-3.5-turboの65.3と比較して元の53.1対67.2を逆転させます（arXiv:2309.03882）。

ここでの両方のフレームはprompt_protocol: zero-shot-mcq-v1を宣言しているため、この変数は保持されています。保持されている変数は、書き留められて初めて可視的に保持されます。

2.4 採点者

フレームAはexact-match-v1で採点します。フレームBはllm-judge-v3で採点します。これらは1つの関数の2つの実装ではありません。Zhengらは、ジャッジモデルが「強い位置バイアスを示す」こと、GPT-4のみが60%以上のケースで一貫性を保ったこと（GPT-3.5では46.2%、Claude-v1では23.8%に対し65.0%）、そして2つの回答が位置を入れ替えたときに反転するジャッジメントを記述しています（arXiv:2306.05685, Table 2）。同じ論文では、GPT-4と人間の合意率を85%とし、人間同士の合意率を81%としています。llm-judge-v3は、異なる文書化された失敗モードを持つ、異なる採点手順です。

2.5 ランナーが到達しうるもの

もう1つの変数は、ランナーが触れることを許可された環境です。CAISIは、他の評価者がインターネットアクセスなしで実行していた間、自身はインターネットアクセスありでSWE-bench Verifiedを実行していたことを後から発見したと公表しました。そして、ベンチマークのドキュメントからではなく、他の評価者が投稿したトランスクリプトからそれを学んだと述べています（Cheating on AI Agent Evaluations, Section 4, November 2025）。コーディング評価のための新しいポリシーは「完全にオフライン」です。静的ベンチマークにとっても到達可能性は重要です。Scaleの検索時汚染作業は、3つのベンチマークの約3%の質問がHugging Faceからラベル付きで取得可能であり、そのソースをブロックすると汚染されたサブセットの精度が約15%低下することを発見しました（Search-Time Data Contamination）。

同じ機関による自社結果と自己報告結果の比較は、1つのヘッドライン数値がどれだけの環境変数を吸収するかを示しています。SWE-bench Verifiedについて、63.0対自己報告の74.9（1モデルあたり）で、違いの可能な原因として、データセットの違い、エージェント設定、および温度やtop_pなどのAPIサンプリングパラメータを挙げています（CAISI Evaluation of DeepSeek AI Models, Appendix A8）。

これらはどれも珍しいことではありません。2026年の635のベンチマークにおける5,816モデルの報告された結果の調査によると、50,461の（モデル、ベンチマーク、メトリックパス）トリプルのうち48,698（96.5%）は、最小再現性サブスキーマの少なくとも1つのフィールドを欠いており、温度はそれらのトリプルの93.9%に欠落しており、MMLU-ProでHugging Faceによって20.9%のスコア、別の評価者によって61.8%で報告されたモデルが1つ記録されています（Evaluation Cards, arXiv:2606.09809）。この調査は、大規模な報告の不備を文書化していますが、この正確な違いの組み合わせがどれほど頻繁に発生するかは述べていません。

3. 比較可能性は参照に属する

VIM（国際計量学用語集）（JCGM 200:2012, §2.46）は、共通の参照へのトレーサビリティを通じて計量学的比較可能性を定義しています。与えられた種類の量の結果は、「同じ参照に計量学的にトレーサブル」である場合に比較可能です。その§2.41の注記は、非順序量の参照として測定手順が役立つことを許可しています。AI-Evalプロファイルは、それをより狭い運用規則に変換します。異なるフレームの下での2つの結果は、ブリッジ、つまり2つのフレームを名前付けし、それらを比較する際の仮定と損失を述べる別のコンテンツアドレス可能なオブジェクトを通じてのみ比較できます。そして、ブリッジはフレームがその正確な側面、スコープ、および手順の制約を満たす場合にのみ適用可能です。mmluだけではそれらを満たしません。

計量学的適合性（§2.47）は別のVIM用語です。それは、2つの結果の差がその差の不確かさに比べて小さいかどうかに関係します。それは、2つの結果が参照を共有することを確認しません。

AI以外の分野はすでにこれに費用を払っています。HbA1cは2つの標準化システム、IFCCとNGSPで報告されており、NGSPはIFCCの結果をHbA1cで1.5〜2%低く報告しています（NGSP）。2007年にはIFCC値に独自の単位（mmol/mol）が付与され、NGSPは2つのシステム間の混乱を避けると述べています。クラウドの可用性も同様の形状をしています。AWS EC2は、外部接続の喪失を定義とする無稼働時間（minutes of Unavailability）から月間稼働率（Monthly Uptime Percentage）を導き出します（AWS EC2 SLA）。一方、Google Computeは永続ディスクアクセスの喪失をダウンタイム（Downtime）としてカウントし、1分未満の断続的なダウンタイムはカウントしません（Google Compute Engine SLA）。2つの契約は、異なる測定対象に対して「99.99%」を印刷しています。

AI固有の文書は、計量学の言葉を使わずに同じ声明に到達します。NISTの自動ベンチマーク評価のための実践の草案は、比較可能性をシステム間のプロトコルの整合性（§2.1）に結びつけ、セマンティックバージョニングの下での破壊的変更を、それ以降の結果が適切に比較できなくなる時点として説明しています（NIST AI 800-2 ipd, January 2026）。実践2.3は、比較を意図した評価ログをグループ化することを新興の実践として挙げており、実践3.2は、評価詳細を共有するための相互運用可能なスキーマが再現を容易にする可能性があると述べています。

国際先進AI測定・評価・科学ネットワークは、2026年7月のベストプラクティス（Best Practice: Automated Evaluation of Large Language Models, §C.1.1）で、比較可能性を2つに分割しています。出力の評価は、スコアリング基準、ルーブリック、採点者をカバーし、常に比較可能であるべきです。出力の生成は、プロンプト形式と推論設定をカバーし、その標準化の厳密さは評価の目標に依存します。これらの用語では、grader_idは出力の評価に属し、prompt_protocolはそれらの生成に属します。2つのフレームはprompt_protocolを固定し、grader_idとrunner_id、およびスコープで異なります。以前のこの記事では、1行で一般的な形式を示しました。「accuracy 0.78」をフレームレコードなしで記録することは、観察ではなく数値です。2つのMMLUスコアは、ハッシュが埋め込まれたその行の特定のケースです。

4. 数値とそのフレームの結びつけ

APLの下では、フレームは主張に添付されたドキュメントではなく、独立したコンテンツアドレス可能なオブジェクトであり、主張はハッシュのみを運びます。AI-Evalプロファイル、つまりモデルビルドに関するベンチマーク観察のための語彙は、そのオブジェクトが何を内容とする必要があるかを固定します。フレームAを読みやすくするためにインデントします。

{
  "version": "0.1",
  "observer": { "id": "acme-eval-lab" },
  "procedure": {
    "runner_id": "lm-eval-harness@0.4.2",
    "grader_id": "exact-match-v1",
    "prompt_protocol": "zero-shot-mcq-v1"
  },
  "aspect": ["accuracy"],
  "scope": {
    "benchmark_id": "mmlu",
    "benchmark_variant": "default",
    "dataset_split": "dev",
    "subset": "all"
  },
  "invariance": ["score-object-serialization"],
  "exclusions": [
    "no-production-readiness-claim",
    "no-deployment-safety-claim",
    "no-out-of-scope-generalization-claim"
  ]
}

そのハッシュはsha256:c7b88426f2676f3653db0fad0bdbd689318f16d589d14a315bdd4cc454bca1abであり、上記のインデントは表示用です。ハッシュはRFC 8785正規バイト（ src/core/jcs.rs:167, canonical_hash）のSHA-256であり、したがって空白はダイジェストに到達しません。フレームBは、runner_idがcustom-runner@2.1、grader_idがllm-judge-v3、dataset_splitがtest-liteであり、subsetキーがない同じオブジェクトであり、sha256:c93a9c55422ddbd2158a5336caa3a251641cf3937f451fb13387a5f54f0d998eをハッシュします。

コミットe46788cのプロファイル検証ツールは、それらのフィールドを規約から要件に変換します。frame.rsの4つのチェックで行われます。procedureは、空でないrunner_idとgrader_idを持つオブジェクトである必要があります。scopeは benchmark_id、benchmark_variant、およびdataset_splitを運ぶ必要があります。aspectは閉じたリストから正確に1つのエントリを保持する必要があります。exclusionsは3つのマーカーすべてを含む必要があります。これは、フレームが何の証拠ではないかをどのように述べるかです。マーカーは固定文字列です。なぜなら、文章の値には制御された語彙がないからです。「デプロイメントの安全性に関する主張なし」とno-deployment-safety-claimは、異なるバイトで同じことを言いますが、チェックが適用する正確な等価性を満たすことができるのは後者だけです。

主張側はclaim.rsにあります。そこでcontent.benchmark_idは必須であり、 frame.scope.benchmark_idと等しくなければなりません。そしてcontent.metric_idは必須であり、アスペクトによって制約されます：accuracyはaccuracy、exact-match、またはf1を許可します（claim.rs:315）。

2つのフレームの中に、より微妙なケースがあります。フレームAはsubset: "all"と書き込みます。フレームBはそのキーを省略します。読者は、比較がそれを正規化し、省略されたオプションフィールドがデフォルト値を表すことを期待するかもしれません。しかし、そうはなりません。コミットe46788cでは、検証ツールは正規バイトでスコープの等価性を決定します。ブリッジチェックは2つのスコープを比較します（canonical_equal、src/core/jcs.rs:84–87でcanonical_bytes(a) == canonical_bytes(b)として実装されています）。したがって、空白はダイジェストに到達しません。このルールでは、検証ツールは"all"と省略されたキーを2つのスコープとして扱います。デフォルト設定は、ハッシュが取得される前に、フレームを発行するツールで行う必要があります。

5. 検証ツールが示すこと

apl-ai-evalはRustクレートで、バージョン1.0.0、ライセンスはApache-2.0です。主張または主張のペアとリレーションクエリが与えられると、主張がプロファイルの下で適切にフォーマットされているか、およびリレーションが評価可能かどうかを決定します。この記事のケースは、テストベクトル内のtwo_mmlu_scores_incomparable_with_ai_eval_profileとして存在し、ペアはtest_data/vectors/pairwise/incomparable-no-bridge.jsonにあり、2つの兄弟ベクトルファイルにはブリッジケースが含まれています。cargo test -p apl-ai-evalは109の単体テスト、3のベクトル統合テスト、および2のドキュメントテストを実行します。それらすべて114はグリーンです。

主張AをAI-Evalプロファイルに対して単独で検証すると、次のようになります。

{"core_outcome":"apl-valid","relation_outcome":"relation-not-evaluated","failure_classes":[],"diagnostics":["carrier-valid","apl-present","apl-frame-bound","apl-valid","same-frame","transformation-missing"]}

この出力と以下の3つは、apl-core e46788cの検証ツールの実際の出力とバイトごとに比較されます。これはzatona-blog-code/the-two-mmlu-scoresにあります。各印刷ブロックにつき1つのテストです：主張Aのみ、主張Bのみ、ブリッジなしのペア、敵対的なブリッジ、および適用可能なブリッジ。1回の完全な実行の生の出力はlogs/run.logです。

主張Bのみも同じ形状を生成します。ここでのapl-validは、適切にフォーマットされ、フレームに束縛されていることを意味し、0.781の精度については何も述べていません。relation-not-evaluatedは、尋ねられなかった質問への回答です。

次に、セクション1のscore-deltaクエリを使用し、ブリッジなしのペアです。

{"left":{"core_outcome":"apl-valid","failure_classes":[]},"right":{"core_outcome":"apl-valid","failure_classes":[]},"relation_outcome":"incomparable","diagnostics":["apl-cross-frame","apl-bridge-not-found"]}

両方の主張はcore_outcome: "apl-valid"と空の失敗クラスを持ちます。リレーションの成果はincomparableです。apl-cross-frameは、2つのframe_refハッシュが異なることを示します。apl-bridge-not-foundは、その違いを横断する比較を許可するものが提供されなかったことを示します。2つの軸は設計上分離されています。これは壊れたレコードでも、通過する比較でもありません。定義された結果のない減算であり、そのように報告されます。

3番目のベクトルは、上記のフレームAとBの間のブリッジではなく、個別の敵対的なケースです。そのソースフレームはアスペクトaccuracyを宣言し、ターゲットフレームはアスペクトjudge-scoreを宣言します。ブリッジ自体はコンテンツアドレス可能なオブジェクトであり、これは適切にフォーマットされています。

{"version":"0.1","bridge_kind":"runner-equivalence","source_frame":{"hash":"<FRAME_HASH:0>"},"target_frame":{"hash":"<FRAME_HASH:1>"},"comparison_scope":{"source_aspects":["accuracy"],"target_aspects":["judge-score"],"relation_type":"score-delta"},"assumptions":["all MMLU results are interchangeable"],"losses":[]}

<FRAME_HASH:n>トークンは記録されたベクトル内のプレースホルダーです。ハーネスはロード時に2つのフレームハッシュを代入します。ブリッジは解析され、正しい2つのフレームを指し、空のlosses配列を宣言し、その仮定を平文で述べます。検証ツールは次のように応答します。

{"left":{"core_outcome":"apl-valid","failure_classes":[]},"right":{"core_outcome":"apl-valid","failure_classes":[]},"relation_outcome":"incomparable","diagnostics":["apl-cross-frame","apl-ai-eval-bridge-aspect-family-mismatch"]}

報告された診断はapl-ai-eval-bridge-aspect-family-mismatchです。ブリッジのcomparison_scopeは、ソース側でaccuracy、ターゲット側でjudge-scoreを宣言しており、2つのフレームと一致します。プロファイルの下では、ブリッジは1つのアスペクトファミリー内の条件間で変換でき、異なるアスペクトを測定するフレームを結合することはできません。

4番目のベクトルは機能するブリッジです。両側で同じ採点者exact-match-v1、同じスコープmmlu / default / dev / all、runner_idのみが異なります。

{"left":{"core_outcome":"apl-valid","failure_classes":[]},"right":{"core_outcome":"apl-valid","failure_classes":[]},"relation_outcome":"bridged-comparable","diagnostics":["apl-cross-frame","apl-bridge-applicable"]}

bridged-comparableは、フレームが異なり、適用可能なブリッジ（その述べられた仮定と損失とともに）が提供されたことを示します。

コードはrepeatabilityブリッジをrepeatability-checkリレーションタイプにピン留めしているため、score-deltaを許可しません。これは、apl-ai-eval-bridge-relation-type-invalid（bridge.rs:167–175）で拒否し、runner-およびgrader-equivalenceブリッジをscore-deltaに限定します。手順の再現性は、それの下で測定された2つのサブジェクト間の違いについては何も述べていません。

フォーマットされていないレコードは別の軸にあります。サブジェクトにtypeとartifact_digestがない主張で、procedureとscopeがオブジェクトではなく文字列であり、除外が不完全なフレームにバインドされている場合、apl-invalid、failure_classes: ["claim-structure-failure"]、診断apl-subject-invalidが返されます。無効は、レコードが適切にフォーマットされた観察ではないことを意味します。比較不能は、2つの適切にフォーマットされた観察を減算できないことを意味します。

クレートはapl-protocol.org/implementations/apl-ai-evalにあります。ソース、ベクトル、および上記で引用された3つのペアワイズJSONファイルは、github.com/evidentum-io/apl-core/tree/e46788c/apl-ai-evalにあります。

6. これが証明しないこと

フレームは狭い質問を解決し、残りは未定義のままにします。

• どちらかのスコアが正しいこと。 apl-validは構造に関する声明です。MMLU-Reduxは5,700の質問を再注釈付けし、「MMLUの質問の6.49%にエラーが含まれている」と推定しています（arXiv:2406.04127）。フレームは数値を宣言された条件に結び付けますが、それらの条件が宣言通りに実行されたことを確立しません。
• 2つの同一の識別子が同じものを指すこと。 バイト等価性は、custom-runner@2.1がcustom-runner@2.1と等しいことを知っています。しかし、2つの実行がコミット、アクセラレータ、トークナイザービルド、またはサンプリングデフォルトを共有したかどうかは知りません。フレームは信頼の境界を識別子を発行する者に移動させますが、それを取り除くことはありません。
• データセットが同じデータセットであったこと。 フレームは名前と分割でデータを識別し、ダイジェストではありません。セクション2.1の14,079対14,042のギャップ（1つの名前が論文のカウントとデータのカウントをカバーしている）は、以前の記事が設定した条件を満たします。同じ名前の下でデータセットが変更される可能性がある場合、ダイジェストはフレームに含まれるべきです。ここでのどちらのフレームもそれを持っていません。
• 閾値、またはそれらが設定された時期に関するもの。 フレームは手順を記録し、リリース閾値やその選択時期を記録しません。NISTの実践1.2は、評価を実施する前に評価が何を測定するかを文書化することに対処しています。
• 不確実性に関するもの。 コミットe46788cでは、検証ツールはオプションのsample_countを受け入れ、不確実性フィールドをチェックしません。どちらの主張もsample_countを記録していません。例として、285の独立した項目から推定された割合は、14,042の項目から推定された割合よりも広い二項区間を持ちます。その比較は、表示されている各主張の不確実性を確立しません。ISO/IEC 17025:2017, 7.8.3.1 c)は、関連する場合に測定不確実性を報告することを求めていますが、ここでの主張はそれを満たす可能性のあるものを何も運んでいません。
• 分割ラベルが読者の想定する意味を持つこと。 devは実際のMMLU分割であり、論文の設計によれば、そのfew-shot例のソースです。それに対するスコアリングは、フレームが可視化する決定であり、それを擁護しません。test-liteはクレートのテストベクトル内のラベルであり、2026年9月29日現在、公開されているMMLUサブセットまたは分割の名前ではありません。
• 語彙が安定していること。 プロファイルは2026年9月7日にバージョン0.1から1.0に移行し、プロファイルの識別子もそれに伴ってapl/ai-eval/v0.1からapl/ai-eval/v1.0に変更されました。セクション3で述べたように、NISTはこのような変更を比較可能性の断絶と見なします。

フレームが確立するものはより狭いものです。それは、ハッシュによって、述べられた手順を述べられた主張に結び付けます。AI-Eval v1.0の下では、提供されたフレームとこのscore-deltaクエリは、適用可能なブリッジの条件を満たさないため、検証ツールはデルタの代わりにincomparableを返します。私がこのペアから得ることは、検証ツールがここで言う最も有用なことは、計算を拒否した数値であるということです。さらに多くの記事がエンジニアリングブログにあります。

---

もしあなたの評価スコアがチーム、ベンダー、または四半期をまたいで比較され、各比較が質問に耐えなければならない場合、それらをハッシュ化されたフレームに対して記録することは私が請け負う契約作業です。