702 篇博文 含有标签「llm」

当公司谈论 AI 风险时，对话通常集中在那些显而易见的失败上：幻觉事实、偏见输出、以及生成内容带来的法律责任。而较少受到关注的是一个更隐蔽的结构性问题：你已经在其输出本质上是概率性的系统之上，做出了商业承诺——定价层级、SLA（服务等级协议）、面向客户的准确性声明。每次模型生成响应时，它都是在从分布中采样。而合同中从未提及“分布”。

这是一个大多数团队发现较晚的业务风险，通常是在客户抱怨同一个文档审查工作流在周一和周五给出了完全不同的结果时，或者当监管机构要求提供系统在架构上无法提供的可复现性保证时。

你的团队发布了一项 AI 功能。你为本地化工作感到欢欣鼓舞：每个按钮标签、工具提示和错误消息都被翻译成了 12 种语言。产品经理签了字。该功能在全球上线。

然而，六周后，一位德国用户发布了一张截图。AI 的回答用词正确但语域（Register）不对 —— 在非正式的客服场景中显得过于生硬。一位日本用户反映，结构化输出中的日期格式为 MM/DD/YYYY，这导致他们的下游工具出现故障。一位巴西的支持工程师注意到，AI 在对复杂查询进行推理时，偶尔会在句子中途滑入英语。这些并不是基础设施故障。你的仪表盘显示一切正常。但对于非英语用户来说，产品正在悄无声息地变得更糟。

根本原因几乎总是一样的：团队翻译了 UI 字符串，但却让系统提示词保留为英文。这看起来像是本地化，但事实并非如此。

大多数团队在开发初期选择一次上下文格式后，就再也不会重新审视它。一位开发者选择 JSON 是因为它看起来结构化且机器可读。另一位开发者则选择 Markdown，因为他们在 README 文件中一直使用它。当似乎没有其他必要时，普通文本（Plain text）就成了默认选择。这些并不是工程决策——它们只是习惯。并且它们在无形中塑造了你的模型如何进行推理。

你传递给 LLM 的格式并非死板的包装。它本身就是一条指令。结构化的 JSON 上下文会引导模型进入遵循模式（schema-following）的行为。Markdown 鼓励层次化的综合。普通文本则开启了更灵活的推理。即使只是选错了一个格式类别，也可能导致准确率下降 40% 或更多——而且你无法在日志中查看到这种错误。

2025 年，全球新合并的代码中约有 41% 是 AI 生成的。这些代码绝大多数流入了公开索引、被爬取、并最终反哺到下一轮 AI 编程工具训练数据中的生产代码库。其中的含义直截了当，但后果仍在持续显现：AI 模型正日益在前代 AI 模型的输出上进行训练，而没有任何结构化的记录来追踪哪些代码来自何处。

这就是上下文污染问题。它并非假设。反馈循环已在大规模运行，质量影响可以量化，而其失效模式足够特殊——在短期内可能看起来像是进步，而底层分布却在悄然退化。

同一家公司的两位分析师都问了你的 AI 助手同一个问题："我们 Q3 的客户流失率是多少？"一个人得到的是 4.2%，另一个人得到的是 4.8%。两个答案都没有错——他们只是在不同的时间、不同的会话上下文中进行了查询，检索索引对略有不同的数据块进行了排名。AI 自信地回答了两个问题，没有任何保留，没有标记任何差异。两位分析师带着不同的数字走进了同一个会议，而你的工具刚刚变成了一个负担。

这就是跨用户一致性问题，也是企业 AI 部署悄然失去信任最常见的原因之一。这种失败并非经典意义上的幻觉——没有编造任何事实。失败在于：你的系统在规模上是非确定性的，而这种非确定性在两个用户互相对比结果之前是不可见的。

一个概念验证（PoC）花费了你 200 美元的 API token。你获得了上线的许可。六周后，账单变成了 18,000 美元。这并非定价变动或计费错误——而是成本建模的失败，也是 AI 工程中最可预见的意外。

AI 功能在预发布（staging）环境和生产环境之间的成本差距并非偶然。它遵循一个一致的模式：预发布环境在结构设计上（通常是无意的）隐藏了生产环境中每一个关键的成本驱动因素。理解这些驱动因素是避免首份账单演变成危机的关键。

当单个 LLM 给出错误答案时，你的直觉可能是询问更多模型。并行运行三个模型并取多数票——这就是集成（Ensemble）。或者把它们放在一个房间里让它们相互辩论——这就是辩论（Debate）。两者听起来都很严谨，且背后都有同行评审的研究支持。但在条件不成熟时，它们会以完全相同的方式失效，而这正是从业者鲜少讨论的部分。

这种失效模式并不隐晦：当你的所有模型都从相同的数据中学习、带有相同的偏见，或者是由具有相同世界观的人训练时，增加模型数量并不会带来更多信号，只会带来更“自信”的噪声。最近的研究为这一现象给出了量化数据：顶尖前沿模型之间的两两错误相关性（pairwise error correlation）约为 r = 0.77。这意味着大约 60% 的错误方差是共享的。来自不同供应商的三个模型实际上只相当于 1.3 个独立模型，而不是 3.0 个。

2024 年初，Klarna 部署了其 AI 客服聊天机器人，第一个月便处理了 230 万次对话。满意度评分与人工客服持平。高管们宣告大获全胜。然而到了 2025 年，该公司已悄然开始重新招聘此前裁减的人工客服。

究竟哪里出了问题？指标呈现的是一个故事，用户的实际体验却是另一个故事。该聊天机器人在简单的事务性查询——订单状态、支付问题——上表现出色，却在复杂纠纷、欺诈索赔和情绪化对话中频频失手。跨所有交互类型进行平均的 CSAT 评分根本无法发现这一问题。系统看似运转正常，却在悄悄侵蚀用户信任。

这并非 Klarna 独有的失败。这是一个在 AI 产品开发中反复上演的模式：团队收集满意度信号，针对它们进行优化，却为时已晚地发现这些信号度量的并不是真实价值。问题不在于工具本身——而在于反馈到来的时机与响应后果显现的时机之间存在错位。

你的聊天机器人在前十五轮对话中运行完美。然后，问题出现了。它与之前的决定相矛盾。它询问用户已经提供过的信息。它丢失了对话开始时明确定义的多步骤任务的脉络。对话历史在技术层面上还在那里——你没有删除任何内容——但模型的行为却好像它不存在一样。

这就是上下文腐化（context rot）：随着对话历史增长，输出质量逐渐下降的现象。2024 年对 18 个最先进模型进行的评估，涵盖近 20 万次受控调用，发现即使在名义上拥有更大窗口的模型中，可靠性在超过 30,000 个 Token 后也会显著下降。在扩展对话中，高性能模型会变得和小得多的模型一样不可靠。问题不在于你的上下文窗口耗尽了，而在于 Transformer 注意力机制是二次方的——100,000 个 Token 意味着 100 亿对关系——模型被迫将注意力分散得如此稀薄，以至于重要的早期内容实际上被忽略了。

当团队遇到这个瓶颈时，通常会采用两种解决方案之一：截断或摘要。这两种方法都会以可预见的方式让情况变得更糟。

关于 LLM 有一个令人不安的事实，但在产品评论中却鲜少被提及：赋予它们用途的特性，恰恰也是让它们易受攻击的特性。一个顺从地执行指令的 LLM —— 无论指令来自何处、何种格式、何种来源 —— 都会以处理合法指令时那种同样的愉快顺从态度去执行恶意指令。模型无法分辨其中的区别。

这不是一个可以被修补掉的 bug。这是一种架构性的现实。随着这些系统承担起更多智能体（agentic）的角色 —— 阅读邮件、浏览网页、执行代码、调用 API —— 其暴露面正以大多数工程团队尚未察觉的方式扩大。

你的 LLM-as-judge 给新模型开了一张健康证明。胜率上升，各项评分指标全线改善，自动化评测流水线全绿通过。然后你上线了——用户满意度却下降了。

这不是边缘案例。研究人员构建了一个无论何种输入都输出固定回复的「空模型」，并在 AlpacaEval 2.0 上拿下了 86.5% 的长度控制胜率。而当时经过验证的真实最优水平是 57.5%。当一个毫无任务能力的模型都能登顶你的排行榜，你的评测框架就有了值得系统审视的问题。

你运行了一个负载测试。你的 p95 延迟是 450ms。你对此感觉良好，上线了该功能，然后两周后你的轮值告警响了，因为用户在周二上午 9 点看到了 25 秒的响应时间。

你的代码没有发生任何变化。没有部署，没有配置更改。供应商的状态页面显示“正常运行 (operational)”。然而，你的应用在业务高峰时段持续 20 分钟无法使用。

这就是 LLM 容量争用问题，也是工程师在被坑之前最常忽视的故障模式之一。