晨间论文

  下载本文的PDF版本 PDF

晨间论文

我们思考数据的方式

人工检查黑盒ML模型;重新获得数据所有权

艾德里安·科利尔

我为本期acmqueue选择的两篇论文都以截然不同的方式挑战了我们思考和使用数据的方式。

在“停止为高风险决策解释黑盒机器学习模型,转而使用可解释模型”中,辛西娅·鲁丁提出了模型应该可以由人类专家检查和解释的理由。在许多情况下,理解模型正在做什么以及如何做出决策非常重要,以至于可解释性必须作为系统的关键设计目标加以考虑。普遍的看法是,放弃深度模型不可避免地意味着牺牲准确性。但鲁丁指出,情况并非一定如此。

如果当存在性能水平相同的可解释模型时,您从不部署黑盒模型会怎样?这种思路引出了后续问题,您如何知道可解释模型可以达到的最佳性能?如果您对这个主题感兴趣,您可以在晨间论文的评论中阅读更多关于CORELS(可证明最优规则列表;https://blog.acolyer.org/2019/10/30/corels/)和RiskSLIM(风险校准的超稀疏线性整数模型;https://blog.acolyer.org/2019/11/01/optimized-risk-scores/)的内容。

第二篇论文“本地优先软件:尽管有云,您仍然拥有自己的数据”描述了如何保留对数据的自主权。您能否将过去使用应用程序将开放文件格式写入本地文件系统所拥有的自由和所有权感,与来自云服务的跨设备访问和多人协作的便利性结合起来?克莱普曼等人认为可以,并提出了一个令人信服的呼吁,让我们开始构建本地优先应用程序。唯一的问题是,如何实现?

 

停止为高风险决策解释黑盒机器学习模型,转而使用可解释模型

鲁丁,C.,等,arXiv 2019; https://arxiv.org/abs/1811.10154

(感谢格林·诺明顿向我指出这篇论文。)

 

仅从标题就可以清楚地看出辛西娅·鲁丁希望我们做什么。她的论文融合了技术和哲学论证,并提出了两个主要观点:首先,加深了我对可解释性和可解释性之间差异的理解,以及为什么前者可能存在问题;其次,为创建真正可解释的模型提供了一些很好的技术指导。

 

在医疗保健和刑事司法领域,利用机器学习(ML)进行对人类生活产生深远影响的高风险预测应用呈上升趋势。预测模型缺乏透明度和问责制可能会(并且已经)造成严重后果

 

术语定义

模型可能成为黑盒,原因有两个:(1)模型计算的函数过于复杂,任何人都无法理解;或(2)模型实际上可能很简单,但其详细信息是专有的,不可用于检查。

可解释的 ML 中,您使用复杂的黑盒模型(例如,DNN(深度神经网络))进行预测,并使用第二个(事后)模型来解释第一个模型正在做什么。一个经典的例子是LIME算法,该算法探索复杂模型的局部区域以揭示决策边界。

可解释模型用于预测,并且可以由人类专家直接检查和解释。

 

可解释性是一个特定于领域的概念,因此不可能有通用的定义。然而,通常情况下,可解释的机器学习模型在模型形式上受到约束,使其对某人有用,或遵守领域的结构知识,例如单调性,或来自领域知识的物理约束。

 

解释并不能真正解释

已经有很多研究旨在为黑盒模型的输出生成解释。鲁丁认为这种方法从根本上存在缺陷。她的论点根源在于观察到,特别的解释实际上只是在“猜测”(我选择的词)黑盒模型正在做什么

 

解释必然是错误的。它们不可能与原始模型具有完美的保真度。如果解释完全忠实于原始模型计算的内容,那么解释将等同于原始模型,并且首先不需要原始模型,只需要解释即可。

 

甚至解释这个词本身也存在问题,因为您并没有真正描述原始模型实际所做的事情。COMPAS(惩教罪犯管理替代制裁分析)的例子生动地说明了这种区别。ProPublica 创建的 COMPAS 线性解释模型依赖于种族,并被用来指责 COMPAS(这是一个黑盒)依赖于种族。但我们不知道 COMPAS 是否将种族作为特征(尽管它可能具有相关的变量)。

 

让我们停止将对黑盒模型预测的近似值称为解释。对于不明确使用种族作为特征的模型,自动解释“该模型预测您将被逮捕,因为您是黑人”并不是对模型实际执行操作的模型,并且会使法官、律师或被告感到困惑。

 

在图像空间中,显著图显示了网络正在关注的位置,但即使如此,它们也没有说明它真正关注的是什么。许多不同类别的显著图可能非常相似。在下面的示例中,模型认为图像是哈士奇的原因的基于显著性的解释,以及它认为图像是长笛的原因的基于显著性的解释看起来非常相似

 

由于解释并不能真正解释,因此识别和排除黑盒模型的问题可能非常困难。

 

反对可解释模型的论点

鉴于黑盒模型和解释存在问题,为什么黑盒模型如此流行?很难反驳深度学习模型最近取得的巨大成功,但我们不应由此得出结论,认为更复杂的模型总是更好。

 

人们普遍认为更复杂的模型更准确,这意味着复杂的黑盒对于获得最佳预测性能是必要的。然而,这通常是不正确的,尤其是在数据结构化的情况下,使用自然有意义的特征进行良好表示时。

 

由于“复杂即好”的信念,如果您想要良好的性能,就必须牺牲可解释性,这也是一个普遍存在的误解

 

对准确性和可解释性之间总是存在权衡的信念导致许多研究人员放弃尝试生成可解释模型。研究人员现在接受深度学习方面的培训,而不是可解释机器学习方面的培训,这加剧了这个问题

 

Rashomon 集 表明,如果您尝试,您通常很可能能够找到可解释模型:鉴于数据允许存在大量相当准确的预测模型,它通常至少包含一个可解释的模型。

这提出了一种有趣的方法,即首先执行相对较快的任务,尝试一种不进行任何特征工程等的深度学习方法。如果这产生了合理的结果,您就知道数据允许存在相当准确的预测模型,并且您可以投入时间尝试找到可解释的模型

 

对于无混淆、完整和干净的数据,使用黑盒机器学习方法比排除故障并解决计算难题要容易得多。但是,对于高风险决策,分析师时间和计算时间的成本低于拥有有缺陷或过于复杂的模型的成本。

 

创建可解释模型

鲁丁的论文第 5 节讨论了在搜索可解释机器学习模型时经常出现的三种常见挑战:构建最优逻辑模型、构建最优(稀疏)评分系统以及定义可解释性在特定领域可能意味着什么。

 

逻辑模型

逻辑模型只是一堆 IF-THEN-ELSE 语句。长期以来,这些都是手工制作的。理想的逻辑模型应具有尽可能少的分支数,以达到给定的准确度水平。CORELS 是一种旨在查找此类最优逻辑模型的机器学习系统。这是一个示例输出模型,它在佛罗里达州布劳沃德县的数据上具有与黑盒 COMPAS 模型相似的准确度

请注意,图标题称其为机器学习模型。在我看来,这种术语似乎不太正确。它是一个机器学习模型,CORELS 是一个生成它的机器学习模型,但 IF-THEN-ELSE 语句本身不是机器学习模型。尽管如此,CORELS 看起来非常有趣,我们将在下一版《晨间论文》中对其进行更深入的研究。

 

评分系统

评分系统在医学中被广泛使用。我们对作为机器学习模型输出的最优评分系统感兴趣,但看起来它们可能是由人类产生的。例如

事实上,该模型是由 RiskSLIM 算法生成的(我们稍后也将对其进行更深入的研究)。

对于 CORELS 和 RiskSLIM 模型,要记住的关键是,尽管它们看起来简单且高度可解释,但它们给出的结果具有极具竞争力的准确性。让事物看起来如此简单并不容易。如果可以选择,我当然知道我更愿意部署和排除哪些模型的故障。

 

为特定领域设计可解释性

即使对于经典的机器学习领域,在这些领域中需要构建数据的潜在表示,也可能存在与黑盒模型一样准确的可解释模型。

 

关键是在模型设计本身中考虑可解释性。例如,如果专家要向您解释他们为什么以某种方式对图像进行分类,他们可能会指出图像中在其推理过程中很重要的不同部分(有点像显著性),并解释原因。将这个想法引入网络设计,Chen, Li 等人(“这看起来像那样:用于可解释图像识别的深度学习”;https://arxiv.org/abs/1806.10574)构建了一个模型,该模型在训练期间学习图像中充当类原型的部分,然后在测试期间查找与它已学习的原型相似的测试图像部分。

 

这些解释是模型的实际计算,而不是事后解释。该网络被称为“这看起来像那样”,因为它的推理过程会考虑图像的“这”部分是否看起来像“那”个原型。

 

 

解释、可解释性和政策

本文的第 4 节讨论了鼓励优先选择(甚至在高风险情况下要求)可解释模型的潜在政策变更。

 

让我们考虑一项可能的授权,即对于某些高风险决策,当存在性能水平相同的可解释模型时,不应部署任何黑盒

 

这听起来是一个值得称赞的目标,但正如措辞所说,要证明不存在可解释模型将非常困难。因此,或许公司将被要求能够提供证据,证明他们已尽到适当的勤勉义务搜索了可解释模型

 

考虑第二个提议,该提议比上面提供的提议弱,但可能具有类似的效果。让我们考虑一下,引入黑盒模型的组织将被强制报告可解释建模方法的准确性,这种可能性。

 

如果遵循此过程,那么如果作者的经验可以作为参考,您可能会看到在野外部署的黑盒机器学习模型会少得多

 

在高风险决策中可能需要完整的黑盒的应用领域是可能存在的。到目前为止,尽管我曾从事过医疗保健和刑事司法、能源可靠性和金融风险评估等众多应用,但我尚未遇到过这样的应用。

 

最后的话

如果这篇评论能够稍微改变对可解释 ML 中大多数工作的基本假设(即黑盒对于准确预测是必要的)的关注,我们将认为本文档取得了成功。如果我们不成功[让政策制定者意识到当前可解释机器学习的挑战],那么当不安全使用黑盒模型时,黑盒模型可能会继续被允许使用。

 

本地优先软件:尽管有云,您仍然拥有自己的数据

克莱普曼,M.,等,Onward! 2019; https://martin.kleppmann.com/papers/local-first.pdf

 

注意!如果您开始阅读本文,您可能会迷失在数小时内,跟踪所有有趣的链接和想法,并最终比您现在对当今软件的状态更不满意。您也可能会受到启发,为建设更美好的未来做出贡献。我全力以赴:)。

 

岩石还是硬地?

一方面,云应用程序可以轻松地从多个设备访问工作并与他人在线协作(例如,Google Docs、Trello)。另一方面,有您安装在操作系统上的老式本机应用程序(一个垂死的品种?例如,请参阅 Kubernetes 联合创始人 Brendan Burns 最近的推文;https://twitter.com/brendandburns/status/1194820433142374400?s=21)。介于两者之间,但不太完美的是具有离线支持的在线(基于浏览器)应用程序。

云应用程序(SaaS(软件即服务)模型)的主要问题是数据的所有权

 

不幸的是,云应用程序在这方面存在问题。尽管它们允许您在任何地方访问您的数据,但所有数据访问都必须通过服务器,并且您只能执行服务器允许您执行的操作。从某种意义上说,您并不完全拥有该数据的所有权,云提供商拥有所有权。

 

服务确实会被关闭,或者定价可能会对您不利地发生变化,或者功能可能会以您不喜欢的方式演变,并且无法继续使用旧版本。此链接“我们的不可思议的旅程”(https://reclaimthenet.org/wordpress-automattic-buys-tumblr/)方便地提供了一个很好的例子——它将首先带您到一个页面,宣布 Tumblr 已被 Automattic 收购,您可以在该页面上同意新的服务条款,如果您愿意的话。

使用传统的操作系统应用程序,您可以更好地控制数据(至少是文件系统上的文件,如果您幸运的话,这些文件甚至可能是开放格式)。但您还有其他问题,例如跨所有设备的轻松访问以及与他人协作的能力。(请注意,这不是新一代的操作系统应用程序,它们实际上只是在线服务上的包装浏览器。)

 

本地优先软件理念

作者创造了本地优先这个词组来描述保留老式应用程序的所有权属性以及云应用程序的共享和协作属性的软件。

 

在本地优先应用程序中,我们将本地设备(您的笔记本电脑、平板电脑或手机)上的数据副本视为主要副本。服务器仍然存在,但它们持有数据的辅助副本,以便帮助从多个设备进行访问。正如我们将看到的,这种视角的转变具有深远的意义

 

优秀的本地优先软件应具有七个关键属性

1. 它应该很快。 您不希望为了与应用程序交互而往返服务器。操作可以通过读取和写入本地文件系统来处理,数据同步在后台进行。

2. 它应该跨多个设备工作。 本地优先应用程序将其数据保存在每个设备上的本地存储中,但数据也会在用户工作的设备之间同步。

3. 它应该在没有网络的情况下工作。 这源于读取和写入本地文件系统,数据同步在连接可用时在后台进行。该连接可以是跨设备的点对点连接,不必通过互联网。

4. 它应该支持协作。 在本地优先应用程序中,我们的理想是支持与当今最佳云应用程序相当甚至更好的实时协作。实现此目标是实现本地优先软件的最大挑战之一,但我们相信这是可能的。”

5. 它应该支持所有时间的数据访问。 从某种程度上说,如果您保留原始应用程序的副本(以及能够执行它的环境),您就可以获得这一点。如果本地应用程序使用开放/持久的文件格式,那就更好了。例如,请参阅美国国会图书馆推荐的存档格式 (https://www.loc.gov/preservation/resources/rfs/TOC.html)。

6. 它应该默认是安全和私密的。 本地优先应用程序可以使用端到端加密,以便存储文件副本的任何服务器仅保存它们无法读取的加密数据。”

7. 它应该为用户提供对其数据的完全所有权和控制权。 我们所说的所有权是指用户对其数据的代理权、自主权和控制权。您应该能够以任何方式复制和修改数据,写下任何想法,并且任何公司都不应限制您被允许做什么。”

 

我们今天能达到多接近?

本文的第 3 节展示了各种不同的应用程序/技术如何与本地优先理念相符。

Git 和 GitHub 的组合最接近,但没有任何东西能够全面满足标准。

我们推测,由于平台的基本瘦客户端性质,Web 应用程序永远无法提供我们正在寻找的所有本地优先属性。通过选择构建 Web 应用程序,您正在选择数据属于您和您的公司,而不是您的用户的道路。

 

移动应用程序使用本地存储并结合后端服务(例如 Google Firebase 及其 Cloud Firestore)更接近本地优先理念,具体取决于应用程序如何处理本地数据。CouchDB 也获得了荣誉提名,只是在正确进行应用程序级冲突解决方面存在困难。

 

CRDT 能否解救?

我们发现了一些技术,这些技术似乎是本地优先理念的有希望的基础。最值得注意的是称为无冲突复制数据类型 (CRDT) 的分布式系统算法系列,它们的特殊之处在于它们从一开始就是多用户的。CRDT 与 Git 等版本控制系统有一些相似之处,只不过它们操作的数据类型比文本文件更丰富。

 

虽然 CRDT 的大多数工业用途都集中在以服务器为中心的计算中,但 Ink & Switch 研究实验室 一直在探索如何在 CRDT 之上构建协作式本地优先客户端应用程序。这项工作的成果之一是名为 Automerge 的开源 JavaScript CRDT 实现,它将 CRDT 风格的合并操作引入 JSON 文档。与 dat:// 网络堆栈 结合使用,结果是 Hypermerge

 

正如数据包交换是互联网和 Web 的支持技术,或者电容式触摸屏是智能手机的支持技术一样,我们认为 CRDT 可能是协作软件的基础,该软件为用户提供对其数据的完全所有权。

 

美好的新世界

作者使用此 CRDT 堆栈构建了三个(相当高级的)原型:一个名为 Trellis 的 Trello 克隆版、一个协作绘图程序和一个名为 PushPin 的混合媒体工作区(Evernote meets Pinterest)。

如果您有 2 分 10 秒的时间,非常值得观看一个简短的 视频,展示 Trellis 的实际操作 (https://www.youtube.com/watch?v=L9fdyDlhByM)。它真正将愿景变为现实。

作者分享了他们从构建这些系统中学到的东西

• CRDT 技术有效——Automerge 库做得很好并且易于使用。

• 离线工作带来的用户体验非常棒。

• CRDT 与反应式编程结合良好,可提供良好的开发者体验:“[这种组合] 的结果是,我们所有的原型都实现了实时协作和完全离线功能,而应用程序开发者几乎不需要付出任何努力。”

• 实际上,冲突不像担心的那样严重。它们在两个层面上得到缓解:(1)Automerge 以细粒度级别跟踪更改;(2)“用户对人类协作有一种直观的感觉,并避免与他们的协作者产生冲突。”

• 可视化文档历史记录很重要(请参阅 Trellis 视频)。

• URL 是共享的好机制。

• 云服务器仍然可以在发现、备份和突发计算方面发挥作用。

 

一些挑战

• 很难推理数据如何在对等方之间移动。

• CRDT 积累了大量的更改历史记录,这会产生性能问题。(这是基于状态的 CRDT 的问题,而不是基于操作的 CRDT)。

 

性能和内存/磁盘使用量很快成为一个问题,因为 CRDT 存储所有历史记录,包括逐字符的文本编辑。这些累积起来,但无法轻易截断,因为不可能知道有人可能会在离开六个月后重新连接到您的共享文档,并且需要从那时起合并更改。

 

感觉某种带有历史水印的日志压缩(例如,在 n 个月后,您可能不再能够合并旧的更改,并且必须对最新状态进行完全重新同步)可能对这里有所帮助。

• P2P 技术尚未准备好投入生产(但当它们工作时“感觉像魔法”)。

 

您今天可以做什么?

您可以通过遵循以下准则,逐步迈向本地优先的未来

• 使用激进的缓存来提高响应速度。

• 使用同步基础设施来实现多设备访问。

• 拥抱离线 Web 应用程序功能(渐进式 Web 应用程序)。

• 考虑将 操作转换 作为 CRDT 的更成熟的替代方案,用于协作编辑。

• 支持将数据导出为标准格式。

• 明确说明哪些数据存储在设备上,哪些数据传输到服务器。

• 使用户能够备份、复制和删除部分或全部文档(在您的应用程序之外)。

我将以第 4.3.4 节中的引文结束

 

如果您是一位对构建开发者基础设施感兴趣的企业家,以上所有内容都表明了一个有趣的市场机会:“用于 CRDT 的 Firebase”。

 

艾德里安·科利尔是伦敦 Accel 的风险合伙人,他的工作是帮助在欧洲和以色列寻找和建立伟大的科技公司。(如果您正在从事有趣的科技相关业务,他很乐意收到您的来信:您可以通过 [email protected] 联系他。) 在加入 Accel 之前,他在技术岗位工作了 20 多年,包括 Pivotal、VMware 和 SpringSource 的 CTO。

版权所有 © 2019,所有者/作者所有。出版权已许可给 。

经许可转载自 https://blog.acolyer.org

acmqueue

最初发表于 Queue 第 17 卷,第 6 期
数字图书馆 中评论本文





更多相关文章

伊桑·米勒、阿基里斯·贝内托普洛斯、乔治·内维尔-尼尔、潘卡吉·梅赫拉、丹尼尔·比特曼 - 远内存中的指针
有效利用新兴的远内存技术需要考虑在父进程上下文之外操作丰富连接的数据。正在开发中的操作系统技术通过公开内存对象和全局不变指针等抽象来提供帮助,这些抽象可以由设备和新实例化的计算遍历。这些想法将允许在具有分离内存节点的未来异构分布式系统上运行的应用程序利用近内存处理来实现更高的性能,并独立扩展其内存和计算资源以降低成本。


西姆森·加芬克尔、乔恩·斯图尔特 - 磨砺您的工具
本文介绍了我们在最初发布十年后更新高性能数字取证工具 BE (bulk_extractor) 的经验。在 2018 年至 2022 年间,我们将程序从 C++98 更新到 C++17。我们还进行了完整的代码重构并采用了单元测试框架。必须经常更新 DF 工具以跟上其使用方式的变化。对 bulk_extractor 工具更新的描述可以作为可以和应该做什么的示例。


帕特·赫兰 - 自主计算
自主计算是一种业务工作模式,使用协作来连接领地及其使者。这种基于纸质表格的模式已经使用了几个世纪。在这里,我们解释了领地、协作和使者。我们研究了使者如何在自主边界之外工作,并且在保持局外人身份的同时很方便。我们还研究了如何启动跨不同领地的工作,长时间运行并最终完成。


阿奇·L·科布斯 - 持久性编程
几年前,我的团队正在为一个商业 Java 开发项目工作,该项目用于增强型 911 (E911) 紧急呼叫中心。我们对尝试使用传统的 Java over SQL 数据库模型来满足该项目的数据存储要求感到沮丧。在对项目的特定要求(和非要求)进行一些反思之后,我们深吸一口气,决定从头开始创建我们自己的自定义持久层。





© 保留所有权利。

© . All rights reserved.