我们已经有了:当 AI 功能在重新造你已有的代码轮子
我合作过的一个团队在上季度发布了一个“智能”日期提取器。该模型可以解析像“下周二”和“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 团队则在一种永久性的“发现赤字”中运营, 且无法弥补,因为那些能弥补这一缺口的人已经停止了交流。
- https://www.nightfall.ai/blog/regex-vs-ai-based-detection
- https://www.johndcook.com/blog/2024/12/15/llm-and-regex/
- https://dev.to/dthompsondev/llm-structured-json-building-production-ready-ai-features-with-schema-enforced-outputs-4j2j
- https://www.cio.com/article/4097339/your-next-big-ai-decision-isnt-build-vs-buy-its-how-to-combine-the-two.html
- https://medium.com/@brett_Tcalhoun/build-vs-buy-in-the-age-of-ai-1429e74b6e3c
- https://www.port.io/blog/catalog-discovery
- https://www.harness.io/harness-devops-academy/resource-discovery-implementation
- https://hatchworks.com/blog/gen-ai/build-vs-buy-framework/
