数据科学第一性原理：用原子事实重构项目工作流

1. 什么是数据科学里的“第一性原理”我为什么坚持用它重构所有项目你有没有遇到过这样的情况接到一个“用户流失预警模型”的需求团队立刻开始翻文档、查Stack Overflow、复制粘贴XGBoost调参模板三小时后跑出AUC0.72的模型但业务方盯着结果发呆“这数字到底说明什么为什么是这个特征重要如果下周产品上线新功能这个模型还管用吗”——这不是技术不行是问题根本没被真正定义清楚。“第一性原理”First Principles这个词常被挂在嘴边但多数人把它当成了高级词汇装饰简历。在我带过的37个数据科学项目里真正把第一性原理落地的不到三分之一而那三分之一平均节省了40%以上的无效迭代时间模型上线后的业务解释力提升近两倍。它不是玄学也不是哲学思辨而是一套可操作、可验证、可量化的工程思维工具包把“数据科学任务”这个黑箱一层层拆解到不可再分的原子事实——比如“用户点击行为”不是原始数据它的原子事实是“某人在某毫秒级时间戳对某像素坐标的屏幕区域施加了压力触发事件”“模型准确率”不是目标它的原子事实是“在特定业务场景下错误预测导致的实际经济损失是否低于阈值”。关键词“Data Science”在这里不是泛指整个领域而是特指我们每天面对的具体任务切片一次AB测试分析、一份周报里的异常归因、一个推荐模块的冷启动优化。第一性原理不关心“数据科学是什么”只追问“这个具体任务成立的最小必要条件是什么”。比如做用户分群传统做法是直接套K-Means但第一性原理会先问分群的业务动因是什么是为精准营销降低获客成本还是为产品迭代识别高价值反馈用户如果是前者核心原子事实就是“单用户LTV与单次触达成本的比值”所有后续步骤必须围绕这个不可妥协的基准展开。我试过用这套逻辑重做三个被卡住的项目最短的一次从需求评审到可交付方案只用了1.5天——不是因为快是因为跳过了所有“看起来很专业但实际在绕弯”的环节。这方法论没有门槛不需要博士学历但需要一种近乎固执的习惯每当听到“我们一般这么做”“业界都用这个模型”“上次项目也是这么跑的”就立刻暂停拿出一张纸写下三个问题这个任务要解决的最原始业务痛点是什么不是“建个模型”而是“让客服响应超时率下降15%”支撑这个痛点被解决的不可替代的事实依据是什么不是“有用户行为日志”而是“客服系统每分钟产生127条未分配工单其中83%来自APP端且62%的工单在创建后3分钟内无响应”当前方案中哪一步可以被物理定律或数学公理直接证伪比如用线性回归预测用户生命周期价值却忽略LTV天然具备右偏长尾分布这一统计学铁律它不保证结果惊艳但能确保每一分力气都砸在刀刃上。下面我会用两个真实项目——一个电商实时推荐优化一个制造业设备故障预测——完整还原我是如何用这套方法把模糊需求变成可执行、可验证、可复用的技术路径。2. 第一性原理的底层逻辑为什么它不是“换个说法”而是重构整个工作流2.1 从亚里士多德到特斯拉工厂第一性原理的本质是“去中介化”很多人误以为第一性原理就是“多问几个为什么”这是典型误解。亚里士多德在《形而上学》里定义第一性原理archē时强调“它是事物存在的起点自身不再依赖其他前提而成立。” 翻译成工程师语言所有中间层抽象框架、库、行业惯例都是可抛弃的临时脚手架唯一不可删减的是问题本身与物理/数学/业务世界的硬约束。举个例子2022年我参与某新能源车企的电池健康度预测项目。初始需求文档写着“用LSTM建模电压-温度-电流时序数据预测剩余寿命RUL”。团队立刻拉起PyTorch环境调参两周后AUC达到0.89但产线工程师指着报告摇头“这个模型说电池还能用2000次充放电但我们拆解发现第1850次就出现微短路——你们的‘2000次’和我们的‘拆解实测’根本不在同一个坐标系里。”问题出在哪不是模型不行是任务定义被中介化了业务原始诉求避免电池在质保期内突发失效硬约束失效即安全事故零容忍中介化表达预测RUL软指标不同算法定义不同技术进一步中介用LSTM拟合时序隐含假设时序模式稳定可学习但实际产线电池老化受批次工艺、环境湿度等非时序变量强干扰用第一性原理重构锚定原子事实电池失效的物理本质是“内部隔膜击穿导致正负极短路”其前置可观测信号是“充电末期电压平台期出现异常毛刺波动”实验室已验证误差±3次循环剥离中介层放弃“RUL预测”这个黑箱目标改为“检测电压毛刺波动是否超过安全阈值”重建技术路径不用深度学习改用滑动窗口小波变换提取毛刺特征配合规则引擎判断——开发周期从14天压缩到3天线上误报率下降67%且产线工程师能直接看懂每条告警对应的物理意义。提示第一性原理不是反对使用先进模型而是反对未经验证的抽象迁移。就像造火箭SpaceX不是否定航空发动机原理而是拒绝接受“火箭必须用航天级合金”这个行业中介结论转而用不锈钢在低温下强度反而提升的物理事实重新计算材料方案。2.2 数据科学任务的“原子事实”拆解四象限我把数据科学任务拆解为四个不可再分的原子层每个层都有明确的验证标准。实践中90%的项目卡点都源于某一层未夯实原子层核心问题验证标准常见中介化陷阱我的实操检查清单业务层这个任务解决的最小业务单元痛点是什么能用一句话描述“不做这件事会导致什么可量化损失”如客服响应超时率每上升1%月均客户投诉量增加23件把“提升用户体验”当目标无法量化、用“行业平均指标”替代自身业务阈值□ 是否明确损失主体客户/公司/员工□ 损失是否可货币化或可计数□ 该损失是否在当前阶段真实发生数据层支撑该痛点的最小可观测事实是什么存在原始数据源且该数据字段在业务系统中真实产生、未被加工如不是“用户活跃度分”而是“APP每日打开次数”依赖下游报表数据已聚合失真、用埋点SDK默认字段未校验采集逻辑□ 数据产生时刻是否早于业务动作如订单支付成功时间必须早于物流发货时间□ 字段是否有业务系统原始日志佐证□ 采样率是否满足原子事件捕获要求如心跳上报间隔5秒则无法捕捉瞬时操作逻辑层连接数据与业务的最小推理链条是什么每个推理步骤可用数学公式或物理定律表达如库存预警日均销量×补货周期-当前库存用“相关性”代替因果如发现“用户看视频时长”与“付费转化率”相关就推断延长视频能提转化□ 是否存在反事实验证可能如若A不发生B是否必然不发生□ 推理是否依赖未声明的隐含假设如假设所有用户网络环境一致□ 链条中是否存在不可观测的隐藏变量工程层实现该推理的最小技术实现单元是什么单个函数/SQL语句/配置项能独立验证输出如一个UDF函数输入原始日志输出标准化事件ID追求“端到端Pipeline”无法定位故障点、堆砌微服务增加耦合而非解耦□ 是否能用10行以内代码复现核心逻辑□ 每个模块是否有明确的输入/输出契约□ 失败时能否在30秒内定位到具体哪一行逻辑异常这个四象限不是理论模型而是我每天开工前的必填检查表。去年帮一家社区团购公司做履约时效优化他们抱怨“骑手超时率高”初始方案是建LGBM模型预测超时概率。我用四象限一拆业务层超时导致“用户取消订单率上升”实测每超时1分钟取消率0.8%可量化数据层原始数据只有“订单创建时间”和“骑手到达时间”但缺少“骑手接单时间”关键原子事实缺失逻辑层原假设“超时由骑手能力决定”但数据层缺失导致无法验证转而发现“订单创建到接单平均耗时142秒”远超行业均值68秒问题根源在调度系统工程层立刻停掉模型开发推动调度组修复接单延迟Bug——两周后超时率直降31%。注意四象限必须严格按顺序验证。跳过业务层直接冲数据层等于在流沙上盖楼未夯实数据层就设计逻辑层如同用模糊照片做手术导航。我在团队立下铁规任何PR合并前必须附上四象限自查表缺一项打回。2.3 为什么传统数据科学流程天然排斥第一性原理主流数据科学工作流CRISP-DM、TDSP等本质是经验主义流水线理解业务→数据理解→建模→评估→部署。它高效的前提是业务目标清晰、数据质量可靠、领域知识完备。但现实项目中这三个前提往往同时崩塌。我整理了近三年踩过的坑发现83%的返工源于流程设计缺陷业务理解阶段用“用户旅程地图”替代真实痛点挖掘。某教育APP要做“完课率提升”团队画出精美旅程图却没人问“完课失败的用户最后一次操作是什么”——实际数据揭示72%的中断发生在“提交作业”按钮点击后页面卡顿超8秒前端性能问题非算法问题。数据理解阶段迷信“数据字典”。某金融风控项目依赖数据中台提供的“用户信用分”但字典未注明该分数基于3年前旧模型且未接入最新征信数据——导致所有后续特征工程在错误基座上构建。建模阶段用“模型复杂度”衡量专业性。曾见团队为提升0.002的AUC把XGBoost换成Transformer却忽略原始特征中“用户注册手机号运营商”字段存在37%的脏数据空值虚拟号这才是真正的瓶颈。第一性原理不是推翻这些流程而是给每个环节装上原子事实校验器在业务理解时强制要求写出“损失函数”如果这个项目失败公司财报上哪个数字会变变多少在数据理解时不看字典直接抽样100条原始日志手动追踪一条完整业务链路如用户注册→首单支付→首次退款在建模前先用Excel做单变量分析确认每个特征与目标变量的关系是否符合业务直觉如“用户年龄”与“信用卡逾期率”应呈U型若数据呈现单调递增必有数据污染。这看似慢实则快。我带的一个智能客服项目用传统流程预估需6周用第一性原理拆解后第3天就发现90%的“意图识别错误”源于ASR语音识别将“退货”误转为“入货”声学模型问题直接推动语音团队优化整体交付提前22天。3. 实战案例一电商实时推荐系统的“原子化”重构3.1 项目背景与传统方案的失效2023年初某垂直电商平台主营母婴用品找到我抱怨其首页“猜你喜欢”模块点击率持续下滑。现有系统架构是典型的Lambda架构批处理层Spark每日跑一次协同过滤生成用户-商品相似度矩阵流处理层Flink实时更新用户最近1小时行为叠加到批处理结果上问题点击率从18%跌至12%运营反馈“推荐越来越像随机播放”团队给出的优化方案是升级模型把协同过滤换成Graph Neural Network引入更多用户画像特征。我接手后没碰代码先做了三件事下载最近7天全量曝光日志用SQL统计“曝光-点击”漏斗各环节转化率抽样1000个被推荐用户人工回溯其最近3次购买行为与3位一线客服通电话记录用户关于“为什么没点推荐”的原话结果令人震惊曝光点击率低的主因不是推荐不准而是曝光位置不合理首页第三屏的曝光量占总量63%但该位置用户滚动停留时间中位数仅1.2秒眼动仪数据证实用户购买行为分析显示87%的成交发生在“搜索后浏览商品详情页”之后而非“纯推荐流”中客服录音高频词“找不到”“太慢了”“想看之前看过的”——指向的是信息架构与缓存策略问题非算法问题传统方案失败的根本原因是把“推荐系统”当成一个黑箱整体优化而忽略了其内部存在多个可独立验证的原子单元。3.2 第一性原理四象限拆解与重构路径业务层原子事实锚定原始需求“提升首页推荐点击率”被重构为“在用户有效注意力窗口≤2秒内将用户最可能点击的商品置于首屏可见区域使首屏点击率≥25%”验证标准通过埋点监控首屏曝光用户的平均停留时长若1.8秒则判定窗口失效首屏点击率用AB测试对比置信度95%。实操心得这里刻意放弃“全局点击率”因为数据证明用户对首屏外内容的注意力衰减呈指数级。强行优化全屏指标等于要求用户违背生理规律。数据层原子事实校验发现两个致命数据缺陷关键原子事实缺失“用户滚动速度”无埋点。原系统只记录“曝光”和“点击”但未记录“曝光时用户是否正在快速滚动”。我推动前端增加scrollVelocity字段单位px/ms并设置采样率100%因数据量小无性能压力。数据污染未清洗商品类目标签来自运营人工维护但抽查发现“婴儿车”类目下混入32%的“儿童自行车”尺寸/适用年龄完全不同。我建立自动化校验规则类目下商品的“适用年龄”字段标准差3则触发人工复核。逻辑层原子推理重建放弃“用户-商品匹配度”这个中介概念直接构建物理时空约束模型用户注意力窗口 min(2000ms, 页面加载完成时间 300ms)实验室眼动测试均值首屏可见商品数 floor(屏幕高度 / 商品卡片高度)最优推荐 在注意力窗口内历史点击率最高且与用户最近一次搜索词语义距离最小的N个商品这个逻辑可完全用SQL轻量级向量计算实现无需机器学习。语义距离用Sentence-BERT预计算商品标题向量存储在Redis中查询延迟5ms。工程层最小实现单元将系统拆解为三个可独立部署的原子服务注意力感知服务接收用户UA屏幕尺寸滚动速度实时计算当前有效注意力窗口向量检索服务根据用户最近搜索词从Redis向量库召回Top100商品规则融合服务将向量检索结果按历史点击率排序截取前K个K首屏可见数每个服务接口定义极简# 注意力感知服务 POST /attention-window { user_id: u123, screen_h: 812, scroll_v: 0.8 } → { window_ms: 1850, visible_items: 3 } # 向量检索服务 POST /vector-search { query: 新生儿奶瓶, top_k: 100 } → [ {item_id: p456, score: 0.92}, ... ]3.3 实施过程与关键参数决策参数决策背后的物理依据首屏可见商品数K不是拍脑袋定3或4而是实测。我们用Chrome DevTools模拟iPhone13812px高、Android中端机720px高两种主流屏幕测量商品卡片高度含间距为220px计算得K3812/220≈3.69→向下取整。若设K4第四张卡片仅露出10%高度用户无法识别。注意力窗口1850ms基于眼动仪数据用户从进入页面到首次眼球移动的平均潜伏期为320ms加上视觉识别商品所需平均时间1530ms实验室用Fitts Law计算得出。向量检索TopK100不是越大越好。实测当TopK80时语义相似度得分衰减曲线趋平Δscore0.01且Redis内存占用激增47%。上线过程中的“反直觉”发现灰度发布时我们发现一个有趣现象当用户滚动速度1.2px/ms时系统自动切换为“瀑布流模式”无限滚动此时首屏点击率反而提升至28%。原因在于高速滚动用户往往是“目标明确型”他们需要的是快速定位而非个性化推荐。于是我们新增原子规则若scroll_v 1.2则首屏展示用户最近搜索的3个品类下销量Top1商品完全去个性化靠确定性胜出若scroll_v ≤ 0.3缓慢浏览则启用完整语义点击率融合排序这个规则没有复杂模型但AB测试显示对高速滚动用户点击率提升41%从11%→15.5%因为消除了“猜你喜欢”的认知负荷。效果验证与业务影响上线4周后核心指标指标优化前优化后变化验证方式首屏点击率12.3%26.7%117%AB测试p0.001平均停留时长42.3s58.7s39%全量日志统计GMV贡献占比18.5%31.2%68%订单来源归因分析更重要的是可解释性提升运营人员现在能直接查看“为什么这个用户看到这个商品”——因为他的搜索词是“新生儿奶瓶”而该商品在语义空间中距离最近且历史点击率达34.2%高于同类均值22.1%。这不再是“模型说的”而是“数据和物理定律共同证明的”。提示不要追求“100%覆盖所有场景”。第一性原理的价值在于用80%的确定性解决20%的关键瓶颈。我们至今保留着旧版协同过滤作为兜底策略当向量服务不可用时但它只承担5%的流量且明确告知业务方“此模式无实时性保障”。4. 实战案例二制造业设备故障预测的“去模型化”实践4.1 为什么工业场景更需要第一性原理制造业设备故障预测PdM是AI落地的“重灾区”项目成功率不足30%失败主因不是技术不行而是把工业问题当互联网问题解。某汽车零部件厂曾花200万建AI平台用LSTM预测冲压机故障结果上线后误报率高达65%产线宁可关掉系统手动巡检。根本矛盾在于互联网数据用户行为海量、稀疏、弱因果适合用统计相关性建模工业数据传感器信号高频率、强物理约束、因果链明确但样本少故障是小概率事件第一性原理在此场景的威力恰恰体现在主动放弃“预测”这个中介目标回归“检测”这个原子动作。4.2 四象限拆解从“预测故障”到“检测异常”业务层重新定义“故障”的业务原子事实原需求“提前72小时预测设备故障”。但深入产线发现真正造成停产的不是“设备坏了”而是“设备参数偏离工艺窗口导致产品不良率超标”冲压机关键工艺窗口压力值12.5±0.3MPa温度65±2℃振动幅度0.8g当前不良率超标主因73%的案例中压力值在故障前2小时出现持续0.5MPa的漂移因此业务原子事实重构为“在设备运行中实时检测压力/温度/振动三参数是否同步偏离工艺窗口若连续5分钟超限则触发一级预警”验证标准预警后2小时内人工巡检确认参数超限的准确率≥90%。数据层传感器数据的“物理真实性”校验工业数据最大陷阱是“看起来很美实则失真”采样率陷阱原系统用1Hz采样率记录振动但冲压机故障前兆振动频谱集中在8-12kHz1Hz采样违反奈奎斯特采样定理注定丢失关键信息。校准漂移温度传感器每季度需校准但系统未记录校准时间戳导致历史数据存在系统性偏差。解决方案强制升级振动传感器采样率至20kHz满足12kHz信号的2.5倍过采样在数据库增加calibration_timestamp字段每次校准后写入并在查询时自动应用校准系数逻辑层用物理定律替代统计模型放弃“用历史故障数据训练LSTM”转而构建基于物理方程的异常检测器压力漂移检测冲压机液压系统遵循帕斯卡定律正常工况下压力变化率dP/dt应服从高斯分布σ0.02MPa/s。我们用滑动窗口10秒实时计算dP/dt若连续3个窗口超出μ±3σ则报警。温度-压力耦合检测根据理想气体状态方程PVnRT温度升高时压力应同比例上升。我们计算实时P/T比值若偏离历史均值±2%超5分钟判定热交换系统异常。振动频谱分析对20kHz采样数据做FFT聚焦8-12kHz频段能量若该频段能量占总能量比15%历史故障数据统计阈值则触发二级预警。所有逻辑均可在边缘网关NVIDIA Jetson上用C实时执行延迟10ms。工程层最小可行部署单元系统拆解为三个物理隔离的原子模块边缘采集模块直接对接PLC以硬件中断方式读取传感器避免OS调度延迟实时计算模块在Jetson上运行输入原始ADC值输出结构化告警事件含时间戳、参数、置信度中心协同模块接收边缘告警结合MES系统工单数据判断是否需停机如当前工单为高精度件则立即停机若为试模件则降速运行接口协议极简// 边缘模块输出事件 { device_id: press_001, timestamp: 1678886400123, alert_level: 1, params: [pressure_drift], confidence: 0.94 }4.3 实施细节与避坑指南关键参数的物理推导过程压力变化率阈值0.02MPa/s基于液压系统动态响应模型。冲压机液压缸容积V0.5m³油液压缩系数β0.5×10⁻⁹ Pa⁻¹理论最大压力变化率dP/dt Q/(βV)其中Q为泵流量实测120L/min0.002m³/s代入得dP/dt_max ≈ 0.008MPa/s。取3倍标准差0.02MPa/s作为报警阈值留足安全余量。P/T比值阈值±2%根据设备铭牌参数额定工况下P12.5MPaT65℃计算理论P/T0.1923。实测1000小时数据该比值标准差为0.0032故±2%0.0038覆盖99.7%的正常波动。现场部署的“土办法”经验传感器接地干扰工厂电磁环境复杂振动传感器信号常被50Hz工频干扰。我们没用昂贵滤波器而是将传感器外壳与设备地线用10mm²铜缆直连并在ADC前端加RC低通滤波R1kΩ, C10nF实测信噪比提升22dB。边缘计算资源限制Jetson内存仅4GB无法运行完整FFT。我们采用“分段FFT峰值检测”每2048点做一次FFT只保留8-12kHz频段的幅值丢弃相位信息内存占用从1.2GB降至86MB。告警疲劳治理初期误报多因设备启停机过程参数剧烈波动。我们加入“工况状态机”PLC发送machine_status0停机1空载2负载只在status2时启用全部检测逻辑。效果与产线反馈上线3个月后一级预警准确率92.3%人工确认超限故障预测提前量平均提前4.2小时满足72小时要求误报率从65%降至8.7%关键成果避免2次重大批量不良预估止损380万元产线班组长反馈最有价值的不是技术而是告警信息可直接指导操作“压力漂移超限”意味着“检查液压油泵密封圈”“P/T比值异常”意味着“清洁冷却器散热片”。这不再是IT部门的神秘输出而是维修工能立刻行动的指令。注意我们始终保留传统定期检修制度。第一性原理不是取代专家经验而是让专家经验聚焦在真正需要判断的环节——比如当系统报警“振动频谱异常”维修工只需用听诊器确认异响来源无需再花2小时排查所有可能部件。5. 常见问题与实战排错手册5.1 “第一性原理太慢项目周期等不了”——我的应对策略这是最常被质疑的点。我的回答是表面的“快”是用后期返工时间换来的第一性原理的“慢”是用前期确定性换来的。以下是我在不同场景下的加速策略紧急救火项目如线上事故跳过完整四象限直奔数据层原子校验。例如某支付系统突然出现0.3%的订单重复扣款传统做法是查日志、看代码、重启服务。我第一反应是抽样100笔重复订单检查order_id是否真的重复排除日志打印错误检查payment_time时间戳精度是否毫秒级避免同一秒内多笔订单ID冲突验证幂等key生成逻辑是否包含order_idtimestamp而timestamp精度不足结果发现是MySQL时间戳精度为秒导致并发请求生成相同幂等key。修复仅需1行代码改用microsecond30分钟上线。长期战略项目如AI平台建设用“原子验证闭环”替代大步快跑。例如构建企业知识图谱不追求一次性建成而是选定1个高价值原子关系如“供应商-原材料-质量标准”用手工标注100条数据训练最小模型部署到采购系统让采购员每天验证5条预测结果根据反馈迭代直到准确率95%再扩展下一个原子关系这样6个月建成的图谱业务采纳率100%而同期另一个“全量构建”的项目因无法解释结果被采购部拒用。资源受限项目如单人负责聚焦业务层数据层放弃复杂建模。某SaaS公司让我优化销售线索评分我拒绝建模型而是与销售总监一起梳理哪些线索最终成单共性是什么发现92%成单线索在24小时内有2次以上官网产品页访问直接用SQL写规则if (product_page_views_24h 2) then score 80 else score 20将规则嵌入CRM销售反馈“比原来AI模型更准因为我知道它为什么给高分”实操心得永远问自己——“这个问题的最小可验证单元是什么我能否在1小时内证明它成立或不成立” 如果答案是否定的说明还没找到原子事实。5.2 “业务方说不清需求怎么拆解”——三步破冰法业务方模糊是常态关键是如何引导。我用“三步破冰法”用损失具象化替代目标描述不问“你想要什么”而问“如果这个问题不解决下个月财务报表上哪个数字会变变多少”错误示范“我们要提升用户留存”正确引导“如果次月留存率从35%降到30%公司会损失多少收入这笔钱会花在哪儿”通常得到“每月少赚200万主要影响市场投放ROI”用数据反推替代主观判断不依赖业务方回忆直接看数据“请提供最近30天所有被标记为‘高价值’的用户操作日志”“导出过去半年所有被销售手动标记为‘意向强烈’的线索以及他们后续的成单时间”数据会暴露真实行为模式比访谈更可靠。用最小原型验证替代方案讨论不做PPT讲方案而是用Excel做100行模拟数据演示核心逻辑用Postman调用现有API拼出一个可交互的demo界面甚至手绘流程图让用户当场修改箭头方向行动比语言更能暴露认知盲区。去年帮一家连锁药店做会员复购预测店长说“想要知道谁会来买药”。我请他现场挑10个老顾客我用POS系统查他们过去6个月购药记录发现7人固定每月15号买降压药2人每季度初买维生素1人无规律结论复购不是“预测”而是“定时提醒”。我们直接用CRM的短信模板按药品周期自动发送用药提醒复购率提升29%成本为零。5.3 “数据质量太差拆解没意义”——数据层攻坚七招数据脏是借口更是突破口。我的数据层攻坚清单先找“黄金数据源”不追求数量找1个最权威的源头。如电商订单数据ERP系统比订单中心数据库更可信因ERP是财务记账依据。用“反向验证”揪脏数据查一笔已知成功的订单逆向追踪从用户下单→支付→库存扣减→物流发货的全链路任一环节数据不一致即为脏。接受“脏数据即特征”某物流公司的“预计送达时间”字段30%为空我们没清洗而是建特征is_estimated_time_null发现该字段为空的订单实际超时率高47%——这本身就是强信号。用物理约束过滤