跳转到主要内容

我们已经有了:当 AI 功能在重新造你已有的代码轮子

阅读需 2 分钟Tian PanTian Pan

我合作过的一个团队在上季度发布了一个“智能”日期提取器。该模型可以解析像“下周二”和“14 号之后的两周”这样的自然语言短语,在生产环境中通过功能标志 (feature flag) 运行,在选定的层级上每次请求的成本约为 3 美分。六周后,一位后端工程师偶然参加了一场设计评审,随口提到公司其实早就有了一个日期解析器。它编写于 2019 年,存在于一个 AI 团队中没人读过的工具模块里,能以不到 1 毫秒的延迟处理 99.4% 的相同输入,而且运行成本几乎为零。那个 AI 功能并没有被撤下,而是被合理解释了——“模型可以处理长尾情况”——于是团队继续前进,发布了一个比公司已有方案更贵、更慢、准确度更低的版本。

这并非个案。对于那些比 AI 团队成立时间更久的公司来说,这是 AI 功能最主要的失败模式。这种模式不断重复:一个智能分类器复制了多年前编写的正则表达式流水线;一个检索系统获取了一个内部服务一直作为类型化表维护的供应商列表;一个智能体 (agent) 学习提取那些解析器已经可以确定性提取的实体。AI 功能发布的质量标准甚至低于它并不知道其存在的确定性系统,而构建确定性系统的团队往往在跨团队会议上才发现这一点。

这种失败模式并非技术问题,而是组织内部的发现 (discovery) 问题。构建 AI 功能的团队不知道现有的能力,因为它是由 2021 年离职的人编写的,存在于一个 AI 团队从未点击进入的服务中,或者被记录在无人开启的 Wiki 页面上。代码库里有答案,但组织架构掩盖了它。

发现鸿沟比 AI 团队意识到的还要深​

大多数 AI 团队都是新成立的。他们在过去 24 个月内组建,通常是从现有工程组织之外招聘的,他们对绿地项目 (greenfield work) 的偏向是结构性的——他们的奖励机制与发布新颖的机器学习能力挂钩,而不是去阅读别人 2019 年写的工具代码。他们视为基座的代码库就是他们自己写的。除此之外的一切都是黑盒。

同时,那些他们本可以受益的确定性能力,恰恰是最不容易被宣传的。2019 年编写的正则表达式解析器没有营销预算。拥有它的团队不会出现在 AI 架构评审会议上。它的 README(如果有的话)上次更新是在 2020 年,引用的是一个此后已被重构的系统版本。这种能力存在、有效,但却是不可见的。

这种不可见性在典型的组织拓扑中进一步加剧。一个拥有三千个文件的单体仓库 (monorepo) 看起来像是一个统一的代码库,但实际上是一组“割据领地”的联邦——每个目录都有一个所有者、一种部落式风格和一套约定,该领地之外的工程师如果没有帮助就无法在其中穿行。工程师在代码库中重新发现做某事的“正确方法”所花的时间,可能比实际实现它还要多。AI 团队没有预算这笔重新发现的成本,所以他们从不支付。相反,他们选择从零开始。

重复建设的代价不只是 Token​

当 AI 功能复制了确定性能力时,显性成本是推理账单。这个数字是真实的,但并不是最大的成本。更大的成本发生在下游,且很少被计入 AI 功能的投资回报率 (ROI)。

第一个隐藏成本是质量退化。一个经过五年磨练和实战检验的正则表达式解析器,已经处理过生产流量中出现的每种奇怪输入——Unicode 边缘案例、特定地区的日期格式,以及企业级用户坚持使用的特殊标点。而在通用语料库上训练的新模型则没有。它会处理好大多数情况,但在少数情况下会出现灾难性的错误,而这些灾难性错误在有人意识到问题在于大语言模型 (LLM) 幻觉出了一个确定性解析器本会拒绝的日期之前,会穿透三层智能体基础设施。LLM 不提供确定性的信息。这并不是特定模型的 bug,而是其本质。当现有的确定性系统能处理该情况时,换成随机性系统是一种在延迟、资金和罕见但严重失败方面的降级。

第二个隐藏成本是延迟。确定性解析器在微秒内返回。而模型在最好情况下也需要数百毫秒,在长尾情况下则需要数秒。如果 AI 功能处于面向用户的路径上,这笔延迟预算就耗尽了——团队将在下一个季度努力通过 Prompt 缓存、更小的模型和并行投机迭代 (speculative decoding) 来夺回几毫秒,试图优化到确定性版本本来就有的延迟水平。

第三个隐藏成本是运维表面积。确定性能力没有评估套件,没有 Token 预算,没有供应商依赖,没有降级策略,没有限流处理,没有分阶段发布——因为不需要这些基础设施。而 AI 替代方案需要这一切。每增加一个重复的能力,平台团队需要运维的表面积就会成倍增加,而平台团队的人员增长速度并不会与他们继承的表面积成比例。

政治后果是最糟糕的部分​

如果唯一的成本只是金钱和延迟,权衡的结果依然会向“先审计”倾斜。但多年累积下来的成本是政治性的,而大多数 AI 团队并未意识到这一点。

当一名遗留系统维护者在跨团队会议上得知 AI 团队发布了一个替代其工作的功能时,他们会准确地解读现状:他们的工作在未经协商的情况下被抛弃了。维护者的反应是理性的。他们不再与 AI 团队共享上下文,不再参加架构评审,不再主动告知他们的服务能做什么。下一次当 AI 团队准备在一个确定性功能(deterministic capability)上重新构建时,那个原本会发出警告的人已经不再参加那个本该发出警告的会议了。

这是一种自我强化的失败。AI 团队对遗留功能缺乏了解,导致了重复建设(recapitulation)。重复建设疏远了这些功能的维护者。这种疏远减少了信息流动,进而加深了无知,催生了下一次重复建设。在一两年内,公司实际上会拥有两个互不交流的工程组织,而 AI 团队则在一种永久性的“发现赤字”中运营,且无法弥补,因为那些能弥补这一缺口的人已经停止了交流。

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 9 分钟

自研还是采购的界限已然改变:当供应商原语吞噬你的基础设施时,如何抉择 AI 功能

供应商 API 正在不断吸收你曾经需要自建的检索、记忆和结构化输出层。本文提供了一个四象限框架,用于决定哪些该自研,哪些该租用,以及你真正的护城河究竟在哪里。

ai-engineering
architecture
阅读需 11 分钟

无法收敛的验证器循环

Worker-critic 代理循环承诺向质量收敛,但很少真正兑现——验证器是一个随机策略,max-iterations 上限是披着质量门外衣的预算门,而能恢复终止性的模式都把满足曲面当作真正的架构问题来处理。

insider
ai-agents
阅读需 10 分钟

那个悄然演变成延迟敏感型服务的夜间批处理作业

随着一个又一个合理需求的加入,一个夜间批处理作业最终演变成了对延迟要求极高的服务。本文将探讨为什么批量推理和在线推理的优化目标截然相反,架构漂移如何导致隐蔽的故障,以及如何有针对性地进行重新架构。

insider
ai-engineering
阅读需 10 分钟

黑板模式回归:1980 年代的 AI 如何处理多智能体协作

通过共享计划文件进行协作的智能体团队正在重新发现 20 世纪 70 年代的黑板架构 —— 但他们只重建了白板,却遗忘了让其发挥作用的调度器、置信度评分和层级结构。

insider
ai-agents
阅读需 9 分钟

在构建下一层 AI 技术栈之前,请先绘制 Wardley 地图

关于 AI 基础设施的‘自研还是外购’的争论,往往假设了一个并不存在的稳定格局。Wardley 地图揭示了你的技术栈中哪些层会在几个月内商品化,以及哪些组件(如领域评估和私有数据)正朝着相反的方向发展。

insider
ai-engineering