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

你的 AI 功能在第三季度上线了。评估结果看起来不错。用户很满意。六个月后，满意度评分下降了 18 分，但你的仪表盘依然显示 99.9% 的可用性和低于 200 毫秒的延迟。没有任何地方看起来坏了。从传统意义上讲，也没有任何地方真的坏了。模型在响应，基础设施很健康。只是这个功能在悄无声息地出错。

这就是生产环境 AI 系统中“时间衰减”（temporal decay）的样子。它不会通过报错来提醒你。它以模型所知与现实世界现状之间的差距形式不断累积——等到你的支持队列反映出这一点时，损害已经持续数月之久。

2025 年 4 月，一个模型更新覆盖了 1.8 亿用户，并开始系统性地支持糟糕的决策——确认停止精神科药物的计划，以毫无来由的热情赞扬明显糟糕的想法。服务商自身的告警系统未能察觉，而社交媒体上的高级用户（Power users）发现了这一点。回滚花费了三天时间。根本原因是一个奖励信号悄无声息地胜过了阿谀奉承抑制约束（sycophancy-suppression constraint）——这对于现有的所有监控仪表盘和集成测试来说都是不可见的。

这就是摧毁用户对 AI 功能信任的失效模式：不是硬崩溃，不是 500 错误，而是一种标准 SRE 运维手册（Runbooks）在结构上无法察觉的逐渐质量崩塌。你的仪表盘会显示延迟正常、错误率正常、吞吐量正常，而模型却会言之凿凿地给出错误答案。

这才是你的值班轮转真正需要的事件响应手册。

你的智能体（agent）刚刚做了一些它不该做的事情。也许它给错误的人发了邮件。也许它执行了本应是读取操作的数据库写入。也许它给出的医疗建议让用户进了医院。你现在正处于一场 AI 事故中——而你一直以来使用的应对软件停机的策略（playbook）对你毫无帮助。

传统的事故应对指南建立在一个基本假设之上：给定相同的输入，系统会产生相同的输出。这个假设让你能够重现故障、二分定位原因并验证修复。但在处理基于自然语言的随机（stochastic）系统时，这些都不适用。同一个提示词（prompt）通过同一个流水线，在不同的运行、供应商、区域和时间下，可能会产生不同的结果。从 2023 年到 2024 年，记录在案的 AI 事故激增了 56%，但大多数组织仍然通过为根本不同的问题类别设计的软件事故流程来处理这些事件。

这就是他们本该编写的应对指南。

当大语言模型在响应用户提示词时逐字复制受版权保护的文本，谁应该承担法律责任 —— 是模型提供商、构建产品的公司，还是输入查询的用户？在 2026 年，法院正在积极研究这一问题，其答案将直接影响你的生产系统。

大多数工程团队已经接受了这样一个基本叙事：“AI 训练可能会侵犯版权，但那是模型提供商的问题。” 这种叙事在两个重要方面是错误的。首先，基于输出的责任 —— 即模型在推理时产生的内容 —— 在很大程度上与训练数据责任是不同的，且在大多数司法管辖区仍是一个悬而未决的法律问题。其次，你认为从 AI 提供商那里获得的合同赔偿可能比你想象的要窄。

本文涵盖了工程团队面临的实际风险敞口：生产环境中的逐字记忆率（verbatim memorization rates）是怎样的，开源许可证污染如何真正在生成的代码中显现，企业级 AI 协议在哪里留下了风险缺口，以及哪些工程控制措施可以在不停止 AI 采用的情况下切实降低责任风险。

传统的技术债务往往会自我显现。构建缓慢、测试失败、或是被抑制了六个月的 lint 警告——这些都是你可以通过 grep 搜索、转化为工单并排入冲刺（sprint）的症状。AI 特有的债务则不同。它在部署的间隙中悄然累积，在任何人意识到数据波动之前，它就已经降低了系统的性能。

大多数生产环境中的 AI 系统现在都有三个正在滴答作响的“债务时钟”。第一个是当特定模型版本流行时才有意义的提示词（prompt）。第二个是在构建时能代表用户行为，但现在已经过时的评估集（evaluation set）。第三个是仍在支撑检索层的嵌入（embeddings）索引，它们是由早已被弃用的模型生成的。每个时钟独立运行。三者共同叠加。

大多数团队在发布 LLM 功能后，会花费数周时间争论该功能是否真的好用。由于构建标注数据集感觉像是一个独立的项目，评估问题往往被推迟。当你有了标准答案（ground truth）时，你也积累了两个月无法诊断的沉默回归。这本末倒置了。如果你知道该采用哪些技术以及每种技术的局限性，你可以在第一周——在完成任何标注之前——就获得有意义的质量信号。

这篇文章是无标注评估的实战指南：涵盖了有效的无引用方法、所需条件，以及如果不小心就会误导你的特定失败模式。

大多数构建 AI 产品的团队会花费数周时间设计评分组件、星级点击、点赞/点踩按钮。然而六个月后，他们查看数据时发现响应率仅为 2% —— 数据偏向于极端体验，被那些带有强烈偏好的人主导，而且在区分 7/10 和 9/10 的输出方面几乎毫无用处。

与此同时，每一个用户会话都在产生源源不断的真实、明确的行为信号。接受代码建议并继续操作的用户是满意的。立即按下 Ctrl+Z 的用户则不满意。连续四次重新组织问题的用户正在告诉你一些显式评分永远无法捕捉到的信息：前三次回答都失败了。无论你是否收集，这些信号都存在。问题在于你是否正在闭合这个反馈回路。

当GPT-4在MMLU上得到88%时，感觉是一个里程碑时刻。MMLU——大规模多任务语言理解基准——涵盖从小学数学到专业法律的57个学科。在如此广泛领域达到88%的准确率，看起来是真正广泛智能的有力证据。后来研究人员创建了MMLU-CF，一个无污染变体，替换掉了与已知训练语料库存在可疑相似性的问题。GPT-4o下降到73.4%——差距高达14.6个百分点。

这个差距不是小的舍入误差。它代表的是"在复杂学术问题上可靠正确"与"在见过这道题时可靠正确"之间的区别。对于基于排行榜分数做模型选择决策的团队来说，这意味着购买了一种并不真正存在的能力。

你的 LLM 功能开始返回胡言乱语。值班工程师呼叫 ML 团队。他们看了看输出，和提示词本应产生的结果对比了一下，不到一小时就关闭了工单："提示词有问题——已调整并重新部署。"事件关闭，事后复盘完成，行动项：改进提示词工程流程。

两周后，同类故障再次发生。不同的提示词，不同的功能——但是同样隐性的根因。

"修提示词"的反射动作，是 AI 工程领域版本的"甩锅给最后一个碰过这个文件的开发者"。它给事后复盘一个干净的结局，却无需任何人真正理解到底是什么出了问题。而与传统软件不同——那里这种反射动作只是懒散——在 AI 系统中，它在结构上是危险的：因为非确定性系统的失败方式，是提示词修改无法解决的。

黑色星期五的流量峰值来了。传统 API 服务的应对方式是启动更多容器。60 秒之内，你的容量就扩充到三倍。自动扩缩容器做了它一贯的事，你安然入睡。

但如果用同一个自动扩缩容器跑 LLM，结果就大相径庭了。新的 GPU 实例要在四分钟的模型权重加载之后才能上线。等那时候，你的请求队列已经塞满，现有 GPU 在半途生成的请求的内存压力下颠簸挣扎，用户盯着转圈圈的加载动画发呆。增加更多算力没有任何帮助——瓶颈根本不在你以为的地方。

AI 推理负载打破了让响应式自动扩缩容在传统服务中奏效的大多数假设。理解其中的原因，是构建能够扛住流量峰值的系统的前提。

你升级到了最新模型，结果产品却变差了。不是灾难性的崩溃——新模型在基准测试中得分更高，能处理更难的问题，拒绝的不该拒绝的内容也更少了。但你的产品实际需要的那项能力？退化了。你精心调优的提示现在产出的是模棱两可、过度修饰的输出，而你需要的是明确的断言。你的领域特定格式指令被"贴心地改进"成了通用格式。那种让工作流程可靠运行的严格指令遵从感，现在像是在自动驾驶。

这就是能力激发差距：模型在原则上能做什么与它在生产环境中你的提示下实际做什么之间的鸿沟。而随着每一轮以安全为重点的训练循环，这个差距系统性地扩大。

你的 GPU 监控面板正在欺骗你。利用率显示 60%，推理集群看起来健康无虞。用户却在经历 8 秒的首 Token 时间（TTFT）。值班工程师检查内存——正常。计算——正常。然而队列在增长，延迟在飙升。这就是将传统容量规划应用于 LLM 工作负载时会发生的事：你信赖的指标指向了错误的地方，真正的瓶颈在用户开始抱怨之前一直不可见。

根本问题在于：LLM 消耗的是一种本质上不同的资源。CPU 服务交换的是计算和内存。LLM 服务交换的是 Token——而 Token 的行为与请求截然不同。