11月13日,深圳 - 腾讯AI Lab今日发布了一款AI辅助翻译产品 - “腾讯辅助翻译”(Transmart),可满足用户快速翻译的需求,用AI辅助人工翻译提高效率和质量。该产品采用业内领先的人机交互式机器翻译技术,融合神经网络机器翻译、统计机器翻译、输入法、语义理解、数据挖掘等多项前沿技术,配合亿级双语平行数据,为用户提供实时智能翻译辅助,帮助用户更好更快地完成翻译任务。产品旨在致敬人工翻译,辅助人工翻译更快、更好地完成任务,探索人工智能赋能翻译行业新思路。


体验网址:腾讯发布人工智能辅助翻译,致敬人工翻译

同时,来自腾讯AI Lab的高级研究员黄国平,在QCon全球软件开发大会上发表了主题为「人机交互式机器泛起研究与应用」的主题演讲。

以下为黄国平在大会的演讲全文。

大家好,我是腾讯AI Lab黄国平,网名为@翻译驴,今天的演讲题目是《人机交互式机器翻译研究与应用》,给大家来分享关于人机交互式机器翻译的一些探索与思考。

需要特别说明的是,在AI技术行业落地过程中,我相信人机交互式机器翻译的经验也能给其他方向的探索有一些启发。

我博士毕业于中国科学院自动化研究所模式识别国家重点实验室,大的研究方向为机器翻译,具体方向为人机交互式机器翻译。

入职腾讯AI Lab后,继续该方向的研究与应用,目前总体负责一款相关的独立产品,最早将近期上线。

在今天的分享中,我首先会简单介绍一下与“翻译”这个关键词相关的现状介绍,包括机器翻译、翻译需求和人工翻译;然后系统介绍人机交互式机器翻译相关的技术、研究与应用;最后分享一下我对人工智能落地的一点思考。

机器翻译的现状

这些年,在大家的推波助澜之下,机器翻译的概念深入人心。一批机器翻译产品接二连三被发布出来,形式包括但不限于网页版、手机APP以及目前甚嚣尘上的翻译机与同声传译。随机机器翻译技术的进步,尤其是基于Transformer的翻译模型全面落地后,自动译文的质量获得大幅度的提升,以至于有些公司喊出了“人工智能将让人工翻译下岗”的口号。

但我们需要看到的是,目前的机器翻译产品的自动译文质量其实也并不高,基本不能用于比较严肃的场合,同时同质化现象也非常严重。

通过各家机器翻译网页版的截图,我们可以用一句诗来概念目前各家产品:藕花深处田田叶,叶上初生并蒂莲。用白话讲,大家都是多胞胎兄弟,没什么明显不同。从技术角度来看,机器翻译严重同质化主要还是因为技术突破是一件非常困难的事。因为技术的突破需要长期的积累,且投入的产出往往是不确定的。

目前国内实质拥有机器翻译科研力量的单位可以分成两类,一类是国有研究机构,主要有中国科学院自动化研究所、计算技术研究所,清华大学、东北大学、苏州大学、哈尔滨工业大学、南京大学等,另一类是商业公司设立的研究机构或者研发团队,如微软亚洲研究院、百度、有道、腾讯、搜狗、阿里巴巴、网易等。

原始学术创新大量来源于前一类研究机构,后一类主要承担起了落地和商业化变现的重任。需要提及的是,这个分类不是绝对的,比如后一类的微软亚研输出的学术创新成果是有目共睹的。

另外需要注意的是,有的公司明显缺乏核心科研力量,他们更多谋求通过宣传公关的方式来引起社会的关注,这是机器翻译行业客观存在的现实。在此向坚持数十年机器翻译研究的团队致以诚挚的敬意!

历史上出现过很多机器翻译方法,比较有名的如基于规则的翻译方法、统计机器翻译方法,目前最流行的是基于神经网络的机器翻译方法,简称为神经机器翻译NMT。

需要说明的是,以前的翻译方法并不是不用了,比如我们会用统计机器翻译的思路和方法改进NMT的翻译性能。在后续演讲过程中,为了方便起见,除非特别说明,“机器翻译”均指“神经机器翻译NMT”。神经机器翻译是指直接采用神经网络以端到端方式进行翻译建模的机器翻译方法。

区别于以前的翻译方法,神经机器翻译采用方法比较简单而且直观:首先使用一个称为编码器(Encoder)的神经网络将源语言句子编码为一个稠密向量,然后使用一个称为解码器(Decoder)的神经网络从该向量中解码出目标语言句子。这样的神经网络模型一般称之为“编码器-解码器”(Encoder-Decoder)结构。

在这种框架下,NMT其实就是一个典型的Seq2Seq模型,传统的NMT使用两个RNN:一个RNN对源语言进行编码,将源语言编码到一个固定维度的中间向量;再使用一个RNN进行解码翻译到目标语言。

从这里可以看出,在生成目标句子的单词时,不论生成哪个单词,它们使用的输入句子的语义编码都是一样的,没有任何区别。而语义编码是由源文句子的每个单词经过Encoder 编码产生的,这意味着不论是生成哪个单词,源文句子中的任意单词对某个目标单词来说影响力都是相同的。

比如输入的是中文句子:这是成功的秘诀,Encoder-Decoder框架逐步生成英文单词:this is the secret of success。

在翻译“秘诀”这个中文词的时候,模型里面的每个中文单词对于翻译目标单词“secret”贡献是相同的。很明显这里不太合理,显然“秘诀”对于翻译成“secret”更重要,但是目前这个模型是无法体现这一点的。

这样的模型,我们可以称之为分心模型。这样的模型在输入句子比较短的时候问题不大,但是如果输入句子比较长,此时所有语义完全通过一个中间语义向量来表示,单词自身的信息已经消失,可想而知会丢失很多细节信息。

为了解决上述模型的问题,我们需要引入注意力机制,即应该在翻译“secret”的时候,体现出中文词对于翻译当前英文单词不同的影响程度,比如给出类似下面一个概率分布值:(这,0.1)(是,0.1)(成功,0.2)(的,0.1)(秘诀,0.5)。

每个中文词的概率代表了翻译当前单词“secret”时,注意力分配模型分配给不同中文词的注意力大小。这对于正确翻译目标语单词肯定是有帮助的,因为引入了新的信息。采用注意力机制“编码器-解码器”结构与普通结构不同之处在于上下文向量的构建。解码步骤中,模型通过注意力机制选择性地关注源语言句子的不同部分,动态地构建上下文向量。

请看视频动态演示

接下来我们将介绍目前线上系统应用最广泛、一般也是自动译文性能最好的机器翻译方法:基于Transformer的机器翻译方法。

传统的神经机器翻译大都是利用RNN或者CNN来作为“编码器-解码器”的模型基础,而谷歌最新的只基于Attention的Transformer模型摒弃了固有的定式,并没有直接使用任何CNN或者RNN的结构。

编码器由6个相同的层堆叠在一起,每一层又有两个支层:第一个支层是一个多头的自注意机制,第二个支层是一个简单的全连接前馈网络。每部分的输出都经过一个LayerNorm,并且采用残差连接。模型的解码器也是堆叠了六个相同的层,每层除了编码器中那两个支层,解码器还加入了第三个支层:带有mask的多头自注意机制。在训练的时候,该模型可以高度并行地工作,所以在提升翻译性能的同时训练速度也特别快。

如果想详细了解Transformer模型的细节,请阅读论文《Attention is all you need》。

请看视频动态演示

接下来简单介绍一下机器翻译的训练流程。虽然机器翻译训练最终优化目标是尽可能提高自动译文与参考译文的相似度,但由于计算速度的原因,目前的训练优化目标一般是降低PPL(困惑度)。

因此,与一般的深度学习模型的训练过程是基本一致的。一般而言,先随机随机初始化模型参数,然后逐词解码一个或者多个Batch,然后计算损失,在这里一般是PPL,然后根据损失确定更新参数的策略。重复上述过程直到收敛。

机器翻译的困难 

在小节最后,我们总结一下机器翻译领域特有的一些困难。

我们一般认为,之所以目前的机器翻译质量还不够好,下边这些原因占了很大一部分。

首先,自然语言中普遍存在的歧义和未知现象始终难以被已有训练数据覆盖并被模型及时学习到,即便能覆盖也可能有长尾问题;其次,翻译本身并不仅仅是字符串的转换,比如我们并不能直接简单通过字面就能正确翻译“青梅竹马”这个词;再者,翻译的解并不唯一,始终存在人为的标准,这样直接做训练模型的损失函数失效;最后,有的翻译问题实在太难了,可能需要翻译大家穷其一生,更遑论机器翻译模型。比如在见到“最是那一低头的温柔,像一朵水莲花不胜凉风的娇羞”的时候,机器翻译几乎只能选择启动自杀程序(如果有的话)。

在这种背景下,除了极少一部分机器翻译能完成得很好的翻译任务以外,如果要正式使用自动译文,几乎都需要不同程度的人工介入。

这是我们为什么投入人机交互式机器翻译的最初动机。

在此,我们需要对传统人工翻译行业保持必要的谦逊,同时向长期奋斗在一线的翻译工作者们致以崇高的敬意。没有他们,我们的机器翻译将无以为继,因为训练语料的产生有赖于广大翻译工作者。

翻译需求与人工翻译行业

介绍完机器翻译现状,我们接下来回归到机器翻译要解决的问题本身,那就是翻译需求。有翻译需求,就离不开人工翻译行业。为了更清晰地看到机器翻译的未来,我们有必要将翻译需求与人工翻译行业看得更清楚。

就当下而言,整个人工翻译市场规模全球为400~500亿美元规模,但欧洲和北美洲占比就超过90%,整个亚洲占比才不到9%。由此可以推算,国内人工翻译行业产值在300亿人民币左右。

这个市场规模似乎并不值得机器翻译玩家们高举高打,因为机器翻译的产值应该不会超过人工翻译行业的产值,虽然机器翻译解决了以往人工翻译难以解决的需求,但新的需求往往难以产生有吸引力的商业价值。

需要提及的是,这里的翻译需求包括笔译、口译以及本地化。因此,如果一家公司想要靠机器翻译来支撑股价,这大概是不现实的。

那我们为什么又要投入精力研究人机交互式机器翻译呢?

主要原因是翻译需求虽然不大,但不可缺少,但是人工翻译翻译行业又非常零散。零散到什么程度呢?前100家语言服务提供者的市场占比总共不到15%。

而且排名和占比都基本稳定。

分散往往意味着低效,事实上也是如此,在以笔译为主的翻译市场上,技术所占的份额就比较少,口译的介入就更少了。

更艰巨的情况是,10人以内的团队为绝大多数,他们需要专业的翻译工具,却无力支付正版。目标也许已经很明确,为了人工翻译行业整体提高翻译效率,我们有必要投入足够的力量到人机交互式机器翻译技术研发中。

  人机交互式机器翻译

接下来我们来认真聊聊什么才是人机交互式机器翻译。

顾名思义,人机交互式机器翻译就是通过人机交互的途径来完成翻译任务,这显然区别于不对最终译文质量负责的全自动的机器翻译。

在前面的介绍中我们曾提到,目前机器翻译全自动输出的翻译结果无法保证译文质量。

但随着机器翻译技术的进步,帮助人工翻译提高翻译效率的可行性已经比较明显。此时的主要挑战在于,如何通过人机交互的方式来完全翻译作业,且要明显提高翻译效率、降低经济成本。

站在人工翻译侧,机器翻译需要能够接受用户提供的译文干预,及时学习用户的修改反馈,同时实时提供翻译辅助信息。

我们认为,同时满足上上述三个要求的系统才能称之为人机交互式机器翻译系统。

那人机交互式机器翻译技术如何与人工翻译完成配合呢?

经过深度调研,我们总结出了如下“一评估三交互”的人机交互翻译范式:

一评估指贯穿全过程的机器翻译自动译文质量评估技术,在具体的应用场景中,通过自动翻译质量评估,向用户推荐合适的交互手段;

三交互指三种人机交互手段,分别是翻译输入法、交互式机器翻译和译后编辑,分别适用于自动译文质量比较差、质量尚可和质量较优的情形。

在“一评估三交互”的人机交互翻译范式中,机器翻译系统承担助手角色,辅助人工翻译在不降低译文质量的前提下显著加快翻译效率。

因此,机器翻译需要承担的任务可以分为六类:

1. 整句更新,理解用户干预,输入当前句子更好的自动译文供人工译员参考和决策;

2. 优质翻译片断提示,以便用户快速采用机器翻译建议;

3. 翻译输入法,方便用户在翻译过程中精准组词,以快速录入人工译文;

4. 在线学习,及时学习用户修改反馈;

5. 语义理解,实时提供翻译辅助信息;

6. 快速解码, 所有交互过程必须实时响应。

可以看到,人机交互式机器翻译即有工程技术的难题,也有目前难以找到有效解决方案的学术问题。

接下来,我将介绍“三交互”中的三个重要模块。

首先是当自动译文质量比较好的情况下,直接通过译后编辑这种模式就可以快速完成翻译任务。

所谓译后编辑,简单而言就是指通过人工修改自动译文来完成翻译。主要的技术难点是如何准确自动推荐优质译文,业界通用的技术为Quality Estimation,即无参考译文的机器翻译质量评估。实现途径一般是特征工程,同时辅以人工翻译规则。

当机器译文质量尚可,但缺乏译后编辑价值时,就需要使用交互式机器翻译技术。交互式机器翻译的中心思想在于,机器翻译根据用户已输入片断,提供片断级的翻译建议。优化目标是通过尽可能少的人工干预,生成尽可能准确的长翻译片断。主要的技术难点在于如何理解用户给定的干预信息,干预信息包括但不限于译文片断、术语以及不希望出现的词。

交互式机器翻译的技术核心是约束解码方法。在通用的机器翻译系统中,模型的推理阶段一般采用标准的Beam Search算法。但在人机交互式机器翻译系统中,生成的自动译文往往需要满足一定约束,比如前缀约束、后缀约束、译文中必须出现或者必须不出现哪些片断。

比较简单且成熟的解码方法称为Grid Beam Search,即在推理的每一个时刻都试图扩展约束,最后输出满足所有约束的翻译假设。优点是代码简单直接,缺点是解码速度下降比较明显,且对约束的噪声比较敏感。

为了改进GBS的缺陷,我们将约束引入训练过程,即将约束作为额外特征引入模型,经实验证明,能达到与GBS基本一致的解码质量,能容忍最多60%的约束噪声,且翻译速度与标准Transformer模型基本一致。

译后编辑与交互式机器翻译的一个共同点都是需要用户阅读理解自动译文,如果自动译文质量比较差的情况下,这是不被用户所接受的。在比较严肃的领域,如医疗、医药、法律等领域是经常发生的事。

在这种情形下,机器翻译就不能辅助人工翻译提高翻译效率吗?

我们的答案是完全可行的,途径就是翻译输入法,在用户不阅读理解自动译文的前提下,通过机器翻译提升人工翻译效率。

我们来简单看一个例子。

用户希望录入的最终译文是“中国考虑改革公务员福利制度”,一般在录入时,我们都希望一次能多输入几个字。搜狗、谷歌、微软输入法虽然都很优秀,但是很遗憾,由于缺乏对翻译上下文的感知,如果输入的拼音串太长,则很容易解码不成功。

每个拼音对应多个汉字,把一个拼音串对应的汉字从左到右连起来,就是如图所示的网格图。y1,y2,y3,…,yN是用户输入的拼音串,N为拼音数也是输入法短语候选的汉字数;h11,h12,h13是第一个拼音y1的候选汉字,以此类推。

从第一个字到最后一个字可以组成很多句子,每一个句子和图中的一条路径一一对应。拼音输入法就是要根据上下文在给定拼音条件下找到一个最优的输入短语,我们利用对数线性模型可以对输入法进行建模。

传统的拼音输入法融合的特征有音字转换概率、字音转换概率、语言模型概率以及输入历史等。

而翻译输入法需要额外融合机器翻译相关的特征,比如翻译概率、翻译规则、翻译假设等。这些机器翻译相关的特征,直接反映了当前翻译的上下文信息,因此就能够生成更符合人工翻译期望的结果。

比如我们能比较少的按键数直接输入“中国考虑改革”。

在线学习是人机交互式机器翻译场景必然面对的挑战,在翻译过程中,用户希望系统能从反馈中自动纠正以前的自动翻译错误。

比如图中所求有两个比较明显的翻译错误,把publication chair翻译成了出版物的椅子,把人名错误翻译成了仁谏早。但在翻译过程中,人工翻译已经分别纠正为出版主席和井佐原均。

如果没有在线学习模块,则可以预计在后续的翻译过程中,自动翻译系统还会继续犯错。

大家可以通过学术搜索引擎发现很多关于在线学习方法的文献,比如我们选择了在线随机森林作为机器翻译在线学习的基础模型。

在翻译问题中,每个源短语对应包含中M棵决策树的随机森林,每棵决策树记录了不同的特征,最后通过投票来决定源短语到目标短语的翻译概率。

体现在线学习的主要是两个方面:

1. 在决策树生长过程中,根据信息增益决定具体的节点是否需要分支;

2. 在翻译过程中,随时根据错误率决定是否删除某决策树是否应该被删除重新生长。

另一种能达到类似于在线学习效果的方法是融合翻译记忆的机器翻译方法。翻译记忆的中心思想是让用户尽量复用之前的人工翻译结果,尽量避免重复翻译相同的文本。

我们可以在机器翻译解码过程中,通过翻译记忆来引导自动译文的生成更偏向翻译记忆中的匹配片断。

综合实验证明,融合翻译记忆之后,自动译文的质量提升是比较明显的。

我们在科研方面也提出了一些新方法,比如将翻译记忆的目标端句子压缩为词图,然后来引导神经机器翻译目标端句子的生成。

实验证明,翻译记忆与当前待翻译的源文句子的匹配率越高,则对自动译文质量的提升作用更为明显。

人机交互式机器翻译应用

在腾讯公司内部,机器翻译落地场景大致可以三类:

机器翻译+语音识别=同声传译;

机器翻译+OCR=拍照翻译;

机器翻译+人机交互=辅助翻译。

这些技术的落地可以同时为公司内产品服务,以及对外开放给合作伙伴。

就目前而言,在人机交互式机器翻译场景,腾讯走在行业前沿。

我们以一个具体的例子来说明人机交互式机器翻译的正确打开方式。这是某大型公司以翻译核心的多语知识解决方案。

整个公司可以分为两类部门:

大部分属于知识消费部门,即翻译需求的发起者,比如在专利申请、手册阅读、信息检索场景都可能有翻译需求;

第二部分是人数较少但不可或缺的知识生产部门,翻译团队,有的公司的做法是直接外包翻译任务,这里的翻译团队就是外部团队。

两类部门通过内部业务系统建立联系,如果没有机器翻译,则所有翻译需求都需要直接导向人工翻译团队。加入机器翻译之后,只需要概要阅读或者跨语言检索的场景则直接导向机器翻译。

如果引入人机交互式机器翻译之后,打通术语词典和翻译记忆库之后,则有一部分需要严肃翻译结果的需求也不用完全导流给人工翻译团队,用户可以直接以较少的努力就能快速完成翻译任务。

请看视频动态演示效果

最后,大家不禁要问,如何才能构建一套人机交互翻译系统呢?

我的答案是首先要定义明确的需求,即我们需要什么语种、什么领域、用于什么场景,以及如何现有业务系统打通;然后准备足量的双语平行句对作用训练语料;接着集成已经可以应用的最新技术,比如输入法、术语抽取、翻译片断挖掘等;再然后就是调试GPU集群、并行加速训练等;最后部署上线并迭代更新。

在这个过程中,往往会出现很多现实问题。比如最终部署的系统并不能完全预定任务,主要可能是对自动译文质量过高的期望,或者发现开源系统不是那么容易填坑,另外就是如何甄别出切实可用的技术,并拉通目标场景的技术链条。

最后的最后,我提出人工智能落地传统行业时遇到的三个典型问题:

1. 我们需要什么的人?调参大师和代码工匠都是需要的,那论文机器呢?现有人员能否快速转化科研成果?

2. 行业内、公司内的数据鸿沟和工程壁垒如何打通?毕竟人工智能技术不太可能成为独立存在,需要嵌入式即有业务逻辑之中;

3. 人工智能产品与用人工智能的产品是不一样的,我们如何选择?

我的分享到此结束,谢谢大家!

大家可以在本公众号号后台回复关键字「机器翻译」获取黄博士的现场演讲PPT。

腾讯AI Lab:深度解读AI辅助翻译的研究及应用相关推荐

  1. SDS分类图的更新 腾讯云存储深度解读

    [编者Peter Ye按] 本篇文章的主体部分是腾讯云美女技术专家Vivian Lei在2017年11月8日第二届日知录企业存储峰会上的演讲<EB级别云存储是如何涨成的?>,本篇文章在日知 ...

  2. 腾讯AI Lab披露可信AI研究进展,解读20余项原创工作

    感谢阅读腾讯AI Lab微信号第142篇文章.本文将介绍腾讯AI Lab在「可信AI」和科技向善的探索和最新研究成果. 近年来,人工智能算法被广泛地应用到医疗.金融.工业生产等多个重要领域,这些算法在 ...

  3. 一篇看懂CVPR 2017五大研究前沿 | 腾讯AI Lab深度解析

    感谢阅读腾讯AI Lab微信号第二篇文章,我们将深度解析本届CVPR热门研究.第一部分是五大前沿领域的重点文章解析,包括低中层视觉.图像描述生成.3D视觉.计算机视觉与机器学习.弱监督下的图像识别等. ...

  4. 开发者的520!11位业界大咖齐聚,深度解读AI大模型落地“解法”

    明天就是"520"了,在这个特殊的日子里,面向开发者的AI告白盛会--WAVE SUMMIT 2022深度学习开发者峰会即将准点上线! 随着数据井喷.算法进步以及算力的突破,效果好 ...

  5. 360金融首席科学家张家兴:只靠AI Lab做不好AI中台 | 独家专访

    「AI 技术生态论」 人物访谈栏目是 CSDN 发起的百万人学 AI 倡议下的重要组成部分.通过对 AI 生态顶级大咖.创业者.行业 KOL 的访谈,反映其对于行业的思考.未来趋势判断.技术实践,以及 ...

  6. 【人工智能】AI与深度学习重点回顾,从研究到应用,这是一份2017年AI领域的最全面总结

    2017年已经结束了,还有什么比回顾这一整年中AI的发展历程更激动人心的吗? AI大事件的作者Denny Britz梳理了2017整年的AI大事,人工智能从研究到应用领域的回顾,都在这篇AI超大事件里 ...

  7. 深度解读AI从业者必备算法和工具 -- 公开课

    1. 为什么需要学AI 关键词:下半场,ToC 类比一下APP: 上半场 -- 安装什么APP,这APP怎么样怎么样 下半场 -- 手机内存已满,卸载什么APP (在此阶段,如何利用好已有的APP用户 ...

  8. 【ACL 2020】腾讯AI Lab解读三大前沿方向及入选的20篇论文

    点击上方"AI遇见机器学习",选择"星标"公众号 重磅干货,第一时间送达 来源:腾讯AI实验室 自然语言理解是腾讯 AI Lab 的主要研究方向之一,研究能力也 ...

  9. ACL 2020 | 腾讯AI Lab解读三大前沿方向及入选的20篇论文

    点击上方,选择星标或置顶,不定期资源大放送! 阅读大概需要20分钟 Follow小博主,每天更新前沿干货 来源:腾讯AI实验室 自然语言处理领域顶级会议 ACL 2020 将于 7 月 5 日至 10 ...

最新文章

  1. 【 MATLAB 】unmkpp 函数介绍
  2. Rust基础笔记:Getting input from the console
  3. OTA:目标检测中的最优传输分配
  4. PHP错误处理 - debug_backtrace()的用法
  5. 一种向后兼容的C++结构体设计
  6. python基础教程(十一)
  7. .NET简谈事务、分布式事务处理
  8. linux的日记文件放哪,linux的日记文件在哪_网站服务器运转保护,linux
  9. 区块链 智能合约中获取不了时间戳 随机数怎么办
  10. svr测试用MATLAB,基于MATLAB的SVR回归模型的设计方案.doc
  11. 【点分治】的学习笔记和众多例题
  12. 自然语言处理TF-IDF关键词提取算法
  13. 快速保存微信文章中视频的方法
  14. 米特科技零信任新品 MetelTrust 智能 CPE 正式发布!
  15. 我的世界服务器高度无限吗,我的世界:玩家突破Y=256格高度限制,难道是假截图?毫无破绽...
  16. perl mysql 数据推拉_用perl 从mysql取出数据做统计分析代码
  17. 电脑账户头像怎么删掉_win10系统账户头像如何删除?windows10账户头像清除方法...
  18. 六月福师计算机应用基础在线作业,福师《计算机应用基础》在线作业一
  19. 医院计算机房建设,医院机房建设解决之道
  20. poj——3118 Arbiter

热门文章

  1. man-翻译和epoll相关的内容,部分
  2. NOD32客户端更新文件
  3. POJ - 2559 Largest Rectangle in a Histogram(笛卡尔树,单调栈实现)
  4. 牛客多校2 - Keyboard Free(几何)
  5. CodeForces - 1353F Decreasing Heights(dp)
  6. HDU - 4641 K-string(后缀自动机)
  7. 鸿蒙系统发红包,鸿蒙修真录红包版
  8. sox+linux查录音格式,linux-使用SOX和sox FAIL格式混合音频:无法打开输入文件`audio_recorded.wav’:WAVE:找不到RIFF标头...
  9. mysql续型_mysql续集1
  10. 【Boost】boost库中thread多线程详解12——线程的分离与非分离