模型越来越强，但用户为什么感觉不到明显提升？

从去年底到现在，GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro 的 MMLU 分数你追我赶，从 86.4% 一路涨到 88.7%，甚至部分新模型宣称已突破 90%。但一个反直觉的现象是，真正把这些模型塞进日常写代码、审合同、做数据分析工作流里的人，反而越来越少发出“哇，它变强了”的感叹。问题不在于模型没进步，而在于实验室的 Benchmark 曲线与用户的真实体感，衡量的是两套完全不同的东西。

Benchmark 通胀：当 90 分变成基线

MMLU、HumanEval、GSM8K 这些测试集的题目本质上是“有标准答案的知识点问答”。模型从 85 分爬到 90 分，确实意味着它记住了更多事实、掌握了更多解题套路。但在真实工作流里，用户面对的往往不是单点问答，而是模糊、冗长且充满上下文的复杂任务。

举个例子：让模型审查一份 80 页的投资协议，找出所有“对赌条款”的变体。实验室里，“大海捞针”测试在 128K 上下文窗口中的准确率可以高达 99%，模型能精准定位第 100 页里的一句插入语。但在真实协议中，对赌条款的触发条件往往嵌套在第 17 页的定义条款里，需要跨页推理、结合法律术语映射才能识别。此时，模型漏检的概率远高于 Benchmark 所示。分数测的是“找得到”，而用户需要的是“理解对并不出错”。

稳定性：比聪明更难的，是“不抽风”

做内部系统集成的工程师最懂稳定性的分量。某团队把 Claude 3.5 Sonnet 接入客服后台做结构化数据抽取，prompt 里的要求写得明明白白：只输出 JSON，不要任何解释。结果同样一段提示词，上午返回的是干净对象，下午突然在 JSON 结尾附上一句“希望以上信息对您有帮助”，直接导致下游解析报错。

他们拉了一周的日志，发现即使 temperature 设为 0，Function Calling 的格式稳定性也只有约 92%，而非文档暗示的接近 100%。这意味着每 100 次自动化调用里，有 8 次需要重试或人工兜底。用户不会记得那 92 次的流畅，只会对 8 次中断印象深刻。对生产环境来说，模型像一辆偶尔急刹的自动驾驶汽车——再快的加速度，也比不上可预测的匀速。

工具调用与上下文：能用和好用隔着一条河

如今主流模型都宣称支持 Function Calling，单步调用的 Benchmark 准确率也确实能做到 95% 以上。但一旦进入真实业务流，模型往往需要连续调用 3 到 4 个工具，并根据中间结果做二次判断。比如先查数据库拿客户 ID，再调 CRM 查订单，最后调物流 API 追踪轨迹。

单步 95% 的成功率，在三步链式调用里端到端成功率会骤降到 70% 左右。因为中间任何一步的 JSON 字段歧义、空值处理或 API 超时，都会让整条链条断裂。更隐蔽的是上下文问题：128K 的窗口看似能吞下整本规范书，但当真把 10 万字的项目文档塞进去让模型重构代码时，它往往会“遗忘”开头定义的接口规范，导致新生成的代码与旧架构冲突。Benchmark 测的是首尾呼应的简单召回，而真实开发需要维持长达数万 token 的多层依赖关系。

成本与延迟：藏在账单里的体验天花板

还有一个常被发布会忽略的维度：成本和延迟。Claude 3.5 Sonnet 在复杂推理上确实比 GPT-4o mini 更细腻，但在某些区域节点，它的输出速度可能只有每秒十几到二十个 token。如果让它生成一段 2000 token 的技术方案回复，用户可能要等将近两分钟。在客服或实时协作场景里，这是不可接受的。

某中型 SaaS 公司做过一次真实测算：把后台自动化流程从 GPT-4o mini 升级到 Claude 3.5 Sonnet，每月 API 账单从约 4000 元人民币涨到 28000 元，但终端用户满意度仅从 78% 微升到 81%。这 3 个百分点的体验改善，对应的是 7 倍的成本膨胀和更慢的响应。对大多数产品经理而言，这笔账算不过来，最终选择退回到“够用且便宜”的方案。

用户活在日常的水位线里

模型厂商在发布会上展示的分数曲线是真实的，用户感觉“也就那样”同样真实。Benchmark 衡量的是峰值能力，比如模型能不能解出最难的数学题、背出最冷门的知识点。但用户的日常体验，取决于水位线——也就是模型在连续工作 8 小时里不崩溃的稳定性、调用 100 次工具里 98 次都可靠的确定性，以及成本可控前提下的响应速度。

当行业从“玩具 demo”走向“生产工具”，比拼的不再是 MMLU 上多出的那两个百分点，而是谁能在真实世界的混沌、噪声和预算限制中，把能力稳稳地交付到用户手里。那才是用户真正能摸到的“变强”。