ベンチマークと既知の制限
ベンチマークと既知の制限
Laya の結果は、チェックポイント、タスク、質問の文言、選択肢の数、ハードウェアに依存します。 チェックポイントや信頼度のしきい値を選ぶ前に、全ベンチマーク表 を使って比較可能な実行を探してください。research ディレクトリ には、主要な表の背後にあるスクリプトと結果ファイルが置かれています。
該当する測定を探す
| 評価したいもの | まず見るもの | 結果を適用する前に確認すること |
|---|---|---|
| 言語をまたぐ意思決定 | BENCHMARKS.md の MASSIVE と XNLI の表 |
言語、タスク、選択肢の数、チェックポイント |
| トリアージやモデレーションなどのワークフロー | BENCHMARKS.md のアプリケーションワークフローの表 |
データセットが学習の混合に含まれていたか、ホールドアウトだったか |
laya-typed-decisions チェックポイント |
BENCHMARKS.md の typed-decisions の表 |
そのベンチマークの学習用分割でファインチューニングされている。ベースのチェックポイントには別の行がある |
| 応答時間 | BENCHMARKS.md の T4、GB10、ノート PC の CPU、サーバー CPU の各節 |
デバイス、バッチサイズ、質問数、ウォームアップ、HTTP 時間が含まれるか |
Laya の元のスイートと並べて掲載されている Jev の数値は、プロンプトとサンプルサイズの異なる
第三者研究から来ています。参考にはなりますが、統制された直接比較ではありません。比較の注記は
research/README.md
にあります。
精度はベースラインとデータ分割とあわせて読みます。たとえば typed-decisions ベンチマークでは、 ファインチューニング済みチェックポイントの精度が 0.766 と報告されていますが、2 つのベースの チェックポイントはいずれもその 0.461 という多数クラス基準を下回ります。この結果は似たタスクでの ファインチューニングを支持しますが、未学習のチェックポイントや新しい領域で 0.766 の精度が 得られることを示すものではありません。
信頼度は精度とは別に読みます。期待キャリブレーション誤差(ECE)は、報告された確率が観測された
正しさとどれだけ一致するかを測ります。小さいほど良い指標です。51 言語スイープの元の ECE と平均
信頼度の列は、#42 の temperature clamp より前のものです。精度の列はそのまま当てはまりますが、
現在の信頼度の値を比べるときは research/results/ の clamp 後の再実行を使ってください。ある
スイートで ECE が低いからといって、別のタスクや選択肢数に対して安全なしきい値が定まるわけでは
ありません。
自分のデータで確認すべき制限
- 言語ルーティング: 英語のチェックポイントは、英語以外ではうまく扱えないテキストでも自信を
持つことがあります。混在言語の入力には
Routerを使い、運用する言語でルーティングの判断を 確認してください。多言語のチェックポイントも、英語の MASSIVE と XNLI のスライスでは英語の チェックポイントより低いスコアになります。 - 選択肢が多い場合: choice の説明は固定の token 予算を共有します。77 ラベルの Banking77 の 実行は、既定の予算では振るいません。1 つの choice 質問はおよそ 20 選択肢までに抑えるか、 自分のラベルでショートリストとより大きな head 予算を評価してください。
- キャリブレーション: 出荷された状態では、2 つのベースのチェックポイントはどちらも公開 スイートで過信気味ですが、別のルーティングタスクでは逆に自信がなさすぎました。信頼度のゲートを 使う前に、自分のワークフローのホールドアウトした別々の例で temperature をフィットさせ、評価して ください。
- タスク転移: アプリケーション基準では、ホールドアウトしたモデレーションが弱く、順序付きの
scoreは報告された英語スイートで最も弱いプリミティブです。多言語のチェックポイントには、 最初のscoreレベルに対する偏りも測定されています。実際に運用する質問タイプとデータ分布を 試してください。 - 文言と順序: 選択肢の順序が
choiceの答えを変えることがあります。記録された例では、真偽を 表す語の choice ラベルや否定形のリクエストも失敗しています。noulは state ではなく自分の選択肢 ラベルに従うことがあります。代替の選択肢順序や文言を確認してください。誤った判断のコストが 高いときは、なおさらです。 - 長い文書: 多言語エンコーダは、その上限に設定すれば最大 8,192 token まで読めますが、 長文コンテキストのベンチマーク では、先行するテキストが約 4,000 token を超えると答えの信頼性が下がると報告されています。 想定する長さで精度を測ってください。
- レイテンシ: T4 の数値は CPU やコールドロードの時間を予測しません。自分のチェックポイント、 デバイス、入力長、質問数で、ウォームアップ後とコールドの呼び出しを測ってください。
README の「正直な制限」セクション に例と現在の回避策があります。上の各制限の背後にあるデータセットとハードウェアは、ベンチマーク表 に書かれています。
結果を再現または拡張する
スクリプトと結果のマップ
と、BENCHMARKS.md 冒頭の実行インデックスから始めてください。research/scripts/bench_local.py
は 51 言語の CPU スイープを実行し、bench_apps.py はアプリケーションワークフローを扱い、
bench_latency.py はルーティングと推論速度を測ります。T4 ノートブックは
research/scripts/build_benchmark_nb.py から生成されます。そのベンチマークを変えるときは
生成側を編集してください。
新しいデプロイでは、比較するすべてのチェックポイントに対して、同じ state、質問、期待する答えを 持つホールドアウト集合を用意してください。各実行で、チェックポイントのリビジョン、Laya と ライブラリのバージョン、デバイス、質問数、選択肢数、token 予算を記録します。精度のための単純な ベースラインも含め、ウォームアップ後のレイテンシと初回使用時のロード時間の両方を報告して ください。こうすると結果を公開された実行と比較でき、アップグレード後に見直せます。