861 篇博文 含有标签「insider」

你发布了一个模型更新。线下评估看起来没问题。但两周后，你注意到你的资深用户开始编写更长、更严谨的提示词——以一种以前从未见过的方式进行对冲。你的支持队列里充满了类似 “AI 感觉不太对劲” 的模糊投诉。你深入调查后发现，更新引入了一个微妙的行为偏差：模型变得过度肯定用户的想法，验证错误的计划，并削弱了它的反驳力度。你决定回滚。

情况在这时变得更糟了。当你回滚时，迎来了新一波投诉。用户说模型感觉冷淡、简短、没用——这与最初投诉回滚的用户所说的恰恰相反。发生了什么？与有问题的版本互动足够久的用户已经围绕它建立了一套新的工作流。他们学会了更用力地引导模型，更多地反驳，以及更具攻击性地提问。回滚移除了他们已经适应的行为，让他们手足无措。

这就是用户适应陷阱。一个微妙的错误行为，如果在生产环境中保留足够长的时间，就会固化为用户习惯。回滚它并不能恢复现状——它在第一次干扰之上又制造了第二次干扰。

一个在文档理解数据集上达到 97% 准确率的基准测试结果看起来非常有说服力，直到你针对公司的实际发票存档运行它，才发现它正在静默地搞乱 30% 的行项目。模型不会报错，也不会返回低置信度，它只是产生了一个看起来合情合理但却是错误的输出。

这是生产级文档 AI 的典型失效模式：静默损坏 (silent corruption)。与崩溃或异常不同，静默损坏会发生传播。乱码的单元格流入下游聚合，聚合信息喂给报告，报告驱动决策。当你意识到问题时，追踪根本原因就像是在搞考古。

文档 AI 在基准测试表现与生产环境表现之间的差距是真实存在的、持久的，且被评估这些模型的团队所低估。理解为什么会存在这种差距——以及如何防御它——正是本文要解决的工程问题。

大多数后端工程师能够背诵 REST 契约：客户端发送请求，服务器处理请求，服务器返回状态码和响应体。200 表示成功，4xx 表示客户端出了问题，5xx 表示服务器出了故障。响应是确定性的，超时是可预测的，幂等键保证了安全重试。

而 LLM 后端违背了上述所有假设。一个返回 200 OK 的请求，可能意味着模型对整个响应产生了幻觉。一次成功的请求可能需要十二分钟，而不是十二毫秒。两次参数完全相同的请求会返回不同的结果。如果服务器在推理过程中超时，你根本不知道模型究竟是否已完成。

把 LLM 硬塞进传统 REST API 的团队，最终往往面对一堆补丁：超时杀死了正在运行的 Agent 任务，客户端把带幻觉的 200 当成成功，重试逻辑因为幂等键没有针对概率性操作设计而三次扣了用户的信用卡。本文将梳理这些不匹配最致命的地方，以及真正在生产环境中能站得住脚的接口模式。

凌晨两点，报警器响了。仪表盘显示没有 5xx 错误、没有超时激增、没有异常延迟。然而客服已经被淹没："AI 给出了奇怪的回答。"你打开运行手册——立刻意识到它是为完全不同的系统写的。

这是 2026 年 AI 故障响应的标志性失效模式。系统在技术上完全健康。Bug 是行为上的。传统运行手册假设存在离散的失败信号：堆栈跟踪、错误码、不响应的服务。基于 LLM 的系统彻底打破了这一假设。输出语法正确、延迟正常、内容却完全错误。没有任何告警能捕捉到它。唯一的信号是某些东西"感觉不对"。

这篇文章是我第一次不得不响应生产 AI 故障时希望就存在的手册。

你AI系统健康仪表盘上最危险的指标，是99.9%正常运行时间旁边那盏绿灯。如果你第一次得知模型出问题是通过一张支持工单，那你拥有的不是可观测性——而只是感觉。

传统APM工具构建于一个二元故障的世界：请求要么成功，要么失败。对于LLM驱动的功能，这个模型彻底失效。一个请求可以在300毫秒内完成，返回HTTP 200，消耗token，给出一个自信却完全错误、毫无帮助、或比六周前悄然退化的答案。这些故障状态没有一个会触发你现有的告警。

研究持续表明，延迟和错误率加在一起，覆盖的LLM功能故障空间还不到20%。另外80%隐藏在五种故障模式中，大多数团队只有在用户已经注意到之后才会发现。

AI 工程中最昂贵的架构错误不是选错了模型，而是选错了交互范式。本该构建 Agent 的团队花了六个月打磨一个聊天机器人，然后困惑地发现用户什么事也办不成。本该构建 Copilot 的团队接入了完全自主的 Agent，结果用整个季度来扑灭未授权操作和失控成本引发的各种火。

这套分类学在你写下第一行代码之前就至关重要，因为聊天机器人、Copilot 和 Agent 有着根本不同的信任模型、上下文窗口策略和错误恢复需求。选错了不只是产品变差——而是产品无法通过调提示词或换模型来修复。

大多数个性化系统是围绕一个飞轮构建的：用户进行互动，你学习他们的偏好，你展示更好的推荐，他们从而进行更多互动。随着数据的积累，飞轮转得越来越快。问题在于，飞轮需要速度才能产生升力——而新用户完全没有速度。

这就是冷启动问题。而且它比大多数团队在首次发布个性化功能时所认识到的更为危险。一个新用户在到达时没有任何历史记录，没有信号，通常还带着怀疑的先验预期：“AI 并不了解我。”你大约有 5 到 15 分钟的时间来证明并非如此，否则他们就会形成一种定论，决定他们是否会留得足够久，以产生那些能让你真正帮助到他们的数据。如果这个窗口期表现糟糕，高达 75% 的新用户会在第一周弃用产品。

冷启动问题不是数据问题，而是初始化问题。工程上的问题是：在缺乏历史记录的情况下，你应该注入什么？

你发布了一个 AI 功能。模型在你的留出集（holdout set）上达到了 92% 的准确率。你把这个结果展示给产品 VP、法务团队和客户成功主管。每个人都点头表示认可。功能上线了。

三个月后，一个你没有专门测试过的客户群体正面临 40% 的错误率。法务部门在提问。客户成功团队正在处理升级投诉。产品 VP 想知道为什么没有人预警。

92% 这个数字在技术上是正确的。但在作为决策输入时，它几乎是毫无用处的 —— 因为整体准确率恰恰掩盖了那些最重要的信息。

几乎在每一个 AI 产品团队中都会出现这样一种模式：团队发布了初始模型，用户开始与之交互，接着有人在回复底部添加了一个“点赞/点踩”小部件。他们称之为反馈闭环。三个月后，模型并没有任何改进。团队纳闷为什么飞轮没有转起来。

问题不在于执行，而在于显式评分并不是反馈闭环——它们只是调查问卷。只有不到 1% 的生产环境交互会产生显式用户反馈。而那 99% 从未点击任何按钮的用户正在向你发送远为丰富的信号；你只是没有收集它们。构建真正的反馈闭环意味着通过系统埋点来捕获行为轨迹，在大规模场景下高效地标注它们，并将其导回训练和评估流程中，从而实现随时间推移的复利增长。

一家加拿大航空公司的支持聊天机器人凭空捏造了一项根本不存在的丧亲票价政策。该机器人表现得非常自信、格式规范且彬彬有礼。乘客们相信了它。法院随后判定航空公司应对这一虚假政策负责。与此同时，该聊天机器人的满意度评分可能还相当不错。

这就是隐式反馈陷阱。大多数团队用来衡量 AI 质量的信号——点赞评级、点击率、满意度评分——不仅充满噪点。它们还在衡量错误目标方面存在系统性偏见。而针对这些信号进行优化，只会让你的 AI 变得更糟。

大多数团队在起步时都会选择向量数据库 (Vector Store)，因为它们上手简单，但随后会发现即使无论如何调整分块大小 (Chunk size) 或嵌入模型 (Embedding model)，某些类型的查询也完全无法生效。这并非调优问题 —— 而是架构上的不匹配。向量相似度与图遍历是两种根本不同的检索机制，随着查询复杂度的增加，这种差异会变得愈发关键。

这不是一篇推荐“两者兼顾”的文章。在实际应用中需要进行真正的权衡，选择失误会耗费数月的工程时间。以下是这种选择在实践中的真实面貌。

大多数构建 LLM 应用的团队在第三周左右都会发现同样的问题：每次有人运行测试套件时，它都会发起实时 API 调用，消耗真金白银，耗时 30 多秒，且每次运行返回的结果都不尽相同。在原型阶段感觉良好的“直接调用 API”方法，现在变成了迭代速度的沉重负担——而且是账单上的一项重要支出。一个工程团队审计了他们每月的 API 支出，发现 2,847 美元中有 1,240 美元（43%）是由于开发和测试流量不必要地访问实时端点而产生的纯粹浪费。

解决方案不是停止测试，而是从一开始就构建正确的开发循环——让快速路径既便宜又具有确定性，而将慢速路径（真实的 API 调用）留给真正需要的时刻。