饿了么搜索推荐研发负责人马尧 - O2O搜索优化实践之道

富代玉

2017/11/14 发布于 技术 分类

外卖是当下最核心的O2O场景之一,搜索及推荐入口作为流量分配的中枢,面临着千万日活用户与百万商家及上亿美食精准匹配问题。本次分享将介绍饿了么搜索、推荐领域面临的特殊挑战,以及在架构、算法上的实践。

文字内容
1. O2O搜索优化实践之道 马尧 yao.ma02@ele.me
2. 概要 01 饿了么o2o搜索推荐业务介绍 02 饿了么o2o搜索推荐的特殊挑战 03 饿了么在工程和算法上的实践 04 一些感悟
3. 饿了么o2o搜索推荐介绍——业务形态 多入口来源 • 搜索入口 • 品类入口 • 首页列表 • 活动、会场入口... ⽤用户触达90%+ 多种产品形态 • 搜索、推荐、筛选 • 优惠、品质、效率 多品类 • 美食 • 果蔬生鲜 • 商超、鲜花、药店…
4. 饿了么o2o搜索推荐介绍——定位 ⽤用户 搜索推荐体验 决策价值 意图理理解 精准匹配 搜索推荐平台 流量量分配中枢 场景发现 智能排序 ⽤用户触达 曝光效率 商家 移动端交易易80%以上 流量量变现、交易易价值、⽣生态平衡
5. 饿了么o2o搜索推荐的特殊挑战—— vs 传统搜索 • 移动化——流量量订单基本全部来源于APP • 场景化——时段、地点、季节、天⽓气、⽤用户相关 • 本地化——⽤用户、商户信息皆是本地 • 短⽂文本(⽆无⽂文本) • 交易易相关 • ⾼高度闭环——信息反馈完整 VS
6. 饿了么o2o搜索推荐的特殊挑战—— vs 电商平台 • 优化链路路⻓长 • 浏览->点击->下单->运达 • 峰值效应明显 • ⾼高QPS;⽤用户⾏行行为分布变化快; • 即时资源约束 • 餐厅资源、⼈人⼒力力;配送运⼒力力; • 时间敏敏感 • 决策效率——快速帮助⽤用户决策 • 等待时间——端到端时间尽可能短 VS
7. 搜索推荐业务目标拆解 浏览 点击 下单 运达 ⽤用户体验提升,带来 更更多回访 搜索推荐是转化的核⼼心环节 智能化 搜索推荐 平台 精准优化 GMV=流量 * CTR * CVR * 客单价 满意度=决策效率 or 就餐体验 or 等待时间... 兼顾商户资源约束、运力约束
8. 搜索推荐业务架构 ⾸首⻚页列列 表 ⼊入⼝口列列 表 搜索 ⼊入⼝口 引导 关键 词搜 索 推荐 场景 化列列 表 运 营 会 场 业务 智能化Rank/场景发现/意图识别 策略略 运营 + ⽀支撑 平台 产品/业务策略略 平台 离线/在线 模型 ⽤用户/商户/菜品 挖掘 ⽂文本/标签 挖掘 特征⼯工程 ⼤大数据平台/机器器学习平台/AB测试引擎/
9. 饿了么在工程和算法上的实践 搜索、Rank技术 框架⻦鸟瞰 体验升级 Rank算法演进路路 线 ⼯工具化提升效率 01 02 03 04 05 ⼯工程升级 o2o分⽚片搜索 Rank⼯工程架构改进 实时数据体系与在 线学习
10. 一次搜索请求的流程 APP ⽤用户请求 BIZ 请求包装、业务逻辑 Rank 智能排序 Search 搜索召回
11. 搜索推荐技术架构 数据服务 在线服务 产品/业务层 智能搜索/ 排序层 数据/模型层 基础设施层 Context (用户、地理位置、查询内容) 竞价排名 新店轮播 业务锁定 运力平衡 查询分析/改写 场景识别/意图理解 搜索召回/排序/ 场景策略触发 搜索召回/Rank特征加载&模型排序 点击率预估、转化率预估、满意度预估 LR GBDT GBDT+LR FM Lambda Rank 商户基础质量 用户偏好 用户身份(新 (品类、价格、位置) 老) 点击率/转化率 距离模型 点击反馈 时段特征 地域特征 实时特征 Spark Hadoop Flume Kafka 查询理解 场景判断 实时数据服务 画像服务 特征服务 交叉/组合特征 Storm KV
12. ⼯工程挑战及升级
13. 工程升级——o2o分片搜索 挑战 • 百万商户、上亿商品、上百个属性 • 空间索引、餐厅索引、美⻝⾷食索引等多维度 索引 • 单节点性能受限于索引⼤大⼩小及复杂度 ⽅方案 • 基于商户配送范围进⾏行行分⽚片,根据⽤用户定位地址 进⾏行行路路由,横向拓拓展⽅方便便 • 单节点索引⼤大⼩小降为1/N,性能提升 • 集群的并发能⼒力力提升 APP ⽤用户请求 BIZ 请求包装、业务逻辑 Rank 智能排序 Search 搜索召回
14. Rank工程挑战 • ⾼高调⽤用量量、⾼高QPS: • 核⼼心⼊入⼝口,每⽇日数亿次调⽤用 • 峰值效应明显,⾼高峰期qps是正常10倍以上 • 重排数多: • 单次Rank重排数5000+ • 多属性、多来源 • ⼀一次Rank需⽤用到300+属性及上百⽤用户、Context属性 • 涉及⼗十多个业务数据源,来⾃自搜索索引/MongoDB/ Mysql/Redis/RocksDB/RPC • ⾼高时效性 • 部分属性必须秒级更更新 • 低时延 • 30-40ms的平均响应时间 APP ⽤用户请求 BIZ 请求包装、业务逻辑 Rank 智能排序 Search 搜索召回
15. Rank工程升级 • 存储设计 • 从单⼀一Mysql到引⼊入RocksDB/Redis/ Mongo等多种KV • 不不同KV针对不不同需求,Redis和实时 数据打通,RocksDB存储天级/⼩小时级 商户属性 • 低时延/⾼高时效 • 多种缓存,减少RPC调⽤用和数据库访 问 • 接⼊入MQ,主动更更新状态缓存 • 通过MQ实时更更新索引,过滤⽆无效候选集 • 引⼊入简单模型粗排,降低重排数 APP BIZ Rank智能排序 Model Loader / Predictor Feature Loader/Convert Guava Cache/Redis-Cache/Map MongoDB MySQL RocksDB Redis RPC MQ Search 搜索召回
16. Rank工程升级——商户特征存储方案 早期⽅方案:MySQL 服务启动全量量加载,发现新数据再 异步全量量加载 • 优点:服务启动成功即可接收请 求, Mysql⽆无压⼒力力 • 缺点:启动慢 过渡 RocksDB • 避免了了⼤大批量量的请求落⼊入数据库 • 减少IO成本:避免了了数据传输的消耗 • 开发效率提升:对于频繁新增的特征数据⽆无 需再⾛走MySQL的修改流程,⼤大幅提升了了迭代 效率。 • ⽅方便便的集成离线⽣生成的数据⽂文件(sst),推数 ⽅方便便 • ⾮非常⾼高的查询性能(0-1ms) • MySQL+Guava Cache做懒加载:启动迅速,但随着QPS升⾼高和商户特征 丰富,cache miss时MySQL的压⼒力力越来越⼤大,重启抖动⾮非常严重 • Mongo DB:导数据成本⾼高、开发不不灵活 • 搜索索引:⾼高IO成本
17. 体验升级 Rank算法演进路路线
18. Rank算法演进路线 数据升级 数据规模 数据精确性 数据时效性 模型升级 复杂度 时效性 优化⽬目标 特征升级 设计⽅方式 特征维度 监控⽅方式 选择⽅方式 时效性 业务理理解升级 单步优化 多步优化 特殊⽬目标 兼顾⽣生态
19. Rank算法演进路线——数据升级 初版数据 数据规模 • 千万以内样本,特征⼏几⼗十维 • 单机训练 数据精准性 • 样本⽣生成依赖于离线多表关联,线上 线下数据经常不不⼀一致 • app埋点不不精准 数据时效性 • 离线T+1样本 • 离线T+1特征 • 离线T+1报表 HDFS 多表关联、拼接 样 本 ⽣生 成 RANK离线 Data Matrix 模型训练+评估 模型离线训练 LR/GBDT/FM 模型离线评估 AUC/MAP/NDCG 效果/性能/可解释性 模型管理理、 加载 RANK在线服务 特征 加载/交叉/组合 模型预估 Predict
20. Rank算法演进路线——数据升级 数据规模 • 模型训练样本量量⾼高速增⻓长 • 单机—>分布式 数据精准性 数据时效性 • 线上⽇日志直接输出训练样本,避免离 • 离线样本—>实时样本 线数据关联的不不⼀一致 • 离线特征—>实时特征 • 正负样本⽣生成依赖于精准埋点 • 离线报表—>实时监控 RANK在线服务 在线⽇日志输出 训练样本 特征 加载/交叉/组合 数据清洗/ 落地/拼接 RANK离线 RANK实时 Data Matrix 样本⽣生成 模型训练+评估 模型训练 LR/GBDT/FM 模型预估 Predict 模型管理理、加载 模型评估 AUC/MAP/NDCG 效果/性能/可解释性
21. Rank算法演进路线——模型升级 复杂度 • 规则—>线性—>⾮非线性—>融合模型 时效性 • 天级—>时段级—>⼩小时级—>流式更更新 优化⽬目标 • 点击率(1)—>点击率+转化率+GMV(2) —>(2)+⽤用户整体体验(3) 设计 • 精细粒度分时段、分场景模型(offline)+在线模型(online) • 点击率、转化率、⽤用户满意度融合模型 ⼈人⼯工规则与策略略 01 餐厅少 ⽤用户⾏行行为单⼀一 迭代慢 线性模型LR ⼈人⼯工特征⼯工程 模型简单 结果可控性强 02 ⾮非线性模型及 模型融合 GBDT/ GBDT+LR
 LamdaRank等 分场景、分⼊入 ⼝口、分时段等 多步模型 03 深度学习 更更复杂的模型 特征学习 更更少的特征⼯工程 端到端学习 04
22. Rank算法演进路线——特征升级 特征设计 • ⼈人⼯工设计—>⼈人⼯工设计+⾃自动构 造 • 分时段、分⼊入⼝口、分地域⾃自动组 合 • GBDT+LR、FM等 特征选择 • 信息增益、卡⽅方、互信息 • 正则化+指标量量化(权重、Auc、 MAP)+特征集合搜索 特征监控 • 覆盖率、范围、异常值 • 离线监控—>实时监控 特征时效 • 离线特征—> 离线分时段—> 离线+实时特征
23. Rank算法演进路线——业务理解升级 单步优化—>多步优化 兼顾点击、转化与交易易额 ⽤用户⾏行行为步骤: 浏览—>点击—>下单 点击率模型—> 点击率模型+转化率模型+客单价 预估 平台特殊⽬目标 资源约束、时间敏敏感 交易易转化—> 交易易转化+⽤用户决策效率+端到端 时⻓长 考虑餐厅负荷、运⼒力力负荷(策略略 调整) 兼顾⽣生态平衡 政策倾斜/ 新店加权/ ⽼老老店拯救 防⽌止过度个性化E&E 各业务线流量量分配均衡
24. 实时数据体系与在线学习
25. 实时数据体系设计 ❖ 应用层 特征⼯程 策略控制 在线学习 实时报表 ❖ 数据类型 曝光 点击 下单 加购 搜索 收藏 ❖ 基础架构 Storm Kafka Redis DRC
26. 实时数据体系与在线学习 实时样本⽣生成、在线训练、特征⼯工程、实时效果报表 Rank Server Log 业务⽇日志 UBT app Log ⽤用户⾏行行为⽇日 志 曝光、点击、 搜索等 交易易⽇日志 实时⽇日志输出 Rank Server 实时特征加载 Flume 模型加载 模型训练 准实时模型与实 时模型 模型评估 离线评估/在线 评估 实时特征计算 Flume BinLog Kafka 订阅 Topic Storm 样本关联 聚合计算 实时效果监控 实时样本流 Redis Mongo DB Graphite
27. 实时数据体系——实时报表 策略效果即时感知&即时决策 分入口、分算法版本、分指标
28. 实时数据体系与在线学习 在线评估 vs 离线评估 • 在线auc与特征覆盖率监控 • 防止线上线下数据不一致带来的评估部准确问题 • 效果评估即时反馈
29. ⼯工具化提升效率
30. 工具化提升效率——排名解释系统 作⽤用 • 技术、产品、业务⽬目标协同 • 快速定位排名原因 • 兼顾效果与可解释性 动态灵活 • 真实场景模拟—指定地址及⼊入⼝口 • 指定⽤用户信息排查 • 指定不不同算法版本对⽐比 Rank因素 • 展示排名决定因素 • Top Feature 打分明细 • 政策、产品、业务因素
31. 工具化提升效率——AB引擎/训练平台 AB引擎 • 集成分流与报表功能 • 可视化配置 • ⽅方便便⾼高速算法迭代 • ⽩白名单便便于算法模拟及预演 训练平台 • 模型训练与评估 • 可视化配置 • 图形化指标展示 • 交互性强
32. 工具化提升效率——Rank在线模拟&Debug系统 可视化集成 • App效果同步展示 • 精准展示曝光、点击、下单 算法信息校验 • 特征信息、算法版本 • 可视化Debug
33. 工具化提升效率——搜索运营/Debug系统 运营系统 Debug系统 • 词库管理理/标签管理理/运营配置 • 抽检/标注 • case排查 • ⼀一键模拟 • 降低⼈人⼯工介⼊入⻔门槛 • 可视化数据校验 • 即时配置、即时⽣生效
34. 一些感悟 • 建⽴立健康合理理、符合公司战略略⽬目标的业务指标 • 强化业务理理解,技术驱动业务 • 重视技术,但不不唯技术 • 基于现有体系快速迭代
35. 欢迎关注 饿科技 We are hiring • 算法⼯工程师 • 搜索⼯工程师 • Java⼯工程师 • 深度学习专家 • ⾃自然语⾔言处理理⼯工程师 yao.ma02@ele.me