Gemini 3.6 Flash 在纸面上表现更佳。什么会让你阻止升级？

标题数据让 Gemini 3.6 Flash 看起来像是一次直接的升级。谷歌称，在 Artificial Analysis Index 上，它比 3.5 Flash 少用了 17% 的输出 token。此外，它在 DeepSWE（49 vs. 37）、MLE-Bench（63.9 vs. 49.7）、OSWorld-Verified（83.0 vs. 78.4）和 GDPval-AA v2（1421 vs. 1349）上也有提升。输出价格也降低了，每百万 token 7.50 美元。这是一个扎实的整体表现。https://preview.redd.it/ddq9bmd41qeh1.png?width=1600&format=png&auto=webp&s=fb1f48624180d063efd9e0d67adda5193345abc9 与此同时，原始资料中的早期截图声称在前端生成和空间推理方面存在性能下降。其中提供的示例不包含原始链接、完整提示、模型设置或可复现的配置。一个示例甚至没有明确是否启用了适当的思考设置。因此，我不会将这些截图视为该模型整体更差的独立证据，也绝不认为它们是该模型是“最差”模型的证据。我的看法更简单：它们足以提出一个回归案例，但不足以定论。 整体提升和局部回归很容易共存。基准测试对其自身的任务分布进行平均。你的应用可能将大部分权重放在一个几乎不影响整体结果的类别上。一个模型可以在编码代理、知识工作和计算机使用方面有所改进，但在某个特定的 UI 模式上变得不太可靠。整体分数上升了，但你的产品仍然会出问题。 对于实际的升级决策，我会采用配对的工作负载回归测试：固定系统提示、用户提示、工具、上下文、温度、思考级别、输出限制和重试策略。在相同的代表性任务上运行现有模型和候选模型，包括罕见但代价高昂的失败案例。尽可能随机化答案顺序并对评审者隐藏模型信息。评分指标包括接受任务率、关键错误、重试次数、工具调用次数、延迟、token 数量以及每个接受结果的总成本。在查看结果之前定义拒绝门槛。最后这一点似乎尤为重要。如果团队在测试后认为偏好模型的回归“足够小”，那么评估就变成了模型推广。预先声明的门槛强制决策遵循工作负载。 我还会避免强制选择一个单一的全局优胜者。如果 3.6 Flash 在文档分析上胜出但在前端工作流上失利，那就是一个路由结果。在失败的类别中保留现有模型，并在通过门槛的类别中使用新模型。生产单元不仅仅是“Gemini 3.6 Flash”，而是模型、设置、提示、工具和工作负载的组合。 官方来源：Google 的 Gemini 3.6 Flash 发布帖子。如果你在生产环境中评估 3.6 Flash，即使整体基准测试有所提升，什么样具体的失败门槛会让你坚持使用 3.5 Flash，或者仅将部分任务路由给它？