首家大数据培训挂牌机构 股票代码:837906 | EN CN
阿里巴巴菜鸟级数据产品经理半年回顾总结篇
干货教程:如何绘制业务流程图(二)
干货教程:如何绘制业务流程图(一)
技术贴:如何在数据库中秘密地查询隐私数据
攻略教程:信息图(infographic)是怎么做出来的?
分析师一定要看!用数据讲故事的五个步骤
技术篇:怎样玩转千万级别的数据?
北漂书生:大数据时代SEO数据如何搜集和分析
干货,从十大问题重新认识并读懂互联网
相似图片搜索、算法、识别的原理解析(下)
相似图片搜索、算法、识别的原理解析(上)
制作信息图时请遵循这10条原则
提高表格可读性的一些技巧,适用于Excel、PPT等数据报表
实用教程:如何让Excel图表更具“商务气质”?
一张数据信息图是这样制作完成的
菜鸟读财报,如何从上市公司财报中挖情报?
北大数据分析老鸟写给学弟们一封信
如何一步一步制作出高品质数据信息图?
总结:海量数据分析处理的十个方法
【实战经验】数据分析师如何了解老板真正想法?
零售业数据分析那些事儿
数据分析时l常用电子表格公式【大全】
用数据来告诉你 上市公司财报的秘密
这12个数据能 帮你搞定淘宝店铺
首席工程师揭秘:LinkedIn大数据后台是如何运作的?(四)
首席工程师揭秘:LinkedIn大数据后台是如何运作的?(三)
首席工程师揭秘:LinkedIn大数据后台是如何运作的?(二)
首席工程师揭秘:LinkedIn大数据后台是如何运作的?(一)
淘宝网店从激活到挽留,4步走玩转数据营销
文案怎样写才有意思、不空洞、打动人?
入门级扫盲贴:数据分析的步骤有哪些?
关系即数据,论社交媒体的关系转换
数据的力量,苹果教你用数据鄙视竞争对手
谁说文科生不能做数据分析?数据分析入行→技能提升→优势
产品运营数据分析——SPSS数据分组案例
如何追踪iPhone和iPad等移动设备的用户行为数据?
阿里巴巴中国站:用户满意度指标权重计算方法
广告中的AdNetwork、AdExchange、DSP、SSP、RTB和DMP是什么?
信息图制作教程:关于数值的表现
为什么大数据会如此轰动?(值得深度的文章)
多图技术贴:深入浅出解析大数据平台架构
面板数据分析中标准误的估计修正——根据Peterson (2009)的归纳
财务官、投资人、CIO看过来:给企业数据定价
推荐系统中常用算法 以及优点缺点对比
探索Weotta搜索引擎背后的大数据技术
如何识别虚假数据?
为什么我们像驯化小狗那样驯化算法
程序员必须知道的10大基础实用算法及其讲解
电子商务:最影响转化率的九大要素
如何迅速成为一名数据分析师?
想从事大数据、海量数据处理相关的工作,如何自学打基础?
如何用亚马逊弹性MapReduce分析大数据?
译文:机器学习算法基础知识
给hadoop新手的一封信:Hadoop入门自学及对就业的帮助
从入门到精通,我是这样学习算法的
小商家,从老客户身上获取的数据才更有意义
13页PPT讲述:大数据下网站数据分析应用
40页PPT详解:京东大数据基础构架与创新应用
67页PPT解密搜索引擎背后的大技术:知识图谱,大数据语义链接的基石
营销洞察力——10个营销度量指标
技术篇:前端数据之美如何展示?
董飞:美国大数据工程师面试攻略【PPT】
easel:如何制作好的信息图——来自专家的顶级技巧
大数据实操:以3D打印机为例,如何知道卖点有没有市场需求?
大数据建模 需要了解的九大形式
用户画像数据建模方法
从规划开始,公司or企业如何入手和实施大数据?
干货:商品信息数据分析和展现系统的设计与开发
高手教你用Excel制作百度迁徙数据地图
50篇干货:淘宝店/电子商务如何玩转数据分析?
精华索引:大数据实际应用案例50篇
验证最小化可行产品 (MVP) 的 15 种方法
干货:数据分析师的完整知识结构
大数据技术Hadoop面试题,看看你能答对多少?答案在后面
用SPSS做数据分析?先弄懂SPSS的基础知识吧
怎样做出优秀的扁平化设计风格PPT? 扁平化PPT设计手册#3
解答│做大数据过程中遇到的13个问题
40页PPT│社交网络发展的新动力:大数据与众包
以Amazon、豆瓣网为例,探索推荐引擎内部的秘密#1
怎样做出优秀的扁平化设计风格PPT?#2
怎样做出优秀的扁平化设计风格PPT?#1
36页PPT│大数据分析关键技术在腾讯的应用服务创新
如何丰满地做SWOT分析?
【35页PPT】TalkingData研发副总阎志涛:移动互联网大数据处理系统架构
27页PPT|以珍爱网为例,如何构建有业务价值的数据分析系统?
国外数据新闻资源分享
21页PPT重磅发布:Mariana——腾讯深度学习平台的进展与应用
从0到100——知乎架构变迁史
PPT解读:百度大数据质量保障方案探索
45页PPT|大数据环境下实现一个O2O通用推荐引擎的实践
从数据看豆瓣兴衰
深度学习系列:解密最接近人脑的智能学习机器——深度学习及并行化实现(四)
重磅推荐:129页PPT讲述移动时代创业黄金法则 via:腾讯企鹅智酷
重磅推荐:大数据工程师飞林沙的年终总结&算法数据的思考
OpenKN——网络大数据时代的知识计算引擎
大数据下城市计算的典型应用
技术贴:大数据告诉你,如何给微信公众号文章取标题?
你的QQ暴露了你的心——QQ大数据及其应用介绍PPT
如何从企业报表看企业的生存能力?
实用的大数据技巧合集
技术帝揭秘:充电宝是如何盗取你的个人隐私的?
重磅!50页PPT揭秘腾讯大数据平台与推荐应用架构
原创教程:饼图之复合饼图与双层饼图(1)
PPT:大数据时代的设计特点——不了解这个你做不了今天的设计
教程贴:如何用方程式写春联?
原创教程:如何用Excel制作简易动态对比图
深度译文:机器学习那些事
教程帖:数学之美——手把手教你用Excel画心(动态图)
董老师走进斯坦福,聊聊硅谷创业公司和大数据的事儿(附课件PPT下载)
【限时】年度钜献,108个大数据文档PDF开放下载
董飞专栏:大数据入门——大数据相关技术、Hadoop生态、LinkedIn内部实战
亿级用户下的新浪微博平台架构
一张图了解磁盘里的数据结构
浅析数据化设计思维在阿里系产品的应用
美团推荐算法实践
一个P2P创业公司有哪些部门,都是做什么的?
一个P2P平台的详细运营框架是怎样的?
机器学习中的算法——决策树模型组合之随机森林与GBDT
神经网络简史
58页PPT看懂互联网趋势,大数据/物联网/云计算/4G都有了
广点通背后的大数据技术秘密——大规模主题模型建模及其在腾讯业务中的应用(附PPT)
微信红包之CBA实践PPT——移动互联网海量访问系统设计
一文读懂机器学习,大数据/自然语言处理/算法全有了……
搜狐新闻客户端的背后大数据技术原理——推荐系统(PPT)
原创教程:用Excel做动态双层饼图
半小时读懂PMP私有广告交易市场
怎样分析样本调研数据(译)
PPT:支付宝背后的大数据技术——DataLab、Higo的实践及应用
大数据技术人员的工具包——开源大数据处理工具list(限时下载)
计算机视觉:随机森林算法在人体识别中的应用
24页PPT:机器学习——支持向量机SVM简介(附下载)
互联网高手教你如何搜集你想要的信息
深度:对地观测大数据处理、挑战与思考
原创教程:用Excel做饼图之复合饼图与双层饼图(2)
移动大数据时代: 无线网络的挑战与机遇(附pdf下载)
Excel使用技巧——25招必学秘技
【年度热门】加上这些 Excel 技能点,秒杀众人(多图)
原创教程:用Excel做纵向折线图
知识图谱——机器大脑中的知识库
何明科专栏:用数据化的方式解析投资条款
DT时代,如何用大数据分析创造商业价值(23页PPT)
MIT牛人梳理脉络详解宏伟现代数据体系
你的老婆是怎么算出来的?揭秘佳缘用户推荐系统
飞林沙:商品推荐算法&推荐解释
PPT:如何成为真正的数据架构师?(附下载)
开源大数据查询分析引擎现状
董飞专栏:打造数据产品必知秘籍
译文:如何做强大又漂亮的信息图
如何使用Amazon Machine Learning构建机器学习预测模型
如何运用数据协助货架管理(内附26张PPT)
SVM算法
主流大数据系统在后台的层次角色及数据流向
PPT:阿里全息大数据构建与应用
人脸识别技术大总结——Face Detection & Alignment
教程:用Excel制作成对条形图
易观智库:大数据下的用户分析及用户画像(18页PPT附下载)
技术向:如何设计企业级大数据分析平台?
电商数据分析基础指标体系
IBM SPSS Modeler 决策树之银行行销预测应用分析
拓扑数据分析与机器学习的相互促进
基于 R 语言和 SPSS 的决策树算法介绍及应用
用php做爬虫 百万级别知乎用户数据爬取与分析
另类新浪微博基本数据采集方法
以10万+阅读的文章为例 教你做微信公众号的运营数据分析
破解数据三大难题:变现?交易?隐私?
微店的大数据平台建设实践与探讨
阿里巴巴PPT:大数据基础建议及产品应用之道
基于社会媒体的预测技术
人工智能简史
技巧:演讲中怎样用数据说话
马云和小贝选谁做老公?写给非数据人的数据世界入门指南
掘金大数据产业链:上游资源+中游技术+下游应用
原创教程:手把手教你用Excel做多层折线图
销售分析:如何从数据指标发现背后的故事
如何一步步从数据产品菜鸟走到骨干数据产品
也来谈谈微博的用户画像
行走在网格之间:微博用户关系模型
如何拍出和明星一样美爆的自拍照?斯坦福大学用卷积神经网络建模告诉你
运营商如何玩转大数据? 浙江移动云计算和大数据实践(PPT附下载)
大数据分析的集中化之路 建设银行大数据应用实践PPT
腾讯防刷负责人:基于用户画像大数据的电商防刷架构
创业提案的逻辑
友盟分享 | 移动大数据平台架构思想以及实践经验
寻路推荐 豆瓣推荐系统实践之路
“小数据”的统计学
重磅!8大策略让你对抗机器学习数据集里的不均衡数据
小团队撬动大数据——当当推荐团队的机器学习实践
微博推荐架构的演进
科普文 手把手教你微信公众号数据分析
信息图制作的六个注意点
【权利的游戏】剧透新玩法:情理之中?意料之外
推荐系统(Recommender System)的技术基础
核心算法 谷歌如何从网络的大海里捞到针
Quora数据科学家和机器学习工程师是如何合作的
阿里巴巴PPT:大数据下的数据安全
数据建模那点事儿
全民拥抱Docker云–Lhotse系统经验分享
实时股票分析系统的架构与算法
架构师必看 京东咚咚架构演进
什么叫对数据敏感?怎样做数据分析?
推荐系统基础知识储备
刘德寰:数据科学的整合与细分 数据科学的七个危险趋势(视频)
实际工作中,如何做简单的数据分析?
分布式前置机器学习在威胁情报中的应用(附PPT下载)
数据科学 怎样进行大数据的入门级学习?
扛住100亿次请求 如何做一个“有把握”的春晚红包系统?(PPT下载)
从 LinkedIn 的数据处理机制学习数据架构
大数据会如何改变管理咨询公司(I)
优秀大数据GitHub项目一览
生硬的数字和数据新闻:这么近,那么远
经典大数据架构案例:酷狗音乐的大数据平台重构(长文)
揭秘中兴大数据在银行领域的系统部署
基于大数据的用户画像构建(理论篇)
【R】支持向量机模型实现
数据图处处有陷阱?五个例子教你辨真伪
如何用R绘制地图
你确定你真的懂用户画像?
数据模型需要多少训练数据?
【接地气】01 数据报表的颜色怎么配
游戏价值和数据分析新思路
【R】异常值检测
快的打车架构实践
豆瓣还是朋友圈:大数据、新方法和日常问
PPT数据图表,怎么做才好看?
大道至简的数据体系构建方法论
数据的误区及自身业务
新浪微博的用户画像是怎样构建的?
面试干货!21个必知数据科学面试题和答案part1(1-11)
易观智库:中国大数据产业生态图谱2016(附下载)
Airbnb的数据基础架构
50PB海量数据排序,谷歌是这么做的
大数据时代工程师如何应对–今日头条走进硅谷技术讲座
D3.js教学记(下)
D3.js教学记(上)
飞林沙:企业级服务公司如何赚钱?只有平台级产品才有大数据的理论
一个母婴电子商务网站的大数据平台及机器学习实践
7大板块 组成数据分析师的完整知识结构
干货:SaaS领域如何分析收入增长?
学术 | 词嵌入的类比特性有实用意义吗?
6个用好大数据的秘诀
一个数据库外行眼中的微信优化 (附专家补充)
大数据调研,如何实现快全准?
数据大师Olivier Grisel给志向高远的数据科学家的指引
数据堂肖永红:数据交易的是使用权或数据的增值,而不是数据本身(PPT附下载)
淘宝商品详情平台化思考与实践
刘译璟:百分点大数据理念和实践(图文+PPT下载)
如何快速搞定一份看起来还不错的演示文档?
【BABY夜谈大数据】决策树
数据驱动设计:数据处理流程、分析方法和实战案例
美图数据总监:Facebook的法宝,我们在产品中怎么用?
树的内核:量化树结构化数据之间的相似性
拿到用户数据之后,LinkedIn怎么赚钱?
GrowingIO张溪梦:增长黑客的核心 企业应该重视产品留存率(附PPT下载)
[译]Airbnb是如何使用数据理解用户旅行体验的?
微博推荐数据服务代理: hyper_proxy的设计和实现
星图数据谷熠:消费领域DaaS 大数据重构未来商业游戏规则(附PPT下载)
鲍忠铁:TalkingData大数据技术与应用实践(PPT下载)
【干货教材】数据分析VS业务分析需求
九枝兰专访:数字营销的核心—企业如何使用数据管理平台(DMP)进行精准营销
我们的应用系统是如何支撑千万级别用户的
R应用空间数据科学
Excel进行高级数据分析(上)
Excel进行高级数据分析(下)
国内各大互联网公司2.0版技术站点收集
网站数据分析思路导图
大数据分析报表设计开发要素
大数据需要的12个工具 推荐
YARN/MRv2 Resource Manager深入剖析—NM管理
YARN/MRv2 Resource Manager深入剖析—RMApp状态机分析
Hadoop 1.0与Hadoop 2.0资源管理方案对比
Hadoop 2.0中单点故障解决方案总结
Hadoop 2.0 (YARN)中的安全机制概述
Hadoop 新特性、改进、优化和Bug分析系列1:YARN-378
Hadoop 新特性、改进、优化和Bug分析系列2:YARN-45
Hadoop 新特性、改进、优化和Bug分析系列3:YARN-392
Hadoop版本选择探讨
探究提高Hadoop稳定性与性能的方法
《Effective C++》读书笔记(第一部分)
Hadoop分布式环境下的数据抽样
Hadoop计算能力调度器算法解析
如何编写Hadoop调度器
数据结构之红黑树
Hadoop pipes设计原理
《C++ Primer plus》学习笔记之”类”
《C++ Primer plus》学习笔记之”类继承”
《C++ Primer plus》学习笔记之”C++中的代码重用”
《C++ Primer plus》学习笔记之”异常”
《C++ Primer plus》学习笔记之”RTTI”
Hadoop pipes编程
Hadoop Streaming高级编程
《C++ Primer plus》学习笔记之”标准模板库”
《C++ Primer plus》学习笔记之”输入输出库”
Linux Shell 命令总结
算法之图搜索算法(一)
awk使用总结
素数判定算法
《C++ Primer plus》学习笔记之“函数探幽”
使用Thrift RPC编写程序
如何在Hadoop上编写MapReduce程序
怎样从10亿查询词找出出现频率最高的10个

小团队撬动大数据——当当推荐团队的机器学习实践

于2017-04-01由小牛君创建

分享到:


张相於

 

 

 

 

作者:张相於

当当个性化推荐开发经理

86年生人,人民大学本科硕士毕业,现任当当个性化推荐开发经理。从事推荐系统、机器学习系统等方面工作,并关注互联网金融、反欺诈、风险控制等机器学习技术的新应用。

联系方式:zhangxiangyu@dangdang.com

 

下面是正文:

当当个性化推荐开发经理张相於深度分享当当推荐团队的机器学习实践经验,侧重介绍一个小团队在构建系统时的一些实践,一些坑,以及如何从坑里爬出来。当当构建机器学习系统过程中踩过的坑主要包括:只见模型,不见系统;不重视可视化分析工具;过于依赖算法;关键流程和数据没有掌握在自己团队;团队不够“全栈”;巨型系统。工具方面,当当在探索阶段选择的是R和Python,大数据阶段则主要依靠Hadoop和Spark,目前集群是几百台的规模。在“全流程构建”的不断迭代中,当当还总结提取出的一套特征工程相关的工具——dmilch。


先说一下我的初衷。机器学习系统现在多红多NB这件事情我已不必赘述。但是由于机器学习系统的特殊性,构建一个靠谱好用的系统却并不是件容易的事情。每当看到同行们精彩的分享时,我都会想到,这些复杂精妙的系统,是怎样构建起来的?构建过程是怎样的?这背后是否有一些坑?有一些经验?是否可以“偷”来借鉴?

所以我希望做一个更侧重“面向过程”的分享,与大家分享一下我们在构建系统时的一些实践,一些坑,以及如何从坑里爬出来。

另外,我本次分享更侧重的是“小团队”,一是因为当当目前做ML的团队确实还比较小,其次是因为据我了解并不是每个企业都像BAT那样阵容庞大整齐。所以小团队的经历和实践或许会有独特的借鉴意义,希望这次分享能从不一样的角度给大家提供一些参考。

大数据

今天分享的实践经历来自当当推荐组的ML小团队。

大数据

我们的团队负责当当推荐/广告中机器学习系统从0开始的搭建、调优、维护和改进。除计算平台为其他团队负责维护以外,ML pipeline中的每个环节均要负责。生产的模型用于部分推荐模块和部分广告模块的排序。

大数据

分享开始之前,有必要阐明一下本次分享的定位。如上图所示,本次分享不涉及这些内容,对此有需求的同学可参考CSDN上其他精彩的分享。

大数据

上面这些,是本次分享所涉及到的,其中“面向过程”是本次的重点。分享的人群定位如下:

大数据

无论你处于构建机器学习系统的哪个阶段,如果能从本次分享有所收获,或者有所启发,那笔者带着“长假后综合症”做的这个PPT就没白忙活……

大数据

这是我们本次分享的大纲:先简单谈一下我对“小团队”的一些认识,再花主要的时间和大家分享一下当当的小团队机器学习实践。接着我会总结一些我们实践中猜到的坑,以及从这些坑中学到的东西。然后我会以一些参考文献为例,做一些对未来工作和可能方向的展望。最后是问答环节。

简论小团队

首先谈谈我对小团队的认识。

大数据

为什么会出现小团队?这个问题乍一看有点像是句废话,因为每个团队都是从小到大发展起来的。这没错,但是机器学习的团队还是有一些属于自己的特点的。

  1. 相比一些功能性系统,机器学习系统的特点之一是不确定性,也就是这个系统搭起来的效果,是无法从开头就量化的。这导致决策层在投入上比较谨慎,不会在刚开始就投入太多人。
  2. 这方面人才确实比较稀缺,招聘难。简历看着漂亮的挺多,有实际能力或经验的其实很少。本着宁缺毋滥的原则,小而精的团队是一个更好的选择。

大数据

小团队做系统的挑战在哪里?这是我们关心的首要问题。小团队挑战的本质其实就是两个字:人少。从这个根本限制会衍生出多个具体的挑战。

  1. 首先是对单兵能力的高要求。这很容易理解,人少就意味着每个人都需要发挥很大的作用,因此对单兵能力要求比较高。对于这个问题,其实没有太多好的办法,主要就是外部招聘和内部培养。
  2. 其次是在系统开发过程中,大家一般都需要交叉负责多个任务,这既是对个人能力的挑战,也是对协作能力挑战。但是另一方面,这其实是对员工最好的培养,能够让大家以最快的速度成长。
  3. 再次就是方向和需求选择的问题。因为人少,所以在决定下一步行动时,需要非常谨慎,尽量减少无产出的投入。这有时确实是一种限制,但是换个角度来看,这“逼迫”我们把精力集中在最重要的部分,好钢都是用在刀刃上。
  4. 最后一点,就是单点风险较高。由于每个人都负责了比较多的部分,所以每个人的离职、休假等异动,都会对系统造成较大影响。这个问题同样主要是通过内部培养和外部招聘来解决,不过还有一个方法,就是用有挑战的事情留住人。哪种方法好使,就要看具体环境的具体情况了。

这样一看,小团队挑战不小,但是反过来看,小团队也有一些独特的优势。

大数据

  1. 首先就是团队易于凝聚。这也是任何小团队的天然优势。
  2. 其次是易于协作。很多事情不需要开会,转身几句话就可以搞定。
  3. 再次是迭代速度的优势。由于流程所涉及的事情全部由少数几个人负责,不需要协调过多的资源,那么只要这几个人使劲,迭代速度就会快起来。
  4. 最后一点,也是非常重要的一点,就是团队的成长。由于大家都要负责很多事情,那么成长速度自然就会很快,同时个人的成就感也会比较高,如果调配得当,会让整个团队处于一种非常有活力的积极状态。

当当推荐机器学习实践

下面我们花一些时间来分享一下当当的机器学习团队是如何撬动机器学习系统这块大石头的。

大数据

上图所示的是我们推荐后台的整体架构。从上面的架构简图中可以看出,机器学习系统是作为一个子系统存在的,与推荐作业平台(生成推荐结果的离线作业平台)发生直接互动。

这几个架构图只是让大家知道机器学习系统在在整个推荐系统中的位置和作用,不是本次分享的重点,没必要一定看懂。

大数据

这一页的架构图是上一页图中红框中部分的细节放大。从图中可以看出,机器学习系统是在结果排序中发挥作用的。关于这个架构的细节我在这里不做展开,感兴趣的同学可参照美团的同学前段时间的分享,是比较类似的架构。

大数据

上面的架构图是上一页架构中红框部分的进一步展开,也就是机器学习系统本身的一个架构简图。有经验的同学能看出来,这张简图中包括了机器学习系统的主要流程部件。

后面我们会说到这一套系统是如何搭建起来的,经历的过程是怎样的。系统初始阶段,是一个探索的阶段。这个阶段的意义在于,搞明白你的问题究竟是不是一个适合用ML技术解决的问题。

机器学习很厉害,但不是万能的,尤其是某些需要强人工先验的领域,可能不是最合适的方案,尤其不适合作为系统启动的方案。在这个阶段,我们使用的工具是R和Python。

大数据

上页右侧的图中,红色框住的部分是可以用R来解决的,蓝色框住的部分是用Python更合适的,绿色框住的部分是两者都需要。

为什么选择R和Python呢?

先说R。

  1. 是因为R的全能性,堪称数据科学界的瑞士军刀。
  2. 是因为R已经流行很多年了,属于成熟的工具,遇到问题容易找到解决方案。
  3. 当时(2013年)sklearn之类的还不够完善好用,而且有问题也不容易找到解决方案。

再说Python。

  1. Python的开发效率高,适合快速开发、迭代,当然要注意工程质量。
  2. Python的文本处理能力较强,适合处理文本相关的特征。
  3. Python和Hadoop以及Spark等计算平台的结合能力较强,在数据量扩张时具有可扩展性。

不过,R的部分现在其实也可以用Python来替代,因为以sklearn,Pandas,Theano等为代表的工具包都已经更加成熟。

但是当过了初期探索的阶段,到了大数据量的系统时,R就不再适合了。主要原因就是两个:可处理数据量小和处理速度慢

  1. 第一个是因为纯的R只支持单机,并且数据必须全部载入内存,这显然对于大数据处理是个很明显的障碍,不过现在的一些新技术对这一问题或许会有所缓解,但是我们没有尝试过。
  2. 其次就是计算速度相对慢,这当然指的也是在大数据量下的速度。

所以,如架构图中左边,一旦到了大数据量阶段,以Hadoop和Spark为代表的工具们就会登上舞台,成为主要使用的工具

过了初期探索、验证的阶段后,就要进入工程迭代的步骤了。

大数据

如图所示的是我们开发的一个典型流程。

验证通过之后,就进入下一个重要环节,我称之为“全流程构建”,指的是将要构建的ML系统,以及后面的使用方,全部构建起来,形成一个完整的开发环境。

这里需要强调的是“完整”,也就是不只是要搭建起ML模型相关的样本、特征、训练等环节,后面使用模型的环节,例如排序展示等,也要一同搭建起来。关于这一点在后面还会再次提到。

如果是初次构建系统,那么“全流程构建”将会花费比较长的时间完成。但这一步是后面所有工作的基石,投入的时间和精力都是值得的。

这个步骤完成之后,一个系统其实就已经构建好了 ,当然是一个只有型没有神的系统,因为每个部分可能都是完全未优化的,而且有的部分可能是只有躯壳没有内容。

之后就进入优化迭代这个“无间道”了,这部分的工作就是不断寻找可以优化的点,然后尝试各种解决方案,做线下验证,如何觉得达到上线标准,就做线上AB。在系统流程构建起来之后,后面基本就是在不停的在这个迭代中轮回。(无间道的本来含义是指18层地狱的第18层,寓意着受苦的无限轮回。)

大数据

其实这个开发流程,特别像盖房子的流程,先要打地基,之后建一个毛坯房,之后就是不断装修,各种验工,直到可以入住。住进去一段时间可能觉得哪里又不满意了,或者又出现了什么新的、更漂亮的装修方法,那可能又会再次装修。如此反复。直到有一天你发财了,要换房子了,那也就是系统整体重构、升级的时候了。

大数据

这一页介绍的我们使用的工具,都是一些市面上常见的主流工具,除了dmilch这套工具。

dmilch(milch为德语牛奶的意思):Dangdang MachIne Learning toolCHain是我们在不断迭代中总结提取出的一套特征工程相关的工具。包含了一些特征处理的常用工具,例如特征正则化、归一化,常用指标计算等。和linkedin前段时间开源出来的FeatureFu目的类似,都是为了方便特征处理,但是角度不同。

大数据

这一页介绍几个我们在工作流程中的关键点。其实小团队在这个方面是有着天然优势的,所以我们的中心思想就是“小步快跑”

第一个关键点就是改动之间的串行性。这或许是机器学习这种算法类系统的独有特点,多个改进一起上的话,有时就无法区分究竟是什么因素起到了真正的作用,就像一副中药一样,不知道起效的是什么,而我们希望的是能把真正的“青蒿素”提取出来。

第二点就是项目推进机制。我们大概每周会有一到两次的会议讨论,主要内容是验证改进效果,方案讨论等,并当场确认下一步的动作。

技术人员其实是不喜欢开会的,那为什么每周还有开呢?我认为最重要的一个目的就是让大家参与讨论,共同对项目负责,共同成长。承担的工作有分工,但是在讨论时无分工,每个人都要对系统有想法,有建议。这也能确保大家互相吸收自己不熟悉的地方,更有利于成长。

还有一个不得不说的话题就是关于新技术的尝试。如果沿用我们之前的盖房子的例子,新技术就好比高大上的家具摆设之类的,家里没个一两件镇宅的,都不好意思跟人打招呼。

这方面我们的经验是,先把已有的技术吃透,用透,再说新技术,不迟。例如推荐中的协同过滤算法,一般会在购买、浏览、评论、收藏等不同数据,不同维度都去加以计算,看哪个效果更好。当把熟悉的技术的价值都“榨取”干了之后,再尝试新技术也不迟。

还有一点很重要,就是别人的技术,未必适合你。不同公司的业务场景,数据规模,数据特点都不尽相同,对于他人提出的新技术,要慎重采纳。

我们曾经满怀信心的尝试过某国际大厂的某技术,但是反复尝试都没有得到好的效果,反而徒增了很大的复杂性。后来和一些同行交流之后发现大家也都没有得到好的效果。所以外国的月亮,有可能只是在外国比较圆。上什么技术,还是要看自己系统所在的土壤适合种什么样的苗。

这部分结束之前我简单介绍一下我们的模型在推荐广告上上线后的效果:推荐首屏点击率提升了15%~20%。广告的点击率提升了30%左右,RPM提升了20%左右。可以看出效果还是很明显的。

那些年,我们踩过的坑

下面进入今天分享的下一个重要环节,那就是我们踩过的各种坑。

“前事不忘,后事之师”,坑或许是每个分享中最有价值的一部分。我们在构建系统时也踩过很多坑,在这里和大家分享几个我认为比较大的坑,希望对大家有所帮助。我会先介绍几个坑,之后再说一下我们从坑里爬出来的感觉、收获。

只见模型,不见系统。

如果要把我们踩过的坑排个名,这个坑一定是第一名。因为如果掉进了这个坑,那么指导你系统方向的依据有可能完全是错的。

具体来说,这个问题指的是在构建系统时,我们一开始基本只关注机器学习模型的好坏,AUC如何,NE如何,但是没有关注这个模型到了线上的最终效果是如何。这样做的后果是,我们觉得模型从指标等各方面来看已经非常好了,但是一上线发现完全没有效果。因为我们忽略了模型是被如何使用的,一直在闭门造成一样的“优化”模型,最后的效果自然不会好。

那正确的姿势是怎样的呢?从我们的经验来看,在系统搭建的初期,就要明确地知道:你构建的不是一个模型,而是一个以模型为中心的系统。时刻要知道模型出来之后要干什么,要怎么用,这种大局观非常重要。

模型虽然是系统的中心,但不是系统的全部。在系统设计、开发、调优的各个阶段,都要从系统的角度去看问题,不能眼里只有模型,没有系统(产品)。否则可能等你调出一个AUC=0.99的模型的时候,一抬头发现已经和系统越走越远了。

所以,做机器学习系统要注意模型和系统并重,如果只看到模型而看不到系统,很可能会做出指标漂亮但是没有实效的“花瓶系统”来。

不重视可视化分析工具

这是一个开始很容易被忽视,但是到后期会导致你很难受的一个问题(这里指的是非深度学习的系统)。

因为机器学习系统某种程度上是个黑盒子,所以我们的精力会习惯性地集中在参数、模型这些东西上,本能地觉得模型的内部工作是不需要关心的。但是我们的经验是,如果只关注黑盒子的外面,完全不关心里面,那么如果模型效果不好,那么将很难定位到问题的所在。反过来,如果效果好了,也会有点莫名其妙,就好比你家厕所的灯忽然自己亮了,或者电视机忽然自己开了,总会让人很不踏实。

这个问题上我们的感触是很深的。我们最早在做系统的时候,发现效果不好,其实是没有太多章法能够帮助定位问题的。只能是把各种特征来回特征,样本处理上变一下花样,如果效果好了,就好了,不好,接着折腾。

后来我们做了一套web页面,上面把每条样本、每个case的特征及其参数,样本的出现次数,在候选集里的排序等等,全部展示出来。如同把整个系统加模型给做了一次解剖,希望能够尽量多地看到系统的内部细节,对于分析问题有很大帮助。

这个系统帮了我们很大的忙,虽然也不能算是“有章法”的做法,但是把很多东西呈现在你面前之后,你会发现有些东西和你想的不一样,也会发现一些你压根不会想到的东西。这对于机器学习这种有点像黑盒子的系统来说,尤为宝贵。到现在,这个系统是我们每次效果验证时非常依赖的一个东西,可以说是我们的另一双眼睛。

过于依赖算法

这个坑相信很多同学也遇到过。我就举一个例子吧。我们当时遇到一个文本处理的问题,要过滤掉大量无关无用的文本词汇。一开始上了很多各种算法,各种调优,但是迟迟得不到满意的效果。

最后我们亮出了绝招:人肉过滤。具体说就是三个人花了三天时间纯人工把文本过了一遍(几千个上万个词),效果立竿见影。当时那个问题,或许是存在效果更好的算法的,但是从系统、工程角度整体衡量一下,还是人工的ROI最高。

所以虽然机器学习是以算法为主的系统,但是也不能思维僵化,凡事都只想着用算法解决,有的地方,还是小米加步枪比较合适。

关键流程和数据没有掌握在自己团队

这个坑,可以说不是一个容易发现的坑,尤其是在系统初期,是比较隐蔽的。我们也是在吃了一些亏之后才发现这个问题的。

在很多公司里,前端展示,日志收集等工作是有专门的团队负责的,而诸如推荐广告这样的团队是直接拿来用的。这样做的好处很明显,可以让机器学习团队专注于本职工作,但是不好的一面是,他们收集到的数据并不总是我们期望得到的。

举个例子。我们一开始使用的曝光数据是兄弟团队帮我们做的,但是我们拿来之后发现和其他数据不太对的上,找了很久才找到问题。这个问题直接影响到我们拿到的样本的正确与否,所以对我们的影响非常的大。

那造成这个问题的原因是什么呢?其实并不是兄弟团队不认真,而是他们并不完全理解我们对数据的需求,他们也不使用该数据,所以数据的质量就会有风险。吃了这一亏之后,我们现在把这部分工作也拿来自己做,这样数据正确与否我们可以全程监控,出了问题也可以自己内部解决,不用协调各种资源。

团队不够“全栈”

这个坑是一个比较复杂的坑。在上一个坑中,我提到我们发现了数据质量有问题,之后自己做了这部分曝光收集的工作。但是定位问题原因和自己接手并不是在数据一有问题的时候就做到的。原因既简单又残酷:我们组里当时没有前端人才。

因为曝光问题涉及到从浏览器到后台系统的一系列动作,而前端是这些动作的第一个环节。但是我们在组件机器学习团队的时候,并没有意识到这里面会有前端什么事,以为有后台+模型的人就够了。所以导致我们面对这个问题比较无力。直到后来有一位有着丰富前端经验的同事加入我们组,我们才定位到问题,并且做出了自己接手的决定。

这个问题给我们的教训是:组建团队的时候要更谨慎一些,要从更系统的角度看待,不能说做机器学习就只招算法工程师,这样会导致团队级的短板,为一些问题埋下伏笔。

不过有的问题在遇到之前可能也难以预测,所以这个坑确实比较复杂。

巨型系统

最后一个坑,当然也要留给一个大坑。这个坑我称之为“巨型系统”。

巨型系统是什么意思呢?简单来说,就是把整个系统做成“一个”系统,而不是分模块做成多个子系统。做成一个系统的含义就是系统内部的模块之间有着高耦合性,强关联性,样本、特征、训练、预测等等全部粘在一起,无法分离。这样做的后果是什么?

直接举例子。我们第一版的系统,光上线就上了得有一周。而且之后的维护相当困难,想改东西非常困难。为什么会做成这样的,我的反思是:在学习理论的时候,就想当然得把样本、特征、训练这个pipeline当做一套东西了,这种思维直接反应到系统里就是一个巨型系统。或许在你只有十几个特征,几百条样本的时候没有问题。但是当你特征涨到几百万,样本涨到几千万的时候,就需要好好想一下,你的系统是不是有点大得失控了。

那更好的做法是什么呢?我们后来的解决方法是:大系统小做。“大系统小做”这个说法不是我发明的,是今年春节后(或者是去年)看到微信团队在说抢红包系统架构时说到的一个概念。我觉得这个说法提炼得很好,表示非常赞同。这个做法的意思就是,虽然你的系统很庞大,很复杂,但是做的时候还是要做好模块分离,这样利于开发,也利于扩展、维护。

机器学习系统的特点在于,刚开始你可能用的特征什么的都很少,所以觉得一个系统里就可以搞定,但是做着做着,需要对特征做各种变换,样本做各种处理,系统会在不知不觉中变得庞大,而如果你只关注模型的话,很容易造出一个无法维护的巨型系统来。

万里长征刚起步

我们的团队在经历了刚刚这许多“坑”之后,一个系统可以说是搭建起来了,但是这只是万里长征的第一步。对于我们如此,其实对于机器学习系统这个新事物,本身也有着不同于传统软件系统的诸多复杂之处,还有很多的挑战需要去解决。我在这里用两篇参考文献简单介绍一下这些复杂之处,以及面对的挑战。有兴趣深入了解的同学可以找文章具体看看。

大数据

第一篇是Google Research的一篇paper,讲的是机器学习技术债。题目也很有意思,可以翻译为:“机器学习:高利息的技术债信用卡”。

这篇文章主要说的是机器学习系统的搭建非常地复杂,如果缺乏经验,或者不够谨慎,在许多环节就容易“欠债”,这些债务当时觉得影响不大,但是由于“利息”很高,到后来会让你还起来很痛苦。

上图是我看了文章之后根据文章自己整理的,技术债的几个具体维度。这几个维度和我们自己的实践也是高度吻合的,当时看文章也是满膝盖的箭。

例如图中右上提到的“子系统边界模糊”,和我之前说过的“巨型系统”有类似之处,说的也是系统内部无分割。

再例如右下提到的“system-level spaghtti(系统级意大利面)”。意大利面代码常用来指代乱成一团的代码,由于机器学习系统一般都是在探索中搭建起来的,不像其他系统那样完全设计好再搭建,所以很容易产生意大利面代码。

如果能在搭系统之前参照这些维度加以考虑,那么系统的开发、升级和维护会轻松很多。相信这些经验也是Google这样的巨头公司摔了很多坑总结出来的。巨头尚且如此,对我们来说自然也不简单。

大数据

接下来这篇文章是现在在FB的SGD大牛Leon Bottou在ICML 2015上做的一个tutorial。题目叫:Two big challenges in machine learning,是一篇比较偏系统实践的文章,说的是机器学习面临的两个新的挑战。

第一点就非常地骇人听闻:机器学习破坏了软件工程。但是仔细想来,确实如此。机器学习系统的开发流程大多是探索式、渐进式的,这一点和传统的软件工程非常不同,这就给系统开发者们提出了挑战。我觉得以后很可能会出现专门的“机器学习系统架构师”职位。

第二点说的是当前的实验方式方法也遇到了极限。这一点乍一看是说科学实验的,其实不然。机器学习系统开发由于是探索式的,所以在开发中要经常做各种实验,验证各种效果,这个整体方法框架,也是需要精心设计的。显然在Bottou看来,目前的方法都不太合适。

via:CSDN