写点什么

Apple Photos 背后的技术与深度学习及隐私的未来

  • 2016-06-29
  • 本文字数:3739 字

    阅读完需:约 12 分钟

无处不在的 AI 辅助成果为我们未来的智能生活指明了两条实现方向——云端与设备内,这种戏剧般的分支选择亦如故事般精彩纷呈。在云阵营中,谷歌公司举起领袖旗帜。而在设备端,苹果则一呼百应。那么谁能够在对抗最终胜出?各擅胜场抑或是双双失利?

如果是在一个星期前,我个人绝对会将选票毫不犹豫地投给云阵营。在拜读了 Jeff Dean 撰写的《谷歌的大规模深度学习》一文后,相信大家会和我一样惊叹于谷歌实现的技术成果——精妙、普适、智能、系统化且极具优势。

而苹果公司则在将深度学习引入自家产品方面表现得较为迟钝。但这似乎也在意料之中,苹果方面有着自己的发展规划。其并不打算充当什么早期采纳者,而更倾向于推出已经被消费者市场所广泛接受的技术成果。

还有一种可能性,事实上苹果公司的行事作风相当隐秘,他们也许掌握着外界无从知晓的深度学习成果。当然,对于这一点我没法打包票。

但能够间接证明这种推论的证据在于,苹果公司即将以种全新方式拓展深度学习:差异化隐私 + 功能强大的设备处理器 + 可下载模型离线训练 + 承诺不收集任何个人信息 + 完美保密的深度学习机制。

Photos 对 Photos

在本次 WWDC 2016 大会的主题演讲中,苹果公司介绍了其全新照片应用,并宣称将利用深度学习技术帮助用户搜索图片、将照片整理成簿以及通过迷你快照形式收集照片、视频与位置。

这些功能听起来与 Google Photos 如出一辙。事实上,Google Photos 设计团队已经能够在无需为照片添加标签的前提下实现搜索。大家不必标记即可找到对应内容的图片。

二者的差异之处在于类似功能的不同实现方式。

苹果公司采用了怎样的实现方式?我们在 WWDC 2016 大会的脱口秀环节上找到了一些线索。

深度学习何时起效?

主持人 Gruber 帮我问出了最为关心的问题: 深度学习何时起效?

最终答案分为以下几点:

  • 深度学习运行在苹果的数据中心之内。
  • 其构建一套模型,且可供设备进行下载。
  • 训练过程并不涉及用户数据,而是依托于外部数据集实现模型构建。
  • 拍摄照片时该模型即得到应用。
  • 分析工作在照片进入照片库的同时瞬间完成。
  • 其通过 110 亿次计算对照片内容进行归类,分辨“其中是一匹马”或者“其中是一座山”。
  • iOS 设备上的 GPU 已经相当强大,因此能够迅速完成这些处理任务。很明显,由于拍摄操作在数量上并不夸张,所以也不会对电池续航造成太大影响。
  • 全部现有照片在后台进行分析由于这会占用相当一部分计算能力,所以相关分析工作会在夜间设备接入电源进行充电时进行。
  • 分析结果不会在同一用户的设备间共享。
  • 每台设备会分别进行上述分析流程。
  • 未来具体实现方式可能有所变化,即分析结果可能共享。由于开发一套面向这类数据共享机制的安全系统非常困难,因此等待也是可以理解的。

隐私是最大的差别所在

虽然苹果方面并没有谈及其具体训练方式,但很可能参考了谷歌在深度学习中的部分思路。

二者真正的差别在于对隐私的处理态度。谷歌方面会将全部个人数据保存在云端,并利用个人与他人数据加以训练。换言之,谷歌公司很清楚这些数据各来自哪位用户。事实上,我时常想到一种反乌托邦场景,即谷歌利用掌握的信息重建个人用户的大脑神经网络,并以模拟方式了解我们对于广告宣传及政治事件的态度——太可怕了。

苹果公司采用的是完全不同的另一种处理思路。苹果方面永远不会了解手机上的分析结论,也不会查看用户的个人数据。这一点已经在发布会上进行了无数次强调,也让人们对数据与隐私安全更加放心。

Craig Federighi:

是的。需要明确的是,对于这些照片本身,其架构集以加密方式存储在云端,而元数据——包括用户创建的元数据以及我们深度学习后分类得出的元数据——同样经过加密,苹果无法进行读取。

那么苹果要如何保证不会上传用户的数据并了解个人信息?其采用的是方案名为差异化隐私(简称 DP)。我之前从没听说过这项技术,因此对其倍感好奇。

Matthew Green 在《差异化隐私是什么?》一文中对 DP 进行了详尽说明,这是一项大数据技术成果,利用统计数据隐藏用户身份,从而在数学层面证明用户隐私得到保护。

那么其实际效果如何? Matthew Green 表示:

实际答案可能外人永远无法知晓。不过总体来讲,看起来苹果公司似乎确实诚实地践行了自己的隐私保护承诺,同时提供了可行的解决方案,这才是最重要的。

Craig Federighi 列举了以下 DP 示例(内容经过编辑):

基本思路是,如果大量用户输入某个实际上并不存在的单词,那么我们将不再将其视为拼写错误,甚至可能将其纳入拼写补全推荐。

在这种情况下,我们希望全部客户都能够理解该单词,但我们又不希望知晓具体是哪位用户输入了该词。没错,我们要刻意回避这种将习惯与个人挂钩的信息。

如果我们获取的只是数据片段中的一个侧面,那么我们拥有的最多也只是这部分片段。在所收集到的大量此类片段中,也许其表面的含义与实际情况并不相符,对吧?

但只要样本量充足,这种不相符的问题将自行得到解决。因此如果我们希望学习新出现的单词,我们会对其进行哈希处理,并从哈希中提取单一 bit,例如将其称为 1。与此同时,手机设备会对数据内容进行混淆,意味着即使其读取到的数据为 1,其也可能通过随机算法将其表达为 0。

苹果公司获得的数据正是这类混淆处理后的结果。但由于拥有充足的数据量,苹果方面仍然能够建立起宏观视角,并了解大规模群体表现出的真实倾向。具体来讲,苹果公司能够借此了解广泛用户的思维方式,但却无法具体将其与个人联系起来。

苹果公司正是利用这样的机制,凭借全球十亿台手机帮助自身建立认知优势。

Gruber 提出了 DP 实现保密的一大关键点。由于数据与货币不同,我们无法在一段时间后判断数据的具体来源,因此即使出现法律纠纷、苹果也无法将数据与个人联系起来。换言之,如果苹果公司的某些人员未来希望利用数据牟取利益,也根本不可能实现。

谷歌公司还开发出了众多模型,其中包含令人印象深刻的功能,且身材纤细可直接运行在智能手机之内。最典型的实例就是利用视觉取景器识别计算机中的文本。而后,其会进行文本翻译并直接把结果叠加在图片之上。谷歌公司很清楚,智能化技术必须能够在移动设备端全面完成,因此其不必远程接入云计算中心。TensorFlow 模型能够运行在手机上,这意味着云训练与远程设备相匹配,但就目前看谷歌不太可能为其采用差异化隐私保护。

苹果公司实现差异化隐私的同时又会失去什么?

看起来苹果公司似乎放弃了立足个人的深度学习分析,但这也只是种可能性。

以谷歌公司的 Smart Reply 为例。在手机之上,大家需要快速回复邮件,但输入内容往往不太方便。因此,谷歌开发出一套系统,用于预测使用频率较高的各类回复信息。

第一步是训练一套小型模型,用于预测某条信息是否适合作为快捷回复。如果将这种方式推而广之,甚至能够作为信息序列有针对性地实现预测型回复。

举例来说,在电子邮件当中,使用频率最高的感恩节邀请回复内容包括:我们也来;一定准时到;我们来不了,很抱歉。

这很像是苹果的设计风格。

下面再进一步,通过建立一套模型预测用户可能做出的反应。例如,我们可能会对邀请消息做出怎样的回复?也许苹果公司做不到如此具体的个性化效果,这是因为其不会在云中保留身份信息,而仅存在宏观的数据聚合视图。而在涉及个性化信息时,苹果公司的政策限制要求其只能在设备内部进行模型训练。

这就引发了数据匮乏问题。单纯访问设备上的数据能否准确代表用户的喜好?苹果公司只依靠 iMessage 或者 Siri 就能掌握我们的习惯吗?抑或是苹果公司会拦截指向 Twitter、电子邮件、Facebook 乃至谷歌搜索的流量?

再就是存在计算问题。根据 Jeff Dean 的说法,我的理解是整套神经网络是由成千上万的参数构成,而非单纯参考设备内运行的信息。

另外还有“多重人格”问题需要考虑。很明显,我们在使用电话、iPad 以及桌面系统时,交互习惯自然有所区别。如果立足于各独立设备,那么我们的习惯自然也存在巨大差异。这意味着苹果公司必须打造出某种元训练层,即将各类设备结合起来以构建起统一的用户视图。这种作法恐怕比将全部信息传输至云端更具挑战。

那么这种个性化能力的缺失是否致命?至于对谷歌而言是如此。谷歌公司最近在其谷歌 I/O 2016 大会上发布了全面普及机器学习的战略。其中的典型方案就是 Google Assistant,这款新的个人 AI 将更为全面地服务用户。

那么苹果是否关心这一点?谷歌公司似乎希望将深度学习本身作为主要目标,而苹果则更倾向于利用这项技术打造更出色的产品。虽然存在巨大差别,但只要有着苹果这位竞争对手的威胁,谷歌就必须提供更具吸引力的生态系统以发展技术成果。

每支团队都需要决定其是否需要构建及部署深度学习系统。这不仅是一项技术方案,更会带来道德层面的拷问。直到现在,我们只见证过一类深度学习系统实例,而苹果公司的思路显然提供了不同的实现模式。

遗憾的是,苹果公司制定的隐私模式很难普及,因为其向来对自家方案采取封闭政策。在另一方面,谷歌公司则忙于利用深度学习探索整个世界。一方强调隐私,一方强调分析结论,多元的发展方向对于我们用户而言显然是件好事。

原文链接: The Technology Behind Apple Photos And The Future Of Deep Learning And Privacy


感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-06-29 19:001886

评论

发布
暂无评论
发现更多内容

Bash 脚本的单元测试

柴锋

bash Linux DevOps Unit Test Shell

异常处理的那些事儿

松花皮蛋me

Java 设计模式

正则表达式位置匹配——匹配两个特殊符号中间的内容

jerry.mei

Java 正则表达式 大前端 字符串匹配

螺旋矩阵算法,臭代码解析,微服务架构 Service Mesh 服务网格 RPC 协议实现原理 Dubbo 通讯协议,John 易筋 ARTS 打卡 Week 13

John(易筋)

ARTS 打卡计划

华为的“少年天才”攀登者,出发向智能存储的“奥林帕斯山”

脑极体

目前数字人民币试点仍是“4+1” 别误读了

CECBC

数字货币 央行 人民币

全面了解CGI、FastCGI、PHP-FPM

书旅

CGI PHP-FPM Fast-CGI

这些年看过的Linux相关书籍推荐

我是程序员小贱

[python基础]2 python数据类型上篇

我是程序员小贱

SpringBoot系列(八):SpringBoot 中的事务处理

xcbeyond

Java 微服务 事务 springboot

Nginx之反向代理

xcbeyond

nginx 反向代理 代理

准时下班的秘密:集成 GitLab && JIRA 实现自动化工作流

Phoenix

团队协作 研发效能

JDK中居然也有反模式接口常量

看山

Java 源码阅读

结算场景下的跳坑记

李印

16张图入门Nginx——(前端够用,运维入门)

执鸢者

nginx 运维 大前端

ARTS 07 - 使用 supervisor 配置 ngrok 内网穿透为守护进程

jerry.mei

算法 练习 ARTS 打卡计划 ARTS活动 内网穿透

SICP,我的函数式编程启蒙书

Kurtis Moxley

读书 函数式编程

SpringBoot系列(七):SpringBoot 中使用Redis缓存

xcbeyond

Java redis 微服务 springboot

IT人为什么难以拿高薪?

看山

成长 随笔杂谈 薪资 心灵鸡汤

ARTS打卡 第12周

引花眠

微服务 ARTS 打卡计划

Java统一异常处理(配置文件集中化定义)

xcbeyond

Java 架构 后端 统一异常

如何选择:Bootstrap Or Layui

引花眠

bootstrap layui

[python基础]3 python数据类型下篇(不得不看的字典,列表大总结)

我是程序员小贱

蓝绿部署、金丝雀发布(灰度发布)、AB测试

看山

微服务 持续集成

ARTS Week12

时之虫

ARTS 打卡计划 arts

航运区块链 抗疫危中有机

CECBC

区块链 航运

这样看mybatis,谁都会分析源码!

诸葛小猿

源码 mybatis mybatis源码

python必备知识总结

我是程序员小贱

一次由默认参数引起的思考

白日梦想家

编程 思考

spark学习之IDEA配置spark并wordcount提交集群

我是程序员小贱

区块链技术--公证人机制

CECBC

区块链 数字货币 公证人

Apple Photos背后的技术与深度学习及隐私的未来_Apple_Todd Hoff_InfoQ精选文章