基準與已知限制

Laya 的結果取決於 checkpoint、任務、問題措辭、選項數量和硬體。選擇 checkpoint 或置信度閾值 之前，先用完整的基準表 找到一次可比的執行。research 目錄 放著支撐主要表格的指令碼和結果檔案。

找到相關的測量

與原版 Laya 套件並列釋出的 Jev 資料來自提示詞和樣本量都不同的第三方研究。它們是有用的背景， 但不是一次受控的正面比較。見 research/README.md 裡的對比說明。

準確率要和基線、資料劃分一起讀。比如 typed-decisions 基準報告微調後的 checkpoint 準確率為 0.766，而兩個基礎 checkpoint 都低於它 0.461 的多數類基線。這個結果支援為相似任務做微調；它 並不能證明未訓練的 checkpoint 或新領域也能達到 0.766 準確率。

置信度要和準確率分開讀。期望校準誤差（ECE）衡量報告的機率與觀察到的正確率吻合得如何；越低 越好。51 語言掃描的原始 ECE 和平均置信度兩列早於 #42 裡的溫度鉗制。它的準確率列仍然適用，但 比較當前置信度值時要用 research/results/ 裡鉗制後的重跑。即便某個套件的 ECE 更低，也不能為 另一個任務或另一種選項數量定下安全閾值。

要在你自己的資料上檢查的限制

• 語言路由： 英文 checkpoint 對它在英文之外處理不好的文本也可能很自信。混合語言輸入請用 Router，並在你實際服務的語言上檢查路由決策。多語言 checkpoint 在英文 MASSIVE 和 XNLI 切片上的得分也低於英文 checkpoint。
• 選項很多： choice 的描述共享一份固定的 token 預算。77 標籤的 Banking77 執行在預設預算下 表現很差。單個 choice 問題保持在 20 個選項左右，或者在你自己的標籤上評估一個候選列表加上更 大的 head 預算。
• 校準： 按交付狀態，兩個基礎 checkpoint 在已釋出的套件上都過度自信，但另一個單獨的路由 任務卻不夠自信。使用置信度門控之前，請在你工作流留出的、獨立的樣本上擬合併評估溫度。
• 任務遷移： 在應用基準裡，留出的內容稽核表現很弱，而有序的 score 是已報告英文套件裡最弱 的原語。多語言 checkpoint 還測出對第一個 score 檔位有偏好。請測試你打算實際服務的那個問題 型別和資料分佈。
• 措辭和順序： 選項順序會改變 choice 的答案。有記錄的例子裡，布林詞選項標籤和被否定的 請求也失敗過；noul 可能跟著選項標籤而不是狀態走。請檢查備選的選項順序和措辭，錯誤決策代價 高時尤其如此。
• 長文件： 多語言編碼器配置到該上限時可以讀最多 8,192 個 token，但 長上下文基準 報告，前文超過約 4,000 個 token 後答案就沒那麼可靠了。請在你預期使用的長度上測量準確率。
• 延遲： T4 的數字不能預測 CPU 或冷載入時間。請用你自己的 checkpoint、裝置、輸入長度和問題 數量測量預熱和冷啟動呼叫。

README 的 Honest limits 一節 有示例和當前的變通辦法。基準表給出了上述每項限制背後的資料集和硬體。

復現或擴充套件一個結果

從指令碼與結果地圖 和 BENCHMARKS.md 頂部的執行索引開始。research/scripts/bench_local.py 跑 51 語言的 CPU 掃描，bench_apps.py 覆蓋應用工作流，bench_latency.py 測量路由和推理速度。T4 notebook 由 research/scripts/build_benchmark_nb.py 生成；改那個基準時請改生成器。

對於一次新部署，為你要比較的每個 checkpoint 保留一份帶相同狀態、問題和預期答案的留出集。每次 執行都記錄 checkpoint 版本、Laya 和庫的版本、裝置、問題數量、選項數量和 token 預算。為準確率 加一個簡單基線，並同時報告預熱後的延遲和首次使用的載入時間。這樣你的結果才能和已釋出的執行相 比，也讓你在升級後能重新審視它。