透明思考


Transparent Thoughts


  1. 机器学习项目如何管理:看板

    在前面的文章中我们看到,涉及机器学习、人工智能的项目,普遍地存在项目管理的困难。然后我介绍了针对这类项目如何设置合理的期望,并且深入分析了机器学习项目的工作内容。既然已经知道如何设置客户的期望、又知道可以做哪些事来逼近这个期望,那么围绕期望和动作进行任务的拆解、管理和可视化应该是顺理成章的。

    前一篇文章中我们已经看到,一个机器学习项目涉及的三类九项工作内容当中,只有一项(“自行训练模型”,上图右下角标星星的部分)不是传统的软件开发任务。只有针对这项工作内容,我们需要新的任务拆解和管理方式,其他部分可以用标准的Scrum方法来处理。

    对于“自行训练模型”过程中的具体任务,可以沿用学校里做实验的概念,将每次模型训练记录为一次“实验”。每次实验应该包含两个部分:

    • 输入部分,即实验的初始状态:数据从哪里来;如何对原始数据加工;选取哪些参数;如何训练模型
    • 输出部分,即实验的效果:模型是否准确描述训练集;模型是否overfit训练集;有多少false positive;有多少false negative

    于是我们得到了一张“实验卡”,上半部分记录实验输入,下半部分记录实验输出。

    把若干张实验卡放在一个看板上,就得到了可视化的实验管理墙。在项目启动时,首先制定一部分实验计划(以一批实验卡的形式),记录每个实验设计的输入部分。每做完一个实验,就在对应的实验卡上记录实验输出。在项目进展过程中,也可以不断增加新的实验卡。项目过程中,做实验的优先级由上一篇文章中介绍的“自行训练模型的流程”来判断:从一个简单的模型开始,首先尝试能降低Bias的实验,当Bias逼近期望时,再做降低Variance的实验。

    作为项目管理者,对着这样一面实验看板墙,需要关注的信息有以下几个方面:

    • 看产出:实验效果(Bias-Variance组合)是否逼近预期?接下来应该做哪些实验?
    • 看计划:实验计划是否完备?是否考虑到各种可能的算法?是否考虑到各种数据来源?是否考虑到各种数据加工方式?
    • 看进度:做实验的速度有多快?训练集获取是否耗时太长?模型训练是否耗时太长?是否需要优化训练算法?是否需要增加计算资源?是否需要提高数据流水线自动化水平?

    用这种方法,我们可以把看似神秘的机器学习项目拆解成独立、可讨论、有价值、可估计工作量、相对较小、可测试(INVEST)的实验卡,于是我们可以用Scrum方法来管理和度量围绕这些卡开展的工作。


  2. 区块链:原理和应用解读

    (正值五四青年节之际,谨以此文送给有志青年们,祝大家多学技术,多写文章。)

    区块链进入大众视野,是从比特币开始的——准确说,是从某些人因为比特币一夜暴富的传奇开始的。然而在随后的区块链热潮中,应该说大部分人是懵逼的。百度百科上,区块链的定义是这样:

    区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。所谓共识机制是区块链系统中实现不同节点之间建立信任、获取权益的数学算法。

    嗯,看得懂的人请举手。

    一种如此难懂、绝大多数人不知道它究竟有何特点的技术,突然获得如此大的关注,怎么可能不被用于割韭菜、收智商税?(用区块链收智商税的终极形态,请看“傻逼链”。)但是我要说,区块链不仅是一种可以被掌握技术的资本家和骗子用来割韭菜的工具,它还是可以有一些靠谱的应用场景的。

    到底什么是区块链?

    很多人大概都听过某个版本的关于“什么是区块链”的解释。但我这个版本,经过验证,没有IT背景的土老财也能听懂,因此很可能是最适合广大人文社科有志青年来听的版本。

    想象一个场景。某甲和某乙,两人合伙做生意。他们马上就有一个挑战:由谁来记账?这两个人必须互相信任,否则任何一个人记账,另一个人都可以怀疑他:你是否少记了一笔收入中饱私囊?这两个人如果各执一词,没有办法调解,所以他俩脆弱的信任如果破裂,生意就做不下去。

    现在两个人的合伙里又加入了一个某丙,三个人,情况会好转吗?并不会。丙负责记账,甲照样可以怀疑:你和乙是不是串通一气的?你们是否少记收入自己私吞了?

    那么大家是怎么解决这个信任危机的呢?办法有两个。第一个,是大家常见的办法:新来的丙是个持证的会计师,那么大家都可以信任他了。我们深究一下,为什么这种方式可行?为什么丙拿一本证书,就突然建立起了信任?原因当然是,丙如果被发现营私舞弊,他可能被吊销会计师资格,甚至可能身陷囹圄。这种风险太大,使得丙不太可能在常规的生意中这么做。而这种风险(换个角度,即围绕这本证书的信任)是由谁来背书的?答案是政府。政府用国家机器的暴力力量确保了,绝大多数情况下,会计师不会营私舞弊,会计师记的账是可以信任的。这个信任的背后,是枪在背书。

    有了这个认知,我们可以去看看社会上绝大多数的信任机制,你会发现,几乎所有陌生人之间的契约和信任,都是国家机器、是枪在背书。为什么我拿钱可以买到面包?纸币的背后是国家的枪在保障,任何人一定认可它的交换价值。为什么我刷个信用卡也可以买到面包?招商银行的背后是央行在保障它的承兑能力,央行的背后是国家的枪。为什么我在淘宝上买的东西不满意就可以退货?因为货款在支付宝里,支付宝背后有银行保障它的承兑能力,最终背后还是国家的枪。

    基于枪建立起来的信任机制足以满足大多数商业场景。但假如这个三人合伙做的不是合法生意,他们不想让国家机器知道这个生意,他们的信任危机又该如何解决呢?这里有第二种方法:三个人各记一本帐,分别都记录所有交易。如果帐对不上,以多数人相同的记录为准。当然,在三个人的情景下,这种机制能建立的信任还是很有限,因为你只要收买一个人就可以占到多数。但如果参与记账的有成百上千人,收买大多数的成本就会很高。随着参与记账的人越多,整套记账机制的可信度就越高。

    这种“每个人都记一本账”的机制,就叫“分布式账本”。围绕着分布式账本建立的信任,不需要国家的枪背书,也不会因为任何一个人的腐化或者退出而破坏。所以我们说,这是一种“去中心化”的信任机制。

    同时,虽然分布式账本是不需要国家的枪了,但分布式账本能实现,依赖于一个关键技术:所有的记账能迅速同步到所有账本。区块链就是实现分布式账本的关键技术。在这种技术中,每一次交易被记录为一“块”(block)数据,这样的“块”又彼此串联成一条“链”(chain),任何一个参与者都可以从任何一次交易的“块”牵出整条“链”,从而得到完整的分布式账本,这就是“区块链”(blockchain)这个名字的由来。

    比特币的价值从何而来?

    区块链的应用,最广为人知的无疑是比特币。但是只看各种正式的比特币介绍,你恐怕看不出为什么它有如此高的价值。比如说,一个正式的介绍可能会说,比特币是一种去中心的货币,它不需要国家为它的信用背书。但是,货币从来是用枪背书的,枪杆子越硬,货币就越值钱。一个不需要枪杆子背书的货币反而很值钱,这个逻辑是不通的。而这个不通的逻辑大家还能讲得这么热闹,恨不得把民主自由人权隐私全都放上来,说这个没有枪杆子背书的货币就应该值钱,这是一个很奇怪的现象。

    当一个东西很值钱但是大多数人都看不懂它为什么很值钱,大概会是两种情况。第一,有人在搅浑水养韭菜。第二,有些关键信息没有说出来。而比特币的情况,两者皆是。我们不谈养韭菜的部分,谈谈那些没有说出来的关键信息是什么。

    前面说了,分布式账本背书的去中心化信任机制,是在一个前提下有意义的:这个账本上记的账,参与交易的各方不想让国家机器知道。不然直接使用枪杆子背书的信任机制就好了。比如我们说比特币是一种货币(当然比特币实际上不是货币,但无所谓了,既然大家都说它是去中心化的货币,那就当它是货币好了),货币是用来买东西的,那么你买什么东西需要一种去中心化的、国家机器不插手的机制来建立信任呢?或者说,你买什么东西不能到淘宝去买(顺便叫卖家给你开张发票)呢?

    毒品。枪支。儿童色情。人体器官。代孕。各种只能在黑市上交易的非法商品。

    这就是比特币的拥护者们不肯/不愿/不能说出来的关键信息:比特币的价值,就是黑市的流动性。黑市对流动性的需求越大,比特币就会越值钱。(想炒币的有志青年请牢记这条基本价值法则。)

    带着这个知识,再反观国内的区块链热潮,你就会明白为什么我说现在国内做区块链项目的有一个算一个全都是割韭菜收智商税的骗子。为什么呢?现在你想做某个事情,做这个事情你需要一种信任机制,而这种信任机制你不能靠国家机器的枪杆子来给你背书,这意味着什么?你敢把这件事拿到互联网上来宣传,你的网站上还打着工信部的备案编号,然后你跟我说你做的这件事非得有去中心化的信任机制才行,不觉得自相矛盾吗?

    作为写作平台的区块链

    还别说,我在国内还真的看到过靠谱的区块链应用。比如说,如果把党建信息承载在区块链上(而不是保存在一个数据库里),效果是什么呢?效果是,假如有一天中国共产党的执政党地位被反动派颠覆了,党组织被破坏,党员被清洗,党组织的活动可以立即转入地下,整个党建链上记录的党组织信息不可伪造、不可篡改、不可删除。万一有那一天,党建链就是传递革命薪火的火种。这事情现在已经有单位在做了,可见我党的先进性和忧患意识。

    最近北大某同学的一篇文章又让我们看到了另一种靠谱的区块链应用。大家可以打开下面这个链接:
    https://etherscan.io/tx/0x2d6a7b0f6adeff38423d4c62cd8b6ccb708ddad85da5d3d06756ad4d8a04a6a2

    这是以太币(跟比特币相当的另一种去中心化数字货币)的一次交易记录。非常平淡的一次交易,这次交易本身的编号是“0x2d6a7b0f6adeff38423d4c62cd8b6ccb708ddad85da5d3d06756ad4d8a04a6a2”(以“0x”开头表示这是一个16进制的数字),它发生的时间是“Apr-23-2018 07:02:20 AM +UTC”,从编号“0x44938b01da1feb3f6fa1cf38870ee564e25d9bf3”的钱包转出,转入编号“0x44938b01da1feb3f6fa1cf38870ee564e25d9bf3”的钱包,转账的金额是“0 Ether ($0.00)”——对的,没真的打钱,不过没关系,金额为0也可以发起一次交易。所以真的是一次很无聊的交易。

    这个交易真正有趣的部分,在于它挂载的数据,也就是下面的“Input Data”字段。区块链的每个“块”是有一定容量的,交易者可以把与这次交易相关的备注信息放进去,备注信息也会随交易块同步到所有的分布式账本。现在,在这个交易的“Input Data”字段,你可以看到一长串16进制数字:

    如果你点击下面的“Convert To UTF8”按钮,你就会看到一篇熟悉的文章。我把这个探索的乐趣留给读者自己了,一定要去点哟。

    这篇文章,现在已经同步到了全世界上千万个分布式账本。除非收买其中超过50%的人,否则这篇文章无法篡改、无法删除。也许你在豆瓣的转发会被删,也许这个查看以太币交易信息的网站会被墙,但是这篇文章会一直在那里,国外能看到,翻个墙也能看到,谁也删不掉,包括你自己也删不掉,哪怕你妈跪下来求你也删不掉。

    所以,各位有志青年请记住,如果下次你想写一篇文章,并且你确定一定以及肯定绝对不会想删除这篇文章,不管是辅导员、校长、你妈、还是别的谁来求你,你都不会删除这篇文章,那么你可以把以太币、比特币之类的区块链平台用来做你的写作平台。你把文章发表到一次区块链交易的备注信息里,然后给大家发一个查看这次交易的链接。

    要我说,这才是区块链技术正确的打开方式。


  3. 浅谈大数据平台基建的逻辑

    这篇文章主要目的是面向初接触大数据的朋友简单介绍大数据平台基础建设所需要的各个模块以及缘由。

    数据仓库和数据平台架构

    按照Ralph Hughes的观点,企业数据仓库参考架构由下列几层构成:

    • 接入层(Landing):以和源系统相同的结构暂存原始数据。有时被称为“贴源层”或ODS。
    • 整合层(Integration):持久存储整合后的企业数据,针对企业信息实体和业务事件建模,代表组织的“唯一真相来源”。有时被称为“数据仓库”。
    • 表现层(Presentation):为满足最终用户的需求提供可消费的数据,针对商业智能和查询性能建模。有时被称为“数据集市”。
    • 语义层(Semantic):提供数据的呈现形式和访问控制。例如某种报表工具。
    • 终端用户应用(End-user applications):使用语义层的工具,将表现层数据最终呈现给用户,包括仪表板、报表、图表等多种形式。
    • 元数据(Metadata):记录各层数据项的定义(Definitions)、血缘(Genealogy)、处理过程(Processing)。

    把数据放到一起:数据湖

    企业大数据平台的核心是把企业数据资产汇集一处的数据湖。ThoughtWorks的“数字平台战略”这样描述数据湖:

    数据湖……的概念是:不对数据做提前的“优化”处理,而是直接把生数据存储在容易获得的、便宜的存储环境中;等有了具体的问题要回答时,再去组织和筛选数据,从中找出答案。按照ThoughtWorks技术雷达的定义,数据湖中的数据应该是不可修改(immutable)的。

    来自不同数据源的“生”数据(接入层),和经过中间处理之后得到的整合层、表现层的数据模型,都会存储在数据湖里备用。

    数据湖的实现通常建立在Hadoop生态上,可能直接存储在HDFS上,也可能存储在HBase或Hive上,也有用关系型数据库作为数据湖存储的可能存在。

    接入原始数据:数据通道

    企业大数据平台创造价值的基础是能把各种与业务有关的数据都接入到数据湖中,这就需要针对各种不同的数据源开发数据通道。数据接入的连接器(connector)通常是一个定时执行的任务,技术选型随数据源而定,有些项目采用定制开发的数据接入任务,也有些项目采用像Talend这样的套装工具。对于来自企业之外乃至互联网上的数据,可能需要编写爬虫。

    数据加工处理:数据流水线

    在数据湖内部,数据会经过“接入层 => 整合层 => 表现层”的加工处理链,逐步变成用户可用的形式。其中每一层的加工处理,至少包含ETL(提取-转换-装载)、指标计算、异常检测、数据质量管理等工作,还可能对数据进行语义标签、分类预测等更深入的操作。

    数据流水线的技术选型主要分为流式数据和批量数据两大类。在Hadoop生态中,Spark常被用于批量数据处理,Kafka和Spark Streaming的组合常被用于流式数据处理。

    面向业务领域:数据集市

    整合层存放了整个企业的数据,并且以规范化的、巨细靡遗的形式(例如Data Vault)对数据建模。表现层则与之不同:数据集市中的数据是针对业务应用领域选择出来的,并且建模形式更方便查询(例如宽表)。数据集市的技术选型也是为了查询的便利,例如采用ElasticSearch或关系型数据库,因为这些工具都支持很完备的查询功能,而且用户也非常熟悉。

    保障数据质量:数据治理

    在实施数据湖的时候,有一种常见的反模式:企业有了一个名义上的数据湖(例如一个非常大的HDFS),但是数据只进不出,成了“数据泥沼”(或数据墓地)。造成这种现象的原因之一,就是因为缺乏必要的数据治理:数据缺乏一致性、数据质量不佳,导致用户无法从数据中获得可靠的洞察。

    数据治理的基本工作包括了数据脱敏、数据质量管理、主数据管理等。AtlasFalcon等工具提供了数据治理的技术能力。

    探索未知:数据实验室

    数据自服务能力的一大亮点是鼓励小型的、全功能的团队自行从数据中获得洞察。为了形成从数据到洞察的快速响应循环,业务团队需要对整合层甚至接入层的数据做快速的探索和实验,而不是先完成接入-整合-表现的整个数据处理链。数据实验室提供模型管理和数据沙箱的能力,让业务团队能用Python、Java等通用编程语言快速展开数据探索和实验。PyTorch、Jupyter、Pandas等工具提供了便捷的途径来搭建数据实验室。

    供给应用:数据商店

    确定要提供给业务团队使用的数据,就可以进入数据商店,包装成数据产品或服务的形式供应出来。基础的形态可以是直接对外提供数据(通过数据库同步、事件订阅、文件服务等形式),在微服务语境下我们更鼓励的方式是以API的形式对外暴露数据服务,更进一步的想法可能是以SaaS服务的形式对外提供。例如Forbes认为以下几种数据服务已经具有较高的成熟度和接受度:

    • 用于benchmark的数据
    • 用于推荐系统的数据
    • 用于预测的数据

    大数据平台的全貌

    到这里我们已经看到了大数据平台各个组件的来由和形状:以数据湖为中心,由数据通道接入原始数据,经过数据流水线的加工处理,根据业务需求进入不同的数据集市,业务用户或是通过数据实验室探索、或是从数据商店获得自己需要的服务,整个过程接受数据质量和一致性的治理。再加上系统监控、日志管理、身份认证、任务调度、配置管理、项目管理、持续交付等通用的能力,我们就看到了一个企业级大数据平台的全貌。


  4. 敏捷在中国这十五年

    题记:2002年3月,《程序员》杂志发表了《极限编程》技术专题。以此为标记,敏捷进入中国已经十六年了。这篇文章是我去年为《程序员》写的年终回顾文章,发表于《程序员》2018年第1期。

    时至岁末,各种年度调查报告渐次登台。其中我注意到云栖社区发布的《2017开发者调查报告》中有一项数据:45.6%软件开发者所在的组织采用了敏捷软件开发方法,在各种开发方法学中位居第一。这个数字又让我联想起,CSDN在年初发布的《2016年度中国软件开发者白皮书》中提到,64%的受访企业采用了敏捷项目管理工具。虽然之前也曾经看到某些调查声称“98%的企业计划采用Scrum”,但我对于这些调查的采样范围一向存疑。云栖社区与CSDN的这两个报告,在我看来客观而坚实地明确了敏捷在当今IT行业的主流地位。

    作为站在传统企业数字化前沿的咨询师,来自各个行业甲方的动向也给我同样的感知。在电信行业,浙江移动大张旗鼓地开展敏捷转型与DevOps体系建设,并与咨询师结对公开演讲,介绍自己的转型经验。在金融行业,渣打银行的敏捷转型已经进行数年,汇丰银行以敏捷理念构建他们位于西安的研发中心,招商银行的CIO陈坤德在金融科技峰会中正面提出“银行必须敏捷化”,新成立的民营互联网银行更是从诞生第一天就把短迭代、自动化、持续交付等敏捷实践植入在基因深处。在汽车行业,7月发布的《汽车销售管理办法》打破了传统4S店对销售渠道的垄断,乘用车主机厂纷纷上马在线营销或销售系统,欲与已在地平线露头的汽车电商一争高下,短迭代、微服务、持续交付同样是他们在数字化渠道建设中的主题词。在航空行业,海南航空旗下的科技集团把自己转型成PaaS云供应商,组织文化、工作方式全面对标互联网企业,敏捷岛、看板、信息可视化等硬件设施已经成为研发团队标配。看着各行业头部企业的动向,我感到现在已经可以放心地说:敏捷,已然成为不可逆转的时代大潮。

    这股大潮在中国最初的涓滴潜流,大约要追溯到十五年前。2001、2002年,彼此互不相识的几组人,几乎不约而同地向中文世界引进与敏捷相关的资料。《程序员》杂志在2001年12月专栏介绍重构、2002年3月专栏介绍极限编程,是中文出版物中有案可查的最早的先行者。同在2002年,北京软件过程改进组织(PKSPIN)的成员唐东铭向人民邮电出版社推荐了Kent Beck的《解析极限编程》,后来这一套《极限编程丛书》于2002年10月出版。到2003年,《软件研发》杂志的创刊号大篇幅介绍敏捷方法,《重构》、《敏捷软件开发》、《自适应软件开发》等一系列重量级著作引进。今日的风起云涌,即肇始于当年的青萍之末。

    饶有趣味的是,唐东铭本人在后来的职业生涯中一直没有机会亲身经历一个敏捷的项目。他的经历,映出了行业的发展历程。敏捷所强调的快速迭代、持续交付,对于植根政府和大企业内部信息化、仰赖“十二金”工程哺育的尚处幼年的中国软件行业而言,是太过超前了。时至2006年,在第十届国际软件博览会上,Martin Fowler做了关于敏捷方法的主题演讲,台下报以他的是困惑的眼神与尴尬的沉默。语言固然是尚未全面与国际接轨的中国软件业理解Fowler演讲的阻碍之一,更大的鸿沟还是在于观念与意识。对于其时的行业环境与技术环境而言,每两周一次迭代、每次迭代发布上线给用户使用,既不可能、也不必要。中国的IT业还没有做好迎接敏捷的准备。

    决定性的转机发生在2008年前后。通信市场的争夺日趋白热化,4G相关产品的研发已经从原来先有规范后有产品,变成了规范产品同步进行,并且运营商也开始要求越来越多的定制功能。这种竞争态势,使各家大厂把应对需求变化、缩短交付周期放上了研发能力的优先级。从2005年底,诺基亚在杭州的研发中心已经开始试点敏捷,并把试点的成果带到了2006年与西门子合资的新公司里。2008年,诺西多条产品线开始大面积推广敏捷。同在2008年,爱立信也在大范围实施敏捷,将传统的功能团队转变为特性团队,用Scrum方法运作项目,并引入了持续集成实践。华为在印度的团队于2006年小规模试点敏捷,总部得知这一经验后于2007年开启一系列试点项目,并于2009年开始全面推广,特性团队、双周迭代、故事墙、持续集成等实践切实落到了基层。2010年落成的华为南京、上海两个新基地,都大量采用开放式办公区、敏捷岛的格局。在BAT气候大成之前,通信大厂是中国技术人才的重要源泉,这几家公司培养出的大量优秀敏捷教练与持续集成专家,为后来敏捷在行业里的广泛传播起到了推波助澜的关键作用。

    互联网大厂的敏捷起步也并非一帆风顺。2009年,百度把握住谷歌退出中国市场的机遇,全面对标谷歌,包括工程师的工作方式。从单一主干开发模式切入,百度大幅提高了研发过程中的自动化程度,把产品发布周期从几个月一次缩短到了每周一次发布。迟至2012年,腾讯某些产品还只能做到两三个月发布一次,通过模块解耦、提升自动化水平、拆分特性团队、持续集成等实践,得以逐步缩短发布周期,达到了每天能发布两个可用版本的水平。

    不过互联网大厂毕竟身处在时代大潮的前沿,时刻接触海量用户真实的行为反馈,以及每一点转化率提升带来的直接经济效益,使他们有直接的动力不断缩短发布周期。大野耐一强调的“湖水与岩石”理论在他们这里得到了淋漓尽致的发挥:发布周期从几个月缩短到一两周,可以靠组织和管理的改变;从一两周缩短到一两天、甚至一天发布若干次,必然要靠技术和平台的积累。BAT自不待言,美团作为二线互联网大厂,也把技术视为自身核心竞争力。对技术人员的尊重不仅体现在管理技术双线并行的职业路径上,也体现在开放、平等、追求卓越的文化氛围上。对技术的重视带来的反哺,则是平台实力的大幅提升。借由高效的数字平台赋能,领先的互联网团队已经超越了“敏捷”的范畴,开发人员无需刻意考虑敏捷的实践,眼前的数据和背后的平台已经驱动着他们自然地按照极短的发布周期不断演进产品。

    当互联网大厂以这样的高节奏从线上往线下席卷而来,各个行业的CIO们纷纷上马敏捷,看起来更像是在BAT收割之前的末路狂奔。已经被驱动起来的金融、汽车、零售行业,在一波与时间赛跑的敏捷浪潮究竟会剩下几家欢喜几家愁?有着大市场基数和高利润空间的教育行业,最近连续曝出令人不安的丑闻,这是否会成为政策放松管制、互联网竞争大举涌入的契机?医药行业树欲静而风不止,近有医药改革两票制全面触动流通环节即有利益、阿里健康倒逼医院改革,远处还有政府依托腾讯建设国家级医疗人工智能平台的愿景,医药行业的数字化、互联网化转型何时会进入快车道?航空行业谋求用数字化拉升资产效率,从民航维修、机场运营,到顾客体验、航线收益,再到搭建云生态平台,对未知场景、未知需求的快速感知和响应能力何时会排上航空业IT的优先级?这些可能都是我们在未来一两年内就会看到答案的事。

    作为中国敏捷十五年发展历程的亲历者与推动者,透过敏捷被引进中国、被推介、被传播、被漠视、被抗拒、被接纳、被推崇、被转变、被淡化的过程,我看到了整个中国IT行业、乃至中国经济发展的缩影。今天敏捷成为最为广泛采纳的软件开发方法,背后折射出的是IT在国民经济生活中的地位提升、是技术人员从外包码农到企业核心竞争力的地位提升、更是中国经济在全球经济中的地位提升。过去十五年,来自美国的敏捷软件开发方法指导了中国的IT行业;未来,中国的IT行业需要什么方法来指导,这个问题可能要靠我们自己来回答了。


  5. 数字化企业的实验基础设施

    前文中我们说到,传统企业在逐步建设自己的数字平台过程中,需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱。今天我们讨论的主题是数字平台战略的第四个支柱“实验基础设施”,看看一个倡导消除摩擦、建设生态、推动创新的数字化平台如何赋能快速、有针对性的商业实验。

    DPS全局观

    什么是实验基础设施

    作为数字化企业的代表,亚马逊是众多怀揣数字化梦想的企业学习的榜样。今天的亚马逊,在零售、广告、消费电子终端、应用商店、云服务等多个领域与各领域的领先企业竞争。更可怕的是,除了丰富的业务线,亚马逊还有Dash Button、Echo、Prime Air、AWS等大量创新。最可怕的是,据AWS的CEO说,除了这些大家知道的、获得了一定成功的创新项目,还有更多创新项目失败了——而亚马逊认为完全OK。亚马逊强大的创新能力,背后体现的是更为强大的快速实验、快速学习、快速调整的能力。缺少这种能力,就算把亚马逊的产品和模式摆在面前照抄,也无法跟上它不断创新的步伐。

    为了支撑数字系统的快速实验、快速学习、快速调整,需要在快速交付基础设施与数据自服务的基础上再考虑下列问题:

    • 需要从多种来源采集关于系统、关于顾客的数据
    • 需要根据业务目标在系统中埋设监控点,并及时把监控结果可视化呈现给业务用户。
    • 为了降低实验试错的风险,在把新版本发布给全部用户之前,应该以金丝雀发布的形式首先发布给一小部分用户,确保新版本不造成重大损害。
    • 系统需要支持功能切换开关(toggle),允许团队在不修改代码的前提下改变系统的行为。
    • 路由技术支持蓝-绿部署和A/B测试,方可高效地开展受控实验。

    实验基础设施详解

    数字平台中的实验基础设施由以下特性共同支撑。

    数据采集

    精益创业的核心逻辑是缩短“Build-Measure-Learn”的周期。为了从实验中学习,就需要全面采集实验数据。交付基础设施通常会包含技术性的监控和数据采集(例如基于ELK的日志监控体系),提供性能、资源、系统告警等角度的数据。

    单纯技术性的数据不足以对业务实验提供反馈,需要贯串用户体验,获取对业务有指导意义的数据。一个可供参考的框架是“海盗度量”:聚焦关注创新业务的获客、活跃、保留、推荐、创收(AARRR)这5个环节,从这个5个点上提出假设,然后用数据来证实或证伪假设。

    金丝雀发布

    金丝雀发布是一种控制软件发布风险的方式:在把新版本发布给全部用户之前,首先发布给一小部分用户,确保功能完好可用。金丝雀发布的主要目的是为了降低风险。新的软件可以先在与用户隔离的环境中接受UAT测试;如果新的软件有问题,受到影响的只是一小部分用户,不至于立即造成巨大的损失;如果新的软件有问题,可以立即回滚到旧版本。

    金丝雀发布最基本的形式,就是在前端反向代理上用路由技术把一定比例的用户导向“金丝雀”版本(例如Nginx可以支持多种筛选用户的方式)。在路由技术的背后,应该以凤凰服务器不可变服务器来实现每个服务,服务的创建和回收应该是完全自动化的。同时还需要需要端到端的综合监控,根据有业务语义的目标(例如转化率)是否发生突变来判断金丝雀的效果。

    Toggle架构

    Feature Toggle的目标是,通过架构设计允许团队在不修改代码的前提下改变系统的行为。常见的一些需要Toggle的场合包括:避免多个交付版本的代码branching/forking;避免未完成功能的代码branching/forking;运行时动态改变系统行为,以实现一些特定能力,例如:线上受控实验、针对不同用户权限提供不同服务、回路熔断和服务降级等。

    常见的Toggle可以分为4类:

    • Release Toggle:某些功能已经存在,但暂时不向用户发布。主要目的是为了基于trunk开发、避免开发分支。静态,生存周期短。可以用Togglz之类工具。
    • Ops Toggle:回路熔断,高负载或发生故障时自动降级服务。较动态,生存周期长。工具如Hystrix等。
    • Experiment Toggles:用于支持线上实验(例如Canary Release、A/B Test等)。动态,生存周期较短。采用路由技术实现。
    • Permission Toggles:用于给不同权限的用户提供不同的服务。引入统一的toggle router和toggle configuration,避免在代码中写条件。动态,生存周期长。

    Feature Toggle也应该以服务API的形式暴露出来,并且鼓励用结构化的、人类可读的配置文件管理Toggle。

    路由技术

    通过路由切换的方式,让用户在不同的时间、不同的场合访问到不同的服务实例(可能是不同的版本)。路由技术可以用来支撑多种实验性部署技巧,包括蓝-绿部署(零宕机部署)、A/B测试、金丝雀发布等。这篇文章介绍了这些部署技巧直接的关系。

    路由技术的实现与下层的弹性基础设施有很大关系,以AWS为例,有几种比较简单的实现蓝绿部署的方式:

    • 对于单个EC2实例,可以修改它的Elastic IP
    • 对于EC2集群,可以切换ELB背后的Auto Scaling Group
    • 可以用Route53修改DNS重定向
    • 可以用BeanStalk切换整个应用环境(如果应用部署在BeanStalk上)

    Cloud Foundry也有一组实现蓝绿部署的最佳实践

    可视化和埋点

    通过埋点获得系统运行时的信息,收集之后显示出来,从而把运维环境中的信息及时反馈回开发团队,缩短反馈周期。

    常见的埋点方式有:

    • 代码中埋点(例如New Relic、AppDynamics、Dynatrace)
    • 监控进程(例如StatsD、collectd、fluentd)
    • 日志(例如Splunk、ELK)

    数据需要用一体化的、直观可视的仪表板展示出来,从而快速指导业务调整。GrafanaKibana等工具提供了很好的仪表板功能,不过还是需要针对自己的情况加以定制。

    小结

    很大程度上,大部分组织的IT建设都谈不上“科学”。科学的基础建立在假说和实验之上,而在很多组织里,“有可能失败的项目”恐怕根本无法立项——更不用说“很有可能失败的项目”。降低做实验和犯错误的成本、从经验中尽可能多学习,是企业面对未知世界的唯一出路。然而快速的受控实验背后隐藏的是基础设施、软件架构、数据等多方面的技术支撑,把实验基础设施作为企业数字化旅程的阶段性目标,拉动各方面基础能力的建设,是建设数字平台的合理路径。


  6. 机器学习项目如何管理:工作内容

    前一篇文章介绍了机器学习的基本过程,然后讨论了如何对机器学习项目设置期望的问题。我们了解到,度量准确率的指标可以有多种,需要根据应用场景来选择。一旦选好了度量指标,接下来就可以围绕这个指标来划分任务、监控进度、管理风险。

    机器学习项目涉及哪些工作

    站在非常宏观的角度,机器学习系统工作的方式是:你有一个模型,你把一堆数据输入给它,然后你以某种方式使用它提供给你的输出。所以机器学习项目要完成的任务也是三大块:处理输入;获得模型;提供产出。

    1. 处理输入
      a. 你需要获得已有的数据
      b. 你需要对数据做矢量化操作,把原本丰富多样的数据变成有若干列的矢量
      c. 你需要对数据做特征工程,找出可能蕴涵了知识、值得被学习的那些特征项
    2. 获得模型
      a. 实际上很多时候你可以使用现成的模型,包括:(i)下载现成的离线模型,或者(ii)使用在线的人工智能服务
      b. 如果没有现成的模型,你也可以考虑使用现有的数据来自行训练模型
    3. 提供产出
      a. 机器学习的结果可能通过某种人-机(UI)或机-机界面(API)被用户直接使用
      b. 作为项目的产出,机器学习模型需要被嵌入到整个数据流水线中
      c. 作为项目的产出,机器学习模型的开发、测试、部署需要有DevOps的支撑

    在所有这些任务中,只有2.b“自行训练模型”(上图右下角标星星的部分)需要新的技能和管理方法,其他都是传统的软件开发任务,可以用标准的Scrum等敏捷方法拆分任务和管理。也就是说,如果你需要的人工智能能力已经有一个现成的模型提供,那么整个项目就是一个传统的软件开发项目,只是需要使用一些新的工具或API而已。

    下面我们聚焦讨论需要自行训练模型时,这部分工作应该如何拆分、如何管理进度和风险。

    自行训练模型的流程

    在自行训练模型的情况下,如上图所示,你会用历史数据(X和Y)来训练一个模型,然后用这个模型对未来的生产数据(X-hat)做预测(算出Y-hat)。不论采用什么指标来度量准确率,模型在训练数据上的表现一定好于在生产数据上的表现,这是因为模型从训练数据中“学到”的知识不一定在生产数据中完全重现,或者用黑话来说,模型在训练过程中“拟合”了训练数据的特征。也就是说,如果一个模型对训练数据表现出了95%的准确率(先不管采用哪个准确率指标),其实你并不知道这个模型对生产数据会表现什么水平的准确率,于是你也不知道这个模型是否好到可以上线运行。

    为了更有效地衡量模型的表现,我们会在开始训练模型之前先拿出一小部分历史数据(例如全部历史数据的10%)用于测试,整个训练过程不接触这部分数据。于是我们就有了“训练集”(training set)和“测试集”(test set)。很多时候我们还会分出一小部分数据作为“验证集”(validation set),为了简化问题,我们可以先采用“训练集+测试集”这种设置。

    把历史数据分成训练集和测试集以后,可以预期,模型在训练集上的表现会优于在测试集上的表现,这两个表现通常都会低于项目期望值。我们把“【模型在训练集上的表现】与【期望值】之间的差距”叫做Bias,把“【模型在训练集上的表现】与【模型在测试集上的表现】之间的差距”叫做Variance。

    于是就有3种可能的情况:

    1. High Bias:模型在训练集上的表现远低于期望,模型还不能实用(此时Variance如何并不重要);
    2. Low Bias, High Variance:模型在训练集上表现好,但是在测试集上表现差,模型还不能实用;
    3. Low Bias, Low Variance:模型在训练集和测试集上表现都好,可以投入实用。

    我们通常会从简单的机器学习算法、手边立即能获得的数据开始尝试。这时候通常Bias会高,因为过于简单的模型不足以呈现数据背后的知识,这时我们说模型“拟合不足”(Under-fitting)。在这种情况下,可以采用的措施包括:

    • 使用更复杂的机器学习算法
    • 使用更复杂的神经网络架构

    用更复杂的机器学习算法和神经网络训练出来的模型,通常能更好地拟合训练集,进入“Low Bias”的状态。这时我们再关注模型在测试集上的表现,如果测试集的表现远差于训练集的表现,就说明模型过度地针对训练集的特征做了优化,我们说模型“过度拟合”(Over-fitting)训练数据。在这种情况下可以采用的措施包括:

    • 引入Regularization通常能降低over-fitting的程度
    • 通过特征工程可以避免一些over-fitting的情况,例如排除掉一些严重过度拟合的特征
    • 引入更多的训练数据,包括数据量和特征量

    最终我们的目标是得到Bias和Variance双低的模型。

    潜在风险点

    从上述的工作流程中,我们可以预先识别一些潜在的风险:

    • 在Under-fitting的状态下,如果人员能力不足,就无法应用更复杂的算法
    • 在Under-fitting的状态下,如果计算资源不足,就无法训练更复杂的模型
    • 在Over-fitting的状态下,如果数据质量不足,就无法开展有效的特征工程
    • 在Over-fitting的状态下,如果数据数量不足,就无法训练高效的模型
    • 如果整个项目涉及的数据基础设施不足,就无法快速迭代实验

    于是,训练一个机器学习模型就不再是一个神秘的、盲目的、随机的过程。借助Bias、Variance、迭代实验的频率等量化数据,IT管理者和不懂技术的业务代表能更清晰地看到项目的进展,整个团队能更好地判断接下来需要做什么:是需要尝试更高级的神经网络呢?还是需要想办法获得更多的数据?或者是需要更多的计算资源?还是需要寻找某些特定的知识和技能?这样就避免了业务代表怀有不切实际的期望、又不知道技术团队在做什么而感到恐慌。

    在下一篇文章里,我会更加具体地介绍,如何借鉴Scrum和看板等敏捷方法的思路,把训练一个机器学习模型的工作拆分成更小粒度、更易于管理的任务,以及如何对机器学习项目进行可视化管理。


  7. 精准投放的原理及其担忧

    从WWW网站发源之初,网站的经营者们就清楚地认识到,自己经营的是一份媒体,就跟报刊杂志一样。媒体的收入,第一是来自读者付费,第二也是更主要的,是来自广告。于是站长们在自己的网站页面上开辟出或大或小、或纵或横的广告位,广告主则可以采购广告位。据笔者亲眼所见,迟至2001年,中国很多网站的广告销售方式仍然是由销售人员拿着一份打印出来的“刊例”(这个词也同样是来自报刊出版领域),直接向广告主介绍。购买广告位的方式,也通常是一家广告主承包一个广告位一段时间(通常是几天,有时长达几周),只有在最热门的广告位(例如首页顶部Banner)才有简单的轮换机制。广告收费是按照广告位与放置时长计算,网站几乎不向广告主反馈投放的效果。简而言之,这是在线广告的初创阶段,网站基本上是被当做报刊来经营的。

    这种投放方式显然是很原始的,最大的问题有两个:首先,广告主需要自己接洽多家媒体,分配各家媒体的投放预算,媒体则要自己管理多家广告主的投放排期,这对于广告主和媒体都是个很大的工作量;而且,广告投放出去以后效果如何,哪些媒体效果更好,后续投放应该如何调整,这些信息广告主无法获得,即使媒体有回馈数据,其中有多大成分的数据夸大,广告主也无从知晓。在这两个痛点的催生下,就出现了“媒体采买平台”的服务形式:经营这个平台的广告代理公司向大量媒体(即网站)购买广告位,广告主只要把广告投放到这一家代理公司,代理公司自会通过软件程序把广告派发到媒体。如此一来,广告主和媒体不用彼此一对一接洽,工作量都减少很多。并且在这个阶段,广告收费模式也改为按点击付费(通常会承诺一定浏览流量),广告主可以更准确地知道广告的效果,按实际效果付费。

    在媒体采买平台的基础上,相关的技术与业态又不断升级,逐渐形成了广告交易平台(ADvertisement eXchange,ADX)、供给方平台(Supply Side Platform,SSP)和需求方平台(Demand Side Platform,DSP)三大类平台协作的格局。供给方平台(SSP)为媒体服务,它负责汇集媒体广告位资源,尽量把广告位卖出最高价;需求方平台(DSP)为广告主服务,它负责汇集广告投放诉求,尽量以最低价格投放达到最佳效果;广告交易平台(ADX)则保持中立态度,为供需两方撮合交易,就像股市一样:只要有一个最高买价能匹配到一个符合条件的最低卖价,就会完成一次广告交易,DSP就会向SSP进行一次投放。

    IT技术创造的奇迹在于,这一系列看似复杂的竞价采购、交易撮合,可以在极短的时间内完成,因此交易的单元可以极小、交易量可以极大。在ADX发生的一次交易,标的物通常是“一次投放”,或者说是“一次浏览”。当你轻点鼠标,打开一个网页时,这个页面上的几个、十几个广告位就分别被SSP发送给ADX“叫卖”,匹配到出价最高的DSP“卖主”,然后把广告呈现在你面前。这整个投放决策的过程,业界标准要求在0.4秒以内完成。

    由于广告投放已经被细化到按次采购,于是广告位本身是否热门变得不再重要,竞价采购的对象变成了流量本身。当然,即使在网站发展初期、甚至在报刊杂志上,广告主和广告代理也会选择流量。例如雷克萨斯不会选择在城市晚报上投广告,而是会更多地在时尚杂志和飞机杂志上出现,这就是对“流量”(也即读者)做过筛选的结果。在这个例子里,丰田公司(或者其广告代理)从媒体属性上对读者的身份、职业、收入水平(统称为“流量属性”)有一个大致的推测,基于这个推测做了投放决定。然而受限于纸媒的技术特质,这个投放决定是非常粗糙的:第一,它能够获得的流量属性信息非常有限;第二,它只能对相当大的人群、在相当长的时间段上做决定;第三,它能得到的效果反馈非常少。

    而程序化的广告投放则完全克服了这三个局限:投放决定是基于每一次浏览、每一个流量来做出的;投放效果(有多大比例的用户点击广告)可以当天回馈给广告主;最重要的是,在线广告业务的经营者能够获得空前丰富的关于“流量”的信息。比如说,当你在微信中点开一个带广告的页面,DSP就有可能获得下列关于你的信息:

    • 你是谁:你的微信ID,你的手机号,你的性别、生日、星座、身高、体重、血型……
    • 你是个什么样的人:你的收入,你的生活方式,你的价值观世界观,你的意识形态,你的观点态度……
    • 你做哪些事:你上网看什么内容,你喜欢什么品牌,你买什么东西、在哪里买,你跟谁交朋友……
    • 你身边的环境:你在什么地方,你周围在发生什么,你在什么时间上网,你在乘坐地铁、公交车、还是滴滴专车……

    在线广告行业里把这些信息都称为“标签”,DSP就是基于这些标签来判断,现在点开网页的这个流量值多少钱,并在0.4秒内决定是否要投标竞价。所以当你听到“流量经济”、“流量就是钱”这样的说法,你应该意识到:这说的就是字面上的意思,每次浏览、每个流量都是有价的。

    也许你会怀疑,DSP怎么会知道我这么多信息?笔者可以透露,上面列举的这些标签,都是一个真实的IT系统中已经存在的标签,实际上DSP能获得的信息比这个列表只多不少。而且DSP非常有意愿知道更多流量属性,因此又衍生出了“数据管理平台”(Data Management Platform,DMP)。这些平台专门从各种来源收集与用户相关的信息,并把这些信息汇集起来形成“统一客户视图”(Single Customer View)——也就是给这个用户、这个流量贴上更加丰富的标签。

    举个例子来说明DMP的工作方式。当你在机场连上免费WIFI,你会看到一个登录页面,你输入手机号获得验证码,连上网络,这时WIFI热点背后的程序已经知道你的手机号、你用的手机款式、你所在的地点,这些信息马上被发送给一个DMP。这时你的朋友从微信发给你一篇文章,是介绍大明星的座驾,你细细欣赏了贝克汉姆的腹肌和他的奔驰G系越野车,于是这个网页背后的埋点程序知道了你对汽车品牌的偏好,这个信息和你的微信ID一起也被发送给一个DMP——很可能是同一个DMP。看完文章,你打开购物软件,买了几样水果送到家里,于是电商平台知道了你的消费能力和居住的小区,这些信息和你的手机号一起同样被发送给DMP。通过手机号、微信ID、身份证号……这些唯一身份标识,DMP建立起了关于你的统一顾客视图,可能会给你贴上成百上千个标签。

    基于这些标签,DSP就可以展开非常精确的广告投放。例如对于奔驰投放的Banner广告,DSP可能会优先考虑这样一些标签:30~40岁,年收入40~60万,居住在一二线城市,本科以上学历,从事IT、金融、房地产等职业,现在车龄6年以上,近期流露换车意向……一旦高度符合这些标签的流量出现,DSP就会高价拍下广告位。一些技术领先的DSP已经开始使用机器学习技术,不用人手挑选投放目标标签,而是由人工智能自动识别目标流量,使广告投放更加精准。

    然后,当你开始跟老婆讨论是不是该换台新车的时候,你无意间发现,手机上打开的网页里有一辆漂亮的奔驰C200休旅车,你点开广告链接,跟老婆一起左看右看,觉得这辆车既有面子又实惠,跟你家的风格简直是天作之合,于是你开心地按下了“预约试驾”。你大概不会多想,这个广告出现的时机怎么那么恰到好处。最终你买下了这辆车,就好像这完全是你自己的决定一样——就在你快要付款的一刻,你又瞥见手机网银的界面上有一个刷信用卡买车免息分期的活动,多巧呀。

    既然广告可以定制,有什么道理媒体上呈现的内容本身不能被定制呢?感兴趣的话,你可以自己做一个实验:首先看看你的知乎首页上有哪些内容,一般来说不会出现跟火影忍者相关的问答,毕竟火影大结局也有段日子了;然后下载腾讯动漫,每天看上几十话火影,用不了几天,你的知乎首页上就会出现一堆讨论鸣人和佐助的帖子。笔者亲身观察到这个现象,好奇地搜索知乎的投资方,腾讯果然在列。大胆猜测一下,知乎即使不是直接使用腾讯的DMP“广点通”,技术原理也相去不远。既然都看见“小樱的实力能到影级吗”这么有吸引力的帖子,怎么能不打开看看呢?于是现在笔者的知乎首页上,各种忍术已经连绵不绝了。

    内容定制正在成为数字化营销的主流工具。和纸媒不同,数字化产品的每次打开、每次浏览都可以是动态的、个性化的。DMP已经掌握了如此丰富的用户洞察,媒体没有道理继续保持一成不变的内容呈现,一定会利用DMP的数据来达成更高的转化率——可能是转化为购车的消费者,也可能是转化为支持某个政策的变革、某种意识形态的观点。于是我们看到,像今日头条这样的媒体,呈现内容的原则不是“外面在发生什么”,而是“读者喜欢看什么”——当然纸媒也有过度迎合读者的风险,但纸媒毕竟只能面向大群读者做一个粗糙的推测,而互联网媒体(和社交网络)则在技术的推动下形成了一个完美的、牢不可破的回音壁。至于传统意义上媒体要客观中立地展现世界样貌的职责,在转化率这个KPI的驱动下显得有些苍白无力。

    精准投放可能带来什么危害呢?数据科学家Cathy O’Neil在《数学大杀器》(Weapons of Math Destruction)一书中介绍了一些已经现实发生的场景。其一,基于数据的精准投放如果被用于教育、医疗、保险等与生活休戚相关的“商品”上,就可能造成对特定人群、尤其是弱势人群的歧视和损害。在美国,有一些质量低劣的教育机构,把自己的广告定向投放到收入低、教育程度低、并且新近遭遇人生重大打击的人群——例如刚离婚、或刚被解雇。这样的人群、处于这样的心理状态下,更容易被这些心灵鸡汤式的广告吸引,从自己原本就已经拮据的经济中再拿出一笔不菲的资金,来参加一个对自身能力没有提升、也不被人才市场承认的培训计划。在中国我们也看到,尽管百度宣称其中立性,但莆田系在百度上投放的医疗广告同样精准地找到了教育程度较低、经济状况较差、已经饱受疾病损害的那些弱势家庭。

    另一方面,当精准投放被应用于政治目的,它能够强化大型利益团体对群众观点和政治议程的操控。2011年奥巴马的竞选团队与IT咨询公司埃森哲合作,首次在美国总统选举中引入了大数据和精准投放技术。在2015年的大选中,“共和党犹太人联盟”的领导者们在拉斯维加斯的威尼斯人酒店开会,在酒店上网时他们看到候选人泰德·克鲁兹承诺加大对以色列安全支持力度的广告宣传。他们不知道的是,这条广告只在这家酒店、只在他们开会的这几天播放。当政治家和利益团体可以不必保持连贯统一的公众形象、而是可以针对受众“定制”其形象和政治观点,这种变化究竟会给公共生活带来什么影响,可能答案还并不清晰。

    在《数学大杀器》中,O’Neil提出了一些限制大企业过度利用个人数据的途径,例如效仿欧洲对互联网数据的管制模式:只有在用户明确同意的情况下,企业才能采集用户数据,且采集到的数据不能用于其他用途。“明确同意”的规定,可能仍然容易通过隐晦的用户协议等方式来绕过;但“不作它用”的规定,对于数据滥用是一个很好的预防措施。至于国内的相关管制会在何时、以何种形式出现,目前仍是未知。在可见的将来,恐怕我们还得继续享受互联网提供给我们的精准得有点细思极恐的广告和内容。


  8. 机器学习项目如何管理:设置期望

    我在之前的一篇文章中提到,机器学习项目如何管理,目前在行业内是一个普遍存在的难题。具体而言,对于这类项目,我们需要一套行之有效的工作办法,帮助一线工作者:(1)知道什么时候该做什么事;(2)知道什么时候该看什么指标;(3)知道什么时候可能有什么风险。这样一套工作办法的第一步,就是对一个机器学习项目设置合理的期望。

    机器学习到底是在做什么

    机器学习的基本过程可以用下面这张图来呈现:

    拿到已有的历史数据作为训练数据,我们需要对训练数据进行矢量化处理,把输入的不论什么形态的数据(例如文本、音频、图片、棋盘盘面)都转化成包含若干列的矢量。从矢量中我们再分出特征(X)和结果(Y),通常特征的列数远多于结果。

    我们把X部分交给一个模型,算出与每一行训练数据对应的预测值Y’。所谓模型,就是一系列的权重系数,把这些权重系数用在一行输入数据上,就会得到针对这一行输入数据的结果预测。我们把Y’与Y对比,评判这一轮预测的效果。这个效果,我们用损失来度量。

    然后我们用一个机器学习算法来尝试优化损失。所谓优化,就是不断尝试调整模型中的权重参数。调一次,再计算出一组新的Y’,再与Y比较效果。如此迭代,直到损失不再降低,或者达到预设的迭代次数。

    所以,首先必须要记住:机器学习是一种优化任务。优化任务的目标不是找到“正确”的答案,而是找到一个“看起来不错”的答案。这一点会对我们看待这类项目的方式产生深远的影响。

    如何为优化任务设置期望

    传统意义上的软件开发(例如开发一个电商网站、开发一个社交app)是能够得到确定结果的:只要需求分析得够细致、原型设计得够保真、测试进行得够周全,你就可以准确地框定一个软件开发过程的产出结果,点击哪个按钮得到什么效果都是可以预先定义的。而机器学习项目则不然:不论分类、回归、聚类,本质上都是对某个损失函数迭代优化的过程。它没有唯一正确的答案,只是有希望得到看起来不错的答案。优化任务的逻辑不是因果,而是概率。

    对于优化任务,我们不能问“是否正确”这个问题。有意义的问题是,模型的预测准确率能达到多少。一个缺乏经验的管理者可能会说“越高越好”,或者拍脑袋说出一个数字“90%”,显然这都不太有助于合理地管理期望和把控进展。暂时放下“准确率”的定义不谈,我们如何知道对于一个机器学习得出的模型应该期望什么样的准确率呢?显然大多数情况下预测准确率不可能达到100%,那么这个期望应该如何设置?

    我们需要引入一个概念:贝叶斯错误率。简单说,贝叶斯错误率是对于一个问题有可能达到的最好的预测效果。贝叶斯错误率通常不是那么容易直接获得的,所以我们用人类的判断作为一个代理指标:一般来说,我们认为人类的判断错误率高于贝叶斯错误率,但是也相差不大。于是前面的问题变成了:对于一个机器学习得到的模型,我们期望它的预测准确率与人类的判断相比如何?

    这个问题没有唯一正确的答案。有些时候我们希望模型的准确率高于、甚至远高于人类的判断;另一些时候,我们只需要模型的准确率勉强接近人类的判断,这样的模型就可以帮人类完成大量繁琐的工作量。对模型的期望设置不是一个技术问题,而是一个业务问题,在开始一个机器学习项目之前,就需要先与业务的负责人展开相关的对话。

    如何定义“准确”

    仍然以最简单的分类问题为例,模型的判别分为阳性(positive)和阴性(negative)两种,两种判别都有正确和错误的可能,于是总共就有了四种可能的情况:

    • True Positive(TP):判别为阳性,实际也是阳性
    • False Positive(FP):判别为阳性,实际却是阴性
    • True Negative(TN):判别为阴性,实际也是阴性
    • False Negative(FN):判别为阴性,实际却是阳性

    一种朴素的“准确率”定义方法是“判别正确的比例”,即:

    但是当样本的分布极其不均衡时,这个对准确率的定义会很有误导性。例如我们假设10000人里有150人患胃癌(阳性),经过对血样的分析,一个模型识别出100名患者(TP),有50名患者没有发现(FN),同时误报了另外没有患病的150人(FP);另一个模型则不做任何判断,直接宣称所有人都没有胃癌。我们直觉会认为前一个模型优于后一个,但朴素的准确率定义却给了我们相反的结论:

    因为朴素的准确率定义有这样的问题,实践中更常用的指标是“精确率”(Precision)和“召回率”(Recall)。它们的定义分别是:

    • Precision = TP/(TP+FP):在预测的阳性个例中,有多少是预测正确的?
    • Recall = TP/(TP+FN):在所有的阳性个例中,总共找出了多少?

    可以看出,Precision和Recall往往是互相矛盾的:如果追求找出更多阳性个例(提高Recall),那么阴性个例被误判为阳性的情况也会增加(降低Precision),反之亦然。在不同的业务场景下,需要追求的指标也会不同。例如在前面的体检场景下,我们会追求更高的Recall:尽量找出所有患病的人,有一些人被误报也没关系。而另一个极端场景是推荐顾客可能会卖的商品,这时我们会追求更高的Precision:推荐位只有5个,我们必须保证推荐的每一件商品都打中用户的兴趣点,至于还有几千个他可能感兴趣的商品没有被推荐,那并不重要。

    以上我们看到的只是最简单的分类问题的场景。对于其他场景,可能需要引入其他度量准确率的指标。所以我们再次看到,采用什么指标来定义“准确”、应该如何权衡指标的取舍,这同样是一个与场景高度相关的业务问题。项目的管理者和业务代表需要清晰理解指标的含义、并合理设置对指标的期望。

    然后呢……

    如果项目的管理者和业务方代表能懂得机器学习是一类优化任务、能理解优化任务的度量方式、能针对这类任务设置合理的期望,在理解和把握项目进度与风险的路上他们就迈出了第一步。在下一篇文章里,我会拆解出机器学习类项目涉及的工作内容。读者将会看到,看起来高大上的机器学习、人工智能,实际上需要特殊技能和高中以上数学能力的只有极小一部分,其他都是普通的、确定性的软件开发工作,可以用典型的软件开发过程和管理方法来对待。针对份额极小、但有时非常重要的“自行训练模型”部分,我会给出更加细化的工作内容拆解,并提出任务拆分、进度管理、风险管理的相关办法。


  9. 数字化企业的数据自服务

    前文中我们说到,传统企业在逐步建设自己的数字平台过程中,需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱。今天我们讨论的主题是“数据自服务”,看看一个倡导消除摩擦、建设生态、推动创新的数字化平台如何处理数据。

    前情回顾

    什么是数据自服务

    数据在企业中的处理过程,能清晰地映射出康威定律对IT系统的影响。在各个部门分别建设IT系统、组织内部大量存在信息筒仓(silo)的年代,数据的操作由OLTP应用系统的开发团队同步开发,那时几乎每个政府信息化、企业信息化系统都会有一块“报表需求”。随后众多组织认识到筒仓系统导致信息在组织内不能拉通,不能产生对整体业务流程的洞察,于是开始建设以数据仓库为代表的OLAP系统。

    这些系统在支撑更高级、更复杂的数据分析的同时,也对应地在组织中造就了一支专业的“数据团队”。这些人使用非常专业的技术和工具对数据进行提取、转换、装载、建立数据立方、多维钻取、生成报表。这些专业的技术和工具,普通的软件开发人员并不掌握,因此对数据处理、分析和呈现的变更都必须归集到这个数据团队来完成。结果是,数据团队的backlog里累积了来自各个部门的需求,需求的响应能力下降,IT系统从上线到获得市场洞察的周期变长。

    微服务架构鼓励小型的、全功能的团队拥有一个完整的服务(及其对应的业务)。这样的全功能团队不光要开发和运维IT系统,还要能从数据中获得洞察——而且要快,不然就会跟不上市场变化,甚至使一些重要的业务场景无法得到支撑。因此他们不能坐等一支集中式的、缓慢的数据团队来响应他们的需求,他们需要数据自服务能力。

    要赋能数据自服务,企业的数字化平台要考虑“两个披萨团队”的下列诉求:

    • 需要定义数据流水线,使数据能够顺畅地流过收集、转换、存储、探索/预测、可视化等阶段,产生业务价值。
    • 需要用实时的架构和API在短时间内处理大量、非结构化的数据,从中获得洞见,并实时影响决策。
    • 为了提高应变能力,系统中的数据不做ETL预处理,而是以“生数据”的形式首先存入数据湖,等有了具体的问题要回答时,再去组织和筛选数据,从中找出答案。
    • 更进一步把数据包装成能供外人使用的数据产品,让第三方从数据中获得新的洞见与价值。
    • 为了支持数据产品的运营,需要实现细粒度授权,针对不同的用户身份,授权访问不同范围的数据。

    数据自服务解读

    下面是ThoughtWorks的数字平台战略第三个支柱“数据自服务”中所蕴涵的具体内容。

    数据流水线设计

    所谓流水线,是指用大数据创造价值的整个数据流。流水线从数据采集开始,随后是数据的清洗或过滤,再然后是将数据结构化到存储仓库中以便访问和查询,这之后就可以通过探索或预测的方式从数据中找到业务问题的答案,并可视化呈现出来。

    一条运转良好的数据流水线,能有效处理移动/物联网等新技术制造出的极其大量的数据,缩短数据从获取到产生洞见的反馈周期,并以开发者友好的方式完成数据各个环节的处理,赋能一体化团队。

    数据流水线的实现有两种可能的方式。一种方式是在各个环节采用各种特定的工具,例如前面介绍的数据流水线,各个环节都可以用开源的工具来实现。当然,选择这种方式也并非没有挑战:组织必须自己编写和维护“胶水代码”,把各种专用工具组合成一个内聚的整体。对组织的技术能力有较高的要求。

    除了基于开源软件实现自己的数据流水线,也可以考虑采用云上的数据流水线PaaS服务,例如DatabricksAWS Data PipelineAzure Data Factory等。这个方式的优点是对技术能力要求较低,缺点则是造成对特定云平台/PaaS提供商的依赖。

    实时架构和API

    实时的数据架构和API支持短时间内处理大量、非结构化的数据,从中获得洞见,并“实时”影响决策。正如Mike Barlow所说:“这是关于在正确时间做出更好决定并采取行动的能力,例如在顾客刷卡的时候识别信用卡欺诈,或者当顾客在排队结账的时候给个优惠,或者当用户在阅读某篇文章的时候推送某个广告。”

    Cloudera的一篇文章中介绍了实时数据处理的4个架构模式,整个流水线架构在Flume/Kafka基础上:

    • 数据流吸收:低延迟将事件持久化到HDFS、HBase、Solr等存储机制
    • 近实时(100毫秒以下)的事件处理:数据到达时立即采取警告、标记、转换、过滤等初步行动
    • 近实时的事件分片处理:与前一个模式类似,但是先对数据分片
    • 复杂而灵活的聚合或机器学习拓扑,使用Spark

    数据湖设计

    数据湖概念最初提出是在2014年Forbes的一篇文章中。它的概念是:不对数据做提前的“优化”处理,而是直接把生数据存储在容易获得的、便宜的存储环境中;等有了具体的问题要回答时,再去组织和筛选数据,从中找出答案。按照ThoughtWorks技术雷达的定义,数据湖中的数据应该是不可修改(immutable)的。

    数据湖试图解决数据仓库几方面的问题:

    • 预先的ETL处理终归会损失信息,如果事后才发现需要生数据中的某些信息、但是这些信息又没有通过ETL进入数据仓库,那么信息就无法寻回了。
    • ETL的编写相当麻烦。数据仓库的schema发生改变,ETL也要跟着改变;应用程序的schema发生改变,ETL也要跟着改变。因此数据仓库通常由一个单独的团队负责,于是形成一个function team,响应速度慢。
    • 数据仓库的分析需要专门的技能,大部分应用程序开发者不掌握,再度强化了数据仓库专门团队;而数据仓库团队其实离业务很远,并不能快速准确地响应业务对数据分析的需求。

    在数据湖概念背后是康威法则的体现:数据能力与业务需求对齐。它要解决的核心问题是专门的数据仓库团队成为响应力瓶颈。当IT能力与业务需求组合形成一体化团队以后,数据的产生方不再假设未来要解决什么问题,因此也不对数据做预处理,只是直接存储生数据;数据的使用方以通用编程语言(例如Java或Python)来操作数据,从而无需依赖专门的、集中式的数据团队。

    数据湖实施的第一步是把生数据存储在廉价的存储介质(可能是HDFS,也可能是S3,或者FTP等)。对于每份生数据,应该有一份元数据描述其来源、用途、和哪些数据相关等等。元数据允许整个组织查看和搜索,让每个一体化团队能够自助式寻找自己需要的数据。任何团队都可以在生数据的基础上开发自己的微服务,微服务处理之后的数据可以作为另一份生数据回到数据湖。维护数据湖的团队只做很少的基础设施工作,生数据的输入和使用都由与业务强关联的开发团队来进行。传统数据仓库的多维分析、报表等功能同样可以作为一个服务接入数据湖。

    在实施数据湖的时候,有一种常见的反模式:企业有了一个名义上的数据湖(例如一个非常大的HDFS),但是数据只进不出,成了“数据泥沼”(或数据墓地)。在这种情况下,尽管数据湖的存储做得很棒,但是组织并没有很好地消化这些数据(可能是因为数据科学家不具备分析生数据的技术能力,而是更习惯于传统的、基于数据仓库的分析方式),从而不能很好地兑现数据湖的价值。

    数据即产品

    数据产品是指将企业已经拥有或能够采集的数据资产,转变成能帮助用户解决具体问题的产品。Forbes列举了几类值得关注的数据产品

    • 用于benchmark的数据
    • 用于推荐系统的数据
    • 用于预测的数据

    数据产品是数据资产变现的快速途径。因为数据产品有几个优势:开发快,不需要开发出完整的模型,只要做好数据整理就可以对外提供;顾客面宽,一份数据可以产生多种用途;数据可以再度加工。数据产品给企业创造的收益既可以是直接的(用户想要访问数据或分析时收费)也可以是间接的(提升顾客忠诚度、节省成本、或增加渠道转化率)。

    在实现数据产品的时候,不仅要把数据打包,更重要的是提供数据之间的关联。数据产品的供应者需要提出洞见、指导用户做决策,而不仅仅是提供数据点。数据产品需要考虑用户的场景和体验,并在使用过程中不断演进。

    细粒度授权

    当数据以产品或服务的形式对外提供时,企业可能需要针对不同的用户身份,授权访问不同范围的数据,对应不同的服务水平和不同的安全级别。一些典型的细粒度授权的场景可能包括:企业内部和外部用户能够访问的数据范围不同;供应链上不同环节的合作伙伴能够访问的数据范围不同;付费与免费的用户能够访问的数据范围不同;不同会员级别能够访问的数据范围不同;等等。

    允许访问的数据范围属于数据产品/服务自身的业务规则。《微服务设计》的第9章建议,“[服务]网关可以提供相当有效的粗粒度的身份验证……不过,比允许(或禁止)的特定资源或端点更细粒度的访问控制,可以留给微服务本身来处理”。

    小结

    为了加速“构建-度量-学习”的精益创业循环,业务与IT共同组成的一体化团队不能依赖于集中式的数据团队来获得对业务的洞察。他们需要规划适宜自己的数据流水线,在必要时引入实时数据架构和API,用数据湖来支撑自服务的数据操作,从而更快、更准确地从数据中获得洞察,影响业务决策。更进一步,数据本身也可以作为产品对内部用户乃至外部用户提供服务,并通过细粒度授权体现服务的差异化和安全性需求。通过建设“数据自服务”这个支柱,企业将真正能够盘活数据资产,使其在创新的数字化业务中发挥更大的价值,这是企业数字化旅程的第三步。


  10. 2017年读过的好书

    今年读了66本书,不过有很大部分是工作需要。而且不知道什么原因,中间读的很多关于内亚性的书都只标了四星……

    仅存的内亚性

    科技与社会的交集

    早就想看的好故事

    • 恶棍列传 - 超级漂亮的小故事,最爱博尔赫斯的故事了
    • 傅科摆 - 太博大了…艾柯编造的神学阴谋论让达芬奇密码就像刺客信条一样直白
    • 麦田里的守望者 - 这才叫中二嘛……我是为素子姐来看塞林格的。
    • 月亮和六便士 - 所谓四十不惑的“不惑”,大概就该是这样的形式吧,知道自己要做什么而不惑于其他,多么令人羡慕。
    • 刀锋 - 求财的得财,求死的得死,求解脱的得解脱,真是一场欢喜大戏。
    • 荒原狼 - 最后终于和荒原狼和解了,这还真是一个美好的故事。

    比日系推理更好的国产推理

    • 暗黑者外传:惩罚 - 这个故事比欧门尼德系列还好,诡计设置很妙
    • 长夜难明 - 推理其实稍微有点弱,但是故事设置得好,抓人。
    • 真相推理师:幸存 - 这已经甩东野十条街了好吗!瞬间爱上这个作者!(虽然感情戏写得很挫…)
    • 红手指 - 谜题很棒,对人性的描写更是精彩,看完心里堵得慌。