Fable 5 的性能跑分应该怎么看？

先说结论：跑分能回答什么？

跑分能回答的是「在某个固定题库上，这个模型相对上一代或相对同期模型处在什么位置」，它是一个横向比较工具，不是能力说明书。

它回答不了的是：在你的具体任务上好不好用。同样的分数，有人觉得提升了，有人觉得没差别，差别出在任务形态和提示写法上。所以分数只适合用来筛掉明显不合适的选项，不适合用来做最终决定。

常见的几类评测分别测什么

不同类型的评测侧重点完全不同，混着看容易得出错误结论。

1. 1知识与推理类：固定题库的选择题或简答题，主要看知识覆盖和推理链。
2. 2代码类：给定函数签名或仓库片段，看能否通过测试用例。
3. 3长文本类：在超长材料里找信息、做多文档比对，考的是上下文利用率。
4. 4主观偏好类：由人或模型对回答打分，结果更容易受评价标准影响。
5. 5工程类：延迟、并发、稳定性等指标，和「聪明程度」是两件事。

怎么核对一个跑分来源是否可信

先看它有没有公开测试方法：题目从哪来、怎么判分、有没有针对该模型调整过提示词。这三条不公开，分数基本只能当宣传看。

再看版本对不对得上。模型会持续更新，拿旧版本的分数说新版本，或者拿不同难度的题库横向比较，都很常见。核对时至少确认评测时间和模型标识是否一致。

最后看有没有第二名和方差。只报单一高分的榜单几乎不提供信息量，一个可信的评测应该让你看到分差和多次运行的结果波动。

更靠谱的做法：自己测一遍

与其纠结公开分数，不如用你自己的任务做一次小样本测试。

1. 1挑 10 到 20 个你真实遇到的代表性问题，覆盖简单与困难的两种极端。
2. 2固定提示词与输入，只替换模型，避免因为写法不同导致结论失真。
3. 3同一任务跑两到三次，观察结果是否稳定，不稳定的任务不适合用来比较。
4. 4记录通过率、返工次数和实际耗时，这些比抽象分数更贴近你的成本。

跑分和实际体验差在哪

评测通常在干净、单一的任务上进行，而真实使用是连续的：要读你的上下文、遵守你的格式、在长对话里保持前后一致。这些能力很少体现在单题分数里。

另外，可用的额度、响应速度和额度消耗也会直接影响体验。同样能力的两个模型，如果其中一个更快更省，实际工作流里可能更值得选。

常见误区

第一个误区是拿不同评测的分数横向比。不同题库难度不可比，跨榜比较基本没有意义。

第二个误区是把一次跑分当成永久结论。模型和评测都在变，任何分数都只代表当时的版本。

怎么把评测结论用到选型上

先用公开分数缩小范围，再用手上的真实任务做最终判断。分数只负责筛掉明显不合适的选项，不负责替你做决定。

选型时把三项指标放在一起看：任务通过率、返工次数、单次成本。三者中任何一项明显吃亏，长期用起来都会不舒服，哪怕它的分数是同期最高的。

还有一点常被忽略：同一家服务的不同档位往往共享同一套评测结论，但额度与响应速度差别很大。看结论时要说清楚具体是哪个档位，否则很容易拿高分去预期低档位的表现。