990 篇博文 含有标签「insider」

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

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

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

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

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

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

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

你的 RAG 系统存在一个不会抛出异常的 Bug。它不会拉高错误率，不会在延迟仪表盘上留下痕迹。相反，它会悄悄地给出听起来自信、合理却错误的答案——而没有人在数周内察觉。

这就是 RAG 中的数据契约问题：你的摄取管道是下游所有环节的事实来源，但它没有 Schema 校验、没有新鲜度保障，也没有在外部世界的形态悄然改变时发出告警。每当上游数据源新增字段、分块参数发生偏移，或者嵌入模型被更新，检索质量就会无声地退化。

80% 的企业级 RAG 项目在生产环境中会遭遇严重故障，而其中最隐蔽的那些故障从不宣告自身的存在。

你的 AI 功能顺利发布。评估集准确率：91%。延迟：可接受。团队深感自豪。六个月后，用户开始抱怨该功能感觉“很笨”，支持工单不断增加，而你的综合指标悄然比发布当天下降了 8%。没有人更改过模型。底层数据流水线完好无损。发生了什么？

这就是逆行准确率问题（The retrograde accuracy problem）。随着产品的增长——新功能、新用户细分、新边缘情况、新流程——你的 AI 在生产环境中看到的输入分布会悄然偏离其训练时的分布。模型没有更新，数据流水线没有故障，而是产品本身的增长超出了模型的能力范围。

你的公司运行着一个共享的 LLM 服务集群。两个租户在使用它：一个面向客户的聊天机器人，其首令牌延迟 SLO 为 500 毫秒；以及一个批量文档丰富管道，通宵处理数千个长上下文提示。某天凌晨三点，聊天机器人团队把你叫醒，因为他们的 P95 TTFT 飙升到了 12 秒。根本原因：批处理任务比预期更早启动，用预填充工作占满了 GPU 内存，而聊天机器人的短请求在一列 8,000 个令牌的提示后面等待。你的 FIFO 调度器给了它们同等的优先级。在你手动终止批处理任务之前，聊天机器人的 SLO 已经被违反了 4,000 次。

这种故障模式很常见，理论上早已被理解，但在实践中却出人意料地普遍。大多数团队部署 vLLM 或 TGI 时使用默认的 FIFO 调度器，随着时间推移添加多个工作负载，只有在发生事故时才发现优先级反转问题。

大多数 AI 团队只会构建一次评测套件——在上线前的冲刺阶段，他们精心设计了边界场景用例，记录预期输出，经过评审后发布。六个月后，套件仍然通过。然而，模型在实际生产流量上已经悄然退步，而评测框架却是在那些流量出现之前编写的。它仍然在评判作者提出问题的答案，而非用户真正在问的问题。

这就是"博物馆问题"：一个在某个时间点策划的评测套件会不断积累文物。它证明系统能处理某人预期的场景，却无法覆盖真正让它崩溃的场景。

大多数 AI 功能发布延迟，并不是因为它们有缺陷。它们延迟，是因为团队仍在针对一套不能反映真实用户行为的测试集进行优化。每周基准分数都在提升，评估指标持续向好。而"实验室表现"与"生产价值"之间的差距，却在悄悄扩大。

令人不安的事实是：最初的 500 名真实用户，在两周内发现的可操作问题，远比再花四周调优提示词要多。这不是在为发布劣质产品辩护，而是在说：你当前对"准备好了"的判断，几乎肯定是错误校准的——只有真实的使用数据才能纠正它。

你的仪表板显示全绿。延迟处于正常水平。错误率为 0.2%。本月正常运行时间为 99.97%。然而，你的 AI 助手正自信地向用户提供错误的信息，格式不对，长度是预期的两倍——而且这种情况已经持续了 11 天。

这就是 SLA 幻觉：基础设施合同保障的是管道，而不是其中流过的水。对于 AI 驱动的功能，“它是否有响应？”与“它的响应是否准确？”之间的差距，正是产品质量悄然崩塌的地方。

大多数 LLM 系统故障并非源于模型出错。而是源于系统误判了模型能够强制执行的约束。当你在系统提示词中写下“绝不泄露客户数据”并将其等同于“撤销数据库凭据”时，你引入了一个范畴错误。这最终会导致安全事件、可靠性故障或受损的用户体验——而你直到故障在生产环境中发生时才会察觉。

软约束与硬约束之间的区别是架构层面的，而非风格层面的。搞错这一点不会导致风格退化，而是会导致安全漏洞。

大多数关于AI延迟的讨论都搞错了方向。团队痴迷于GPU利用率、模型量化和批处理大小。与此同时，真正让用户感到烦躁的延迟——AI开口说话前的那段停顿——几乎完全由推理开始前发生的事情决定。瓶颈在于上下文，而非算力。

首Token时间（TTFT）是决定AI功能感觉灵敏还是迟钝的关键指标。而TTFT主要由预填充阶段主导：在生成任何输出Token之前，处理完整输入上下文所需的时间。对于128K Token的上下文，预填充可能耗时数秒。GPU在努力工作，但用户什么也看不到。

解决方案不是更好的GPU，而是在用户提问之前就预先加载好上下文。

你的测试环境通过了所有检查。LLM 对每个测试提示词都做出了正确响应。延迟表现良好。质量评分看起来也不错。你发布了。然后，两天后，生产环境开始在你的评估集从未涵盖的一类查询中出现幻觉，你的成本飙升了 3 倍，因为缓存是冷的，而且你的供应商推送的模型更新静默地改变了行为，而你的旧测试套件无法检测到。测试环境显示一切正常，生产环境却给出了截然不同的结果。

这并不是一个可以通过编写更多测试用例来弥补的测试差距。预发布环境对 AI 系统具有结构性的误导，而对传统软件则不然。失败模式是系统性的，解决办法不是更好的测试环境，而是一种不同的架构。