702 篇博文 含有标签「llm」

一家医疗初创公司从某个主流前沿模型迁移到了同一供应商提供的新版本。结果是：为了恢复功能对等（feature parity），耗费了 400+ 个工程小时。新模型每次响应生成的 token 数量是原来的五倍，抵消了预期的成本节省。它开始提供未经请求的诊断建议——这带来了合规性风险。而且它破坏了下游的所有 JSON 解析器，因为它把响应包裹在了 Markdown 代码块语法中。同一供应商，不同的模型，却是推倒重来。

这就是供应商抽象税（provider abstraction tax）：它不是切换供应商的成本，而是不为此做规划所产生的累积成本。它不是一次性的迁移事件，而是一个持续的消耗——你在升级三周后发现的行为退化、无法跨模型迁移的提示词工程工作，以及因为某个供应商分别计算输入和输出 token 的速率限制而导致静默失败的重试逻辑。直接在单一供应商之上构建系统的团队会无形中积累这种债务，直到收到弃用通知或价格变动通知时，账单才会一次性结清。

我尊重的一位资深分析师这样描述她的团队在使用大语言模型 (LLM) 驱动的分拣代理的前六个月：“它让简单的告警消失了，却让复杂的告警变得更难信任。”这句话一直让我记忆犹新，因为它捕捉到了这项权衡的本质。安全运营中心 (SOC) 中的 AI 并不是一个关于效率提升的故事。它是一个关于信心校准的故事，而大多数团队都在朝着同一个错误的方向进行校准。

诱人的版本是：在告警队列前放置一个模型，让它聚类重复项、总结原始事件并自动关闭明显的噪音。MTTR（平均响应时间）图表下降了。寻呼机安静了。一级告警积压蒸发了。而真正导致你被入侵的版本是：模型自信地将一次真实的入侵误判为无害的备份作业，而一名疲惫的分析师——被告知“AI 已经分拣过了，没问题”——甚至从未打开过这个案例。第一个版本是真实的，第二个版本也是。它们是同一个系统在不同信心水平下的表现。

检查你代码库中每一次 LLM 调用里的 max_tokens 参数。如果你和大多数团队一样，这个参数要么没设置，要么设成了模型的最大值，或者是半年前随便选的一个像 4096 这样的整数，之后就再也没动过。它是 API 请求中一个显眼的预算旋钮，却在默默地为你从未使用过的冗余买单。

在中等商业模型上，输出 token 的成本大约是输入 token 的四倍，而在昂贵模型上甚至高达八倍。生成步骤的经济效益完全是失衡的：你在 max_tokens 中留下的每一分未使用的余量，都是你可能需要支付的成本；而且由于解码是顺序进行的，你生成的每一个 token 都会线性地增加你的 P50 延迟。然而，大多数生产系统都将此参数视为安全阀——设置得高高的，然后忘掉它，继续开发。

一个团队花了三周时间集成一个基础模型，将收到的支持工单分类到不同的路由类别中。该模型在测试中达到了 87% 的准确率。他们发布了。六个月后，一名工程师注意到 70% 的工单在主题行中包含产品名称，而一个简单的查找表就能以 99% 的准确率处理这些工单。LLM 正在处理那困难的 30%，而在其余时间里则在胡言乱语。

这并非一个少见的故事。之所以会发生这种情况，是因为团队将“使用 LLM”作为首选的实现方案，而不是最后的手段。解决方法是设立一个强制性的关卡：在被允许构建 AI 版本之前，你的 AI 功能必须先输给一个笨规则。

2026 年 1 月，OpenAI 仅提前两周通知便将若干 GPT 模型从 ChatGPT 中退役——而就在此前不久，其 CEO 刚刚在公开场合承诺在此次退役后会"提前充分通知"。对于那些已将工作流构建在这些模型之上的团队而言，这份公告无异于周五下午收到的一条页面报警。那一次 API 未受波及，但下一次未必如此。

你当前调用的每一个模型都有弃用日期。部分日期已列在供应商的文档页面上，另一些尚未宣布。操作层面的问题不是你的生产模型是否会被退役，而是你能否在问题发生前及时收到通知并从容应对，还是在用户开始遭遇故障后手忙脚乱地迁移。

大多数团队选择 LLM 的方式就像选择数据库引擎一样：在架构评审时选一次，然后再也不改。你选了 GPT-4o 或 Claude 3.5 Sonnet，把它写进配置文件，然后上线。这个选择感觉无法逆转，因为更改它需要重新部署、跨服务协调，以及针对本周 eval 的回归测试。

这种思维方式是错误的。你的流量并不是同质的。"总结这篇文档"和"调试这个神秘堆栈跟踪"两个请求同时打到同一个接口，对能力的需求天差地别——但从静态模型选择的基础设施视角来看，两者毫无区别。你要么对其中一个过度供给，要么对另一个供给不足，而且每一个请求都是如此。

模型路由将 LLM 的选择视为运行时分发决策。每个进入的查询都会根据能预测该请求最合适模型的信号进行评估，并据此进行分发。路由层不存在于配置文件中——它运行在你的请求路径上。

你的摘要步骤判断出客户投诉是关于账单的。你的提取步骤提取出了“订阅层级：Pro”。你的生成步骤写了一封跟进邮件，提到了他们的“Enterprise 方案”。三次 LLM 调用，一个流水线，一个完全错误的输出 —— 而且整个过程中没有触发任何错误。

这就是多模型一致性失效：复合 AI 系统的无声杀手。它看起来不像是一个异常。它不会触发你的错误率 SLO。它只是自信地向用户发布错误的内容。

大多数 LLM 工程经验 —— 缓存提示词、调整温度、控制 token 预算 —— 都假设输入是文本、输出也是文本。一旦加入图像、PDF 或音频，这些经验几乎全部失效。预处理方式不同，故障模式不同，成本模型也不同。而你为文本流水线构建的评估套件，根本发现不了新出现的问题。

企业知识中约有 50% 存储在非文本格式中：PDF、幻灯片、扫描表单、产品图像。当团队尝试处理这些数据时，他们会发现，引入多模态不仅仅是增加一种模态 —— 而是增加了一个全新的工程复杂度层面。

告警在凌晨 2:47 响起。面向客户的聊天助手正为一半的付费用户返回 429 错误。工程师们在仪表板中忙乱寻找，试图找到那天下午发布的 Bug。他们一无所获 —— 代码没问题。真正的罪魁祸首是另一个团队在当晚启动的批量摘要任务，它共享了同一个供应商 API 密钥，耗尽了该账户接下来四小时的每分钟 Token 预算。没有人拥有这个共享密钥，也没有人负责这个限制。

这就是“喧闹邻居”（noisy-neighbor）问题。与经典的 API 配额事故不同，它在 LLM 系统中表现出一种独特的残酷性。一个达到速率上限的 REST 端点会迅速失败并进行重试；而 LLM 的“每分钟 Token”（TPM）桶是根据请求内容非对称消耗的。因此，一个生成 8K Token 的功能可能会使一个进行低成本 200 Token 分类调用的功能陷入饥饿，而这一切在请求计数图表中甚至都不会显现。流量在你所测量的维度上并不“喧闹”。

大多数团队发现这一点的方式正如上文提到的团队：一个无关团队的任务与付费用户的会话发生冲突，而两者唯一的共同点只是环境变量中的一个字符串。

你的组织有一份隐私政策。它用合理的措辞描述了用户数据的谨慎处理、保留限制以及对 GDPR 和 HIPAA 的合规。但它几乎肯定没有说明：在任何策略控制生效之前，用户的姓名、电子邮件地址或病史是否以明文形式传输给了托管的 LLM API。

这个缺口——你能指出的隐私政策与你实际能证明的隐私保证之间的距离——正是大多数生产 LLM 系统悄然失守的地方。研究显示，提交给 ChatGPT 和 Copilot 等工具的提示词中，约有 8.5% 包含敏感信息，包括 PII、凭据和内部文件引用。在企业环境中，用户将邮件、客户数据和支持工单粘贴到 AI 辅助工作流程中，这一比例几乎肯定更高。

问题不在于开发者粗心大意。而在于 LLM 提示层从未被设计为数据处理边界。它从上游系统——用户输入、RAG 检索、智能体上下文——继承内容，却不执行治理整个技术栈其他部分的数据分类规则。

有一家公司每位用户每月收费 50 英镑。其 AI 功能消耗了 30 英镑的 API 费用。这意味着在支付任何一笔退款或处理任何一个流失席位之前，剩下的 20 英镑还要覆盖主机、支持和利润。他们打造了用户喜爱的产品，发展到数千名订阅者，却在不知不觉中构建了一个客户越多、亏损越多的商业模式。

这并非关于坏主意的警示故事，而是关于定价架构的警示故事——这套架构从一个下一个用户边际成本几乎为零的世界照搬而来。当你的产品需要调用语言模型时，那个世界已不再完全适用。

传统 SaaS 毛利率为 70–90%。以 AI 为核心的公司报告的数字是 50–60%——差距主要由一行成本解释：推理。当 Token 占据销售成本的 20–40% 时，标准 SaaS 打法就会失效。

上个季度，一家中型AI初创公司的系统提示词中落地了一个单行变更。这个差异看起来无害：一位工程师收紧了关于响应长度的指令。审查者在两分钟内批准了它，就像批准一个变量重命名一样。48小时内，支持工单激增。模型开始在复杂查询的句子中间截断答案，而旧措辞几个月来默默处理的边界情况现在都失败了。原来的指令不仅控制着长度——它隐式地锚定了模型关于何时一个主题已经完成的判断。没有人捕捉到这一点，没有人去寻找它。

这就是当今提示词审查的核心问题：我们正在将代码审查的直觉应用于一个这些直觉大多数是错误的媒介。代码审查之所以有效，是因为被审查的工件是确定性的，语义可以从语法中恢复。提示词两者都不是。它的含义分布在模型的权重、训练数据以及推理时运行的随机采样中。你在屏幕上看到的差异只是你正在批准的变更的一小部分。