426 篇博文 含有标签「llm」

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

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

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

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

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

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

大多数团队在选择标注策略时，都会比较单价：众包工人大约 $0.08/条，LLM 生成不到$0.003/条，人类领域专家约 $1/条。跑一遍表格，选出看起来"足够好"的最便宜选项，然后上线。这套算法经常让团队陷入麻烦。

真正的决策并非只看单条标签的成本。每种标签来源都有一个隐藏的质量税——以垃圾梯度、误导性评估曲线，或花费数月排查生产故障的形式复利叠加；而干净的标签本可以在训练阶段就捕获这些问题。最便宜的来源往往是计入下游信任成本后最昂贵的一种。

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

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

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

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

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

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

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

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

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

在 AI 工程领域，一直存在一种固有的假设：获得更好输出的路径是更好的模型。更大的上下文窗口、更新的训练数据、更高的基准测试分数。在实践中，交付最强大 AI 产品的团队通常在做一些不同的事情：他们正在构建流水线（pipelines），由多个专门的组件——检索器（retriever）、重排序器（reranker）、分类器（classifier）、代码解释器（code interpreter）以及一个或多个语言模型——协同工作，处理任何单一模型都无法独立可靠完成的任务。

这种架构模式有一个名字——复合 AI 系统（compound AI systems）——它现在是生产级 AI 的主导范式。了解如何正确构建这些系统，以及在构建不当时它们会在哪里失效，是当今应用 AI 工程中最重要的技能之一。

一场持续 90 分钟的客服会话。一个已经浏览文档一小时的研究助手。一个已经处理十几个文件的编程 Agent。所有这些最终都会撞上同一堵墙——但撞上时，它们不会大声报错。它们只会变得迟钝。

模型开始遗忘二十分钟前做出的决定。它自相矛盾。本应显而易见的检索结果莫名消失。用户察觉到有些不对劲，却说不清助手为何变差了。这就是上下文窗口悬崖：不是一个硬性错误，而是一种渐进的质量崩塌——而你的监控系统几乎肯定没有衡量它。

扩大上下文窗口并不能解决这个问题。拥有百万 Token 窗口的模型在处理中间位置内容时仍然会退化；即便不退化，你也在为多出 100 倍的 Token 买单，而模型实际关注的只是其中一小部分。解决方案是应用层的上下文管理——明确策略什么留在窗口里、什么被压缩为摘要、什么完全移到窗口之外。

你的部署流水线是绿色的。延迟处于正常水平。错误率：0.02%。新的模型版本已成功发布——或者说你的仪表盘是这么显示的。

与此同时，你面向客户的 AI 正在微妙地以较低的精度总结文档，对以前能直接回答的问题含糊其辞，并不时地压平下游流水线所依赖的结构化输出。没有警报响起。没有触发值班呼叫。你收到的第一个信号是两周后的一张支持工单。

这就是 AI 部署中的隐性回归问题。传统的回滚信号——HTTP 错误、p99 延迟、异常率——是为确定性软件构建的。它们无法察觉行为漂移。随着团队更频繁地升级语言模型，“基础设施健康”与“AI 运行正确”之间的鸿沟成了回归问题的藏身之处。

当数据变得嘈杂时，你的梯度提升模型会礼貌地退化。准确率下降，精确率下降，监控告警触发，值班工程师知道该去哪里排查。LLM则不会这样。向LLM输入降级、陈旧或格式错误的数据，它产生的输出流畅、自信、听起来权威——但部分甚至完全是错的——而下游消费该输出的系统根本无从分辨。

这就是数据质量税：当劣质数据进入LLM管道时，你付出的复利代价——不是以低置信度分数的形式，而是以披着事实语法的幻觉来呈现。

你花了三周时间精心整理一套高质量的评估集。你编写了测试用例来覆盖产品经理担心的边缘情况，从内测用户中采样了真实查询，并得到了一个团队认可的准确率数字。六个月后，这个数字仍然出现在每周的仪表盘上。你刚刚发布了一次在评估中表现出色的模型更新，用户却在提交工单。

问题不在于模型退步了。问题在于你的评估集几个月前就已经不再代表现实——而没有人注意到。

这种失败模式有个名字：评估集衰退。它几乎发生在每一个生产AI团队身上，而且几乎从不会在用户行为中出现可见损失之前被发现。