目录
背景介绍
推荐系统
平台推荐
总结
系统现状
总结

背景介绍

推荐系统

目标:展示用户最感兴趣的内容
策略:热门、关联关系、协同过滤
阶段划分:召回→排序(粗排-精排)
技术手段:索引(正排/倒排/向量相似度等)、机器学习(XGB/LR/NN等)、干预规则(过滤/调权/打散/强插等)
评价机制:AB实验
评价指标:商业指标(CTR、CVR等)

平台推荐

推荐主要业务包含首页、相关、酒旅、push,见下表。

业务 子展位 展位
首页 猜你喜欢 单品推荐
image.png
主题推荐
image.png
image.png
内容
image.png
其他tab 大牌&附近好店
image.png
相关推荐 到餐 POI详情页 Deal详情页
外卖 订单详情页
酒店 POI详情页 订单详情页
境内游 POI详情页 支付成功页
大交通 机票订单详情页 火车票订单详情页
到综 POI详情页
image.png
Deal详情页
image.png
金融 支付页
image.png
猫眼 订单详情页
团APP 订单列表页
image.png
收藏列表页
image.png
地图页
image.png
酒旅推荐 猜你喜欢 image.png
push推荐 image.png

总结

  • 业务:首页推荐、相关推荐、酒旅推荐、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生产链路
系统架构 image.png image.png
基础能力 策略开发
- 推荐服务框架recommend-framework,规定了前置process、主召回/排序逻辑、后置process三个阶段

召回
- 自研的分布式索引平台,支持正排/倒排/向量检索
排序
- 特征平台uds
- 特征抽取框架StrategyFlow,graph化抽象,算法自助开发和配置
- MLX模型预测
| 策略开发
- 策略开发框架pipeline,可组装串/并行pipe,每个pipe由算法实现init、process等方法,
- 策略开发工具utils,包含第三方依赖client、数据处理封装、日志监控埋点工具等
召回
- KV + MLX
排序
- KV + MLX
| | 业务流程 | image.png |

image.png前处理
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. 监控埋点、日志等
| | 数据 | image.png | image.png | | 策略迭代 | 开发:
- 开发相关数据表
- 索引构建、模型训练
- 开发特征抽取逻辑
- 开发各阶段策略的processor逻辑
- 配置策略依赖关系、排序模型、实验流量等
- 部署:使用飞流(内部发布系统,集成teamcity)
- 自测:remote debug或debug平台
- 自压测
预发布(每天定时):
- 工程PR值周:
- 审完PR合并分支
- 算法预发布值周:
- 部署
- 进行回归测试、对比压测
- 工程评审
上线(每天定时):
- 工程上线值周同学通过PLUS上线
| 开发:
- 开发相关数据表
- 索引构建、模型训练
- 开发特征抽取逻辑
- 开发各阶段策略的processor逻辑
- 配置策略依赖关系、排序模型、实验流量等
- 部署:管理平台,提交策略,策略即发布
- 自测:remote debug或debug平台
预发布(随时):
- 提交新策略至预发环境,进行对比压测(算法自助)
上线(随时):
- 提交新策略至生产环境(算法自助,须工程同学评审)
|

总结

首页和push的建设中,都对应用层、核心逻辑层做了分离。在组织协同上,应用层主要对接PM,核心逻辑层主要对接算法,协作较为高效。
在基础能力上,由于首页推荐场景更复杂、迭代更频繁,在策略开发、召回、排序等基础能力上更为完善,如:

  • 干预平台对人工规则类的策略做了更好的封装
  • 索引平台支持更快捷的索引构建、数据检索、向量检索
  • 特征管理和基于graph的特征抽取框架

在业务使用、系统运维上,由于push建设较晚,选择了更为流行的serverless架构,相比于首页推荐的微服务架构,业务策略可随时迭代上线;工程同学只关注容器稳定性,运维压力相对较小(前提:业务策略需要规范和流程约束)。

《业务研习》_美团外卖.pptx