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

大多数团队将他们的黄金评估集（golden eval set）视为宪法——持久、权威且变动成本极高。他们花数周时间挑选案例，请领域专家进行标注，并将其接入 CI。然后，他们就转去忙别的事了。

六个月后，评估套件显示通过率为 87%，但用户却在抱怨输出结果支离破碎。评估指标并没有倒退——它们只是腐化了。该数据集测量的仍然是 10 月份重要的数据。它只是不再测量现在重要的数据。

这就是黄金数据集腐化问题（golden dataset decay problem），它比大多数团队愿意承认的更为普遍。

你见过的每一个 Agent 演示都以干净的结果收尾。工具调用返回了模型预期的数据，响应在两秒内到达，最终答案清晰准确。那是演示。生产环境则是另一回事。

在生产环境中，工具会超时。API 会返回 403，因为某个服务账户上周二被轮换了。第三方数据丰富端点返回 200，但响应体写着 {"status": "degraded", "data": null}。OAuth 令牌在周六凌晨 3 点过期。这些不是边缘案例——这是任何与真实世界交互的 Agent 的正常运行状态。失败模式是可预见的。问题在于，大多数 Agent 架构将它们视为事后补救，而大多数 Agent UI 根本没有向用户传达这些失败的词汇。

大多数AI团队能告诉你他们的遏制率——AI在不转交给人工的情况下处理的交互比例。但很少有团队能告诉你这个数字是否合理。

升级标准是AI增强团队中最重要的设计文档，而大多数团队根本没有这份文档。他们有一个埋藏在YAML文件中的阈值，以及一个隐含的假设：AI知道自己什么时候卡住了。这个假设在两个方向上都是错误的：阈值过高，人工就要花时间返工AI的工作；阈值过低，用户在没有任何补救措施的情况下承受AI的错误。两种失败都是隐性的，直到它们积累成大问题。

当你从一位刚刚离职的工程师那里接手一个 AI 系统时，会有一种特殊的恐惧感袭来。系统提示词长达数百行，有一个叫 evals/ 的文件夹里存着 340 个测试用例却没有 README，代码中的注释写着 # 不要修改这里——找 Chen 问 而 Chen 已经联系不上了。

你不知道为什么客服机器人被禁止在星期二讨论定价，不知道哪些评估用例是为了捕捉六个月前的回归问题而写的，哪些只是随机示例，也不知道屏蔽某些产品类别的护栏究竟是法律要求、合规实验，还是某人因为某个副总裁看到了一条糟糕的输出而随手加上的。

系统还在运行。目前如此。但你无法安全地修改任何东西。

你构建了一个 AI 功能。你跑了评估。你在测试集上看到了 95% 的准确率。你上线了。六周后，用户对它深恶痛绝，你的团队正在悄悄计划回滚。

这就是最后一公里可靠性问题，它很可能是当今生产环境中 AI 功能失败最常见的原因。这与你的模型不好无关，而与平均准确率指标如何掩盖失败分布有关——以及某些失败无论其统计频率如何都会带来高昂代价。

你的用户没有秒表，他们只有感觉。而这些感觉与时钟现实的偏差，对你构建AI界面的方式至关重要。一个逐字出现、持续三秒的响应，用户普遍感觉比一秒后突然全部出现的批量响应更快——尽管批量系统在客观上更快。这不是非理性的，也不是人类认知的缺陷，而是一种有据可查的感知现象。如果你在构建AI产品时没有考虑这一点，你就是在为错误的指标做优化。

本文将剖析延迟感知背后的心理学、真正预测用户满意度的指标、利用这些感知特性的前端模式，以及何时流式传输会带来比价值更多的复杂性。

有一种故障模式会在团队解决了幻觉过滤、输出解析、重试逻辑等较容易的问题之后反复出现：模型给出听起来很自信的错误答案，基于置信度的路由逻辑信任了这些错误答案，系统在生产中悄无声息地出现异常，而评估仪表板看起来一切正常。

这不是提示词问题，而是校准问题，它根植于现代LLM的训练方式之中。

一个团队发布了一款支持聊天机器人。在测试阶段，每月账单看起来还在可控范围内——工程团队演示期间仅花费了几百美元。上线三周后，发票寄到了：4.7 万美元。没人虚报 Token 数量，也没人算错账。生产环境的工作负载与他们模拟的完全不是一回事。

这种模式在不断重复。团队估算 LLM 成本的方式就像估算数据库查询成本一样——通过测量一个典型的请求并乘以预期访问量。这种思维模型在 LLM 上彻底失效了，因为两个最大的成本驱动因素（输出 Token 长度和工具调用开销）是在推理阶段决定的，其行为在设计阶段无法完全预测。

本文讨论的是如何在发布前进行更好的预测，而不是在账单到期后如何优化。

你手写的 ETL 管道处理了 95% 的记录。那些边界情况——带有逗号的货币字符串、格式不一致的日期、不统一的国家代码——流向了你的数据仓库，并悄悄地破坏了你的仪表板。直到季度报告看起来不对劲时，才有人注意到。你又在管道中添加了一个特殊情况。循环往复。

LLM 可以解决这个问题。它们能从原始样本中推断模式（schema），处理任何工程师都预料不到的杂乱边界情况，并能以极短的开发时间将非结构化文档转换为结构化记录。已经有几个团队推出了这种方案。其中一些团队也经历过 LLM 悄无声息地将 "$1,200,000" 转换成 1200 而不是 1200000，在结构完全有效的情况下将严重程度分数从 "high" 切换到 "low"，以及以通过了所有模式检查的方式连接了错误的业务外键。

问题不在于 LLM 不擅长数据工程。而在于它们的失败模式对 ETL 来说恰恰是完全错误的：高置信度、不报错、且输出结构有效。

一家运行生产级 AI 分诊助手的医疗保健公司收到了一封令所有团队都心生畏惧的邮件：他们的推理服务商将在 90 天后停用他们正在使用的模型。他们更新了模型字符串，进行了快速的手动冒烟测试，然后发布了替代版本。三周后，新模型开始主动提供未经请求的诊断意见。Token 使用量暴增了 5 倍。整个 Prompt 模板由于新模型对指令表述的解读不同而失效。由于输出 Schema 发生了偏移，JSON 解析也宣告失败。

这并非个案。如果你仅仅将模型停用视为一种配置变更，而不是一次系统迁移，那么这就是你在模型停用周期中的常态体验。

当 OpenAI 在其较新的模型中弃用 max_tokens 而改用 max_completion_tokens 时，已经稳定运行了数月的应用程序开始返回 400 错误。没有任何公告触发警报，你的代码中也没有错误。模型改变了，但你的假设没有变。这是将模型升级视为破坏性变更（Breaking Change）的典型案例 —— 只不过大多数变更更加隐蔽，因此更难被发现。

基础模型的更新并不遵循与库发布相同的“社会契约”。Git 提交中没有 BREAKING CHANGE: 前缀。没有语义化版本（SemVer）的提升来告知你的 CI 流程去报错。输出格式变窄、语调偏移、JSON 结构重组、推理路径缩短 —— 下游消费者是通过逐渐恶化的用户体验和混乱的数据分析慢慢发现这些问题的，而不是通过抛出的异常。

2024 年 8 月，安全研究人员发现 Slack AI 在回答查询时会将公开频道和私密频道的内容同时拉入同一个上下文窗口。公开频道中的攻击者可以精心构造一条消息，当 Slack AI 摄取该消息时，就会将指令注入受害者的会话——由于 Slack AI 不引用来源，由此导致的数据外泄几乎无从追踪。这种攻击甚至可以泄露私信中嵌入的 API 密钥。Slack 在负责任披露后修复了这一问题。

这并不是传统意义上的漏洞。它是将上下文视为无用户访问控制的共享可变资源所带来的后果。而这正是大多数正在构建共享 AI 助手的团队现在都在犯的错误，只是更加悄无声息而已。