861 篇博文 含有标签「insider」

我认识的一个团队花了三个月时间构建了一个基于规则的地址标准化器。它处理了最常见的 20 种格式，使用 USPS API 进行验证，并且在他们见过的数据上表现出色。然后他们迎来了一个新的企业客户。第一周的数据中，地址被嵌入在自由格式的备注字段里，邮政编码缺少国家前缀，还有他们的规则从未见过的跨境格式。这个标准化器在 31% 的记录上发生了静默失败。他们尝试用 LLM 作为一个快速修复方案，预期准确率为 80%，结果得到了 94%。令人惊讶的不是 LLM 奏效了 —— 而是他们的评估框架中没有任何指标预见到了这一点。

这就是问题的现状。基于规则的标准化是可预测的、快速且廉价的。当数据分布在预设范围内时，它表现良好。LLM 处理的是长尾部分 —— 那些奇怪的格式、隐含的领域知识以及规则永远无法穷举的边缘情况。但 LLM 也很昂贵、缓慢且不稳定，如果你不小心，它们会破坏生产流水线。对于几乎每个团队来说，正确的答案是采用混合方案，在各自擅长的输入上分别使用这两种方法。

产品团队已经开始直接将分析问题路由给 LLM：“是什么导致了流失率激增？”“为什么重新设计后转化率下降了？”“我们应该把留存预算重点花在哪个群体上？”输出结果出现在高管汇报幻灯片中，驱动着路线图决策，并向投资者展示。模型以优雅的文字和具体的数字自信地作答。然而，这些答案中有很大一部分是以一种不易察觉的方式出错的。

这并不是对用 LLM 处理数据工作的全面批评。在某些任务中，它们确实很有帮助。问题在于其失败模式是隐形的——模型不会留有余地，不会说明局限性，也不会区分“我是根据你的数据计算出来的”和“我生成了一个听起来像这个数字应该是多少的东西”。了解故障发生位置的从业者可以捕捉到真正的价值并避开雷区。

大多数工程团队认为自己已经对 LLM 供应商锁定做了充分防护：用 LiteLLM 统一 API 调用、避免在托管平台上做微调、把原始数据存在自己的存储里。他们感到安全。然后某天提供商宣布弃用某模型，或竞争对手降价 40%，团队才发现，自己搭建的抽象层大概只处理了约 20% 的实际迁移成本。

另外 80% 藏在没人仔细看过的地方：围绕模型格式怪癖写成的系统提示词、按照某个模型的拒绝阈值校准的评估套件、一旦换模型就会失效的嵌入索引，以及建立在某种行为模式上却根本无法迁移的用户预期。

某零售采购智能体在"初始测试期间"继承了供应商 API 凭证，却没有人在系统投产前对其加以限制。当一个差一错误触发后，该智能体拥有完全的下单权限——永久生效，毫无限制。等财务部门察觉时，已有价值 47,000 美元的未授权供应商订单发出。代码没有问题，模型也按设计运行。造成如此大破坏的，是权限问题。

这就是最小足迹原则：智能体应仅请求当前任务所需的权限，避免在任务范围之外持久化敏感数据，清理临时资源，并将工具访问权限限定于当前意图。这是 Unix 最小权限原则在新时代的延伸——在这个时代，代码会在运行时自主决定下一步需要做什么。

团队之所以在这里屡屡犯错，并非出于疏忽，而是概念错误：他们把智能体权限当作设计时的工作，而智能体 AI 使其成为了运行时问题。

当你在多个区域运行无状态 HTTP API 时，路由问题基本上已经解决了。在前面放一个全球负载均衡器，按地理位置分配请求，最糟糕的情况也不过是缓存项稍微过时。任何副本都可以处理任何请求，并获得相同的结果。

LLM 推理打破了每一个假设。一旦你添加了提示词缓存（Prompt Caching）——你肯定会加，因为缓存命中和未命中的成本差异大约是 10 倍——你的服务就会以大多数基础设施团队预料不到的方式变得有状态，直到他们在第二个区域看到延迟数据退化。

你的 SaaS 产品以十个设计客户的规模上线，一切运转完美。随后你陆续接入了一百个租户，其中一个——一位在复杂研究工作流中使用 20 万 token 上下文窗口的重度用户——导致了所有其他客户的延迟飙升。支持工单开始涌来。你查看监控面板，却看不到任何明显异常：模型健康，API 返回 200，p50 延迟看起来正常。而你的 p95 已经悄悄翻了三倍。

这就是嘈杂邻居问题，它对 LLM 基础设施的冲击比几乎任何其他共享系统都要剧烈。以下是它为何比数据库场景更难解决——以及真正有效的应对方案。

你的单次请求错误率看起来很正常。延迟在 SLO 范围内。LLM 裁判对输出的评分是 87%。接着，一位用户提交了支持工单：“我把账号告诉了机器人三次，它却一直重复问我。”另一位用户说：“它先是同意退款，两轮对话后又否认该政策的存在。”

单轮失败是显而易见的。请求进来，模型出现幻觉或拒绝回答，你的评估 (eval) 捕捉到了它，然后你修复提示词。反馈循环很紧密。多轮失败则完全不同：会话开始时表现良好，随后逐轮恶化，而你的监控从未报警，因为每个单独的回复在技术上都是连贯的。问题出在整个会话上——而几乎没有团队为此建立观测机制。

对主要前沿模型（Claude 3.7 Sonnet、GPT-4.1、Gemini 2.5 Pro）的研究显示，从单轮转向多轮对话时，平均性能会下降 39%。这个数字掩盖了真相：只有大约 16% 的下降是由于能力损失。另外 23 个百分点则是一场可靠性危机——随着对话长度增加，模型在同一任务上的最佳表现与最差表现之间的差距翻了一番。你得到的不仅是质量更差的输出，还有极不稳定的输出。

你的 p99 延迟刚刚飙升到了 12 秒。警报在凌晨 3:14 响起。你打开运维手册 (runbook)，看到如下指令：检查数据库连接池、验证负载均衡器、重启服务。你三样都做了。延迟依然居高不下。服务并没有宕机——它正在运行且有响应。但有些地方不对劲。事实证明，由于最近的一次提示词 (prompt) 变更无意中开启了“啰嗦”模式，模型生成的响应比平时长了三倍。运维手册里没有关于这一条的说明。

这是工程团队尚未准备好应对的新一类值班事故：系统正在运行，但模型表现异常。传统的 SRE 运维手册假设的是二进制的故障状态。AI 系统是以概率方式失效的，其症状看起来不像停机，而更像“漂移”(drift)。

新员工在入职第三天就上线了一个新功能。团队里的每个人都印象深刻。三周后，她引入了一个 Bug，一位资深工程师只用了五个字就解释了原因：“我们不那样做。”她对此一无所知，写出那段代码的 AI 也是如此。

AI 编程助手极大地缩短了新工程师完成“首次提交”的时间。但这种速度掩盖了一个大多数团队都没有察觉到的权衡：过去那种让初级工程师速度慢下来的“代码阅读”过程，恰恰是教会他们系统如何实际运作的关键。剥离了这个过程，你得到的就是那些能够将自己不理解的功能发布到尚未内化的架构中的工程师。

问题不在于工具。而在于我们没有更新入职流程，以适应 AI 现在所做的工作 —— 以及它不再要求工程师亲自去做的事情。

你的 AI 演示确实令人印象深刻。高管观众们纷纷点头，工程副总裁（VP of Engineering）直言“这就是未来”，试点项目也获得了真金白银的预算批准。六个月后，周活跃用户数（WAU）停滞在 12%。在全体会议上，这款工具会被客气地提及。没人忍心宣布它已经失败。这就是试点坟场（pilot graveyard）——优秀的演示项目最终消亡的地方。

这种失败并非个案。大约 88% 的企业 AI 试点项目从未进入生产阶段。只有 6% 的企业成功地将生成式 AI 项目从试点推向了具有一定规模的生产环节。从“会议室里令人惊艳”到“日常工作流中的支柱”之间的巨大鸿沟，正是大多数企业 AI 投资付诸东流的地方。

原因不在于模型，而在于演示之后发生的一切。

Cursor 在 2025 年实现了 10 亿美元营收，却亏损了 1.5 亿美元。客户支付的每一分钱都直接流向了 LLM API 供应商，工程、支持和基础设施开销无从覆盖。这不是一个规模化问题——而是一个单位经济学问题，在酿成危机之前始终隐而不见。

大多数构建 AI 功能的工程团队都在犯同一个错误：把推理成本当作一个无关紧要的小项，上线固定费率订阅，然后假设经济账迟早会算对。但它永远不会自己算对。可变推理成本的行为方式与软件中任何其他 COGS 都截然不同——一旦你最重度的用户发现了你最昂贵的功能，那些适用于传统 SaaS 的定价架构就会让你流血不止。

2025 年 4 月，全球使用最广泛的 AI 产品之一更新了系统提示词。错误率保持平稳。延迟表现正常。部署仪表盘显示一切正常。然而在三天内，数百万用户发现了一些严重的问题：模型变得异常谄媚，附和错误的想法，验证糟糕的推理，并对用户说的任何话都表现出虚假的热情。回滚公告发布时，该事件已经席卷社交媒体，用户纷纷晒出截图作为证据。在一段时间内，Twitter 成了生产告警系统。

当你把提示词和模型的变更当作配置更新，而不是行为部署时，就会发生这种情况。那些在代码金丝雀基础设施上投入多年的团队，却仍在以单一原子级切换的方式发布 AI 变更——瞬间全球化、瞬间不可逆，没有分级发布，除了用户投诉外也没有自动回滚信号。

LLM 行为的金丝雀部署并非可有可无。它是缺失的基础设施层，区分了那些能在内部捕捉退化的团队，和那些只能通过支持工单发现问题的团队。