我见过不少AI项目的高光时刻和至暗时刻Demo汇报时掌声雷动业务方两眼放光老板当场拍板全面推广然后三个月后模型被人悄悄下线或者沦为一个偶尔有人点开看一眼的演示系统。这种案例看多了以后我越发认同一个判断——没有数据底座AI很容易只剩演示效果。今天我想借这个标题把我这几年在AI项目落地过程中看到的、踩过的、想明白的东西完整梳理一遍希望能给正在做AI转型或者正在被AI效果困扰的朋友一些参考。1. 一个成功通过验收的AI项目是怎么一步步烂尾的先讲一个我印象特别深的项目。前几年帮一家连锁零售企业做门店单品需求预测算法上算不上复杂XGBoost加一些时序特征POC阶段用历史订单数据做验证预测误差指标相当漂亮。汇报那天业务负责人很兴奋说这就是他们要的东西于是直接进入全面推广阶段。结果呢上线不到两个月模型的预测结果开始被门店店长集体吐槽业务方开始质疑算法的可靠性最后项目被搁置变成了PPT里的一个案例。复盘的时候发现问题基本都出在数据上而不是模型上。当时POC的数据是从数仓导出来的一份干净的历史快照算法工程师在Notebook里反复清洗、补全、筛选把异常订单、退单、团购单都处理过一遍但这些清洗逻辑只存在于个人脚本里生产环境的数据管道根本没有对应的处理环节。促销活动数据、天气数据、商圈事件这些对销量影响极大的外部变量当时散落在运营的Excel里每次更新靠人工发邮件。训练模型的时候算法同学手工把Excel合并了进去上线后根本没有稳定的接口去拿这些数据。商品主数据管理混乱同一个SKU在ERP、电商平台、门店系统里的编码规则不一样有的用12位数字有的带字母前缀数据管道在关联这些表的时候频繁报错导致每天凌晨的数据同步任务经常跑不完早上8点模型要出预测结果数据却还没就位。其实这三点都不是什么高深的技术难题但它们组合在一起把一个原本效果很好的AI项目活活拖垮了。这让我意识到一个问题很多AI项目的失败根本不是算法选型不对、参数没调好而是模型脚下那层数据地基压根就不存在或者存在但远远不够结实。2. 数据底座不是数据平台拆开看它到底包含什么数据底座这个词这两年被提得很多但很多人的理解还停留在上了Hadoop、建了数仓、买了BI工具这个层面。实际做AI项目的人都知道AI真正需要的数据底座比传统报表体系要复杂得多。2.1 数据底座的四个核心层如果用我的话来说数据底座可以拆成四层每一层解决不同的问题。第一层是采集与接入层。这一层负责把散落在各个业务系统、数据库、日志文件、第三方接口、IoT设备里的数据以稳定可靠的方式汇聚到一个统一的地方。这一层的关键不是技术而是覆盖度——你有没有把该接的数据全接进来。很多AI项目死就死在数据源不全训练模型的时候这个变量没有、那个维度缺失巧妇难为无米之炊。第二层是存储与计算层。这一层是传统大数据平台最熟悉的部分也就是数据仓库或者数据湖。它负责把采集上来的原始数据进行分层加工ODS层存原始数据DWD层做清洗和标准化DWS层做汇总ADS层面向应用。对AI项目来说这一层还需要额外考虑训练集和推理集的存储管理、特征数据的读写效率以及历史数据的版本问题——模型训练需要回溯历史不能今天的数据把昨天的数据覆盖掉。第三层是治理层。这一层包括元数据管理、数据质量规则、数据血缘、主数据管理、数据安全与权限控制。这是最容易被忽视但又最要命的一层。没有元数据管理半年之后没人说得清某张表里的某个字段到底是什么意思没有数据质量监控脏数据流入模型结果出错都找不到源头。第四层是服务层。这一层面向具体的消费方给算法团队提供特征平台给业务团队提供指标平台给应用系统提供数据API。传统数仓的服务对象主要是报表和BI而AI项目需要的服务层必须额外支持离线批量取数和在线实时特征读取两种模式否则训练环境和生产环境的数据口径很容易分裂。2.2 AI项目对数据底座的独特要求传统数据平台服务的核心对象是看报表的人而AI data 底座服务的核心对象是跑模型的系统。这带来几个本质差别模型训练需要历史数据而且是带业务含义、有时间维度的历史数据模型推理需要实时或准实时的当前数据延迟不能太高模型上线后还需要反馈数据回流形成一个闭环。所以我不太建议把数据底座和传统数仓画等号。数仓可以认为是一套面向人类决策的数据体系而AI需要的是一套面向机器决策的数据体系。两者有重叠但AI侧的多了一层特征生命周期和数据反馈闭环的管理。这也是为什么有些公司传统数仓做得不错但AI项目一落地就各种别扭——因为两边对数据的消费方式完全不一样。3. 演示通过不等于上线好用中间隔着三件要命的事很多AI项目在演示阶段效果炸裂一上生产就翻车根子通常不在模型本身而在三个非常具体的数据问题上。3.1 训练与推理的特征一致性这是最常见、也最坑的一个问题。算法工程师在训练模型的时候手里拿的是一份已经清洗好的历史数据特征值是怎么算出来的、用了哪些字段、窗口期是怎么定义的都在代码里。但到了线上推理阶段模型要实时读取特征数据管道是另一批人写的字段名称可能变了、时间窗口可能算的不一样、缺失值的处理方式可能不同。只要有一丁点不一致模型输出的结果就会出现肉眼可见的偏差。我见过一个做客户流失预测的团队模型在离线验证集上AUC能到0.9上线后预测结果却基本等于随机猜。后来一查发现离线特征工程里对最近一次交互时间这个特征做了缺失值填充用全局均值填的但线上推理代码里没有做这个填充缺失的字段直接被置为0。0在特征空间里代表用户刚刚发生过交互和从未交互过的语义完全不同模型直接跑偏。解决这个问题的关键是在底座建设阶段就建立特征一致性校验机制离线特征和在线特征必须来自同一份特征定义训练和推理共用一套特征计算逻辑。这也是为什么现在很多团队开始重视特征平台目的就是把特征的计算、存储、上线统一管理起来。3.2 数据时效性跟不上业务节奏不同类型AI业务对数据时效的要求差异极大。我用一个表格来说明AI应用类型数据时效要求数据底座需要的能力智能推荐、实时风控毫秒级到秒级实时采集、在线特征存储、低延迟查询智能客服、动态定价分钟级准实时同步、微批计算需求预测、经营分析T1天级离线批量管道、定时调度设备预测性维护秒级到分钟级时序数据接入、窗口计算很多项目的毛病在于业务方希望模型达到某种时效效果但数据底座的架构完全支撑不了。比如有的公司要做实时营销推荐但数据管道还是每天凌晨跑一次全量同步数据进数仓的时候已经是昨天的旧数据了推荐引擎拿到的用户行为信息滞后一天推荐效果当然差。问题不在模型在于底座对数据时效的支撑能力没跟上。3.3 数据质量——脏数据的威力被严重低估第三个要命的问题是数据质量。传统的报表体系里一两条脏数据通常不影响大局顶多让指标波动一下人眼还能识别出来。但在机器学习里脏数据会直接进入特征空间变成模型的错误经验。尤其是某些极端值、异常值如果没被清洗掉模型可能会为了拟合这些异常点而扭曲整体决策边界。举一个例子一家做制造业质量预测的工厂用历史质检数据训练良品/不良品分类模型。结果发现模型对某些批次的产品误判率特别高。排查后发现某个月的质检录入系统改版部分旧记录被错误迁移导致约3%的样本标签反了。模型直接用这3%的错误标签学习虽然整体准确率看着没掉太多但在某些品类上的误判率显著上升。数据质量问题还包括数据口径不一致比如销售额在不同系统里一个含税一个不含税、主数据混乱同一客户在不同表里名字写法不同、时间字段时区不统一有的存北京时间有的存UTC等等。这些问题的根源都在数据底座缺少质量监控和血缘追踪。没有质量规则在入口处拦截脏数据就会像污水一样流进模型的饮用水系统。4. 从零搭数据底座的实操路径先通后优分阶段走聊完了问题说说怎么建。我自己的经验是数据底座不能指望一步到位也不存在一个买来即用的成品。它更像一个持续建设的过程但可以分阶段、有节奏地推进。4.1 阶段零先做数据资产盘点任何数据底座项目第一步都不是选技术栈而是盘点。你需要搞清楚公司现在有哪些数据存在哪儿谁在维护质量如何业务价值高不高流程是什么样的我自己惯用一个清单来摸底业务系统数据ERP、CRM、电商平台、门店POS、客服系统的数据表清单日志与埋点数据前端埋点、服务端日志、App行为数据是否在做结构化存储外部数据天气、地理、行业、第三方API哪些已经被使用哪些还没接非结构化数据文档、图片、音视频是否纳入了数据体系主数据情况客户、商品、组织架构的编码统一情况数据质量现状哪些表长期没人维护、哪些字段一堆空值、哪些曾经出过口径争议这个盘点不用搞得很重但一定要涉及业务和数据两侧的人。参与的人越全后面建底座的时候需求遗漏越少。4.2 阶段一把管道打通建分层数仓/湖仓盘完之后优先解决数据能不能稳定、完整地流进来的问题。这一阶段的核心动作是建立数据采集管道和分层存储。ODS层操作数据存储把各业务系统的原始数据全量接入保留原貌别做任何业务逻辑加工这样以后出问题还能回溯源数据。DWD层明细数据层做清洗、去重、标准化、字段统一比如统一日期格式、统一客户ID形成一份干净的明细数据。这一层必须配合数据质量规则在写入时校验关键字段。DWS层汇总数据层面向业务主题做轻度汇总比如订单维度的日汇总、商品维度的销量统计。ADS层应用数据层面向具体应用场景加工AI模型的训练集通常从这一层或者DWD层取数。选型方面体量不大的团队完全没有必要一上来就上重型大数据框架。业务数据量在几百GB以内的用PostgreSQL或者MySQL做数仓、用Airflow或者DolphinScheduler做调度完全够用。体量大一点的可以考虑ClickHouse做分析查询引擎、Iceberg或Hudi做数据湖存储对象存储做底层。核心按需配比把管道跑通比工具酷炫重要得多。4.3 阶段二元数据、数据血缘、质量监控三件套管道通了之后紧接着要做治理。很多团队跳过治理直接进模型开发前期确实省事但半年后必还债。治理层的重点是三件事元数据管理每张表、每个字段的业务含义、负责人、更新频率要记录下来、数据血缘清楚一条数据从哪个源系统来的、经过哪些加工、被哪些下游模型使用、数据质量监控对关键表的关键字段做完整性、准确性、唯一性校验出了问题能自动告警。这三件事做起来都有工具可以选开源的有Apache Atlas、DataHub商业的有各种数据治理平台。但对中小团队来说别一上来就追求工具全家桶先在代码仓库里维护一份字段字典、在调度系统里挂几个质量校验脚本让口径有据可查、问题有迹可循这件事先运转起来比上什么平台都重要。4.4 阶段三面向AI的服务层——特征平台与指标平台等前几个阶段稳定了再考虑建设特征平台。特征平台解决的核心问题是训练和推理共用一套特征逻辑特征可以复用、可以监控、可以回滚。市面上有开源的Feast、阿里的Flink AI Flow等方案也可以自研一个精简版——用元数据表把特征的SQL定义管理起来统一发布给训练和推理两侧使用。指标平台则面向业务把公司统一的指标口径沉淀下来比如销售额怎么定义活跃用户怎么定义。这样不同团队看到同样的数字时说的是一回事AI模型的标签设计和业务目标也能对齐。4.5 小团队怎么轻量起步如果你所在的团队只有三五个人没有专门的数据团队也别慌。轻量版的路径是用Git管理ETL代码用PostgreSQL做主存储用Dagster或Airflow做定时任务用dbt做数据转换和测试再在BI工具里做指标看板在代码仓库里维护字段字典。这套组合加起来成本不高但能把管道、口径、血缘的基本框架搭起来。我见过不少项目用这套轻量组合跑得很好。关键在于流程和契约先立住工具可以后续再升级。5. 建底座过程中最容易踩的坑以及我现在的一些固定习惯最后聊几个我在真实项目里踩过的坑以及踩完之后养成的习惯。这些内容不在任何一本工具书里但对做实际项目的人很有参考价值。5.1 数据血缘缺失出问题找不到源头有次用户反馈某个BI看板的数字不对。数据团队查了两天没找到原因因为原始表的字段在一个月前被上游某位同事改过名字但下游的ETL脚本没有跟着改导致数据写入错位。这是典型的数据血缘缺失问题——链路太长中间任何一环动了下游没人知道。我现在的习惯是所有进入数仓的表必须在元数据系统里登记来源、负责人、更新徽章任何字段变动必须走变更通知流程。这个流程一开始会显得繁琐但一旦链路里的表超过几十张它省下的排查时间远超维护成本。5.2 数据版本管理被忽视模型回滚时数据已经变了做AI项目的人都知道模型要版本管理但很多人忽略了数据也要版本管理。有一次我们上线了一个新模型效果不如预期决定回滚到旧版本。结果一跑发现旧模型的效果也比之前差了——原因在于训练数据的历史快照没有被保留回滚时模型读到的已经是经过新清洗逻辑处理过的数据了分布早就变了。现在我会确保训练集在模型上线时做一个快照存储单独存一份带版本号的数据副本。这样无论后续管道怎么改历史模型随时能用当时的原始数据重新评估和复现调起问题来特别高效。5.3 算法团队和数据团队之间缺乏接口人意识这是个组织问题但直接影响数据底座建设。算法工程师的特点是快速迭代、灵活探索数据工程师的特点是追求稳定、流程规范。两者如果没有一个明确的协作机制很容易互相抱怨——算法嫌数据管道太慢、字段不全数据嫌算法提的需求变来变去、边界不清。我的解决办法是强调数据契约算法团队需要什么表、什么字段、什么更新频率、什么质量约束写清楚交给数据团队数据团队以这份契约为准开发和维护管道。契约变更走评审流程而不是随时口头提需求。这个机制想清楚后两边的协作摩擦能少一半。5.4 先想清楚数据从哪来、到哪去再谈模型优化一个项目能不能成很多时候在动手之前就注定了。如果你准备上AI我建议先回答三个问题核心数据能不能稳定、完整地拿到关键口径有没有人说得清楚数据出了问题有没有办法快速定位和回溯如果三个问题里有任何一个是不知道那就先别急着训练模型老老实实把数据底座补一补。这不是让你不做AI而是让你用更稳的方式做AI。我在实际项目中越来越体会到算法本身的迭代空间其实是有限的真正决定AI项目能不能走远走稳的是脚下那层看不见的数据底座。它不负责产出一个炫酷的Demo但它决定了这个Demo能不能变成每天被真实业务使用的生产力。别让AI只剩演示效果从把数据底座打扎实开始。