背景介绍
推荐系统
目标:展示用户最感兴趣的内容
策略:热门、关联关系、协同过滤
阶段划分:召回→排序(粗排-精排)
技术手段:索引(正排/倒排/向量相似度等)、机器学习(XGB/LR/NN等)、干预规则(过滤/调权/打散/强插等)
评价机制:AB实验
评价指标:商业指标(CTR、CVR等)
平台推荐
推荐主要业务包含首页、相关、酒旅、push,见下表。
业务 | 子展位 | 展位 | ||
---|---|---|---|---|
首页 | 猜你喜欢 | 单品推荐![]() |
主题推荐![]() ![]() |
内容![]() |
其他tab | 大牌&附近好店![]() |
|||
相关推荐 | 到餐 | POI详情页 | Deal详情页 | |
外卖 | 订单详情页 | |||
酒店 | POI详情页 | 订单详情页 | ||
境内游 | POI详情页 | 支付成功页 | ||
大交通 | 机票订单详情页 | 火车票订单详情页 | ||
到综 | POI详情页![]() |
Deal详情页![]() |
||
金融 | 支付页![]() |
|||
猫眼 | 订单详情页 | |||
团APP | 订单列表页![]() |
收藏列表页![]() |
地图页![]() |
|
酒旅推荐 | 猜你喜欢 | ![]() |
||
push推荐 | ![]() |
总结
- 业务:首页推荐、相关推荐、酒旅推荐、push推荐等
- 业态:垂直/交叉
- 场景:本/异地、促销/非促销
- 内容:主题/内容(文章、评论)/单品(poi、deal)
系统现状
历史上,push推荐由平台技术中心建设,其他项目由推荐技术中心建设,形成两种架构风格。
现以首页和push两个典型系统为例,进行简要介绍。
首页推荐 | push推荐 | |
---|---|---|
业务介绍 | - 简介:美团APP首页推荐展位,包含猜你喜欢、今日特价、附近好店等 - 系统体量: - 日调用量:3亿 - 峰值:9k - 策略迭代:日均10~20 - 商品量级:召回后千级,粗排后百级 - 使用资源:约3000台16c32g - 系统环境: - 开发:staging - 预发布:prod灰度链路 - 线上:prod生产链路 |
- 简介:推荐push,推荐出用户最喜欢的商品,推送到用户的设备上,用户每天最多收到1条 - 系统体量: - 日调用量:8亿(API),10W+(落地页) - 峰值:2W - 策略迭代:日均1~2 - 商品量级:召回后百级,粗排后不到100 - 使用资源:约1000台8c16g - 系统环境: - 开发:staging - 预发布:prod灰度链路 - 线上:prod生产链路 |
系统架构 | ![]() |
![]() |
基础能力 | 策略开发 - 推荐服务框架recommend-framework,规定了前置process、主召回/排序逻辑、后置process三个阶段 |
召回
- 自研的分布式索引平台,支持正排/倒排/向量检索
排序
- 特征平台uds
- 特征抽取框架StrategyFlow,graph化抽象,算法自助开发和配置
- MLX模型预测
| 策略开发
- 策略开发框架pipeline,可组装串/并行pipe,每个pipe由算法实现init、process等方法,
- 策略开发工具utils,包含第三方依赖client、数据处理封装、日志监控埋点工具等
召回
- KV + MLX
排序
- KV + MLX
|
| 业务流程 | |
前处理
1. 数据预取
1. 用户画像和行为Session信息
1. (from StrategyFlow)click信息(1小时,6小时,24小时)、order信息(1小时,6小时,24小时)
1. (from Flame)30天pv, pv时长, order, 小白盒, 定位城市,商圈等长时间跨度信息
1. (from UPS)用户行为和属性 https://km.sankuai.com/page/206600650
1. (from request)用户实时信息
2. 获取物料详情、索引(from Boolean)
2. 数据组装,构建用户attention数据集、索引数据集
场景触发
1. 用户兴趣点
1. 基于用户行为(点击,下单,搜索,定位等)构建触发候选集
2. 榜单
1. 优惠、榜单类,无限制
召回
1. 模型召回:u2i、u2t,使用DSSM模型
1. KV索引:i2i,离线生成索引,存放在redis中,通过boolean访问
1. 直接召回:召回用户行为产生的deal+poi+关注点+榜单
过滤
- 根据不同策略对poi,deal的限制,进行过滤
排序
- LR模型,预估的ctr会进行统一矫正
后处理
1. 阈值过滤
1. topN截断
1. 监控埋点、日志等
|
| 数据 | |
|
| 策略迭代 | 开发:
- 开发相关数据表
- 索引构建、模型训练
- 开发特征抽取逻辑
- 开发各阶段策略的processor逻辑
- 配置策略依赖关系、排序模型、实验流量等
- 部署:使用飞流(内部发布系统,集成teamcity)
- 自测:remote debug或debug平台
- 自压测
预发布(每天定时):
- 工程PR值周:
- 审完PR合并分支
- 算法预发布值周:
- 部署
- 进行回归测试、对比压测
- 工程评审
上线(每天定时):
- 工程上线值周同学通过PLUS上线
| 开发:
- 开发相关数据表
- 索引构建、模型训练
- 开发特征抽取逻辑
- 开发各阶段策略的processor逻辑
- 配置策略依赖关系、排序模型、实验流量等
- 部署:管理平台,提交策略,策略即发布
- 自测:remote debug或debug平台
预发布(随时):
- 提交新策略至预发环境,进行对比压测(算法自助)
上线(随时):
- 提交新策略至生产环境(算法自助,须工程同学评审)
|
总结
首页和push的建设中,都对应用层、核心逻辑层做了分离。在组织协同上,应用层主要对接PM,核心逻辑层主要对接算法,协作较为高效。
在基础能力上,由于首页推荐场景更复杂、迭代更频繁,在策略开发、召回、排序等基础能力上更为完善,如:
- 干预平台对人工规则类的策略做了更好的封装
- 索引平台支持更快捷的索引构建、数据检索、向量检索
- 特征管理和基于graph的特征抽取框架
在业务使用、系统运维上,由于push建设较晚,选择了更为流行的serverless架构,相比于首页推荐的微服务架构,业务策略可随时迭代上线;工程同学只关注容器稳定性,运维压力相对较小(前提:业务策略需要规范和流程约束)。