做大数据建模的同行，几乎都会走到同一个坎上：单表建模玩到后期，模型效果就是上不去。我在一个供应链需求预测项目里，第一次被“多源数据融合”狠狠教育了一课——数据建模的核心难点，从来不在算法，而在怎么把分散在多个系统的数据，在统一口径下喂给模型。当时我天真地以为，把ERP、物流、天气、主数据表都塞进同一个宽表就算融合，结果模型上线后，预测精度甚至比只用ERP数据的基准还差。后来才慢慢明白，多源数据融合不是“数据量堆砌”，它是一套从实体识别、主键映射、时间粒度对齐到冲突消解的完整工程技术。这篇文章，就把这些逐步拆开讲清楚，也把我踩过的坑一并放出来。
1. 一场被“数据孤岛”拖垮的建模实验：问题出在哪
1.1 模型的“观测死角”比参数更致命
拿一个最常见的场景说事。假设要做一个用户留存模型，手里只有订单库，目标变量是“用户在N天后有没有再次下单”。表面上看字段很干净：订单时间、金额、品类、支付渠道。但模型实际上只能回答一个问题：买过东西的人，哪些更可能再来买。而那些“逛了一圈什么都没买”“加购了没付款”“在搜索页停留很久最后离开”的用户，在订单库里完全不存在。于是模型把“没看过所以没买”和“看过没买然后流失”这两类行为本质完全不同的人，统统归成一类，它的决策边界自然是一团浆糊。
更麻烦的是负样本缺失。订单库只能包含已经成交的用户，未成交但有活跃行为的用户根本不会出现在表里，模型永远学不到“高活跃度但未转化”这种关键模式。你换更强的模型、调更多的超参数、做更仔细的特征工程，都填不上这个洞。这就是典型的观测死角：单一数据源只覆盖了业务链的一段，而数据建模需要的是整个链路的视图。
多源数据融合的真正价值，就是补全这些观测死角。数据建模本质上是让模型去学习 P(y|x)，x 的覆盖度决定了模型表现的上限。把浏览、搜索、加购行为数据并进来以后，才能构造出“看了三次商品详情页但没下单，之后第5天回来买了”这类跨域组合特征。一个很粗糙但直观的类比：你想搞清楚一个路口为什么会堵，只看红绿灯状态是不够的，必须把摄像头画面、车道渠化方案、高峰时段流量数据叠在一起，才能还原事情全貌。大数据建模里的融合，做的就是这件事。
1.2 融合不是一个加数据的动作，而是一套建模前置工程
很多团队一提多源数据融合，第一反应就是“多拉几张表，join成一个宽表”。这个理解会让人在后面付出巨大代价。因为不同系统里的数据，从定义上就不对齐。同一个用户，会员库叫 member_id，订单库叫 user_no，行为日志里的设备指纹又是一串完全不同的字符串；同一个SKU，ERP里叫 item_code，电商前端叫 product_id，到了BI报表里可能直接换成商品名称。字段名看起来都是“金额”，但A系统是含税成交价，B系统是未税结算价，C系统是折扣前原价，三张表想直接相加，算出来的指标自己都不敢信。
所以多源数据融合应该被定义成一整套建模前置工程，大致包括：数据接入、字段解析、标准统一、实体对齐、主键映射、粒度配准、时间窗口校准、冲突消解、质量校验。每一环都在处理同一个核心问题：同一个业务对象，在不同系统里“长得不一样”，怎么让它在模型面前变成一个统一、可信、可计算的样子。
这套工程没做好，后面模型再高级也是白搭。业界有句话叫 Garbage in, garbage out，在多源场景下尤其真实。数据建模最终输出的是决策依据，地基如果是一堆互相打架的表，上面盖出的模型越复杂，塌得越难看。
1.3 怎么判断你的项目真的需要上多源融合
不是所有建模问题都要搞多源融合。只有下面三类信号出现时，融合才是绕不开的选项：
- 现有特征缺乏跨域组合能力。比如单靠订单数据已经很难再挖出新特征，而业务经验明确告诉你“行为+交易”“计划+履约”这类组合能提升区分度。
- 模型存在明显的样本偏置。正样本来自某个系统、负样本需要从另一个系统补全，或者某些关键人群在单一数据源里根本观测不到。
- 关键字段在不同系统里互相矛盾。比如ERP说订单已签收、物流系统说还在转运中，这类冲突已经不是建模问题，而是数据治理问题，需要靠融合逻辑统一。
如果你只是在一个内部数据源上做探索性分析，或者数据本身就高度规范化，那没必要为融合而融合。融合是有成本的，接入、清洗、同步、维护，每一项都要占人力和资源。但一旦确认需要，它就必须被当成一个正式工程来推进，而不是在建模阶段才临时抱佛脚。
2. 多源融合的三个技术层次：先别急着上复杂模型
聊到具体做法，我习惯把多源数据融合分成三个层次来看：数据接入层、特征融合层、语义融合层。这三个层次解决的问题完全不同，工作量也逐层递增。很多人一上来就研究实体消歧算法、知识图谱，结果连最基本的字段都还没对齐，属于典型的工具先于问题。
2.1 数据接入层：先解决“装得下、长得齐”
这一层的目标是把各个源系统的数据稳定、完整地搬运到统一存储里，也就是常说的数仓或数据湖的ODS层。技术选型上，可以是传统ETL调度的批处理，也可以用CDC监听数据库增量，再配合Kafka这类消息管道做成实时或准实时链路。具体用哪种，取决于下游模型对时效的要求：用户实时推荐可能需要分钟级延迟，而供应链日级预测用T+1批量同步就够了。
但不管选哪套，有一条原则我坚持了很久：源层数据必须保持原文原样，不做过多的清洗和转换。也就是说，在数仓里要有一层“不可变”的贴源数据，字段名、枚举值、时间格式都跟源系统保持一致，只是在上面加数据源标识和采集时间。倒不是怕脏，而是后续做融合时，你会发现清洗规则难免要回退和调整，如果源头已经被改得面目全非，连追溯都无从下手。
这一层比较容易出的问题是连接器不稳定、增量同步漏数据。我的做法是在接入层对每张表做水位线监控，比如记录源表最大更新时间，如果某次同步水位线没有前进，立刻告警。多源融合的前提是每个源都不断流，数据源断了一个，下游特征就悄悄缺失，模型输出还不会报错，这种风险最磨人。
2.2 特征融合层：特征对齐才是建模的主战场
数据进了同一个仓库，并不代表就能直接建模。绝大多数融合工作真正的主战场在特征层，也就是把不同来源的数据转换成可供模型训练的数值特征，并保证它们在行、列、时间上都对齐。
特征对齐的第一件事是确定行粒度。模型预测的是“每一个用户”还是“每一个订单行”，还是“每一个SKU每天”？融合的时候，每张源表都要先聚合到这个统一粒度上。比如用户粒度建模，订单表要先按 user_no 汇总成：近30天下单次数、平均订单金额、最近一次下单距今天数；行为表要按 user_id 汇总成：近7天浏览商品数、平均单次停留时长。两张表都聚合成“一个用户一行”之后，才能安全地 join 到一起。
第二件事是时间窗口的选取。跨源特征尤其要小心时间边界。比如行为数据表的统计窗口，必须落在预测日之前；如果你预测用户明天是否购买，却用了“明天当天及以后的行为特征”，就是典型的数据泄漏。Oracle里便宜又好用的方法，是在写特征SQL时不厌其烦地加时间条件，比如WHERE behavior_dt <= DATE_SUB(prediction_date, 1)。宁可多写两行条件，也不要让模型偷看到未来。
2.3 语义融合层：两张表的“用户”和“金额”到底是不是同一个东西
语义融合是多源数据融合里最隐蔽、也最难自动化的一层。它要回答的问题是：A系统里叫customer_id的字段，和B系统里叫member_uuid的字段，到底是不是指同一个业务实体；A系统的revenue和B系统的sales_amount，计算口径是否一致。
现实情况往往是：系统A和系统B由不同团队在十年前各自建设，它们甚至不知道自己管的数据是同一个对象的一部分。后来数据仓库开始做集成，才发现会员ID有三种编码规则，订单金额是含税还是不含税要翻几千行SQL才能推测出来。这个时候，任何纯技术方案都没法单独解决，必须结合业务定义。
我建议先做三件事：第一，梳理统一数据字典，给每个关键字段写上唯一定义、值域、枚举含义；第二，做字段级映射表，把各系统的字段与标准字段对应起来；第三，对无法确认的冲突项，找业务方当面确认，而不是自己猜。语义融合不一定要上知识图谱或深度学习实体匹配，大多数场景下，一份维护良好的映射表已经能解决大头。从下表的视角可以看三层工作的差异：
| 层次 | 工作对象 | 典型手段 | 主要产出 |
|---|---|---|---|
| 数据接入层 | 源系统原始表 | ETL/CDC/流式同步 | ODS贴源层、同步监控 |
| 特征融合层 | 统一粒度后的宽表 | 聚合、Join、时间窗口 | 模型训练特征矩阵 |
| 语义融合层 | 字典、口径、实体定义 | 数据字典、实体映射、主数据管理 | 统一业务口径与实体ID |
3. 贯穿融合全程的核心动作：实体、主键、粒度三件套
不管数据源有多少个，最终都要落到“对象”上。对象是谁、用什么标识、在什么粒度上对齐，这三个问题贯穿多源数据融合的全程，也是我每次做数据建模之前必须盘清楚的三件事。
3.1 实体识别：先承认不同系统里的“同一对象”长得不一样
实体识别听起来抽象，落地其实很具体：把各业务系统里表示“同一个现实对象”的字段找出来。常见的实体包括客户、商品、订单、门店、供应商、设备，等等。在跨系统的表里，这些实体通常没有统一的命名，也不会完全一致。
比如同一个用户：
- 会员系统：
member_id，格式是M20230101001； - 交易系统：
user_no，格式是纯数字； - 埋点日志：
user_id或设备指纹device_fingerprint。
这三者完全靠数据库自动匹配是做不到的，得靠业务经验先画出实体关系图，再用抽样的方法验证。我的习惯是先找业务核心对象画一张简单的“业务对象-字段-系统”对照表，明确每个对象在每个系统里有哪些候选标识字段。之后给每个对象分配一个全局实体ID，也就是下文说的代理键。
如果连业务访谈都没做，就直接对字段名相似度做算法匹配，很容易掉进两个坑：一是同名不同义，比如code在A表是商品编码、在B表是仓库编码；二是同义不同名，比如name和desc可能都指商品名称。所以实体识别的第一步永远是人工盘点，算法只是在人工确认后的范围内做批量辅助。
3.2 主键映射：从业务主键到代理键的转换
主键映射要做的事，是把各系统里千奇百怪的业务主键，统一映射到一个稳定的实体ID上。这个统一ID在数据建模里常叫代理键或全局ID。它的作用就像为同一个人发了不同身份证号之后，再补一张“一人一号”的对照表。
具体实现上，可以用自增序列、雪花算法或者hash编码，关键是这张映射表要固定下来，并记录来源系统和原始ID。结构大概长这样：
CREATE TABLE dim_entity_mapping ( entity_type STRING COMMENT '实体类型：customer/product/order...', source_system STRING COMMENT '源系统标识：erp/crm/logistics...', source_id STRING COMMENT '源系统里的业务主键', global_entity_id STRING COMMENT '统一实体ID', effective_start DATE, effective_end DATE );这里特别想提醒一句：不要图省事，直接把源系统的ID加个前缀拼成全局ID。比如把C10001和U10001拼成C10001-U10001，看着简单，一旦源系统ID在业务上发生变更或复用，全局ID就会跟着错乱，而且很难排查。稳定的做法是把映射关系落在独立表里，由映射服务统一维护，下游特征表只引用global_entity_id。
多对一的情况也必须人工确认。比如一个用户有两个手机号分别注册了两个账号，后来合并成一个，映射表里可能对应一个全局ID；一对多的场景则要特别谨慎，比如一个订单拆成多个物流包裹，每个包裹状态不同，这种如果强行映射到同一个订单ID，粒度就乱了。映射规则写清楚之后，还要定期检测是否有ID覆盖、失效和空值。
3.3 粒度对齐和时间对齐：融合的死角
主键映射解决的是“是不是同一个对象”的问题，粒度对齐解决的是“一行代表什么”的问题。这张表一行是一张订单，那张表一行是一个订单行项目，还有一张表一行是一个发货批次，把它们直接join，行数要么膨胀、要么蒸发。
我的经验是在融合之前，先明确建模的事实粒度。比如预测“订单是否按时送达”，事实粒度应该是“订单行项目+SKU”，而不是“订单头”。因为同一个订单可能包含不同SKU，各SKU的到货时间并不相同。确定粒度之后，所有源表必须在该粒度上聚合：订单头表拆到订单行，物流包裹表按订单行关联，下来的特征再按订单行汇总。
时间对齐是另一个容易翻车的地方。跨系统数据经常有事件时间和落库时间两个概念。ERP里的“订单签收时间”可能是仓库文员录入的时间，物流系统里的是扫描枪自动记录的时间，两者可能差好几个小时甚至一天。融合时应该统一用哪个？通常建议：优先使用最接近真实业务动作的时间，也就是抓拍设备、扫码设备自动生成的时间；人工录入时间只能作为辅助，不能作为默认时间轴。此外，在做“截止到某个时间点”的特征汇总时，所有子查询都必须显式加上event_time <= 目标时间的条件，防止把未来状态引入当前特征。
4. 当多源数据“打架”：冲突消解与数据质量对冲
多源融合的乐观想法是：每个源都完整、准确、一致。但真实世界里的数据，同一件事在不同系统里经常给出不同答案。怎么处理这些“打架”的数据，直接决定了模型的可信度。
4.1 冲突并不罕见：四类典型冲突
我总结出四类最常见的冲突，它们对建模的影响各有不同：
| 冲突类型 | 典型表现 | 发生原因 | 对建模的影响 |
|---|---|---|---|
| 缺失 | 物流系统没有某个订单的签收记录 | 系统间接口漏数、单证未同步 | 特征为空，样本被丢弃或估值偏置 |
| 重复 | 同一订单在ERP里出现两条记录 | 接口重放、人工重复录入 | join后行数膨胀，统计特征被放大 |
| 矛盾 | ERP显示已签收，物流显示在途 | 状态更新时序不一致，人工提前关单 | 目标变量被污染，模型学错标签 |
| 延迟 | WMS入库日期晚于实际到货日一周 | 补录晚、系统异步同步慢 | 时间窗口算错，特征时序失真 |
不要以为这些冲突只是个例。跨系统数据每天都有一定比例的“异常”，平时没人注意，建模时一旦把这类脏数据带进去，可能直接把一个特征从强信号变成噪声。比如目标变量delay_days，如果ERP提前关单，标签就会从“延迟3天”错写成“提前1天”，模型输出的可靠性自然无从谈起。
4.2 冲突消解规则：系统化的优先级判断
处理冲突，不能靠写代码时“谁最后覆盖谁”的隐式规则。我建议把冲突消解规则显式地定义成一张配置表，至少包含冲突字段、数据源优先级、默认取值、例外条件，以及规则负责人。
规则本身的常见逻辑有这么几类：
- 按来源可信度。业务系统直接产生数据的字段，可信度通常高于人工上传的表格；主数据系统的编码信息高于各业务系统自己维护的副本。比如商品名称，以主数据系统为准；订单签收时间，以物流扫描设备自动记录为准。
- 按时间戳。对同一字段，谁的业务时间更靠后，谁就更接近当前事实。比如库存数量，肯定要以最后一次盘点或出库记录为准。
- 按多数表决。如果三个源里有两个给出同样的值，优先采用多数值的口径。这种做法适合静态属性，比如商品分类、供应商所属地区。
- 按规则判定。某些冲突需要业务规则介入。比如ERP状态显示“已取消”，但物流系统有真实发运轨迹，通常判定为“实际已发运”，因为物理世界的行为比单据状态更可信。
我给过一个比较形象的比喻：冲突消解就像两个目击者对一起事件的描述不一致，法官需要的不是“随机信一个”，而是质证、时间线、证据等级。数据融合其实是把这个质证过程自动化了。规则定好后，还要保证每个融合字段都能追溯到取了哪个源的值，这样下游业务方来质疑的时候，你能当场拿出依据。
4.3 质量报告与血缘：让模型上线后还能追问题
很多人做多源融合，模型一发版就觉得完事大吉。但数据源会变、上游系统会改、对比基期会迁移，融合逻辑随时可能悄悄失效。我习惯在每条融合任务的末尾挂一张数据质量报告，用固定的指标衡量数据是否健康：
- 各字段空值率。空值率突然上升，通常意味着上游关联键出了问题。
- 主键重复率。超过阈值就要查是不是接口重复推送或映射表故障。
- 关键字段取值分布。比如延迟天数如果一夜之间全部变成0，多半是标签口径被改。
- 源系统水位线延迟。如果某个源的最新数据已经落后3天，下游融合特征就要标记为“低置信度”。
配合血缘关系，问题定位就变得很快。每个特征都记录它来自哪个源表、经过哪几步转换、最后落在哪个字段；出现异常时，沿着血缘线一路查下去，最迟半天能找到根因。没有血缘的多源融合项目，后期基本就是救火模式，今天一个数不对，明天一个特征缺失，每次都要从头翻SQL，既耗时又痛苦。
5. 完整实战拆解：供应链到货预测模型的多源融合链路
前面讲了不少原理，下面用一个我实际做过的场景把整套流程串起来：制造业供应链里的“到货延迟天数预测”。这个项目让我对多源数据融合的各个环节都有了实感，也踩了不少坑，过程比较有代表性。
5.1 业务目标与数据源盘点
业务背景是某制造企业的零部件采购到货经常不准，生产计划只能靠人为经验预留缓冲时间。他们想做的是一个模型：每个采购订单行（对应某个SKU）到货延迟多少天。目标变量就是实际签收日期 - 计划到货日期，如果是负数就等于提前到货。
数据源大致可以分成四块：
- ERP系统：采购订单头、订单行、计划到货日期、供应商主数据。
- WMS仓储系统：实际入库记录、到货签收时间。
- 物流运输系统：发货时间、各转运节点扫描时间、签收时间。
- 外部数据：来源地天气情况、节假日安排、路况指数。
如果没有多源融合，只用ERP的计划日期和供应商主数据，模型可以预测平均水平，但无法解释“为什么这个订单会晚”“是不是天气导致”。要想回答后两个问题，就必须把物流过程和外部因素接进来。
5.2 实体、主键、粒度的落地方案
这个项目的核心对象有三个：采购订单行、物流发货批次、物料SKU。
ERP里的主键是po_line_id（订单行ID），物流系统里跟踪到的是shipment_id，但物流系统回传的表里业务上也保留了po_line_id的关联字段。遗憾的是，早期接口对接不全，物流表里有大约15%的po_line_id是空的，只能靠“供应商+物料+最近下单时间”做弱匹配。为此我建了一张映射表，并写了对账逻辑，弱匹配后还人工抽检了100条，确认匹配正确率在98%以上。
粒度上，模型最终锁定为“采购订单行+SKU”一行。WMS的每条入库单要聚合到这个粒度，物流事件表按shipment_id展开、再关联回po_line_id。下面是一段特征加工SQL的骨架，重点看关联条件和时间约束：
SELECT e.po_line_id, e.sku_id, e.supplier_id, e.scheduled_arrival_date, w.actual_receipt_date, DATEDIFF(w.actual_receipt_date, e.scheduled_arrival_date) AS delay_days, s.first_ship_date, s.last_scan_date, SUM(CASE WHEN s.event_type = 'TRANSPORT' THEN 1 ELSE 0 END) AS segment_cnt FROM erp.po_line e LEFT JOIN wms.receipt w ON e.po_line_id = w.po_line_id LEFT JOIN logistics.shipment_event s ON e.po_line_id = s.po_line_id AND s.event_time <= w.actual_receipt_date GROUP BY e.po_line_id, e.sku_id, e.supplier_id, e.scheduled_arrival_date, w.actual_receipt_date, s.first_ship_date, s.last_scan_date;这段SQL里有几个关键点：物流事件表 join 加上了s.event_time <= w.actual_receipt_date，避免把签收之后才补录的事件也算进去；DATEDIFF算出目标变量；segment_cnt统计运输事件数。实际项目里物流事件表很大，必须提前按po_line_id分区或建索引，否则会跑到怀疑人生。
5.3 特征构建与时间切分
完成基础对齐之后，我在这个粒度上逐步构建了以下特征：
- 供应商维度：过去90天历史订单准时率、过去90天平均到货延迟天数、供应商所在城市。
- 物料维度：物料历史平均提前期、物料近30天下单频次、物料价格带。
- 订单维度：当前订单的提前期（计划到货日期减去下单日期）、订单包含的SKU数量、是否加急。
- 物流维度：首条发货事件距计划到货的天数、最近扫描节点距目的地的距离、运输事件分段数量、中间节点的平均停留时长。
- 外部因素：发货城市和收货城市当天是否暴雨/台风、是否重大节假日、星期几、当月是否月底。
外部天气数据不是实时去拉，而是先把历史天气快照落成一张维表，按城市和日期关联，避免建模时依赖不稳定接口。特征构建的代码通常是一串按粒度聚合的DataFrame操作，比如用Python的话，可以按supplier_id做groupby算历史准时率，再merge回订单行。这里要特别提醒：所有历史窗口都要以预测日为准，比如“过去90天”是预测日往前推90天，而不是特征加工当天。我见过有人直接用当前日期算历史窗口，这在离线训练时好像没事，一旦上线做实时预测，窗口就“偷偷”往后跑了，特征分布直接漂移。
时间切分上，我用的是滚动起点法，按订单计划到货日期排序，前80%做训练、后20%做验证，并且确保训练集和验证集没有时间交叠。之所以不用随机切分，是因为这个场景里的天气、备货周期、供应商状态都有强时间效应，随机切分会把未来信息泄漏到训练集里，指标虚高到让人产生错觉。
5.4 融合效果与代价
简单对比一下不同数据源组合的效果（评估指标用预测值与实际值的平均绝对误差MAE）：
| 融合组合 | MAE（天） | 说明 |
|---|---|---|
| 只用ERP数据 | 4.2 | 基线，基本是历史平均水准 |
| ERP+物流数据 | 3.5 | 加入真实履约节点后误差明显下降 |
| ERP+物流+外部天气/节假日 | 3.2 | 额外增益主要来自异常天气和节假日的长尾订单 |
最后的三个多点误差，对生产计划来说仍然有优化空间，但相比原来靠人工拍脑袋已经可用了。更要紧的是，模型给出的特征重要性里，供应商历史准时率、物流分段时长、发货地天气这几项排在最前面。这从业务逻辑上也是成立的：准时率代表供应商的稳定水平，物流分段时长代表实际运输瓶颈，天气影响的是偶发风险。融合不是把“变量数量”堆上去，而是把业务链路上缺失的观测视角给补上了。
6. 融合建模的坑与我的经验清单
每次写到实战，总会想起那些让人头皮发麻的排查过程。多源融合一旦哪里没对齐，报错往往不会很明显，只会让模型指标悄悄变差。这里把我踩过的坑和现在的固定动作一并列出来，希望能帮你少走弯路。
6.1 五个真实踩过的坑
第一个坑是上来就全量接入。早期我会觉得“把所有数据都搬过来再说”，结果每张源表都要开发同步任务、每张表都可能有脏数据，运维成本高得吓人，而真正进模型的源可能只有一半。现在我的做法是先做增量价值验证：先建一个只包含两三个关键数据源的小管线，跑出基线效果，再逐步加源、看增量收益，没收益就直接砍掉。
第二个坑是主键想当然唯一。曾经在 join 订单表和物流表时，发现预测目标出现大量重复，追了半天才明白：一个订单行可能被拆成多个包裹，每个包裹有一条记录，直接 join 后行数膨胀，目标变量被重复计数。从那以后，每次 join 前我都会先做一次“主键唯一性检查”，用GROUP BY数一下每个键对应的行数，确认不是一对多再往下走。
第三个坑是时间窗口没掐死，造成特征泄漏。离线验证的 AUC 逼近0.99，当时一度觉得自己要发顶会了。后来发现某个排序特征把“未来30天是否发生某事件”也算进去了，上线之后效果直接崩塌。现在我对所有跨源特征都强制要求带上“截止时间”条件，并且专门在代码里搜索有没有漏掉<=的地方。
第四个坑是指标口径不清。两个系统对“订单金额”的定义完全不一样，一个是含税实付、一个是未税原价。合并之后，供应商金额排序完全乱套，模型的调整系数也跟着扭曲。解决办法是建字段口径映射表，每个字段都写清楚定义和来源，业务方签字确认后再进模型。
第五个坑是融合后特征膨胀。只要把10个源的表都加进来，特征数很容易突破几百维。几百个特征在小数据集上尤其容易过拟合，而且解释性很差。我现在的习惯是控制单次融合的特征增量范围，同时用特征重要性做前置筛选，不盲目上深度模型。
6.2 我现在的融合建模工作清单
经过这些折腾，我基本形成了一套自己的固定动作。接到建模需求时，先不急着选模型，而是按下面几步走：
- 画一张“业务对象-系统”地图，把核心实体、关键行为、主键来源都列出来。
- 写清楚每个融合字段的来源系统、更新频率、口径定义和负责人。
- 先做单源基线模型，记录当前效果。
- 每次只增加一个数据源，评估增量增益，再决定是否保留。
- 所有时间型特征在代码层强制约束窗口上限，并安排代码评审专项检查。
- 建立自动数据质量报告，监控空值率、主键重复率、关键字段分布变化。
- 上线前让业务方参与口径确认，上线后保留完整的特征血缘，方便追数。
这条清单并不能让你一蹴而就，但能帮你把多源数据融合里那些“看似小其实致命”的问题，在早期就暴露出来。我自己现在的习惯是，接到一个建模需求，先问的问题不是“用什么算法”，而是“这个预测对象在真实业务里，会经过哪些系统、留下哪些足迹”。把这些足迹理清楚，数据建模的成功率往往就已经有一半了；另一半，才轮到模型和调参。多源数据融合技术说起来很大，落到项目里其实就是这些琐碎又关键的小事，一件件做到位，结果自然站得住。
