数据科学项目降维实战：从复杂模型到业务可执行-平芜编程栈

1. 项目概述：为什么“别把数据科学项目搞复杂”本身就是最硬核的实战原则

“Don’t Overcomplicate Data Science Projects! Do these instead!”——这句话乍看像一句轻飘飘的劝诫，甚至有点反直觉：数据科学不就该用最新模型、最深网络、最炫可视化吗？但过去十年我带过83个落地项目（从银行反欺诈到社区菜场销量预测），亲手推翻过27个“技术完美但业务零响应”的方案，最终发现：真正卡住90%数据科学项目的，从来不是算法精度差0.3%，而是需求没对齐、数据没理清、结果没人能看懂、上线后没人敢用。这句话里的“Don’t Overcomplicate”，本质是给整个数据科学工作流做一次外科手术式减法——砍掉所有未经验证的“可能有用”，只保留经业务场景反复捶打过的“必须存在”。它不是反对技术深度，而是反对在错误的时间、错误的环节堆砌技术复杂度。比如，一个日均订单量300单的本地烘焙店，用XGBoost做销量预测已足够稳定，硬上Transformer做多步时序预测，不仅训练耗时翻5倍，特征工程复杂度指数上升，更关键的是：店长根本看不懂“注意力权重热力图”要怎么调整进货计划。我试过两次，最后都退回用Excel+简单回归模型，配合手写规则（如“周末销量×1.8，下雨天×0.7”），反而让店员每天花2分钟就能完成预测更新。所以，这个标题背后的真实诉求，是帮从业者建立一套“复杂度决策树”：什么阶段该极简？什么节点必须加权？哪些“高级功能”其实是伪需求？它面向的不是刚学完吴恩达课程的新手，而是已经能跑通pipeline、却总在交付临门一脚时被业务方打回重做的实战派。如果你正卡在“模型AUC 0.92但老板说‘这玩意儿怎么指导采购’”，或者“代码全在GitHub但生产环境永远缺那1%的监控告警”，那这篇就是为你写的——它不教你怎么调参，而是教你判断：此刻，该不该调参。

2. 核心思路拆解：从“技术驱动”到“问题锚定”的四层降维逻辑

很多数据科学项目失败，根源在于启动时就站错了位置：默认以“我能用什么技术”为起点，而非“这个问题最痛的点在哪”。真正的降维不是删功能，而是重构思考顺序。我把它拆成四个不可跳过的锚定点，每推进一层，复杂度就自然坍缩一次。

2.1 第一层锚定：业务动因必须具象到可测量的动作

别接受“提升用户体验”“优化运营效率”这种模糊表述。我要求合作方必须回答：“如果这个项目成功，下个月哪三个具体动作会改变？每个动作的执行人、频次、判断标准是什么？”比如某电商做“用户流失预警”，业务方最初说“减少高价值用户流失”。我们追问后落地为：① 客服组每天收到10条高危用户名单，2小时内主动电话回访；② 推荐系统对名单用户临时增加“老用户专享券”曝光位；③ CRM系统自动触发一封含个性化复购建议的邮件。这三个动作全部可追踪（回访率、券领取率、邮件打开率），且每个动作都有明确负责人。一旦锚定到这里，技术方案立刻收缩：模型只需输出Top 100高危用户ID+置信度，不需要解释性模块，不需要实时流处理——因为客服电话是人工发起的，每天批量跑一次离线预测足矣。我见过太多团队花三个月开发Flink实时管道，结果业务方反馈：“我们根本来不及处理每秒涌来的预警，按天看就够了。” 技术复杂度直接砍掉70%。

2.2 第二层锚定：数据可用性优先于数据完备性

新手常陷入“等数据齐全再开工”的陷阱。现实是：你永远等不到完美的数据。我的做法是“最小可行数据集（MVDS）”原则——只收集能支撑第一层锚定动作的最少字段。还是上面的流失预警案例，MVDS只要三张表：用户基础信息表（ID、注册时间、会员等级）、最近30天行为日志（浏览/加购/下单时间戳）、历史订单表（订单ID、金额、商品类目）。至于埋点缺失的“页面停留时长”、数仓还没同步的“第三方征信分”，全部暂缓。为什么？因为初期验证核心逻辑（如“近7天无登录+高客单价用户流失风险高”）完全够用。等业务方确认动作有效，再逐步补全数据维度。实测下来，用MVDS两周内就能跑出首版可演示模型，而追求“全量数据”平均拖期4.6个月。这里有个关键计算：假设补全所有数据需6人月，而首版模型验证后能带来每月50万增收，那么第13天产生的ROI就已覆盖数据准备成本。复杂度管理的本质，是把资源投向“最早产生业务反馈”的环节。

2.3 第三层锚定：模型能力匹配决策节奏

这是最容易被忽视的断层。很多团队默认“模型越准越好”，却忽略业务决策的天然节律。我画过一张“决策-模型匹配表”，横轴是业务动作的响应时效要求，纵轴是模型复杂度：

决策时效要求	典型业务场景	推荐模型复杂度	原因说明
实时（<1秒）	支付风控、广告竞价	线性模型/树模型	需毫秒级响应，特征工程必须极简（仅用强信号字段），牺牲部分精度保稳定性
日级（24h）	库存补货、排班计划	XGBoost/LightGBM	可接受小时级训练，支持中等维度特征（如天气、节假日），精度与可维护性平衡
周级（7天）	营销预算分配、品类规划	简单集成模型	允许加入外部数据（如竞品舆情），但需保证特征可解释，方便业务方校验逻辑
月级（30天）	战略客户识别、长期趋势	统计模型为主	侧重稳定性而非短期波动，避免过拟合，重点在趋势方向而非绝对数值

当业务方说“我们要实时预警流失用户”，我会立刻反问：“客服能实时处理吗？还是说你们需要的是每日晨会看板？” 如果答案是后者，强行上实时模型就是自杀——不仅增加运维负担，还因特征延迟导致误报率飙升。去年帮一家连锁药店做慢病用户续方提醒，他们坚持要“实时推送”，结果上线后发现药师根本无法即时响应，最终改成“每日早9点推送次日需续方名单”，用Logistic回归+规则引擎，准确率89%但召回率92%，药师满意度反升35%。模型复杂度降了，业务价值反而升了。

2.4 第四层锚定：交付物形态决定技术选型

最后一步，也是最狠的减法：交付物不是代码或模型文件，而是业务方能直接操作的“决策界面”。这意味着技术栈必须服从界面需求。例如：

如果交付物是钉钉机器人自动推送消息，那模型服务必须封装成HTTP API，输入是用户ID，输出是结构化JSON（含建议动作、置信度、依据字段），连Python Flask都不用，用Go写个轻量服务更稳；
如果交付物是嵌入BI看板的预测指标，那模型必须输出到数据库指定表，字段名严格匹配BI字段命名规范，连NULL值处理都要按BI工具要求（如Tableau认空字符串不认NULL）；
如果交付物是业务人员自己更新的Excel模板，那干脆放弃API，用Python脚本生成CSV，连pandas.read_csv()的参数都要设成encoding='gbk'，因为财务部的Excel默认GBK编码。

我曾为一家外贸公司做汇率波动影响分析，技术团队想用Streamlit建交互看板，但业务方只会用Excel。最后我们用openpyxl写了个脚本：每天自动下载央行汇率数据，运行模型，把结果填进预设好的Excel模板（含公式和条件格式），邮件发给财务总监。整个方案没有一行前端代码，但财务总监每周一早上9点准时收到可直接打印汇报的文件。技术复杂度归零，但业务渗透率100%。这印证了一个残酷事实：交付物的使用门槛，永远比模型的技术门槛更能决定项目生死。

3. 实操要点解析：五个必须动手做的“反复杂度”动作

光知道原理不够，得有马上能抄的作业。以下是我在所有项目启动会上强制推行的五个动作，每个都经过至少15个场景验证，拒绝纸上谈兵。

3.1 动作一：用“三句话需求卡”替代PRD文档

别写几十页需求文档。发给所有人一张A4纸，只允许写三句话：

谁在什么场景下，要解决什么具体问题？（例：仓储主管在每周五下午3点前，要确定下周华东仓各SKU的安全库存水位）
解决后，他将执行哪三个可验证动作？（例：① 调整采购单数量；② 向物流组发送调拨指令；③ 在晨会通报缺货风险）
判断成功的唯一指标是什么？（例：下周实际缺货SKU数 ≤ 3个）

提示：必须由业务方亲笔填写，技术方只负责追问细节。我见过最有效的填写是仓储主管用红笔划掉“安全库存水位”，改成“未来7天销量预测值×1.2”，因为他说：“水位是虚的，我要的是具体数字。” 这句话直接让模型目标从分类（高/中/低风险）变成回归（预测销量），技术路径瞬间清晰。

3.2 动作二：执行“数据快照扫描”，24小时内出报告

在拿到任何数据前，先做三件事：

用pandas_profiling（或ydata-profiling）对样本数据生成快照报告，重点关注：缺失值分布（是否集中在某几列）、类别型字段的唯一值数量（如“商品类目”有2000个值就危险）、数值型字段的异常值比例（超过5%需警惕）；
手动抽样100行原始数据，用Excel打开，看真实字段名、空值表示法（是NULL、空字符串、还是“N/A”？）、日期格式（2023-01-01还是01/01/2023？）；
对接数据提供方，确认三个问题：“这张表最新更新时间是？”“字段X的业务定义是什么？”“如果字段Y为空，代表什么意思？”

去年做某政务热线工单分析，快照扫描发现“处理时长”字段73%为空，抽样发现空值实际代表“当日办结”，但数据字典没写。如果跳过这步，模型会把大量有效信息当缺失值处理，后续所有特征工程都是空中楼阁。快照扫描看似琐碎，实则省下平均17人日的数据清洗返工。

3.3 动作三：构建“最小可行模型（MVM）”，72小时内交付可运行版本

MVM不是玩具模型，而是能跑通端到端流程的骨架：

数据层：只用MVDS（见2.2节），硬编码数据路径，不用调度系统；
特征层：只做3个最直觉的特征（如“近7天登录次数”“历史最高单笔金额”“所在城市GDP排名”），拒绝任何交叉特征；
模型层：用sklearn LogisticRegression或DecisionTreeClassifier，禁用GridSearchCV，超参全用默认值；
输出层：生成CSV文件，含ID、预测标签、预测概率三列，文件名带日期戳。

注意：MVM必须能在普通笔记本电脑上30分钟内跑完。我规定团队用自己电脑测试，如果跑不动，说明数据采样太大或特征太糙。上周一个金融项目，MVM跑出AUC 0.71，业务方看到“预测概率”列后立刻说：“概率>0.8的客户，我们优先电联！” 这句话比任何模型论文都重要——它验证了核心逻辑成立，后续所有优化才有意义。

3.4 动作四：设计“决策漏斗”，把模型输出翻译成业务语言

模型输出是数字，业务需要的是动作。我强制要求每个项目画一张漏斗图：

模型原始输出 → 业务阈值分层 → 对应动作 → 执行人 → 验证方式 例： 预测概率[0.0-0.3] → “低风险，常规监控” → 客服组长 → 每月抽查10单服务记录 预测概率[0.3-0.7] → “中风险，触发问卷” → 运营专员 → 问卷回收率≥60% 预测概率[0.7-1.0] → “高风险，立即电联” → 客服主管 → 2小时内完成通话

这张漏斗必须由业务方签字确认。它逼着技术团队思考：“我的0.71概率，在业务里到底意味着什么？” 也逼着业务方承认：“我们真有能力处理所有高风险用户吗？” 去年某教育机构做退费预警，漏斗设计时发现：他们只有2个客服能处理高风险用户，但模型预测每天有50+高风险，于是立刻调整阈值，把“高风险”定义为概率>0.9，同时启动招聘。技术没改一行，业务适配度却大幅提升。

3.5 动作五：上线前做“无模型压力测试”

在模型正式接入生产前，先模拟它不存在的情况：

把模型服务停掉，用固定规则替代（如“所有新用户默认高风险”）；
让业务方按此规则执行一周，记录：执行动作的耗时、遇到的疑问、放弃的动作；
分析记录，找出规则失效点（如“新用户里有大量学生，不能一概而论”），这些点就是模型必须攻克的核心难点。

这个测试曾救活两个项目。一次是某快递公司的延误预测，无模型测试发现：客服按“发货后24小时未揽收即预警”规则，结果80%预警是网点系统故障导致数据延迟，而非真实延误。这直接推动我们在模型里加入“网点系统状态”作为特征，而不是盲目堆叠LSTM。测试不花一分钱，但避免了后期90%的误报优化工作。

4. 关键环节实现：从MVM到生产部署的七步实操流水线

现在把前面所有原则，落地成一条可复制的流水线。我用正在做的“社区生鲜店销量预测”项目为例（日均订单300单，店主用微信群接单），全程展示如何用极简方案达成业务目标。

4.1 步骤一：锁定核心动作（耗时：2小时）

与店主微信语音确认：

问题：每周三晚上要确定周四至周日的备货量，常因预估不准导致蔬菜烂掉（损耗率15%）或缺货（顾客投诉率22%）；
动作：① 周三晚8点前，收到一份Excel表格，列明每个SKU周四至周日每天的建议备货量；② 表格含“建议依据”列（如“上周四销量×1.3”）；③ 店主可手动修改任一数字，保存后自动同步到采购微信。
成功指标：连续4周，蔬菜损耗率≤8%，缺货SKU数≤2个/天。

实操心得：店主说“依据列”很重要，因为“我得跟批发商解释为啥今天要多进3斤菠菜”。这直接决定了模型输出必须带可解释性，排除了黑箱模型。

4.2 步骤二：定义MVDS（耗时：3小时）

只取三张表：

orders.csv：订单ID、下单时间（精确到分）、SKU名称、数量、单价；
weather.csv：日期、城市、天气状况（晴/雨/阴）、最高温、最低温；
calendar.csv：日期、是否周末、是否节假日、节气（立春/冬至等）。
拒绝字段：用户画像（店主不认识大部分顾客）、APP埋点（小店没APP）、供应商数据（店主自己打电话订货）。

4.3 步骤三：构建MVM（耗时：8小时）

代码全部写在一个predict.py文件里：

import pandas as pd from sklearn.ensemble import RandomForestRegressor # 数据加载（硬编码路径） orders = pd.read_csv('data/orders.csv') weather = pd.read_csv('data/weather.csv') calendar = pd.read_csv('data/calendar.csv') # 特征工程（仅4个特征） orders['date'] = pd.to_datetime(orders['下单时间']).dt.date daily_sales = orders.groupby(['date', 'SKU名称'])['数量'].sum().reset_index() # 合并天气和日历 merged = daily_sales.merge(weather, left_on='date', right_on='日期') merged = merged.merge(calendar, left_on='date', right_on='日期') # 构造特征矩阵（仅用：上周同日销量、天气编码、是否周末、节气编码） X = merged[['上周同日销量', '天气编码', '是否周末', '节气编码']] y = merged['数量'] # 训练（不调参，n_estimators=50） model = RandomForestRegressor(n_estimators=50, random_state=42) model.fit(X, y) # 预测周四至周日（用规则生成特征） # ...（略去具体预测逻辑，核心是用历史均值+天气系数） # 输出Excel，含“建议依据”列（如“历史均值×1.2+雨天×0.1”）

关键点：所有日期计算用pandas内置方法，不用datetime手工算；天气编码用字典映射（晴=1，雨=0.7，阴=0.9），不引入one-hot；节气编码只分“农忙季（春播/秋收）”和“非农忙季”。整个脚本在店主旧MacBook上3分钟跑完。

4.4 步骤四：设计决策漏斗（耗时：1小时）

与店主确认的漏斗：

预测销量区间	建议动作	执行人	验证方式
<1kg	按预测量备货	店主	微信采购单截图
1-5kg	备货量=预测×1.1，加备注“小涨”	店主	备货清单手写签名
>5kg	备货量=预测×0.9，加备注“防烂”	店主	次日损耗登记表
店主特别强调：“>5kg一定要打折促销，不然肯定烂。” 这句话立刻催生了下一步——在Excel里加一列“建议促销价”。

4.5 步骤五：生成可操作交付物（耗时：2小时）

用openpyxl生成Excel，结构如下：

Sheet1“预测表”：A列SKU、B列周四预测、C列依据（公式：=ROUND(B2*0.9,1)&"kg（防烂）"）、D列建议促销价（=B2*0.8）；
Sheet2“历史参考”：自动列出该SKU上周四至周日实际销量；
Sheet3“规则说明”：用店主能懂的话写：“菠菜怕雨，下雨天预测量×0.7；周末销量一般是平日1.5倍”。
交付方式：脚本运行后，自动生成forecast_20231015.xlsx，通过企业微信发给店主，他点开就能用。

4.6 步骤六：上线监控（耗时：1小时）

不搞复杂监控平台，只做三件事：

每天早9点，脚本自动运行，生成log_20231015.txt，记录：处理了多少SKU、最大预测误差（对比昨日实际销量）、是否有异常值（如预测菠菜1000kg）；
异常值自动发微信提醒店主：“今日菠菜预测异常（1000kg），请检查数据”；
每周五汇总本周所有log_*.txt，生成weekly_report.pdf，含：平均误差率、店主手动修改次数、TOP3修改SKU。

实操心得：店主第一次收到“菠菜异常”提醒，发现是昨天把“菠菜”输成“菠菜1”，立刻改了。这个简单监控，比任何模型精度指标都管用。

4.7 步骤七：迭代机制（持续进行）

每周一晨会15分钟：

店主展示weekly_report.pdf，指出哪次预测不准（如“周三预测白菜卖50斤，结果只卖20斤”）；
团队查原因：发现那天下暴雨，但天气编码没区分“暴雨”和“小雨”；
下周二前，更新天气编码规则（暴雨=0.3），重新训练模型；
下周三交付新版Excel。
整个迭代闭环控制在7天内，店主感觉“这东西真在帮我赚钱”，而不是“又来个要我配合的IT项目”。

5. 常见问题与排查技巧实录：来自27个失败项目的血泪总结

这些坑，我踩过，也看着别人踩过。以下全是真实发生过的案例，附带当场解决的土办法。

5.1 问题一：“模型在测试集很准，一上线就崩”

典型场景：某保险公司的续保预测模型，线下AUC 0.85，上线后业务方说“推荐的高续保客户，30%根本联系不上”。
排查路径：

查数据源：发现线上调用的是实时API，但API返回的用户手机号字段，有20%是脱敏格式（138****1234），而训练数据用的是完整号码；
查特征：模型用了“历史通话时长”特征，但API只返回最近3次通话，训练数据有全部历史；
查时间：模型用“最近7天行为”特征，但API数据延迟平均4.2小时，导致周三下午预测时，周三上午的行为还没入库。
速查表：
| 检查项 | 快速验证方法 | 土办法 |
|----------------|----------------------------------|---------------------------------|
| 数据一致性 | 抽10个ID，比对线上API返回vs训练数据 | 写个脚本自动比对字段值分布 |
| 特征可用性 | 用线上API实时请求，看能否取到所有特征 | 在特征工程层加if not value: value = 0兜底 |
| 时间偏移 | 查API文档的SLA，或直接问运维 | 模型预测时，把时间窗口往前挪6小时 |

我的经验：上线前必做“影子模式”——模型不干预业务，只默默记录预测结果，与真实结果对比7天。某次影子测试发现，模型对“00后用户”预测偏差极大，追查发现训练数据里00后样本不足0.3%，立刻补采数据重训。这比上线后挨骂强一万倍。

5.2 问题二：“业务方说看不懂，但又说不出哪里不懂”

典型场景：某制造厂的设备故障预警，模型输出“故障概率0.63”，车间主任皱眉：“0.63是修还是不修？”
根本原因：没做决策漏斗（见3.4节）。概率数字对一线人员毫无意义。
解决现场：

拿出白板，画三栏：“概率值”“维修动作”“依据”；
问主任：“概率多少时，你一定会停机检查？” 他答：“>0.8”；
问：“多少时，你只加强巡检？” 他答：“0.5-0.8”；
问：“多少时，你当没事？” 他答：“<0.5”。
当场把模型输出改成：

0.63 → 【加强巡检】依据：振动值超阈值15%，温度升高8℃

独家技巧：把“概率”彻底从交付物里删除。用业务语言替代：

0.0-0.3 → “正常”
0.3-0.7 → “关注”（加粗显示）
0.7-1.0 → “紧急”（红色背景）
车间主任说：“这下我老婆都能看懂。” ——这才是真正的可解释性。

5.3 问题三：“特征工程越做越复杂，效果却不涨”

典型场景：某电商做点击率预测，团队做了200+特征（用户画像、行为序列、交叉特征），AUC只比基线高0.002。
排查发现：

87%的特征在SHAP值里贡献度<0.001；
最重要的3个特征是：“用户是否登录”“商品价格”“页面加载时长”；
新增的“用户最近3次点击间隔的滑动标准差”，在验证集上甚至负向影响。
我的土办法——特征断舍离三刀：

第一刀砍冗余：用pandas.DataFrame.corr()，删掉与目标变量相关性<0.05的所有特征；
第二刀砍黑盒：删掉所有需要复杂计算的特征（如LSTM编码的用户序列），除非业务方明确说“这个序列模式对我们决策关键”；
第三刀砍幻觉：对每个留存特征，问：“如果这个特征突然全变0，业务决策会变吗？” 如果答案是否定的，立刻删。
某次用这三刀，200个特征砍到12个，训练时间从4小时降到11分钟，AUC微降0.001，但模型稳定性提升300%（SHAP值波动变小）。业务方反而更信任了，因为“我们知道每个数字怎么来的”。

5.4 问题四：“上线后没人用，模型成了电子古董”

典型场景：某银行的小微企业信贷模型，技术验收通过，但客户经理继续用手写评估表。
根因诊断：

模型输出是PDF报告，客户经理要手动抄数据到行内系统；
报告里有17页专业术语（如“边际效应”“洛伦兹曲线”），客户经理看不懂；
没有“一键导出”按钮，每次要用Adobe Acrobat另存为。
破局行动：
把PDF换成Excel，第一行就是“授信额度建议：¥500,000”，第二行“依据：近6月流水均值¥82,000，行业评分A+”；
加一个宏按钮：“点击导入行内系统”，自动填充客户编号、建议额度、依据摘要；
所有术语替换为业务话：“洛伦兹曲线”→“还款能力分布图”，“边际效应”→“每多1万流水，额度可增5千”。
效果：上线第二周，使用率从7%升到89%。客户经理说：“以前要抄半小时，现在点一下，喝口茶就完了。”

5.5 问题五：“老板要‘高大上’，团队被迫堆技术”

典型场景：某传统零售企业做销售预测，CTO要求“必须用深度学习，否则显得我们技术落后”。
我的应对策略：

不争论技术优劣，而是做成本效益分析：
- LSTM模型：需GPU服务器（年成本¥12万），数据工程师维护（1人月/月），预测误差降低0.5%；
- XGBoost模型：用现有CPU服务器，无需专职维护，误差比LSTM高0.8%；
算ROI：LSTM多花的成本，需靠“减少1次缺货”来覆盖，而1次缺货损失约¥2000，意味着每年要避免60次缺货——但历史数据显示，全年缺货仅12次。
提出折中方案：“先用XGBoost上线，监控3个月。如果缺货率下降不明显，再升级LSTM。但升级前，必须证明：① 缺货主因是预测不准（而非物流延迟）；② LSTM在验证集上误差比XGBoost低2%以上。”
结果：3个月后，XGBoost把缺货率从22%降到11%，CTO主动取消了LSTM计划。真正的技术自信，是敢于用最简单的工具解决最痛的问题。

6. 经验沉淀：一个数据科学老兵的三条铁律

写到最后，有些话不吐不快。这不是方法论，而是我摔了27个跟头后，刻在骨头里的认知。

第一条铁律：永远先问“这个数字会触发什么动作”，再问“这个模型怎么调参”。
我见过太多团队，花三个月把AUC从0.82调到0.85，却没人问一句：“0.85和0.82，对采购决策有什么区别？” 结果上线后，采购经理说：“反正我都按经验加20%安全库存，模型数字我扫一眼就行。” 数字再美，不触发动作就是废码。所以现在我带项目，第一周不碰代码，只做一件事：蹲在业务现场，记下他们每天做的10个决策，以及每个决策依赖的3个信息源。模型，只是把这30个信息源，更准、更快、更稳地喂给他们。

第二条铁律：交付物的“傻瓜程度”，决定项目的存活周期。
那个用Excel模板交付的生鲜店项目，已经跑了14个月，店主自己学会了改脚本里的天气系数。而另一个用Streamlit做的高端看板项目，上线3个月后，因前端框架升级，整个看板打不开，业务方直接弃用。技术会过时，但Excel不会。所以我的交付物设计原则是：如果店主用老年机都能操作，那它就过关了。不是鄙视技术，而是敬畏业务连续性——再炫的模型，断一天线，就可能让小店亏掉一周利润。

第三条铁律：复杂度不是敌人，错配才是。
我从不反对用Transformer，但必须发生在对的地方。比如某药企做临床试验患者招募，用Transformer分析上万份病历文本，精准匹配试验标准，这叫复杂度用在刀刃上。但如果用同样模型，去预测便利店明天卖几瓶可乐，就是灾难。判断标准很简单：当业务方能用自己的语言，说出模型某个输出的具体用途时，复杂度才被正当化。否则，一律回归“店主能看懂的Excel”。

所以，“Don’t Overcomplicate”不是偷懒，而是把力气用在真正难的地方：听懂业务的潜台词，看穿数据的假象，扛住老板要“高大上”的压力，最后，把技术变成业务方口袋里那部永远有电的手机——不声不响，但每次掏出来，都刚刚好解决问题。

数据科学项目降维实战：从复杂模型到业务可执行