21 篇博文 含有标签「llm-engineering」

你对模型进行了安全微调。评估套件显示它以 98% 的比率拒绝有害请求。然后你将它部署到生产环境，你的医疗文档助手开始对常规临床术语含糊其辞，你的法律研究工具拒绝总结涉及暴力的判例法，你的代码生成流水线给每个 shell 命令包裹了三层警告。完成率下降了 15%。用户满意度暴跌。模型更安全了——但也更没用了。

这就是对齐税：安全训练对语言模型施加的可衡量的任务性能退化。每个交付 LLM 驱动产品的团队都在支付这笔税，但大多数团队从未量化过它——更少有人知道如何在不牺牲所需安全属性的前提下降低它。

在每个 AI Agent 项目中都有一个特定的时刻——框架不再帮忙了。你发现自己花在阅读框架源码上的时间比写业务功能还多的时候，你就知道这个时刻到了。那些本该帮你屏蔽复杂性的抽象，反而成了复杂性的主要来源。

这就是抽象反转问题：当一个框架迫使你在高级抽象之上重新构建底层原语——而这些高级抽象本来就是为了隐藏这些底层原语而设计的。这个术语来自计算机科学，它描述的是当抽象层缺少你需要的逃生通道时会发生什么：你最终不得不在抽象之上重新构建底层能力，代价更高，用起来也更别扭，还不如一开始就不用这个抽象。

在 AI 工程领域，这个问题已经泛滥成灾。团队采用编排框架期望加快速度，几周内就撞墙，然后花几个月时间来绕过这个本该加速他们的工具。

你的 AI Agent 刚刚为了回答一个只需要两次调用的问题，进行了十二次 API 调用。你没有注意到这一点，因为工具调用没有 EXPLAIN ANALYZE，没有 ORM 分析器来标记问题，而且 Agent 最终还是得到了正确答案 —— 只是晚了两秒钟，且 Token 预算超支了三倍。

这就是 N+1 查询问题，它已悄然从数据库层迁移到了你的 Agent 工具调用层。坏消息是：这种故障模式与 2010 年代毒害 Web 应用程序的模式完全相同。好消息是：那个时代的解决方案几乎可以直接移植过来。

你的 AI Agent 在开发阶段的成本比你想象的要低，但在生产环境中的成本却远超你的预料。API 账单——大多数团队针对其进行优化的指标——仅占在生产环境中运行 Agent 真实总成本的 10–20% 左右。其余部分则隐藏在大多数工程预算从未明确建模的层级之中。

这很重要，因为决定大规模部署 Agent 并不是一个真正的技术决策。而是一个单位经济效益决策。那些基于不完整成本模型做出决策的团队，正是六个月后报告投资回报率 (ROI) 为负的那些团队。

你使用 GPT-4 生成了 50,000 个合成的指令遵循示例，在这些示例上微调了一个较小的模型并将其部署，结果看起来非常棒。六个月后，你的团队重复了这一过程——只不过这次为了节省成本，你使用微调后的模型来生成示例。第二个模型的评估结果略低，但在噪声范围内。你以同样的方式微调了下一个版本。到第四次迭代时，你的模型输出呈现出一种奇怪的同质化。用户反馈它听起来像机器人。它在处理任何不符合狭窄模板的内容时都显得很吃力。你最强大的微调模型已经变成了最糟糕的一个。

这就是模型崩溃（model collapse）——当大语言模型（LLM）使用其他 LLM 生成的数据进行训练时，会发生渐进式的、自我强化的退化。这并非理论上的风险。它是一种有据可查的故障模式，具有可衡量的机制，并且越来越有可能影响那些在没有仔细思考反馈动态的情况下就将合成数据生成常态化的团队。

大多数工程师对待智能体工具的方式与编写 REST 接口或库函数如出一辙：清晰地暴露功能、记录参数、处理错误。这对人类来说是正确的直觉。但对于 AI 智能体（AI Agents）来说，这完全是错误的。

智能体使用的工具是以非确定性的方式被消耗的，它被逐个 Token 解析，并由一个对上周二使用过什么工具没有持久记忆的模型来选择。你编写的工具 Schema 并不是文档——它是运行时提示词（runtime prompt），在推理时被注入到模型的上下文中，塑造着智能体做出的每一个决策。每一个字段名称、每一段描述、每一个返回值的结构都是一个设计决策，具有可衡量的性能影响。这就是智能体-计算机接口（ACI，Agent-Computer Interface），它值得你像对待任何关键的面向用户的界面一样投入工程精力。

大多数 AI 智能体之所以昂贵，是因为一个细微的架构错误：它们将每一个中间结果都视为要反馈给模型的消息。每一次工具调用都变成了 LLM 上下文窗口的一次往返，而当一个中等复杂度的任务完成时，你已经为处理相同的数据支付了五次、十次、甚至二十次的费用。一个在三个分析工具之间传递的 2 小时销售录音，可能在路由上就花费你 50,000 个 token —— 而这还不是为了分析，仅仅是为了路由。

有一种更好的方法。当智能体编写并执行代码而不是逐个调用工具时，中间结果会保留在执行环境中，而不是上下文窗口中。模型看到的是摘要和过滤后的输出，而不是原始数据。这种差异不是渐进式的 —— 在实际工作负载中，token 消耗量减少了 98–99%。

大多数构建 AI 智能体的团队都将模型视为固定不变的产物。你选择一个基础模型，编写提示，连接一些工具，然后发布。如果智能体开始出错，你会调整系统提示或切换到更新的模型。在这种框架下，学习发生在“上游”——在 AI 实验室中，在预训练和 RLHF 阶段——而不是在你的技术栈中。

这是一种错误的思维模型。随着时间推移而改进的智能体，是在三个不同的架构层面上实现这一点的，其中只有一个层面涉及修改模型权重。了解这一区别的团队能够构建出质量持续提升的系统；不了解的团队则会不断手动修补相同的故障模式。

大多数构建 AI Agent 的团队花费数周时间进行部署前评估，却几乎不测量 Agent 在生产环境中实际的行为。这正好本末倒置了。真正重要的指标——Agent 无监督运行的时长、寻求帮助的频率、承担的风险程度——只有在运行时，跨越数千个真实会话之后才能浮现。不去衡量这些，等于盲目飞行。

一项针对数千次生产部署和软件工程会话的大规模研究，揭示了一些真正令人意想不到的发现。呈现出来的图景，与大多数构建者的预期大相径庭。