企业官网建设流程全解析

说实话，干了这么多年电商推荐，最让我觉得“既麻烦又值钱”的需求，就是服装尺码推荐。你打开任意一个卖衣服的App，首页推荐点击率再高、详情页做再花哨，最后都逃不过一个问题：这件衣服到底买什么码？买小了穿不上，买大了像偷来的，退货率直接给你拉爆。

我做过一段零售电商侧的推荐系统，科技圈最爱吹“大数据赋能服装新零售”，实际落到项目里，核心就一件事：怎么用历史订单、身高体重、浏览行为这些数据，在用户下单前就尽可能猜中那个“穿上去刚刚好”的尺码。这个算法做得好了，用户不会感知到，但后台的退货率和换货率会有肉眼可见的变化。

这篇就是我在实际项目里做尺码推荐算法的一次完整复盘。适合正在做电商推荐、或者打算做服饰类商品体验优化的开发者和产品经理，尤其是被“尺码不准”“退货率高”折磨得不轻的同学。这里没有炫技，都是踩过坑之后的实操经验。

1. 这个项目到底解决什么问题

1.1 服装尺码不只是“S/M/L”三个字母

先说一个反常识的事实：服装尺码的标准，根本没有真正统一过。

同样是“L码”，不同品牌之间可能差出一个胸围的宽度；同样是牛仔裤，同一个品牌的不同系列，版型可能一偏紧一偏松；同一件衣服，你穿合身，我穿可能胸口勒得慌。尺码本身就不是一个物理上的绝对坐标，它是一个“版型+用户身材+主观喜好”三者博弈后的结果。

这就导致了一个结果：就算你身高体重一模一样，买同一个品牌的不同款式，你需要的尺码也可能完全不同。很多人以为尺码推荐AI就是查表，身高175cm体重70kg推荐L码，这种认知是大错特错的。真的这么简单，就不会有那么多七天无理由退货了。

我做这个项目的核心目标，就是压缩用户从“看到衣服”到“买到合身衣服”之间的试错成本。用户在选尺码的那个下拉框点开之前，我就能预判他大概率穿哪个码，而不是让用户反复买反复退，用运费和时间换合身。

1.2 不是不想推荐，是以前的推荐方式太粗了

我接触过不少电商团队，他们其实早就想过尺码推荐这件事，只是没做起来。我复盘了一下，半途而废的普遍原因有三个。

第一个原因是规则太简单。很多平台早期的尺码推荐就是一张身高体重映射表，称作“尺码对照表”：175/70对应L，165/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%以上的需求。

这里有个容易被忽略的点：版型标签。同样标着“L”，修身款和宽松款对应的实际合身人群完全不同。我见过一些团队为了省成本不做版型标注，认为模型能自己学出来，实际上不行，至少在小数据量下学不出来。我们当时的做法是让选品团队在录入商品时多一个“版型”字段，这是个低成本但收益很明显的投资。

3.2 模型选型：为什么不是神经网络

尺码推荐这个场景，最开始也有方案争夺。有同事提议上深度学习，用NN学用户和商品的embedding，听起来很fancy。但我最后选了梯度提升树（GBDT系列），理由很朴素：数据量撑不起深度学习。

一个用户一年才买多少次衣服？全平台看起来订单量大，但是切到“用户-商品-尺码反馈”这个粒度，每个用户的样本量就是个位数到两位数。深度学习在这种稀疏场景下很容易过拟合，而且调参成本高，线上推理资源压力也大。GBDT对中小规模表格数据非常友好，特征工程灵活，可解释性强，出了问题也更好排查。

我并不是说神经网络在这个领域完全没有用，之前也见过有人用双塔模型做类似事情，效果也不算差，但那是在订单密度很高的垂直服装平台上。对于一般电商平台，我强烈建议先从GBDT做起，把特征和标签弄干净，比选什么模型重要得多。模型永远是最后一个可以优化的环节，数据和特征才是决定上限的东西。

3.3 训练流程和样本构造细节

这里我给出一个可复用的训练流程。你要复现这个项目，按这个骨架来跑基本不会跑偏。

第一步，清洗样本。拉取近24个月的订单数据，过滤掉异常订单、刷单订单、秒杀订单和跨境代购订单。逐单标记：如果订单内商品被因“尺码不合适”退款或换货，标负例；如果确认收货且超过退货期无售后，标正例；退货原因不是尺码相关，直接删掉该条样本，不进入训练集。

第二步，构造特征。按前面那张特征表做特征工程，注意所有的用户特征必须在“下单时刻”之前截断，不能用未来信息。比如用户在某天买了件L码卫衣，那这个订单的特征里就不能包含他后面买的XL裤子的信息，否则会造成数据穿越，线上表现直接崩盘。

第三步，定义目标。我把目标定义为“该商品尺码偏移量”的分类问题：假设某商品尺码档位是S=0、M=1、L=2、XL=3、XXL=4，模型要预测的就是用户应该买第几档，或者输出一个置信度最高的偏移值。对于尺码档位，我直接映射成有序整数，用类似有序回归的建模思路来做。

第四步，训练与评估。GBDT框架我用的是LightGBM，训练一轮后看验证集上的准确率和分类AUC。评估指标上一节讲过，重点看“±1档以内准确率”，同时把“绝对匹配准确率”作为复盘参考。

我不会在这里贴一堆项目特有的代码，核心逻辑写个伪代码也就二十行：

# 模型核心逻辑示意 from lightgbm import LGBMClassifier # X: 用户特征 + 商品特征 + 上下文特征 # y: 尺码偏移目标（如 -1, 0, 1, 2 表示相对基准档位的偏移） model = LGBMClassifier( objective="multiclass", num_class=5, learning_rate=0.05, n_estimators=300, subsample=0.8, colsample_bytree=0.8, reg_lambda=1.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%，但修身裤这个细分类别的推荐反而变差了。拆分着看，才能发现哪些改动是真正在进步，哪些只是在平均数上投机。

这类的尺码推荐还能往前面延伸一步，比如结合商品的真实用户反馈数据，给每件衣服算一个“实际穿着放量偏差值”，把“按尺码表算出来该买什么码”和“用户真实穿着反馈算出实际该买什么码”之间的差量做出来，能进一步把尺码表不可靠的问题压到更低。那些售后反馈里最被忽略的信息，往往是这些算法项目里最值钱的金矿。