AI 数据准备：为什么它决定项目成败
模型的表现上限，在数据输入的那一刻就已经确定。算法可以换、参数可以调，但训练数据里没有的信息，模型学不出来；训练数据里错误的规律，模型会忠实地学会。
AI 数据准备，是指为机器学习与大模型应用系统化完成数据接入、清洗、口径对齐、特征构造与流程固化的全过程，目标是把分散、原始、含噪的多源数据，转化为可复现、可追溯、可持续供给的训练与推理数据集。它不是建模的前置杂活，而是决定模型上限的那一段工作。
实际项目里的卡点通常不在算法。最常见的四类是：口径不统一导致历史数据不可比、处理逻辑散在多个脚本里没人说得清、换一批数据就要重做一遍、结果无法向审计或业务方解释来源。这四条中的任何一条，都足以让一个模型表现不错的项目上不了线。
一个反直觉但常见的现象：把数据口径理顺带来的效果改善，经常大于换一个更强的模型。前者是几周的梳理，后者是几天的调参，但收益的差别通常是反过来的。
关键事实表
| 覆盖环节 | 数据接入、清洗与转换、口径对齐、特征构造、流程固化与重跑 |
|---|---|
| 实现方式 | 可视化工作流，每步对应一个节点，中间结果可单独查看 |
| 数据源接入 | 300+ 连接器，涵盖主流数据库、文件、接口与业务系统 |
| 脚本兼容 | 已有 Python 与 R 代码可通过脚本节点嵌入，不必推翻重写 |
| 可重跑性 | 流程保存后换数据重跑，处理逻辑与数据本身分离 |
| 过程记录 | 工作流即处理过程的记录，可向评审与审计展示每一步的依据 |
| 部署形态 | 支持完全本地离线部署，可运行于无外网连接的内网环境 |
| 已适配操作系统 | Windows、麒麟 V10 / V11、统信 UOS（均为 x86-64 版本） |
| 已适配处理器 | 海光 C86（x86-64），已完成测试并有实际部署 |
| ARM 架构 | 暂不支持，鲲鹏与飞腾在规划中，立项前请先确认服务器架构 |
※ 所列适配环境均为已完成测试并有实际交付的组合。涉及具体模型、具体业务系统的对接能力，需在评估后逐项确认，我们不在未验证的场景上做承诺。
AI 数据准备：做到什么程度算就绪
「数据准备好了吗」这个问题通常得不到明确回答。下面七条可以直接拿去逐项核对，全部通过再进入建模环节，能省掉大量返工。
- 口径统一：同一指标在所有来源含义一致 销售额是否含税、订单是否含取消单、机构编码在两个系统里指不指同一家。这类差异不解决，后面所有分析都建在流沙上。历史上做过口径调整的，还要确认调整前后的数据是否可比。
- 时间对齐：每个特征在预测时点都取得到 把每个字段拿出来问一句「做预测的那一刻，这个值取得到吗」。取不到的一律去掉。这条防的是数据泄漏 – 模型在测试集上准确率高得反常，上线后完全不行，多半是这里出了问题。
- 缺失有明确策略，而不是随手删或填零 先分清缺失的原因：是没采集到、不适用、还是本身就是零。三种情况处理方式完全不同。填零最省事也最容易引入偏差，尤其在金额与计数类字段上。
- 标签定义明确且可复现 「流失客户」「异常交易」「优质订单」这类标签，定义要写下来并能用规则重新生成。靠人工标注的，要确认不同标注人的判断是否一致，否则模型学的是标注人的分歧。
- 训练与验证按时间切分，不是随机切 预测类任务如果随机划分数据集，等于让模型看到了未来的数据，评估结果会虚高。正确做法是用早期数据训练、晚期数据验证，模拟真实的预测场景。
- 算过朴素基线 用最简单的规则（上期值、同期值、多数类）先算一遍误差，这是模型必须跑赢的线。这一步花不了多久，却能避免整个项目做完才发现不如不做。
- 整条流程可以换数据重跑 下一批数据来了，是执行一遍流程就行，还是要有人重新操作一轮。这一条决定了项目是交付了一次结果，还是交付了一个能持续用的能力。
七条里前五条属于数据本身，第六条属于评估方法，第七条属于工程化。多数项目在第一、二、七条上出问题，而这三条恰好都可以在动手建模之前就确认。
一条工作流覆盖完整路径，每个阶段的中间结果都能单独查看。
接入与汇聚
连接多个业务系统、数据库与文件，统一读入工作流，建立单一入口。文件类数据可用文件夹模式批量读取。
清洗与口径对齐
去重、缺失处理、字段标准化、跨来源口径统一。这一段通常最耗时，也最影响最终结果。
特征构造与检查
按建模需要构造衍生字段，同时核对时间对齐与泄漏问题。可用统计节点先看分布再决定处理方式。
固化与重跑
整条流程保存为工作流，下一期换数据重跑即可，也可交给服务器端按期自动执行。
AI 数据准备：脚本方式与工作流方式的差别
两种方式都能把数据处理出来。差别不在能不能做，在做完之后这份工作还剩下什么。
| 对比维度 | 散装脚本方式 | 可视化工作流方式 |
|---|---|---|
| 处理逻辑的位置 | 分散在多个文件与笔记本里 | 集中在一张可看全貌的流程图上 |
| 排查问题 | 逐段加日志重跑定位 | 每个节点的中间结果可单独查看 |
| 换数据重跑 | 常需人工调整与确认 | 执行同一条流程即可 |
| 交接 | 依赖原作者讲解 | 交出的是一张能读懂的流程图 |
| 向业务方解释 | 代码难以在会上讲清楚 | 可顺着流程逐步讲，当场指出要改哪步 |
| 向审计说明来源 | 需另写文档，易与实际逻辑分叉 | 流程本身即过程记录，不会与实际运行分叉 |
| 代码复用 | 已有 Python 与 R 脚本可通过脚本节点嵌入工作流，两种方式并非互斥 | |
※ 本表比较的是工程化与协作特性，不是处理能力优劣。一次性的探索分析、或只有一两个人使用且不需要对外解释的场景，直接写脚本通常更快。
数据准备最大的损耗常发生在交接环节:业务方说不清口径、工程师不了解业务含义、分析师拿到数据才发现字段对不上。把三方放在同一份可读的流程上，问题能在当场解决。
这样组织之后的实际变化
- 口径分歧在流程评审时暴露，而不是上线后
- 业务规则的修改直接落在对应节点上，可追溯
- 人员变动时交接的是流程图，不是口头经验
- 下一个类似项目可以基于现有流程改，不必从零搭
- 审计问询时能逐步说明数据从哪来、经过什么处理
不同行业，同一层数据底座
下面四类的共同点是：数据来源分散、口径需要统一、结果要能对外说明。
