上周去某家社区超市结账，收银员递给我一张打印小票，底部多了一行字：“您常买的某品牌鲜牛奶下周有促销，搭配全麦面包更划算”。我愣了一下——这家店什么时候开始懂我了？后来一问才知道，他们用一套上线不到三个月的商品推荐系统，把小票、会员卡、促销记录和货架数据全部串了起来。市面上聊推荐系统，默认语境全是电商：千人千面、点击率、实时会话。但超市这套逻辑完全不同，顾客在线下推着购物车逛，货架位置本身就是推荐位，买单瞬间才是黄金窗口。我结合自己做的“超市智能商品推荐系统设计”项目，把这几个月踩过的坑和趟出来的规律整理成文，希望能帮到正在做线下零售数据化的朋友。
1. 超市推荐和电商推荐的底层逻辑差异：先别急着上算法
1.1 三个本质不同的购买场景
电商推荐的整个链路是搜索—点击—加购—支付，每一步都有明确的用户反馈，用户在网站上的行为密度非常高，一天能产生几十上百次交互。超市不一样，顾客进店之后的逛、拿、放回这些动作，在没有摄像头和货架级传感器的情况下基本采集不到，你手里最干净、最完整的信号只有一张张POS小票——也就是结账那一刻的购物篮。
第二个差异是商品生命周期。电商绝大部分商品可以长期挂售，算法有充足时间学习。超市里生鲜、季节品、临期品每天都在变，土豆白菜保质期就几天，一个上架周期内可能根本攒不够算法学习所需的样本量。如果照搬电商那种“积累用户行为——更新模型——再推荐”的闭环，等模型学会的时候，货架早换了一轮。
第三个差异藏在推荐位的物理属性里。线上货架无限长，推荐错了成本极低；线下货架和动线是有限的，顾客要走到你推荐的那个货架前才算数。这意味着超市推荐系统输出的任何结果，都必须考虑到物理可达性和当下的购物阶段，不是算法算出来就完事的。
1.2 从“猜你想要什么”到“帮你把这趟买顺”
电商推荐的核心是猜用户当前想要什么，点击率是生命线。超市推荐的目标则完全不同，业务上你要回答的问题是：这位顾客这趟来大概要买哪些品类？购物篮里还缺什么？把缺的那部分补上，客单价自然就上去了。
举个很直观的例子：顾客明明已经选了牛排，购物篮里大概率还缺黑胡椒酱、西蓝花、意面，甚至一瓶红酒。这不是猜他想买什么，而是帮他完成“这顿饭”的拼图。经典零售故事里的“啤酒与尿布”虽然被营销叙事夸张过，但原理是成立的——买尿布的年轻父亲和买啤酒的人群高度重合，把啤酒放在尿布附近，双方都受益。
所以设计系统的第一件事不是选算法，而是和目标业务方对齐KPI：你到底想提升客单价、消化临期库存、还是提高会员复购？这三个目标会导向完全不同的推荐策略，我在后面会展开说。顺序搞反了，算法再漂亮也没人买单。
1.3 谁真的需要这套系统（以及谁不需要）
不是所有超市都需要推荐系统。我见过一些便利店老板拿着几百个SKU的Excel表来找我聊协同过滤，说实话没必要，那个规模下货架摆放和补货策略带来的收益远大于推荐算法。
| 门店类型 | SKU规模 | 数据基础 | 推荐方案建议 |
|---|---|---|---|
| 社区便利店 | 几百个 | 单店POS流水 | 暂不需要，做好陈列即可 |
| 中型社区超市 | 几百到几千 | 会员覆盖率低 | 关联规则 + 规则引擎 |
| 大型商超/连锁 | 上万 | 会员体系完善，多门店 | 召回—排序完整架构，分店建模 |
| 超市到家小程序 | 同上 | 有在线浏览行为 | 可以参照电商思路但注意生鲜差异 |
先对号入座，再决定投入多少资源，这是我给所有线下零售从业者的第一条建议。
2. 整体架构与数据链路：从POS小票到推荐结果
2.1 数据采集：POS小票是主干，但别忽略辅助信号
超市里能采的数据其实比想象中多，按重要性排序大概是：POS订单明细、会员档案、促销档期、退货记录、库存与缺货记录。POS明细是绝对的主干，它能给出订单号、商品编码、数量、金额、门店、交易时间和会员ID。这中间最关键的一点是订单粒度——同一张小票里的所有商品天然构成一个“购物篮”，这是所有后续分析的地基。
辅助信号同样不能忽略。会员领了哪些优惠券、核销了没有，能反映价格敏感度；退货记录能告诉你顾客对哪些品类不满意；库存和缺货记录能帮你过滤掉“算法推荐了但库里没有”的尴尬。
这里有个典型的坑：很多超市的POS系统没有把退货单和原销售单关联起来，“买了又退”被当成了真实购买，这会严重污染关联规则的统计。我在项目初始化阶段花了整整一周做数据清洗，剔除退货、剔除员工内部购买、剔除批发团购单，后面模型效果才正常。数据质量决定算法上限，这句话在超市场景体现得淋漓尽致。
2.2 特征体系：商品、顾客、门店三个维度缺一不可
推荐特征分三大块：商品侧、顾客侧、门店侧。商品侧要梳理类目层级、品牌、规格、价格带、保质期类型、冷链要求、是否促销品、季节标签。这里特别要注意“保质期类型”这个特征——长保商品适合被推荐，短保生鲜商品推荐要非常克制，人家不会因为你的推荐就多买一堆容易烂的菜。
顾客侧依赖会员体系，包括RFM（最近购买时间、频次、金额）、平均篮单价、品类偏好分布、常购时段、价格带偏好。没有会员体系的门店可以把匿名小票按“同一时段、同一收银台、连续单号”做临时会话聚合，效果打折但聊胜于无。
门店侧特征常被忽略：门店面积、商圈类型、周边客群结构、历史销售增速，这些决定了同一套模型在不同门店的表现差异。别指望用市中心大店的数据训练一个模型去服务所有门店，后面踩坑部分会专门讲这个问题。
2.3 离线管道和实时管道的分工
我的做法是把系统切成两条管道，各干各的。离线管道每天凌晨跑T+1任务，产出每日推荐候选集、关联规则、商品向量、用户偏好画像，服务于小程序首页、电子价签、次日促销推荐这些场景，对时效性要求不高。实时管道专门服务收银台结账前的那几秒钟，逻辑非常简单但要求响应在几十毫秒内完成。
实时管道的推荐不是跑复杂模型，而是基于“当前购物篮”的规则匹配：把购物篮里的商品编码拿过来，去查离线算好的规则表，命中哪些关联规则，按置信度排序，取前三个结果返回。整个链路用到的存储也就一个关系型数据库加一个缓存。把缓存打开，热点规则全部提前加载，接口P99延迟能压到50毫秒以内——这套组合便宜、可控、维护成本低，是我最推荐的中小型超市起步方案。
3. 算法选型：把关联规则、协同过滤和深度模型放在正确的位置
3.1 关联规则：Apriori 与 FP-Growth 的取舍
关联规则是超市场景最容易出效果、也最好解释的算法。核心概念就三个：支持度、置信度、提升度。我拿项目里的真实例子说明。
假设有一千张小票，其中两百张包含牛奶，一百五十张包含面包，两者同时出现的有六十张。那么支持度就是60 / 1000 = 6%，代表这个组合在全部订单中出现的比例；置信度（牛奶→面包）是60 / 200 = 30%，代表买了牛奶的顾客里有多少也买了面包；提升度是30%除以面包的整体购买比例15%，等于2。提升度大于1就说明“牛奶和面包”之间有正向关联，大于1.5基本可以放心上推荐位。
阈值怎么定？数据量大时支持度可以设低一些（比如1%），数据量小时要设高一些避免偶然共现。置信度建议至少20%到30%，低于这个值推荐出去的效果很差。算法实现上，Apriori在几千个SKU时还能跑，SKU上万后性能下降非常明显，因为它要反复扫描数据集生成候选集；FP-Growth用树结构压缩事务，不生成候选集，内存友好，我最终选了FP-Growth。但不管用哪个，生鲜短保商品都建议直接挡在推荐结果之外。
3.2 协同过滤：没有评分时如何定义“相似”
超市的用户—商品矩阵里没有评分，只有“买没买”。解决思路是把购买次数当作隐式反馈，构造用户—商品共现矩阵。这个矩阵极其稀疏，一个普通会员一年也就几十张小票，和电商用户动辄上百次点击完全不是一个密度。
所以我强烈建议超市场景以Item-based协同过滤为主，User-based只能做辅助。Item-based的思路是先算商品与商品之间的相似度——把每个商品在所有小票里的共现向量当作它的“画像”，用余弦相似度计算两两相似度；顾客买了A，就推荐与A最相似且不在当前购物篮里的TopN。相比User-based，它不依赖某个用户的丰富历史，新用户只要有一张小票就能推荐，实用性高得多。
这里有个业务细节：计算相似度时要忍住诱惑，把矿泉水、百元充值卡这类“人人都会买”的商品从共现向量里剔除，否则它们会和所有商品都相似，推荐出来毫无信息量，变成了变相的热销榜。
3.3 浅层模型还是深度模型：按数据量决定
我的判断标准很简单，先看每月有效小票量级。小于十万张，关联规则加Item-based协同过滤足够，别折腾深度学习；几十万到百万张，可以在排序层上一个梯度提升树模型（比如XGBoost和LightGBM这类，效果稳定且好调）；到千万张以上，才需要考虑商品向量化、图神经网络这类更复杂的方案。
别迷信深度学习。超市的数据密度远低于互联网，深度模型在小数据上很容易过拟合，或者把促销期的噪音当成规律学进去。一个清醒的判断是：推荐系统的离线指标提升和业务收益之间隔着一条巨大的鸿沟，简单模型更容易解释、更容易排查、更容易让业务方信任，这就够了。
整体框架我采用的是标准的召回—排序结构。召回阶段把三类候选合并：关联规则候选、相似商品候选、门店热销补充；排序阶段用GBDT对候选打分，特征拼接顾客、商品、门店、时间四类信息；最后过一道规则过滤，把临期品、缺货品、禁止推荐品类全部挡掉。这个结构在超市场景完全够用，也方便后续扩展。
4. 工程实现：从购物篮向量到渠道下发
4.1 把购物篮当成“句子”：商品向量的训练细节
排序模型再好，也依赖召回质量。我后来做了升级：把每个会员的购物篮按时间排序，当成“句子”，把商品当成“词”，用词向量那套方法训练商品向量。道理很简单——经常出现在同一个购物篮里的商品，和经常出现在同一句话里的词一样，语义上是相近的。这样算出来的商品相似度比itemCF的共现矩阵平滑得多，还能通过向量运算做一些有意思的探索。
几个训练细节值得记录。一是购物篮序列构造时，同一张小票里商品的先后顺序其实没有意义，要随机打乱，否则模型会学到假的“顺序信息”；二是窗口大小设3到5比较合适，太大会把无关商品强行拉近；三是负采样时必须剔除矿泉水、抽纸这种超高频率商品，否则它们会成为万能的“负样本中心”，把向量空间搞坏。
构建训练样本时，我曾经踩过数据泄漏的坑：把当天的退货数据直接拿来当负样本，结果模型学会了“识别那些会被退货的商品”，上线之后推荐质量奇差。后来把退货数据单独清洗，作为过滤规则而不是训练样本，才恢复正常。
4.2 排序层：特征、样本与模型
排序模型的作用是把召回来的候选商品按“顾客当下会买”的概率重新打分。我的特征分三组。商品侧有价格、折扣力度、历史转化率；顾客侧有该顾客对这个类目的历史购买频率、价格带匹配度、距离上次购买该类目的时间。最后一组特别关键：超市有周期购买属性，牛奶喝完大概一周，米面油大概一个月，距离上次购买时间太近就不推荐，太远也不必追着推。
场景侧特征包括当前时刻、门店编号、当前购物篮已有品类数量。比如晚上七点，购物篮里已经躺着一盒鸡蛋，排序模型会倾向于把配菜类商品排前面。
训练样本定义要小心。正样本是推荐后被加入购物篮或者直接购买的商品，负样本是展示了但没买。这里必须等A/B测试闭环跑起来才能拿到真实的曝光数据，所以第一个月往往是冷启动，模型效果不会太好，别慌，先把曝光日志埋点埋全。
4.3 渠道与时机：推荐位不是越多越好
推荐结果要分发到具体渠道，每个渠道的特性完全不同。
| 渠道 | 时机 | 展示数量 | 适合内容 |
|---|---|---|---|
| 收银台屏幕 | 结账前几秒 | 1-3个 | 凑单型、满减门槛补齐 |
| 电子价签 | 顾客在货架前 | 1个关联提示 | 当前商品的搭配品 |
| 到家小程序 | 下单前/次日提醒 | 3-6个 | 生鲜补货、促销预告 |
| 打印小票 | 结账后 | 1-2个 | 优惠券二维码，线下回流 |
时机规则比模型重要。不要顾客一进门就推冷饮，他还没逛到饮料区；不要顾客刚买完某个品类就推同类目，他短时间内不会再买；生鲜补货提醒适合在晚上八点后推送第二天的菜。我的经验是一篮子推荐不要超过三个，超过三个顾客根本看不过来，还会觉得被冒犯。
4.4 规则过滤与人工兜底
这一层最不智能，但往往决定系统能不能上线。无论模型给什么结果，都必须过一遍硬规则：缺货商品不推、临期商品不推、有合规风险的商品（烟酒、处方性质保健品）坚决不推、儿童营养品类目不能推荐给没有小孩的顾客。价格带也要兜底——一个习惯买高端有机食品的顾客，你不该给他推性价比散装货；反之也一样。
规则兜底还有一个隐藏好处：业务方敢把推荐位交给你。零售店长和采购最怕系统乱推影响库存和毛利，有了硬规则，他们才愿意把真实曝光数据开放给算法团队，形成正向循环。
5. 冷启动、效果评估与踩坑实录
5.1 三类冷启动的应对方案
新商品、新门店、新会员三类冷启动要分开处理。新商品没有历史数据，我按价格带和品类把它归入已有商品簇，先给一个保守的推荐位，积累三十次展示之后再进入正常候选池。新门店没有本地数据，先用同商圈、同面积级别的老门店模型做迁移，跑两到四周后再用本店数据微调。新会员没有历史记录，先用门店热销TopN加时段热销顶上，同时在会员注册时加一道“偏好品类勾选”——收集的信息量不大，但对冷启动很有帮助。
5.2 评估指标怎么定
推荐系统上线后，我每周看四类指标。直接指标是推荐位的点击、扫码、加入购物篮率；生意指标是客单价、购物篮商品数、连带率；库存指标是临期品清仓率和滞销品动销率；体验指标是退货率和投诉率。只看点击率会骗自己，超市推荐的价值必须落到生意指标上。
A/B测试建议按门店组或会员ID分桶，至少跑两周。两周是线下购买周期的约数——很多家庭的超市大采购是两周一次，跑不够一个完整周期，结论不可信。我不建议按“线上点击用户和线下到店用户”来分实验组，这个口径混在一起根本解释不清楚。
5.3 我踩过的几个具体的坑
第一个是数据泄漏。训练集里混入当天退货单据，模型学会了推荐“要退的商品”。清洗退货数据之后，离线指标和在线转化率同步明显提升，这算是我印象最深的一次教训。
第二个是促销干扰。大促期间所有关联规则都被打折商品主导，跑出来一堆“满减凑单”规则，促销一结束全失效。解决办法是训练时剔除促销占比过高的样本，或者干脆给促销单独建一套规则库。
第三个是推荐了顾客刚买过的东西。顾客上周刚拿一箱牛奶，这周又给他推牛奶，体验极差。后来在排序特征里加入“购买间隔”，长保商品设三十天冷静期、短保设七天，问题才解决。
第四个是忽略门店差异。总店数据训练的模型放在写字楼店表现很差，因为两个店的顾客结构完全不一样。最终的方案是至少按大店、社区店、写字楼店分三套模型，效果才稳定下来。
最后再说句实在话：如果你的超市还在用Excel看销售排名，别急着上推荐系统。先把POS数据规范化、打通会员体系、把品类和价格带标签补全，这些基础工作决定了后面所有算法的上限。我做这个项目最大的体会是，线下零售的推荐不是要炫技，而是要在一趟购物已经接近尾声的时候，恰到好处地递上一个让顾客觉得“这趟没白来”的理由。先把关联规则跑通，亲眼看到客单价在涨，再考虑模型升级，这个顺序不会错。
