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

1. 什么是数据科学里的“第一性原理”？我为什么坚持用它重构所有项目

你有没有遇到过这样的情况：接到一个“用户流失预警模型”的需求，团队立刻开始翻文档、查Stack Overflow、复制粘贴XGBoost调参模板，三小时后跑出AUC=0.72的模型，但业务方盯着结果发呆：“这数字到底说明什么？为什么是这个特征重要？如果下周产品上线新功能，这个模型还管用吗？”——这不是技术不行，是问题根本没被真正定义清楚。

“第一性原理”（First Principles）这个词常被挂在嘴边，但多数人把它当成了高级词汇装饰简历。在我带过的37个数据科学项目里，真正把第一性原理落地的不到三分之一；而那三分之一，平均节省了40%以上的无效迭代时间，模型上线后的业务解释力提升近两倍。它不是玄学，也不是哲学思辨，而是一套可操作、可验证、可量化的工程思维工具包：把“数据科学任务”这个黑箱，一层层拆解到不可再分的原子事实——比如“用户点击行为”不是原始数据，它的原子事实是“某人在某毫秒级时间戳，对某像素坐标的屏幕区域施加了压力触发事件”；“模型准确率”不是目标，它的原子事实是“在特定业务场景下，错误预测导致的实际经济损失是否低于阈值”。

关键词“Data Science”在这里不是泛指整个领域，而是特指我们每天面对的具体任务切片：一次AB测试分析、一份周报里的异常归因、一个推荐模块的冷启动优化。第一性原理不关心“数据科学是什么”，只追问“这个具体任务成立的最小必要条件是什么”。比如做用户分群，传统做法是直接套K-Means，但第一性原理会先问：分群的业务动因是什么？是为精准营销降低获客成本？还是为产品迭代识别高价值反馈用户？如果是前者，核心原子事实就是“单用户LTV与单次触达成本的比值”，所有后续步骤必须围绕这个不可妥协的基准展开。我试过用这套逻辑重做三个被卡住的项目，最短的一次，从需求评审到可交付方案只用了1.5天——不是因为快，是因为跳过了所有“看起来很专业但实际在绕弯”的环节。

这方法论没有门槛，不需要博士学历，但需要一种近乎固执的习惯：每当听到“我们一般这么做”“业界都用这个模型”“上次项目也是这么跑的”，就立刻暂停，拿出一张纸，写下三个问题：

1. 这个任务要解决的最原始业务痛点是什么？（不是“建个模型”，而是“让客服响应超时率下降15%”）
2. 支撑这个痛点被解决的不可替代的事实依据是什么？（不是“有用户行为日志”，而是“客服系统每分钟产生127条未分配工单，其中83%来自APP端，且62%的工单在创建后3分钟内无响应”）
3. 当前方案中，哪一步可以被物理定律或数学公理直接证伪？（比如用线性回归预测用户生命周期价值，却忽略LTV天然具备右偏长尾分布这一统计学铁律）

它不保证结果惊艳，但能确保每一分力气都砸在刀刃上。下面我会用两个真实项目——一个电商实时推荐优化，一个制造业设备故障预测——完整还原我是如何用这套方法，把模糊需求变成可执行、可验证、可复用的技术路径。

2. 第一性原理的底层逻辑：为什么它不是“换个说法”，而是重构整个工作流

2.1 从亚里士多德到特斯拉工厂：第一性原理的本质是“去中介化”

很多人误以为第一性原理就是“多问几个为什么”，这是典型误解。亚里士多德在《形而上学》里定义第一性原理（archē）时强调：“它是事物存在的起点，自身不再依赖其他前提而成立。” 翻译成工程师语言：所有中间层抽象（框架、库、行业惯例）都是可抛弃的临时脚手架，唯一不可删减的是问题本身与物理/数学/业务世界的硬约束。

举个例子：2022年我参与某新能源车企的电池健康度预测项目。初始需求文档写着“用LSTM建模电压-温度-电流时序数据，预测剩余寿命RUL”。团队立刻拉起PyTorch环境，调参两周后AUC达到0.89，但产线工程师指着报告摇头：“这个模型说电池还能用2000次充放电，但我们拆解发现第1850次就出现微短路——你们的‘2000次’和我们的‘拆解实测’根本不在同一个坐标系里。”

问题出在哪？不是模型不行，是任务定义被中介化了：

• 业务原始诉求：避免电池在质保期内突发失效（硬约束：失效即安全事故，零容忍）
• 中介化表达：预测RUL（软指标，不同算法定义不同）
• 技术进一步中介：用LSTM拟合时序（隐含假设：时序模式稳定可学习，但实际产线电池老化受批次工艺、环境湿度等非时序变量强干扰）

用第一性原理重构：

1. 锚定原子事实：电池失效的物理本质是“内部隔膜击穿导致正负极短路”，其前置可观测信号是“充电末期电压平台期出现异常毛刺波动”（实验室已验证，误差<±3次循环）
2. 剥离中介层：放弃“RUL预测”这个黑箱目标，改为“检测电压毛刺波动是否超过安全阈值”
3. 重建技术路径：不用深度学习，改用滑动窗口+小波变换提取毛刺特征，配合规则引擎判断——开发周期从14天压缩到3天，线上误报率下降67%，且产线工程师能直接看懂每条告警对应的物理意义。

提示：第一性原理不是反对使用先进模型，而是反对未经验证的抽象迁移。就像造火箭，SpaceX不是否定航空发动机原理，而是拒绝接受“火箭必须用航天级合金”这个行业中介结论，转而用不锈钢在低温下强度反而提升的物理事实，重新计算材料方案。

2.2 数据科学任务的“原子事实”拆解四象限

我把数据科学任务拆解为四个不可再分的原子层，每个层都有明确的验证标准。实践中，90%的项目卡点都源于某一层未夯实：

这个四象限不是理论模型，而是我每天开工前的必填检查表。去年帮一家社区团购公司做履约时效优化，他们抱怨“骑手超时率高”，初始方案是建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，引入更多用户画像特征。我接手后没碰代码，先做了三件事：

1. 下载最近7天全量曝光日志，用SQL统计“曝光-点击”漏斗各环节转化率
2. 抽样1000个被推荐用户，人工回溯其最近3次购买行为
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。

工程层最小实现单元

将系统拆解为三个可独立部署的原子服务：

1. 注意力感知服务：接收用户UA+屏幕尺寸+滚动速度，实时计算当前有效注意力窗口
2. 向量检索服务：根据用户最近搜索词，从Redis向量库召回Top100商品
3. 规则融合服务：将向量检索结果，按历史点击率排序，截取前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模拟iPhone13（812px高）、Android中端机（720px高）两种主流屏幕，测量商品卡片高度（含间距）为220px，计算得K=3（812/220≈3.69→向下取整）。若设K=4，第四张卡片仅露出10%高度，用户无法识别。
• 注意力窗口（1850ms）：基于眼动仪数据，用户从进入页面到首次眼球移动的平均潜伏期为320ms，加上视觉识别商品所需平均时间1530ms（实验室用Fitts' Law计算得出）。
• 向量检索TopK=100：不是越大越好。实测当TopK>80时，语义相似度得分衰减曲线趋平（Δscore<0.01），且Redis内存占用激增47%。

上线过程中的“反直觉”发现

灰度发布时，我们发现一个有趣现象：当用户滚动速度>1.2px/ms时，系统自动切换为“瀑布流模式”（无限滚动），此时首屏点击率反而提升至28%。原因在于高速滚动用户往往是“目标明确型”，他们需要的是快速定位，而非个性化推荐。于是我们新增原子规则：

• 若scroll_v > 1.2，则首屏展示用户最近搜索的3个品类下销量Top1商品（完全去个性化，靠确定性胜出）
• 若scroll_v ≤ 0.3（缓慢浏览），则启用完整语义+点击率融合排序

这个规则没有复杂模型，但AB测试显示，对高速滚动用户，点击率提升41%（从11%→15.5%），因为消除了“猜你喜欢”的认知负荷。

效果验证与业务影响

上线4周后核心指标：

更重要的是可解释性提升：运营人员现在能直接查看“为什么这个用户看到这个商品”——因为他的搜索词是“新生儿奶瓶”，而该商品在语义空间中距离最近，且历史点击率达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-12kHz，1Hz采样违反奈奎斯特采样定理，注定丢失关键信息。
• 校准漂移：温度传感器每季度需校准，但系统未记录校准时间戳，导致历史数据存在系统性偏差。

解决方案：

• 强制升级振动传感器采样率至20kHz（满足12kHz信号的2.5倍过采样）
• 在数据库增加calibration_timestamp字段，每次校准后写入，并在查询时自动应用校准系数

逻辑层：用物理定律替代统计模型

放弃“用历史故障数据训练LSTM”，转而构建基于物理方程的异常检测器：

• 压力漂移检测：冲压机液压系统遵循帕斯卡定律，正常工况下压力变化率dP/dt应服从高斯分布（σ=0.02MPa/s）。我们用滑动窗口（10秒）实时计算dP/dt，若连续3个窗口超出μ±3σ，则报警。
• 温度-压力耦合检测：根据理想气体状态方程PV=nRT，温度升高时压力应同比例上升。我们计算实时P/T比值，若偏离历史均值±2%超5分钟，判定热交换系统异常。
• 振动频谱分析：对20kHz采样数据做FFT，聚焦8-12kHz频段能量，若该频段能量占总能量比>15%（历史故障数据统计阈值），则触发二级预警。

所有逻辑均可在边缘网关（NVIDIA Jetson）上用C++实时执行，延迟<10ms。

工程层：最小可行部署单元

系统拆解为三个物理隔离的原子模块：

1. 边缘采集模块：直接对接PLC，以硬件中断方式读取传感器，避免OS调度延迟
2. 实时计算模块：在Jetson上运行，输入原始ADC值，输出结构化告警事件（含时间戳、参数、置信度）
3. 中心协同模块：接收边缘告警，结合MES系统工单数据，判断是否需停机（如：当前工单为高精度件，则立即停机；若为试模件，则降速运行）

接口协议极简：

// 边缘模块输出事件 { "device_id": "press_001", "timestamp": 1678886400123, "alert_level": 1, "params": ["pressure_drift"], "confidence": 0.94 }

4.3 实施细节与避坑指南

关键参数的物理推导过程

• 压力变化率阈值（0.02MPa/s）：基于液压系统动态响应模型。冲压机液压缸容积V=0.5m³，油液压缩系数β=0.5×10⁻⁹ Pa⁻¹，理论最大压力变化率dP/dt = Q/(βV)，其中Q为泵流量（实测120L/min=0.002m³/s），代入得dP/dt_max ≈ 0.008MPa/s。取3倍标准差（0.02MPa/s）作为报警阈值，留足安全余量。
• P/T比值阈值（±2%）：根据设备铭牌参数，额定工况下P=12.5MPa，T=65℃，计算理论P/T=0.1923。实测1000小时数据，该比值标准差为0.0032，故±2%（0.0038）覆盖99.7%的正常波动。

现场部署的“土办法”经验

• 传感器接地干扰：工厂电磁环境复杂，振动传感器信号常被50Hz工频干扰。我们没用昂贵滤波器，而是将传感器外壳与设备地线用10mm²铜缆直连，并在ADC前端加RC低通滤波（R=1kΩ, C=10nF），实测信噪比提升22dB。
• 边缘计算资源限制：Jetson内存仅4GB，无法运行完整FFT。我们采用“分段FFT+峰值检测”：每2048点做一次FFT，只保留8-12kHz频段的幅值，丢弃相位信息，内存占用从1.2GB降至86MB。
• 告警疲劳治理：初期误报多因设备启停机过程参数剧烈波动。我们加入“工况状态机”：PLC发送machine_status（0=停机，1=空载，2=负载），只在status=2时启用全部检测逻辑。

效果与产线反馈

上线3个月后：

• 一级预警准确率：92.3%（人工确认超限）
• 故障预测提前量：平均提前4.2小时（满足72小时要求）
• 误报率：从65%降至8.7%
• 关键成果：避免2次重大批量不良（预估止损380万元）

产线班组长反馈最有价值的不是技术，而是告警信息可直接指导操作：“压力漂移超限”意味着“检查液压油泵密封圈”，“P/T比值异常”意味着“清洁冷却器散热片”。这不再是IT部门的神秘输出，而是维修工能立刻行动的指令。

注意：我们始终保留传统定期检修制度。第一性原理不是取代专家经验，而是让专家经验聚焦在真正需要判断的环节——比如当系统报警“振动频谱异常”，维修工只需用听诊器确认异响来源，无需再花2小时排查所有可能部件。

5. 常见问题与实战排错手册

5.1 “第一性原理太慢，项目周期等不了！”——我的应对策略

这是最常被质疑的点。我的回答是：表面的“快”是用后期返工时间换来的，第一性原理的“慢”是用前期确定性换来的。以下是我在不同场景下的加速策略：

• 紧急救火项目（如线上事故）：跳过完整四象限，直奔数据层原子校验。例如某支付系统突然出现0.3%的订单重复扣款，传统做法是查日志、看代码、重启服务。我第一反应是：

  1. 抽样100笔重复订单，检查order_id是否真的重复（排除日志打印错误）
  2. 检查payment_time时间戳精度（是否毫秒级，避免同一秒内多笔订单ID冲突）
  3. 验证幂等key生成逻辑（是否包含order_id+timestamp，而timestamp精度不足）
     结果发现是MySQL时间戳精度为秒，导致并发请求生成相同幂等key。修复仅需1行代码（改用microsecond），30分钟上线。

• 长期战略项目（如AI平台建设）：用“原子验证闭环”替代大步快跑。例如构建企业知识图谱，不追求一次性建成，而是：

  1. 选定1个高价值原子关系（如“供应商-原材料-质量标准”）
  2. 用手工标注100条数据，训练最小模型
  3. 部署到采购系统，让采购员每天验证5条预测结果
  4. 根据反馈迭代，直到准确率>95%，再扩展下一个原子关系
     这样6个月建成的图谱，业务采纳率100%，而同期另一个“全量构建”的项目，因无法解释结果，被采购部拒用。

• 资源受限项目（如单人负责）：聚焦业务层+数据层，放弃复杂建模。某SaaS公司让我优化销售线索评分，我拒绝建模型，而是：

  1. 与销售总监一起梳理：哪些线索最终成单？共性是什么？（发现92%成单线索在24小时内有2次以上官网产品页访问）
  2. 直接用SQL写规则：if (product_page_views_24h >= 2) then score = 80 else score = 20
  3. 将规则嵌入CRM，销售反馈“比原来AI模型更准，因为我知道它为什么给高分”

实操心得：永远问自己——“这个问题的最小可验证单元是什么？我能否在1小时内证明它成立或不成立？” 如果答案是否定的，说明还没找到原子事实。

5.2 “业务方说不清需求，怎么拆解？”——三步破冰法

业务方模糊是常态，关键是如何引导。我用“三步破冰法”：

1. 用损失具象化替代目标描述
   不问“你想要什么”，而问：“如果这个问题不解决，下个月财务报表上哪个数字会变？变多少？”

   • 错误示范：“我们要提升用户留存”
   • 正确引导：“如果次月留存率从35%降到30%，公司会损失多少收入？这笔钱会花在哪儿？”
     （通常得到：“每月少赚200万，主要影响市场投放ROI”）

2. 用数据反推替代主观判断
   不依赖业务方回忆，直接看数据：

   • “请提供最近30天，所有被标记为‘高价值’的用户操作日志”
   • “导出过去半年，所有被销售手动标记为‘意向强烈’的线索，以及他们后续的成单时间”
     数据会暴露真实行为模式，比访谈更可靠。

3. 用最小原型验证替代方案讨论
   不做PPT讲方案，而是：

   • 用Excel做100行模拟数据，演示核心逻辑
   • 用Postman调用现有API，拼出一个可交互的demo界面
   • 甚至手绘流程图，让用户当场修改箭头方向
     行动比语言更能暴露认知盲区。

去年帮一家连锁药店做会员复购预测，店长说“想要知道谁会来买药”。我请他现场挑10个老顾客，我用POS系统查他们过去6个月购药记录，发现：

• 7人固定每月15号买降压药
• 2人每季度初买维生素
• 1人无规律
  结论：复购不是“预测”，而是“定时提醒”。我们直接用CRM的短信模板，按药品周期自动发送用药提醒，复购率提升29%，成本为零。

5.3 “数据质量太差，拆解没意义！”——数据层攻坚七招

数据脏是借口，更是突破口。我的数据层攻坚清单：

1. 先找“黄金数据源”：不追求数量，找1个最权威的源头。如电商订单数据，ERP系统比订单中心数据库更可信（因ERP是财务记账依据）。
2. 用“反向验证”揪脏数据：查一笔已知成功的订单，逆向追踪从用户下单→支付→库存扣减→物流发货的全链路，任一环节数据不一致即为脏。
3. 接受“脏数据即特征”：某物流公司的“预计送达时间”字段30%为空，我们没清洗，而是建特征is_estimated_time_null，发现该字段为空的订单，实际超时率高47%——这本身就是强信号。
4. 用物理约束过滤：