机器学习-关注机器学习和机器语言及数据算法研究_大数据分析第一门户
分类 CATEGORY
后使用快捷导航没有帐号？
　　　　文/辛东方　　科技发展的速度远远超过人类的想象力，“人工智能”一词从提出发展到现在已经过去六十个年头。在过去的岁月当中，世界各国科学家一直在缓慢着进行人工智能领域的研究，虽然收获甚微，但总体上
　　　　文/辛东方，80后作家、专栏作者、专注互联网科技领域　　“人工智能“”一词的提出发展到现在，已经走过六十多个春秋。期间，各国的人工智能技术都在缓慢的进行着，发展虽然缓慢，但毕竟都是一直前进的。　 ...
　　科技的发展，让人类社会智能化应用达到前所未有的高度。智能化应用的同时，但同时也带来一些焦虑和不安。假如人工智能失去控制，机器人将会给人类带来何种危害程度？这也是很多人最为关注的话题。　　　　文/辛
　　20多年前的美国，凯文·凯利站在一片燃烧的草原前想起一节福音：“新的到来，旧的逝去”，机器的进化仿佛失控的火苗，正在冲破人为划定的边界。他在《失控》一书中说：“生命正在变为人造的，一如人造的正在变得 ...
应萝卜网的邀请，我特地将《LoadRunner性能测试巧匠训练营》分成系列，发布在互联网分析沙龙上，供各位学习交流！话不多说进入学习吧！小白一直勤勤恳恳的奋斗在测试行业多年，但始终每天重复着黑盒功能测试，虽然自 ...
如今，Web应用程序的响应速度是成功的关键法宝之一。它与用户互动，用户对网站的看法，甚至谷歌网站排名情况都有着密不可分的关系。数据库性能是响应速度最重要的因素之一，一旦出错，所有程序都将会宕机。 工欲善其 ...
不知不觉，从事推荐系统相关工作已近两年，这两年自己踩坑，看人踩坑已然不少。记得一位资深从业者说“现在看起来，推荐系统就是个坑啊！”，心有戚戚的同时又不禁思索，到底坑在哪？ 第一坑：高估系统对用户需求的 ...
淘宝自从2010开始规模使用MySQL，替换了之前商品、交易、用户等原基于IOE方案的核心数据库，目前已部署数千台规模。同时和Oracle, Percona, Mariadb等上游厂商有良好合作，共向上游提交20多个Patch。目前淘宝核心系 ...
基于遗传策略的特征选取 遗传算法通常实现方式为一种计算机模拟。对于一个最优化问题，一定数量的候选解（称为个体）的抽象表示（称为染色体）的种群向更好的解进化。传统上，解用二进制表示（即0和1的串），但也可 ...
Han Hsiao 观点：简单说：数据挖掘就是从海量数据中找到隐藏的规则，数据分析一般要分析的目标比较明确，数据统计则是单纯的使用样本来推断总体。主要区别：“数据分析”的重点是观察数据，“数据挖掘”的重点是从数 ...
最近一直想入门数据分析的小伙伴问我，如果要入事数据分析一直来说要学那些语言呢？其实小编跟企业部门部门与侯选人接触下来，给我的感觉是对于这个初级的数据分析师来，一般前二年做差不多都是老大让你做的是处理临 ...
谈到Hermes的索引技术，相信很多同学都会想到Solr、ElasticSearch。Solr、ElasticSearch真可谓是大名鼎鼎，是两个顶级项目，最近有些同学经常问我，“开源世界有Solr、ElasticSearch为什么还要使用Hermes?”在回答这 ...
Apache Pig是在HDFS和MapReduce之上的数据流处理语言，它将数据流处理自动转换为一个DAG（有向无环图）的MapReduce作业流去执行，为数据分析人员提供了更简单的海量数据操作接口。但是在DAG的作业流中，作业之间存在 ...
做幻灯片不是PowerPoint一个软件的活，适当利用一些合适的工具，让你事半功倍。下面是9个我收集的跟幻灯片有关的资源，有的是网站，有的是软件，有的是书籍。相信能给你带来一些启发。1、 SlideShare
这个相当于PPT ...
“我到底在想什么？！？” 凌晨1:30分，我正盯着不到一个月前我写的一段代码。当时它看起来像是件艺术品，全部是可理解的，优雅、简单、让人叹为观止。这一切都不再了，明天是我的最后期限，数小时前我发现了一个bug ...
关注互联网沙龙分析
微信扫描二维码关注
互联网分析沙龙微信号
京ICP备号-2
提供计算与安全服务TalkingData大规模机器学习的应用
发表于 09:06|
来源程序员杂志|
作者张夏天
摘要：TalkingData目前提供应用统计分析、游戏运营分析、移动广告监测、移动数据DMP平台、移动行业数据分析等。随着各项业务快速发展，数据规模也越来越大，带来很大的挑战。本文将简要介绍我们应对这些挑战的一些经验。
TalkingData诞生于2011年，目前提供应用统计分析、游戏运营分析、移动广告监测、移动数据DMP平台、移动行业数据分析和洞察，以及企业级移动数据分析和挖掘的解决方案等产品和服务。随着各项业务快速发展，需要机器学习支撑的需求也越多越多，数据规模也越来越大，带来很大的挑战。而且TalkingData作为一个新兴企业，资源相对有限，没有办法通过大量增加硬件资源、增加计算能力来应对大数据问题，这给我们带来了更大的挑战。本文将简要介绍我们应对这些挑战的一些经验。计算平台TalkingData的数据处理集群目前仅有32台机器，除了承担机器学习任务外，更多的工作是数据处理，集群的负荷是非常繁重的。为了尽可能提高集群计算效率和程序开发效率，我们选择了Spark。我们认为Spark最大的两个优点。一是数据处理效率高（相对于Hadoop MapReduce而言）。二是开发效率高，Scala语言的特性和Spark的DAG机制使得复杂的数据处理流程和计算逻辑能够很简洁地编写，虽然Scala语言的特性也非常多，但是Spark对Scala语言的掌握程度要求不高，对一般程序员而言，一周时间足够掌握，而且程序开发效率相比Hadoop MapReduce能够提高一倍以上。 而且Spark社区的发展也很快(活跃开发者人数已经超过Hadoop MapReduce)，能够得到较好的社区支持和未来更多新功能。当然也有人质疑Spark在大规模集群上的稳定性，但对我们来说目前这还不是一个问题。算法分析大数据给机器学习带来了很大的机遇，也给机器学习带来了很多的挑战。大量的训练样本和丰富的特征维度，使得学习算法更容易学到较好的模型。数据更新速度很快，我们也可以更快地更新模型。同时，由于数据规模的增大使得机器学习算法的效率问题越来越突出。首先，从算法复杂度来说，有些算法的复杂度与训练样本数（如SVM）或者特征数量（如决策树）的关系是超线性关系。有一些模型学习中用到的优化方法，如牛顿法，需要计算训练特征维度规模的海塞矩阵的逆矩阵及其乘法，其计算复杂度为 O(n^3)）。随着数据量和特征数量的增长，模型训练的计算量急速增加，使得训练时间变得越来越长而不可接受。而硬件数量的扩充，带来的计算效率提升往往是低于线性的增长。因此，在进行大数据问题时，我们始终面临着计算资源相对不足的问题。为了解决计算复杂度的问题，也出现一些计算量较小的优化方法，如随机梯度下降（Stochastic Gradient Decent）、小批量梯度下降（mini-Batch Gradient Decent）等方法。但是，机器学习算法大部分都是迭代算法，需要反复使用数据多次，而在处理大规模问题的时候，训练数据集可能无法全部装载到内存中，而需要一次一次的从分布式文件系统中读取，带来巨大的重复I/O开销。即使Spark这样具有In-Memory计算能力的分布式计算框架，同样受制于集群资源和任务队列资源的限制，很多情况下并不能够把训练数据全部装载到内存中，还是需要多次从分布式文件系统中读取数据文件。数据迭代是机器学习算法处理大数据问题的“阿格硫斯之踵”。因此，尽可能降低算法迭代次数，是提高大规模机器学习任务的有效方法。在实践中，我们尽可能使用那些只需扫描数据一遍的算法。 如用SimHash来进行聚类， 用关联表算法来做推荐等。同时，我们也会优化算法实现，使其无需迭代即可训练出较好的模型，如随机决策树算法（Random Decision Tree）、线性回归(Linear Regression)和逻辑斯特回归（Logsitic Regression）等。另外，虽然我们以Spark为计算平台，但是并没有太多的使用Spark内嵌的MLLib来完成机器学习任务。最主要的原因也是因为MLLib中的算法基本都是迭代算法，其效率达不到我们的要求。实际应用TalkingData的业务比较多，需要机器学习提供支持的地方也比较多。目前大致可分为四个方面：移动应用推荐，广告投放优化，用户画像和游戏数据挖掘等四大块。这里分别简要介绍下这几个方面的工作。【移动应用推荐】TalkingData为几家移动应用市场提供过移动应用推荐解决方案如机锋和同步推，使用用户的下载和浏览行为数据，来进行移动应用的关联推荐和个性化推荐。但是这种外包模式显然无法充分利用我们的数据优势，也不是一种便捷的服务提供模式。前几年当推荐系统成为工业界和学术界都非常关心的技术时，国内外都出现了以提供推荐系统解决方案的公司。但目前这些公司都已经转型，比如, 目前已专注于提供金融客户数据管理和分析工具，而不再把推荐系统解决方案作为重点。实践已经证明第三方提供技术解决方案（包括提供SaaS服务）的模式并不具备很大的市场。我们通过这些外包项目，发现这种模式最大的问题在于数据的收集处理。如果我们要求客户按照我们提供的数据格式，为我们准备好数据，则会给客户带来很大的负担。由于客户对推荐系统了解不多，对于如何把已有的数据映射成我们的数据格式通常会感到比较困惑，而难以正确完成。而如果我们根据用户提供的现有数据进行转换，又使得我们的服务难以标准化而快速复制。另外就是一旦我们把推荐系统交付给客户后，我们也很难给客户提供持续及时的效果优化服务。因为上述这些问题，我们的推荐系统服务，就从提供外包转向了提供轻量级的移动应用推荐服务接口。这一服务也可以算是一种SaaS模式，但是与之前其他公司提供的推荐SaaS服务的重大区别是我们不需要客户提供推荐模型训练数据，客户仅需要调用我们的接口获得关联推荐和个性化推荐的结果。这就样也就没有转换客户数据的问题，从而极大地降低推荐系统服务的使用门槛。而通过SaaS服务，我们也可以持续优化和升级推荐算法的效果。我们能够提供这样的服务，主要是随着TalkingData积累的数据量越来越大，我们逐渐积累了大量的移动应用使用情况数据，这些数据比下载和浏览行为数据能更准确地反映用户的移动应用兴趣偏好，我们完全具备了不使用客户的数据而提供更好的推荐结果的能力。移动应用服务是作为TalkingData DMP里的一组接口向外提供服务的，我们将其作为TalkingData向外提供数据能力的一个出口。目前TalkingData推荐服务接口，每天要处理上亿的移动应用使用行为Session来建立推荐模型，覆盖30万以上的移动应用。现在，已经有一些移动应用换量平台使用我们的服务接口，也有一些移动应用市场准备尝试使用我们的推荐接口来为用户提供移动应用推荐。近些年来，推荐算法是数据挖掘，机器学习学术会议上非常热门的主题之一。可以说相关的文献是汗牛充栋，各种新算法和算法改进层出不穷。Netflix悬赏100万美元的推荐系统竞赛更是推动了推荐算法研究的热潮。然而众多的推荐算法，在实际应用中并不是那么好用。首先对于最基础的协同过滤算法，即通过计算用户或者物品之间相似性的方法，由于其计算复杂度与用户或者物品的数量是超线性的关系，而且需要计算矩阵乘法，难以并行化，用来处理大规模问题比较困难。而基于矩阵分解的方法，除了效率问题外，就是难以保证有较好的训练数据。因为这些算法的假设是基于每个用户和物品都有足够多的评分，但是实际上这是不可能的。另外，矩阵分解算法的目标是预测评分值与实际评分值最小化， 而实际应用中我们真正关心的是用户对不同物品感兴趣程度的排序。最小化评分误差，是否就能最小化排序误差？当然，也有一些矩阵分解算法被提出来用以最小化排序误差，但是其计算量的增长又是十分巨大的。因此，我们基于现实的数据情况（都是隐式反馈，设备规模较大， 和应用较多）， 采用了在工程上比较好实现，计算效率较高，结果也较好解释， 但是一点也不先进的算法，或者说算法框架—关联表。关联表算法原理比较简单，可以看做是对关联规则挖掘的一种简化。该算法通过统计物品两两之间同时出现的频次（如一个设备在一段时间内使用了哪些应用），构建出物品到物品的关联表。在进行关联推荐时，通过在关联表中查找目标物品的Top N关联物品进行推荐。而在进行个性化推荐时，使用用户最近有行为的那些物品分别查询关联表，然后再合并这些结果作为最后的推荐结果。下面是一个关联表构建和使用的例子：基于以上的关联表，做Top 2的关联推荐时, 如果目标物品是a2, 推荐的结果是a5和a3(排除a2)。如果要做Top 2个性化推荐，有d11: a1, a2, 用a1查关联表(a1, a2)得到a5(3), a3(2), a4(2)用a2查关联表得到a5(5), a3(4), a4(3). 合并以后得到a5(8), a3(6), a4(5), 取前两个为a5, a3。在此基础上，根据实际情况的需要，我们还需要对关联表的结果进行去流行，已避免推荐出来的全都是最流行的那些应用，在这里就不详述了。为了平衡长期兴趣和短期兴趣，我们采用不同时间内的数据建立关联表，比如一个月，一周和一天的数据分别建立关联表。也可以使用不同的数据源来建立关联表，比如使用应用的数据和安装应用的数据。然后再通过多个关联表的加权结果来获得最后的结果。实际上，除了用用户行为数据来统计应用之间的关联程度来建立关联表外，还可以使用其他的数据和方法来构建物品两两之间的关系。比如为了解决应用的冷启动问题，我们使用应用的介绍文本，采用文本处理的一些技术建立应用之间的关联关系。因此，我们推荐系统的核心就是一系列这样的关联表。在做推荐时，通过一定的规则根据输入参数查询各个关联表，然后融合也这些关联表的结合，作为最终的推荐结果。关联表方法，从算法的角度上看无疑是十分简单的，但是是非常适合工程化的。从我们的实践来看，在很多情况下，在精度上并不比先进算法有太大的差距。【广告投放优化】TalkingData积累了大量移动数据，完全具备进行广告精准投放的能力。但是作为第三方数据平台，我们严守中立，不会从事任何具体的广告投放业务，我们仅仅是为移动广告生态系统提供数据能力，提高整个生态系统的效率。我们的移动DMP可以提供移动设备的应用兴趣等标签，广告主、网盟、DSP都可以通过我们的DMP平台来获得受众数据来优化广告投放。但是也有一些合作伙伴，希望我们能够直接提供投放的目标设备或者媒体。为了提供较好的结果，我们使用超过1.5亿移动设备使用行为作为训练数据，特征空间超过180万维，以使用过投放目标应用的设备为正样本进行训练。为了能够对所有设备进行预测并输出所有应用与目标应用的关系，我们选择使用Logistic Regression算法进行训练。Logistic Regress也是处理大规模分类问题的常用算法，模型和训练过程相对简单，模型的可解释性也强。但是这个规模的问题，如果采用一般的算法实现，如MLLib的实现，在我们的集群上最少也需要几个小时的时间进行训练， 这会长时间占据集群资源影响其他任务的完成。 而且这个学习问题，除了数据规模比较大以外，还有一个挑战就是正样本数量通常较少。因为需要投放广告的应用，通常使用的用户不会太多。我们遇到的情况，正样本从几百到几百万都有，但即使是几百万的正样本，相对于1.5亿的训练样本，正样本比例也是极低的，不过千分之几。在这种情况下，一般很难训练得到较好的模型，我们使用过MLLib的LR算法进行训练，即使有几百万的正样本，模型的AUC指标也仅比0.5高一点，基本不具备区分正负样本的能力。这种情况下，一般可以对训练数据采样来增加正样本的比例来改善的学习结果。采样有两种方式，一种是增加正样本数量，另一种是减少负样本数量。前者会增加训练样本的数量而增加计算量。而后者又因为用户行为数据是稀疏数据且维度很高，如果丢弃大量的负样本，就会丢弃大量的特征，使得在预测时对只有这些特征的设备无法进行预测。因此我们不希望通过调整样本比例的方式来解决这个问题。为了解决训练效率和样本偏倚的问题，我们优化了Logistic Regression算法求解的过程，使得训练过程只需要扫描数据一遍即可达到收敛，而且在样本偏倚很严重的情况下也能达到较好的效果。在仅占用集群8%资源的情况下，Logistic Regression算法仅需5分钟即可完成具有180万维特征，1.5亿样本的训练。从测试情况来看，在正样本较多的情况下（几十万到几百万），AUC基本都在0.7以上，很多时候超过0.8，甚至0.9。而在正样本较少的情况下（几百到几千），一般也能达到0.6以上的AUC。 从实际广告投放情况来看，通常能提高50%以上的转化率。虽然Logistic Regression算法已经优化得很快了，但是在有多个优化任务的时候，还是可能会感到速度太慢。曾有过要跑500个任务的情况，一个任务跑5分钟，就需要2500分钟，接近42个小时。实际上500个任务，就需要扫描数据500次，这是最大的开销。实际上，对于这500个任务，使用的都是同一份数据。其格式如下：设备id, 应用1， 应用2， 应用3……只是每个任务会指定一个应用为学习目标，其余的应用则为特征。把原始数据根据指定应用加工成训练数据，这在Spark中是非常容易完成的。但是每个任务都这么干一次，就会多次的读取这个数据。显然，这是非常不经济的。要提高效率，就需要消除这些冗余IO操作，只进行一次数据读取。因为我们的算法是在每个数据分片上对数据逐条处理，因此对一条数据，进行多种不同的处理并没有难度，只是在最后的Reduce阶段，需要对不同分片上不同任务的模型结果进行整合，这在技术上不是什么难题。批量训练程序的效率是非常高的，对于500个任务，批量训练程序只需要50分钟就可以完成训练，训练时间缩短到原来的2%。平均一个任务（有1.5亿训练样本，180万的特征空间）的训练时间为6秒。批量训练程序的限制在于内存，任务越多，对应的模型越多，占用的内存就越大。目前的数据情况能够支撑大约1000个模型。【用户画像】TalkingData积累的数据以移动设备的行为数据为主，无法直接获得设备的兴趣标签。而DMP向外提供数据时，又必须以标签的形式向外提供数据，而且直接提供行为数据也对隐私保护不利。目前主要是利用移动应用的标签（由我们的专业团队人工标注）和设备使用应用的数据对设备进行标签标注。除了为每个设备画像，有时候我们需要对某个或者某类应用的使用者进行群体画像。我们曾通过直接统计用户群使用过的其他应用比例作为用户画像的基础，但是发现由于应用活跃程度的长尾效应，不管是什么人群，使用率最高的应用基本都是微信，QQ这些平台级应用，也就没有办法总结出这个人群的特征了。而如果将这个人群的各个应用的使用率除以所有设备上的应用使用率，得到应用使用率的提升率，又会突出那些使用率很低的应用。通过调整公式和参数，可以在提升率和使用率之间做一些妥协，但很难达到理想的状态。为了解决这个问题，我们将这个问题作为分类问题，使用Logistic Regression模型来处理，以获得模型中各个特征（即应用）的系数作为关联程度的分值，取得了非常好的效果。这个学习问题与广告投放优化中的问题是完全一样的，都是以某个或者某些应用的使用设备为正样本，其他设备为负样本，而以其他的应用作为特征，训练Logistic Regression模型，从而得到各个应用与目标人群的关联程度。从训练得到的结果来看，流行度高的应用都得到了抑制，而关联程度高的应用使用率也不会太低。得到了人群的关联应用后，可以再利用这些应用的标签为这个人群标注兴趣标签。用这个方法，我们为招商银行掌上生活，和一些广告的受众人群做了画像，都取得了比较好的效果。【游戏数据挖掘】TalkingData的游戏运营分析平台，是国内手游运营分析工具的开创者。目前为超过3万款游戏服务，其中包括消灭星星、植物大战僵尸这些非常受欢迎的游戏。游戏运营分析平台可以看作应用统计平台的游戏专业版，在数据收集上增加了游戏相关的一些标准事件如升级，虚拟币消费，付费等。因为TalkingData的游戏运营分析平台的定位，不仅仅是提供统计指标，还需要一定的预测能力，为游戏运营方预测哪些用户可能流失，哪些用户有可能付费。流失预测和付费预测，都是分类问题。因为我们需要考虑同时为3万多款游戏提供这样的预测，我们没办法逐个分析和抽取每款游戏收集的数据，特别是自定义事件来作为训练的特征。因此从规模化的角度考虑，我们立足于使用十几个标准化事件的数据作为特征。而对于自定义事件，我们也将其作为标准化事件来使用，仅使用自定义事件的总次数，和出现的不同的自定义事件的种数作为特征。我们认为一个玩家产生的自定义事件的次数和种类，与玩家对这个游戏的兴趣和投入程度应该是正相关的。这样，既能利用一些自定义事件的信息，但是又不需要对每个游戏的自定义事件做深入分析。当然，这个方案是预测精度向工程可行性的妥协方案，必然是要损失一定的精度。但是从我们的测试结果来看，预测精度还是可以接受的。这个工作与前面提到的广告投放优化问题，在规模上也有一些不同。对于每一个游戏而言，都不是一个大规模的机器学习问题，训练样本和最多也就百万规模，而特征数量仅有十几维。用我们优化过的Logistic Regression算法，这样的规模单机训练仅需要十几秒的事件即可完成计算。但另一方面，因为需要支持所有游戏，每次需要训练3万多个模型。这种情况下，运用Spark的并行能力来加速每个任务的训练速度没有什么意义，反而会因为多节点之间的同步问题，浪费掉不少计算能力。因此，我们在每个游戏的训练数据和预测数据处理好以后，把每一个游戏的数据Shuffle到一起，然后在Reduce过程中进行单机的Logistic Regression算法模型训练，然后进行预测。实际上，这里利用了Spark的并行能力来调度多个单机任务在集群上执行。总结：机器学习能力服务化前面介绍了我们在机器学习方面的一些工作。最后，总结一下我们的一点工作经验。TalkingData作为一个数据公司，很多业务都需要机器学习能力的支持，而我们的机器学习团队规模并不大，无法对每一个业务需求都做到及时响应。比如广告投放优化的工作，每次业务部门接到客户的需求，都需要来联系我们，让我们跑结果。这种方式让我们经常要干一些重复劳动，每次修改一下脚本，然后向Spark集群提交任务，跑出结果，再筛选设备和媒体出来。而客户的需求也得不到及时的响应。为了解决这个问题，我们就把这个机器学习的能力进行了服务化，提供了Web界面给我们的业务部门使用。他们收到客户需求后，就不需要再找我们了，而是直接使用Web工具，自动生成结果。这个工具几乎不涉及机器学习的专业知识，使用者仅需要指定投放的目标应用是哪一个就行。这样，我们免去了一些没有太多意义的重复性劳动，又让业务部门不再需要依赖我们来跑结果，提高了双方工作效率。移动应用推荐服务接口也是一个机器学习能力服务化的例子，我们把为客户部署推荐系统，改为了提供推荐服务，而且进一步利用了我们的数据能力，降低用户使用门槛。而我们也可以把精力集中在提供更高质量的标准化服务，而不是为客户的需求变化而疲于奔命。基于这些经验，我们认为一个机器学习团队，不仅要能提供好的机器学习能力（高效精准的算法），还需要把这些能力尽可能的服务化，为其他部门或者是客户提供简单易用的机器学习服务。机器学习团队的工作应该是不断解决新的问题，把这些问题的解决方案固化成服务给公司内外的用户来使用。当我们解决了一个问题时，就不要再让这个问题成为我们的日常性工作，而牵扯我们解决新问题的精力。作者简介：张夏天，TalkingData首席数据科学家，负责TalkingData机器学习和数据挖掘工作，为TalkingData的数据产品和服务提供支持。曾在IBM中国研究院、腾讯数据平台部和华为诺亚方舟实验室任职。对大数据环境下的机器学习、数据挖掘有深入的研究和实践经验。&<img src="http://ipad-cms.csdn.net/cms/attachment/b.png"
推荐阅读相关主题：
为了更好帮助企业深入了解国内外最新大数据技术，掌握更多行业大数据实践经验，进一步推进大数据技术创新、行业应用和人才培养，-12日，由中国计算机学会（CCF）主办，CCF大数据专家委员会承办，中国科学院计算技术研究所、北京中科天玑科技有限公司及CSDN共同协办的2015中国大数据技术大会（Big Data Technology Conference 2015，BDTC 2015）将在北京新云南皇冠假日酒店隆重举办。
相关热门文章主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
傻丫头和高科技产物小心翼翼的初恋
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：。个人QQ群：、
CSDN &《程序员》编辑/记者，我的邮箱
一只文艺范的软件攻城狮，Keep Learn，Always.
个人大数据技术博客：
原文链接：
译者：赵屹华
审校：刘翔宇
责编：周建丁（投稿请联系）
在本文中，我们将介绍一种方法，用来解释中的任何一种分类器的预测结果，并且用来实现。动机：我们为什么要理解预测结果？机器学习如今是非常火的一个话题。随着计算机在围棋等游戏中击败人类专家，许多人不禁要问机器是否也能胜任司机的工作，甚至是取代医生？现在很多前沿的机器学习模型还是一个黑盒，几乎无法去感知它的内部工作状态。这就给我们带来了可信度的问题：我该相信那个模型的某个预测结果是正确的吗？或者说我该相信那个模型的预测结果普遍都是合理的吗？围棋游戏的赌注还是小事，如果让计算机取代医生可算一件大事了，或者让计算机判断我是不是恐怖分子嫌疑人（《疑犯追踪》）。更通俗的来说，如果一家公司正准备替换上一套基于机器学习的系统，它就要确保机器学习模型的工作状态是良好的。从直观上看，解释每次独立预测背后的基本原理能使我们更容易信任或是不信任预测结果，乃至分类器本身。即使我们无法理解模型在所有情况下的表现，却有可能理解（大多数情况都是如此）它在某些特定情况下的行为。最后，说一下准确性。如果你有机器学习的经验，我敢说你正在想的是：“我当然知道模型在真实情况下能取得不错的效果，因为在交叉验证中已经得到了很高的准确率！当99%的情况下模型都能准确预测时，我为啥还要去理解它的预测结果呢？”任何一位在现实问题中（不是在静态的数据集上）使用过机器学习方法的人都能证明，交叉验证的准确率很具有误导性。有时候预测数据会不小心混入训练数据中。有时候你收集数据的方法会引入现实中不存在的相关性，而模型却能捕捉到。其它许多棘手的问题都会影响我们评判模型性能，即使是使用。我不是不让你测试准确率，而是准确率不应该是你的唯一标准。Lime：一些例子你真的相信你的新闻数据集的分类器吗？首先，我们给一个文本分类的例子。著名的新闻数据集（ 20 newsgroups dataset）是一个标尺，在多篇文章中被用来比较不同的模型。我们选取两个难以区分的类别，选取标准是它们有着许多重合的词语：基督教（Christianity）和无神论（Atheism）。训练一个有着500棵树的随机森林，我们在测试集上得到92.4%的准确率，高的惊人了。如果准确率是唯一的衡量标准，我们肯定会相信这个算法。下图是测试集中任意一个案例的解释，由生成。这是分类器预测结果正确但是原因错误的一个例子。仔细观察就会发现单词“Posting”（邮件抬头的一部分）在21.6%的训练数据中出现过，仅有两次是属于“基督教”类别。在测试集里也是一样，它在20%的样本中出现过，也仅有两次属于“基督教”类别。数据集的这种分布状态使得问题比现实状况简单得多，分类器是无法区分基督教和无神论两个类别的。这一点准确率或者原始数据上是很难观察到的，但是如果有预测的解释则很容易发现。一旦你明白了模型真正的工作原理，此类洞察能力就显得很平常了，模型的泛化能力也更强了。进一步看看其解释能力如何：这是一个非常稀疏的线性模型（只有6维特征）。尽管底层的分类器是复杂的随机森林，在这个例子里它几乎就是个线性模型。基本可以确定，如果我们从例子中删除“Host”和“NNTP”两个单词，预测为“atheism”的概率值将会是0.57-0.14-0.12=0.31。由深度神经网络解释预测结果下图来自我们的论文，我们在一些任意的图像上解释Google的 Inception neural network。在本例中，我们解释图像中类别最确定的那部分。这里，图像中的是木吉他，分类器却预测为电吉他。解释部分阐述了为何两者被混淆了：它们的指板很相似。lime包目前暂时还无法实现图像分类器的解释，我们正在开发中。
参考阅读：
Lime：我们是如何进行解释Lime是Local Interpretable Model-Agnostic Explanations的缩写。名字的每一部分反映了我们进行解释的意图。Local指的是局部保真——也就是说我们希望解释能够真实地反映分类器在被预测样本上的行为。这个解释要求是可以理解的(interpretable)——即能够被人类读懂。Lime能够解释任何模型，而不需要进行模型适配，所以是与模型无关的(model-agnostic)。现在我们来俯瞰一下lime的工作原理。若想了解更多细节，请查阅我们论文的 。首先来说一说可解释性。有些分类器使用的用户完全无法理解的表征方式（如词向量）。Lime用可以被理解的表征方式（比如用单词）来解释这些分类器，即使它不是分类器真正在使用的方式。另外，lime考虑了人类的局限性：解释内容不会过长。目前，我们的工具包支持稀疏线性模型的解释，我们正在开发支持其它表征方式。为了做到与模型无关，lime不会深入模型内部。为了搞清楚哪一部分输入对预测结果产生贡献，我们将输入值在其周围做微小的扰动，观察模型的预测行为。然后我们根据这些扰动的数据点距离原始数据的距离分配权重，基于它们学习得到一个可解释的模型和预测结果。举个例子，如果我们要解释“我讨厌这部电影”这句话的预测结果，我们将打乱这个句子，对“我讨厌电影”、“我这部电影”、“我电影”、“我讨厌”等句子进行预测。即使起初的分类器使用了更多的词语，但是我们可以合理的预期例子中只有“讨厌”这个词相关。注意，如果分类器用到了一些不可解释的表达方式，比如词向量，此方法依旧可行：我们只需用词向量来打乱句子，不过最后的解释还是会落到诸如“讨厌”或“电影”的词。这个过程的演示图如下。原始模型的决策函数用蓝/粉背景表示，显然是非线性的。亮红色的叉叉表示被解释的样本（称为X）。我们在X周围采样，按照它们到X的距离赋予权重（这里权重的意思是尺寸）。我们用原始模型预测这些扰动过的样本，然后学习一个线性模型（虚线）在X附近很好地近似模型。注意，这个解释只在X附近成立，对全局无效。结论我希望已经能让你明白了理解预测器单独的预测结果的重要性。有了解释，你能有更多的信息来决策是否信任预测结果，或是整个模型，以及提供思路来改进模型效果。代码和论文的链接如果你对深入理解lime的工作原理和曾经做过的验证性实验感兴趣，请查看论文的。如果你想对文本分类器使用lime，请下载我们的。安装命令如下：pip install lime工具包的使用很简单。它特别容易解释scikit-learn的分类器。在github页面我们还放了一些教程，比如，来自scikit-learn的例子。
日-23日，由CSDN重磅打造的将在深圳举行，目前18位讲师和议题已全部确认。两场峰会大牛讲师来自百度、腾讯、阿里、京东、小米、唯品会、滴滴出行、携程等知名互联网公司，共同探讨高可用/高并发/高稳定/高流量的系统架构设计、秒杀系统架构、搜索架构、中小企业架构之道、数据平台系统演进历程和技术剖析、传统数据库与分布式数据库选型/备份/恢复原理及优化实践、大数据应用实战等领域的热点话题与技术。【目前限时6折，】