跑分没掉队，口碑先塌了：大模型评测避坑指南

一、现象回顾：一次典型的“口碑滑铁卢”

前段时间，某厂商的新模型高调发布：参数规模与上下文窗口双双拉满，终端编程类基准得分从上一代的低两位数跃升至 65% 上下，一度逼近甚至超越多款头部模型，在国际某评测机构的智能指数中冲进全球前列；API 输出单价砍半，还承诺开放权重。按理说这是一份漂亮的答卷。

结果发布仅三天，口碑先塌了。争议集中在五件事上，且全砸在同一周。把这些争议抽象出来看，它们恰好对应大模型评测中五个最经典的“口径陷阱”。

1. 演示惊艳，但能力边界说不清

一位正在开发 3D 游戏的用户专门购买订阅去复现官方演示，屡试不成。深入排查后他发现，模型内置的一个 3D 生成技能，实际执行的是本地脚本调用外部生成服务，脚本中的版本号信息恰好与某家 3D 生成服务商对得上（该爆料者本人也声明未经完全确认）。当他强制模型只用自带代码生成时，效果大打折扣。

这里的技术实质是：“原生能力”与“工具增强能力”是两回事。演示里的惊艳效果，真正来源可能是外部服务，而非模型自身的生成与推理能力。调外部接口本身不算问题——工程上这甚至是正确做法——但如果宣传时不说清能力边界，用户的预期就会错位，落差感直接转化为口碑的反噬。

2. 基准高分，真实任务多轮翻车

另一组编程实测中，测试者给出五张参考图，要求模型用浏览器端 3D 渲染方案复刻一个可交互的游戏手柄。第一版被评价为“粗糙、偷懒，像降智的小模型”；第二版标识错误、部件空间关系有误；第三版在指出问题后承认并开始修正，眼看要成，又撞上了五小时的额度上限。同一组测试里，对照组的另一款模型是唯一会主动测量位置和空间关系的。

而这款模型在终端编程基准上的得分超过 65%。为什么高分换不来一次像样的复刻？因为基准测试大多是“单轮、有明确预期输出”的任务，而真实工程是“多轮迭代、需要自我校验”的过程。两类场景考察的能力维度并不重合。

3. 幻觉率的“口径游戏”

官方口径称幻觉率从 23% 降到 8%，但细看会发现该数字挂着“外部核查闭环”——即配备了专门的事实校验环节。而第三方在不带任何校验的裸测下，测出的幻觉率高达 44%。

两个数字未必都是假的，但它们回答的是不同的问题：前者是“带核查系统时最终交付的错误率”，后者是“模型裸奔时的原生错误率”。宣传时挑对自己有利的口径，对比时又混用口径，是评测失真的重灾区。

4. 单价降了，账单没降

官方将输出单价砍半，但第三方实测中，最高推理档位下完成一个任务耗时近五分钟、实际扣费约 0.4 美元；对照模型完成同一任务仅需约一分钟、扣费反而相近。更长的思考时间吃掉了更低的单价，甚至反超。

成本的真实构成是：单价 × token 用量 × 调用次数 × 时间的机会成本。只看单价，就像只看汽车百公里油耗却不问自己要跑多远、路况如何。

5. 额度调度与推广合规

同期还爆发了额度风波：官方在凌晨道歉，承认后台调度缺陷与子 Agent 逻辑冗余，并给全体用户补偿了约合一周用量的额度。此外，海外推广的披露合规问题也被讨论，有观点指出部分推广内容可能未按当地规则标注付费合作关系（相关文件真实性未经独立核实）。我们不对具体事件下结论，但它提示了一个通用问题：你在社交平台上看到的“自来水好评”，未必是自发口碑。

二、跑分与实测为什么脱节：三个结构性原因

其一，基准的代表性有限，且存在过拟合空间。 编程类基准由一组标准化任务构成，答案空间相对明确。厂商在训练阶段反复对着基准“刷题”，分数上升不一定意味着通用能力同步上升。尤其是终端类任务，评分往往只看“最终是否跑通”，不看中间过程的质量与收敛效率。

其二，评测环境的“温室效应”。 官方口径里的成绩，往往在最理想配置下取得：挂载了核查闭环、预置了技能与工具链、选用了最高档推理配置。用户实际使用时未必具备这些条件。评测环境与生产环境之间的差值，就是口碑的落差。

其三，选择性披露放大预期。 宣传时讲基准分数和演示效果，不讲任务失败率、多轮迭代上限、真实耗时分布。信息不对称之下，用户用真实任务遭遇的落差感，会加倍砸回口碑上。

三、方法论：开发者如何自建可信评测

与其争论谁的跑分更高，不如花一两天搭一套属于自己的评测流水线。以下六个环节建议逐条对照。

1. 分层评测：原生能力与工具增强能力分开测

为每个测试项标注能力归属：

• 原生层：直接对话生成、代码生成、逻辑推理，禁用一切工具；
• 工具层：允许调用检索、代码执行、外部生成类 API 等技能；
• 系统层：带校验闭环、重试策略的完整工作流。

三层分别记录指标，才能判断“这个效果到底是谁的功劳”，也才能识破“演示靠外部服务撑场”的情况。

2. 用自己的任务集，而不是公开基准

从真实业务中抽取 20–50 个任务，注意两个维度的混合：既要有“单轮能完成的”，也要有“需要三轮以上迭代加自我纠错”的；既要有“客观验收标准”的（能编译、能运行、输出可校验），也要有“主观验收”的（如设计还原度）。公开基准可以作参考项，但绝不能是决策依据。

3. 把“多轮迭代容忍度”纳入指标

真实工程里，第一版做错很正常，关键是模型能否在反馈后收敛、以及额度够不够它收敛。建议记录：

• 达到“可用”标准用了几轮；
• 每轮的 token 消耗与耗时；
• 是否在中途撞上额度或上下文上限。

“改到一半额度耗尽”这类失败，单轮基准永远测不出来，却是生产环境最常见的崩溃方式。

4. 幻觉率：统一口径再比较

比较幻觉率前，先对齐三个问题：是否带外部核查？样本从哪里来？错误如何判定？示意性伪代码如下：

for sample in testset:
    answer = model.generate(sample.prompt, tools=[])   # 关键：裸测，禁用一切工具
    facts  = extract_facts(answer)
    errs   = verify(facts, sample.ground_truth)
    record(sample.id, errs, context_used=0)
report(hallucination_rate = error_facts / total_facts)

同一套流程再跑一遍带核查闭环的版本，两个数字都保留——它们分别回答“模型本身有多可靠”与“系统能兜住多少”，混在一起谈就是耍流氓。

5. 成本与效率联合核算

不要只记录单价，要记录“单位任务的完成成本”：

cost_per_task = input_tokens × in_price + output_tokens × out_price + external_api_fee
efficiency    = cost_per_task / quality_score

再叠加耗时分布对比。如果模型 A 单价只有 B 的一半，但单任务耗时是 B 的四倍、多轮重试又翻倍消耗输出 token，总成本反而更高。评测报告里缺了这张账单，选型结论就不完整。

6. 评测基建：留痕、归档、可复现

评测会产生大量日志与中间产物。建议把每次评测的输入、输出、工具调用链、计费数据全量落盘到日志服务；原始产物（截图、生成文件、执行记录）归档到对象存储；用容器平台固化评测环境，保证脚本在任何机器上一键重跑；配合监控告警观察额度与算力消耗速率。这些日志服务、对象存储、容器平台、监控告警类通用云能力足以支撑一套小规模评测系统，重点在流程规范，而非工具堆砌。

四、写在最后：口碑是预期的函数

回顾整个事件，模型本身的硬实力未必差——跑分确实没掉队，翻车的核心是宣传口径与真实体验之间的落差。对厂商而言，演示讲清能力边界、指标写明测试条件，是成本最低的信任投资；对开发者而言，与其在社交媒体的评测帖之间摇摆，不如建立一套自己的分层评测流水线，把“别人怎么说”变成“我自己测出来什么”。当每个团队都用自己的任务集说话时，跑分与口碑的鸿沟，自然会收敛于它该在的位置。