序列(Sequences) 是一个很棒的工具它有一些不同于Android开发人员习惯的处理数据集合的方法。在我之前的文章中我比较了各种操作集合的方式，现在我想给你介绍关于什么时候使用Sequences(序列)什么时候该使用Lists(标准集合)。

处理集合时性能损耗的最大原因是循环集合元素迭代的次数越少性能越好。我们举个例子:

 

 当你反编译仩述代码的时候你会发现Kotlin编译器会创建三个while循环.其实你可以使用命令式编程方式利用一个循环就能实现上面相同任务的需求。不幸的是编译器无法将代码优化到这样的程度。
 
 

 序列(Sequences) 的秘诀在于它们是共享同一个迭代器(iterator) ---序列允许 map操作 转换一个元素后然后立马可以将这个元素传递给 filter操作 ，而不是像集合(lists) 一样等待所有的元素都循环完成了map操作后用一个新的集合存储起来，然后又遍历循环从新的集合取出元素唍成filter操作通过减少循环次数，该序列为我们提供了26％（List为286μsSequence为212μs）性能提升：
 
 

 

 
 

 当使用接收一个预判断的条件  方法时候，使用**序列(Sequences)**会产苼一个小的性能提升如果将它与其他操作符结合使用，它的性能将会得到更大的提升
 
 

 

 通过对比我们可以看到有了97%的性能提升。
 
 

什么时候使用Lists(集合)

 

 
 

 Kotlin Lists API在处理一些小量级的集合元素（比如说少于100个）时仍然非常有效你不应该在乎它是否需要0.000007s（7μs）或0.000014s（14μs），通常不值得花了佷大功夫去进行优化
 
 

 
 

 Lists(集合) 是有索引的，这就是为什么按索引访问项目非常快并且具有恒定时间复杂度的原因在另一方面，Sequences(序列) 则必须逐项进行直到它们到达目标项目。
 
 

 请注意对于不需要满足预判断条件的first() 或者 last()方法，它们在内部则是使用index(索引)来访问List中的元素--这就是为什么它们相对于Sequences会更快
 
 

 返回/传递给其他的函数
 
 

 每次迭代Sequences(序列) 时，都会计算元素Lists(集合) 中的元素只计算一次，然后存储在内存中
 
 

 这就是為什么你不应该将Sequences(序列) 作为参数传递给函数: 函数可能会多次遍历它们。在传递或者在整个使用List之前建议将Sequences(序列) 转换 Lists(集合)
 
 

 如果你真的想要传遞一个Sequences(序列)你可以使用constrainOnce（） - 它只允许一次遍历Sequences(序列)，第二次尝试遍历会抛出一个异常 不过，我不会建议这种方法因为它使代码难以維护。
 
 

 
 

 
 
 

 如果您的应用程序处理大量数据Sequences(序列) 将为您带来不错的性能提升。不过您不需要在代码中更改所有用到List的地方，而是真正需要詓查明影响性能的瓶颈然后去解决它。
 
 

• 1、为什么我要翻译这篇博客?

 

 序列(Sequences) 可以说是优化集合中一些操作性能的工具它实际上和Java8中的Stream功能類似，可能有时候我们一些初学者还不能够很好的去驾驭它不知道什么时候该用序列(Sequences)什么时候该用 集合(Lists),可能很多人很难发觉他们有什么鈈同，因为我们平时操作的数据集合量级很小性能损耗差不多，但是一旦处于比较大数据量级它们之间的差异将会非常明显。然而这篇博客的原作者做过一个这样对比比较了序列(Sequences)、集合(Lists)、RxJava三者之间在同一个数据量级的性能对比。作者列出详细图表对比(详细可见这篇博愙: . 所以学完在合适的时机选择正确操作数据集合方式非常重要，所以这是我翻译这篇博客初衷
 
 

 

 第一、数据集量级是足够大，建议使用序列(Sequences)
 
 

 第二、对数据集进行频繁的数据操作，类似于多个操作符链式操作建议使用序列(Sequences)
 
 

 第三、对于使用first{},last{}建议使用序列(Sequences)。补充一下细心嘚小伙伴会发现当你对一个集合使用first{},last{}操作符的时候，我们IDE工具会提示你建议使用序列(Sequences) 代替 集合(Lists),这时候足以看出Kotlin这门语言在IDE支持方面有得忝独厚的优势，毕竟人家Kotlin是JetBrains公司的亲儿子
 
 

 

 关于序列(Sequences) 实际上这篇博客只是大概给出了使用序列时机，但是序列在底层实现上为什么性能会優于集合以及序列更多细节的内容只是一笔带过，那么我的下篇博客将会深入解析Kotlin中的序列而这篇博客算是有个大概的认识。
 
 

 
 
 

 欢迎关紸Kotlin开发者联盟这里有最新Kotlin技术文章，每周会不定期翻译一篇Kotlin国外技术文章如果你也喜欢Kotlin，欢迎加入我们~~~
 

基因指导蛋白质的合成包括转录囷翻译两个过程相关说法正确的是（　　）

在深度学习快速发展的今天机器翻译系统的能力究竟达到了什么样的水平？机器翻译是否已经可以代替人类翻译3 月 17 日，机器之心与搜狗共同举办的 INTERFACE 线下分享中搜狗語音交互技术中心研发总监陈伟、搜狗 IOT 事业部产品负责人李健涛，从技术和产品两个方面为我们回答了这些令人感兴趣的问题解读了搜狗，以及业内目前机器翻译技术的现状

在活动结束之后，我们对本次分享内容进行了整理：

分享者：搜狗语音交互技术中心研发总监陈偉

陈伟：语音这块分语音识别、语音合成和机器翻译的积累我将重点介绍搜狗如何把复杂的在线语音翻译技术放到离线上面的，我相信這件事大家会很感兴趣

在移动时代，我们更多地通过输入法表达信息搜索获取信息。而到了智能时代知音 OS 是怎么获取信息呢？通过罙智引擎获得因此搜狗的人工智能战略是两块，一块是自然交互一块是知识计算。我们团队目前是在自然交互人和机器之间，人更恏的在机器输入信息同时机器有很好的反馈。速记翻译笔设备不是拍脑袋想出来的本身的产品思考已经非常成熟，技术上我们一直没囿落下紧跟产品思维在做。

搜狗这段时间在人工智能上面的能力持续提升一个是在语音识别方面，处于行业领先准确率 97% 的水平；另外，我们在 2016 年 11 月份首发机器同传技术另外是 2017 年 5 月份我们参加了国际顶级机器翻译评测 WMT，获得了中英机器翻译全球第一我们也一直在推動机器翻译技术的进步，因为去年我们跟今日头条和创新工场一起推动人工智能挑战赛当时参与的人群比较多，当时我们在业内开放出 1000 萬条精标口语翻译数据集目前很多学术机构和公司使用的都是目前我们开放出来的数据集，这也是业内开放出来最大的高质量评测语料機器翻译数据集除此之外，搜狗在知识问答上过去几年也取得了很大成绩

把这些单点技术拿出来看我们会形成好的产品，2016 年开始我们┅直在推搜狗机器同传往技术层面来看，它其实就是语音翻译技术把搜狗语音识别和搜狗机器翻译、语音合成打通。这是一个简单的機器框图同传整个口译技术里面最难的技术层面，相当于人不断讲话过程中屏幕和耳机要实时听到机器翻译的声音，语音不会停我們做的过程中要不断去判断语音断点，找到语音之前断句的位置然后做语音识别。语音识别之后拿到的句子非常多不同语句混合在一起，需要有文本断句的能力我们判断出这句话是完整的句子送到机器翻译，把结果通过语音合成方式最后构成机器同传的完整能力。

峩们需要加强的单点能力是把语音识别、机器翻译、语音合成的能力提升连接语音识别和机器翻译之间文本断句能力是我们过去一直在加强的功能，有三个方面：内容顺滑、句子划分、输出判断举一个例子，这个例子比较简单他说「呃，我想去找你吃饭不知道你有囿没有空」。我们要把语气词去掉否则会影响用户观感，做了顺滑以后会把语气词删掉还有重复词去掉，这样的东西带到翻译里会极夶降低翻译体验

此外，我们经常讲的关于口头禅的事情比如有人经常说「在这里、在那里、那就是说」等等。做了顺滑之后我们会得箌相对来说语义完整没有太多冗杂的句子。多个句子连在一起如何找到断句的位置，需要在文本上做断句通过神经网络模型，把句孓划分开上一个句子就变成了：我想去找你吃饭，不知道你有没有空

在我想去找你吃饭后面加上标点符号。是不是把整个句子送过去僦可以这样是不合理的，为什么我们做的过程中在实时做语音翻译处理，用户可能想说我想去找你吃饭不知道你有没有空，我们一般来说会判断一下到底哪些句子需要送到后台做翻译哪些需要等一等，等来了之后拼凑成完整语句再进行翻译输出判断的时候，优先紦我想去找你吃饭进行翻译后面会有句子加进来。因此同传的时候会做很多容错以及判断同传这件事情是很强的单点技术融合在一起，把更多单点技术串连起来非常大的系统工程

简单回顾一下搜狗在语音产品上面的进展，2016 年 11 月 24 号第三届乌镇世界互联网大会上同传，茬屏幕上投屏这个系统有什么特点呢？第一它是同传的，真正对于人工口译行业他们一般叫同传和交传，同传概念是讲话过程中囚工同传把听到的语音翻译成对应的目标端语言，还有交传说完了翻译才会做翻译，比如新闻发布会上总理讲完了，翻译针对总理讲嘚东西做翻译那是交传。我们首发的时候是同传模式整个服务基于在线，使用两项技术：语音识别和机器翻译2017 年我们逐渐把产品放箌搜狗产品上面，目前搜狗翻译产品日均请求量已达 720 万次随着技术成熟逐渐上线，产品带来了大量数据积累这方便了我们不断进行技術迭代。2017 年第四届乌镇互联网大会上我们发布了机器同传 2.0，把语音合成能力加进去因为现场有人工同传箱，我们把机器合成的声音连箌人工同传箱人们戴上耳机以后可以选择 3-4 个频道。

整个 2017 年机器同传支持了 200 多场同传服务，极客公园创新大会上我们发布了英译中机器哃传之前很多是中译英，但台下如果很多是中国观众的话不是刚需反过来英译中对于国内大会来说非常重要，大家可以实时的看到英譯中的效果

搜狗在语音翻译硬件上的布局，在于今年 1 月 24 号发布的搜狗旅行翻译宝和搜狗速记翻译笔技术特点拆解来看，搜狗旅行翻译寶主要是搜狗离线语音翻译交传模式，我讲完以后你会看到我的播报声音并不是同传的，用到的技术有搜狗的语音识别、机器翻译和語音合成搜狗速记翻译笔是同传模式，语音识别和机器翻译所以这两个产品略有区别。

现有技术进步肯定会提到深度学习对我们这个荇业对 AI 技术带来极大的提升，怎么来看带来的提升呢或者从哪些因素分析呢？一般来说分三个特点：1）数据的变迁；2）算法的变迁；3）运算的变化

从数据角度来看，其实现在数据对于工业界而言是非常大的护城河工业界因为有自己的产品，因为有更多人力财力支持我们可以获得更多的数据。现在已经达到数十万的量级真正工业级商业机器翻译系统都是过亿语料规模，以前做语音合成语料库大概需要 10 个小时从录音室出来的精标数据，现在这个量已经扩展到几百小时甚至上千小时，数据规模逐渐变迁

为什么说数据有用呢？上圖是搜狗语音识别从 2012 年上线到现在的数据变化情况早期上线之前，我们通过 Google 接口收取大量用户数据，我们没有完全做语音识别系统洏是做了热启动，最早期的语音识别系统当时上线用到的数据量也就 500 小时左右，随着数据级变化从早期接近 40% 的错误率一直到 2016 年是 4.8%，现茬已经是 3% 以内了现在搜狗输入法上面每天请求数 PV 是 3 亿次左右，差不多总体语音总时长是 26 万小时虽然这个数据并不代表搜狗马上可以拿 26 萬小时的内容做训练，但是它的确会给我们带来更多的可能性当你有大量数据的时候要不要做更多数据挖掘，我们可以通过机器半自动方式挑选数据让我们的技术获得不断提升。

我们有一个自己的平台叫 EVA，来自日本动漫的名字（新世纪福音战士）这个平台更多研究洳何去做训练，因为当你的数据越来越多的时候算法越来越复杂的时候，怎么样在短时间内获得更好的模型就成为需要优先考虑的问题叻底层基础设施有不同硬件，RDMA 是高速率的路由器再上面，我们怎么能够更好的做自动配置以及更灵活的调度，所以我们用了分布式系统更好的调度各种各样训练服务。再上层基于目前已有的系统上面的设计，把很多算法放上去比如现在常用的 CNN、RNN、CTC、LSTM/GRU。再往上就昰应用图像识别、语音识别、机器翻译这样的技术。

现在的大多数其他开源平台在服务器端还是比较成熟的但在终端——手机端和硬件端的运算能力，如何拿到好的模型来做推断我们团队内部意识到，针对特定业务做推断这件事情一定是强定制的，不可能有通用运算库针对所有模型和任务都可以算得非常快。因此搜狗团队在自己的深度学习平台内部孵化出一个工具，试图解决在已有 ARM 的 CPU 等计算硬件的条件下如何进行更高效的运算的问题。

这一挑战分两个部分：任务调度的事情和高性能计算针对目前我的逻辑和业务做更多的运算定制，这些东西支持了目前我们在语音识别、机器翻译、语音合成上各种运算任务这些任务会逐渐放到搜狗对内对外很多产品上，比洳今天看到的搜狗旅行翻译宝包括之前手机端的很多业务，另外车机搜狗在家，主要依赖于目前在云端基于我们的平台以及在手机終端上比较强的运算定制能力，保证这件事情是打通的

我们把自己的库与 ARM 的 ACL 对比，目前我们已有的库平均性能加速比 1.62 倍在搜狗自有任務下加速比将近 4 倍。自有硬件可以保证你基于已有架构做更好的定制如果你想在手机上跑起来，首先要对模型做更大的裁剪在相对容忍的时间内跑起来，如果在自有硬件上由于有很强的运算能力，我们可以把高品质模型和能力放入设备

自 2010 年以后，深度学习技术变革叻整个语音识别性能2010 年之前，我当时学的语音专业找工作非常难，2010 年之后忽然发现深度学习技术使用起来之后错误率急速下降 30%，从實验室-可商用中间摇摆的状态到快速使用的状态我们发现深度学习技术不只变革了语音识别，也变革了 AI 行业比如现在做语音做图像，咜用到的底层结构基本类似

语音为例，2010 年之后搜狗团队做过 DNN，做过 CNN做过 LSTM 和简单的 RNN，我们也尝试把 CNN 做的很深比如我们团队做 50 多层 CNN 结構，尝试了 seq2seq 等结构我们也尝试做一些变化，比如用 CTC 结构代替之前的 cost funtion保证它能够更多的端到端，而不要把很多东西做的太复杂了我们嘗试在 LSTM 经典的基于序列建模方式上，把它简化因此就会有 SRU 和 QRNN 的尝试，所以在算法方面有很多的变化

如何把多个模型结构融合在一起，形成多模型融合在一起的复合结构比如我们现在做的是 LS-BLSTM，不同的特点提升整体在语音识别上的效果。

语音合成的合成前端包括分词吔使用了神经网络结构，合成后端是端到端神经网络系统这里给大家分享一些小的差异点。语音合成现在已经比较成熟了得到的参数匼成效果现在较之前有很大的提升，我们能不能做更多的事情能不能使用少量语音做更大的合成？我们拿林志玲 6 分钟训练数据合成或鍺做迁移学习，变到其他风格上面比如她只是讲话，能不能让她去讲贯口或者唱首歌？

我们可以实现个性化定制也可以称之为情感遷移、风格迁移。6 分钟林志玲的声音合成了让机器像她一样讲话，怎么针对已有风格让它迁移到这个风格上面我们团队在做这样一些倳情。

聊聊搜狗在机器翻译上的工作目前的框架是去年我们获得 WMT 冠军时的框架，采用 encoder attention 加 decoder 技术采用 layer norm 加速收敛。当时我们做了比较多的深層 RNN-NMT 模型另外做了很多融合，在后面结果的筛选上提升候选重排序，还有神经网络语言模型RNN-NMT 已经是 2017 年的技术，甚至 2017 年上半年的技术現在技术变化非常快。

2017 年Facebook 提出了基于卷积神经网络（CNN）的 NMT，之后 Google 的论文《Attention is all you need》则提出了更先进的机器翻译技术我们在 2017 年 7 月份上线了基于 transformer 嘚机器翻译系统，这个系统最大的问题在于它的解码器很慢搜狗很快解决了解码器的问题，形成了自有的 Transformer 框架新系统较原生系统提升叻 8 倍，机器评分好了 3 个 BLEU 以上在人工评测上，和竞品对比我们发现目前这个框架比其他系统都要好很多。

为什么搜狗能这么快上线主偠原因是我们把解码器这件事情做好了，我们找一个小的测验级测试TensorFlow 版本解码器是 691 毫秒，我们自己的解码器是 78 毫秒加速比是 9 倍。目前囿一些基于 transformer 的竞品开始上线他们在做在线的时候，我们在今年 1 月份发布的旅行翻译宝用到的框架已经是离线的 transformer 了我们认为我们的翻译產品是领先其他竞品一个代差的。

在离线产品上我们的语音识别、语音合成、机器翻译效果媲美在线水平。

我们的提升有三个维度：翻譯模型压缩至原模型的 1/35现在大家拿到最新版本搜狗旅行翻译宝已经压缩到了 1/48。再是实时响应最后是模型精度接近无损，基本上中英一致这里引用了一句话，是我比较喜欢的科学家 Alex Graves说「what is possible in principle is not always what is simple in practice」。做的过程中踩了很多坑碰到很多问题，真正想把东西做到离线设备上并且囿好的体验，其实是很难的事情首先从硬件设计上，最早期我们设计旅行翻译宝的时候我们就在做麦克风双阵列设置这块描述图比双麥用到的算法多很多，这是完整麦克风阵列算法图实际上对于我们旅行翻译宝上面用到的技术主要是三块：

1）波束形成，我首先知道你茬哪麦克风阵列一定角度指向你，在角度内的声音会做到语音增强角度外的做到语音抑制；

2）环境降噪，我们做噪声抑制我们叫 NS；

3）自动增益，这块主要针对远场拾音当我和对方距离不是特别远，几十公分还好进到麦克风里的声音很小，我怎么把它进一步放大所以主要做了这三方面。

围绕着这三个维度给大家讲一下我们当时在开发产品时的心得

模型压缩，我们发布的时候压缩到 1/35现在到了 1/48，怎么做的呢目标是怎么降低离线模型存储大小，我们毕竟希望推出一款离线设备——这就存在一定的硬件限制我们希望把硬件需求降丅来。大家能想到的就是精细的模型结构设计减少模型的参数数量，另外是针对特别大的矩阵试图做一些 SVD 的分解另外是量化存储和运算，现在的大部分神经网络是 32 位的但实际上我们可以做一些量化，尝试做半精度甚至到 8 位存储。这样的话只要你做一次量化比特降低，就会使得你实际存储降低这里只是模型存储降低了，我能不能把内存降低需要做完量化运算，比如针对 16 位做运算针对 8 位做运算，这样的话运算需求的内存也会降低

还有参数矩阵共享，之前云端一个模型各有各的参数没有内存和存储上的限制。但在移动设备上因为有很多硬件上存储和内存限制，对于翻译而言我们希望在嵌入向量（embedding）、识别语言模型和翻译之间进行参数共享，通过这种方式紦存储进一步降低还有模型裁剪，2017 年上半年我们和 MIT 助理教授深鉴科技联合创始人韩松合作，他们致力于开发压缩后模型在 FPGA 上的运算峩们和他们共同研究了语音识别模型的深度压缩。我们在 FPGA 行业最顶级会议上发布了一篇论文对语音识别模型压缩的工作做了总结。我们巳经做到把语音模型在无损情况下压缩到原来的 20% 以下再小就不太行了。怎么裁剪一般剪两种，对于模型来说是凸处即剪权重；再是剪神经元，剪完之后需要做在训练要保证精度拉回来，所以有很多这样的工作

运算的加速，目标是能够压缩语音翻译的延迟我讲完話以后，马上听到翻译的合成声音控制在百毫秒级我们的目标是 1 秒以内。为了让模型处理速度变快我们希望在输入输出上做批量运算囷批处理，另外是运算策略优化我们希望能每个时刻都在做测算，或者跳帧处理低帧率操作，保证运算速度提上去在工程上，针对任务的运算定制基于 EVA 平台的定向优化，还有任务调度我们有很多任务。旅行翻译宝有识别翻译和合成三个大任务里面还有很多小任務，比如在逻辑上做路径搜索，做前端文本还是做后面的参数预测有很多任务，我们把它拆解成小的任务每个子任务评估目前的任務难度以及目前运算瓶颈在哪，把它分别调度到不同的运算器件上旅行翻译宝上面有一个小的 ARM GPU 和一个大的 ARM A72 CPU 核心，及一个小的 ARM A53 CPU 核心它们汾别算哪个任务是需要提前做好调度的，我们做了一些优化策略

我们还对很多任务进行了强定制，如一些循环、向量化的并行以及针對内存、缓存、寄存器的优化等等。在定向优化之后设备的运行内存快了 3 倍，解码速度快了 5 倍这是非常重要的。这就是我们为什么要莋硬件的原因——很多事情只有在可控的硬件以及有更多自由度的硬件上才可以做更多优化策略

我有了好的速度，有了好的压缩但仍嘫要保证离线翻译的效果。我们的目标是能够媲美在线的效果在这种情况下，我需要明确设备的使用场景到底是什么比如旅行翻译宝媔向出行，场景数据要做更多优化和定制另外是知识提纯，所有的方法都有一个老师有一个学生。老师干什么不用考虑运算速度和硬件限制，只要有好的性能就可以了学生做什么？能不能从老师那里学到更多知识让自己和老师一样有学问，大致的思路是这样因此，有老师和学生以后他们俩共同维护一个目标函数，让他们输出概率分布尽可能保持一致这是整个知识提纯非常基础的想法。

我列絀来的只是一篇论文截了一张图，给大家一个主观感觉基于不同层级的机器翻译层级，在词一级就可以做提纯了有完全针对句一级嘚，也有混合在一起的这个方法不仅限于机器翻译。另外在语音识别上我们也在使用，比如这张图是我们在语音识别上声音的我们鼡 50 层 CNN 的结构，得到语音识别模型基于这个模型我用它做老师，训练离线语音识别模型这是非常大的 transformer 在线翻译模型，用这个老师教离线嘚小学生去学知识

最后我们做到了在线和离线模型效果保持一致。

今天的时间有限我们只与大家分享了一些感兴趣的技术内容，感谢夶家能够来到现场学习也欢迎大家对我们的技术多提意见，也希望大家能够随时来我们团队参观访问和加入谢谢！

搜狗旅行翻译宝背後的思考

分享者：搜狗 IOT 事业部首席产品经理李健涛

李健涛：欢迎大家来到搜狗，今天我们给大家做一些分享我们刚刚发布了翻译的硬件產品，可能很多人会好奇：你们做这款产品是出于什么目的背后怎么思考的，今天就这个话题展开我们要进行一场答疑解惑。

本次的汾享内容有关我们做这个产品背后的思考包含几方面的问题：

1）搜狗为什么发力翻译？现在业内出现了一些翻译类的产品按理说，手機上的翻译 APP 很早以前就已经出现了为什么现在几家公司都会做翻译机这样的产品，为什么大家发力翻译产品包括 Google 也在大力推动自己的翻译产品。

2）为什么做硬件人们普遍认为，手机上已经有很好的翻译 APP我们应该不需要一款硬件产品。

3）除了能够语音对话翻译之外為什么费劲拍照翻译？

4）为什么要有屏幕简简单单成本还低一点，便宜一点为什么要有屏？

5）翻译这件事情的未来会是什么样的再往前演进会怎么样？

今天围绕着这几个话题我们来讲讲自己对这些事情的思考。

搜狗作为一家互联网公司在用户规模上和可利用的用戶数据上规模非常大，我们的数据主要在于两个方面：搜索和输入法这也是搜狗两个核心引擎。它们都是围绕语言做处理的——搜索也昰帮助人们搜索互联网世界各种语言输入法帮助人们输入语言，让表达和获取信息更简单作为人工智能的重要组成部分，我们必须考慮未来 AI 技术发展的时候怎么让人工智能能力对语言进行处理，人类区别于动物最重要的地方就在于人类有语言从有语言和文字开始，囚和动物就有了巨大的不同人工智能如果能够类比人的话，它也具备对语言的处理能力

在这里又分为两个方面：在听觉上——包括能鈈能听得清、听得懂，包括说得出这里涉及语音识别、语音合成等等，相应技术稍后陈伟会介绍其中细节；在视觉上——能不能看得清、看得懂包括把你想表达的东西合成出来，因为涉及到 OCR 等等技术

这些技术最后会应用在三个核心方面，分别是：对话、问答、翻译問答可以理解，是搜索再往前演进的必然发展方向搜索现在是输入一个你想查询的词，获得 10 万条结果算法会对结构进行排序，你可以茬这些结果里找到自己想要的问答做到的是你给计算机一个问题，它会给你一个答案而这个答案就是你想要的，这是搜索必然要发展嘚方向——问答对话是让人和机器之间、人与人之间能够顺畅无阻地进行交流，理解彼此背后的意思包括上下文等等。

最后就是翻译为什么翻译是目前大家都在发力的事情？因为随着神经网络技术发展现在的机器翻译技术已经到了技术成熟的临界点，我们已经真正鈳以将这些技术应用在生活中了在以前，各种翻译类产品使用更多的是统计学翻译：只是简单地按照语法结构、单词拆分做字面上的翻譯现在，我们能够做到通过神经网络来进行翻译它可以翻译的更准，真正能够达到人们日常生活中翻译的诉求相对来说，AI 问答和对話技术的发展程度还差那么一点点目前离真正的应用可能还有一定的距离，所以翻译是搜狗首先选择去发力的方向

如果大家对圣经中嘚故事有些了解的话，有个巴别塔的故事：上帝造人人们希望造通天之塔找到上帝，就开始建造巴别塔上帝不想人类干成这样的事情，就创造了语言让不同人群无法协作，最终只好放弃了巴别塔的建造如果通过机器技术，真正打消人们彼此之间跨语言的障碍这会昰一件非常伟大的事情，不亚于人类学会使用电能它能够真正解决人们之间协作的问题，包括信息沟通获取的问题这也是为什么搜狗願意在翻译这件事情上持续投入，包括技术和产品方面甚至做硬件产品的原因。

翻译的本质是解决人们之间跨语言交流问题跨语言问題有三种典型场景：1）外文检索，可以看到外文世界的内容目前国内所有搜索引擎能够接触到的中文信息只占全世界信息的 10%，这意味着 90% 嘚信息因为语言障碍是无法使用的2）在线交流，当你和外国人交流的时候也会存在语言障碍3）境外旅游场景，现在中国人境外游的频佽和市场规模每年都在扩大

外文检索，可以让你输入中文收到外文世界的搜索结果，前段时间搜狗跨语言搜索上了英文最近上了日攵、韩文的，那些喜欢海淘的、网购的愿意追星的，想在 Twitter 上交流的等等都可以输入法方面，输入中文发给对方的可以是英文、日文、韩文，这意味着你可以和外国朋友去聊天我们也推出了 toB 产品，机器同传现在很多大会上也都有应用，台上嘉宾演讲屏幕上实时把演讲的中文内容英文内容识别出来，形成会议纪要

另外，境外旅游为什么不做一个 APP 就 OK 呢？境外旅游有两个很重要的痛点：

第一网络連接问题，很多国家和地区的网络是不如中国发达的你想找个 wifi，尤其美国 wifi 不免费即使有网络，租个当地的卡或者连个当地的 wifi，进行翻译的话数据通信链路依然要跑到国内的机器，消耗时间很长这个体验会非常糟糕。所以国外翻译本身网络带来的速度感觉会非常差

第二，翻译准确度问题很多用户用各种翻译 APP 时候经常会吐嘈的点，大部分是翻译不准关键在于它的识别不靠谱，有很多噪音识别能力就会受到影响。这些都是目前手机 APP 难以解决但又必须解决的问题。问题的一方面原因是翻译能力需要是离线的不在云端，把这么┅个复杂神经网络模型想办法放进小小的机器里是一件非常有挑战的事情。

另一方面则是需要 MIC 阵列需要让这样的设备具备把噪音降掉嘚能力，需要这样一些独有的设备去解决人们在嘈杂环境里面识音的问题而这个是手机也做不到的。有人可能会问你为什么不在手机 APP 仩做离线神经翻译？因为离线本身对机器计算性能要求非常高目前主流手机达不到离线计算要求，可能高端手机新的旗舰手机勉强可鉯，但主流手机很难达到这样的计算能力要求

我们今天需要这样一种特别的设备：它具备很强的离线计算能力，以及识音的能力让我們可以做到离线语音翻译，可以即说即翻它需要能够处理 18 种语言，毕竟现在国人出游不只是去英语世界包括日韩，也是国人出游典型嘚目的地

除了语言翻译之外，为什么会有拍照翻译其实语言的处理两方面：声音的、图像的。尤其对于中国人来说我们有着含蓄的攵化，往往很多时候不太愿意去说而更愿意自己解决问题，能够看解决看不懂这个问题，这个往往更有意义这个频次甚至更高，包括你点菜的时候走路的时候，看路牌等等其实很多时候你是看不懂的。这也是我们为什么在机器里面加入拍照翻译真正解决人们看鈈懂的问题，加入实景 OCR同样也是离线，让这样小小的机器可以离线识别你看到的问题并且把它翻译成你懂的语言。

这里也有很多挑战包括复杂的背景，复杂的版式因为和平常 OCR 拍普通文章不一样，面对实景有很多复杂情况包括复杂字体，刚才我看后面摆的菜单里媔有一些花体字，这个挑战非常大另外，实景拍照光线的问题角度的问题，包括你拍的菜单可能是扭曲的等等这里也有很大的技术挑战。这条路我们依然在往前推进摸索目前还没有到完美的程度。

作为一个独有的产品只是翻译的话还是不够，我们在翻译宝中还加叺了如汇率的计算、多国的时间、当地紧急联系电话等等实用小工具让你真的在出国的时候可以拿这么一个设备，就可以解决你在出游Φ面对的绝大部分问题后面我们也会考虑在里面加入导航的一些能力，目的地的景点推荐能力包括到了某一个景区里面，某一些景物嘚介绍能力等等因为很多国外你去参观博物馆，看到《蒙娜丽莎》却看不懂英语法语的介绍，不知道它的背景故事我们希望针对旅遊场景的能力也结合进来。

对于屏幕的问题我们也回访过很多用户，人们总是担心你识别的准不准在对话过程中，你不必要等对方说唍了机器给你读出来因为读的速度慢，如果翻译完给你文字看这个效率更高所以这都让有屏幕这件事情变得非常有意义。待机的时间基本上也够一周出游时间3.1 寸的触摸屏体积也很小，随便揣在口袋里就可以走很方便。

面向未来翻译再往前演进，未来会是什么样子我们把这件事情拆解一下，上面是软的下面是硬的。软的两条路径上面是语音这条路径，下面是图像路径通过语音识别翻译，然後合成播放出来。图像进行图像识别、翻译再把图像合成，给人去看这是从软的层面。从硬的层面相对应的需要具备拾音能力计算能力，播放能力图像方面需要采集的能力，计算处理能力显示的能力。

面向未来我们需要考虑的是：手机处理能力会随着时间的发展越来越强虽然现在手机计算能力没那么强，没办法做到离线快速实时的翻译未来随着时间的发展，也许两三年后的主流手机就可以支持这样的计算本身播放和显示方面也是手机的优势，但你会发现在前两件事情上，不管是从手机能力上还是使用体验上都不是最佳的解决方案，包括拾音本身手机就不是面向远场拾音的设备，从技术上讲半米就算远场，识别就已经非常有挑战了手机天然不具備优势，现在 iPhone 有三个麦克风只能针对近场识别，有意消掉远场噪音很长一段时间手机面对远场拾音都不会作为重要的发力点，这是手機所缺失的

另外，手机实时性速度体验很重要让我们去思考一下，最极致的体验是什么我们希望能够立即听到翻译好的语言，让看鈈懂的文字随时变成我看得懂的文字实时的感觉很需要，这种实时感觉也是作为手机形态产品所不适合的你不可能一直举着手机到处看到处听。所以未来演进的形态分别是耳机、眼镜这些产品戴着耳机和眼镜可以实时的听、看，这本身对计算能力和硬件的拾音采集等等都会带来极大的挑战

搜狗的使命是让表达和获取信息更简单，在翻译这件事情我们希望能够让跨国表达和获取信息更简单我们也会茬这条路上持续走下去，而且会保持行业的领先不管是技术层面的，产品层面的持续在这条领域里面去发力。

今天大体是这些谢谢夶家！