702 篇博文 含有标签「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% 通常分布在六七个没人追踪的阶段中。孤立地看，每一项似乎都很小，但它们共同占据了主要的优化空间。

当团队对 AI 管道进行提示注入加固时，通常只聚焦于文本：清洗用户输入字符串、扫描输出中的外泄数据、过滤已知的越狱（jailbreak）模式。这些工作固然重要，但对于现代 AI 系统而言，它们大约只覆盖了一半的攻击面。另一半隐藏在图像、PDF、音频片段和图表之中——这些格式能绕过你写下的每一条文本扫描规则，因为模型处理它们的通道与处理文本的通道完全不同。

针对视觉语言模型的隐写注入攻击（steganographic injection attacks），在包括 GPT-4V、Claude 和 LLaVA 在内的生产模型上，成功率约达 24%。这个数字并非实验室数据，而是来自真实的攻击载荷——隐藏在看似普通的图像中，使生产模型偏离预期行为。你的文本注入扫描器对此毫无察觉。

大多数防御提示词注入 (Prompt Injection) 的团队都会联想到一个攻击者：一个精心设计特定字符串以覆盖 AI 指令的人。这种思维定式是错误的，并让他们付出了代价。这个问题更难的版本根本不需要攻击者。

每当你的 AI 应用摄取用户生成的内容时 —— 无论是产品评论、工单、上传的文档还是 CRM 笔记 —— 它都面临着同样的结构性漏洞。无需恶意企图。普通用户出于普通原因生成的普通文本，在规模化的情况下，其表现可能与蓄意的注入攻击完全一致。如果你的应用仅针对对抗性案例进行防御，那么你防御的只是少数情况。

你的 RAG 系统很可能正在把自己的输出编入索引。只是你还不知道而已。

一切往往从一件看似无害的事开始：有人把一份季度总结文档添加到了知识库。而这份总结，正是由查询该知识库的同一个 LLM 生成的。六个月后，开发者又加入了 AI 生成的版本说明，随后是自动生成的支持 FAQ，再然后是合成的入职指南。这些文档没有任何一份被标注为 AI 生成。对于检索系统而言，它们与人工撰写的一手资料看起来别无二致。于是，当你的模型检索上下文来回答问题时，其中相当一部分上下文是之前某次模型运行所输出的压缩版、甚至可能已经失真的结果——而你的准确率指标依然绿灯常亮。

这就是溯源债务：在检索语料库中，AI 生成的内容在没有来源标记的情况下不断累积，形成一个反馈循环——每一代模型的输出，都成为下一代模型的原始素材。

有一种特定的失效模式正在悄悄破坏 AI 产品的数据指标，却没有人察觉。你的仪表盘显示建议接受率为 34%、DAU 强劲、功能参与度持续增长。仪表盘没有显示的是：60% 被接受的建议随后被立即重写，参与度最高的用户正是那些点击 AI 输出、全选，然后自己重新输入的人；这个功能对下游任务完成率零可测影响。

这就是"安静放弃"模式：用户系统性地绕过 AI 功能，同时产生活跃用户的全部表面指标。他们不会禁用该功能——他们只是忽略其输出。在你的分析系统中，他们与最佳 AI 用户看起来完全相同。

凌晨 2 点，一个定时报告生成任务向共享的 API 密钥并行发出五十个 LLM 请求。等到早上 9 点的产品演示开始时，每一个实时对话补全都在悄无声息地超时。错误仪表板一片绿色，日志里没有 429 错误。模型确实在返回响应——只是慢了十秒，而这个功能的 SLA 是两秒。

这就是配额饥饿。它不像故障，它看起来只是"今天 AI 有点慢"。

你的 RAG 评估套件在忠实度（faithfulness）方面达到了 0.89。你向知识库添加了 5,000 个新的支持文档。你重新运行相同的评估，忠实度降到了 0.79。你的团队提交了一个模型退化（model regression）工单。

其实没有任何退化。你的评估只是变成了一个谎言。

这就是 RAG 评估失效悖论：在你更新知识库的那一刻，你针对旧索引构建的评估集就会悄无声息地停止衡量其设计的初衷。大多数团队在几个月后才会发现这一点——在为幻影般的退化消耗了大量的工程周期之后——如果他们真的能发现的话。