文 | 吴海波
编 | YY
阅读说明,本文的机器学习领域限制于互联网搜索、推荐、广告场景,仅限于个人观点。
2017年,我和团队的几个核心去了趟北京,找了各大互联网公司一线实战的同学,交流各自在机器学习上的经验。这次交流让我的认知上了一个台阶,开始思考什么是真正优秀的机器学习团队。
感慨一句,百度,特别是凤巢,真是中国机器学习的黄埔军校,门生遍布天下。
工程系统中,提升收益是优化算法的根本动机。 业界流行过这样一句话:“能加几台机器解决的问题,不要让人去优化。”乍一眼看有些反直觉,但是结合语境细想,这句话的核心思想是做事应当把控好大方向。机器便宜,人力昂贵,在业务快速发展的阶段,有很多更重要的事情要去做。能不能比竞争对手快一个周期,就是团队生与死的差别。这种情况下,过度追求算法的提升可能是在舍本逐末,反而不明智。
对比学术界,互联网中搜索推荐及广告的场景,有个明显的特点,就是数据规模大,训练数据丰富,正负反馈获取成本低。这就造成了和传统机器学习算法格格不入的方案,通常模型方案都是不那么经济。
此外,大多数工程系统,是从业务需求侧或者产品需求侧设计的,很少会把算法当做真正的业务方。 工程师对研究者常见的批评,有一条就是开发的算法往往缺少对应的需求。而业务方的要求,就算有时在实现难度上大到不合理,通常也是市场的客观反映。因此,大部分工程上针对算法的设计方案,更像是主流需求外的附加需求,常常是阉割再阉割。
采用机器学习时,有几个问题是共通的:数据质量建设——ABtest怎么做的,流量波动大不大,实验置信度有多少,埋点方案有没有第三方检验,数据口径是否统一。
这两年,各大公司分别实现了一波少帅的Parameter Server,动不动就号称千亿级的特征规模。这套广告业务的核心技术:点击率 (Click Through Rate, CTR) 。预估任务最开始由Google提出,而国内选择的突破口是在Logistics Regression中引入id类特征,这就造成了极大的运算量。众所周知,LR模型是线性模型,需要做特征交叉,互联网的用户、商品、内容都是一个非常夸张的量级,交叉之后往往会得到一个规模极大的特征集。
大规模首先要解决计算力问题。 很多互联网公司的机器学习团队虽然有很多数据,但是跑不动,就只能用部分数据;又因为训练数据不足,特征工程就不能做多,只好人工进行特征选择,费时费力。如果计算力足够,样本量级上去,这个问题就可以迎刃而解。
同样搞机器学习,大公司可能一天进行十几种尝试,小公司却只能做一两种。冷兵器对上火炮,只有被碾压。少帅在14年提出的SOTA,100T数据,10亿特征,半个小时迭代100轮的计算力,到了现在能实现的公司也寥寥无几。
另一方面是线上服务。 这么大规模的模型,怎么发布上线,更新模型的时候怎么保持线上数据的一致性,处处都是难题。模型大了,相应的特征也很多,那么哪里存储这些特征?离线的特征可以存缓存,实时特征怎么办,数据还要沟通,能做到实时吗?如果模型不能被单机加载到内存,难度又得上一个量级。
综合起来,大规模LR模型非常考验团队工程系统能力。从另一个角度看,这是一种工业级的哲学观,追求通用,追求效率,降低模型对个别算法的依赖,通过堆切大量特征的方式击败小作坊式特征工程,充满暴力美学。
上文的大规模LR看起来是一种“笨方法”。最近这几年工业界投入甚多的深度学习,则是另一条被看好的道路。说实话,大部分的深度学习在推荐和搜索,并没有取得像图像领域那样让人印象深刻的效果。但它拥有一个致命的诱惑——不需要或需要少量的人工特征工程。
就是这个方案对比以前的模型没有提升,但它不需要特征工程,于是能带来巨大的效率提升。如果想做出较通用的解决方案,对业务来讲,原先可能要好几个同学哼哧哼哧搞好几个月的特征工程,现在深度学习方案能快速的搞出来。
总的来说,目前的机器学习还有很大的发展空间,让我们把喧嚣留给媒体,自己安安静静地继续探索吧~