当我们谈论大模型应用开发时，评测环节往往是那个“既重要又棘手”的存在。它决定了产品能否真正解决用户问题，却又充满了难以量化的灰色地带。这篇文章，聊聊在实践中对评测的一些观察与思考。

为什么公开Benchmark的参考价值有限

各家模型发布时，漂亮的Benchmark数据总是标配。如果仅看这些数字，似乎AGI已经近在咫尺。然而现实往往给人当头一棒——Ilya在最近的播客中开篇就直面这个问题，这本身就很说明问题。造成这种落差的原因，可以归结为两点。其一，RL后训练的泛化能力仍然有限，目前更像是“种瓜得瓜、种豆得豆”的状态。其二，构建训练任务时，研发团队有意无意地针对现有Benchmark进行优化，形成了一种“合法的reward hacking”——这不是算法的问题，而是人的决策问题。对于应用开发者而言，除非某个Benchmark恰好基于你的业务场景构建，否则公开评测数据能迁移到实际场景的比例相当存疑。这意味着，每个业务场景都需要构建自己的评测体系，来衡量模型选型和应用架构的真实效果。

评测的本质：把模糊的目标变成可衡量的数据集

在实际业务中，评测最核心的价值是什么？我们认为是：将产品目标和用户需求进行量化，而量化的载体就是评测数据集。今天的AI应用场景复杂度极高，很难用一套规则来定义“好”与“不好”。输入数据的分布难以用其他方式描述，最终都只能转化为数据集来承载。这个逻辑在AI 1.0时代就已成立，到了生成式AI时代更是如此。

实践中的几个关键认知

随机性是绑定的约束条件

与AI 1.0时代不同，LLM的输出天然带有随机性。更麻烦的是，当我们用LLM来做自动化评测时，评测本身也带有随机性。这就形成了一个“随机套随机”的局面。这里有一个值得思考的问题：假设有两个0-1随机变量A和B，期望分别是0.96和0.97。如何设计采样策略，在控制总成本的前提下，区分出哪个是A、哪个是B？这个问题的答案直接影响评测的效率和可信度。

小样本人工评测的价值被低估了

在功能迭代的早期阶段，差异往往足够明显，人工只需不到10次自评就能发现方向性问题。而且人工评测能观察到更多维度，这些维度可能正是自动化评测难以覆盖的。2024年，Anthropic和Cursor在公开分享中都提到了这种“Vibe评测”方式。评测手段的选择，本质上取决于待测方案之间的预估差距——差距越大，所需样本量越小。极端情况下，如果一个方案99%正确、另一个只有1%，各抽样一次就能大概率区分。

机评与人评的一致性陷阱

对于非结构化文本输出，我们通常会构建一个评测workflow来进行自动化打分。这种方式看起来高效，但隐藏着一个重要问题：评测维度需要显式定义，而将产品sense或用户期望精确转化为可描述的维度，本身就极其困难。更微妙的是，这种细节常常被组织架构所遮蔽。其他人看到的是最终的评测数字，却对数字背后的局限性缺乏认知，进而产生误判。因此，自动化评测不能替代人工判断。产品负责人或用户代表对产品效果的直接评测仍然不可或缺。未被量化的因素并没有消失——组织对这些信息的把控力，往往决定了产品迭代的有效性。

评测方案自身需要持续迭代

评测方案，尤其是自动化方案，终究是阶段性的proxy指标。系统效果在不断优化，用户使用方式在演变，输入数据分布也在变化。评测方案本身就是一个需要迭代的产品，而非一劳永逸的基础设施。

警惕平均化对问题的掩盖

做过数据分析的人都明白下钻的重要性，评测同样如此。对功能的评测需要关注主要维度上的细分表现，才能发现潜在的局部问题。平均化的数字往往会让真正的瓶颈隐形。

独立评测团队的组织困境

对于稍大规模的团队，可能会设立专门的评测组。专业化分工带来效率，同时也引入了新的挑战。

目标错位风险

评测团队的使命是评价功能好坏，但评测团队自身的工作却很难被有效评价。这导致团队目标容易滑向“按时交付评测方案”，进而演变为“评测那些可以被评测的维度”。一个典型模式是：评测方案逐步聚焦于已发现问题的维度——因为新问题可以持续加入评测。而产品为用户创造的价值、用户的“aha moment”，这些真正重要却难以量化的因素，则被渐渐边缘化。将评测能力整合到产品迭代团队中，而非作为中台职能，可能是一种解决思路。

评测团队与研发团队的边界模糊

当需要构建机评方案时，评测团队实际上也在搭建某种workflow——实现对结果的reward计算，或生成理想答案作为对照。这与应用研发团队的工作有相当大的重叠。差异或许在于：评测方案不受推理成本、响应延时、模型合规等约束。某种意义上，这是同一个功能的另一种实现——只是约束不同，且作为评测方，对方案质量的要求反而更高。当组织内还存在数据合成或RL reward构建的团队时，这些边界就变得更加模糊。

评测团队是效果的“QA”吗

将评测结果作为上线门槛看起来合理，但问题可能没那么简单。如果评测只覆盖已发现问题的维度，那么将评测团队定位为效果QA未尝不可。但理想的评测应该包含产品的核心价值。核心价值没过60分就不能上线吗？这需要具体分析。如果竞品都很弱，或许可以先上线迭代；如果产品涉及核电安全，80%的正确率可能都嫌低。脱离场景谈标准，意义有限。

写在最后：保持对评测方案本身的警觉

人类组织很容易过度简化事物，尤其当某件事被量化之后——因为数字看起来更客观、更公正。但评测方案可能并没有那么可信，设计者并非全知全能，仍然面对诸多限制。在实践中，我们需要始终记住评测方案的局限性，并警惕组织被评测体系过度塑造产品方向的风险。评测是服务于产品的工具，而非定义产品的标准。这或许是评测领域最值得持续思考的命题。

关注“鲸栖”小程序，掌握最新AI资讯