MIT报告：九成AI试点无效，警惕数据引力陷阱

过去几年，大型企业斥资构建人工智能基础设施与应用，董事会批准计划，财务部门完成论证，采购团队敲定算力资源。然而，一个关键问题常被忽视：如何管理底层数据？

这并非引发头条的灾难性故障，而是一种静默的累积性拖累，表现为非预期的人力激增与项目延期。在与多位基础设施负责人交流后，“数据引力”（Data Gravity）成为高频词汇。

麻省理工学院 NANDA 倡议发布的2025年报告显示，95%的企业生成式AI试点项目对损益表几无 measurable 影响。报告指出，症结在于企业整合AI的方式存在差距，而非模型质量本身。这一数据警示企业重构AI商业论证：成功的试点并不意味着组织能在完整数据资产上复现同等效果。

多数企业AI架构假设数据可迁移至新平台，认为集中数据即可让上层智能层顺畅运行。这一假设在企业规模下往往失效。

企业数据具有“引力”。法规限定特定记录的存储位置，主权规则要求部分数据留存于特定司法管辖区，即便当地计算成本更高。业务部门花费数年建立的数据治理体系，使其不愿也难以将数据移交中央存储库。强行分离数据与应用，可能导致高昂的系统失效成本。

此类问题常在概念验证（PoC）阶段被掩盖。PoC通常基于少量预清洗数据运行，当项目转向处理未经整理的庞杂数据时，真实成本才会显现。“数据引力”意味着数据集越大，移动成本越高。除传输费用外，延迟、带宽、安全控制及运营投入均会在模型输出前推高账单。

相关成本很少以单一项目形式出现，而是转化为对已有团队的数十项微小需求：构建和维护从非设计系统中抽取数据的管道；在源系统变更时核对副本与原始数据；在各存储位置应用一致的治理措施；以及追踪开发、测试和训练产生的额外数据集。

单独看，这些任务尚可控；但叠加后，它们成为项目的沉重税负，且随规模扩大而加剧。

这种税负的危险性在于其滞后性。它通常在平台采购和团队组建后的12至24个月显现，此时初步成功指标已向上汇报，合同签署、人员到位且方向公开承诺。此时解构“先中心化”架构的成本，远高于初始设计时规避数据引力。

许多AI项目停滞被归因为“数据未准备好”，这一诊断准确但不完整。深层问题在于，组织试图用存储策略解决上下文问题。

模型需要的不是原始数据堆砌，而是上下文：即查找正确记录、交叉引用政策、尊重访问规则并使用最新信息的能力。这依赖于企业级上下文层——一种在不强制源系统移交数据的前提下，跨系统、跨地点发现、连接和检索信息的受治理机制。

AI推理所需的记录、元数据和向量并非同一概念。记录受法规、主权及应用约束；而元数据和向量可帮助AI查找和推理，无需继承源数据的所有限制。将建设目标从“数据合并”转向“上下文可用”，可避免两年后因架构缺陷重建系统。

在签署重大AI基础设施投资前，组织应明确以下问题：哪些数据集受法规或合同限制不可移动？谁拥有各数据集的治理权，副本存在时权责如何界定？源系统演变时，副本如何保持同步？智能能否下沉至数据所在地，还是架构强制集中化？这些问题虽不直接决定供应商选择，但能塑造候选名单。

正确的架构与选型能以更低成本更快实现AI自动化。应将数据架构视为AI商业论证的核心要素，而非算力交易后的补救细节。

行业习惯以令牌数、吞吐量和GPU利用率衡量AI投资回报率。这些指标仅反映计算效率，却忽略了上游约束：喂给模型的数据是否可信、受控且最新，同时不造成人员负担。

令牌长度和GPU效率揭示了运行成本，却无法保证决策所需的上下文质量。上下文的准确性取决于底层数据是否与业务流程正确连接。从数据中提炼上下文，决定了智能体行动的精准度，也定义了企业是走向原生AI组织，还是背道而驰。

算力是易于预算的项目，而数据引力是常被滞后发现的支出项。最大化AI收益的企业，将是那些设计数据架构以服务智能体上下文需求，而非强行移动或集中分布式数据的公司。