模型选择器是一条死路（9分钟阅读）

# 模型选择器是一条死胡同 | Lovable 来源：https://lovable.dev/blog/the-model-picker-is-a-dead-end 打开几乎任何一款 AI 产品，你都会在角落里看到同一个下拉菜单。在你能做成任何事情之前，你先有一项任务：选一个模型。也许还要决定它应该花多大力气去思考。 这个选择很重要。某个模型可能非常擅长追踪一个棘手的 bug，但在设计上却出奇地差。另一个模型能做出漂亮的界面，但在长时间的构建中却会迷失方向。然后一个新的模型发布了，排名又变了，或者价格也变了。 把某个模型称为“最好的”，等于假设前沿技术有一顶王冠。它没有。如果选择哪个模型会改变你的应用能否正常工作，你就不应该在工作开始之前就必须猜对。 在 Lovable，这就是模型无关（model independence）的意义。我们不把模型当作可互换的。我们是模型无关的，因为我们对模型有着深刻的见解。 ## 模型无关，而非模型漠不关心 模型漠不关心意味着把所有模型放到同一个接口后面，给它们同样的指令，然后换一个名字而已。真正的模型无关意味着了解每个模型最适合怎么用。 我们在 Lovable 有一个团队专门做这项工作。对于每个模型，他们会根据它的强项来调整指令、工具和项目上下文。他们研究它在什么地方会卡住——是在冗长的调试循环中、配置后端时、打磨界面时，还是在其他完全不同的地方。然后他们会在完整的构建中测试整套配置。 例如，在其中一个评估中，一个前沿模型比它的前代完成任务快了 15%，少用了 40% 的轮次，分数高了 2–3%。这些都是实实在在的提升，让这个新模型在当时成为更强的选择。 我们可以投入大量资源让一个模型在 Lovable 内部良好运行，当更好的东西出现时仍然可以继续前进。可移植性给了我们这种自由，而不会浪费我们学到的关于模型行为差异的知识。 ## 控制平面就是产品 “给我的应用添加支付功能”听起来像一条指令。在 Lovable 内部，这个请求会启动一个应用构建智能体。这个智能体从你的请求开始，一路把构建推进到可用的改动，并对沿途发现的一切做出反应。 它必须理解你的意图，找到项目的相关部分，规划改动，编写代码，运行应用，然后看看是否有效。如果出了问题，正确的恢复路径并不总是显而易见的。系统应该重试、改变计划、使用另一个工具、引入一个推理方式不同的模型，还是向你提问？ 答案取决于构建过程中发现了什么。一个简单的请求可能暴露出一个架构问题。或者第一次尝试可能表明，模型理解了目标，但在某个工具上遇到了困难。 这就是为什么控制平面要实时观察工作进展：你想做什么，任务变得有多困难，智能体是在取得进展还是开始原地打转。然后控制平面可以把构建的不同部分分配给不同的模型，而不是要求一个模型独自搞定所有事情。 控制平面还会围绕模型调整整个系统。在一次评估中，一个模型不断重新读取已经在上下文中的文件，并在成功编辑后再次检查它们。我们给了它不同的指令：信任上下文，信任编辑结果，跳过多余的工具调用。我们还可能改变工具、我们解释工具的方式、模型看到的项目上下文量，以及在下一步之前长构建如何被总结。 这不是模型轮盘赌。我们不是把同一个提示词发给五个模型，然后挑一个最喜欢的答案。我们给每个模型适合它的指令、工具和上下文，然后判断应用是否变得更好。 ## 模型无关并不意味着频繁切换 在构建过程中更换模型可能会让事情变得更糟，因为一个长时间运行的项目会积累历史。智能体已经探索过文件、尝试过方法、遇到过错误，也学到了什么才是重要的。模型只是那个智能体的一部分。当模型改变时，我们可能不得不压缩那段历史并重建它的缓存上下文。对话中的一些细节可能只以摘要的形式存活下来。 这意味着一个模型可能在单独评估时更好，但对于手头的构建来说仍然是错误的选择。我们的控制平面必须权衡可能的收益与可能丢失的上下文以及可能重复的工作。目标不是尽可能频繁地切换模型。一次有价值的切换必须值得付出代价。否则，我们只是在制造模型折腾。 决定是否切换，首先要弄清楚系统为什么失败。有时应用构建智能体会通过一个 vent 工具（https://lovable.dev/blog/we-gave-our-agent-a-vent-tool）直接告诉我们，把那些本来很难看到的问题浮出水面。 如果某个模型提供商过载，Lovable 可以通过另一家提供商把下一次调用发送给同一个模型。这可以解决可用性问题，但解决不了方法不对的问题。如果上下文不对、某个工具令人困惑，或者模型误解了任务，更换提供商只会放弃缓存而没有解决失败的根本原因。带着用户反馈重试可能会有帮助。否则，换一个不同的模型可以尝试另一种方法。 恢复应该改变那个失败的东西——无论是上下文、计划、工具还是模型。 ## 应用本身才是基准 一个模型可以给出令人印象深刻的答案，却仍然给你留下一个坏掉的应用。它可以写出看起来很有说服力但永远跑不起来的代码，或者创建一个看起来成品级的结账页面却保存了错误的数据。在基准测试中，答案看起来可能很棒。在浏览器里，可能就是另一回事了。 所以 Lovable 的优化单位是成品应用。我们关心整个轨迹：系统尝试了什么，在哪里恢复了，构建花了多长时间，花费了多少成本，以及最终的应用是否做了你要求的事情。 这改变了“快”和“便宜”的含义。一个模型可以响应很快，但如果它需要三倍的轮次才能完成，它仍然是慢的。一次便宜的调用如果让构建走上了错误的道路，就会变得昂贵。即使是一个出色的计划，也只有当系统能把它变成可工作的软件时才有意义。 公开排行榜可以引导我们发现有前途的模型，但它们无法告诉我们这些模型是否能在 Lovable 内部产出更好的应用。我们在 Lovable 内部使用我们自己的提示词、工具、上下文和智能体循环来测试每个候选模型。我们每次构建都会运行多次，因为一次漂亮的结果可能是运气。一个表现良好的模型从小工作量开始，只有持续交付才会获得更多。 测试也必须赢得我们的信任。我们寻找人工判断、我们的 LLM 评审，以及我们根据外部证据预期的模型排名之间的一致性。当这些信号不一致时，我们会检查构建结果并找出原因。在一次对比测试中，这让我们重新校准了一个把空洞的构建排在很前面的评审，并换掉了另一个给几乎相同的构建打出相反分数的评审。 那些能够持续产出更好应用的模型会获得更多工作，由人工判断作为最终检查。 ## 有时正确的模型是我们自己的 通过往提示词里多加一段话来获得的改进是有限度的。例外情况不断堆积，一条指令修复了一个失败，却把模型从其他事情上引开。最终，再修改一次提示词也不再有帮助了。有些工作出现得足够频繁，用一个专门模型更合理。 这就是我们开始训练自己的模型的地方。路由请求、总结回复和编写提交信息给了我们定义清晰的任务，让我们学习如何训练、评估和发布模型。 现在，我们的后训练模型正在生产中处理相当大一部分应用构建工作。我们将训练下一代模型来处理更难的问题和更多构建环节。 我们自己的模型仍然经过与外部模型相同的控制平面。如果一个外部模型在某项工作上变得更好，它可以取代我们自己的模型。即使是我们自己训练的模型也必须赢得它们的流量。我们的雄心是为 Lovable 最了解的领域构建世界上最好的模型。 ## 我们学到的东西会延续下去 任何公司都能买到前沿模型的使用权。难的是构建一个系统，能够把它不均衡的、快速变化的优势转化为人们可以依赖的软件。每一次失败都有助于改进它。每一次失败都成为一个测试，告诉我们提示词、工具、上下文、编排、评估器或模型哪个需要改变。我们重新运行构建，然后把学到的东西反馈回控制平面。 当新模型发布时，这些学习成果会延续下去。Lovable 会让它通过一个已经知道优秀是什么样的系统，并找到它的能力适合的位置。 一个模型公司可以改进它的模型。Lovable 可以改进整个系统。 ## 整个前沿都应该为你服务 基础模型会继续变得更好。只是它们不会在同样的事情上、以同样的速度、或者按照任何人预测的顺序变得更好。 当一个模型在推理、速度或某个重复任务上突飞猛进时，Lovable 应该在它起作用的地方让它发挥作用。当它落后时，Lovable 应该继续前进。 模型选择器是一条死胡同，因为它在对问题还没有足够信息之前就冻结了决定。Lovable 应该持续观察工作进展，使用任务所需要的模型，并在证据改变时改变方向。 你告诉 Lovable 你想构建什么。前沿可以继续在你脚下移动。我们的工作就是跟上它，这样你就能构建出人们喜爱的软件。