> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aihubmix.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AIHubMix Fidelitas Standard v2.0

> AIHubMix Fidelitas Standard の 4 つの評価次元、総合スコアの計算式、ネイティブ機能とインターフェース互換性の判定、応答速度とキャッシュの測定、問題セットの出典と統計上の範囲について説明します。

AIHubMix Fidelitas は、同一モデルを異なるモデルプロバイダーが提供するサービスで利用した際のパフォーマンスを測定対象とし、タスク結果の正確性、機能の可用性、応答パフォーマンス、初回リクエストの完了状況をそれぞれ評価します。総合スコアと 4 つの次元スコアを併記し、規定のテスト条件で同一モデルのサービスパフォーマンスを比較するために使用します。

本ドキュメントでは **AIHubMix Fidelitas Standard v2.0** を採用し、プロジェクトのバージョンは **AF v2.0** です。メインスコアには、プロバイダーのドキュメントに従って構成した機能サポートとキャッシュの測定結果を使用します。インターフェース互換性とデフォルト構成でのキャッシュ結果は、それぞれ診断指標として報告します。

## スコアリングの範囲と読み方

| 評価項目 | 記号 | 重み | 測定内容 |
| - | - | - | - |
| 回答品質 | Q（Quality） | 35% | ツール呼び出し、知識と推論、長文理解タスクにおける結果の正確性 |
| 機能サポート | F（Functionality） | 25% | ストリーミング、ツール、構造化出力、パラメータ、コンテキスト、エラー応答、使用量計測の機能可用性 |
| 応答速度 | P（Performance） | 20% | 最初の本文応答までの遅延、生成レート、同時実行時の有効スループット、キャッシュの有効ヒット状況 |
| サービス安定性 | R（Reliability） | 20% | 固定リクエストセットが初回実行時に有効に完了した割合 |

**独立した評価対象は「モデルプロバイダー × モデルバージョン」**、すなわち特定のモデルプロバイダーが提供する特定のモデルバージョンのサービスです。各対象は、指定された評価バッチと構成の下で、4 次元のスコアと総合スコアのセットを形成します。

思考モード、リクエストパラメータ、アカウントのサービスティア、テスト地域、観測時間帯は測定条件に該当し、結果とともに記録します。条件が異なる結果にはそれぞれ注記し、直接統合しません。モデルバージョン、地域、サービスティアを検証できない場合は、対応する未検証状態を明記し、確認済みと推定しません。

評価は AIHubMix API を通じて実行し、結果はこの接続方式における実際の観測パフォーマンスを表します。公式リファレンスサービスも AIHubMix API を通じて測定し、公式 API に直接接続した独立の測定結果としては扱いません。

同一の比較グループでは、同じ問題セット、ラウンド、タイムアウト、リクエスト予算、失敗時のスコアリング、統計手法を使用します。プロバイダーのドキュメントが定める必須リクエストフィールド、ストリーミング構造、使用量フィールドは接続アダプタ層（adapter）で処理し、測定対象を揃えます。本手法はモデル間の知的能力のランキングには使用せず、モデルプロバイダーの属性は加点の根拠になりません。

### スコアの状態

| 状態 | 意味 |
| - | - |
| 正式 | 対応する標準に従ってテスト登録、サンプリング、判定、エビデンス検証を完了 |
| 参考結果（PROVISIONAL） | 計算結果を形成できるが、サンプリング、判定、アダプテーション登録、またはエビデンスに適用上の制限がある |
| 利用不可（UNAVAILABLE） | 必要な判定、分母、またはリファレンスが欠けており、数値を付与しない |
| 比較不能 | モデル構成、観測条件、または結果ビューが一致せず、同一基準の比較に含めない |

欠損値と 0 点は区別して処理します。サービスの明確な失敗または必須機能の未提供は、対応する規則に従って失敗として計上します。未測定、分母不明、またはエビデンス不足の場合は、対応する状態を保持します。いずれかの次元が利用できない場合、総合スコアも利用不可とし、その重みを他の次元に再配分しません。

### 結果の解釈

* 元の指標をスコアリング式に従って絶対パフォーマンス A に変換し、相対リファレンスとエビデンスの合成を経て次元合成スコア D を得ます。総合スコアには D を使用し、元の正解率、機能通過率、サービス成功率を直接重み付けすることはありません。
* スコアは特定の問題セット、負荷、地域、構成、観測ウィンドウにおけるパフォーマンスを反映し、適用条件は結果とともに記録します。
* 表示精度は統計的な識別能力を意味しません。回答品質の差はペア統計区間と合わせて解釈し、小数の差のみで優劣を判断することはできません。
* 総合スコアは集約指標であり、認証ではなく、信頼区間も提供しません。統計的な結論は、具体的な次元のエビデンスに基づきます。
* サービス安定性では、初回成功数、計画機会数、両側 95% 区間を併せて報告します。これを長期 SLA として直接解釈することはできません。

再確認により、モデル同一性の不一致、入力の無通知の切り詰め、機密性の高いコンテンツの漏えい、重大なプロトコル破損、または課金異常が確認された場合、結果には「受け入れ基準未達」と個別に表示し、再現用のエビデンスと使用上の制限を保持します。次元スコアと総合スコアはこの制限を相殺しません。

## 総合スコアと次元の合成

### 総合スコアの計算式

総合スコアは、4 つの次元合成スコアの加重計算によって求めます。`D_Q`、`D_F`、`D_P`、`D_R` は、それぞれ回答品質、機能サポート、応答速度、サービス安定性の合成スコアを表します。

```text 総合スコア theme={null}
Overall = 0.35 × D_Q + 0.25 × D_F + 0.20 × D_P + 0.20 × D_R
```

4 つの次元合成スコアはすべて 0–100 点満点とします。総合スコアは全体の結果を要約し、4 つの次元スコアは具体的な差異を識別するために使用します。

### 3 層合成

各次元の合成スコア D は、絶対パフォーマンス A、公式リファレンスに対する相対評価 B、エビデンス完全性 C の加重計算によって求めます。

```text 次元スコア theme={null}
D = 0.65 × A + 0.20 × B + 0.15 × C
```

| 入力層 | 重み | 定義 |
| - | - | - |
| A：絶対パフォーマンス | 65% | 規定のテストと統計手法に従って得られた実際の測定結果 |
| B：公式リファレンスに対する相対評価 | 20% | 同一の次元における絶対パフォーマンスと公式リファレンスサービスとの差 |
| C：エビデンス完全性 | 15% | サンプルカバレッジ、観測の一貫性、計量エビデンスが今回の結果をどの程度支えているか |

A、B、C は計算層の記号であり、接続グレードを表すものではありません。絶対パフォーマンスには規定の式を使用し、当該バッチで最速または最高スコアのサービスを 100 に設定せず、バッチごとの再正規化も行いません。

アンダースコアの前は計算層、後は評価次元を表します。たとえば、`A_F` は絶対パフォーマンス層の機能サポートスコア、`D_F` は 3 層合成後の機能サポートスコアです。

メインスコアと診断値では、次の構成接尾辞も使用します。

| 記号 | 英語名称 | 意味と用途 |
| - | - | - |
| `F_native` | Native Functionality Score | プロバイダーのドキュメントに従って構成・解析したネイティブ機能サポートスコア。メインスコアの `A_F` として使用 |
| `F_strict` | Strict Interface Compatibility Score | AIHubMix のインターフェース規定に直接従って検査した厳格なインターフェース互換性スコア。個別の診断として別掲 |
| `K` | Cache Hit Score | キャッシュ有効ヒットのサブスコア。応答速度の絶対パフォーマンスに算入 |
| `K_native` | Native Cache Hit Score | プロバイダーのドキュメントで要求される構成で測定したキャッシュサブスコア。メインスコアに使用 |
| `K_default` | Default-Configuration Cache Hit Score | セッションアフィニティ構成を一律に付加しない場合に測定したキャッシュサブスコア。個別の診断として別掲 |

`native` はプロバイダーのドキュメントに従った構成、`strict` は厳格なインターフェース検査、`default` は本ドキュメントで定義するデフォルト構成を表します。`K` は本手法のキャッシュ記号であり、Quality を表すものではありません。メインスコアには `F_native` と `K_native` を統一して採用し、診断値とメインスコアは混在させません。

### 公式リファレンスに対する相対評価 B

`A_official` は公式リファレンスサービスの当該次元における絶対パフォーマンススコアを表し、その相対リファレンススコア `B_official` は 50 に固定します。

```text 相対リファレンス層 theme={null}
B_official = 50
B = 50 + 50 × clip((A − A_official) / δ, −1, 1)
```

`clip(x, −1, 1)` はクリップ関数であり、x を −1 から 1 の範囲に制限します。差分スケールパラメータ δ は次元ごとに定義します。

| 次元 | δ |
| - | - |
| 回答品質 Q | 2 |
| 機能サポート F | 15 |
| 応答速度 P | 10 |
| サービス安定性 R | 2 |

回答品質では、5,000 回のペアタスクによるクラスターブートストラップで、公式リファレンスに対する差分区間を推定します。**両側 95% 区間が 0 を含む場合、`B_Q = 50`** とし、区間が 0 を含まない場合は上記の写像に従って計算します。

公式リファレンスサービスは絶対パフォーマンスの測定を独立して受け、その B は 50 に固定し、満点を前提としません。構成、タイムアウト、時間帯、または結果ビューが異なり比較できない場合、相対リファレンス層には推定値を入力しません。

### エビデンス完全性 C

C は次の 5 項目で構成され、各項目の満点は 20 点、合計は 100 点です。各項目は記録上のカバレッジとエビデンスの状況に応じて、20 点、10 点、または 0 点を付与します。

| 項目 | 検証内容 |
| - | - |
| サンプルカバレッジ | 実際の有効記録と計画サンプル数との一致度 |
| ウィンドウカバレッジ | 必要な時間帯または回答品質の収集セグメントの完全性 |
| 使用量の完全性 | 元の `usage` のカバレッジと検証可能性 |
| 分母エビデンス | 問題判定、機能判定、キャッシュ計量の分母の再検証可能性 |
| プロトコルの一貫性 | リクエスト構成、記録の帰属、観測プロトコルの一貫性 |

C は測定エビデンスを評価するもので、モデル能力を直接測定するものではありません。各項目の付与値はエビデンス記録に関連付け、結果状態は独立して保持します。エビデンス層のスコアは、必要なデータ有効性の検証を代替しません。

## 回答品質

回答品質 Q は、標準回答と規定の判定プロトコルに基づき、有効な全タスクインスタンスの正解率を測定します。

### 問題セットと判定

| 区分 | 測定内容 | 問題数 × ラウンド | 計画インスタンス数 | 判定方法 |
| - | - | - | - | - |
| BFCL | 関数選択、引数の充填、並列呼び出し、無関係な呼び出しの抑制、3 段階ツールチェーン | 500 × 3 | 1,500 | 指定バージョンの公式 AST チェッカーに基づく Python 専用 JSON マッチングアダプテーション |
| HLE | 分野別に層化した高難度のテキスト知識・推論問題 | 250 × 10 | 2,500 | 回答等価性ジャッジ。ジャッジモデル、プロンプト、バージョンを記録 |
| AA-LCR | 約 7.4 万から 11.4 万 token の複数ドキュメント統合質問応答 | 25 × 10 | 250 | 指定ドキュメントと標準回答を使用し、回答等価性で判定 |
| 合計 | 775 問の異なる問題 | 区分ごとに規定されたラウンド数で実行 | 4,250 | 有効な全インスタンスを集計 |

```text 回答品質の絶対パフォーマンス theme={null}
A_Q = 100 × 正解インスタンス数 / 有効スコアリングインスタンス数

完全な計画分母 = 1,500 + 2,500 + 250 = 4,250
```

3 つの区分はインスタンス数で集計し、各区分の正解率を等重み平均しません。マルチターンのツールタスクは複数の API リクエストに対応する場合があり、タスクインスタンス数とリクエスト数は別々に集計します。

> [!NOTE]
>
> 本問題セットは AF Suite の派生問題セットであり、Artificial Analysis 公式の厳密なサブセットではなく、同社のリーダーボードスコアを再現するものでもありません。50 個の BFCL マルチターンタスクは実在する問題に基づいて構成しており、BFCL 公式のステートフルなマルチターン実行環境とは別に定義しています。出典とバージョンは[データセットの出典](#dataset-sources)を参照してください。

### 比較条件と欠測の処理

* タスクの正確性は標準回答に基づいて判定し、公式リファレンスの回答は正解として扱いません。
* 各対象は同じ制御可能な予算、サンプリング回数、セマンティック等価パラメータを使用します。思考モード、ツールテンプレート、または `effort` を揃えられない場合は「構成比較不能」と表示します。
* サービス失敗、タイムアウト、拒否応答、予算枯渇は、タスク失敗として分母に算入します。
* ジャッジが無効、または有効な判定を欠く記録は個別に注記し、計算可能な分母から除外したうえで、参考結果の状態を保持します。
* 問題のフィルタリング規則はテスト登録で明示し、レポートには計画数、フィルタリング数、実際のスコアリング数を併記します。
* 反復ラウンドは同一の問題クラスターに帰属し、新たな独立問題としては扱いません。

相対差は区分ごとのペアタスクによるクラスターブートストラップを 5,000 回反復して求めます。各対象は同じ問題サンプリングインデックスを使用し、差の両側 95% 区間を報告します。区間が 0 を含む場合は「優劣なし」と表示し、相対リファレンス層を 50 とします。

## 機能サポート

機能サポート F は、規定の構成でインターフェース機能が利用可能かを測定し、タスク回答の正解率には重複して算入しません。

### 機能グループと重み

| 機能グループ | 重み | 検査内容 |
| - | - | - |
| ストリーミングとメッセージプロトコル | 20% | ストリーミングの差分、イベント順序、終了ブロック、`finish_reason`、`usage` の位置 |
| ツールインターフェース | 20% | ツール名、schema、引数解析、並列呼び出し、ツール結果の返送、エラー処理 |
| 出力制約とパラメータ | 20% | `temperature`、`max_tokens`、`stop`、構造化出力、思考構成の実際の動作 |
| コンテキストと状態 | 15% | ウィンドウ境界、上限超過時の処理、履歴メッセージ、長入力の完全性 |
| エラーとリカバリ | 15% | エラーコード、エラーボディ、レート制限、リトライのセマンティクスとドキュメント規定との整合性 |
| 計量とキャッシュプロトコル | 10% | `usage` の完全性、合計の整合性、キャッシュ計量 |

`f[组]`（Functional Group Pass Score、機能グループ通過スコア）は、単一機能グループの有効適用インスタンスの通過率を表します。式中の `f流式`、`f工具`、`f约束`、`f上下文`、`f错误`、`f计量` は、表中の 6 グループにそれぞれ対応します。

```text 機能サポートの絶対パフォーマンス theme={null}
f[组] = 100 × 通過インスタンス数 / 有効適用インスタンス数
A_F = 0.20 × f流式 + 0.20 × f工具 + 0.20 × f约束
    + 0.15 × f上下文 + 0.15 × f错误 + 0.10 × f计量
```

各グループは 10 個のテストケースで構成され、各ケースを 3 つのウィンドウで 1 回ずつ実行するため、合計 60 個のテストケース、180 個の判定になります。テストケース内で規定された反復リクエストは個別に記録し、テストケースのグループ分けと重みは変更しません。

### 判定状態

| 状態 | 意味 | 集計時の処理 |
| - | - | - |
| PASS | 適用されるすべての検査項目を通過 | 通過および有効適用インスタンスに算入 |
| FAIL | 機能の欠如、コントラクト不一致、値の誤り、想定外のサービス障害 | 有効適用インスタンスに算入し、通過には算入しない |
| NA | モデルがネイティブに機能をサポートせず、十分なエビデンスがあり事前登録済み | 適用分母から除外 |
| UNTESTED | テスト未実行 | 必須テスト記録が不足する場合、制限付きまたは利用不可の状態を保持 |
| INVALID | テスター、フィクスチャ、または構成のエビデンスが無効で、被測定サービスに帰責できない | 機能失敗として扱わず、有効分母とエビデンスの制限を記録 |
| UNOBSERVED | 前段のステップが中断し、後続の観測が形成されていない | 通過として記録せず、観測欠落の状態を保持 |

ネイティブ機能スコアは有効適用記録に基づいて計算します。INVALID または UNOBSERVED が存在する場合は、カバレッジと分母の制限も併せて開示します。必要な検査にエビデンスがない場合、厳格な互換性スコアは利用できません。モデルがネイティブにサポートしていてもサービスが提供していない機能は FAIL として記録し、NA には分類できません。

### ネイティブ機能とインターフェース互換性

| 指標 | 英語名称と日本語での意味 | 検査根拠 | 用途 |
| - | - | - | - |
| `F_native` | Native Functionality Score、ネイティブ機能サポートスコア | プロバイダーのドキュメントに従ってフィールド、ストリーミング構造、必要なリクエスト構成を解釈し、機能の存在とセマンティクスの正確性を検証 | メインスコアの `A_F` として使用 |
| `F_strict` | Strict Interface Compatibility Score、厳格なインターフェース互換性スコア | AIHubMix のインターフェース規定に直接従ってフィールド、イベント構造、戻り値の動作を検査 | インターフェース互換性の診断として別掲 |

フィールドが存在し、位置または命名がプロバイダーのドキュメントに適合する場合、ネイティブ機能検査はその実際の構造に従って解析します。フィールドが完全に欠落している場合、数値が誤っている場合、または相互に矛盾する場合は、実際の検査結果に従って判定します。アダプタ層は元のフィールドとマッピング根拠を保持し、未知の値を機能通過と推定しません。

`F_native` と `F_strict` は別々に報告し、同一の比較表のメインスコアで交互に選択することはできません。キャッシュの有効ヒット率は[応答速度](#speed)に算入し、請求の正確性は別途検証します。

## 応答速度

応答速度 P は、本文応答のパフォーマンスとキャッシュの有効ヒットで構成します。メインスコアには `K_native` を使用します。

### 負荷とサンプリング

非思考プロファイル I（Non-thinking Profile、非思考負荷プロファイル）と思考プロファイル T（Thinking Profile、思考負荷プロファイル）は別々に測定・報告します。I と T は負荷プロファイルの識別子です。I プロファイルはモデルが非思考モードをネイティブにサポートすることを要求し、T プロファイルでは `effort`、思考予算、出力予算を記録します。

C1（Concurrency 1、同時実行数 1）と C10（Concurrency 10、同時実行数 10）は、同時に実行するリクエスト数を表します。ここでの C は Concurrency を表し、エビデンス完全性層の C とは別に使用します。

| 構成項目 | 測定の取り決め |
| - | - |
| 入力 | 10,000 ± 2% token、`o200k_base` で計量。入力の先頭位置に一意のプレフィックスを追加し、想定外のキャッシュヒットを抑制 |
| 出力 | 1,000 から 1,200 個の本文トークン。固定の検証ポイントを含む |
| タイムアウト | 300 秒。同一の比較グループで統一 |
| 同時実行数 1（C1） | 90 回、3 ウィンドウ × 30 |
| 同時実行数 10（C10） | 90 回、3 ウィンドウ × 30 |
| キャッシュサブテスト | 30 回、3 ウィンドウ × 8k/32k の 2 段階 × 5 回 |
| 分離 | 回答品質と応答速度は別々に実行し、応答速度には独立した測定時間帯を使用 |

同時実行テストはクローズドループの補充方式を採用し、1 つのリクエストが完了するごとに 1 つを追加送信します。C10 は当該負荷における観測結果を表し、完全なキャパシティカーブを構成するものではありません。

### 計時と有効出力

| 指標 | 英語名称 | 定義と用途 |
| - | - | - |
| 計測開始点 | Measurement Start Time | 事前確立済み接続の完了後、正式なリクエストの書き込みが始まる時刻。接続のコールドスタート所要時間は別途記録 |
| TTFT | Time to First Token | 最初の実際の推論、本文、またはツール引数ペイロードを待つ時間。空のロールとハートビートイベントは算入せず、元の指標として扱う |
| TTFA | Time to First Answer | 最終本文の最初の非空断片を待つ時間。それ以前の思考所要時間を含み、遅延スコアリングに使用 |
| TPOT | Time per Output Token | 本文生成段階の 1 トークンあたりの平均所要時間。先頭と末尾の本文断片の時刻および対応するトークン数から算出 |
| goodput | Valid-Output Throughput | C10 の完全なウォールクロック時間内で、正確性と完全性の要件を満たす有効本文トークン数のレート |

本文が一度にまとめて返される場合、TPOT は無効として記録し、これに基づいてトークン単位のレートを構成しません。スコアリング統計量には、失敗処理を含む P50（50th Percentile、第 50 パーセンタイル、すなわち中央値）を使用します。実測 P95（95th Percentile、第 95 パーセンタイル）とウィンドウ間の変動は別途報告します。各段階 90 回のサンプルでは P99（99th Percentile、第 99 パーセンタイル）に関する結論は導けません。ここでの P は Percentile を表し、応答速度次元の P とは別に使用します。

### スコアリング式

本節の関数名とサブスコア記号は、いずれも本手法の計算上の記号であり、意味は次のとおりです。

| 記号 | 英語名称 | 意味 |
| - | - | - |
| `S(x; τ)` | Latency Score Function | 待機時間 x を遅延サブスコアに変換する関数。τ は遅延スケール |
| `L(x; t, k)` | Lower-is-Better Score Function | 値が低いほどよいスコア関数。本節では TPOT に使用し、t は満点目標、k は範囲の倍数 |
| `H(x; t)` | Higher-is-Better Score Function | 値が高いほどよいスコア関数。本節では有効スループットに使用し、t は満点目標 |
| `l_ttfa` | Answer Latency Subscore | 最初の本文応答までの遅延サブスコア。C1 と C10 のスコアリング結果のうち小さい方 |
| `l_tpot` | Output Token Time Subscore | 本文の 1 トークンあたり所要時間のサブスコア。C1 と C10 のスコアリング結果のうち小さい方 |
| `P_response` | Response Performance Score | 遅延、1 トークンあたり所要時間、有効スループットを合成した応答パフォーマンスサブスコア。キャッシュサブスコアは含まない |
| `P50_TTFA_C1`、`P50_TTFA_C10` | Median Time to First Answer at Concurrency 1 / 10 | 同時実行数 1 または 10 における、失敗処理を含む TTFA の中央値 |
| `P50_TPOT_C1`、`P50_TPOT_C10` | Median Time per Output Token at Concurrency 1 / 10 | 同時実行数 1 または 10 における、失敗処理を含む TPOT の中央値 |

`A_P` は応答パフォーマンスとキャッシュサブスコアを含む絶対応答速度スコアです。`D_P` は、さらに相対リファレンスとエビデンスの合成を経て、総合スコアに参加する応答速度次元スコアです。

以下の `clip` は数値を 0 から 1 の範囲に制限し、`ln` は自然対数、`min` は小さい方の値を取ることを表し、Σ は総和を表します。式中の τ、b、c、k は、式の直後のパラメータ表で定義します。

```text 応答速度の絶対パフォーマンス theme={null}
S(x; τ) = 100 × τ / (τ + x)
L(x; t, k) = 100 × clip[ln(k·t/x) / ln(k)]
H(x; t) = 100 × clip[ln(x / (0.05·t)) / ln(20)]

l_ttfa = min(S(P50_TTFA_C1; τ), S(P50_TTFA_C10; τ))
l_tpot = min(L(P50_TPOT_C1; b, 10), L(P50_TPOT_C10; b, 10))

goodput = Σ有効リクエスト min(本文 tokens, 1000) / Σ C10 ウィンドウのウォールクロック時間

P_response = 0.35 × l_ttfa + 0.35 × l_tpot + 0.30 × H(goodput; c)
A_P = 0.80 × P_response + 0.20 × K_native
```

| パラメータ | 英語名称 | 値 | 意味 |
| - | - | - | - |
| τ | Latency Scale | 2 秒 | 遅延サブスコアが 50 になるときの TTFA |
| b | Target Time per Output Token | 5 ms/token | TPOT の満点目標。この値以下で 100 |
| c | Target Valid-Output Throughput | 1,200 token/s | C10 有効スループットの満点目標。この値以上で 100 |
| k | TPOT Range Multiplier | 10 | TPOT の対数写像における範囲の倍数 |

上記の目標は本標準が規定する負荷に対するものであり、すべてのモデルおよびすべてのワークロードに共通するしきい値を表すものではありません。

| TTFA | 0 秒 | 1 秒 | 2 秒 | 4 秒 | 10 秒 |
| - | - | - | - | - | - |
| 遅延サブスコア | 100 | 66.7 | 50 | 33.3 | 16.7 |

### 無効出力と測定の分離

長さの不一致、検証ポイントの誤り、循環的な劣化、ストリーム内エラー、異常終了、または切断された出力は無効と判定し、負荷と所要時間には引き続き算入します。P50 を計算する前に、次の処理を適用します。

* TTFA は正の無限大として計上し、対応する遅延サブスコアは 0 とします。
* TPOT は `10b`、すなわち 50 ms/token として計上します。
* goodput の有効出力への寄与は 0 とし、時間は対応する C10 ウィンドウに保持します。
* 元の実測所要時間は個別に保持し、スコアリング処理値で上書きしません。

有効リクエスト数、計画数、有効出力率を併せて報告します。パフォーマンス結果にはサービス失敗がサービス提供に与える影響が含まれ、成功したリクエストの遅延のみで解釈することはできません。

## キャッシュヒット

キャッシュサブスコア K（Cache Hit Score、キャッシュ有効ヒットサブスコア）は、再利用可能なプレフィックスのうち、実際にキャッシュ読み取りとして報告されたトークンの割合を測定します。長さごとにホットリクエストの読み取り量と再利用可能量を集計し、8k と 32k の 2 種類の長さを等加重で集約します。

| 記号 | 英語名称 | 意味 |
| - | - | - |
| `K_length` | Length-Specific Cache Hit Score | 特定のプレフィックス長段階のキャッシュ有効ヒットサブスコア |
| `K_8k` | 8k-Prefix Cache Hit Score | 約 8k トークンのプレフィックス段階のキャッシュ有効ヒットサブスコア |
| `K_32k` | 32k-Prefix Cache Hit Score | 約 32k トークンのプレフィックス段階のキャッシュ有効ヒットサブスコア |
| `cache_read_native_tokens` | Cache-Read Native Token Count | ホットリクエストが実際に報告したキャッシュ読み取りのネイティブトークン数。キャッシュ書き込みは含まない |
| `expected_reusable_native_tokens` | Expected Reusable Native Token Count | 規則上再利用可能なプレフィックスのネイティブトークン数。ヒット率の分母として使用 |

ここでの `native_tokens` は、指定されたネイティブトークナイザーで計量したトークンを表し、`K_native` におけるプロバイダーのドキュメントに従った構成を表す `native` とは別に解釈します。

```text キャッシュヒットサブスコア theme={null}
K_length = 100 × Σホットリクエスト cache_read_native_tokens
                 / Σホットリクエスト expected_reusable_native_tokens

K = (K_8k + K_32k) / 2
```

異なる長さを統合したトークン加重ヒット率は診断指標として使用できますが、メインスコアの等重みの K を代替しません。

### テストシーケンスと分母

各グループは固定の長いプレフィックスと変化する新しい質問を使用し、合計 5 回のリクエストを送信します。

1. 初回リクエストでキャッシュに書き込み、プレフィックスの先頭位置に独立したランダム識別子を追加して、異なるテストグループを分離します。
2. 2 回目から 4 回目はプレフィックスをバイト単位で一致させ、末尾には異なる短い質問を使用し、前回のリクエスト完了からそれぞれ 5 秒、30 秒、120 秒後に送信します。
3. 5 回目は完全に独立した新しいプレフィックスに置き換え、コールドコントロールとします。

3 つのウィンドウでそれぞれ約 8k と 32k の 2 段階をカバーし、合計 30 回のリクエストになります。ホットヒットのスコアリングには 2 回目から 4 回目のみを使用し、各長さに 9 回のホットリクエスト機会があります。初回書き込みとコールドコントロールは別途検証します。

分母には、登録された再利用可能プレフィックスのネイティブトークン数を使用し、指定されたトークナイザー、テンプレート、キャッシュ規則を根拠とします。新しい質問と再利用できない部分は個別に識別し、全入力トークン、実際のヒット量、または `o200k_base` のカウントで分母を代替しません。ブロック単位で報告された読み取り量は、元の値とブロックサイズを保持します。

メインスコアには **`K_native`** を使用します。これはプロバイダーのドキュメントに従ってキャッシュを有効にするために必要な構成を使用し、必要なセッションアフィニティフィールドは接続アダプテーションに含めます。**`K_default`** は、セッションアフィニティ構成を一律に付加しない場合の結果を記録し、デフォルト構成の診断として扱います。各社は同一の構成判定原則に従って実行し、レポートには具体的な構成を保持します。

### 異常と観測不能な状況

| 状況 | 処理 |
| - | - |
| 再利用可能な分母が不明 | K は利用不可とし、0 とは記録しない |
| 成功したリクエストにキャッシュ読み取りフィールドがない | デフォルトでは観測不能として記録する。ドキュメントでゼロヒット時にフィールドを省略することが明示され、登録済みでエビデンスが一致する場合に限り、0 として解析 |
| 読み取り量が分母を超える、またはフィールドが競合する | 異常と元の値を記録し、100% に切り詰めない |
| コールドコントロールが成功し、読み取り量が 0 | コールドコントロールのエビデンスとして使用可能。完了できなかったコントロールは制限状態を保持 |
| ホットリクエストが失敗し、分母を確定できる | 読み取り量を 0 として算入し、失敗記録は別掲 |
| モデルがネイティブにキャッシュをサポートしているが、サービスが提供していない | K = 0 |
| モデルがネイティブにキャッシュをサポートせず、事前に定義されている | 「No-cache」段階として別掲し、`A_P = P_response`、キャッシュありの段階とは別々に報告 |
| ヒット計量をサポートしていない | K と P を利用不可とし、キャッシュの重みを移さない |

`usage` はインターフェースが報告するキャッシュ読み取り量を確認できるのみです。実際のコストは照合後にのみ検証済みと表示できます。キャッシュヒットは無料を意味せず、合計コストの低減も保証しません。

## サービス安定性

サービス安定性 R は、固定リクエストセットの初回有効完了率を測定し、スコアリングでは自動リトライやモデルプロバイダー間のフォールバックを使用しません。

```text サービス安定性の絶対パフォーマンス theme={null}
A_R = 100 × 初回有効完了数 / 有効計画機会数

完全な計画機会数 = 300
```

### テストセットと成功条件

テストは合計 300 回の試行機会で、3 つのウィンドウに分散し、各ウィンドウ 100 回です。各 100 回は同じタスク構成を使用します。短いテキスト 40、約 10k の長入力 30、ツールプロトコル呼び出し 20、マルチターン履歴付きの単一呼び出し 10 です。

ツールタスクには事前に用意した有効な履歴を使用し、スコアリング分母を安定させます。デフォルトは単一同時実行とし、リクエストレートは検証済みの RPM、TPM クォータ内に収めます。本スイートは独立して実行し、回答品質の問題、機能のネガティブテストケース、診断リトライ、ウォームアップ、負荷テストのリクエストを混入させません。

初回成功の条件は、次のすべてを満たすことです。

* HTTP ステータスが想定どおりで、応答構造とイベントシーケンスが有効であること。
* 本文またはツールペイロードが空でなく、正常に終了していること。
* ストリーム内エラー、想定外の切断、必須フィールドの欠落がないこと。
* 規定の `usage` フィールドが完全で、対応するインターフェース構造に従って解析できること。
* 300 秒の期限内に完了していること。

HTTP 200 のみでは成功と判定できません。タスク回答の誤りとサービス失敗は別々に集計します。

### 失敗、無効記録、区間

クォータ内の 429、サーバーエラー、接続失敗、タイムアウト、空の応答、ストリーム切断、異常な切断は失敗として計上します。モデルプロバイダーの障害により計画されたリクエストを送信できなかった場合も、失敗として計上し、原因を記録します。

テスト環境またはテスターの異常は INVALID と表示し、被測定サービスに帰責せず、有効機会数とカバレッジの制限を保持します。診断リクエストは独立して記録し、初回結果を代替しません。

成功率は両側 95% Clopper–Pearson 区間で報告します。300/300 の観測成功率は 100%、区間の下限は約 98.78% ですが、長期的なサービス成功率が 100% であることを証明するものではありません。ウィンドウ別およびタスクカテゴリ別に、失敗の分布と最長の連続失敗区間を記録します。

## テスト規模と比較可能性

### サンプル規模

以下は AF Suite における AF Full の計画規模です。

| 項目 | プロバイダーごとの計画規模 | 構成 |
| - | - | - |
| 回答品質 | 4,250 インスタンス | BFCL 1,500、HLE 2,500、AA-LCR 250 |
| 機能サポート | 180 件の判定 | 60 個のテストケース × 3 つのウィンドウ |
| 応答速度 | 180 回のリクエスト | C1/C10 各 90 回、3 つのウィンドウに分散 |
| キャッシュ | 30 回のリクエスト | 3 つのウィンドウ × 2 種類のプレフィックス長 × 5 回 |
| サービス安定性 | 300 回の機会 | 3 つのウィンドウ × 100 回 |

タスクインスタンス数、API リクエスト数、ジャッジリクエスト数は別々に集計します。多段階のツールタスクとテストケース内の反復は、追加のリクエストに対応する場合があります。

### 実行条件

* 同一の比較グループでは、問題セット、ラウンド、タイムアウト、温度、出力予算、失敗処理、スコアリング式を統一します。
* 同一のクライアント、ネットワーク地域、接続ポリシーを採用し、アカウントのサービスティア、実際の開始・終了時刻、実行順序を記録します。
* 完全なテストでは 3 つのウィンドウを使用し、ウィンドウ間の間隔は少なくとも 60 分とします。回答品質と応答速度は別々に実行します。
* モデル ID、認証、必須フィールド、ストリーミング形式、使用量マッピング、キャッシュのセマンティクス、トークナイザーの根拠をアダプテーション記録としてまとめます。
* 接続アダプテーションはサンプリング前に登録して検証し、同一の規則を条件を満たすすべてのモデルプロバイダーに適用します。
* スコアリングのメインビューでは `F_native` と `K_native` を統一して採用し、互換性とデフォルト構成の診断は別々に報告します。
* 初回実行の結果は継続的に保持し、計画量、実績量、フィルタリング、失敗、無効、未観測の記録を別々に照合します。

テストは承認されたクォータ、権限、費用の範囲内で実行します。必要条件を満たさない場合、結果は制限付き、未完了、または利用不可の状態を保持し、残りの項目を再正規化しません。

## データセットの出典と結果記録

### データセットの出典

回答品質ではバージョン管理された派生問題セットを使用し、出典、サンプリング記録、完全性検証の情報を保持します。AF Full の回答品質問題セットには 775 問の異なる問題が含まれます。出典スナップショットは次のとおりです。

| 区分 | 出典スナップショット | バージョン記録 | ライセンスと使用範囲 |
| - | - | - | - |
| BFCL | [Berkeley Function Calling Leaderboard のデータとチェッカー](https://github.com/ShishirPatil/gorilla/tree/6ea57973c7a6097fd7c5915698c54c17c5b1b6c8/berkeley-function-call-leaderboard) | `6ea57973c7a6` | 出典リポジトリは Apache-2.0。本評価では派生問題セットとチェッカーアダプテーションを使用 |
| HLE | [テキストミラーのスナップショット](https://huggingface.co/datasets/macabdul9/hle_text_only/tree/e3e9cb5a550ec7de645fac553b0e2768d30a03ee)、[公式データセット](https://huggingface.co/datasets/cais/hle) | ミラー `e3e9cb5a550e` | 出典の記録は MIT。公式の現行バージョンとバイト単位で同一であることは未検証 |
| AA-LCR | [Artificial Analysis AA-LCR のデータとドキュメントのスナップショット](https://huggingface.co/datasets/ArtificialAnalysis/AA-LCR/tree/9a77ef56b717057ade24ceab4d273712a0b4f19e) | `9a77ef56b717` | データセットリポジトリは Apache-2.0。引用ドキュメントの第三者の権利は引き続き元の権利者に帰属 |

BFCL はカテゴリ別のクォータでサンプリングします。HLE と AA-LCR は層化比例サンプリングを行い、各層の最小カバレッジを確保します。サンプリングには指定されたシードと SHA-256 によるソートを使用し、問題セットのバージョン、フィルタリングリスト、判定プロトコルを結果とともに記録します。

上記のリンクは元の出典を検証するためのものであり、AF スコアを直接再現できる完全な評価パッケージを示すものではありません。制限付きデータは本ドキュメントでは再配布せず、具体的なライセンスは各出典に従います。

### 結果記録と検証

プロバイダーレポートは AF Profile と総称し、次の評価情報を記録します。

| 記録カテゴリ | 必須内容 |
| - | - |
| 評価の同一性 | 標準と問題セットのバージョン、モデルプロバイダー、正確なモデルバージョン、公式リファレンスサービス |
| 測定条件 | 思考構成、アカウントティア、地域、時間帯、タイムアウト、同時実行数、パフォーマンスパラメータ |
| アダプテーション根拠 | ドキュメントの参照日、必須フィールド、ストリーミング構造、使用量解析、キャッシュ構成 |
| サンプルカバレッジ | 計画数、実績数、スコアリング分母、フィルタリング、失敗、無効、未観測項目 |
| 判定根拠 | 標準回答、チェッカーまたはジャッジ構成、判定状態、バイアス評価 |
| 元の測定 | マスキング済みリクエストと応答、イベント時刻、状態、終了理由、元の `usage` |
| 集計結果 | A/B/C 層の入力、4 つの D スコア、総合スコア、次元区間、丸め前の値 |
| 診断指標 | `F_strict`、`K_default`、有効率、エラーカテゴリ、対応する適用制限 |

サービスの成功、タスクの正解、出力の有効性は別々に表示します。ネガティブテストケースはサービス安定性スコアに混入せず、キャッシュの読み取りと書き込みは別々に計量し、推定コストと実際のコストの検証状態は別々に記録します。外部に公開する前に API キー、ユーザー識別子、機密性の高いコンテンツを削除します。数値には単位を付し、欠損値は状態を保持します。

## 参考データと計算例

以下では、DeepSeek V4.1 Flash 1017 の 5 社のサービス結果を用いて計算方法を説明します。メインスコアには `F_native` と `K_native` を使用します。数値は小数第 2 位まで表示し、計算には結果ファイルに保存された中間値を使用します。

> [!NOTE]
>
> 本節は参考結果（PROVISIONAL）です。収集とアダプテーションの事前登録エビデンスが不完全であり、AIHubMix Fidelitas Standard の正式な AF Full 結果としては扱えません。回答品質では各社 4,240 インスタンスを算入し、別に 10 個のフィルタリング済みインスタンスがあります。HLE/AA-LCR のジャッジと被測定モデルは同じ DeepSeek ファミリーに属し、独立したキャリブレーションのエビデンスが不足しています。結果は記録された構成と観測範囲に限定されます。

### 絶対パフォーマンスとキャッシュサブスコア

下表の Q、F、P、R はいずれも絶対パフォーマンス A であり、**総合スコアにおける 4 つの次元表示スコアとして直接用いるものではありません**。K は P に含まれるキャッシュサブスコアです。

| モデルプロバイダー | A\_Q | F\_native（A\_F） | A\_P | K\_native | A\_R |
| - | - | - | - | - | - |
| ByteDance | 42.05 | 74.98 | 84.37 | 93.83 | 100.00 |
| Baidu | 38.00 | 88.39 | 37.77 | 68.85 | 100.00 |
| Alibaba Cloud | 41.75 | 89.78 | 88.58 | 99.37 | 100.00 |
| DeepSeek 公式リファレンス | 42.45 | 94.00 | 86.14 | 98.38 | 100.00 |
| Fireworks | 41.42 | 71.78 | 79.51 | 60.68 | 100.00 |

* 5 社のサービス安定性スイートはすべて 300/300 です。他のスイートのサービス失敗は引き続き所属する次元に算入され、R スイートの結果で代替することはできません。
* Fireworks の `K_native` はドキュメントで規定されたセッションアフィニティ構成を使用し、その他のサービスは各ドキュメントが要求する構成で測定しています。
* Baidu の K は、ゼロヒット時にフィールドを省略する場合に 0 として解析するサンプルに関する規則を採用していますが、関連する事前登録エビデンスは不完全です。8k のコールドコントロールに未完了の記録があるため、K は参考状態を保持します。
* DeepSeek の `F_strict` は 27 件の INVALID 記録により利用できません。`F_native` は有効適用記録に基づいて計算します。

### 機能サポートの次元合成

Alibaba Cloud を例に説明します。絶対機能サポートスコアは `A_F = 89.777778`、公式リファレンスの同項目における絶対スコアは 94、差分スケールは `δ_F = 15`、エビデンス完全性は `C_F = 100` です。まず相対リファレンススコア `B_F` を計算し、次に次元スコア `D_F` を合成します。

```text 相対リファレンスと機能次元スコア theme={null}
B_F = 50 + 50 × clip((89.777778 − 94) / 15, −1, 1)
    ≈ 35.925926

D_F = 0.65 × 89.777778 + 0.20 × 35.925926 + 0.15 × 100
    ≈ 80.540741
```

89.78 はネイティブ機能の絶対パフォーマンス、80.54 は総合スコアの計算に参加する機能次元の表示スコアを表します。

### 公式リファレンスのサービス安定性スコア

公式リファレンスの R スイートは 300/300 で、絶対サービス安定性スコアは `A_R = 100`、相対リファレンススコアは `B_R = 50`、エビデンス完全性は `C_R = 100` です。

```text サービス安定性の次元合成 theme={null}
D_R = 0.65 × 100 + 0.20 × 50 + 0.15 × 100
    = 90
```

100% は今回のサービス安定性スイートの観測成功率、90 は 3 層合成後の次元表示スコアです。

### 次元表示スコアと総合スコア

下表は D 値を使用し、総合スコアの式に対応しています。表はサービスの表示順に従い、スコア順には並べていません。

| モデルプロバイダー | 回答品質 D\_Q | 機能サポート D\_F | 応答速度 D\_P | サービス安定性 D\_R | 総合スコア |
| - | - | - | - | - | - |
| ByteDance | 50.83 | 62.24 | 76.57 | 88.50 | **66.37** |
| Baidu | 36.70 | 75.71 | 36.55 | 87.00 | **56.48** |
| Alibaba Cloud | 52.13 | 80.54 | 85.01 | 90.00 | **73.38** |
| DeepSeek 公式リファレンス | 52.59 | 84.60 | 80.99 | 90.00 | **73.76** |
| Fireworks | 50.42 | 60.16 | 68.55 | 88.50 | **64.10** |

公式リファレンスを例にします。

```text 総合スコア計算 theme={null}
Overall = 0.35 × 52.594340 + 0.25 × 84.600000
        + 0.20 × 80.990116 + 0.20 × 90.000000
        ≈ 73.76
```

### 独立した診断指標

| モデルプロバイダー | F\_strict | K\_default |
| - | - | - |
| ByteDance | 56.83 | 93.83 |
| Baidu | 66.17 | 68.85 |
| Alibaba Cloud | 89.78 | 99.37 |
| DeepSeek 公式リファレンス | 利用不可 | 98.38 |
| Fireworks | 71.78 | 11.06 |

`F_strict` はインターフェース互換性を表し、`K_default` はセッションアフィニティ構成を一律に付加しない場合のキャッシュ結果を表します。いずれの列もメインスコアの入力値を代替するものではありません。

回答品質について、公式リファレンスに対する差分区間では、ByteDance、Alibaba Cloud、Fireworks の 95% 区間がいずれも 0 を含むため、対応する `B_Q = 50` とします。Baidu の差分は約 −4.46 パーセントポイント、95% 区間は約 −5.78 から −3.16 パーセントポイントです。この結論は今回のタスクセットと観測条件に限定され、総合スコアの統計的有意性に関する結論には拡張されません。

## 標準と適用条件

標準の識別子：**AIHubMix Fidelitas Standard v2.0**。結果には AF Suite、アダプテーション構成、判定プロトコル、測定条件を併せて記録します。構成または統計基準が異なる結果は別々に解釈します。

モデルページの 4 つのスコアは D 値です。レポートの正解率、機能通過率、遅延、キャッシュ率、初回成功率は、対応する元の指標または A 値です。総合スコアは集約表示に使用し、具体的な接続判断は次元の結果、機能要件、エビデンス条件に基づきます。

関連ドキュメント：[モデルを選ぶ](https://docs.aihubmix.com/jp/guides/choose-models.md) · [モデルの詳細と比較](https://docs.aihubmix.com/jp/guides/model-details.md)

ドキュメント日付：2026-11-05


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.