8.0
热点
AI SCORE
技术实践2026-08-17 13:47
企业 AI 瓶颈不是模型，而是遗留架构
dev.to · AI#架构#AI落地#企业IT
Editor brief · 编辑速览
作者认为多数企业 AI 落地卡在遗留架构而非模型本身——批处理数据、实时性不足导致 AI 无法充分发挥作用；解法是局部现代化而非推倒重来。
我的观点：大多数企业现在不需要更好的 AI 模型。
他们需要更好的基础设施。
我们在 AI 模型（GPT vs Claude vs Gemini）、Agent 框架、RAG 架构、向量数据库和模型基准测试上花费了大量时间进行讨论。
与此同时，一些公司仍然通过夜间批处理任务来传输关键业务数据。
这是没人愿意谈论的矛盾。
你可以把一个能力极强的 AI 模型放在企业系统之上，但如果该模型必须等待 24 小时才能获得所需的数据，那么你建造的不过是一个极其昂贵的报告工具。
我认为遗留架构正在成为企业 AI 最大的隐性约束。
而解决方案不一定是"替换一切"。
事实上，我认为这种方法通常是错误的。
更好的方法是实现系统现代化——那些阻碍 AI 实时访问、处理和执行业务数据的部分。
想象一个欺诈检测系统。
一笔交易发生。
AI 模型理论上可以几乎即时评估数十个信号：
模型不一定是问题所在。
问题出现在这些信号存在于五个不同的系统时。
突然之间，你的"实时 AI"不再实时了。
GeekyAnts 最初的遗留系统分析正好做了这个区分：AI 也许能够快速做出决策，但断连的系统以及延迟的数据会阻止决策以业务所需的速度发生。
这就是为什么我认为关于企业 AI 的讨论需要转变。
问题不仅仅是"这个模型有多智能？"
还包括："智能能以多快的速度在组织中流动？"
实时 AI 不仅仅是一个 LLM 响应快速。
一个实时决策系统需要整条事件链都能快速运转：
Business Event
↓
Data Capture
↓
Data Processing
↓
Context Retrieval
↓
AI / ML Decision
↓
Business Rule Validation
↓
Action
↓
Feedback
如果这条管道中的任何部分依赖于缓慢的遗留系统，整个体验都会受到影响。
这使得企业 AI 变成了一个架构问题。
说实话，我认为这是一件好事。
因为架构是企业实际上能够修复的东西。
企业数据很少存在于一个地方。
遗留架构往往只提供碎片。
模型接收到的信息是不完整的。
而一个上下文不完整的 AI 系统可能给出一个完全错误的自信答案。
这比没有 AI 更糟糕。
大量企业软件是围绕调度处理设计的。
这在企业生成报告时完全合理。
但当软件需要响应实时发生的事件时，这就变得不那么合理了。
传统系统可能定期更新库存。
现代 AI 系统可能想要对以下情况做出反应：
等待下一次批处理更新就违背了目的。
这就是为什么我强烈主张对 AI 密集型企业系统采用事件驱动架构。
当重要的事情发生时，系统应该知晓。
而不是等到夜间 ETL 之后。
现代 AI 系统通常需要与以下系统通信：
遗留应用程序并非总是为这种级别的连接性而设计。
结果是可以预测的：
每一个 AI 计划都变成了一个集成项目。
这也是我不认为企业应该将 AI 就绪度与集成架构分开评估的原因之一。
如果连接一个新的 AI 能力需要六个月的定制集成工作，那么 AI 模型不是你最大的问题。
你的架构才是。
这是高管们容易低估的部分。
一个团队获得批准来构建 AI 能力。
工程团队开始工作。
然后有人发现：
"我们无法访问那个数据。"
"那个 API 已被弃用。"
"没人知道为什么这个服务会以这种方式转换数据。"
"原始开发人员八年前就离开了。"
现在 AI 项目悄然变成了一个遗留现代化项目。
源文章在紧耦合系统和累积技术债务方面提出了类似的观点：修改旧应用程序会带来更长的开发周期、更高的运营风险和不断增加的维护复杂性。
这就是为什么我认为 AI 采纳将比以往几乎任何技术浪潮都更快地暴露技术债务。
AI 需要互联的系统。
遗留系统往往正因为擅长规避变化而存活下来。
这两个特性并不是特别搭配。
以下是我与极端现代化叙事不同意的部分。
你不一定需要丢弃你的遗留平台。
在许多企业中，这不现实。
系统可能很老，但它仍然可能可靠地处理价值数十亿美元的交易。
仅仅因为它老就替换它是不负责任的。
我宁愿看到企业采用一种扼杀者风格的现代化方法：
Legacy System
↓
API / Integration Layer
↓
Event Streaming
↓
Modern Data Layer
↓
AI Services
↓
New Business Capabilities
现代化那些阻碍业务发展的部分。
保留那些仍然有效的部分。
逐步将能力从单体中分离出来。
这比五年"替换一切"计划要实际得多。
我故意不将其称为客观排名。
没有通用的"最佳 AI 公司"。
合适的合作伙伴取决于你是在解决架构问题、组织转型问题、现代化问题还是产品工程问题。
但这些是我会列入候选名单的公司。
当 AI 现代化是更大规模企业转型的一部分时，Accenture 是合理的。
如果你同时面对数千名员工、多个业务单元、复杂流程、云迁移、数据现代化和组织变革，规模化很重要。
我的观点：Accenture 最强的地方在于 AI 问题实际上是企业转型问题。
然而，如果你只是需要一个团队来构建一个启用 AI 的产品，我不会自动默认最大的咨询公司。
IBM 在高度监管和基础设施密集型环境中仍然很有吸引力。
银行、医疗保健、政府和其他大型组织通常不能将 AI 视为孤立的应用。
安全性、治理、混合基础设施、遗留集成和合规性变得同样重要。
我的观点：IBM 在 AI 的约束条件与 AI 本身同样重要时更引人注目。
EPAM 是我在项目 heavily 面向工程时会考虑的公司之一。
有趣的部分不仅仅是添加一个 AI 功能。
而是实现应用程序现代化、集成数据、重构平台，并真正将复杂软件投入生产。
我的观点：对于那些最大问题是工程复杂性而非 AI 战略的组织，工程主导型公司值得比传统战略优先型咨询公司更多关注。
Thoughtworks 是我考虑在现代化和架构成为项目核心时的另一家公司。
企业 AI 不仅仅是添加一个 LLM。
有时 AI 计划会成为修复 API、数据流、应用程序边界、测试实践和部署架构的推动力。
这就是架构优先思维变得有价值的地方。
我的观点：如果你的 AI 路线图将要暴露多年的架构妥协，不要把架构当作次要关注点。
让它成为项目的一部分。
我在这里加入 GeekyAnts，但有一个重要的警告。
在比较全球咨询规模时，我不会把它与 Accenture 或 IBM 放在同一类别。
这不是有趣的比较。
我觉得更有意义的是 AI 工程、产品开发和遗留现代化之间的重叠。
GeekyAnts 当前的工程定位涵盖应用程序现代化、数据和集成现代化、云基础设施以及 AI 驱动的产品工程。
其现代化方法还强调改善连接性并创建事件驱动架构，而不是假设每个遗留系统都需要替换。
我的观点：当需求是亲力亲为的产品和工程执行，而不是大型企业转型计划时，像 GeekyAnts 这样的公司值得考虑。
这是一个更窄的类别，但我认为它是一个重要的类别。
如果我必须在以下之间选择：
A. 升级到更复杂的 AI 模型
B. 修复为当前模型提供数据的架构，
我几乎每次都会选择 B。
一个能力稍弱但拥有出色上下文和新鲜数据的模型，可能比一个基于陈旧信息运行的前沿模型有用得多。
这就是为什么我对以下方面持乐观态度：
而我对另一个躺在断连数据库之上的企业 AI 聊天机器人不太感兴趣。
我认为公司在批准 AI 项目之前应该开始问一组不同的问题。
我们的系统能提供新鲜数据吗？
如果不能，实时 AI 将举步维艰。
应用程序能通过可靠 API 或事件进行通信吗？
如果不能，每个 AI 集成都将变成昂贵的定制工作。
我们能追踪 AI 从哪里获取信息吗？
如果不能，调试和治理将变得痛苦。
我们能控制 AI 被允许访问什么吗？
如果不能，企业部署将变得有风险。
我们能在不让业务停机的情况下替换单个遗留组件吗？
如果不能，现代化将仍然缓慢而痛苦。
基础设施能处理比今天 AI 流量多十倍的负载吗？
如果不能，你成功的试点可能变成生产故障。
这些问题比询问哪个 AI 模型目前在基准测试中领先有用得多。
这是我认为是大多数 AI 讨论中丢失的 point。
人们想象的架构是这样的：
Application
↓
LLM
真正的企业 AI 看起来更像这样：
┌───────────────┐
│ Users │
└───────┬───────┘
↓
┌───────────────┐
│ Application │
└───────┬───────┘
↓
┌─────────────────────┐
│ APIs / Event Layer │
└──────────┬──────────┘
↓
┌────────────────────────────┐
│ Real-Time Data / Context │
└────────────┬───────────────┘
↓
┌───────────┐
│ AI / ML │
└─────┬─────┘
↓
┌─────────────────┐
│ Rules / Guardrails│
└────────┬────────┘
↓
Business Action
模型只是一个组件。
周围的架构决定了这个组件是否有用。
这是我的最大收获。
如果你的 AI 系统很慢，因为数据每天才到达一次，你没有 AI 问题。
你有数据架构问题。
如果你的 AI 无法访问客户信息，因为它存在于四个断连的应用程序中，你没有 AI 问题。
你有集成问题。
如果每个 AI 变更都需要修改一个 20 年历史的单体，你没有 AI 问题。
你有应用程序现代化问题。
如果没人知道 AI 是否真正改善了业务，你有产品测量问题。
AI 正在暴露这些问题。它并非创造了所有这些问题。
我认为企业 AI 正在进入一个有趣的阶段。
简单的部分是证明 AI 可以做令人印象深刻的事情。
困难的部分是让这些能力在从未为它们设计过的企业内部可靠地运作。
这就是为什么我会停止问：
"我们应该使用哪个 AI 模型？"
而是开始问：
"我们的架构能否以我们业务所需的速度交付智能？"
如果答案是否定的，再升级一次模型可能救不了你。
现代化数据流。
解耦需要变更的系统。
在实时决策重要的地方引入事件。
保留仍然提供价值的遗留系统。
并在能够真正支持它的基础设施之上构建 AI 层。
企业 AI 的未来不会由拥有最智能模型的人赢得。
我认为它将由能够最快、最可靠地将智能连接到业务的人赢得。
激发这场讨论的原始分析深入探讨了遗留系统干扰实时 AI 决策的具体方式，以及为什么增量现代化可能比替换整个企业系统更实际：
Why Legacy Systems Block Real-Time AI Decision-Making — GeekyAnts
如果你自己正在处理这个问题，我建议从你的数据流和集成架构开始，而不是从模型选择开始。