流水线税正在阻碍企业级AI智能体的规模化落地

企业AI架构正面临一场深层危机:依赖数据管道、RAG层、向量数据库和编排框架的传统方式,在智能体规模化生产中频频失效。数据每经一次流转,治理策略就面临一次失效风险,由此形成隐性的"流水线税"——导致AI项目延期、幻觉频发、审计困难。解决之道在于重构架构逻辑:不再搬移数据,而是将AI与治理能力直接内嵌于数据层,实现实时、主权化的统一管控。

三个月前,我与企业技术领导者的对话还围绕着该对哪个模型进行微调。而今天,话题已经转向了一个更根本的问题:为什么向模型输送数据的流水线,才是导致他们AI项目延期六个月的真正原因。更重要的是,为什么不断增加流水线和云计算资源,并不能让AI在生产环境中转化为可量化的业务价值。

这绝非偶然。2025年的企业AI架构——向量数据库、RAG层、编排框架,以及从业务系统中抽取数据的摄取流水线——建立在一个经不起生产环境检验的假设之上:企业能够以足够快的速度持续移动数据,使AI智能体在实时场景下保持有效,同时在每次数据迁移之后再于下游重建数据治理体系。

这一假设源于AI出现之前的系统蓝图,就好比只是增加马匹数量,而非真正提升马力。在生产环境中运行的AI需要的是制动马力级别的基础设施——将数据与AI在实时状态下整合于一套主权基础设施之中,而非分散部署在不同位置。

下一代成功的企业架构,其起点和终点都在这套系统的核心引擎:数据层。

这是一个全新的引擎世界,所有组件在实时状态下协同运转。这不是将一堆碎片化的零件靠良好意愿拼凑在一起,仅仅优化到减少阻力和摩擦的程度——而是意味着为AI的成功构建一套全新的、主权式的系统性设计。

旧有的假设已经无法成立。而数据层,正是它最先崩溃的地方。

看看大多数大型组织实际运行的架构:事务性系统向流水线输送数据,流水线再输送至数据仓库、数据湖仓、特征存储和模型。每一次跳转都是一次数据转译,而每一次转译都意味着治理策略需要重新应用,数据血缘变得模糊,在某个系统中定义的数据脱敏规则可能悄无声息地无法传播到下一个系统。

当数据抵达AI智能体时,它可能已经被复制了四次,并经历了三套治理机制——而这三套机制彼此之间并不完全一致。一旦监管机构提出一个简单的问题——"你能告诉我这位客户的数据去了哪里、谁动过它吗?"——给出答案往往需要六周时间和一个外部咨询项目的介入。

这就是流水线税。它不会作为任何预算中的一个独立条目出现,但它会以审计发现、AI幻觉、停滞的迁移项目等形式显现出来。这也解释了为什么95%的企业表示希望以自有的主权AI和数据平台方式运营,而实际上只有13%的企业报告真正实现了这一目标。上述数据来自EDB近期的客户调研,而更宏观的规律在整个市场中清晰可见:Gartner已将生成式AI项目的放弃率与数据质量低下、风险管控不足、成本持续攀升以及业务价值不明确相挂钩。麦肯锡2025年AI现状调查也发现,AI采用率在持续扩大,但大多数组织尚未将这项技术扩展为企业级的整体影响力。

市场已经开始意识到这一问题。企业在2025年大力建设的RAG基础设施正在遭遇退潮——VB Pulse发现,那些"在2025年大规模铺开RAG"的组织,如今都撞上了同一个失败节点:为文档检索而构建的架构,在智能体规模下无法稳定运行。单一方法的向量相似性匹配,已无法满足生产环境中需要跨系统保证准确性、访问控制和上下文理解的智能体工作负载。

向量数据库的市场格局正因此发生改变。问题不在于检索本身将消失,而在于简单的RAG到向量数据库的流水线,正在为一个全新的AI时代重新构建。超大规模云厂商开始围绕智能体而非流水线重构其数据技术栈。即便是数据湖仓领域的老牌厂商也在发表研究报告,论证当查询横跨数据库和文档时,仅仅使用更强大的模型并不能解决问题——真正的解法在于架构本身。

然而,大多数相关讨论中缺失的,恰恰是下一步的行动方向。如果流水线是问题所在,那么什么可以取而代之?

目前正在形成的架构答案其实清晰明了:停止移动数据,将智能体和AI带到数据所在之处。数据治理应当从设计之初就内嵌于数据层本身,而非事后再拼接到每一个下游系统上。

将治理视为架构本身的属性。可以类比人体:各个器官执行不同的功能,但它们相互依存,由同一套系统全天候管控。企业AI需要同样的原则——不同系统和智能体可以服务于不同目的,但必须在同一套治理规则、策略和主权控制下运行。

实现这一目标所需的各项要素已不再停留于设想阶段。Postgres(R)——大量企业运营数据的原生存储环境——可作为治理控制平面,在引擎层面原生支持行级安全、列级脱敏和数据血缘追踪。Apache Iceberg已赢得开放表格格式之争。模型上下文协议(MCP)为AI智能体提供了一种标准化、受治理管控的方式,能够直接访问运营数据,无需为每个应用单独开发定制集成。

这些都不是2027年的路线图议题,而是正在发生的采购决策。

同样的逻辑也适用于那些拖累一切的现代化积压工作。长期以来,数据迁移一直被当作项目来对待:确定范围、配置人员、熬过痛苦、最终延期18个月交付。

迁移之所以依然痛苦,原因在于其工作本身——发现模式依赖关系、转译嵌入的业务逻辑、验证功能等价性——恰恰是需要高度上下文理解的、重复性的推理工作,而这正是由多个AI智能体协同完成的任务现如今真正擅长的领域。

今年备受关注的COBOL代码转译演示,只是一场更大变革的先兆:数据迁移正在从一次性工程项目,演变为持续自动运行的能力。这将改变其单位经济模型,也将改变战略层面的核心问题。有趣的问题不再是"这次Oracle迁移要花多长时间?",而是"我们能以多快的速度演进整个平台战略?"

在下一个十年的企业基础设施竞争中胜出的厂商,不会是拥有最快查询引擎或最流畅Notebook体验的那些。而会是那些认识到数据移动正在破坏企业AI的厂商。

流水线税已经征收太久了。真正有价值的工作现在从数据层开始——当企业停止缴纳这笔税时,它才真正开始。

流水线模式在智能体规模下已经崩溃。它源于良好的初衷,但在一个正迈向每日10亿个智能体执行2170亿条指令的世界里,它在架构上已然是中世纪的产物。智能体时代,将在数据层决出胜负。

Q&A

Q1:什么是"流水线税"?它对企业AI有什么影响?

A:流水线税指的是企业在数据从源系统经过多个流水线、数据仓库、特征存储等环节流转至AI模型的过程中,所积累的隐性成本和风险。每一次数据跳转都会造成治理策略失效、数据血缘模糊等问题,最终导致AI幻觉、审计困难、项目延期等后果。它不会出现在预算清单中,却是导致95%的企业无法真正实现主权AI平台的核心原因之一。

Q2:RAG架构在企业AI中为什么会失败?

A:RAG架构最初是为文档检索场景而设计的,在单一任务下表现尚可。但当企业AI进入智能体规模阶段,需要跨系统保证准确性、访问控制和上下文理解时,简单的RAG到向量数据库的流水线就无法支撑。单一方法的向量相似性匹配精度不足,架构本身也缺乏对智能体工作负载所需治理能力的原生支持,因此大量企业正在经历RAG基础设施的失败退场。

Q3:企业应该如何解决数据流水线带来的AI架构问题?

A:核心思路是停止移动数据,而是将AI智能体带到数据所在之处,并将治理机制内嵌于数据层本身。具体而言,可以利用Postgres作为治理控制平面,结合Apache Iceberg的开放表格格式和模型上下文协议(MCP),让智能体以标准化、受治理的方式直接访问运营数据,避免每次数据迁移都需要重新应用治理策略的问题。

来源:CIO DIVE

0赞

好文章,需要你的鼓励

2026

05/18

21:43

分享

点赞

邮件订阅