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

你的 AI 功能顺利上线了。延迟很低，错误率微乎其微，HTTP 响应全是 200。六个月后，一名用户抱怨聊天机器人言之凿凿地推荐了一款你在三个月前就停产的产品。工程师深入调查后发现，系统在回答用户问题时，有三分之一的情况都是错误的——这不是因为代码部署出了问题，也不是因为依赖项升级，而是因为时间的流逝。你将一张快照交付到了奔流的河水中。

这并非假设。行业数据表明，91% 的生产环境 LLM 在部署后的 90 天内会出现可衡量的行为漂移。一个最初能在无需人工干预的情况下处理 70% 查询的客户支持机器人，到第三个月时，这一比例可能会悄然下降到 50% 以下——而此时，基础设施仪表盘全程显示的都是代表正常的绿色。“六个月悬崖”是真实存在的，它是无声的，而且大多数团队并没有能够预见其到来的监测手段。

一家电信公司发布了一款 AI 客服聊天机器人，拥有 99.99% 的可用性和低于 200ms 的响应时间 —— 每一个传统的 SLA 指标都显示为绿色。然而，在 35% 的账单查询中，它的回答都是错误的。没有任何合同条款涵盖这一点。没有任何警报触发。客户只是悄然流失。

这就是 AI 的“西瓜效应”：系统表面看起来很健康，内部却在悄悄腐烂。传统的可靠性 SLA —— 可用性、错误率、延迟 —— 是为确定性系统构建的。它们衡量的是你的服务是否回答了问题，而不是回答得好不好。在传统的 SLA 下发布 AI 功能，就像保证你的支持团队发送的每封邮件都能送达，却不对回复内容是否合理做任何承诺。

当一个人脸识别系统报告95%的准确率时，你的第一直觉是发布它。但这个直觉是错的。同一个系统可能同时对深肤色女性的错误率高达34%，而对浅肤色男性只有0.8%——40倍的差异，完全隐藏在那个令人安心的聚合数字里。

这就是聚合准确率幻觉，它正在摧毁从招聘到医疗保健再到语音识别等各个行业的生产AI功能。这种模式在结构上与辛普森悖论相同：一个在聚合层面看起来公平的模型，可以同时在每个有意义的子群体上进行系统性歧视。聚合指标是加权平均值。当某些子群体在评估集中数量较少或代表性不足时，其失败率会被多数群体的成功所稀释。

修复方法不是换一个不同的准确率阈值，而是分类评估——按子群体计算性能指标，定义差异SLO，并像监控延迟和错误率一样在生产中持续监控它们。

常见的失败模式不是构建了不起作用的AI功能，而是在不知道功能是否有效的情况下就将其上线。团队跳过评估基础设施的原因不是懒惰——而是构建评估需要标注数据，而在第一天你根本没有。

这就是评估的冷启动问题。要获得有效信号，你需要系统在生产环境中运行。要有信心地部署，你首先需要评估基础设施。这种循环依赖是真实存在的，它导致团队做出三种选择之一：没有评估就上线，在生产环境中才发现故障；延迟上线，同时花数月时间手动标注数据；或者使用合成评估——并承担其中的所有风险。

本文讨论的是第三条路如何正确走通。合成评估冷启动是可行的，但前提是你要理解它无法检测什么，并从一开始就围绕这些盲点进行设计。

大多数团队都是通过惨痛的教训才发现系统提示词蔓延（System Prompt Sprawl）问题的。AI 功能发布了，用户发现了边缘情况，而修复方案总是如出一辙：增加另一条指令。六个月后，你就有了一个 4,000 token 的系统提示词，没人能完全记在脑子里。模型开始执行一些并非初衷的任务——不是因为它坏了，而是因为你写的指令之间存在细微的矛盾，而模型正悄悄地代表你处理这些矛盾。

蔓延并不是一种灾难性的故障。这正是它的危险之处。当你的指令发生冲突时，模型不会崩溃或抛出错误。它会做出选择，通常很流利，通常看起来很合理，而且通常错误得刚好足以成为真正的支持负担。

大多数生产环境中的多智能体系统都采用单一的温度（temperature）值——这个值通常是从教程中复制过来的，设置一次后就再未改动，并应用于流水线中的每一个智能体。分类器、生成器、验证器和格式化器全都运行在 0.7，仅仅因为 README 是这么写的。这等同于给每个数据库查询都设置相同的超时时间，而不论它是点查询还是全表扫描。在开始调试那些看似模型错误、实则是采样策略错误的故障模式之前，一切看起来都很正常。

温度并非一个全局性的旋钮。它是一个基于角色的策略决策，如果设置错误，会根据偏离方向的不同而产生截然不同的故障特征。

演示每次都能成功。LLM把"显示上个季度收入前十的客户"翻译成完美的SQL，结果瞬间弹出，会议室里所有人都点头认可。然后你把它部署到你实际的数仓上——130张表、1400个字段、十年积累的有机命名惯例——模型开始自信地生成返回错误数字的查询。没有报错，只是答案是错的。

这就是Schema边界问题，也是为什么Text-to-SQL在所有AI能力中，基准测试性能与生产现实之间的差距最大。在Spider 1.0（标准学术基准）上得分86%的模型，在Spider 2.0上准确率下降到约6%，而后者更接近真实企业Schema的复杂度。供应商在干净的玩具Schema上演示，你却要在自己的Schema上部署。

每个构建AI Agent的团队都会做同样的粗略计算：用预期的工具调用次数乘以每次调用的成本，再加上一点缓冲。这个估算在离开白板之前就已经错了——不是错了10%或20%，而是错了5到30倍，具体取决于Agent的复杂程度。40%的Agentic AI试点项目在达到生产阶段之前就被取消，而推理成本失控是最常见的单一原因。

问题是结构性的。单次调用成本估算假设每次推理是独立的。在多轮Agent循环中，它们并非独立。每次工具调用都会增大后续所有调用必须支付的上下文。结果是一条二次方成本曲线伪装成了线性曲线，工程师们直到账单到来才发现这一点。

模型卡会告诉你该模型在 MMLU 上得分 88.7 分。但它不会告诉你：该模型会系统性地将责任归咎于可能性列表中最先出现的技术，导致约 10% 的归因答案在事实正确的情况下语义却是错误的。它不会告诉你：在系统提示中加入"你是一个有帮助的助手"，与留空系统提示相比，会降低结构化推理任务的性能。它不会告诉你：在高负载下第 99 百分位延迟是中位数的 4 倍，也不会告诉你：模型在法律和金融查询上的行为，会因你是否包含合规免责声明而发生明显变化。

这些内容都不在模型卡里。你需要将系统部署到生产环境，然后亲眼看着问题出现，才能学到这些。

2026 年 3 月，一家大型电商平台在一天之内损失了 630 万个订单——美国订单量的 99% 化为乌有。原因不是某次鲁莽的部署，也不是数据库故障。一个 AI 编程工具基于过时的内部文档自主生成并部署了代码，导致每个市场的配送时间估算全部出错。该公司要求 80% 的工程师每周使用该工具，采用率指标一片绿灯，工程纪律却不然。

这才是规模化 Vibe 编程的真实面貌——不是四天就能上线的快速演示，而是第 365 天消失的 630 万个订单。

在一项受控随机对照试验中，使用 AI 编程助手的开发者预测他们的速度会提高 24%。而实际上，他们慢了 19%**。关键在于：他们仍然认为自己变快了。这种认知鸿沟——即生产力的“感觉”与实际交付能力背道而驰——是一种失效模式的早期预警信号，这种模式通常在数月而非数小时内显现。

行业已实现近乎普及的 AI 采用。93% 的开发者使用 AI 编程工具。生产力增长却停滞在 10% 左右。这些数字之间的差距并非工具问题，而是一个不断累积的债务问题，大多数团队在扭转成本变得极其昂贵之前，往往察觉不到它的存在。

你的团队上线了一个基于 LLM 的新功能，进行了为期两周的干净 A/B 测试，并看到了具有统计显著性的提升。你将其全量发布。三周后，留存指标毫无变化，客服工单却在攀升。究竟哪里出了问题？你用教科书式的实验方法去测试了一个不符合教科书假设的处理方案——"处理方案是稳定的"这一前提，在无声无息中已然被打破。

标准 A/B 测试是为确定性或近确定性的处理方案而设计的：按钮颜色变更、参数固定的排序算法、结账流程。而 LLM 功能几乎违反了使经典频率派实验可靠的所有假设。处理方案的方差很高，处理方案本身会因服务商推送模型更新而在实验进行中途发生变化，"成功"难以被清晰量化，而且新鲜感效应足够强烈，足以产生在用户适应后就烟消云散的实验结果。

本文将介绍在这些挑战下使实验仍然有效的调整方法。