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

麦当劳得来速 AI 的失败，并非因为用户抱怨。它失败，是因为用户停止使用得来速。三年来，这套系统一直记录着"健康"的接受率，而病毒式传播的视频却显示顾客在苦苦哀求它从订单中删除 260 块鸡块。当合作关系终止时，官方给出的理由是技术"尚未成熟"。真正的信号其实一直隐藏在客流量数据里——无人阅读，无人量化，无人汇报。

这就是大多数 AI 功能在生产环境中失败的样子。用户不会关闭你的功能。他们不会提交工单。他们不会留下一星评价。他们悄悄地绕开它，而你的仪表板依然一片绿色。

你的 AI 功能上线了。用户正在使用它。每一次会话回放、每一次点踩、每一个返回错误答案的请求，都清晰地暴露出它现在的表现与它应有水平之间的差距。信号就在眼前。问题是：你是否可以合法地利用这些信号。

这就是团队撞上合规高墙的地方。这不是一堵理论上的墙——而是实实在在的。仅在 2024 年，欧洲监管机构就开出了逾 12 亿欧元的 GDPR 罚款，OpenAI、Meta 和 LinkedIn 均在被点名之列。大多数执法行动背后有一条共同主线：以原先收集目的之外的方式使用行为数据，或收集了超出运营功能所必要的数据。监管机构并不会因为你的意图是改进模型而非投放广告就网开一面——尽管工程师们往往这样以为。

大多数工程团队将 API 文档视为开发者体验关注点——一种为了减少支持工单和入职时间而进行的改进。当你的主要消费者是在浏览器中阅读文档的人类时，这种思维方式是有道理的。但现在，这已经不再足够。

当 AI 智能体通过工具调用访问你的 API 时，你的文档就不再仅仅是指南，而是变成了运行时行为。模糊的参数描述不再是 UX 上的不便，而是对模型产生幻觉值的直接指令。缺失的错误代码不再是参考文档中的空白，而是一个模糊信号，可能导致智能体陷入没有退出条件的重试循环。你三年前为人类读者编写的文档，现在正被一个无状态的语言模型解析，无论它是否理解正确，都会自信地执行。

大多数团队在开发初期选择一次上下文格式后，就再也不会重新审视它。一位开发者选择 JSON 是因为它看起来结构化且机器可读。另一位开发者则选择 Markdown，因为他们在 README 文件中一直使用它。当似乎没有其他必要时，普通文本（Plain text）就成了默认选择。这些并不是工程决策——它们只是习惯。并且它们在无形中塑造了你的模型如何进行推理。

你传递给 LLM 的格式并非死板的包装。它本身就是一条指令。结构化的 JSON 上下文会引导模型进入遵循模式（schema-following）的行为。Markdown 鼓励层次化的综合。普通文本则开启了更灵活的推理。即使只是选错了一个格式类别，也可能导致准确率下降 40% 或更多——而且你无法在日志中查看到这种错误。

2025 年，全球新合并的代码中约有 41% 是 AI 生成的。这些代码绝大多数流入了公开索引、被爬取、并最终反哺到下一轮 AI 编程工具训练数据中的生产代码库。其中的含义直截了当，但后果仍在持续显现：AI 模型正日益在前代 AI 模型的输出上进行训练，而没有任何结构化的记录来追踪哪些代码来自何处。

这就是上下文污染问题。它并非假设。反馈循环已在大规模运行，质量影响可以量化，而其失效模式足够特殊——在短期内可能看起来像是进步，而底层分布却在悄然退化。

你上线了一个 AI 功能，运行了一次干净的两周 A/B 测试，看到参与度提升了 4%，然后宣告成功。六个月后，功能全量发布，参与度却持平甚至下滑。测试结果不是因为噪声——而是根本就在衡量错误的东西。

A/B 测试建立在一个假设之上：实验组和对照组的用户在统计上是相互独立的。而 AI 功能会系统性地打破这一假设。用户相互交流、从彼此的行为中学习，并共享 AI 工具的输出结果。当真正的机制是长期的行为适应时，两周内处理效应并不会趋于稳定。忽视这一点，你的实验会给出一个内部自洽却因果无意义的数字。

同一家公司的两位分析师都问了你的 AI 助手同一个问题："我们 Q3 的客户流失率是多少？"一个人得到的是 4.2%，另一个人得到的是 4.8%。两个答案都没有错——他们只是在不同的时间、不同的会话上下文中进行了查询，检索索引对略有不同的数据块进行了排名。AI 自信地回答了两个问题，没有任何保留，没有标记任何差异。两位分析师带着不同的数字走进了同一个会议，而你的工具刚刚变成了一个负担。

这就是跨用户一致性问题，也是企业 AI 部署悄然失去信任最常见的原因之一。这种失败并非经典意义上的幻觉——没有编造任何事实。失败在于：你的系统在规模上是非确定性的，而这种非确定性在两个用户互相对比结果之前是不可见的。

大多数构建 RAG 系统的团队在第一个月都花在流水线（pipeline）上——分块策略、嵌入模型选择、向量数据库配置、检索微调。他们让系统跑通了。演示顺利通过。利益相关者印象深刻。

六个月后，系统开始悄无声息地退化。支持工单提到了错误的流程。机器人引用了一个已经在第三季度停用的价格档位。客户得到了关于一个在他们注册前就已弃用的产品功能的肯定回答。流水线没问题，问题出在知识库上。

当单个 LLM 给出错误答案时，你的直觉可能是询问更多模型。并行运行三个模型并取多数票——这就是集成（Ensemble）。或者把它们放在一个房间里让它们相互辩论——这就是辩论（Debate）。两者听起来都很严谨，且背后都有同行评审的研究支持。但在条件不成熟时，它们会以完全相同的方式失效，而这正是从业者鲜少讨论的部分。

这种失效模式并不隐晦：当你的所有模型都从相同的数据中学习、带有相同的偏见，或者是由具有相同世界观的人训练时，增加模型数量并不会带来更多信号，只会带来更“自信”的噪声。最近的研究为这一现象给出了量化数据：顶尖前沿模型之间的两两错误相关性（pairwise error correlation）约为 r = 0.77。这意味着大约 60% 的错误方差是共享的。来自不同供应商的三个模型实际上只相当于 1.3 个独立模型，而不是 3.0 个。

贷款申请被拒。候选人在招聘流程中被过滤掉。医学影像工具将某张扫描标记为异常。在每一种情况下，AI系统都做出了一个至关重要的决定——而用户毫不知情其背后的原因。

构建这些系统的团队往往花费数月时间调整精确率、召回率和输出质量。他们进行A/B测试，迭代提示词，最终交付了一个94%准确率的模型。但他们从未构建那个告诉用户发生了什么的层。这就是解释债务：在没有归因、置信度信号和申诉机制的情况下发布AI决策所积累的代价——这些要素本可以让决策具有可解释性。

你的聊天机器人在前十五轮对话中运行完美。然后，问题出现了。它与之前的决定相矛盾。它询问用户已经提供过的信息。它丢失了对话开始时明确定义的多步骤任务的脉络。对话历史在技术层面上还在那里——你没有删除任何内容——但模型的行为却好像它不存在一样。

这就是上下文腐化（context rot）：随着对话历史增长，输出质量逐渐下降的现象。2024 年对 18 个最先进模型进行的评估，涵盖近 20 万次受控调用，发现即使在名义上拥有更大窗口的模型中，可靠性在超过 30,000 个 Token 后也会显著下降。在扩展对话中，高性能模型会变得和小得多的模型一样不可靠。问题不在于你的上下文窗口耗尽了，而在于 Transformer 注意力机制是二次方的——100,000 个 Token 意味着 100 亿对关系——模型被迫将注意力分散得如此稀薄，以至于重要的早期内容实际上被忽略了。

当团队遇到这个瓶颈时，通常会采用两种解决方案之一：截断或摘要。这两种方法都会以可预见的方式让情况变得更糟。

典型的 AI 团队在面对合规性时的经历通常是这样的：智能体（Agent）已经上线，用户非常喜欢，然后法务部门转来一封邮件，询问系统是否符合 HIPAA 标准。被指派回答这个问题的工程师发现，上下文窗口（context windows）包含 PHI，没有足够粒度的审计日志，LLM 提供商没有签署商业伙伴协议（BAA），而且智能体的工具权限超出了最低必要标准所允许的范围。修复工作需要三个月，并且需要重写部分代码。

这种模式并非特例。根据 2024 年的一项行业调查，78% 的企业高管无法在 90 天内通过 AI 治理审计，而 2025 年有 42% 的公司放弃 AI 项目主要是由于合规性和治理失败——而非技术原因。所构建的内容与合规性实际要求之间的差距是架构层面的，并且在第一轮迭代（sprint 1）中就已经形成。