8.0
热点
AI SCORE
编程提效2026-08-18 13:58
好AI用不出好效果？先检查你的数据基础设施
dev.to · AI#AI架构#数据基础设施#企业AI
Editor brief · 编辑速览
多数企业AI落地瓶颈不是模型选择，而是数据无法在需要时实时触达——传统企业架构假设数据可以隔夜处理，但实时AI需要毫秒级数据访问，这不是换平台能解决的。
关于企业 AI，我有一个不太主流的观点：
大多数公司不需要更好的 AI 模型。它们需要的是围绕已有模型搭建的更好的基础设施。
业界有一种倾向，把 AI 落地当作一个模型选型问题来对待。
应该用 GPT？Claude？还是开源模型？RAG？Agent？微调？
这些问题固然重要，但往往问得过早了。
如果 AI 系统在需要时无法访问当前的客户数据、交易信息、库存数据、运营事件或业务规则，那模型并没有多少空间来展现它的智能。
我越来越确信，遗留架构是实时 AI 最大的隐性约束之一。
而且，我不认为答案是"用新平台替换一切"。
那通常只是一种昂贵的回避真正架构问题的方式。
传统企业软件的构建基于一个截然不同的假设。
数据可以隔夜处理。
报表可以每隔几小时送达一次。
系统之间可以交换文件。
员工可以手动在应用之间搬运信息。
这种模式之所以可行，是因为业务决策并不总是需要在毫秒级别内完成。
AI 改变了这个等式。
想象一个 AI 欺诈检测系统正在评估一笔交易。
模型几乎可以即时识别可疑行为。但如果交易历史、客户信息、设备数据和行为信号分散在互不连接的系统里，而这些系统只是定期更新数据，那么 AI 实际上是在用昨天的信息做实时决策。
这不是 AI 问题。
这是架构问题。
同样的模式出现在客户服务、电商推荐、库存预测、保险核保、理赔处理和运营自动化等领域。
实时 AI 需要实时获取决策背后的上下文。
大型组织很少有一个干净的数据源。
客户数据可能存在于 CRM 中。
财务信息可能躺在 ERP 里。
交易记录可能位于核心银行平台。
运营数据可能散布在数据库、电子表格、SaaS 应用和各种内部工具中。
"我们把 AI 连接到所有这些系统吧。"
现实从这里开始变得复杂。
AI 未必是在推理上吃力。它是在为组装所需上下文而吃力。
这可能是最大的架构错配。
遗留应用在信息被定期处理时通常运行得很好。
但当一个 AI Agent 响应某个事件时，它不需要一个上次同步时间是三小时前的数据库。
它想要的是当前状态。
欺诈模型想要当前这笔交易。
推荐引擎想要客户当前的行为。
库存系统想要当前的库存仓位。
AI 客服 Agent 想要最新的客户交互记录。
数据是陈旧的，决策就是陈旧的，无论模型有多强大。
企业宣布一个 AI 计划时，往往预设最难的部分是构建 AI 本身。
在许多企业环境中，真正的难点是把 AI 与其他所有东西连接起来。
遗留应用的 API 可能非常有限。
有些系统需要定制中间件。
还有一些通过老旧的集成机制暴露数据。
有些关键应用可能在过去几十年里被深度定制过。
突然之间，"AI 项目"变成了一个数据集成和现代化项目。
这就是我认为应该在选型之前讨论架构的原因。
AI 开发需要迭代。
换一个方法试试。
引入一个新模型。
添加一个数据源。
改变决策逻辑。
当每次变更都需要修改一个紧耦合的遗留应用时，这些都会变得很困难。
结果是可以预见的：团队行动变慢、成本上升、实验变成了一件有风险的事。
AI 原生系统需要不同层次的灵活性。
技术债不再只是工程上的烦恼。
它可以直接决定一个组织能以多快的速度采纳 AI。
每一个未文档化的依赖、脆弱的集成、过时的接口和硬编码的业务规则，都会增加将新智能连接到现有工作流的成本。
最终，组织会陷入一种奇怪的状态：
它在 AI 上投入了大量资金，却无法将其投入运营，因为周围的软件跟不上。
这是 AI 对话中被忽视的部分。
一家银行不应该因为想要 AI 欺诈检测能力就替换掉核心银行系统。
一家制造商不应该因为想要预测性维护就把运营软件扔掉。
一家医疗机构不应该在引入 AI 到工作流之前重建每一个系统。
这在财务和运营上都不现实。
相反，我会对选择性现代化采取更加激进的方法。
保留那些仍然在做核心工作的系统。
现代化它们周围的接口。
创建可靠的数据访问层。
在真正需要实时行为的地方引入事件驱动集成。
通过 API 暴露重要的业务能力。
将合适的工作负载迁移到云原生基础设施。
然后在这个基础上叠加 AI。
目标不是让一切变新。
目标是让现有企业系统能被现代软件所使用。
在我看来，一个具备 AI 就绪能力的组织需要几项要素协同工作：
AI 系统需要有治理的、访问决策所需信息的权限。
重要事件应该可以被获取，而不是完全依赖预定的批量传输。
这些成为了遗留应用与更新 AI 系统之间的连接组织。
如果 AI 系统做了一个错误的决策，团队需要理解是什么数据、什么服务和什么流程导致了它。
并非每个 AI 决策都应该自动成为自动化业务行为。高impact工作流需要适当的审批和升级机制。
这比起谈自主 Agent 来说要无趣得多。
但它远比后者重要。
我不认为有单一的"最佳 AI 公司"适合企业现代化。不同组织面临截然不同的约束。
但如果我要评估这个特定问题的工程合作伙伴，有几个名字我会列入候选清单。
EPAM 的价值在于问题在技术层面非常深入且涉及复杂的企业环境。
其 2026 年与 Anthropic 的合作明确聚焦于将 AI 应用到遗留运营、工作流自动化、大规模数据和企业转型等领域。
我的看法：EPAM 更适合"我们如何真正重新工程化这个复杂的企业环境？"这类挑战，而不是简单地问"给我们一个 AI 战略。"
在企业规模层面，Accenture 难以被忽视。
其 2026 年与微软围绕前沿部署工程（forward-deployed engineering）开展的工作，明确聚焦于帮助组织在整个企业范围内实现 AI 的运营化。
我的看法：如果你的组织是一个大型跨国企业、多个业务单元、转型以年而非月来衡量，那么 Accenture 的规模是一个显著优势。
但我不会为每一个 AI 现代化项目都自动选择最大的咨询公司。
当架构、工程实践和长期可维护性与 AI 实施本身同等重要时，Thoughtworks 值得被纳入讨论。
我的看法：当我关心的问题不再是"我们能多快地部署一个 AI 功能？"而是"围绕 AI 我们应该如何重新设计工程系统？"时，我会考虑 Thoughtworks。
这个区别很重要。
IBM 在 AI 现代化与混合云、治理、现有企业基础设施以及高度受监管行业的交叉领域仍然举足轻重。
我的看法：当现代化无法与治理、安全、合规和现有企业技术投资分开时，IBM 变得特别有意思。
GeekyAnts 是我会在更广泛的 AI 工程对话中纳入的另一个名字，尤其对于那些关注遗留现代化、AI 集成和产品工程交汇处的组织。
它目前的定位横跨 AI 系统、产品工程和企业现代化，而不是将 AI 视为一个孤立的层面。
我的看法：在比较全球转型规模时，我不会把 GeekyAnts 与 Accenture 放在同一类别。这不是重点。
更有意思的比较是：一支团队能否真正将现代化、产品工程和 AI 实施连接起来，而不会把合作项目变成一个庞大的转型计划。
对于初创公司、成长期公司和希望获得更 hands-on 工程参与方式的组织，这是一个值得考虑的类别。
我认为企业目前在 AI 能力上投入过多，而在 AI 基础设施上投入不足。
再换一个模型修复不了互不连接的数据库。
再好的一句 prompt 修复不了过时的客户记录。
一个自主 Agent 不会为 一个 20 年的遗留应用凭空创造出一个 API。
把 LLM 扔到一个破碎的工作流上，并不会让工作流变得智能。
它只是让破碎的工作流变得更复杂。
从 AI 中获得最大价值的组织，不一定是拥有最先进模型的组织。
我认为将是那些能以最小摩擦连接数据→智能→业务行动的组织。
如果我今天要给一家企业提建议，我会用这一条原则：
"我们如何替换遗留系统？"
"哪些业务决策在 AI 能获取实时信息的情况下会变得大幅改善？"
找出那些系统。
找出集成瓶颈。
找出延迟敏感的地方。
找出哪些地方人类仍然需要批准决策。
然后首先现代化那些路径。
这比因为 AI 变热门了就去重建整个企业要现实得多。
如果大多数问题的答案是"否"，我不会从另一个 AI 试点开始。
我会从架构开始。
因为在某个时刻，企业 AI 不再是 AI 问题。
它变成了一个软件工程问题。
说实话，我认为这是一件好事。
它意味着更好的 AI 的路径不一定是再换一个模型。
有时候就是终于修复我们过去十年一直在回避的那些系统。