1. 项目概述：当数据遇见AI，一场深度对话的价值
最近和一位深耕数据与AI交叉领域多年的老朋友Jerome Pasquero进行了一次长谈，话题就围绕“Data in AI”这个看似宏大却又无比具体的命题展开。这并非一次学术研讨，更像是一位一线实践者的经验复盘。我们聊的不是那些飘在空中的概念，而是实实在在的坑、抉择背后的逻辑，以及那些在标准文档里找不到的“手感”。如果你也正身处数据科学、机器学习工程，或是任何需要将数据转化为智能应用的领域，这次对话的精华或许能帮你少走几步弯路。
“Data in AI”这个标题，拆解开来，核心是探讨数据在整个人工智能系统生命周期中的角色、挑战与最佳实践。它远不止是“把数据喂给模型”那么简单。从原始数据的获取与理解，到预处理与特征工程的匠心，再到模型训练中的数据流管理、评估中的数据洞察，乃至最终产品化后的数据监控与迭代，数据是贯穿始终的血脉。Jerome的视角之所以有价值，在于他经历了从早期研究到大规模工业部署的全过程，他的经验覆盖了算法敏感性与工程鲁棒性之间的那个微妙平衡点。
这次深度探讨，我们将聚焦几个关键层面：首先是如何构建一个以数据为中心的AI开发理念，而不仅仅是模型至上；其次，在数据流水线的各个环节中，有哪些容易被忽视却至关重要的细节；最后，当项目从实验走向生产，数据层面会面临哪些全新的挑战，又该如何应对。无论你是刚开始接触机器学习的数据分析师，还是负责维护复杂AI系统的工程师，都能从中找到共鸣和切实可用的建议。
2. 核心理念：从模型中心化到数据中心化
2.1 范式转变：为什么数据比算法更值得投资？
过去十年，AI的发展很大程度上是“模型中心化”的。大家热衷于讨论最新的Transformer架构、更深的神经网络、更巧妙的优化器。这没错，算法的突破打开了新的可能性。但Jerome尖锐地指出，在绝大多数工业场景中，尤其是当你的模型已经从一个研究原型迈向解决实际业务问题时，瓶颈往往迅速从模型架构转移到了数据质量、规模和处理流程上。
一个经典的误区是：团队花费80%的时间调参和尝试新模型，却只给数据清洗和验证留下20%的精力。结果往往是，一个在精心挑选的干净测试集上表现SOTA的模型，一上线就崩盘，因为真实数据充满了噪声、分布偏移和意料之外的边缘情况。数据中心化的理念，就是要把这个投入比例倒过来，或者至少做到50/50。这意味着，我们需要像对待核心算法一样，设计严谨的数据采集规范、建立自动化的数据质量监控管线、投资于高效的特征存储和服务系统。
背后的逻辑很简单：模型只是一个函数f(x)。它的性能上限，在选定架构后，几乎完全由输入x（即数据）的质量和代表性决定。给一个顶尖的模型喂垃圾数据，它只能输出垃圾。而一个简单的模型，如果有高质量、高相关性的数据，往往能产生惊人的实用效果。因此，投资于数据基础设施、数据质量团队和数据迭代流程，其长期回报率通常远高于持续追逐最新的模型。
2.2 数据质量的多维度定义
谈到数据质量，很多人第一反应是“干净”，没有缺失值和异常值。但这只是最基础的一层。Jerome提出了一个更全面的框架，他将数据质量分解为五个可操作、可测量的维度：
- 完整性：关键字段是否缺失？对于监督学习，标签的覆盖度如何？我们曾有一个用户画像项目，初期30%的用户缺少“年龄”标签，直接训练模型会导致严重偏差。解决方案不是简单删除，而是建立了分层抽样和主动触达的标签补全机制。
- 一致性：同一实体的数据在不同来源或不同时间点是否一致？例如，用户的“注册城市”在业务数据库和日志流水里是否相同？我们通过定义“黄金记录源”并建立数据血缘图谱来解决，确保下游所有消费方都引用同一份权威数据。
- 准确性：数据是否真实反映了现实世界？这最难验证。我们采用多源交叉验证（如将内部交易数据与脱敏的外部征信数据片段进行比对）以及业务规则校验（如“订单金额不能为负”）。
- 时效性：数据的新鲜度是否符合模型预期？一个实时欺诈检测模型，如果使用的用户行为特征延迟了十分钟，价值就大打折扣。我们为每个特征都定义了“有效截止时间”和“更新频率”，并在特征平台上透明展示。
- 相关性：这是业务层面的质量。数据是否真的对预测目标有贡献？我们通过定期的特征重要性分析和AB测试来淘汰陈旧或无效的特征，防止特征膨胀拖累系统性能。
注意：数据质量的维护不是一次性的项目，而是一个持续的过程。必须将其工程化，嵌入到每一次数据生成、流转和消费的环节中，并配备相应的监控告警。
2.3 构建可追溯的数据血缘
当模型效果出现波动时，你能多快定位到是数据链的哪一环出了问题？是原始数据源变了，是ETL脚本有bug，还是特征计算逻辑被误改了？数据血缘就是你的“侦探地图”。它记录了数据从源头到最终消费（包括模型训练）的完整路径，包括所有的转换、计算和依赖关系。
Jerome团队的做法是，强制要求所有数据管道（无论是Airflow DAG、Spark Job还是简单的Python脚本）都必须通过元数据层注册其输入和输出。他们使用开源的OpenLineage这类工具（当然，自研一套轻量级系统也是常见选择）来自动捕获作业执行时的血缘关系。这样一来，任何数据集的“前世今生”都一目了然。
举个例子，某天信用卡交易欺诈模型的AUC突然下降了5%。通过血缘图，我们迅速定位到模型使用的“用户近期交易频率”这个特征。进一步回溯，发现生成该特征的作业在两天前因为一个内存配置错误而部分失败，导致最近三小时的数据没有被正确聚合，进而影响了特征值。没有清晰的血缘，这种排查可能需要跨团队开会、翻看多个日志文件，耗费大半天时间。
3. 数据处理流水线的核心环节
3.1 数据获取与理解的实战要点
项目启动，第一件事不是写模型代码，而是彻底地“理解你的数据”。Jerome强调，这需要数据分析师、领域专家和机器学习工程师的紧密协作。他推荐一个三步法：
第一步：探索性数据分析（EDA）的工业化。不仅仅是画几个分布图。要系统性地检查：
- 分布与偏态：目标变量是否极度不平衡？特征是否符合预期分布（如高斯、长尾）？对于偏态严重的特征，记录下是采用对数变换、分箱还是其他处理方式。
- 缺失模式：缺失是随机的，还是有规律的（如某个渠道来的用户必缺某字段）？这本身可能就是重要信号。我们曾将一个“用户未填写公司信息”的布尔标志，作为一个强有力的特征加入B2B销售预测模型中。
- 异常值检测：使用IQR、Z-score或基于模型的方法（如Isolation Forest）找出异常点。关键是要区分“数据错误”和“业务现实”。一个金额巨大的订单可能是欺诈，也可能是大客户采购，不能一概删除。
第二步：构建数据契约。在团队内部，甚至与数据提供方之间，为关键数据源定义明确的“契约”。包括：字段名、类型、取值范围、是否可空、更新频率、延迟承诺等。这能极大减少后续的歧义和故障。我们使用Protobuf或JSON Schema来形式化这些契约，并在流水线入口进行验证。
第三步：创建“数据说明书”。为每个数据集维护一个活的文档，记录其来源、采样方法、已知问题、常见使用方式和避坑指南。这能加速新成员上手，避免重复踩坑。
3.2 特征工程：从艺术到工程
特征工程曾被称作“黑魔法”或“艺术”。但Jerome认为，在大规模应用中，必须将其工程化、自动化、可复现化。
核心原则：可复现性与一致性。训练时对某个特征做的缩放（如StandardScaler），在线上推理时必须用相同的参数（均值和标准差）进行变换。这要求我们将特征处理逻辑（包括拟合和转换两个阶段）封装成独立的、可序列化的模块，并和模型一起打包部署。我们大量使用Scikit-learn的Pipeline和Transformer API，或者自定义PyTorch/TensorFlow的预处理层来实现这一点。
特征存储的兴起。当你有上百个特征，被多个模型共享时，手动管理就是噩梦。特征存储（如Feast、Tecton）解决了这个问题。它允许你：
- 定义特征：在中央仓库中声明特征的计算逻辑（如“过去7天用户登录次数”）。
- 离线计算与存储：由调度任务批量计算特征值，存入低延迟数据库（如Redis）供线上推理用，同时存入数据湖（如Hive）供离线训练用。
- 保证一致性：确保训练和推理时访问的是通过完全相同逻辑计算出的特征值，避免“训练-服务偏斜”。
Jerome分享了一个案例：他们为推荐系统构建了一个“用户实时兴趣向量”的特征，更新频率是分钟级。如果没有特征存储，在线服务需要自己实时聚合用户最近的行为，计算压力大且逻辑复杂。接入特征存储后，离线作业每分钟计算好所有用户的兴趣向量并推送到在线存储，服务端只需简单查找，延迟从几百毫秒降到个位数，且保证了全局特征定义的一致性。
3.3 数据版本化与模型可复现性
模型版本化大家都有意识，但数据版本化同样关键。你无法复现三个月前那个“效果最好”的模型，除非你知道当时它用的是哪份数据。数据版本化不仅指备份原始数据文件，更重要的是记录下生成训练集所用的所有代码、参数和上游数据版本。
他们的实践是采用“快照+代码”的方式。对于核心数据源，每天或每周定时创建不可变的数据快照（例如，存储在S3上，路径包含日期分区s3://bucket/raw_data/dt=2023-10-27/）。训练脚本运行时，必须明确指定所用数据快照的日期范围或版本标签。同时，将特征工程和样本筛选的代码用Git管理，每次训练任务都会记录对应的Git Commit SHA。
这样，任何模型训练记录都包含了一个三元组：模型代码版本， 特征处理代码版本， 输入数据版本。通过这个三元组，理论上可以完全复现当时的训练环境。我们甚至将此集成到MLflow等模型管理平台中，作为模型元数据的一部分自动记录。
4. 模型开发与评估中的数据考量
4.1 构建有代表性的数据集
数据集划分（训练/验证/测试）是老生常谈，但Jerome指出了几个工业界容易忽略的细节：
时间序列数据的划分。绝对不能随机打乱！必须严格按照时间顺序划分，用过去的数据训练，用未来的数据验证和测试。这能有效检测模型对模式变化的适应性。我们通常采用“滚动窗口”法：例如，用1-6月的数据训练，7月的数据验证，8月的数据测试。然后，将整个窗口向后滑动一个月，重新训练和评估，以观察模型性能的稳定性。
处理数据泄露。最常见的泄露发生在特征中包含了“未来信息”。例如，用“当天的总销售额”来预测“当天某个时间点的销售额”。在特征工程时，必须确保每个样本的特征值仅使用了该样本时间点之前的信息。这需要精心设计特征计算的时间窗口和作业调度时间。
分层抽样与类别平衡。对于分类问题，尤其是多分类或标签不平衡时，确保每个集合中各类别的比例与总体分布大致一致（分层抽样）。对于极度不平衡的数据（如欺诈检测），我们不会在数据层面过度采样（如SMOTE），因为这会扭曲真实分布。更常用的做法是，在训练时使用类别权重（class_weight）来让模型更关注少数类，或者在评估时使用PR曲线、F1-score而非单纯的准确率。
4.2 超越AUC：更贴近业务的评估指标
AUC-ROC是二分类模型的黄金标准，但它也有局限。Jerome强调，评估指标必须与业务目标对齐。
案例：信用卡欺诈检测。AUC很高，但模型可能把很多大额正常交易误判为欺诈（假阳性），导致客户体验极差。这时，我们更关注“在控制假阳性率（例如，低于0.1%）的前提下，召回率（查全率）能达到多少”。我们会绘制精确率-召回率曲线（PR Curve），并在业务能容忍的精确率阈值下，比较召回率。
案例：推荐系统的排序。AUC可能无法很好反映排序质量。我们会引入归一化折损累计增益（NDCG）、平均精度均值（MAP）等指标，更直接地衡量“把用户最可能点击或购买的商品排在前列”的能力。
模型评估的“实战演习”。除了离线指标，在重大模型上线前，我们一定会进行影子模式或A/B测试。影子模式让新模型并行运行，记录其预测结果但不影响线上决策，用于对比新老模型在完全真实流量下的表现差异。A/B测试则是将一部分真实流量分给新模型，直接观察核心业务指标（如点击率、转化率、营收）的变化。这是数据在模型评估中最终极的试金石。
4.3 偏差与公平性检测
数据中的历史偏见会被模型放大，导致不公平的决策。Jerome提到，这在金融、招聘、司法等领域尤为重要。他们会在模型评估中加入偏差检测环节：
- 识别敏感属性：如性别、种族、年龄组等（需在合规前提下，使用脱敏或代理变量）。
- 分组评估：计算模型在不同子群体上的性能指标（如准确率、FPR、FNR）。查看是否存在显著差异。
- 使用公平性指标：如** demographic parity**（不同群体获得正面预测的比例应相似）、equal opportunity（不同群体中正例被正确预测的比例应相似）等。
- 缓解措施：如果发现偏差，可能需要在数据层面进行重采样、在损失函数中加入公平性约束项，或在后处理阶段调整决策阈值。
这个过程不是一次性的，需要持续监控，因为数据分布和用户群体可能随时间变化。
5. 生产环境中的数据挑战与应对
5.1 训练-服务偏斜：头号杀手
这是模型线上效果不如离线的首要原因。Jerome列举了四种常见的偏斜及其应对：
数据偏斜：线上推理时使用的特征数据，与训练时特征的数据分布不一致。
- 原因：特征计算逻辑不一致、线上数据管道延迟或故障、数据源变更。
- 应对：使用特征存储确保一致性；对线上特征数据进行持续监控，对比其与训练数据分布的差异（如计算PSI群体稳定性指标）。
概念偏斜：我们试图预测的目标本身，其定义或统计特性发生了变化。
- 原因：业务规则改变（如“欺诈”的定义变了）、市场环境突变（如疫情对用户行为的影响）。
- 应对：建立模型性能的实时监控仪表盘，一旦发现指标持续下滑，立即触发警报和排查。建立模型重训练的数据和流程。
工程系统偏斜：线上服务环境与训练环境的差异。
- 原因：编程语言/库版本不同、硬件差异（CPU/GPU）、预处理代码未正确打包。
- 应对：使用容器化（Docker）将模型及其依赖完整封装；在部署前进行严格的线下仿真测试。
抽样偏斜：训练数据不能代表全体用户或所有场景。
- 原因：训练数据来自历史日志，但新产品功能吸引了新用户群体。
- 应对：主动收集新群体数据（如通过探索性策略），并定期用最新全量数据刷新训练集。
5.2 数据监控与模型性能衰退
模型不是“部署即结束”的产品。必须建立一套监控体系，像监控服务器CPU一样监控模型和数据。
数据监控层：
- 特征值监控：监控每个特征的基本统计量（均值、标准差、缺失率）的日环比、周环比变化。设置阈值告警。我们常用群体稳定性指数（PSI）来量化特征分布的变化，PSI>0.1通常意味着需要警惕。
- 输入数据质量监控：检查线上推理请求中，特征是否缺失、类型是否正确、是否在合理值域内。
模型监控层：
- 预测结果监控：监控模型预测分数的分布变化。例如，欺诈模型输出的平均欺诈概率突然升高或降低，可能意味着数据或模型出了问题。
- 业务指标关联监控（如果可能）：将模型预测与后续的业务结果（如用户是否真的违约、是否点击了推荐）关联起来，计算线上真实环境的准确率、召回率。这通常有延迟，但价值最大。
- 影子模式对比：持续运行影子模式，对比新旧模型在相同流量下的预测差异。
我们曾遇到一个案例：一个价格预测模型的平均预测值在两周内缓慢但持续地上升了10%。数据监控显示所有特征PSI都正常。最终排查发现，是一个上游数据团队悄悄更改了一个宏观经济指标的计算口径，导致其数值系统性偏高，而这个特征在模型中的权重很大。没有细致的监控，这种缓慢的“漂移”很难被及时发现。
5.3 数据驱动的模型迭代闭环
AI系统的生命力在于迭代。Jerome团队建立了一个高效的迭代闭环：
- 问题检测：通过监控系统或业务反馈发现模型性能下降或新的优化机会。
- 根因分析：利用数据血缘和详细的日志，定位是数据问题、特征问题还是模型架构问题。
- 实验设计：在离线环境设计实验，测试新的特征、模型或数据处理方法。使用清晰的实验框架（如MLflow Projects）记录每次尝试的参数和结果。
- 离线验证：在历史的、未参与训练的测试集和更近期的“时间测试集”上验证改进效果。
- 影子部署与A/B测试：通过影子模式验证线上稳定性，然后通过A/B测试验证业务价值。
- 全量发布与监控：全量发布新模型，并加强监控，完成闭环。
这个循环的核心燃料就是高质量的数据和严谨的数据日志。每一次线上推理的请求和结果（在符合隐私政策的前提下）都应被安全地日志记录，这些日志经过脱敏和处理后，会成为下一轮训练数据的重要来源，帮助模型学习到最新的用户行为模式。
6. 工具、文化与未来展望
6.1 技术栈选型心得
Jerome并不迷信任何单一工具，他强调“合适的才是最好的”。他们的技术栈是混合型的：
- 数据存储与处理：大规模原始数据用云对象存储（如S3）和数据湖格式（Delta Lake/Iceberg）；交互式查询用Trino/Presto；大规模ETL用Spark；流处理用Flink。
- 特征平台：早期自研，后期切换到Feast，看中其开源、云原生和相对简单的架构。对于超大规模、实时性要求极高的场景，他们会评估Tecton。
- 实验跟踪与模型管理：MLflow是事实上的标准，足够轻量且功能全面。它完美地记录了数据、代码、参数和模型的关联关系。
- 工作流编排：Apache Airflow用于管理复杂的、有依赖关系的批处理任务流（如数据获取、特征计算、模型训练流水线）。
- 在线服务：模型使用TorchServe或TensorFlow Serving封装成API，部署在Kubernetes上，便于扩缩容和版本管理。
他的建议是，从小而精开始。初期不必追求大而全的平台，先用MLflow管好实验，用Git管好代码，用S3管好数据版本。当协作效率成为瓶颈时，再逐步引入特征存储等更复杂的系统。
6.2 培养数据素养与跨团队协作
技术之外，Jerome认为最大的挑战是文化和协作。数据科学家、机器学习工程师、数据工程师和业务分析师常常各自为战。打破壁垒的关键是：
- 建立共同语言：举办内部讲座，让数据科学家给工程师讲模型原理，让工程师给科学家讲数据管道和系统约束。
- 共担责任：明确“模型效果”是所有人的共同目标。数据工程师要保证数据管道稳定，数据科学家要对线上效果负责，而不是只交出一个离线指标漂亮的模型就完事。
- 工具民主化：建设内部平台，让业务分析师也能通过低代码界面访问特征、发起简单的模型训练实验，将数据能力赋能给更广的团队。
6.3 前瞻：自动化、合成数据与隐私计算
最后，我们聊到了一些前沿趋势。Jerome对AutoML和自动化特征工程持务实态度，认为它们在解决大量重复性、模式固定的问题时能极大提升效率，但在需要深度业务理解和创新的场景下，人类专家的洞察仍不可替代。他更看好的是Data-Centric AI工具的发展，即能自动发现数据问题、提出修复建议、并优化数据质量的AI工具。
对于数据稀缺或隐私敏感的领域，合成数据和隐私计算（如联邦学习、差分隐私）越来越重要。他们正在探索使用生成对抗网络（GANs）来生成高质量的合成用户行为数据，用于模型前期的算法验证和开发，从而减少对真实敏感数据的依赖。而在与合作伙伴进行联合建模时，联邦学习框架能让他们在不交换原始数据的前提下，共同训练一个更强大的模型。
和Jerome的这次对话，让我再次深刻体会到，AI的成功落地，是一场关于数据的“长征”。它需要技术的严谨、工程的扎实，更需要跨团队的协作和对业务价值的持续聚焦。把数据放在AI系统的中心位置去思考、去设计、去投资，这或许是当下从AI项目中获得可靠回报的最稳健路径。
