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

几乎每个经历过初期演示阶段的微调项目，都会重蹈同一个覆辙：团队遭遇质量平台期，决定需要更多数据，增加了 50% 的样本，重新训练，却发现模型要么一如既往地平庸，要么明显变差了。增加数据的直觉对大多数软件问题是对的——更多信号通常有帮助。但微调存在一个预训练所没有的饱和区间，大多数从业者并不能识别自己何时进入了这个区间。

2024 年一项在 Qasper 数据集上测试 LLM 微调的研究发现，将训练集从 500 条扩展到 1,000 条后，Mixtral 的准确率得分从 4.04 跌至 3.28，完整性得分从 3.75 跌至 2.58。这不是超参数问题，而是数据饱和：模型开始记忆分布噪声，而非学习可泛化的模式。团队在引擎已经淹没之后，继续往里加燃油。

在 2022 年，一支团队花了三个月时间微调一个基于 BERT 的分类器，用于对客户支持工单进行分类。这是一次实实在在的胜利——准确率达到了 94%，而他们旧的基于规则的系统最高只有 70%。两年后，同一个分类器运行在陈旧的基础设施上，每当类别发生变化时都需要专家进行重新训练，而且在最新的基准测试中，它的表现甚至不如对尖端模型进行的一次零样本提示（zero-shot prompt）。没人敢碰它。开发它的工程师已经离职了。现在的团队担心弃用它会破坏某些功能。该功能就此被冻结了。

这就是“冻结功能陷阱”（frozen feature trap）。它是 AI 技术债中一种较为隐蔽的形式，且正在整个行业中蔓延。各支团队逐渐发现，曾经看起来像是护城河的东西，实际上是一个他们一直在往里砸钱的无底洞。

大多数团队在 AI 系统中加入人工在环 (human-in-the-loop) 审核后，就认为安全问题解决了。六到十二个月后，他们发现了真正的问题：人工审核员现在成了阻碍系统规模化的瓶颈，质量在无人察觉的情况下下降，而移除监督层又显得过于冒险。他们陷入了困境。

这就是 HITL 吞吐量失效。它不同于广为人知的 HITL “橡皮图章”失效（即人类不经真正审查就批准决策）。吞吐量失效更隐蔽且危害更大：审核员在尽职尽责地工作，但队列增长速度超过了团队的处理速度，延迟承诺变得无法兑现，人工层从独立验证变成了整个系统的速度限制器。

当 LLM 的输出感觉不对劲时，工程师会本能地去调 temperature。这是调试手册里最早的动作之一——调低它以获得更强的一致性，调高它以获得更多创意。这感觉很有效，因为改动简单且效果立竿见影。但这几乎从来都不是正确的做法。

Temperature 和 top-p 只是输出质量最后 10% 的因素，而不是前 90%。真正决定模型成败的变量是上下文质量、指令清晰度和模型选择——依次排列。在一个有问题的提示词之上再调整采样参数，就像给一道还没煮熟的菜调味一样。根本问题并没有消失。

大多数部署 LLM 代码审查工具的团队都会在两周内发现同一种失败模式：模型为每个 PR 生成 10–20 条评论，其中 80% 都是噪音。在第三个 PR 中，如果开发者不看就关闭了所有评论，这个工具就名存实亡了 —— 通知被发送到无人查看的频道，而机器人仍然在每次推送时消耗算力。

问题不在于模型。而在于这些团队发布了一个评论生成器，却称之为审查工具。

你的 SRE 团队非常擅长运行微服务。他们精通蓝绿部署、金丝雀发布、分布式链路追踪、SLO 消耗率告警以及复盘文化。接着，有人发布了一个由 LLM 驱动的功能，不到一周就发生了一起上述实践都无法处理的故障：模型开始生成听起来很合理但结构错误的内容，没有日志报错，没有健康检查失败，用户在任何人注意到之前已经默默地接收了四个小时的垃圾信息。

这不是技能差距，而是架构差距。运行 LLM 服务是一门与运行微服务截然不同的运维规范。如果你不明确地识别出那些无法迁移的实践，它们将会让你的团队陷入困境。

当 AI 系统犯下严重错误时，一种本能的反应似乎很合理：在流程中加入人工环节。如果一名审核员遗漏了某些内容，就增加第二层审核。如果法务部门感到不安，就增加第三层。这种级联反应给人的感觉像是安全性的复利叠加——每一个审批阶段都是另一层保护。

事实并非如此。在大多数高审核量的生产系统中，增加审批层级反而会降低 AI 的准确性，让审核员产生一种毫无实际作用的监管错觉，而且最糟糕的是，它会毒化 AI 训练所依赖的反馈信号。最终，你承担了人工审核的全部运营成本，却几乎没有获得任何安全性收益。

大多数团队都以相同的方式发现了同步 UI 的问题：用户点击"生成报告"，然后浏览器标签页陷入沉默长达四十秒。没有加载动画，没有进度提示，只有一个冻结的按钮。一半用户刷新页面并重复提交。另一半用户认为产品出了故障，直接关掉标签页。

根本问题不在于智能体的延迟——而在于 LLM 驱动的智能体所处的时间尺度，打破了同步请求-响应 UX 所有内置的假设。单次 GPT-4o 调用平均需要 8–15 秒。一个搜索网页、读取三份文档、写初稿再格式化输出的多步智能体，可能需要两到四分钟。你无法通过优化智能体来让这感觉变快，必须重新设计后端与 UI 之间的契约。

你最优秀的 AI 工程师能凭记忆背诵 Claude 的 XML 格式偏好。他们知道 Claude Opus 拒绝泛化隐式指令，知道少样本示例（few-shot examples）实际上会损害 o1 系列模型的性能，还知道在某些地区，Azure OpenAI 相比直接 API 会增加额外的 8 到 12 秒延迟。这种专业知识花了数月时间积累。它也代表了当今 AI 工程中最被低估的风险之一。

当供应商弃用某个模型或悄然改变行为时，这些知识并不会随之迁移。它会消失。那些围绕单一模型系列构建系统以及组织能力的团队，往往会以惨痛的方式发现这一点。

你的 AI 个性化系统已经学会了用户是谁。它建立了用户画像，调优了向量表示，并给出了令人惊叹的精准推荐。然后，它悄悄地开始欺骗你——不是用错误，而是用过时的"真相"。上个季度痴迷于 Kubernetes 的用户加入了一家初创公司，现在需要了解销售漏斗。买了两年婴儿用品的客户刚刚把最小的孩子送去了幼儿园。你的模型仍然以为自己认识他们，但它并不了解。这就是个性化画像衰减，这是团队只有在用户抱怨 AI"不再懂我"时才会发现的静默失败模式。

在 2023 年，“提示词工程师”（prompt engineer）是科技领域搜索频率最高的职位名称之一。LinkedIn 上到处都是重新包装个人简介的工程师。招聘信息许诺给那些懂得如何诱导 GPT-4 表现的人六位数的薪水。但职位描述中没有提到的是，其中列出的许多技能已经处于“借来的时间”中——到 2026 年，那些能够分辨出持久技能与衰减技能区别的工程师，最终的境遇将大不相同。

提示词工程的职业陷阱并不在于这个领域消失了，而在于它变化太快，以至于在 12 个月内建立的技能到第 18 个月就变成了负资产。那些在错误的层面过度投入而忽视了正确层面的工程师发现，随着下一个模型版本的发布，他们所掌握的专业知识变得毫无意义。

有一种特定的工程债（Engineering debt）永远不会出现在你的指标中。每当有人在系统提示词（System prompt）中添加一个句子来修复一个偶发的投诉——比如 “绝不讨论竞争对手的产品” 或 “始终以正式的口吻回复” ——而随后又没有人验证模型是否真的执行了它，这种债务就会累积。几个月后，提示词增加到 800 个 Token。它听起来很有权威感，包含的内容包罗万象。但也许其中三分之一根本没起作用。

提示词变异测试（Prompt mutation testing）就是找出那三分之一无效指令的实践。该技术借鉴了软件工程中经典的变异测试：系统地在代码中引入微小、刻意的错误，以确定你的测试套件是否真的能捕获它们。在这里，你向系统提示词中引入刻意的扰动——删除一个分句、抵触一条规则、用近义词替换关键关键词——并衡量模型的输出实际发生了多大变化。那些在扰动下幸存且不影响行为的指令是装饰性的。而那些一旦被触碰就会导致出错的指令则是承重的（Load-bearing）。