服装电商这个行当，做得越久越会发现一个扎心的事实：用户下单时对尺码的判断，基本靠猜。我自己在某服装电商团队做推荐相关项目时，第一天拿到业务方的需求，对方只说了四句话：让用户更容易买到合身的衣服；把尺码相关退货降下来；别让客服每天被尺码投诉淹没；最好还能反哺供应链。听上去很简单，真正动手才发现，尺码推荐根本不是"根据身高体重给个S/M/L"这么粗暴的事。它横跨数据清洗、特征工程、算法选型、AB实验和供应链协同，任何一个环节掉链子，线上效果都会直接反弹到退货率上。这篇文章我会把整个项目从立项到落地踩过的坑、用过的方案、以及最终稳定运行的架构完整梳理一遍，适合正在做推荐系统、或者准备在服装品类上做精细化运营的同行参考。
1. 电商退货的"隐形黑洞"：尺码问题背后的业务账
1.1 不只退货率，尺码问题牵动的是整条供应链
先看一条业务账。服装品类退货率常年能到25%到35%，而其中因为尺码不合适产生的退货，通常能占到退货总量的40%到60%。一单退货背后的羊毛出在羊身上：逆向物流成本、仓库二次质检、重新上架后的折价销售，一套流程下来，退货成本大约能吃掉订单金额的8%到15%。对于毛利只有40%到50%的服装品牌来说，这意味着每退一单，这件衣服的利润基本归零，甚至倒亏。
但我们当时复盘时发现更大的问题不在退货本身，而在用户行为链的断裂。一个用户买错了尺码，客服介入、退货退款，表面上一单结束了，实际上下一次她大概率不会再来这家店。我们从留存数据里看到一个趋势：尺码推荐生效过的用户，二次购买率比没生效的用户能高出3到5个百分点。这个数字单看不大，放在服装这种低频复购品类上，几乎决定了品牌在做的是"一锤子买卖"还是"回头客生意"。
第三重成本是供应链的错配。尺码买错不是均匀分布的错，而是集中在某些尺码上。比如一款连衣裙如果M码长期缺货、S码和XL码天天积压，你会看到前端在丢订单，后端在压库存。推荐的本质其实是把需求提前、精准地映射到库存结构上，如果尺码推荐做得好，库存周转的优化效果远比打折促销来得健康。
1.2 尺码推荐算法的能力边界：能做什么，不能做什么
做这个项目之前，团队里很多人把尺码推荐和"猜你喜欢"混为一谈。直到我们梳理需求才想明白两者的差异：猜你喜欢回答的是"用户喜欢什么样的衣服"，尺码推荐回答的是"用户穿这件衣服哪个尺码更合身"。两者都叫推荐，但判断逻辑完全不在一个维度上。
尺码推荐能做的，是利用用户侧和商品侧的历史数据，给出一个"最大概率合身"的码数。它包括：读取用户历史购买同品类的尺码偏好、比对商品本身的尺码表与版型、参考相似体型用户在目标商品上的购买分布，最后综合出一个推荐结果。
它做不到的也很明确：用户主观上喜欢宽松还是紧身、她最近半个月是瘦了还是胖了、不同品牌尺码表之间暗藏的"虚标"问题，这些都不是算法单靠历史订单能100%搞定的。这也是为什么尺码推荐从来不是"预测一个绝对正确的码"，而是"把选错码的概率尽量压低"。业务方如果一开始就要求"推什么就必须穿什么"，那这个项目趁早别接。
2. 特征工程：从"身高体重"到"有信息量的尺码画像"
2.1 用户侧特征：几个被严重低估的输入信号
最基础的特征是身高和体重，但这里有个坑：用户填写的身体数据往往不是实时的，有的人一年前注册时填了一次，之后就再也没更新过。我们当时在用户画像侧加了一个"自报数据置信度"的权重——如果该用户有近90天的购买记录，就降低自报数据的权重，让历史下单行为主导尺码判断。这个改动上线后，推荐准确率提升了大概2个百分点，属于少见的低成本高收益优化。
比身高体重更关键的是购买历史。我们提取了用户在每个品类的历史购买尺码序列，不只是取最后一次，而是看近半年的尺码漂移趋势。很多用户会随着体重变化或品牌切换，从M码慢慢漂到L码，捕捉这个趋势比单独用一个点判断准得多。
还有个容易被忽略的信号是"重复购买"。用户对同一款商品第二次下单，选的尺码就是高置信度的合身标签。这类样本在训练数据里权重我们调得非常高，因为它是唯一一种"用行动确认"的尺码信号，比任何问卷和客服反馈都可靠。
2.2 商品侧特征：尺码表、版型与品类差异
商品侧的尺码表是最让人头疼的特征来源。不同品牌的尺码表口径完全不一致，同样是M码，有些品牌标胸围88到92厘米，有些只标一句"适合体重55到60公斤"，还有一些干脆只写了S/M/L，连数字都不给。我们拿到原始尺码表后做了两件事：第一，把文本描述清洗成统一的数字化区间，拆成胸围、腰围、肩宽、衣长等标准维度；第二，对不同品类单独建特征映射，因为上装看胸围肩宽，下装看腰围臀围，连衣裙还得多看一个裙长，混在一起建模会互相干扰。
版型标签是另一个被验证有明显增益的特征。我们把商品打上"修身""标准""宽松""oversize"等版型标签，实测下来，同一款式的修身版和宽松版，如果只按基础尺码表推，推荐结果会直接错位。用户穿修身版需要大一码，穿oversize版反而要往小选，这个差异只能靠版型标签来表达。
这里分享一个我们在商品侧做的补充动作：把商品的尺码表按品类做标准化对齐。比如上装统一映射到数字体系，用"160/84A"这种国标码替代S/M/L，这样就能对不同品牌做段差补偿——A品牌M码对应84厘米胸围，B品牌M码对应88厘米，映射到统一体系后，推荐引擎能自动识别"B品牌的M码其实等于A品牌的L码"。
2.3 最容易忽视的坑：尺码标签噪声
你可能会下意识认为，商品本身的尺码标S/M/L是可信的。我们是吃过亏之后才明白，这个假设不成立。有一个实际发生的案例：某批次连衣裙因为供应商贴错水洗标，全部从M码标成了L码，用户收到的衣服普遍偏小，于是该商品下所有购买记录都被打上了"偏小"的负反馈。但实际上问题出在标签错位，不是版型问题，如果我们不做清洗直接用历史数据训练，模型会学到一条完全错误的规则。
另一种常见噪声是面料缩水。棉质面料首次下水缩水率能达到3%到5%，用户穿了一次再洗一次，合身度数据就失真了。处理这种噪声，我们用的办法是在特征层加入"面料成分"和"洗涤方式"标签，在清洗层做异常尺码分布检测——当某SKU的退货尺码分布和同品类其他商品显著偏离时，触发人工复核。
3. 算法路线：规则引擎起步，逐步升级到机器学习
3.1 0到1阶段：基于品类规则的尺码映射
在没有足够数据积累的第一版，直接用规则引擎完全是合理的。我当时设计的规则很简单：统计每个品类下历史订单中各个尺码对应的身高体重区间，然后对当前用户的身高体重做区间重叠匹配，从重叠度最高的尺码集合里挑推荐结果。
这里有一个关键设计：为什么用区间重叠而不是直接取最近中心点？因为尺码本身不是点估计，它是一段容忍区间。比如统计出来M码的典型身高体重区间是160到170厘米、50到65公斤，用户165厘米、58公斤同时落在M和L的重叠区，这时候就要叠加年龄、品类偏好去二次判断。规则引擎在这一步的兜底逻辑是：用户年龄偏大的，尺码倾向往大推一档，因为体型随年龄的自然变化在服装上是客观存在的事实。
规则引擎还有一个很实用的衍生功能：输出推荐尺码的同时，把命中的尺码区间边界也一并返回。前端可以展示"您的体型数据落在M码和L码之间，考虑到您过去偏好合身版型，优先推荐M码"，这个交互对后续用户信任建设非常有帮助。
3.2 过渡方案：相似用户聚类与协同过滤变体
当订单量积累到百万级之后，规则引擎的瓶颈就出来了——它无法处理"每个品牌实际版型不同"这个事实。我们当时采用的中间方案是带权重的相似用户聚类，思路非常朴素：把用户在某个品类最后一次购买的尺码标准化成统一尺码编号，然后统计出用户的历史尺码向量，用余弦相似度找最像的N个用户，再取这N个用户在目标商品上购买的尺码众数作为推荐。
这个方案的可解释性不错，部署也轻量，但它的问题在于用了整体偏好去映射单品。如果用户平时买A品牌穿M码，但目标商品是版型偏小的B品牌，相似用户算法无法自己发现这个变化，必须靠外部修正。所以我们又在聚类结果之上加了一层尺码偏移：把A品牌和B品牌的尺码映射到统一数字码体系，用两个品牌间的段差自动做补偿。举个例子，A品牌M码映射为160/84A，B品牌M码实际对应165/88A，那么系统在推荐B品牌商品时，会直接把聚类出的M码结果向上移一个段位。
3.3 进阶路线：多任务学习与排序模型
在特征丰富到用户侧、商品侧、上下文侧都有充分数据之后，我们最终采用的方案是GBDT多任务模型，同时预测三个目标：合适尺码的分类概率、用户是否退货（作为合身度的代理标签）、用户下单后是否复购。为什么一定要多任务？因为单一的分类模型训练信号是"用户最终购买的尺码"，但"最终购买"并不等于"穿着合适"。
用户可能因为折扣大而接受偏大一码，可能因为库存缺码而将就小一码，也可能就是懒得退了。这些灰色行为单独看都会污染训练标签。多任务模型相当于让模型同时学习"购买"和"合适"两个角度，在训练过程中共享底层特征表征，上层各任务用不同损失函数约束，最终学到的表示会天然区分"买对了"和"买漏了"。离线验证里，单任务准确率大约78%，换成多任务后直接拉到84%，效果差得还是很明显的。
3.4 为什么我不建议一上来就上神经网络
这个观点可能会被一些做深度学习的同行反对，但我的经验是：服装尺码场景的数据量，相比语言和图像领域其实是小得多的。哪怕头部电商平台，单品类有效订单也就是千万级别，而且带着大量稀疏和噪声。神经网络在这种数据规模下特别容易过拟合，且排查问题、上线部署都会增加不少工程负担。
我们团队也不是没试过深度模型，最后发现那些提升基本来源于特征工程和标签清洗，而不是模型的拟合能力。务实路线应该是：把规则统计方法跑明白，把特征和标签质量做扎实，然后上梯度提升类模型，就能拿到80%以上的提升。等用户规模和数据量真正上来之后，再考虑用神经网络去做跨品类的特征交叉，那时候性价比才合理。
4. 数据陷阱与评估体系：容易被带偏的两个环节
4.1 稀疏数据和冷启动：新用户新品怎么办
尺码推荐对冷启动的敏感程度比常规推荐更夸张。常规推荐冷启动时可以用热门商品兜底，尺码推荐却做不到——用户没有历史数据，你根本不知道她适合什么码。我们做了三层回退策略：新品冷启动时，用同品牌同品类的尺码分布兜底，比如同品牌牛仔裤的历史尺码分布中M码占45%，那就优先推M码；新用户冷启动时，用身高体重区间匹配；如果连身高体重都没有，那就直接展示尺码表让用户自己选，同时给一个"不确定就选大一码"的默认建议。
这个三层回退看起来简单，但落地时不注意就会出问题：回退的顺序不能乱。我们一开始是先走用户相似度再走身高体重，结果冷启动用户被大量误推到和他体型毫不相关的尺码上。调换顺序之后，冷启动场景的推荐准确率明显更稳。
4.2 反馈信号里的选择偏差：没退货不代表合适
用线上订单数据训练尺码模型，最大的陷阱在于"没有退货"这个信号实在太弱了。用户不退货的原因可能很复杂：嫌退货流程麻烦、刚好赶上折扣不想折腾、衣服虽然偏大但也能穿。如果模型把"没退货"一律当作"合适"，那它学出来的分布一定会被这些灰色行为带偏。
我们清洗标签时做了一套"信号分级"：保留商品并且后续还有同品类复购的用户行为，视为高置信"合适"信号；退货单视为高置信"不合适"信号；没退货但也没复购的行为，权重直接降低一半。这个改动在离线评估里带来的提升非常显著，因为误差原本就大量集中在这类灰色样本上。顺便说一句，如果产品里已经有用户主动填写"穿着体验"的入口，那这种显式反馈的权重应该给到最高，它是比行为信号更干净的正样本。
4.3 离线评估：准确率不是唯一标准
尺码推荐如果只盯准确率，很容易自欺欺人。准确率反映的是"推荐结果和用户最终购买尺码是否一致"，但用户最终购买尺码可能受折扣、库存、个人习惯等因素干扰。我们实际用的核心离线指标是"加权准确率"：尺码跨度在一个段位内的判定权重为1，跨两个段位以上的错误权重加到2。这个设计是基于业务优先级的——推荐错一码还可以接受，推荐错两码用户基本就流失了。
第二个常用指标是top2命中率。用户下单页通常会给2到3个尺码选择，如果推荐结果包含正确尺码算作命中，top2命中率能到92%以上，说明至少不会让用户陷入"推荐的码根本穿不了"的尴尬。
4.4 线上实验：怎么设计才不被打脸
线上验证时如果只看转化率，很容易被各种因素干扰。尺码推荐真正要盯住的指标是：推荐尺码对应订单的退货率、二次购买率和尺码客诉率。我们当时做过一个双向AB实验：实验组展示算法推荐结果，对照组展示商品默认尺码，同时观察两组的退货率。
结论很有意思：实验组退货率下降了约1.5个百分点，这是好消息；但实验组里"用户主动忽略推荐尺码、自行选其他码"的比例反而上升了。原因不难理解，用户已经习惯了默认选项，突然弹出一个推荐码，她会下意识怀疑。这事儿提醒我们，推荐能力的建设不只是模型问题，还要配合前端UI的设计，让用户明白"这个推荐是从你的购买行为推断出来的"，信任感建立起来了，模型的效果才能真正释放。
5. 工程落地：把模型放进真实业务流
5.1 在线推理与缓存策略
尺码推荐其实不需要实时计算。用户的体重和购买记录不会每秒都变，商品尺码表也不会频繁更新，所以我们的架构是"离线训练、线上查询"。用户特征库和商品尺码库小时级刷新，模型输出结果天级刷新，并预计算好放进缓存，线上请求直接读缓存返回，单次服务延迟控制在几个毫秒内。
不过缓存策略有个容易被忽略的细节：不能把模型输出的原始尺码直接返回给前端，它必须先经过一个业务层做尺码校准。比如模型推荐L码，但目标商品只有M和XL有库存，这时候直接推L就是在误导用户。我们的业务层会做库存交集判断，推荐结果优先从"模型推荐、且有库存、且尺码跨度不超过一个段位"的集合里选。这个逻辑写在业务层而非模型层，保证模型可以专心学习用户和商品的特征关系，不用被实时库存这类易变信息干扰。
5.2 可解释性：让用户看到推荐理由
尺码推荐这种低频但决策关键的功能，用户不会盲目相信。我们在前端展示推荐结果时，同时给出结构化的推荐理由，比如"根据你近三个月的上装购买记录，你更多选择M码；此商品版型标准，建议尝试M码"，或者"你的身高体重数据位于M/L区间，考虑到该商品版型修身，推荐L码"。这套展示逻辑不只是为了提升用户体验，还有一个隐藏价值：记录用户的决策痕迹。如果用户看到了推荐理由仍然选择了其他尺码，系统就能把这次"偏差决策"记录下来，反哺后续模型迭代。
为了支持可解释性，模型层面也要做配合。GBDT这类树模型天然具备特征重要性的输出能力，我们按特征贡献度排序，把排名前两位的特征对应的文案模板拼接到推荐理由里。不需要复杂的可解释性模型，一套文案模板加特征重要性排序就够用了。
5.3 跨团队协作：商品数据质量和推荐效果强相关
做尺码推荐最难的其实不是算法规避坑，而是建立一套商品级别的数据流程。很多商品管理团队在录入尺码表时，只填了S/M/L，完全没有数字化区间和版型字段。如果上游数据是脏的，下游模型怎么调都没用。
我们的做法是在商品创建环节增加必填的数字化尺码区间和版型标签，并配置自动校验规则：如果填写的尺码区间和同类目其他商品差异超过一定阈值，系统直接给商品管理端发预警。这个动作对推荐效果的提升甚至比我们在模型层加班调参更明显。说到底，推荐系统的上限是由数据质量决定的，算法只是在逼近这个上限。与其在模型复杂度上内卷，不如把商品数据的标准先立起来。
6. 项目复盘：失败方案与踩坑记录
6.1 错误一：试图用一个模型覆盖全部品类
项目早期，我们为了管理和维护方便，做了一个"全品类统一模型"，结果被现实狠狠打脸。连衣裙、牛仔裤、羽绒服、贴身内衣的尺码逻辑差异太大：羽绒服要预留宽松量用户才能穿进内搭，连衣裙对腰围和裙长极度敏感，内衣几乎只靠胸围和罩杯公式。统一模型把所有这些差异揉进特征一试，效果非常平庸，而且很难定位是哪类数据在拖后腿。
换成分品类小模型之后，每个模型的特征空间和训练标签都更聚焦：上装看胸围肩宽，下装看腰围臀围，连衣裙专门加了裙长作为额外特征，效果立刻提升。教训就是：宁可先按上装、下装、连衣裙、外套四类各搞一个小模型，也不要贪图省事做一个大而全的统一模型。
6.2 错误二：把大量工程资源投到模型复杂度上
另一段弯路是我们曾想着一步到位，把工程资源大量投在跑深度模型上。前期离线指标看起来非常好，团队一片乐观，最后一分析才发现根本原因不在模型强，而是训练集里塞满了大量重复购买同一商品的用户——模型直接学会了"上次买过这个码就推荐这个码"，相当于把作弊答案背了下来。
换一批新商品做测试，效果立刻崩盘。这件事教会我们：离线验证一定要做时序切分，训练集只取某时间点前的数据，测试集取之后的数据，并且要把同一用户对同一商品的重复样本单独剔除。只有在这种设定下仍然表现稳定的模型，才具备真实的泛化能力。
6.3 迭代方向：向"尺码商品卡位"延伸
到后期，我们不再只满足于在用户维度上预测尺码，而是把视角转向商品维度，评估"这个SKU的尺码结构是否合理"。做法是统计每款商品的尺码销量分布和用户群体的身高体重分布，计算两者之间的错配程度。如果某款连衣裙的销量集中在M和L，但库存却压在S和XL，那就说明商品企划阶段定尺码结构就没有对齐用户需求。
更实用的是用这个分析结果反哺设计师和版房：如果某个品类在一段时间内持续出现"偏小"的反馈，系统会生成量化提示，比如"近30天该品类建议尺码比实际版型大一个段位"，供版房改进。这一步做完，尺码推荐就不再是一个单纯的线上转化工具，而是成了连接用户需求和生产端的传感器。现在回想起来，尺码推荐这个项目的价值，最大的部分其实不是那个推荐模型本身，而是它迫使整个团队把用户身体数据、商品尺码数据、供应链库存数据真正打通的这个过程。
