567 篇博文 含有标签「llm」

大多数 AI 团队把通过评估套件视为系统正常运行的信号。但事实并非如此——至少不全是。一个稳定得分 87% 的套件只做了一件事：告诉你系统在套件恰好覆盖的那 87% 的场景中表现良好。如果这套测试是六个月前手工整理的，基于团队能想到的示例，从未用真实流量更新过，那它正在以越来越高的置信度测量错误的东西。

这就是评估覆盖率问题。它与你的评估器是否准确无关——而是关于你测试集中的查询分布是否与用户实际发送的查询分布相匹配。当这两种分布出现偏差时，你会得到一个比评估失败更糟糕的结果：一个通过的评估，背后却是悄然劣化的产品。

你的模型是基于去年的数据训练的。它在两个月前进行了内部评估，并在一个月后正式发布。当你得知用户遇到故障时，你已经落后于模型运行所需的现实世界六个月了。这种差距并非部署问题，而是反馈循环的问题。大多数团队不仅没有闭合这个循环，甚至根本没有对其进行衡量。

当模型表现不佳时，本能反应往往是归咎于模型架构或训练数据。但更深层次的问题通常在于反馈系统的延迟。从用户经历故障到该故障影响你的模型，这中间需要多长时间？大多数团队如果说实话，其实并不知情。行业分析表明，如果模型在六个月或更长时间内没有获得针对性更新，其在面对新数据分布时的错误率会上升 35%。原因并非模型本身在衰减——而是世界在前行，而模型却停滞不前。

几乎在每一个生产环境的 AI 系统中都会出现这样一种模式：团队从一个精简的系统提示词（system prompt）开始，发布功能，然后不断迭代。出现了一个新的边缘案例，于是他们添加一条规则。又来了一个工单，再加一条规则。六个月后，系统提示词已经增加到了 2,000 个 token，涵盖了 20 个不同的行为要求。对于大多数请求，AI 听起来依然连贯。但微妙的合规性失败已经潜伏了数周——这里忽略了格式，那里跳过了语气要求，一条升级规则被悄悄绕过。没有人发现，因为没有哪个单独的失败严重到需要触发警报。

这不是模型质量问题。这是基于 Transformer 的语言模型处理指令的一种基本架构特性，大量的实证研究使得这些失败模式变得可预测。理解这一点将改变你编写系统提示词的方式。

在 AI 产品开发中，有一个常见的假设：如果一个模型能处理难题，它就一定能处理附近的简单任务。这个假设是错误的，它导致了一类生产环境下的失败，而无论你读多少基准测试报告都无法为此做好准备。

这一潜在现象的研究术语是“破碎边界”（jagged frontier）——AI 的能力边界并不是一条平滑的线，并非难题在界外、简单任务在界内。它是一个参差不齐、不可预测的形状。AI 系统可以编写生产级别的数据库查询优化器，却仍然会算错图中两条线段是否相交。它们可以通过博士级别的科学考试，却在涉及空间关系的儿童谜题上失败。它们可以综合 50 页的文档，然后对自己刚刚读过的一段文字产生充满自信的幻觉。

一个团队为内部文档构建了 RAG 流水线。检索效果看起来不错——相关段落都被召回了。但在生产环境中，用户持续收到过时的答案。深入查看日志后他们发现，模型返回的是训练数据中的事实，而非它被给予的文档内容。检索成功了，但模型就是没用上它。

这就是知识污染问题：模型的参数记忆——训练期间编码进权重的知识——压制了检索到的上下文。这种失败悄无声息、表现自信，也是生产环境 RAG 系统中最常见的故障模式之一。

大多数生产环境中的 AI 失败都是“响亮”的。模型返回 5xx 错误。模式验证抛出异常。评估套件在发布前捕获了回归。但还有一类失败是完全无声的——没有错误，没有异常，没有警报触发——因为系统正完全按照设计运行。它只是在处理一个来自 18 个月前的现实快照。

你的 LLM 存在知识截止日期（Knowledge Cutoff）。这个截止日期不仅仅是文档中的一个脚注。它是模型认知的真实情况与实际现实之间日益扩大的鸿沟，而且你每在生产环境中多运行一天旧模型，这种差距就会累积。团队庆祝上线，随后眼睁睁看着用户信任在接下来的六个月里悄然瓦解——世界在前进，而模型却停滞不前。

大多数工程师发现实时网络接地局限性的方式如出一辙：花一个下午接入搜索 API，推上生产，然后接下来三周都在解释为什么延迟高达六秒、近期事件的回答出错，以及用户偶尔被引导到假冒电话号码。

根本假设——搜索增强型 LLM 不过是"带新鲜数据的普通 RAG"——是大多数痛苦的来源。实时网络接地与静态检索几乎没有共同之处，除了"检索"这个词。它是一个披着 NLP 外衣的分布式系统问题。

这条流水线在纸面上看起来很合理：你有一个目标任务，没有人工标注样本，但有一个能力强大的大模型可用。于是你用该模型生成标签，再用这些标签微调一个更小的模型。发布，重复。

没有人足够重视的问题是：当你的标注模型和目标模型在同一批互联网数据上训练时会发生什么？而如今，它们越来越多地确实如此。

我认识的一个团队花了三个月时间构建了一个基于规则的地址标准化器。它处理了最常见的 20 种格式，使用 USPS API 进行验证，并且在他们见过的数据上表现出色。然后他们迎来了一个新的企业客户。第一周的数据中，地址被嵌入在自由格式的备注字段里，邮政编码缺少国家前缀，还有他们的规则从未见过的跨境格式。这个标准化器在 31% 的记录上发生了静默失败。他们尝试用 LLM 作为一个快速修复方案，预期准确率为 80%，结果得到了 94%。令人惊讶的不是 LLM 奏效了 —— 而是他们的评估框架中没有任何指标预见到了这一点。

这就是问题的现状。基于规则的标准化是可预测的、快速且廉价的。当数据分布在预设范围内时，它表现良好。LLM 处理的是长尾部分 —— 那些奇怪的格式、隐含的领域知识以及规则永远无法穷举的边缘情况。但 LLM 也很昂贵、缓慢且不稳定，如果你不小心，它们会破坏生产流水线。对于几乎每个团队来说，正确的答案是采用混合方案，在各自擅长的输入上分别使用这两种方法。

产品团队已经开始直接将分析问题路由给 LLM：“是什么导致了流失率激增？”“为什么重新设计后转化率下降了？”“我们应该把留存预算重点花在哪个群体上？”输出结果出现在高管汇报幻灯片中，驱动着路线图决策，并向投资者展示。模型以优雅的文字和具体的数字自信地作答。然而，这些答案中有很大一部分是以一种不易察觉的方式出错的。

这并不是对用 LLM 处理数据工作的全面批评。在某些任务中，它们确实很有帮助。问题在于其失败模式是隐形的——模型不会留有余地，不会说明局限性，也不会区分“我是根据你的数据计算出来的”和“我生成了一个听起来像这个数字应该是多少的东西”。了解故障发生位置的从业者可以捕捉到真正的价值并避开雷区。

2024 年 12 月，OpenAI 整个平台宕机超过四个小时。一项新部署的遥测服务配置错误，导致大规模集群中的每个节点同时猛攻 Kubernetes API。DNS 崩溃，控制平面瘫痪，所有服务随之倒下。恢复耗时如此之久，部分原因在于团队缺乏他们后来所说的"破防工具"——那些在常规流程失效时可以立即调用的预建应急机制。

如果那天你正在运营一款 AI 驱动的产品，你必须在压力下快速做出决策。多服务商路由？优雅降级？缓存响应？还是只能祈祷，然后挂出一个状态页面？

这就是你应该在那个电话打来之前就已经写好的应急手册。

你的 AI 产品有两个功能面：一个面向用户的聊天功能和一个后台报告生成任务。两者在同一个 Key 下调用同一个 LLM API。一个下午，你收到了一张工单：“聊天回复在中途被截断了。”没有触发任何警报。日志中也没有 429 错误。API 在整个过程中一直返回 HTTP 200。

发生了什么：报告生成任务逐渐消耗了你大部分的共享 Token 配额。聊天请求虽然能完成，但仅达到了你的 max_tokens 限制——在语义上被截断，在语法上有效，却在无声无息中出错了。你的标准监控从未察觉到这一点，因为在 HTTP 层面上没有任何异常。

这并不是一种边缘情况。当工程师将 LLM 速率限制视为简单的节流问题，而不是意识到它们实际上属于分布式系统失效类别时，就会发生这种情况。