ArchSummit2016干货分享+美团：即时物流调度平台实践+一点资讯：兴趣引擎-深度融合搜索和推荐+阿里-智能问答系统的实践

**

2015年7月

**

加入滴滴打车3个半月，感觉遇到和解决的技术问题超过之前1年的。写在这里给大家分享。

滴滴这边负责所有策略算法设计的是“策略组”，大概有20几个员工。由于滴滴的业务线越来越多（出租车，专车，快车，顺风车拼车，大巴），项目上线时间紧，没有时间对策略算法做最好的设计和优化。于是，新成立了一个通用模型组，目标是抽取出不同业务线的共同点，在一个更高的角度设计更好的策略算法，特别是提供通用的大规模机器学习支持。我是这个team第一个员工。

订单分配：

滴滴一个技术重点是订单分配，全国每天有几百万的乘客通过滴滴叫车出行，有近百万司机接滴滴的订单，如何将订单分配给司机使得更多的人更快地打到车？至少有如下问题需要考虑：

1. 从大的层面，如何设计一套分配策略，能够保证目标最大？
2. 从小的层面，分配订单时应该考虑到哪些因素？（距离？是否顺路？司机习惯偏好？天气？供求关系) 这些因素如何组合？
3. 如何在更长的时间维度上做更优的分配？（比如，当前时刻将乘客A分给司机B是最优的，但几秒之后司机C出现了，司机C离乘客A要近得多）
4. 拼车更环保也能帮乘客省钱，如何在订单分配中让尽可能多的人在保证体验的同时拼上车？TRB中有非常多的文献
5. 乘客加价如何影响订单分配？
6. 我们应该学习Uber的一些策略吗？（比如播单不告诉司机乘客的目的地）

在创业初期，可以用规则快速简单地实现，现在滴滴已经初步有了一套理论上保证收益的分配策略，需要我们进一步去优化效果和效率。

透露一下，在整体策略中，有一个部分是涉及到大规模机器学习：样本是几十亿级别，特征是亿级别（这是我进来的第一个项目）

动态调价：

设想在周五的傍晚，下班高峰，又开始下大雨。在国贸商圈有1000个用户通过滴滴叫车，而附近只有100辆车。如何做订单分配？应该把有限的车给谁？

首先，我们需要定义一个目标：动态调价的目的是什么？最大化成交量？最大化流水？最大化（愿加价）乘客打车的成功率？还是这几个目标的组合最合理？

选定目标之后，每个乘客应该加多少钱？一个优质订单是不是应该少加点？

滴米：

为了促进订单成交，除了给司机补贴和要求乘客加价，是不是还有别的激励方案？

于是滴滴牛逼的PM们推出了滴米这个牛逼的产品。滴米是一种虚拟货币，对于优质订单，一堆司机挤破头来抢，我们就扣他们虚拟货币，对于没人要的订单，我们就奖励滴米。这样就调节了优质劣质订单冰火两重天的不和谐局面。关键是，乘客和滴滴不用花一分钱!

产品很牛逼，策略上如何支持？一个订单发出前，如何确定其是扣滴米还是奖励滴米？扣多少奖多少？每个司机一样吗？整个策略会导致通货膨胀或者紧缩吗？

到达时间预估

预估司机从A点到B点的时间消耗，对滴滴挺重要。如果准确地预估？基于哪些数据和因素？这是一个机器学习问题吗？有更巧妙的预估方法吗？

工作感受

说了来滴滴3各月参与和了解的几个项目，我觉得都非常有意思，也非常有意义。说下来之后的几点体验：

第一，最大的体会是中国互联网行业，特别是滴滴，生机勃勃，有太多有挑战的事情等着做。产品和策略迭代非常快，基本上每天线上的策略设计和架构都会有一次优化上线，你每次改动就会影响每天几百万人的出行体验。

第二，相比我之前的工作，在滴滴工作会和不同岗位的同学紧密合作，每天和靠谱的策略组小伙伴一起做策略设计和讨论；和90后PM mm们讨论进度和策略设计；和QA团队合作测试，保证上线风险可控；和OP同学配合上线；

第三，滴滴的招聘质量提升非常快，3个月前我刚入职，周边同学大概还是百度同学的平均水平，现在我参与的面试，发的offer的质量基本和hulu差不多了。

最后，昨天滴滴大巴上线了，现在可供出行的产品线有出租车，专车，快车，顺风车，大巴。欢迎加入滴滴，在滴滴最美好的阶段，和牛逼的人做牛逼的事情，一起改变中国人的出行体验。有兴趣的联系我: guodong@diditaxi.com.cn

  <h1 class="entry-title">**

ArchSummit2016干货分享

**

上周去参加了ArchSummit 2016，是一个偏架构技术的会，也有一些talk结合了架构和算法一起介绍。我听了十几个和大数据架构和算法比较相关的talk，做了一点小结分享给大家。

Highlights

1. 订单分配：美团和菜鸟物流（阿里旗下）都简单介绍了自己的订单分配算法，和滴滴分单场景有近似之处。美团的外卖配送在某些方面比滴滴的分单问题更有挑战性，有一些思想可以借鉴，比如权衡体验和效率的“压单”；

2. 热门的机器学习算法：

GBDT + LR：腾讯微信的用户相似度预估、广告点击率预估，阿里推荐算法的点击率预估都在用。具体可以看Facebook在2014年的文章；

FTRL：这个算法是google在2011年左右publish的，被国内各大公司作为online learning的重要选择，我之前实验中做过评估，其显著的几个优点：样本只需要过一遍，预测效果top，稀疏模型

• 大规模分布式机器学习框架：

• Parameter Server：若干公司提及，包括一些规模不太大的公司（第四范式、一点咨询），目前来看parameter server还是大规模特征下的分布式机器学习框架的首选

  Spark：spark简单易用，当特征规模在千万之内还是很不多，ThinkData给出自己开源的分布式机器学习算法库，据称在预测效果和训练速度上都显著优于MLlib

• 图算法：微信在做定向广告时，需要构造用户在朋友网络上的“社交相似度”特征，其使用了KDD2016最新的node2vec算法，类似Random walk + Word2vec，据称效果显著，有兴趣的可以去看paper；

• 知识图谱（Knowledge graph）：Facebook的knowledge graph将这块带的很火，在需要理解用户意图给出用户想要的结果的场景下大多会涉及。 本次有2个talk涉及：阿里的自动问答系统，一点咨询（类似今日头条）的新闻搜索；

• 深度学习：这次几个talk上提到，不过都还是在尝试，感觉没有DL在其应用中还没发挥核心作用。包括阿里的自动问答，第四范式

• 架构引擎相关，有2个talk影响较深刻，一个是阿里双十一的流量规划和压测实践（流量隔离压测 + 配比拉平可以减少直接在线上做压测的风险和人员投入成本），另一个是百度的大数据系统技术栈（百度文件系统BFS，分布式数据库Tera都已在github开源，值得学习一下）

• slides 下载

  美团：即时物流调度平台实践

  现状：美团外卖日订单800万，平均配送时长（从下单到送达）降到了单均28min，配送路程为2KM，28min还是比较厉害的。

  美团外卖配送算法在某些方面比滴滴的订单分配更复杂：

  1. 滴滴订单分配的对象是司机和乘客，而美团配送需要考虑三方（骑手、乘客、餐厅）。增加了不少复杂性，比如需要考虑商家备餐时间的不确定性和差异性
  2. 滴滴大部分订单都不是拼车，而美团骑车平均会一次性配送5个订单，订单匹配和组合的效率是核心问题
  3. 路径规划的复杂性更高（设想一个骑车同时被分配了5个订单，候选的路径数）
  4. 配送目的地的复杂性：外卖配送的目的地很多是小区（送达X号楼X单元X层的房间）和写字楼（楼层），应该要考虑更多的骑手个性化

  美团的订单分配算法演进

  

  这里的“压单”是等待更多类似的订单，聚合起来一起分配给骑手。有点类似滴滴的拼车等待

  在用的几个重要平台：场景回放平台、算法仿真环境（派单场景下）、分布式计算平台

  微信朋友圈基于社交相似度的定向广告技术

  简介：lookalike是一种经典的广告定向技术，指的是找出和指定目标人群类似的人群。微信使用了包含图特征的有监督学习找出的目标微信用户做广告定向，相比广告随机投放给active用户，可以提高2-3倍的点击率。

  算法概况：目标是预估指定用户和另一个微信用户的相似度

  1. 训练样本的label获取：找出公共展示广告较多的用户pair，计算其相似度：共同点击广告个数/共同展示的广告个数
  2. 使用了用户pair之间的社交相似性特征，通过node2vec network embedding算法生成
  3. 机器学习模型：SVR，GBDT+LR都做了尝试

  使用node2vec生成社交相似度特征

  node2vec = Biased Random Walk + Word2Vec node2vec in KDD 2016： http://www.kdd.org/kdd2016/papers/files/rfp0218-groverA.pdf 强调了调参（网络深度和广度参数p、q）的重要性

  GBDT+LR组合模型（通过GBDT学习出高区分性的组合特征，输入到LR中）

  Paper from Facebook：http://www.quinonero.net/Publications/predicting-clicks-facebook.pdf (ADKDD 2014)

  腾讯和阿里都做了尝试：http://www.cbdio.com/BigData/2015-08/27/content_3750170.htm

  一点资讯：兴趣引擎-深度融合搜索和推荐

  1. 检索系统使用了WAND operator：http://cis.poly.edu/westlab/papers/cntdstrb/p426-broder.pdf WAND泛化了AND和OR操作，是更强大的匹配操作符

  2. 异构索引：由于需要在几个维度（近期和长期内容、编辑精品vs抓取内容、垂直频道vs全局内容、热门推荐和个性化推荐）上兼顾搜索和推荐的效果，搞了若干个内容索引，后面会做自适应索引召回（基于对query或者用户的理解决定从哪些索引返回结果）

  3. 自适应索引召回策略：对Query做意图理解，决定返回的文章 除了搜索词本身，还考虑了时下热点，用户浏览搜索上下文，用户兴趣图谱，用户demography等信息 决定从哪些下游索引、服务、内容中获取结果，以及排序

  4. 树状知识图谱 提到了其在用，未透露技术细节。树状知识图谱应该是内容推荐和搜索的关键模块

  5. 模型训练与更新 online learning 准实时模型更新（KAFKA –> Storm –> Online Learning），声称在用Parameter server 模型使用了流行的FTRL 实验框架支持feature configuration

  阿里-智能问答系统的实践

  1. 几种主流的问答匹配技术：rule-based模板式匹配，基于检索的模型，基于统计机器翻译SMT，基于深度学习模型 阿里目前以前三者为主，基于深度学习模型在探索
  2. 基于检索的问答模型还是基础方案 基本是搜索的一套方法，在复杂问答场景不胜任（意图识别，上下文对话）
  3. 意图识别，被抽象成分类问题解决。该部分非常有挑战性，阿里也还停留在基础阶段，深度学习被应用在该分类任务中
  4. Knowledge graph有被应用
  5. 语义挖掘：同义语义挖掘、近似词挖掘、潜在语义分析（LSA，PLSA，LDA）
  6. 探索中：Deep learning、Transfer learning、Reinforcement learning

  ThinkData：Fregata- Spark上的轻量级大规模机器学习算法库

  已开源：https://github.com/TalkingData/Fregata

  基于Spark实现的分布式机器学习算法库，目前只有几个基础的模型(LR、softmax、RDT)，声称相比MLlib有更快的训练速度和更好的模型效果。

  几个点评：

  1. 提出了基于SGD改进的GSA（Greedy Step Averaging）优化算法（出发点是解决SGD等常见的优化算法需要选择learning rate的问题），该算法是Fregata实验效果优于MLlib的主要原因。文章见：https://arxiv.org/pdf/1611.03608v1.pdf
  2. Fregata强调样本一遍过完，无需多次迭代，提高了训练速度（我理解这取决于给定算法是否需要迭代，Fregata目前实现的少数几个模型不依赖于多遍迭代）
  3. Fregata对标MLlib，同基于Spark，依然没有解决训练样本特征维度过高（百万/千万级）无法训练的问题，不如Parameter Server
  4. 目前只实现了LR、softmax、RDT少数几个模型，且尚不兼容Spark1.6以上的版本

  第四范式：其构建机器学习产品的介绍

  整体停下来，干货很少。提到一个GDBT计算框架，就是实现的Parameter Server。部署在HADOOP那套生态上（YARN/HDFS等）。

  另外，第四范式在尝试Deep Sparse Network，戴总的研究方向Transfer learning声称“在研究如何应用”状态

  阿里巴巴-天猫双11容量规划演进

  容量规划经历的几个阶段

  压测和容量评估，不能以“点”的方式，要做场景化压测和评估

  容量评估主流程：容量评估&压测平台

  自动化，最终自动生成压测报告，例行执行；可以控制流量要求

  流量隔离压测 + 配比拉平

  阿里经历过直接在线上做全链路压测，为了线上分享和人员精力消耗（“几百人坐在一起盯着自己系统”），采取了在隔离的集群上做压测（可能占全部机器资源的90%），压测完找到合理的机器分配比之后，再在全部服务器上做配比拉平

  百度：Spider3.0背后的数据处理系统（数据库Tera，文件系统BFS）

  百度整体的大数据架构技术栈github page

  

  整个Spider3.0处理流程（增量处理、流式处理，基本都围绕Tera数据库读写）

  数据爬取延迟从spider2.0的2~3天，降低到spider3.0的5分钟

  Tera：百度高性能分布式NoSQL数据库Tera

  1. 对标google BigTable，加强版Hbase，已开源：https://github.com/baidu/tera
  2. keywords：分布式、列存储，支持分布式事务，万亿条记录，百PB容量，亿级QPS读写，全局有序表，快照支持回滚
  3. 分布式：按照row切割成大量的Tablet，做到并发读写，Tablets灵活地分裂与合并
  4. 容错和备份：先写log，再写内存，再固化到磁盘

  BFS：百度文件系统

  见：https://github.com/baidu/bfs

  LinkedIn：Lessons in Internet scale stream processing（海量流数据处理经验总结）

  

  Apache Samza

  LinkedIn开源的分布式流数据处理系统，对应于Storm和Spark Streaming，号称计算性能优于MR和Spark。 目前除LinkedIn，Uber、Netflix等公司也在用Samza。

  Posted by Dong Guo

  2016-12-18T23:29:32+08:00

  " pubdate="" data-updated=“true”>Dec 18th, 2016

  越来越多人和公司认同data-drivern决策的必要性，不仅是滴滴、Google、Microsoft、Linkedin、Amazon这些科技公司，也包括传统意义上的非技术公司。Data-drivern的核心是Controlled experiment（即大家常说的A/B Testing)，按照字面理解就是将其它影响因素都control住，保持一致，实验结果只由预设的不同方案影响。

  在滴滴算法团队，很多时间和精力都在做各种策略和算法实验，比如我们比较不同的订单分配策略哪个可以让接驾时间更短，比如评估新的动态定价策略对乘客的留存和活跃度有什么样的影响。基于近期在做实验方面遇到的一些挑战思考，以及上个周末看的几篇文章写一个小结在这里。先介绍几个controlled experiment相关的基础而重要的点，总结做controlled experiment中的一些遇到的难点和挑战，最后是一些实验方案和架构的构想。

  1. 几个基础&重要的知识点

  1.1. A/A Testing

  A/A测试是一个比较有效的实践去检测你的实验设置中是不是有bias。AA测试一般有两种实现方法，一种就是仅在实验前做离线数据分析（AA测试并不都需要去线上做实验），另一种就是在线上setup A/B/A的实验。

  1.2. Hypothesis Testing

  A/B测试基本都需要通过假设检验计算猜想的置信度，你想证明的东西称为alternative hypothesis(“备择假设”，比如“我的新算法比老算法能提高CTR”），反面称为null hypothesis（即“零假设”，即“我的新算法和老算法没啥差别”）。通过收集A/B实验的数据，计算B的均值X_b和A的均值X_a，计算二者的diff X_d = X_b – X_a，如果零假设成立，X_d应该较小。在假设策略A和B无明显差别的前提下，可以得到X_d服从的分布X_D，比较X_d和分布X_D，利用小概率事情一次是不会发生的思想（实际是设定置信度阈值，比如0.05），判断是接受还是拒绝零假设。（具体公式后续补充）

  1.3. Sociation or Causality

  相关性 ！= 因果性，非常重要的sense。一个经典的例子是“大量样本表明，口袋里有打火机的人得肺癌的概率显著高于口袋里没有打火机的人”

  2. 做Controlled experiment容易犯的错误和挑战

  通过AB测试产出正确的决策通常是一件非常不容易的事情，我可以很容易列举10条常见的导致产出错误结论的原因。错误的结论包括false postive（新方案无效或者有负向效果，但通过实验得出有效的结论）和false negtative（新方案有效果，但是通过实验判定无效），其中false postive相比false negative对公司伤害可能更大。常见的观点是在科技公司的算法和策略优化中，80%~90%的idea被验证是无效或者有负向效果的（见Microsoft这篇文章【3】的5.1小节）

  2.1. 几条典型的产出错误结论的原因

  1. AB流量划分不随机：比如用用户ID最后一位数字做分流，事后才发现该ID并不随机。可通过对数据源深入了解分析和AA测试来减少这方面的错误
  2. AB流量划分随机，但是control或treatement会影响对方的流量，导致对比结果的不可信
  3. 错误的指标选取：比如有时业务指标（KPI）很难量化，选择的“近似”可量化的指标实际相比业务指标差很远
  4. 实验结果未达到足够的置信度就宣布结论：看p-value，多break down指标看细节
  5. 线下线上分流没有对齐：实验设计、代码开发、指标选取都没有问题，但是由于离线用日志评估结果时未使用和线上一致的分流方案（典型的原因是没有将分流标志写入日志，离线只能按照口头约定的逻辑重新实现分流逻辑，常发生在开发和指标统计不是一个团队时），必然导致统计结果有偏差
  6. 实验期间外部因素干扰了实验结果，比如天气或特殊事件
  7. 任何一个环节的bug
  8. 实验本身很完美，但是你的（或者老板给你定的）KPI错了

  2.2. 挑战1：设计合适的AB流量划分方案

  常见的流量划分方法有这么几种：按照某种ID进行随机划分（比如用户ID、session ID、cookie ID），按照时间片进行划分（比如每半个小时进行算法的轮换）、按照地理区域划分（比如将城市划分成网格，交错apply不同的算法）。

  AB流量划分的第一点是保证划分的随机性，通过做AA测试分析基本可以保证。第二点是保证control/treatment不影响对方的流量，对于某些实验上面几种典型的流量划分方案就不可行了。假设滴滴要评估一个新的定价策略是否可以提高GMV，我们看下这几种流量划分方案：

  1. 按照乘客或者订单ID随机划分：订单分配算法是全局的，所以运力/司机是2个定价策略共享的
  2. 按照时间片进行划分轮换：在当前时间片apply某个定价策略，可能会占用下个时间片的运力，特别是时间片较短时（比如不足一小时）影响显著，但是时间片越大时间本身引入的外界因素干扰就越大（比如不同时段的需求、运力、天气等因素的差异）
  3. 按照地理区域划分：同样有运力共享的问题

  对于这个case，如果你有好的流量划分idea非常欢迎和我交流

  2.3. 挑战2：确定正确的业务目标和实验指标

  想清楚业务优化的目标是一切的基础，比较容易犯的错误是优化了一个短期的目标，而该短期目标和长期目标常常是冲突的。错误的KPI往往有两个来源，一个是所谓的“目标分解，阶段性目标”，另一个是不了解各种指标之间存在千丝万缕联系的老大直接拍板了一个KPI（如果能在不伤害其他指标的情况下做到优化KPI当然是好的，但是老大只提了要优化KPI，没有说其他指标不能受到影响）。

  Google在这篇文章【1】中提到了广告的投放不能仅看当下的收入，应该看长期的收益（年的粒度）。如果给用户展示了过多的广告，用户会自然地学习到对广告的blindness，之后的广告CTR会显著下降。为了度量不同的广告策略对用户长期的影响，作者设计AA –> AB –> AA实验：

  1. 第一阶段（AA）：挑选两拨有相同广告体验的用户，且整体CTR差异不大
  2. 第二阶段（AB）：给其中一拨人B使用新的广告投放策略（即更多的广告展示），持续一段时间（文中提到是90天）
  3. 第三阶段（AA）：给用户群B恢复和A一致的广告体验，对比两拨人的广告CTR （这个阶段采用BB也可行）

  这里涉及到一个问题，用户对广告的blindness程度是受新策略作用时长影响的，这种影响可能需要数个月才能收敛，作者想去量化这种收敛后的长期影响，文中提出了2个方法，一个是用指数函数去fit CTR衰减曲线，另一个是用机器学习模型去预测（使用短期的CTR变化），作者提到google在过去几年累积了上百个广告blindness相关的样本，可以用作有监督学习。

  我们在滴滴也犯过优化与长期目标矛盾的短期目标的错误，这里就不细讲了。

  3. 统一的一站式实验平台

  公司内部需要有一套统一的一站式实验平台，按照做实验的顺序包括：较完整指标库、实验管理、新建实验、流量管理与冲突检测、实验上线、实时监控报警、查看实验结果等。几个要点如下：

  1. 正确/权威/完整/统一的指标库：每个实验都有自己的一级二级指标，全局统一且正确的指标非常关键，每次创建实验只需要从指标库中勾选需要观察的指标即可
  2. 全局流量管理：流量划分收敛到平台（避免由于未经协调不同的小组创建了同一份流量上创建了冲突的实验），且可以设计更高效的流量划分方案，比如Google的支持多层正交实验的平台【2】
  3. 实验管理/检查/分享：所有的实验及配置都可在平台上清晰地查看，有很多好处：比如每个人都有机会了解正在执行的实验，查看实验结果和结论，专业的同学可以帮忙检查实验的配置
  4. 创建实验无需开发，产品和运营同学也可以操作上线实验
  5. 实时监控及时发现问题：实验创建过程中可以配置任意metric的预期range，一旦在线上超过range自动发报警

  Google这篇文章【2】提出了支持不同实验在同一个domain的不同layer上overlapping的实验平台架构，值得一看。

  4. 实验的评审和分享

  创建一个公正的实验并产出可靠的结论是非常不容易的事情，在目标设定、指标选取、分流方案、外部因素考虑、置信度等任意一个方面出错都可能导致产出误导的结论。所以有一个实验review或者评审的环节就很有帮助了（文章【2】中也提到google有这样的实验委员会）。

  除了把控实验的指标，分享&讨论有趣的实验有助于stand on each others‘ shoulders，这个可以通过wiki、邮件、或者在实验平台的相关页面分享给大家。

  在滴滴待了16个月了，这一篇说说我理解的未来的智能出行：

  1. 整个城市的车辆都由一个中枢系统控制，车辆的路径规划和控制可以最大化整体城市居民的出行效率，交通拥堵从此消失；

  2. 车辆是自动驾驶的，所以非常安全，车内变成真正的生活空间，交通标识和信号灯也不需要了；

  3. 人们不再购买车，车也不再属于个人，因为在城市的任何区域任何时间1分钟内就可以呼叫到车；

  4. 车辆都是电动的，会自己选择合适时机去电池站更换电池。由于车辆没有驾驶室，且车辆之间可以像积木一样拼接，车辆的外形也会发生变化；

  归纳起来就是几个关键字：共享出行、电气化、汽车网联、自动驾驶

  

  滴滴、Uber、Google以及一众高校正在推进这一科幻版的未来场景：

  共享出行：其是滴滴和Uber们的原始出发点，目前中国每天有10~20M乘客通过共享的方式出行。

  电气化：电动车的成本显著低于汽油车，滴滴正在推动更多电动车加入车主行列；

  自动驾驶：这一块已经非常火了，一方便有望大大降低交通事故发生率，对于滴滴和Uber来说可以省掉司机支出极大地降低成本；

  Automated and Connected Vehicles技术目前是研究热点，有一篇科普文章