720 篇博文 含有标签「llm」

当单个 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 容量争用问题，也是工程师在被坑之前最常忽视的故障模式之一。

当你的 LLM 智能体失败时，最诱人的事情莫过于问它为什么。它会给出流畅、具体、看似充满自我意识的回答。它可能会说："我误解了用户的意图，检索了关于 X 的文档，而实际上应该定向到 Y。"听起来就像是根本原因。你把它记下来，打开提示编辑器，然后花四十分钟追查一个错误的问题。

这就是 LLM 自我调试的核心陷阱。模型的解释和模型实际的失败机制是两回事。有时两者重叠，但经常并不重合。在采取行动之前判断自己处于哪种情况，是区分快速调试和昂贵弯路的关键所在。

你的 LLM API 返回的 P50（中位数）延迟为 800 毫秒。你的仪表板显示为绿色。你的 SLA 规定“两秒以内”。接着，一个用户提交了工单：“它转了 30 秒然后就放弃了。”你检查日志，发现 P99 延迟高达 28 秒。

这种差距——中位数与尾部延迟之间 35 倍的比率——并非偶然。这是 LLM 工作原理的结构性属性，仅仅通过调整超时时间是无法消除的。

2025 年的研究发现，提交给商用 LLM 的 Prompt 中有 8.5% 包含敏感信息——PII、凭据和内部文件引用。这一统计数据可能低估了问题的严重性。它只计算了用户显式输入的内容，而没有计算系统静默添加的内容：检索到的客户记录、数据库查询的工具输出、从之前会话持久化的记忆，或者是训练前未经过清洗的微调数据。大多数 AI 流水线的 PII 泄露并非源于用户错误，而是源于没有单一工程师负责的架构盲点。

失效模式几乎总是一样的：团队发布了一个 AI 功能，认为“我们不发送个人数据”，但个人数据却从缝隙中进入了——在包含客户地址的 RAG 检索分块中，在返回完整用户档案的智能体工具输出中，或者在从 CRM 导出且未经脱敏（redaction）的微调数据集中。GDPR 的数据最小化原则要求你只收集特定目的所必需的数据。LLM 架构在默认情况下违反了这一点。

你的微调模型在评估套件上达到了 93% 的准确率。你将其上线。三周后，一位客户发来截图：模型以十足的自信回答了一个从未出现在训练数据中的问题——而且答错了。这并非通常意义上的幻觉，而是一段记忆。一种在预训练阶段烙入权重的模式，在微调从未覆盖的分布上死灰复燃。这就是预训练残留（pretraining residue），也是生产微调中最容易被忽视的故障模式之一。

微调调整的是权重，而不是从头重新训练模型。在万亿 token 规模预训练期间形成的模式——校准机制、置信度信号、世界模型先验——依然留存于权重之中。无论你的微调数据集多么精心策划，它都只是叠加在更深层先验之上的薄薄一层。当输入落在你的微调分布之外时，模型不会说"我不知道"，而是回溯到预训练，自信地给出答案。

2026 年 3 月，一场集体诉讼指控 Perplexity 的“无痕模式”（Incognito Mode）正在将对话数据和用户标识符路由到 Meta 和 Google 的广告网络 —— 甚至对于明确激活了该功能的付费订阅者也是如此。该功能被称为“无痕”。用户认为这意味着私密。但实现方式却并非如此。

这是 AI 隐私模式中最常见的失败模式：名字是营销，实现是“留存戏剧”（retention theater）。工程师上线了一个开关。法务批准了措辞。用户按下开关并信任它。但在数据管道的某处，输入内容仍在流向日志服务、训练任务或某个没人记得拦截的第三方分析 SDK。

你的团队刚刚花了三周时间优化推理。你们换成了量化模型，调整了批处理策略，成功缩短了 12% 的首字延迟 (TTFT)，然后上线了。接着你查看了实际的面向用户的延迟，发现几乎没有变化。

这就是“推理陷阱”。它是 LLM 应用中最常见的性能分析失效模式，其发生的原因是工程师们习惯于测量那些容易测量的指标——GPU 利用率、推理吞吐量、每秒 Token 数 (TPS)——而不是真正缓慢的部分。在一个典型的 RAG 流水线中，如果包含所有涉及 GPU 的环节，推理大约占延迟的 80%。但剩下的 20% 通常分布在六七个没人追踪的阶段中。孤立地看，每一项似乎都很小，但它们共同占据了主要的优化空间。