842 篇博文 含有标签「ai-engineering」

你构建了一个个性化功能，将其接入应用，然后发布上线。第一周到了。系统尽职尽责地为每个新用户推送同样的几个全局热门内容——你的 AI 号称智能，却连按字母排序的列表都不如。参与度指标几乎没有变化。团队得出结论：模型需要更多调优。其实不然。模型完全按设计运行。问题在于，你要求它在没有任何可学习内容之前就开始学习。

这就是冷启动问题，它摧毁的 AI 功能比糟糕的模型多得多。

核心矛盾是循环的：行为机器学习系统需要用户交互才能产生有用的预测，但它需要产生有用的预测才能获得用户交互。某大型电商平台记录显示，冷启动影响了超过 60% 的新用户——这些用户收到了明显失准的推荐，可测量地损害了转化率。在整体指标中，这一信号几乎不可见，因为活跃用户掩盖了损失。

一家金融科技初创公司在他们的系统提示词中添加了一个逗号。第二天，他们的发票生成机器人开始输出乱码，在有人追踪到原因之前，他们已经损失了 8,500 美元。没有抛出任何错误。没有触发任何报警。应用程序继续运行，虽然错了但很自信。

这就是在生产环境中调试 LLM 的真实样子。没有指向行号的堆栈追踪。没有你可以检查的核心转储（core dump）。系统不会崩溃——它在继续运行的同时，悄无声息地产生降级的输出。传统的调试直觉不再适用。大多数工程师的反应是随机调整提示词，直到看起来好一点，然后基于三个示例进行部署，并称其已修复。结果两周后，问题又以另一种形式浮出水面。

有一种更好的方法。LLM 的故障遵循系统性的模式，而这些模式对结构化的调查有反应。这就是这套方法论。

灰度发布（Canary deployments）之所以有效，是因为 Bug 是二元的。代码要么崩溃，要么正常运行。你将 1% 的流量引导到新版本，观察 30 分钟的错误率和延迟，然后决定回滚或继续。系统会自动评分。一个糟糕的发布会大声宣告自己的存在。

AI 功能并非如此。一个开始生成微妙错误建议、过时推荐或听起来煞有介事的废话的语言模型，其 5xx 错误率为零。延迟保持在 SLO 范围内。灰度发布看起来是绿色的，而产品却在无声无息地辜负用户。

这不是工具问题。这是概念上的错位。渐进式发布背后的整个思维模型——确定性代码、自我评分系统、二元通过/失败——在你引入一个其正确性无法通过观察请求本身来衡量的组件时，就会崩溃。

用LLM智能体替换所有Zapier流程和RPA脚本的团队，往往在六个月后发现了同一件事：他们用"脆弱但可审计"换来了"灵活但难以维护"。Zapier流程以可预测的方式崩溃——第14步因API变更而失败。LLM工作流则悄无声息地出错——模型悄悄地将支持工单路由到错误的队列，直到客户升级投诉才被发现。审计日志只记录着"AI决策"，这用律师的话来说就是"没人知道发生了什么"。

答案不是回避在自动化中使用LLM，而是要有意识地判断哪些任务交给哪个系统，并架构好两者之间的接缝，使故障不会相互传染。

你发布了一个新的平台级防护栏 (guardrail) —— 一条防止 AI 讨论竞争对手价格的规则。它在周一早上上线。到了周三，你最大的企业客户提交了一个支持工单：他们的销售助手 (他们曾精心调整该助手，以便为采购团队比较供应商选项) 停止工作了。他们没有更改任何东西。你更改了一些东西，而其影响范围 (blast radius) 在无形中波及了他们。

这就是多租户提示词问题 (multi-tenant prompt problem)。允许客户定制的 B2B AI 产品实际上是在运行一个分层指令系统，但大多数团队并没有将其视为一个系统。他们将其视为字符串拼接：获取平台提示词，附加客户的指令，也许再附加用户偏好，然后调用 LLM。模型会处理剩下的事情。

模型并不能处理好。它会默默地挑选一个赢家，而你直到有人投诉才会发现是哪一个。

周一早上，一张工单传了过来：你负责的 AI 功能的用户满意度在周末下降了 18%。你打开部署日志，心里一沉。周五的发布包含了来自供应商的模型版本升级、产品团队的提示词（prompt）优化、内容审核后的检索语料库（retrieval corpus）刷新，以及因 API 字段重命名而进行的工具架构（tool schema）更新。四个变更。一次回退。完全不知道该归咎于哪个变量。

这就是多变量回归问题（multi-variable regression problem），它是生产环境 AI 系统中最难处理的一类故障。倒不是因为这种故障有多罕见——行为回退（behavioral regressions）时有发生——而是因为当团队快速迭代时，产生这种问题的条件几乎是必然的。那些看起来单独都很安全的变更堆积在一起，同时发布，最后让你在黑暗中摸索着进行调试。

每个严肃的工程团队在合并代码前都会运行一次 Lint 检查。ESLint 捕获未定义的变量，Prettier 强制格式规范，Semgrep 标记安全反模式。没有人会在不先运行至少一次静态检查的情况下将 JavaScript 发布到生产环境。

现在想想你的团队在发布一次提示词变更之前会做什么。如果你的团队和大多数团队一样，答案是：在 PR 里审阅一下，用肉眼扫描，也许手动测试几个输入用例，然后合并。你生产 AI 功能的系统提示词——控制模型如何为每一位用户表现的指令集——所受到的预部署审查比一次 CSS 改动还要少。

这个差距不是一个微小的流程疏漏。一项分析了 2,000 多个开发者提示词的研究发现，超过 10% 的提示词存在提示词注入攻击的漏洞，约 4% 存在可衡量的偏见问题——而这一切都在没有人察觉的情况下部署到了生产环境。自动捕获这些问题的工具已经存在，只是大多数团队还没有把它接入流水线。

你的 Agent 在 1 月份时运行良好。到了 3 月，它开始在 15% 的工具调用中失败。到了 5 月，它在另外 20% 的情况下会静默地产生错误输出。你的部署日志没有任何变化。没有人动过 Agent 的代码。工具定义看起来和六个月前一模一样——而这恰恰就是问题所在。

工具 Schema 并不需要被修改才会出错。它们所描述的服务在底层发生了变化。Enum（枚举）值增加了。后端重构使必填字段变成了可选字段。以前接受字符串的参数现在需要 ISO 8601 时间戳。Schema 文档保持冻结，而底层的 API 却在不断演进，你的 Agent 仍在自信地调用它，完全不知道契约（contract）已经发生了变化。

这就是 Schema 熵（Schema entropy）：你的 Agent 接受训练时所使用的工具定义与生产环境服务实际表现出的行为之间逐渐产生的差异。它是生产环境 AI 系统中最被低估的可靠性问题之一，研究表明，工具版本控制问题约占生产环境 Agent 故障的 60%。

这是一个几乎出现在每个生产 AI 部署中的模式：团队发布了一个能够处理 90% 查询的功能。然后开始收到投诉。某用户提了一个超出训练分布的问题，模型自信地给出了错误答案。RAG 流水线检索到一份过时文档，模型却将其当作最新信息来回答。一个法律查询触及了提示没有覆盖的边缘情况，模型靠猜测蒙混过关。在每一种情况下，修复方案都不是换一个更好的模型，而是让系统学会说"我不知道"。

弃权——有原则地决定不回答——是 AI 系统设计中最难、最被低估的能力之一。几乎所有产品工作都致力于让答案更好，几乎没有任何工作致力于让系统可靠地知道何时该拒绝作答。这种不对称是一种在生产环境中不断累积的设计债务。

三年前，"AI 团队"意味着一群藏在组织架构角落里的专家，对产品工程师基本不可见。如今，一位金融科技公司的高级软件工程师，周一用微调模型上线欺诈评分功能，周三为客户支持搭建 RAG 管道，周五调试 LLM 延迟问题。专家并没有消失——但"AI 工作"与"产品工程"之间的边界，消失得比几乎所有人预想的都快。

大多数团队的应对方式是把新头衔贴在旧职位描述上，然后宣告完事。这是错误的答案，功能失调很快就会显现：所有权不清、工具重复，以及一个 ML 平台团队把半数时间花在解释"为什么产品团队不能直接调 OpenAI API"上。

本文探讨如何把结构搭对——不是抽象地谈，而是针对大多数工程组织实际经历的 AI 采用阶段。

你的团队花了三天时间迭代系统提示词。评估分数从 82% 提升到了 85%。你上线了。三周后，生产指标毫无变化。发生了什么？

简短的答案是：你的评估欺骗了你。不是恶意为之，而是样本量不足加上忽视了方差。在 100 个样本的测试集上提升 3 个百分点，完全在大多数 LLM 系统的噪声底线以内。在这个规模下，你无法区分信号与随机性——但几乎没有人会在采取行动之前做这个数学验证。

这就是 LLM 评估中的统计功效问题，它正在悄无声息地腐蚀大多数 AI 产品团队的迭代循环。

每一项微调工作最终都会达成同样的直觉：更好的数据意味着更好的模型，而更好的数据意味着更高质量的样本。因此，团队会构建复杂的标注流水线，以过滤掉平庸的输出，只保留金标准回复，并基于让他们引以为傲的数据集进行训练。然而，由此产生的模型在那些最初推动项目启动的具体用例中表现不佳。这种失败如此普遍，以至于值得拥有一个专属名称：课程陷阱（curriculum trap）。

这个陷阱在于 —— 仅策划你最好、最自信、最权威的输出并不能教会模型变得更好。它教会模型的是无论是否合理都要表现出自信。你创造出的东西在演示中看起来令人印象深刻，但在生产环境中却漏洞百出，因为生产环境充满了你的策划过程系统性排除掉的混乱边缘情况。