基准与已知限制

基准与已知限制

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 预算。为准确率 加一个简单基线，并同时报告预热后的延迟和首次使用的加载时间。这样你的结果才能和已发布的运行相 比，也让你在升级后能重新审视它。