1. 为什么我给电商项目加了这套推荐系统前阵子帮某电商团队做技术方案聊到首页转化率上不去的问题。打开后台一看运营还在手动配置“热销TOP10”和“小编推荐”两个固定位用户进来看到的商品几乎是一样的。问题很明显同一个喜欢户外装备的老用户和另一个只买母婴用品的用户看到同样的推荐位兴趣匹配度自然很低。这不是运营不努力而是人工维护推荐位的方式根本做不到“千人千面”。当时项目后端用的是ThinkPHP前端是Vue技术栈已经定型不太可能为了推荐系统单独上一套Python服务。我希望在不推翻现有架构的前提下嵌入一套基于机器学习的商品推荐能力。很多人一听“机器学习电商推荐”第一反应是“这得用大规模分布式计算吧”其实对于中小型电商系统来说完全可以在ThinkPHP和Vue这套常规技术栈里落地一个实用的推荐引擎关键是选对算法、理顺数据流、合理拆分离线训练和在线推理。这篇内容就是当时整个设计和实现过程的复盘包括架构怎么搭、协同过滤模型怎么训练、模型怎么和ThinkPHP对接、前端推荐位怎么做、以及上线之后踩过的几个坑。适合正在用PHP技术栈做电商、又想给系统加上个性化推荐能力的团队参考也适合想了解推荐系统完整落地流程的开发者阅读。2. 整体架构设计离线训练与在线推理分离2.1 一条数据要分成“采集-计算-服务”三个阶段推荐系统看起来是个实时响应的东西实际上真正吃性能的计算并不适合放在用户请求链路里。我在设计时把整个系统切成了三层数据采集层、离线计算层、在线服务层。数据采集层负责接收用户行为。用户在商品详情页停留、点击了某个推荐位、把商品加入购物车这些都是信号。前端把行为数据通过接口异步上报ThinkPHP接收后写入行为日志表。这里不存在实时推荐的计算压力只要保证日志能稳定落库就行。离线计算层是整个推荐系统的核心大脑。我选择用Python脚本定期跑模型训练脚本从数据库读取用户行为数据计算商品相似度矩阵生成用户推荐列表最后把结果写回MySQL或者Redis。整个过程和ThinkPHP主服务完全解耦训练脚本可以放在服务器上由定时任务触发也可以放在独立机器上跑完再同步结果。在线服务层才是用户真正感受到的部分。用户打开首页时Vue前端调用ThinkPHP的推荐接口ThinkPHP从Redis或数据库里直接取出该用户的推荐商品列表返回。这个接口必须足够快因为路径上不涉及复杂计算只是在查预计算结果。2.2 ThinkPHP和Python脚本的分工边界这个设计有个很重要的原则ThinkPHP不做矩阵运算Python不做在线接口。PHP作为Web后端擅长的是接收请求、处理业务、读写数据库Python生态里有NumPy、SciPy、scikit-learn这些成熟的机器学习库做相似度计算和矩阵分解要比PHP方便得多。两者各干各的通过数据库表和文件来交换数据耦合度很低。我当时在做方案时考虑过两种集成方式。第一种是用Python写一个独立的推荐服务ThinkPHP通过HTTP调用它第二种就是上面说的离线计算结果落库ThinkPHP直接查库。对比下来第二种更稳妥。原因很简单电商项目本身QPS不算高但可用性要求很严格多一个Python推理服务就多一个故障点。预计算结果存储在Redis里推荐接口的响应基本就是一次缓存查询稳定性和性能都有保证。2.3 数据表设计行为记录与模型结果的存储整个系统的数据表不需要设计得太复杂但有几张表必须提前想清楚。用户行为日志表记录了每次行为的时间、用户ID、商品ID、行为类型。行为类型我分了浏览、点击、收藏、加购、下单五种每种赋予不同权重。采集阶段最简单的方式是直接在现有的业务表里加字段但如果业务量大建议独立建一张行为流水表方便离线脚本全量读取。模型结果表用于存储每个用户的推荐列表。字段结构大致是用户ID、推荐商品ID集合、推荐分、生成时间。如果用户量在十万级以内可以直接存JSON字符串如果用户量再大建议拆成用户推荐明细表一个用户一行记录一个推荐位。商品相似度表存的是“商品A和商品B的相似度值”这是协同过滤算法离线算出来的中间结果。这张表在在线服务阶段不一定直接暴露给用户请求但它用于生成候选集和解释推荐理由时非常有用。这些表设计好之后前面说的三层架构就有了数据基础。下一步要解决的是核心问题相似度矩阵到底怎么算出来。3. 核心算法选型为什么用物品协同过滤而不是矩阵分解3.1 推荐系统算法谱系里的务实选择机器学习应用到推荐领域常用算法大致有三类基于内容的推荐、协同过滤推荐、以及混合推荐。基于内容推荐靠商品属性标签做匹配比如商品属于“户外”分类就给用户推荐同分类商品协同过滤不依赖商品属性只看用户行为“买了A的人也买了B”就是典型的物品协同过滤思想。我最终选择的是基于物品的协同过滤Item-Based Collaborative Filtering选它不是因为高大上而是因为它最适合中小电商的实际数据情况。用户协同过滤要计算用户之间的相似度在用户量增长后矩阵会非常庞大计算成本呈指数上升而物品协同过滤计算的是商品之间的相似关系电商平台商品数量相对用户数量稳定得多计算开销更可控。矩阵分解比如SVD理论上效果更好能解决稀疏性问题但它有两个实际门槛一是训练参数调节复杂隐含因子数量、正则化系数都要调没有专业算法工程师在团队里很难达到理想效果二是模型更新频率不好控制对于商品频繁上下架的电商场景矩阵分解的实时性反而不如物品协同过滤。3.2 相似度计算的完整思路物品协同过滤的核心是计算商品之间的相似度矩阵。流程并不复杂第一从行为日志表中提取“用户-商品”交互数据构建用户行为矩阵。行是用户列是商品单元格的值是用户对商品的综合行为得分。第二根据用户行为矩阵计算商品与商品之间的相似度。这里用最常用的余弦相似度公式商品A和商品B的相似度等于“同时购买或点击A和B的用户数”除以“购买或点击A的用户数与购买或点击B的用户数的几何平均”。听起来抽象翻译成SQL就是统计两个商品共同出现在多少个用户的行为列表里。第三对每个商品筛选出相似度最高的TopN个商品写入商品相似度表。这个计算的完整代码我当时用Python实现的核心逻辑大概是这样import pandas as pd from sklearn.metrics.pairwise import cosine_similarity # 读取用户行为数据 df pd.read_sql(SELECT user_id, item_id, score FROM user_item_score, engine) # 构造用户-商品矩阵 user_item_matrix df.pivot_table(indexuser_id, columnsitem_id, valuesscore).fillna(0) # 计算商品之间的余弦相似度 item_similarity cosine_similarity(user_item_matrix.T) item_similarity_df pd.DataFrame(item_similarity, indexuser_item_matrix.columns, columnsuser_item_matrix.columns)实际运行中要注意一个细节如果直接把所有商品两两计算相似度N个商品就是N的平方量级计算商品数量两三万时还能接受到了十万以上就会非常慢。建议先用热门商品筛选缩小候选集只对行为量达到阈值的商品建索引。3.3 行为权重设计不是所有行为都等价在构造用户行为矩阵时最关键的细节是行为权重的设定。用户的“加购”行为和“浏览”行为对推荐的意义完全不同。我当时采用的经验值如下行为类型权重说明浏览1最基础的兴趣信号点击推荐位2代表用户主动关注权重略高于浏览收藏3兴趣增强信号加购4强购买意图下单5最强正向信号但数据量较少每类行为的得分加总后还可以做一个时间衰减。三个月前的购买行为和一周前的浏览行为重要性应该不一样。我在脚本里加了一个简单的衰减函数得分乘以0.5^(距今月数/3)让最近的兴趣占主导。这个升级很实用周末上新的商品很快就能进入推荐池而不是被历史热门永远压住。4. 混合召回策略一个模型解决不了所有问题4.1 召回层的三层设计如果只依赖协同过滤模型出推荐结果上线后很快会发现两个问题新用户没有行为数据模型给不出推荐长尾商品得不到曝光机会活跃商品总是被反复推荐。所以我在召回策略上做了三层设计第一层是协同过滤召回基于离线训练的商品相似矩阵找出用户历史行为商品的相似商品作为核心个性化推荐。第二层是热门商品召回统计最近7天全站下单和加购排名前100的商品过滤掉用户已经购买过的按热度排序补充。这一层主要解决冷启动问题。第三层是新品加权召回新品上架后没有足够的行为数据协同过滤很难覆盖。我把上架时间在7天内的商品单独拉一个列表给予一定权重随机混入推荐位。三层结果合在一起后还要做一次去重和过滤。用户已经购买过的商品、已经下架的商品、以及用户明确不感兴趣的标签类别都要从候选集中剔除。4.2 排序层的选择规则打分还是LR模型召回层给出的是一两百个候选商品推荐位只能展示10个必须有个排序逻辑。排序可以简单粗暴地用规则打分也可以训练一个逻辑回归模型。我当时第一版用的是规则打分公式综合分 协同过滤得分×0.6 热门度×0.2 新品加权×0.2 随机扰动×0.1。随机扰动这个值很重要它保证推荐位不是绝对稳定用户刷新几次之后能看到一些变化避免推荐位死气沉沉。上线跑了一段时间之后团队希望进一步提升点击率我引入了逻辑回归排序模型。特征向量包含用户维度的历史点击率、历史转化率、该商品类别偏好度商品维度的近7天热度、好评率、价格区间以及上下文的时间段特征。我用Python的scikit-learn训练了一个LR模型把从规则打分时候积累的行为日志作为训练样本打标签点击为正样本曝光未点击为负样本训练完成后把模型系数导出成JSON文件。ThinkPHP在推荐接口里加载这个JSON文件对候选商品做一个简单的评分排序。{ features: [user_clk_rate, item_hot_score, cat_affinity, price_level, hour_sin, hour_cos], coef: [0.32, 0.18, 0.25, -0.11, 0.08, 0.02], intercept: -0.05 }这里有一个非常关键的点LR模型的部署不需要Python环境。ThinkPHP读取JSON系数后直接做一次线性加权计算响应时间几乎不受影响。这正好呼应了前面说的“PHP不做矩阵运算”的边界。5. ThinkPHP接口设计与推荐业务逻辑封装5.1 推荐接口返回什么数据推荐接口的设计直接决定了前端好不好用。我定义了一个统一的推荐V1接口路径大致是/api/v1/recommend/list参数包含用户标识、场景类型首页推荐、详情页相似推荐、购物车猜你喜欢、返回数量。返回的数据结构如下{ code: 0, data: { scene: home, items: [ { item_id: 1024, title: 户外双肩包, price: 199.00, cover: https://cdn.example.com/1024.jpg, reason: 因为你看过类似商品, track_id: exp_001 } ], track_id: search_20250101 } }其中reason字段用于前端展示推荐理由track_id用于追踪每次推荐请求的来源方便后续做效果分析这是一个容易被忽略但很重要的设计。5.2 接口内部是如何处理缓存与兜底的ThinkPHP推荐接口的核心逻辑不复杂但有一个细节值得单独说缓存层必须区分“无推荐结果”和“数据过期”两种情况。我当时在Redis里存每个用户的推荐列表Key的设计是recommend:user:{uid}:{scene}Value存JSON字符串过期时间设为30分钟。用户请求过来时先查Redis命中就直接返回如果没有命中则从MySQL的推荐结果表查询再回填Redis。有一个边界情况我最早没有处理好如果一个用户确实没有任何推荐结果比如一个从未产生行为的新用户缓存里存空数组下一次请求还是会穿透到数据库。后来我在Redis里把空结果也缓存住但设置一个更短的过期时间。这种方法叫“空值缓存”能有效防止数据库被无效查询打爆。接口的兜底逻辑是如果Redis和MySQL都没有推荐结果就返回全站热销榜。无论如何不能让用户看到一个空推荐位宁可推荐不精准也不能让页面露出空白区域。这是电商推荐系统里的一条底线。5.3 行为上报接口与异步处理推荐系统要靠数据持续迭代所以行为上报接口和推荐接口同等重要。前端每次曝光和点击推荐位时会调用/api/v1/recommend/report接口上报事件。上报接口接收的参数包括用户ID、商品ID、推荐场景、行为类型、track_id、时间戳。为了不影响主业务接口性能我在ThinkPHP中使用异步任务队列来处理上报数据先写入内存队列再由后台进程批量消费写入行为日志表。这个设计在高并发场景下尤其重要否则打爆数据库的不是用户浏览主页面而是埋点上报。这里顺便推荐一个做法上报接口最好和推荐接口放在同一个子域名下避免跨域问题。线上环境前端的请求会比较多控制好上报频率也很有必要。我当时在前端做了批量上报收集到5条事件或5秒之内合并发送一次。6. Vue前端推荐位的组件化设计与埋点实现6.1 推荐位组件如何拆分前端部分我用Vue 3配合Composition API实现。推荐位不是一个简单的列表而是一个包含加载状态、错误重试、空数据兜底、曝光埋点、点击跳转等多个行为的复杂组件。拆分成三层结构比较合理最外层是页面容器负责调用接口获取推荐数据中间层是推荐卡片列表负责循环渲染每个商品卡片最内层是单个商品卡片组件负责展示商品信息并执行埋点上报逻辑。template div classrecommend-section h3{{ sceneTitle }}/h3 div v-ifloading classrecommend-loading加载中.../div div v-else-ifitems.length classrecommend-list RecommendCard v-foritem in items :keyitem.item_id :itemitem clickhandleClick / /div div v-else classrecommend-empty暂无推荐/div /div /template组件化的好处是首页、详情页、购物车页可以复用同一套推荐组件只需要通过props传入不同的场景类型和商品上下文即可。6.2 曝光埋点最容易做错的一步曝光埋点不能简单地理解为“组件加载时就上报”因为用户可能根本没滑到推荐位区域。我在组件里引入了IntersectionObserver当推荐位真正出现在视口内时才触发曝光上报。推荐位的曝光数据是后续判断推荐效果的基础如果曝光数据不准点击率计算出来就是错的。一个常见的坑是在onMounted里直接上报曝光结果用户在页面底部根本没看到推荐位系统却记录了一次曝光导致点击率虚低。这个错误在排查点击率偏低问题时非常迷惑人。用IntersectionObserver后推荐位的曝光上报会在元素进入视口且停留超过300毫秒时才触发。6.3 千人千面场景下的前端性能控制首页一次返回20个推荐商品每个商品卡片有几张图片如果同时加载会导致页面首屏明显变慢。我在前端做了按需渲染页面滑动到推荐位附近才开始创建商品卡片的DOM同时图片使用懒加载只加载当前视口内的图片资源。另一方面推荐位数据的请求时机也值得注意。首页推荐位可以和页面主数据同时发起请求但不能阻塞主渲染流程。我通常把推荐系统数据请求放到了nextTick之后执行这样即使推荐接口偶发慢请求也不会拖累首屏速度。7. 上线后的踩坑记录与调优过程7.1 数据稀疏导致的“推荐灾难”推荐系统上线第一周模型训练出来的结果看起来没问题但线上反馈很快来了很多用户看到推荐位上的商品和自己八竿子打不着。排查发现行为日志表里超过百分之八十的用户只有一两次浏览记录协同过滤算法在这类稀疏数据上几乎失效相似度计算出来全是噪声。这个问题的根本原因不是算法选错了而是数据量积累不够。解决办法是降低协同过滤在排序中的权重提高热销商品的兜底比例。等数据积累到一定量级后协同过滤的权重再逐渐提升。我在设计系统时给排序公式预留了权重开关就是为了应对这种上线初期的数据冷启动阶段。7.2 相似度矩阵计算的性能瓶颈商品数量到五万之后离线训练脚本跑一次的时间从几分钟延长到了半小时。检查发现是余弦相似度的计算没有做剪枝。用户行为矩阵95%以上都是零全量计算浪费巨大。优化方案有两个一是只对“同时被N个以上用户共同交互过”的商品对计算相似度过滤掉零共现商品对二是利用物品共现矩阵代替全量用户矩阵做计算。第二项优化效果非常明显计算量从N的平方降到了实际有共现关系的商品对数量训练时间缩短到原来的十分之一以内。7.3 推荐位点击率不升反降的排查链路系统上线两周后运营反馈推荐位点击率比之前人工配置的时候还低。这个反馈很打击人但也促使我做了一次完整的排查。排查链路大致如下先看曝光量和点击量的绝对值发现曝光量增加了三倍点击量没有同步增加所以点击率被摊薄了。也就是说新的推荐位确实展示给了更多人但其中大量曝光给到了本来对推荐位兴趣较低的用户。接下来查看不同用户群体的分群CTR老用户的点击率其实高于之前新用户的点击率拉低了整体值。这个结果表明推荐系统本身没有做错只是新用户冷启动问题放大了。解决办法是在排序模型中加入用户活跃度特征对低活跃度用户提高热销商品权重。调整后整体点击率逐步回升而且比人工配置时期最高值高出约15%。8. 推荐效果怎么评估离线指标与线上验证8.1 离线评估的三个核心指标模型更新或算法调整之后不能直接上线看运气。我会在离线脚本里固定输出三个指标第一个是召回率测试集里用户真实交互过的商品有多少比例出现在推荐列表中。第二个是精确率推荐列表里的商品有多少是用户确实感兴趣的。第三个是覆盖率推荐系统覆盖了多少商品品类覆盖率太低说明推荐结果太集中不利于长尾商品分发。这三个指标可以在训练脚本跑完后自动生成报告作为模型迭代是否值得上线的判断依据。我给自己定了一个标准新模型在精确率不低于旧模型的条件下覆盖率提升超过10%才考虑灰度上线。8.2 线上验证灰度发布与对照实验推荐算法迭代最忌讳全量一刀切。我采用的方式是用户级灰度通过用户ID取模10%的用户走新推荐规则90%的用户走旧规则运行一周后对比两组用户的点击率、加购率、支付转化率。对比时要注意排除时间因素干扰。比如双十一大促期间全体用户转化率都在涨不能用新组数据直接对比历史数据必须用同期的对照组横向比较。这个实验设计的思路虽然朴素但对中小电商团队来说足够实用。8.3 模型更新频率与推荐多样性的平衡模型不可能每天训练一次。我当时按实际情况设置了三种更新策略。相似度矩阵是相对稳定的每周更新一次即可用户推荐列表对实时性要求更高每天凌晨增量更新热门商品排行榜每6小时更新一次配合Redis缓存过期时间控制。同一个用户在一天之内看到的推荐位也不应该完全一样。我在排序公式里加入了随机扰动项并保证同一商品连续两次请求之间的展示间隔尽量拉大。适度多样性不仅不会降低点击率反而会因为新鲜感提升用户停留时间这在电商场景里是一个值得长期优化的方向。9. 最后分享一点实践心得整个项目从设计到上线前后大约花了一个多月。最深的体会是推荐系统的核心价值不在于用了多高深的算法而在于把数据采集、离线训练、在线服务、效果反馈这几个环节串成一个闭环并且保证每条链路都能稳定运转。如果你正准备在自己的电商系统里加入推荐能力我的建议是先别急着追求深度学习模型从物品协同过滤加上热销兜底做起。这套方案在ThinkPHP和Vue的技术栈里落地成本可控而且能让你在真实流量中积累行为数据。等到数据量足够多、业务场景足够复杂之后再逐步引入更复杂的排序模型这样的演进路径是最稳妥的。
1. 为什么我给电商项目加了这套推荐系统前阵子帮某电商团队做技术方案聊到首页转化率上不去的问题。打开后台一看运营还在手动配置“热销TOP10”和“小编推荐”两个固定位用户进来看到的商品几乎是一样的。问题很明显同一个喜欢户外装备的老用户和另一个只买母婴用品的用户看到同样的推荐位兴趣匹配度自然很低。这不是运营不努力而是人工维护推荐位的方式根本做不到“千人千面”。当时项目后端用的是ThinkPHP前端是Vue技术栈已经定型不太可能为了推荐系统单独上一套Python服务。我希望在不推翻现有架构的前提下嵌入一套基于机器学习的商品推荐能力。很多人一听“机器学习电商推荐”第一反应是“这得用大规模分布式计算吧”其实对于中小型电商系统来说完全可以在ThinkPHP和Vue这套常规技术栈里落地一个实用的推荐引擎关键是选对算法、理顺数据流、合理拆分离线训练和在线推理。这篇内容就是当时整个设计和实现过程的复盘包括架构怎么搭、协同过滤模型怎么训练、模型怎么和ThinkPHP对接、前端推荐位怎么做、以及上线之后踩过的几个坑。适合正在用PHP技术栈做电商、又想给系统加上个性化推荐能力的团队参考也适合想了解推荐系统完整落地流程的开发者阅读。2. 整体架构设计离线训练与在线推理分离2.1 一条数据要分成“采集-计算-服务”三个阶段推荐系统看起来是个实时响应的东西实际上真正吃性能的计算并不适合放在用户请求链路里。我在设计时把整个系统切成了三层数据采集层、离线计算层、在线服务层。数据采集层负责接收用户行为。用户在商品详情页停留、点击了某个推荐位、把商品加入购物车这些都是信号。前端把行为数据通过接口异步上报ThinkPHP接收后写入行为日志表。这里不存在实时推荐的计算压力只要保证日志能稳定落库就行。离线计算层是整个推荐系统的核心大脑。我选择用Python脚本定期跑模型训练脚本从数据库读取用户行为数据计算商品相似度矩阵生成用户推荐列表最后把结果写回MySQL或者Redis。整个过程和ThinkPHP主服务完全解耦训练脚本可以放在服务器上由定时任务触发也可以放在独立机器上跑完再同步结果。在线服务层才是用户真正感受到的部分。用户打开首页时Vue前端调用ThinkPHP的推荐接口ThinkPHP从Redis或数据库里直接取出该用户的推荐商品列表返回。这个接口必须足够快因为路径上不涉及复杂计算只是在查预计算结果。2.2 ThinkPHP和Python脚本的分工边界这个设计有个很重要的原则ThinkPHP不做矩阵运算Python不做在线接口。PHP作为Web后端擅长的是接收请求、处理业务、读写数据库Python生态里有NumPy、SciPy、scikit-learn这些成熟的机器学习库做相似度计算和矩阵分解要比PHP方便得多。两者各干各的通过数据库表和文件来交换数据耦合度很低。我当时在做方案时考虑过两种集成方式。第一种是用Python写一个独立的推荐服务ThinkPHP通过HTTP调用它第二种就是上面说的离线计算结果落库ThinkPHP直接查库。对比下来第二种更稳妥。原因很简单电商项目本身QPS不算高但可用性要求很严格多一个Python推理服务就多一个故障点。预计算结果存储在Redis里推荐接口的响应基本就是一次缓存查询稳定性和性能都有保证。2.3 数据表设计行为记录与模型结果的存储整个系统的数据表不需要设计得太复杂但有几张表必须提前想清楚。用户行为日志表记录了每次行为的时间、用户ID、商品ID、行为类型。行为类型我分了浏览、点击、收藏、加购、下单五种每种赋予不同权重。采集阶段最简单的方式是直接在现有的业务表里加字段但如果业务量大建议独立建一张行为流水表方便离线脚本全量读取。模型结果表用于存储每个用户的推荐列表。字段结构大致是用户ID、推荐商品ID集合、推荐分、生成时间。如果用户量在十万级以内可以直接存JSON字符串如果用户量再大建议拆成用户推荐明细表一个用户一行记录一个推荐位。商品相似度表存的是“商品A和商品B的相似度值”这是协同过滤算法离线算出来的中间结果。这张表在在线服务阶段不一定直接暴露给用户请求但它用于生成候选集和解释推荐理由时非常有用。这些表设计好之后前面说的三层架构就有了数据基础。下一步要解决的是核心问题相似度矩阵到底怎么算出来。3. 核心算法选型为什么用物品协同过滤而不是矩阵分解3.1 推荐系统算法谱系里的务实选择机器学习应用到推荐领域常用算法大致有三类基于内容的推荐、协同过滤推荐、以及混合推荐。基于内容推荐靠商品属性标签做匹配比如商品属于“户外”分类就给用户推荐同分类商品协同过滤不依赖商品属性只看用户行为“买了A的人也买了B”就是典型的物品协同过滤思想。我最终选择的是基于物品的协同过滤Item-Based Collaborative Filtering选它不是因为高大上而是因为它最适合中小电商的实际数据情况。用户协同过滤要计算用户之间的相似度在用户量增长后矩阵会非常庞大计算成本呈指数上升而物品协同过滤计算的是商品之间的相似关系电商平台商品数量相对用户数量稳定得多计算开销更可控。矩阵分解比如SVD理论上效果更好能解决稀疏性问题但它有两个实际门槛一是训练参数调节复杂隐含因子数量、正则化系数都要调没有专业算法工程师在团队里很难达到理想效果二是模型更新频率不好控制对于商品频繁上下架的电商场景矩阵分解的实时性反而不如物品协同过滤。3.2 相似度计算的完整思路物品协同过滤的核心是计算商品之间的相似度矩阵。流程并不复杂第一从行为日志表中提取“用户-商品”交互数据构建用户行为矩阵。行是用户列是商品单元格的值是用户对商品的综合行为得分。第二根据用户行为矩阵计算商品与商品之间的相似度。这里用最常用的余弦相似度公式商品A和商品B的相似度等于“同时购买或点击A和B的用户数”除以“购买或点击A的用户数与购买或点击B的用户数的几何平均”。听起来抽象翻译成SQL就是统计两个商品共同出现在多少个用户的行为列表里。第三对每个商品筛选出相似度最高的TopN个商品写入商品相似度表。这个计算的完整代码我当时用Python实现的核心逻辑大概是这样import pandas as pd from sklearn.metrics.pairwise import cosine_similarity # 读取用户行为数据 df pd.read_sql(SELECT user_id, item_id, score FROM user_item_score, engine) # 构造用户-商品矩阵 user_item_matrix df.pivot_table(indexuser_id, columnsitem_id, valuesscore).fillna(0) # 计算商品之间的余弦相似度 item_similarity cosine_similarity(user_item_matrix.T) item_similarity_df pd.DataFrame(item_similarity, indexuser_item_matrix.columns, columnsuser_item_matrix.columns)实际运行中要注意一个细节如果直接把所有商品两两计算相似度N个商品就是N的平方量级计算商品数量两三万时还能接受到了十万以上就会非常慢。建议先用热门商品筛选缩小候选集只对行为量达到阈值的商品建索引。3.3 行为权重设计不是所有行为都等价在构造用户行为矩阵时最关键的细节是行为权重的设定。用户的“加购”行为和“浏览”行为对推荐的意义完全不同。我当时采用的经验值如下行为类型权重说明浏览1最基础的兴趣信号点击推荐位2代表用户主动关注权重略高于浏览收藏3兴趣增强信号加购4强购买意图下单5最强正向信号但数据量较少每类行为的得分加总后还可以做一个时间衰减。三个月前的购买行为和一周前的浏览行为重要性应该不一样。我在脚本里加了一个简单的衰减函数得分乘以0.5^(距今月数/3)让最近的兴趣占主导。这个升级很实用周末上新的商品很快就能进入推荐池而不是被历史热门永远压住。4. 混合召回策略一个模型解决不了所有问题4.1 召回层的三层设计如果只依赖协同过滤模型出推荐结果上线后很快会发现两个问题新用户没有行为数据模型给不出推荐长尾商品得不到曝光机会活跃商品总是被反复推荐。所以我在召回策略上做了三层设计第一层是协同过滤召回基于离线训练的商品相似矩阵找出用户历史行为商品的相似商品作为核心个性化推荐。第二层是热门商品召回统计最近7天全站下单和加购排名前100的商品过滤掉用户已经购买过的按热度排序补充。这一层主要解决冷启动问题。第三层是新品加权召回新品上架后没有足够的行为数据协同过滤很难覆盖。我把上架时间在7天内的商品单独拉一个列表给予一定权重随机混入推荐位。三层结果合在一起后还要做一次去重和过滤。用户已经购买过的商品、已经下架的商品、以及用户明确不感兴趣的标签类别都要从候选集中剔除。4.2 排序层的选择规则打分还是LR模型召回层给出的是一两百个候选商品推荐位只能展示10个必须有个排序逻辑。排序可以简单粗暴地用规则打分也可以训练一个逻辑回归模型。我当时第一版用的是规则打分公式综合分 协同过滤得分×0.6 热门度×0.2 新品加权×0.2 随机扰动×0.1。随机扰动这个值很重要它保证推荐位不是绝对稳定用户刷新几次之后能看到一些变化避免推荐位死气沉沉。上线跑了一段时间之后团队希望进一步提升点击率我引入了逻辑回归排序模型。特征向量包含用户维度的历史点击率、历史转化率、该商品类别偏好度商品维度的近7天热度、好评率、价格区间以及上下文的时间段特征。我用Python的scikit-learn训练了一个LR模型把从规则打分时候积累的行为日志作为训练样本打标签点击为正样本曝光未点击为负样本训练完成后把模型系数导出成JSON文件。ThinkPHP在推荐接口里加载这个JSON文件对候选商品做一个简单的评分排序。{ features: [user_clk_rate, item_hot_score, cat_affinity, price_level, hour_sin, hour_cos], coef: [0.32, 0.18, 0.25, -0.11, 0.08, 0.02], intercept: -0.05 }这里有一个非常关键的点LR模型的部署不需要Python环境。ThinkPHP读取JSON系数后直接做一次线性加权计算响应时间几乎不受影响。这正好呼应了前面说的“PHP不做矩阵运算”的边界。5. ThinkPHP接口设计与推荐业务逻辑封装5.1 推荐接口返回什么数据推荐接口的设计直接决定了前端好不好用。我定义了一个统一的推荐V1接口路径大致是/api/v1/recommend/list参数包含用户标识、场景类型首页推荐、详情页相似推荐、购物车猜你喜欢、返回数量。返回的数据结构如下{ code: 0, data: { scene: home, items: [ { item_id: 1024, title: 户外双肩包, price: 199.00, cover: https://cdn.example.com/1024.jpg, reason: 因为你看过类似商品, track_id: exp_001 } ], track_id: search_20250101 } }其中reason字段用于前端展示推荐理由track_id用于追踪每次推荐请求的来源方便后续做效果分析这是一个容易被忽略但很重要的设计。5.2 接口内部是如何处理缓存与兜底的ThinkPHP推荐接口的核心逻辑不复杂但有一个细节值得单独说缓存层必须区分“无推荐结果”和“数据过期”两种情况。我当时在Redis里存每个用户的推荐列表Key的设计是recommend:user:{uid}:{scene}Value存JSON字符串过期时间设为30分钟。用户请求过来时先查Redis命中就直接返回如果没有命中则从MySQL的推荐结果表查询再回填Redis。有一个边界情况我最早没有处理好如果一个用户确实没有任何推荐结果比如一个从未产生行为的新用户缓存里存空数组下一次请求还是会穿透到数据库。后来我在Redis里把空结果也缓存住但设置一个更短的过期时间。这种方法叫“空值缓存”能有效防止数据库被无效查询打爆。接口的兜底逻辑是如果Redis和MySQL都没有推荐结果就返回全站热销榜。无论如何不能让用户看到一个空推荐位宁可推荐不精准也不能让页面露出空白区域。这是电商推荐系统里的一条底线。5.3 行为上报接口与异步处理推荐系统要靠数据持续迭代所以行为上报接口和推荐接口同等重要。前端每次曝光和点击推荐位时会调用/api/v1/recommend/report接口上报事件。上报接口接收的参数包括用户ID、商品ID、推荐场景、行为类型、track_id、时间戳。为了不影响主业务接口性能我在ThinkPHP中使用异步任务队列来处理上报数据先写入内存队列再由后台进程批量消费写入行为日志表。这个设计在高并发场景下尤其重要否则打爆数据库的不是用户浏览主页面而是埋点上报。这里顺便推荐一个做法上报接口最好和推荐接口放在同一个子域名下避免跨域问题。线上环境前端的请求会比较多控制好上报频率也很有必要。我当时在前端做了批量上报收集到5条事件或5秒之内合并发送一次。6. Vue前端推荐位的组件化设计与埋点实现6.1 推荐位组件如何拆分前端部分我用Vue 3配合Composition API实现。推荐位不是一个简单的列表而是一个包含加载状态、错误重试、空数据兜底、曝光埋点、点击跳转等多个行为的复杂组件。拆分成三层结构比较合理最外层是页面容器负责调用接口获取推荐数据中间层是推荐卡片列表负责循环渲染每个商品卡片最内层是单个商品卡片组件负责展示商品信息并执行埋点上报逻辑。template div classrecommend-section h3{{ sceneTitle }}/h3 div v-ifloading classrecommend-loading加载中.../div div v-else-ifitems.length classrecommend-list RecommendCard v-foritem in items :keyitem.item_id :itemitem clickhandleClick / /div div v-else classrecommend-empty暂无推荐/div /div /template组件化的好处是首页、详情页、购物车页可以复用同一套推荐组件只需要通过props传入不同的场景类型和商品上下文即可。6.2 曝光埋点最容易做错的一步曝光埋点不能简单地理解为“组件加载时就上报”因为用户可能根本没滑到推荐位区域。我在组件里引入了IntersectionObserver当推荐位真正出现在视口内时才触发曝光上报。推荐位的曝光数据是后续判断推荐效果的基础如果曝光数据不准点击率计算出来就是错的。一个常见的坑是在onMounted里直接上报曝光结果用户在页面底部根本没看到推荐位系统却记录了一次曝光导致点击率虚低。这个错误在排查点击率偏低问题时非常迷惑人。用IntersectionObserver后推荐位的曝光上报会在元素进入视口且停留超过300毫秒时才触发。6.3 千人千面场景下的前端性能控制首页一次返回20个推荐商品每个商品卡片有几张图片如果同时加载会导致页面首屏明显变慢。我在前端做了按需渲染页面滑动到推荐位附近才开始创建商品卡片的DOM同时图片使用懒加载只加载当前视口内的图片资源。另一方面推荐位数据的请求时机也值得注意。首页推荐位可以和页面主数据同时发起请求但不能阻塞主渲染流程。我通常把推荐系统数据请求放到了nextTick之后执行这样即使推荐接口偶发慢请求也不会拖累首屏速度。7. 上线后的踩坑记录与调优过程7.1 数据稀疏导致的“推荐灾难”推荐系统上线第一周模型训练出来的结果看起来没问题但线上反馈很快来了很多用户看到推荐位上的商品和自己八竿子打不着。排查发现行为日志表里超过百分之八十的用户只有一两次浏览记录协同过滤算法在这类稀疏数据上几乎失效相似度计算出来全是噪声。这个问题的根本原因不是算法选错了而是数据量积累不够。解决办法是降低协同过滤在排序中的权重提高热销商品的兜底比例。等数据积累到一定量级后协同过滤的权重再逐渐提升。我在设计系统时给排序公式预留了权重开关就是为了应对这种上线初期的数据冷启动阶段。7.2 相似度矩阵计算的性能瓶颈商品数量到五万之后离线训练脚本跑一次的时间从几分钟延长到了半小时。检查发现是余弦相似度的计算没有做剪枝。用户行为矩阵95%以上都是零全量计算浪费巨大。优化方案有两个一是只对“同时被N个以上用户共同交互过”的商品对计算相似度过滤掉零共现商品对二是利用物品共现矩阵代替全量用户矩阵做计算。第二项优化效果非常明显计算量从N的平方降到了实际有共现关系的商品对数量训练时间缩短到原来的十分之一以内。7.3 推荐位点击率不升反降的排查链路系统上线两周后运营反馈推荐位点击率比之前人工配置的时候还低。这个反馈很打击人但也促使我做了一次完整的排查。排查链路大致如下先看曝光量和点击量的绝对值发现曝光量增加了三倍点击量没有同步增加所以点击率被摊薄了。也就是说新的推荐位确实展示给了更多人但其中大量曝光给到了本来对推荐位兴趣较低的用户。接下来查看不同用户群体的分群CTR老用户的点击率其实高于之前新用户的点击率拉低了整体值。这个结果表明推荐系统本身没有做错只是新用户冷启动问题放大了。解决办法是在排序模型中加入用户活跃度特征对低活跃度用户提高热销商品权重。调整后整体点击率逐步回升而且比人工配置时期最高值高出约15%。8. 推荐效果怎么评估离线指标与线上验证8.1 离线评估的三个核心指标模型更新或算法调整之后不能直接上线看运气。我会在离线脚本里固定输出三个指标第一个是召回率测试集里用户真实交互过的商品有多少比例出现在推荐列表中。第二个是精确率推荐列表里的商品有多少是用户确实感兴趣的。第三个是覆盖率推荐系统覆盖了多少商品品类覆盖率太低说明推荐结果太集中不利于长尾商品分发。这三个指标可以在训练脚本跑完后自动生成报告作为模型迭代是否值得上线的判断依据。我给自己定了一个标准新模型在精确率不低于旧模型的条件下覆盖率提升超过10%才考虑灰度上线。8.2 线上验证灰度发布与对照实验推荐算法迭代最忌讳全量一刀切。我采用的方式是用户级灰度通过用户ID取模10%的用户走新推荐规则90%的用户走旧规则运行一周后对比两组用户的点击率、加购率、支付转化率。对比时要注意排除时间因素干扰。比如双十一大促期间全体用户转化率都在涨不能用新组数据直接对比历史数据必须用同期的对照组横向比较。这个实验设计的思路虽然朴素但对中小电商团队来说足够实用。8.3 模型更新频率与推荐多样性的平衡模型不可能每天训练一次。我当时按实际情况设置了三种更新策略。相似度矩阵是相对稳定的每周更新一次即可用户推荐列表对实时性要求更高每天凌晨增量更新热门商品排行榜每6小时更新一次配合Redis缓存过期时间控制。同一个用户在一天之内看到的推荐位也不应该完全一样。我在排序公式里加入了随机扰动项并保证同一商品连续两次请求之间的展示间隔尽量拉大。适度多样性不仅不会降低点击率反而会因为新鲜感提升用户停留时间这在电商场景里是一个值得长期优化的方向。9. 最后分享一点实践心得整个项目从设计到上线前后大约花了一个多月。最深的体会是推荐系统的核心价值不在于用了多高深的算法而在于把数据采集、离线训练、在线服务、效果反馈这几个环节串成一个闭环并且保证每条链路都能稳定运转。如果你正准备在自己的电商系统里加入推荐能力我的建议是先别急着追求深度学习模型从物品协同过滤加上热销兜底做起。这套方案在ThinkPHP和Vue的技术栈里落地成本可控而且能让你在真实流量中积累行为数据。等到数据量足够多、业务场景足够复杂之后再逐步引入更复杂的排序模型这样的演进路径是最稳妥的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
