企业官网建设流程全解析

1. 从"业务要一个AI"到"案例模型"：绕不开的沉淀问题

先交代一下背景。我过去几年一直在帮各类企业做数据分析与建模落地，接触过大量所谓的"AI需求"。大多数需求长得很像：领导说我们要上预测、上智能补货、上风险识别，然后项目组开始拉数据、调模型、出报告，折腾三个月后交付一个"能跑但没人敢信"的模型。过半年再看，那个模型基本已经废弃，新来的人看不懂老代码，只好重新做一遍。我做过很多次这样的重造轮子，后来意识到问题不在建模能力，而在我们从来没有把案例沉淀成"模型"——不是指那个算法模型，而是指"一个完整案例的可复现样本"。

我在这里说的 AppML 案例模型，指的是 Application-oriented Machine Learning Case Model，也就是面向业务应用场景的机器学习案例模型。它是把一类业务问题（比如销量预测、客户流失预警、设备故障识别）从业务定义、数据采集、特征加工、模型训练、评估上线，到运行监控的完整过程，整理成一套可以被快速复用的标准化结构。它回答的不是"这个项目的准确率是多少"，而是"如果我再遇到同类型问题，如何在三天内跑通一个合格版本"。

这篇文章要分享的，就是我在这套思路下沉淀出来的案例模型框架，以及一个完整的实操案例：某城市连锁便利店的单品销量预测。案例本身做了脱敏处理，数据结构和方法都是真实可复现的。如果你正在做机器学习落地，或者刚接手一个"老板说不清楚但希望很宏大"的数据项目，这篇文章应该能帮你少走不少弯路。

1.1 案例模型到底沉淀什么

很多人一想到"沉淀"就以为是写文档，实际上文档只是副产品。案例模型沉淀的是一整套可执行的资产：

• 问题定义模板：把模糊的业务诉求翻译成具体的预测目标。
• 数据口径说明：每个字段的定义、来源、更新频率、坑点。
• 特征加工代码：一套从原始表变成训练样本的可复用脚本。
• 模型训练管线：能一键从数据跑出模型的全流程。
• 评估报告框架：不同业务场景该看什么指标，阈值是什么。
• 监控指标与告警规则：模型上线后怎么判断它是否开始失效。

这几样东西组合在一起，才叫一个"案例模型"。它把一次性的项目经验变成了组织资产。实际执行时不需要每一样都做到完美，但至少要先有骨架，后续遇到新场景时往里面填内容。

1.2 谁最需要这套东西

如果你只是用现成平台做一次数据分析，或者跑一个 Kaggle 比赛，那不需要案例模型。案例模型适合以下几类人：

• 需要把机器学习能力复制到多个门店、多个产品线、多个客户群的业务分析师。
• 团队里数据工程师、算法工程师、业务方经常因为口径不清而反复扯皮的公司。
• 老板希望"每个业务线都能用上AI"但预算和人力有限的中小团队。

对这些场景来说，代码跑通只是开始，真正要解决的是"换了个数据源怎么快速适配""新同事接手需要多久""业务侧换了个KPI我们的模型还成不成立"这一类问题。案例模型就是用来回答这些问题的。

2. 案例模型的四层骨架：用工程语言给业务问题建模

把案例拆开看，其实只有四层：目标层、数据层、特征层、模型与评估层。大多数项目做不好，是因为把这四层混在一起，动不动就跳层。业务方说"我要预测销量"，建模的人直接开始翻数据，翻了两天发现数据对不上，再回头问业务方"你说的销量到底按订单算还是按出库算"。这种来回扯皮浪费的时间，比建模本身多得多。

2.1 目标层：业务语言到模型目标的翻译

我在目标层做三件事。

第一，把业务诉求写成一句话。例如"缺货率要降低30%""未来一周每个门店每个SKU的补货量要更准"。这句话必须是业务方承认的、可以用数字衡量的。

第二，把这一句话拆成可计算的预测目标。预测目标不一定只有一个。比如补货问题，可以预测未来7天总销量，也可以预测未来每一天的销量，甚至预测某个SKU在某天缺货的概率。不同目标对后续逻辑的影响非常大，必须在这一步定清楚。

第三，明确成功标准。我一般会让业务方回答一个问题："模型做完之后，你怎么知道它成功了？"如果业务方说"感觉准了"，那这个项目大概率会烂尾。必须逼他给出可量化的指标，比如缺货率下降几个百分点、库存周转天数减少几天。

下面用一个表格展示目标翻译的几种常见方式：

这里有些读者可能对 WAPE、NDCG 这些英文缩写不熟。WAPE 是加权绝对百分比误差，通俗说就是"总预测误差占真实总量的比例"，0.3 意味着整体误差三成左右。NDCG 是排序质量指标，1 是完美排序，0 是乱序，线上推荐一般做到 0.6 以上算合格。

2.2 数据层：数据契约是隐形地基

目标定完后最不该急着建模，而是先写数据契约。数据契约不是数据字典，它比数据字典多了"这里有个坑"的说明。

以销量预测为例，一张订单明细表的字段可能长这样：

数据契约必须由数据工程师、算法工程师、业务方三方确认。实际执行时有一个小技巧：找业务方要最近三个月的原始数据，手工汇总一遍，看结果和业务方自己系统里的报表数字能不能对上。对不上，就先解决对不上的问题，永远不要带着脏数据建模。我见过太多项目死在这一步。

2.3 特征层：从原始数据到可用信号

特征工程听起来很玄，本质上就是回答一个问题：哪些信息可以帮助预测未来？

我梳理特征时有一个固定的思维清单：

• 历史表现：过去7天、14天、30天的销量均值、中位数、最大值、趋势斜率。
• 业务节奏：星期几效应、月初月末、节假日前后。
• 外部扰动：天气、温度、空气质量、周边是否有大型活动。
• 商品自身属性：品类、规格、价格带、是否新品。
• 门店属性：门店面积、商圈类型、客单价水平。

注意，特征不是越多越好。我在特征层最看重的四件事：有效性、稳定性、可得性、时效性。很多团队喜欢堆上千个特征，结果上线后上游数据晚了两小时，特征加工就要跑四小时，根本来不及。所以案例模型里对每个特征都要标注"加工耗时"和"更新频率"，能实时算的尽量实时，不能实时算的用滞后值。

2.4 模型与评估层：先建基线，再谈优化

模型层的第一个原则是：先有基线，再上复杂模型。所谓基线，就是"什么也不学"也能得到的预测，最常用的基线是"最近14天同星期均值"。基线的存在意义是给所有后续模型划一条及格线。如果你的 XGBoost 比基线还差，说明问题出在数据或特征上，而不是模型不够高级。

评估层的第二个原则是：训练集、验证集、测试集必须按时间切分，不能随机切分。很多新手在这里踩坑：随机切分样本导致训练集里包含了未来的信息，测试集里也混入了过去的数据，线上表现一塌糊涂。

我用时间序列场景做案例时，一般按这样切分：

• 训练集：过去 12 个月数据。
• 验证集：最近 1 个月数据，用于调参。
• 测试集：最近 2 周数据，只用于最终评估一次。

这看起来很简单，但真正执行时需要把特征加工完全放入时间窗口内，不能有一丁点"未来信息"。这一点我在后面第 4 章会专门讲踩坑过程。

3. 一个最小化完整案例：便利店门店SKU未来7天销量预测

下面用一个完整案例把上面的骨架串起来。这个案例来自我实际参与过的一个连锁便利店项目，数据经过了脱敏和简化，但逻辑完全保留。

3.1 业务背景与数据口径

业务方是某城市一家拥有 80 家门店、SKU 数量约 3500 个的连锁便利店。痛点有两个：缺货率在高峰期达到 12%——这意味着十次购物有一次买不到想要的商品；同时部分门店的临期损耗每年要报废大量商品。业务方希望建立一套智能补货辅助系统，至少能给出"未来7天每个门店每个SKU的预计销量"，供门店店长和供应链采购参考。

数据范围方面，案例只使用下面几类数据，不做过度扩展：

• 门店信息：门店ID、门店面积、商圈类型（写字楼/社区/学校/混合）、是否24小时营业。
• 商品信息：SKU ID、品类、零售价、是否生鲜、是否新品。
• 销售流水：订单ID、门店ID、SKU ID、销售数量、下单时间、销售金额。
• 营销信息：是否参与促销、促销折扣力度、是否新品推广期。
• 外部天气：每日最高温、最低温、是否降雨、空气质量指数。

口径上，销量只统计正数订单，退款单单独拆分出来。日期统一按自然日统计，当日最后一条订单时间到 23:59:59 都算当天。所有数据处理脚本都写在一份etl.py里，保证任何人拿到同样数据能跑出同样结果。

3.2 特征体系设计

这个案例的特征体系我在第 2 章提到的思维清单基础上做了落地：

时间特征：

• 星期几（周一至周日）。
• 是否法定节假日（未来7天是否包含节假日）。
• 是否为节假日后一天。

历史销量特征：

• 过去7天、14天、30天的销量均值。
• 过去28天的销量中位数。
• 过去7天同星期的销量均值。
• 过去7天的销量趋势斜率（用最小二乘法算）。
• 过去7天零销量天数。

商品与门店特征：

• 门店过去30天总销量和总客流量。
• 品类在该门店过去30天的销量占比。
• 商品过去30天的价格弹性（价格变化与销量变化的比例）。

外部特征：

• 预测期第1天到第7天的天气预报温度。
• 预测期是否预报有雨。

这里要注意，天气预报在预测时是"未来信息"，但它可以提前两天获得，属于可实时获取的合法特征。真正危险的是把"当天实际天气"当特征去预测当天销量，这在线上根本取不到，但很多数据集里容易不小心泄露。

3.3 基线模型、线性模型与树模型的对比

为了体现"案例模型"的对比逻辑，我同时跑了四类模型：

1. 基线 A：直接用"过去14天同星期的平均销量"作为未来7天每一天的预测值。
2. 基线 B：在基线 A 基础上乘以一个门店—品类的季节系数（比如该门店该品类在最近30天的环比增长比例）。
3. 线性回归：把特征直接喂给线性模型，按门店和SKU的ID做回归。
4. LightGBM：树模型集成，按时间序列切分训练集、验证集、测试集。

评估指标主要看 WAPE 和偏差率。WAPE 的公式是 total absolute error / total actual。偏差率则是 (预测总量 - 实际总量) / 实际总量，这个指标特别适合补货场景——偏差率为正意味着多订了货，为负意味着会缺货。

测试集上的结果如下（已简化处理）：

可以看到，LightGBM 在 WAPE 上比简单基线低了 14 个百分点，看起来效果好很多。但需要注意 LightGBM 的偏差率是 +0.01，也就是整体上几乎不偏，这背后其实是通过大量特征学习到的门店差异和SKU差异共同作用的结果。对业务方来说，只要 WAPE 小于 0.3，偏差率控制在 ±5% 以内，他们就有信心把模型结果作为补货参考。

3.4 模型上线与决策闭环

模型上线不是把模型文件发到生产环境就完了。这个案例的上线方式是每天凌晨 2 点由调度系统拉取昨日销售流水、更新特征、生成门店 SKU 级别的未来 7 天预测表，写入业务数据库。店长可以在手机端看到一个补货建议值，系统会显示"预测销量、预测下限、预测上限、缺货风险等级"。

缺货风险等级的计算方式比较简单：

• 如果预测销量的 5% 分位数大于当前库存，系统标"建议补货"。
• 如果预测销量的 50% 分位数大于当前库存，系统标"紧急补货"。
• 如果当前库存已经大于预测销量的 95% 分位数的两倍，系统提示"减少补货"。

用分位数而不是单点预测做决策，是案例模型里一个很实用的经验。单点预测只给一个数，但业务决策需要的其实是风险区间。我在实际项目中发现，决策层非常买单这种做法，因为它让系统看起来像"懂业务"，而不是一个黑盒子。

4. 沉淀过程中踩过的三个典型坑

案例模型之所以有价值，不完全是因为它成功的时候好用，更是因为它把失败过程也固化了。下面三个坑都是真实发生过的，建议读者仔细看。

4.1 时间窗错位让验证集变成了"透视图"

第一个坑是特征时间窗错位。当时我在做基线B的特征工程时，生成了一个"过去7天销量均值"的特征。训练集数据是从 1 月到 12 月，验证集是 1 月当月。看起来没有问题，但某一天我在检查特征分布时发现，验证集 1 月 5 日那条样本的"过去7天销量均值"竟然包含了 1 月 6 日到 1 月 11 日的销量——原因是在生成特征时用了整个数据集做窗口滑窗，而没有严格按照"每条样本都只能用这一时刻之前的数据"来生成。

这种问题不会导致训练时报错，模型照样能跑，WAPE 在验证集上漂亮得惊人，但上线后立刻被打回原形。排查方式其实很笨：随机抽几条验证集样本，手动按时间戳推导特征值，再和特征表里存的值比对。我强烈建议每个案例模型在数据管线里加入一个"时间戳严格性测试"，每次训练前自动随机抽样 100 条检查是否泄漏。

4.2 特征池里全是全局变量，门店个性被冲淡

第二个坑是过度使用全局特征。有一版我为了提高泛化能力，把门店、SKU 的特征全部做成了全局平均值，比如"全部门店过去30天平均客流量"。结果模型学出来的是一个"全国统一口味"的预测器——它对销量大的门店预测偏高，对销量小的门店预测又偏低，而那些真正有季节规律的门店根本没学到。

后来我改成每个门店、每个SKU都单独保留最近30天的统计量，并且加上门店、SKU的类别编码作为 categorical 特征，LightGBM 的效果才明显上升。这给我的经验是：在带ID类型的业务里，特征至少有一部分要按ID去分组生成，完全去掉个性信息等于把业务知识扔掉了。

4.3 模型卡片写了一大堆，却没有写"什么时候不能用"

第三个坑是关于模型维护的。案例模型沉淀时，我们给每个模型都写了一页模型卡片，内容包括业务目标、数据来源、特征列表、评估结果。听起来很完善，但后来新同事接手时，拿着模型卡片完全不知道怎么用，因为卡片里没有写"什么时候模型会失效"。

后来我把模型卡片改成从四个角度描述失效场景：

• 数据变化：门店突然闭店重开、商品改包装、换供应商。
• 业务变化：价格策略调整、促销节奏变化、商圈改造。
• 外部变化：极端天气频发、节假日调休。
• 模型自身：误差连续两周高于阈值、预测分布明显偏移。

这四条写下来之后，监控系统的告警规则才能落地。否则你根本不知道该监控什么，只能等业务方投诉"模型最近不准了"才知道出了问题。

4.4 版本管理与复现问题

还有一个很容易被忽视的坑是模型版本管理。很多人用文件名区分版本，比如model_v2_final_new.pkl，过两天又变成model_v2_final_new2.pkl。一旦需要回滚，根本不知道哪个版本对应的特征代码是哪个版本。我的做法是把模型、特征代码、数据版本绑在同一个 Git 提交里，每次训练跑完后自动记录结果。这样回滚时是整条链路一起回滚，而不是单独换一个模型文件。

5. 从第一个案例扩展到模型库的思考

打通第一个案例之后，很多人会问：接下来该怎么做？

5.1 先复制哪一类场景最合适

我建议先找和当前案例"底层结构相似"的场景。比如销量预测和门店客流量预测、库存补货和员工排班预测，它们都有时间序列结构，特征体系也相似，复制成本很低。反过来，风险识别这种分类问题虽然目标类型不同，但特征加工和数据契约的框架是通用的，可以第二波再做。

一个简单的判断标准是：数据源是不是已经在同一个数仓里？业务方是不是同一个团队？如果是，复制起来比想象中快。我在实际项目中，第二个案例（门店客流预测）从立项到上线只用了三周，因为大部分数据管道直接复用了销量预测案例的代码。

5.2 配套的监控与重训节奏

案例模型库不是建完就完，还需要有明确的运行规则。我的建议是：

• 每周自动评估一次线上误差，和测试集基线对比。
• 每月做一次完整重训，用最近三个月数据拟合。
• 每次重训后对比新旧版本在验证集上的指标，如果新版本没有明显优势，继续保留旧模型，不盲目替换。

重训不是越频繁越好，因为业务季节性和节假日周期需要足够的历史数据才能学出来。月度重训配合每周评估，是时间序列场景比较稳妥的节奏。

5.3 工具和人员配置的一些个人体会

工具方面，并不需要一开始就上很重的平台。我们早期用 Git、Airflow 调度、MLflow 做实验记录，加上统一的数据库连接配置，就够支撑三四个案例模型同时运转。等模型多了、自动化要求高了，再考虑引入更完整的ML平台。

人员配置上，我的经验是一个案例模型团队最低需要三个人：一个算法工程师、一个数据工程师、一个业务分析师。业务分析师的作用经常被低估，但正是他持续把业务方的话翻译成评估口径，模型才没跑偏。如果你的团队只有算法工程师，建议至少让业务方有人在关键里程碑参与评审。

最后聊一点真实感受

做案例模型这件事，一开始会觉得很麻烦，尤其是前期要写数据契约、做时间戳测试、维护模型卡片，感觉每一项都不产生直接收益。但当你第二个、第三个案例开始复用管道时，节省的时间是呈指数级增长的。我记得第一次把销量预测案例复制到新场景时，光是那一套标准化特征代码就省了整整两周的重复劳动。

给正在做类似事情的朋友一个具体建议：不要一上来就做庞大的统一平台，先认真把一个业务场景的案例模型做到可复制，然后把它交给团队其他人用。只要有人开始用第二遍，你自然会知道哪里设计得不好、哪里该改。迭代着迭代着，你手里就真的有一套别人拿不走的案例模型了。