说实话干了这么多年电商推荐最让我觉得“既麻烦又值钱”的需求就是服装尺码推荐。你打开任意一个卖衣服的App首页推荐点击率再高、详情页做再花哨最后都逃不过一个问题这件衣服到底买什么码买小了穿不上买大了像偷来的退货率直接给你拉爆。我做过一段零售电商侧的推荐系统科技圈最爱吹“大数据赋能服装新零售”实际落到项目里核心就一件事怎么用历史订单、身高体重、浏览行为这些数据在用户下单前就尽可能猜中那个“穿上去刚刚好”的尺码。这个算法做得好了用户不会感知到但后台的退货率和换货率会有肉眼可见的变化。这篇就是我在实际项目里做尺码推荐算法的一次完整复盘。适合正在做电商推荐、或者打算做服饰类商品体验优化的开发者和产品经理尤其是被“尺码不准”“退货率高”折磨得不轻的同学。这里没有炫技都是踩过坑之后的实操经验。1. 这个项目到底解决什么问题1.1 服装尺码不只是“S/M/L”三个字母先说一个反常识的事实服装尺码的标准根本没有真正统一过。同样是“L码”不同品牌之间可能差出一个胸围的宽度同样是牛仔裤同一个品牌的不同系列版型可能一偏紧一偏松同一件衣服你穿合身我穿可能胸口勒得慌。尺码本身就不是一个物理上的绝对坐标它是一个“版型用户身材主观喜好”三者博弈后的结果。这就导致了一个结果就算你身高体重一模一样买同一个品牌的不同款式你需要的尺码也可能完全不同。很多人以为尺码推荐AI就是查表身高175cm体重70kg推荐L码这种认知是大错特错的。真的这么简单就不会有那么多七天无理由退货了。我做这个项目的核心目标就是压缩用户从“看到衣服”到“买到合身衣服”之间的试错成本。用户在选尺码的那个下拉框点开之前我就能预判他大概率穿哪个码而不是让用户反复买反复退用运费和时间换合身。1.2 不是不想推荐是以前的推荐方式太粗了我接触过不少电商团队他们其实早就想过尺码推荐这件事只是没做起来。我复盘了一下半途而废的普遍原因有三个。第一个原因是规则太简单。很多平台早期的尺码推荐就是一张身高体重映射表称作“尺码对照表”175/70对应L165/60对应M。听上去很合理实际用起来完全不行因为这张表忽略了版型和品类差异一条修身牛仔裤同尺码的臀围和一条宽松工装裤的臀围天差地别一件卫衣的M码可能比一件衬衫的M码宽出一大截。第二个原因是数据太稀疏。衣服不是高频消费品一个普通用户一年买的衣服也就十几件每件衣服对应的尺码反馈就一次。用这么稀疏的数据去训练模型很多常规推荐算法根本跑不起来。第三个原因是用户不配合。如果把“请填写你的三维数据”放在注册流程里用户转化率当场就得掉几个点。现实中几乎没人愿意认真量胸围、腰围、臀围顶多给你一个不太准的身高体重。所以尺码推荐这个事技术和业务两边看着都觉得很值得做一做就发现全是坑。但我觉得这事恰恰是大数据和机器学习最能发挥价值的地方数据少没关系只要信号准反馈稀疏没关系只要能把用户、商品两端的隐含信息挖出来。2. 尺码推荐算法的整体设计与难点拆解2.1 为什么不能直接预测“用户该穿什么码”第一版设计时我最初的想法很直接把尺码当作一个多分类问题S、M、L、XL、XXL分别当类目用用户的特征去预测他适合哪一类。这个方案看着顺理成章实际做着做着就发现问题了。问题是尺码类别本身是相对的。同样是M码在这家店可能合身在另一家店就会偏小。如果模型只学“某类用户喜欢M码”那么这个M码在不同商品上的含义是不同的模型学到的权重就会被这种不一致稀释掉。再加上有的品牌尺码偏大偏小严重模型就容易把“用户喜欢宽松”错误地学成“用户需要大一码”把两个维度混在一起。后来我换了个思路不直接预测绝对尺码而是预测一个“偏移量”。以某个商品自己的尺码表为基准先去计算这个商品版型对应的“中间尺码”比如同品类的历史畅销码然后预测用户在这个基准上需要加几档还是减几档。这种设计的好处是每个商品有自己的“坐标系”不同品牌之间尺码不一致的问题就被归一化掉了模型学出来的东西不再是绝对尺码而是“用户体型相对于标准版型的偏差”。2.2 核心难点不是算法而是“什么是正确答案”我一向认为好模型的前提是有好标签。尺码推荐算法里定义“正确”比调参难十倍。第一个尝试是看用户买过什么码。一个用户历史上在平台买了L码的卫衣且没退货就推断他适合L码。这个思路有道理但太容易被误导他买L码可能是因为这件卫衣版型偏小也可能他其实穿M更修身只是没有M的货了。单一“买过”信号只是下单了不代表穿得舒服。第二个尝试是看用户退没退货。如果退货原因是“尺码不合适”就认为推荐失败。这个信号更接近真实反馈但问题在于退货这件事有几个特点——延迟很长用户可能穿了几天才退正负例极度不平衡大部分订单不退货并且退货原因往往是多因素混合的质量问题、颜色不对、物流太慢都可能写“尺码不合适”。所以我们最后用的标签方案是把“购买了某商品对应尺码、完成确认收货、并且没有在七天无理由内退货”当作弱正例把“因尺码问题退货”或“换货到不同尺码”当作强负例把质量退、颜色退、拖延不确认收货的样本全部过滤掉。这个标签体系也不是一天定下来的是跟着业务团队和客服团队反复聊把退货原因的字段梳理了一遍才理清楚。我在这上面花的时间不比调参建模少多少但后来的实践证明这份工作绝对值得。用一套不干净的数据喂什么模型都是白搭。2.3 用户主观偏好怎么量尺码推荐有个躲不开的难点合身这件事本身就带有强烈的个人偏好。有人就喜欢oversize风买什么都特意大一码有人喜欢紧身穿搭明明标准M的身材偏要买S。这些偏好是真实存在的需求不是模型学不会而是数据里本来就隐含了这种个性化因子。我的处理办法是给标签体系加一维不只看用户买什么码还看他持续买什么码。如果用户在同一品类、类似版型下反复购买同一尺码并且从不退货那么这个尺码就大概率是他偏好的真值。模型必须兼容这种“宽松偏好型用户”和“修身偏好型用户”在他们的特征上单独形成一种稳定的预测模式而不是逼着所有人都往标准身材上靠。只不过这个偏好特征的提取必须有足够多的历史订单支撑新手用户就享受不到这个福利了。所以在设计上我们把用户分成了两个群体老用户走个性化偏移新用户走身高体重规则引擎。两类用户用两套逻辑上线之后比一套逻辑硬撸到底舒服得多。3. 核心实操特征、模型与训练细节3.1 到底哪些特征有用项目做了三轮特征体系被删删改改了很多次。我整理了一份最后沉淀下来的名单基本可以覆盖这类业务80%以上的需求。特征大类具体特征说明用户基础信息性别、年龄、身高、体重不完美但有比没有强得多体感比三围弱但容易获取用户历史尺码行为过去365天购买尺码分布、换货尺码记录、退货尺码记录这是最强的一类特征能反映个人偏好和常驻尺码基线品类偏好近90天各品类购买比例、品类尺码均值用户在不同品类尺码是有迁移规律的商品信息商品所属品类、版型标签修身/宽松/标准、面料弹性版型标签极其重要靠运营标注不靠算法猜商品尺码表尺码对应的胸围/衣长/腰围/臀围区间弱特征有噪音但能辅助上下文下单季节、当前月份冬天买外套和夏天买T恤尺码逻辑完全不同这里有个容易被忽略的点版型标签。同样标着“L”修身款和宽松款对应的实际合身人群完全不同。我见过一些团队为了省成本不做版型标注认为模型能自己学出来实际上不行至少在小数据量下学不出来。我们当时的做法是让选品团队在录入商品时多一个“版型”字段这是个低成本但收益很明显的投资。3.2 模型选型为什么不是神经网络尺码推荐这个场景最开始也有方案争夺。有同事提议上深度学习用NN学用户和商品的embedding听起来很fancy。但我最后选了梯度提升树GBDT系列理由很朴素数据量撑不起深度学习。一个用户一年才买多少次衣服全平台看起来订单量大但是切到“用户-商品-尺码反馈”这个粒度每个用户的样本量就是个位数到两位数。深度学习在这种稀疏场景下很容易过拟合而且调参成本高线上推理资源压力也大。GBDT对中小规模表格数据非常友好特征工程灵活可解释性强出了问题也更好排查。我并不是说神经网络在这个领域完全没有用之前也见过有人用双塔模型做类似事情效果也不算差但那是在订单密度很高的垂直服装平台上。对于一般电商平台我强烈建议先从GBDT做起把特征和标签弄干净比选什么模型重要得多。模型永远是最后一个可以优化的环节数据和特征才是决定上限的东西。3.3 训练流程和样本构造细节这里我给出一个可复用的训练流程。你要复现这个项目按这个骨架来跑基本不会跑偏。第一步清洗样本。拉取近24个月的订单数据过滤掉异常订单、刷单订单、秒杀订单和跨境代购订单。逐单标记如果订单内商品被因“尺码不合适”退款或换货标负例如果确认收货且超过退货期无售后标正例退货原因不是尺码相关直接删掉该条样本不进入训练集。第二步构造特征。按前面那张特征表做特征工程注意所有的用户特征必须在“下单时刻”之前截断不能用未来信息。比如用户在某天买了件L码卫衣那这个订单的特征里就不能包含他后面买的XL裤子的信息否则会造成数据穿越线上表现直接崩盘。第三步定义目标。我把目标定义为“该商品尺码偏移量”的分类问题假设某商品尺码档位是S0、M1、L2、XL3、XXL4模型要预测的就是用户应该买第几档或者输出一个置信度最高的偏移值。对于尺码档位我直接映射成有序整数用类似有序回归的建模思路来做。第四步训练与评估。GBDT框架我用的是LightGBM训练一轮后看验证集上的准确率和分类AUC。评估指标上一节讲过重点看“±1档以内准确率”同时把“绝对匹配准确率”作为复盘参考。我不会在这里贴一堆项目特有的代码核心逻辑写个伪代码也就二十行# 模型核心逻辑示意 from lightgbm import LGBMClassifier # X: 用户特征 商品特征 上下文特征 # y: 尺码偏移目标如 -1, 0, 1, 2 表示相对基准档位的偏移 model LGBMClassifier( objectivemulticlass, num_class5, learning_rate0.05, n_estimators300, subsample0.8, colsample_bytree0.8, reg_lambda1.0 ) model.fit(X_train, y_train) # 线上预测输入用户与商品特征输出各偏移档位概率 prob model.predict_proba(X_test) pred_offset int(prob.argmax()) - 2 # 转为相对基准的偏移关于参数我给的是一个比较稳妥的起点并不是什么最优参数。实际项目中还是要根据数据量去调学习率和树的数量别照抄。3.4 线上预测时的“解释性”设计很多算法项目上线之后业务方会来问“为什么推荐这个码”。你肯定不能甩给他一堆特征重要性和树的残差他听不懂也不会信。我给线上接口设计了一个三层解释逻辑第一层是“因为您的身高体重属于标准体型的M档”针对完全没有历史记录的用户第二层是“因为您过去在类似版型的商品上购买L码且反馈良好”针对有历史行为的老用户第三层是“因为该商品版型偏小一档系统根据您的身材自动上调一档”针对被商品版型修正影响了的用户。这三层解释不是说真的给用户看而是给客服和运营看。用户来问尺码问题客服一查就知道系统推荐依据是什么能快速判断是推荐逻辑问题还是用户特殊身材需要人工介入。这个小设计看似不核心但上线后客服侧的满意度提升非常明显算是性价比极高的一笔投入。4. 线上落地与工程实现要点4.1 实时推理还是离线预计算尺码推荐和一般推荐系统在工程上的最大区别是尺码推荐的输入变化不频繁不需要做严格的实时个性化。用户半年内长胖3斤、身高变化1厘米尺码偏好基本不会变。商品维度上一款衣服上架后它的版型标签就定了不会时时变。所以我把整个尺码推荐拆成两条链路离线预计算链路每天凌晨跑一次全量用户尺码偏好模型输出每个用户在各品类下的“偏好尺码基线”和“偏移置信度”写进缓存。商品详情页请求时直接读这个用户基线配合当件商品版型参数几毫秒就能给出推荐。在线轻量修正链路用户如果在下单前临时修改了尺码选择或者曾经在某件商品下做过换货操作实时记录这个行为下次再点进这个商品或类似商品时在线叠加一个修正因子。这么拆分的好处是核心算法跑在离线任务里资源可控线上只做查表和简单逻辑延迟压力小。如果一个尺码推荐非要在用户点开商详那一刻实时跑全量模型遇到流量高峰很容易被打爆没必要。4.2 冷启动问题怎么处理新用户没有历史购买记录新商品也没有历史反馈这在推荐系统里叫冷启动尺码推荐里同样存在。我对新用户的处理策略是“规则打底、模型修正”。用户注册时通常会填身高体重和性别这几个字段就够用了。先按BMI区间和身高算出“标准体型尺码基线”比如“身高178cm体重72kg的成年男性在T恤品类的基础档是L”。然后如果用户允许访问位置再结合地理位置修正一下南方人的尺码均值普遍比北方人的小一档这个是统计事实虽然不能一竿子打死但作为先验概率是有参考价值的。对新商品的冷启动靠的是商品信息录入时的那几个字段品类、版型、面料弹性。如果一件新上架的卫衣标了“宽松版型”那么在尺码推荐时自动向下一档偏移。这个规则是运营同学常年积累下来的经验我们第一次把它固化成了系统逻辑相当于让机器学会了“宽松版型要买小一码”这种常识性知识。4.3 推荐结果长什么样这一块很多人没想清楚。尺码推荐不是要把用户的尺码选择权剥夺它只负责“把预设值填对”用户仍然可以手动改。在商品详情页的尺码选择器里我们会把系统推荐的码做高亮显示旁边放一行小字“根据您的历史尺码推荐L码”。如果用户没有历史行为就写“根据身高体重推荐M码”。用户点击确认后系统推荐就算完成了使命。这个交互设计很重要。当初也有人建议直接把尺码选择器干掉让系统自动选美其名曰“千人千码”。我坚决反对原因很简单尺码推荐只能做到概率最优做不到绝对正确。用户自己对自己的身体最了解他可能有孕期体型变化、健身增肌、冬天穿厚内搭等各种情况系统不可能全知道。保留人工改码的入口既不给用户添堵也给自己留了一条退路。4.4 上线初期的灰度策略就算离线评估做得再乐观落地时也要谨慎。尺码推荐的改动会直接影响用户下单决策推荐错了可能会导致之前本来能通过用户自己选码选对的订单变成退换货这是得不偿失的。我的灰度方案分了三步第一步先只对没有历史购买记录的新注册用户开推荐这部分用户本来就没有基线系统推荐的码对他来说就是唯一参考不会产生预期落差。第二步对老用户中退货率特别高、明显有“买码困难症”的用户开放比如历史尺码退货率超过30%的用户这些用户本来就饱受选码困扰推荐给他们的价值最大。第三步全量放开同时监控全站尺码相关退货率。灰度最重要的监控指标是参与推荐订单的“尺码相关退货率”不能高于同商品未参与推荐订单的退货率。后续真实上线数据证明新品尺码推荐订单的退货率相对基准能下降好几个点这个效果肉眼可见地划算。5. 常见问题与排查经验实录5.1 身高体重都准为什么推荐还是不准这是被问得最多的问题。用户身高175cm、体重65kg按BMI算标准体型应该穿M结果系统推荐L。用户来投诉说推荐不准。排查这类问题的路径是有规律的。不要上来就怀疑模型先看两件事第一该商品是否被运营打过“偏小版型”标签如果版型标了偏小模型向上修正是正常行为第二该用户是否有历史尺码行为特征比如他过去在这个品类一直买L系统会优先尊重用户自己的习惯而不是理论上的标准表。还有一种很隐蔽的情况同类目下系统对图片相似但版型不同的商品输出结果差异很大。用户看到两款差不多的卫衣一款推荐L一款推荐M就觉得系统疯了。实际上一篇是正常版型、一篇是修身版型不同推荐本身就是有逻辑的只是没有把原因透给用户。后来我们把“版型”两个字直接写进了推荐理由这种投诉马上就少了。5.2 标签不准导致模型学歪运营同学手工标注的版型字段也会出问题。有一次我们复盘负面样本发现大量“推荐S码但用户退货并且换成了L码”的案例细查后发现那批商品全被运营错误标成了“宽松版型”——实际大货版型是修身的。模型被这些错误标签反复教育自然越走越偏。这个问题的排查方法没什么捷径就是定期做样本审计。我建议每个月抽一批预测结果和用户反馈做一次人工抽样把模型预测结果和真实反馈不一致的case拿出来看一眼重点看商品版型标签、尺码表数值这两类输入是否合理。很多时候不是算法问题是数据质量问题。5.3 极端体型用户怎么办有一种用户是任何数据算法都很难救的就是极端体型。比如特别高但特别瘦、特别矮但体重偏重、或者肩宽特别大这类情况。这些用户的特征分布落在训练样本的尾部数据量很少模型很难学出稳定的规律。我的处理方案是提供一个“特殊体型通道”当系统检测到用户预测结果的置信度低于阈值并且该用户的历史尺码退货率偏高时在详情页给他弹一个“尺码助手”引导卡片让他自助填写胸围、腰围、臀围、肩宽。填完这些信息后走一个独立的规则引擎比通用算法更可靠。这个功能用的人不多但用的人退换率极低。尺码推荐不是非要一个模型通吃给极少数特殊用户一个“人工模式”的出口实际运营体验会好很多。5.4 不同品类之间的尺码迁移规律做多品类的时候有些品类可以互相参考有些品类则完全不能互相参考。比如同一个用户T恤和卫衣的尺码基本一致裤子尺码相对独立鞋子尺码跟衣服则完全无关。我做过一个实验把用户在某品类的尺码特征拿去预测他在另一品类的尺码结果发现上衣-卫衣的互相预测准确率不错上衣-裤子就差了很多裤子-鞋子基本没有正相关性。所以在模型特征里我只保留了部分跨品类尺码特征把“品类相关性”放进特征选择的标准里垃圾关联少一点模型收敛就快一点。后来我又加了一个“品类内常穿尺码”的字段相当于给每个用户在不同品类建立独立的尺码档案。比如同一个用户在上衣品类是L在裤装品类是33在鞋靴品类是42。每一个档案都是一个独立模型输入互不污染。这事看着繁琐但对准确率的提升是非常显著的。6. 写在最后的一些操作心得尺码推荐这个项目做下来核心的体感只有一个这活不是纯技术活更像是一场“数据、业务、用户三者之间的三角博弈”。你得一边理解业务运营凭什么给商品打版型标签一边忍受用户不愿填身材数据的现实还得在稀碎的反馈信号里把正确信息捞出来。算法永远是最后那一环前面的人生意逻辑想不明白后面跑再牛的模型都是自嗨。最后分享一个实用小技巧每次模型迭代之后不要只看全量指标把商品按“版型标签”和“品类”各拆一组分别看效果。全量指标容易掩盖结构性偏差——可能你今天整体准确率提升了0.5%但修身裤这个细分类别的推荐反而变差了。拆分着看才能发现哪些改动是真正在进步哪些只是在平均数上投机。这类的尺码推荐还能往前面延伸一步比如结合商品的真实用户反馈数据给每件衣服算一个“实际穿着放量偏差值”把“按尺码表算出来该买什么码”和“用户真实穿着反馈算出实际该买什么码”之间的差量做出来能进一步把尺码表不可靠的问题压到更低。那些售后反馈里最被忽略的信息往往是这些算法项目里最值钱的金矿。