2 篇博文 含有标签「llm-api」

一个平台团队发布了一项质量改进。推理阶段的一个图层会读取用户的近期交互记录，并悄无声息地调整响应风格：这里更正式一些，那里更简洁一些，或者当历史记录显示是一个工程师在提问时，响应会更具技术性。A/B 测试显示，整体满意度提升了几个百分点。发布公告的标题是“更智能的响应，无需更改 API”。没有人修改 API 中的标志位。没有人更新文档。响应内容中也没有任何迹象表明模型刚刚采用了哪种人格。

六周后，一位企业客户提交了一个支持工单，称“你们的模型比宣传的要差”。他们的内部评估套件——运行的是你们团队发布基准测试时所用的相同提示词——得分低了 8 分。你团队的第一步是核实提示词的一致性。提示词完全匹配。解码参数匹配。模型版本字符串也匹配。差异最终追溯到了个性化层，它为客户新开设的测试账号推断出一个“历史记录贫乏的默认人格”，而为你衡量基准测试的长效用户账号推断出了一个更丰富的人格。关于个性化究竟是功能还是缺陷的讨论，不再仅仅是一个产品决策，而演变成了一场合同谈判。

当你的应用程序第一次从模型供应商那里收到 429 错误时，发生了一些重要的事情，但几乎没人注意到。并不是错误本身，而是接下来执行的那行代码。也许你的 HTTP 客户端会以指数退避进行重试。也许它会降级到更小的模型。也许它会将请求排队，或者直接丢弃，又或者显示一个永远无法解决的加载动画。无论它做什么，这种行为现在就是你的容量策略。它决定了当供不应求时，哪些用户能获得服务，哪些用户的体验会降级。

而且，几乎可以肯定你并没有亲自制定过这个策略。它是由编写 SDK 封装的人、重试装饰器，或者是某人从教程中复制的三行 try/except 代码决定的。在负载下，你的系统中最重要的决策——当无法兼顾所有任务时该怎么办——正由一段没人审视过的代码作为容量决策来执行。

这篇文章的观点是，你应该把这段代码视为它的真实面貌：一个负载削减策略和一个容量计划，而不是一个错误处理器。429 并不是问题所在。问题在于你已经将系统在资源竞争下的行为设计，外包给了库的默认设置。