702 篇博文 含有标签「llm」

你的 AI 编码智能体刚刚生成了一个拉取请求。代码看起来没问题，编译通过，测试也过了。你合并了它。两天后，预发布环境的 CI 流水线开始抛出 AttributeError: module 'openai' has no attribute 'ChatCompletion'。智能体使用了一年前已被废弃、并在最新主版本中彻底移除的 API 模式。

这就是废弃 API 陷阱，它坑害团队的频率远比那些聚焦 AI 代码质量的会议分享所描述的要高得多。一项对七个前沿 LLM 进行评估、覆盖 145 个 API 映射的实证研究发现，大多数模型在主流 Python 库上的 API 使用合理性（AUP）低于 30%。当被明确给出废弃上下文时，所有被测模型的废弃 API 使用率高达 70–90%。这个问题是结构性的，与特定模型或特定库无关。

一份干净的 PDF、一个强大的 LLM、三十行代码。演示成功了。你提取出了发票总额、合同日期、患者诊断。利益相关方印象深刻。然后你推向生产，不到一周，流水线就在 15% 的文档上静默地返回错误数据——而没有人知道。

这就是文档 AI 的陷阱。失败模式不是崩溃或异常，而是一条在生成垃圾数据的同时仍然报告"成功"的流水线。构建生产级文档提取，与构建一个演示，是完全不同的问题——而大多数团队直到已经上线才意识到这一点。

大多数团队在做“云端 vs. 边缘”的决策时往往凭直觉：因为云端更简单，所以他们默认选择云端。直到 HIPAA 审计来袭，或者延迟 SLO 下降了 400 ms，亦或是收到了当月的账单。只有到那时，他们才会反思是否某些推理本来就应该在本地完成。

答案几乎永远不会是“全云端”或“全边缘”。大规模运行生产级 AI 的团队已经达成共识，采用了分层架构：由设备端或本地模型处理大部分请求，而云端前沿模型则负责处理小模型无法应对的情况。正确处理这种路由是一个工程决策，而不是一种直觉。

这就是进行严谨决策的决策框架。

大多数 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 也很昂贵、缓慢且不稳定，如果你不小心，它们会破坏生产流水线。对于几乎每个团队来说，正确的答案是采用混合方案，在各自擅长的输入上分别使用这两种方法。