跨国深谈← 返回←模型路由为什么还没解决：Amazon Nova 负责人的实话

模型路由为什么还没解决：Amazon Nova 负责人的实话

关联

人物 Michael Giannangelli

公司 Nova

概念 模型路由 · 评估 · 智能体 · RLGym · 迁移

新模型发布了，能力可能没好两倍，但成本却是两倍 。这是他的判断。他说企业界正在经历一个转向：从”给我最好的模型”变成”每个 token 花出去，产出到底够不够” 。

【背景】Michael 指 Amazon Nova 产品负责人 Michael Giannangeli。

模型路由：听起来简单，实际远未解决

理论上，模型路由就是根据任务自动把请求分给合适的模型——简单任务用小模型省钱省延迟，难的才上大模型。但 Michael 的原话是：“我认为这远未成为一个已解决的问题” 。

核心困难不在技术实现，在于你没法衡量”好”长什么样。评估是多维度的：准确性、推理是否正确、输出是否合理、延迟、成本 。

构建一个稳健的评估本身就不容易，而更麻烦的是模型进步太快——你两个月前建好的评估，可能所有模型都跑到 100% 了，这个评估就饱和了，对路由来说毫无价值 。他举了 Nova 2 发布时的例子：他们针对多轮多工具使用建了一个评估，早期准确率大概 50%，发布后几个月就全满了 。编码基准也一样，SweeBench 去年还是标准，转眼模型就冲到 70%、80%、90%，不再有区分度 。

所以模型路由需要持续迭代评估，每次新模型出来都要重新校准——“这让人精疲力竭” 。

评估怎么建：从真实失败模式出发

Michael 区分了两类东西：评估和公共基准。基准是给外界看信号的，比如”这个模型在迁移或 Web 应用上还行”，但非常窄，现实里未必适用 。真正有用的是评估，而且必须扎根于真实失败模式 。

他们的做法是：每次模型失败——不管是客户反馈还是自己用的时候碰到的——只要不是一次性问题，就建一个评估来衡量它，然后证明模型在这个失败模式上确实改进了 。评估列表会越来越大，饱和了再删，他们在谈的是数百个评估的规模 。

数据来源呢？他们不在客户数据上训练，除非有明确许可 。

真正的高可见度来源是内部用例——亚马逊员工用 Claude Code、Kiro 等工具时，可以选择加入追踪，他们能识别出模型做错的轨迹，围绕这些建评估，再转成训练数据，形成闭环 。Michael 认为这是大公司的一个真实优势：Anthropic、OpenAI、Mistral 没有那么多内部使用数据可以挖 。

RLGyms：让模型在模拟环境里试错学习

【背景】RL 即强化学习(Reinforcement Learning)，Gym 指训练环境。

RLGym 的思路是建一个模拟环境，模型在里面尝试任务、失败、学一点、再试，通过反复试错变强 。结构和评估很像——都有任务、harness、工具、验证器——但区别在于评估只衡量好不好，RLGym 还让模型从失败中学习，生成的数据直接用于训练 。

例子不限于 LeetCode 式的编程题。Michael 说现在更有价值的方向是拿真实环境来建——客户正在用模型做但模型还不太行的事情，比如某些迁移任务，最好的模型可能只有 10% 的准确率 。

具体领域包括迁移、DevOps、渗透测试、漏洞检测 。资源有限，所以有优先级：选对客户重要、对业务重要、且亚马逊有独特数据的领域，DevOps 就是一个例子 。

迁移会变成自主的吗？

长远看，Michael 认为迁移这类任务会 mostly autonomous（大部分自主完成），不需要太多人在回路里 。理由很直白：工程师本来就不喜欢做迁移 。随着上下文窗口变大、harness 变好，智能体会跑越来越广的迁移任务 。

但现实比”一对一翻译代码”复杂得多。老代码库可能 20 到 40 年前的，人们想在迁移的同时做现代化——业务逻辑还合理吗？

要整合吗？要重写吗？

这就无限复杂了 。所以信任需要时间建立。

Michael 描述了一条渐进线：从人做所有事，到人交出更多任务，到五五开，到人只在关键节点检查 。“我们还远没到智能体做所有事的阶段，但正沿着这条线移动” 。

还有一个数学问题：即使智能体单轮 90% 准确，多轮下来可靠性会急剧下降 。所以到”完全不用操心”或者”比人强”的程度，还需要时间 。

瓶颈转移：从工程工时到”做对东西”

Michael 说现在瓶颈已经不在工程工时了 。真正的问题是：你在构建对的东西吗？

你迭代得够快吗？你从一线拿到反馈了吗？你能闭环然后快速发布吗 ？

所以产品角色的价值没有消失。智能体让每个人都更高效，你可以用更少的人做更多事 ，但”做对东西”这件事仍然需要人。

他认为界限在模糊——他自己上周就发了第一行生产代码——但角色不会完全合并，PM、工程师、设计师各有帮助团队跑更快的作用 。他的建议很简单：快速发布，不需要完美，拿到真实反馈再迭代 。不是 MVP 变更小了，而是你能更快到达 MVP 。

对于个人，他的建议是保持平衡：大部分精力聚焦在你在构建的目标上，但留 10% 到 20% 的时间尝试新东西 。不要对这些模型或工具能做什么产生假设，因为每天都有新模型出来，实际能力可能已经超出你的认知 。

本集带走

• 模型路由的核心难题是评估，不是路由本身：你先得能多维度衡量”好”，而评估会随模型进步迅速饱和，需要持续重建。
• 评估要从真实失败模式出发，不是公共基准：基准窄且容易过时；每次非一次性失败都该建一个评估来追踪改进。
• RLGym 的价值在真实环境，不在练习题：拿客户实际在做但模型还差的场景（迁移、DevOps、安全）建模拟环境，让模型试错学习，比 LeetCode 式任务有价值得多。
• 多轮任务可靠性是数学问题：单轮 90% 准确率，多轮下来可靠性会骤降——这是自主智能体还不能”放手”的根本原因之一。
• 瓶颈已从工程工时转向”做对东西”：快速发布、拿真实反馈、闭环迭代，比追求完美重要得多。
• 留 10-20% 时间试新东西：不要对模型能力形成固化假设，每天出新模型，你的认知可能已经落后了。

新模型发布了，它可能并没有好两倍，但成本却是两倍。
A newer model comes out and it is maybe not twice as good, but the costs are twice as much.
—— Michael Giannangelli · [05:59]

所以你可能有一个两个月前运作良好的评估，但随着模型变得更好，现在也许那个评估已经饱和了，所有的模型都达到了那个标准。
And so you may have had an eval that worked well two months ago, but as the models get better, now maybe that eval’s saturated and all of the models are meeting that.
—— 嘉宾 · [10:33]

所以现在那个评估对于模型路由来说毫无价值。
So now that eval is worthless for model routing.
—— 嘉宾 · [10:45]