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

当一个 AI 驱动的客服智能体无法解决问题并将工单升级给人工时，接下来会发生什么？在大多数系统中：客户被冷转接，没有任何上下文，不得不从头开始重新解释所有情况。人工客服完全不知道 AI 尝试了什么、收集了哪些信息，以及为什么发生了交接。

这是人工接管失败最常见的形式——不是戏剧性的 AI 崩溃，而是自动化与人工处理衔接处悄然发生的 UX 崩塌。究其根本，是工程师精心设计了 AI 处理路径，却将人工接管作为事后补丁——一个出问题时的回退方案。结果是，接管体验像系统报错，而非经过设计的操作模式。

那些做得好的工程团队，从第一天起就将人工接管视为一等功能。以下是其在实践中的具体体现。

当生产环境出现故障时，工程师们首先会想到 git blame。提交哈希值指向 PR，PR 指向作者，而作者则指向上下文——Slack 讨论串、设计文档，或者是记住了代码初衷的那个大脑。这条链路是团队排查事故、进行安全审计以及积累机构知识的方式。它假设每一行代码都有一个理解自己在做什么的人类作者。

AI 已经悄然打破了这一假设。目前约 46% 的代码由 AI 生成，在 Java 团队中，这一比例甚至超过了 60%。这些代码中的大部分都不携带任何有意义的溯源元数据。git blame 链条依然在运转——只是现在它终止于一名开发者，他们接受了一个可能并未完全理解的建议，而且没有记录提示词、模型版本或 AI 拒绝的备选方案。

你的 LLM-as-judge 给新模型开了一张健康证明。胜率上升，各项评分指标全线改善，自动化评测流水线全绿通过。然后你上线了——用户满意度却下降了。

这不是边缘案例。研究人员构建了一个无论何种输入都输出固定回复的「空模型」，并在 AlpacaEval 2.0 上拿下了 86.5% 的长度控制胜率。而当时经过验证的真实最优水平是 57.5%。当一个毫无任务能力的模型都能登顶你的排行榜，你的评测框架就有了值得系统审视的问题。

2025 年的研究发现，提交给商用 LLM 的 Prompt 中有 8.5% 包含敏感信息——PII、凭据和内部文件引用。这一统计数据可能低估了问题的严重性。它只计算了用户显式输入的内容，而没有计算系统静默添加的内容：检索到的客户记录、数据库查询的工具输出、从之前会话持久化的记忆，或者是训练前未经过清洗的微调数据。大多数 AI 流水线的 PII 泄露并非源于用户错误，而是源于没有单一工程师负责的架构盲点。

失效模式几乎总是一样的：团队发布了一个 AI 功能，认为“我们不发送个人数据”，但个人数据却从缝隙中进入了——在包含客户地址的 RAG 检索分块中，在返回完整用户档案的智能体工具输出中，或者在从 CRM 导出且未经脱敏（redaction）的微调数据集中。GDPR 的数据最小化原则要求你只收集特定目的所必需的数据。LLM 架构在默认情况下违反了这一点。

2026 年 3 月，一场集体诉讼指控 Perplexity 的“无痕模式”（Incognito Mode）正在将对话数据和用户标识符路由到 Meta 和 Google 的广告网络 —— 甚至对于明确激活了该功能的付费订阅者也是如此。该功能被称为“无痕”。用户认为这意味着私密。但实现方式却并非如此。

这是 AI 隐私模式中最常见的失败模式：名字是营销，实现是“留存戏剧”（retention theater）。工程师上线了一个开关。法务批准了措辞。用户按下开关并信任它。但在数据管道的某处，输入内容仍在流向日志服务、训练任务或某个没人记得拦截的第三方分析 SDK。

当团队对 AI 管道进行提示注入加固时，通常只聚焦于文本：清洗用户输入字符串、扫描输出中的外泄数据、过滤已知的越狱（jailbreak）模式。这些工作固然重要，但对于现代 AI 系统而言，它们大约只覆盖了一半的攻击面。另一半隐藏在图像、PDF、音频片段和图表之中——这些格式能绕过你写下的每一条文本扫描规则，因为模型处理它们的通道与处理文本的通道完全不同。

针对视觉语言模型的隐写注入攻击（steganographic injection attacks），在包括 GPT-4V、Claude 和 LLaVA 在内的生产模型上，成功率约达 24%。这个数字并非实验室数据，而是来自真实的攻击载荷——隐藏在看似普通的图像中，使生产模型偏离预期行为。你的文本注入扫描器对此毫无察觉。

大多数防御提示词注入 (Prompt Injection) 的团队都会联想到一个攻击者：一个精心设计特定字符串以覆盖 AI 指令的人。这种思维定式是错误的，并让他们付出了代价。这个问题更难的版本根本不需要攻击者。

每当你的 AI 应用摄取用户生成的内容时 —— 无论是产品评论、工单、上传的文档还是 CRM 笔记 —— 它都面临着同样的结构性漏洞。无需恶意企图。普通用户出于普通原因生成的普通文本，在规模化的情况下，其表现可能与蓄意的注入攻击完全一致。如果你的应用仅针对对抗性案例进行防御，那么你防御的只是少数情况。

每一个交付过 LLM 驱动的智能体（Agent）的工程师都曾被一个简单的思维模型所诱惑：工具就是一个函数。增加一个工具意味着智能体多了一项功能。其成本仅仅是系统提示词（System Prompt）中的几行文档，或许是一个 Schema 定义，又或者是工具注册表中的一个新条目。这给人的感觉是累加的——线性增长。

事实并非如此。每一个新工具并不只是孤立地扩展智能体的能力；它扩展的是该工具与已有所有工具组合后能产生的能力。这种区别是一类生产环境故障的根源，这类故障在事后无论如何调整提示词都无法修复，因为问题出在架构层面。“提示词表面积”（Prompt Surface Area）问题是真实存在的，它会迅速复合增长，而大多数团队直到深陷其中时才察觉。

你的 RAG 系统很可能正在把自己的输出编入索引。只是你还不知道而已。

一切往往从一件看似无害的事开始：有人把一份季度总结文档添加到了知识库。而这份总结，正是由查询该知识库的同一个 LLM 生成的。六个月后，开发者又加入了 AI 生成的版本说明，随后是自动生成的支持 FAQ，再然后是合成的入职指南。这些文档没有任何一份被标注为 AI 生成。对于检索系统而言，它们与人工撰写的一手资料看起来别无二致。于是，当你的模型检索上下文来回答问题时，其中相当一部分上下文是之前某次模型运行所输出的压缩版、甚至可能已经失真的结果——而你的准确率指标依然绿灯常亮。

这就是溯源债务：在检索语料库中，AI 生成的内容在没有来源标记的情况下不断累积，形成一个反馈循环——每一代模型的输出，都成为下一代模型的原始素材。

凌晨 2 点，一个定时报告生成任务向共享的 API 密钥并行发出五十个 LLM 请求。等到早上 9 点的产品演示开始时，每一个实时对话补全都在悄无声息地超时。错误仪表板一片绿色，日志里没有 429 错误。模型确实在返回响应——只是慢了十秒，而这个功能的 SLA 是两秒。

这就是配额饥饿。它不像故障，它看起来只是"今天 AI 有点慢"。

每个 AI 产品团队的某个角落都有一个安全仪表板，显示着被拒绝的请求。触发了哪些过滤器，拦截了哪些越狱尝试，抓住了哪些违反政策的行为。运营团队通过它来确保防护栏（guardrails）稳固，而其他人都对其视而不见。

这是一个错误。AI 拒绝的请求是你所能接触到的最集中、最真实的用户调研信号。如果一个用户尝试了三种不同的措辞，想让你的产品去做它不愿做的事情，他是在以极其清晰的方式告诉你，他到底想要什么以及无法得到什么。将这一信号视为安全产物而非产品产物，是在浪费你所能收集到的最宝贵的反馈。

你的 AI 功能顺利发布。评估集准确率：91%。延迟：可接受。团队深感自豪。六个月后，用户开始抱怨该功能感觉“很笨”，支持工单不断增加，而你的综合指标悄然比发布当天下降了 8%。没有人更改过模型。底层数据流水线完好无损。发生了什么？

这就是逆行准确率问题（The retrograde accuracy problem）。随着产品的增长——新功能、新用户细分、新边缘情况、新流程——你的 AI 在生产环境中看到的输入分布会悄然偏离其训练时的分布。模型没有更新，数据流水线没有故障，而是产品本身的增长超出了模型的能力范围。