挑战真实场景对话——小爱同学背后关键技术深度解析
本文来自 PaperWeekly 和 biendata 组织的企业 AI 技术实战讲座。作者为小米人工智能部的崔世起，崔老师以著名的“小爱同学”为实例，详细介绍了全双工关键技术及其应用。
本文主要分为四部分：
什么是全双工连续对话，针对全双工交互中涉及到的关键技术进行介绍
针对拒识和判不停两部分工作，介绍一下小米的实践
当前工作的进展与展望
按照惯例，我们依然为大家整理了直播中问答环节的精华内容
作者简介：崔世起，就职于小米人工智能部，目前主要负责小爱全双工项目的技术研发。
什么是全双工连续对话
全双工是通信领域的术语，指在通话的时候数据可以在两个方向同时传输。举个简单的例子可以解释全双工，手机通信就是全双工，而用对讲机通信是半双工。
全双工连续对话有三个特点：
第一是一次唤醒连续对话，以小爱智能音箱为例，用户唤醒小爱之后，一段时间之内可以对小爱连续地发出指令，不需要每次重新唤醒。
第二是边听边说，随时打断。边听边说是指小爱音箱在说话的同时可以听用户的指令。如果用户对小爱音箱的播报不感兴趣可以随时插话打断，这样交互效率会更高。
第三是在连续对话的场景下，人一边思考一边说话，产生一些不自然的停顿会更接近于人与人之间真实的表达方式。在多轮对话，也容易省略掉一些内容。
下面播放一段演示视频，是一段用户唤醒小爱之后的对话，其中有一些指令，也有人在闲聊，小爱可以智能地把闲聊的声音忽略掉。
人：小爱同学，今天心情好不好？
本来我今天心情不好的，你来找我聊天，瞬间心情变好了。
人：打开书房灯。
设备已经开了。
人：亮度调暗一点。
调暗了。
人：放一首《燕归巢》。
一首《燕归巢》送给你，遇到他道一声别来无恙。
画外闲聊音：我们自己聊天的声音是能够接收的。
人：它挺聪明的，应该不会乱搭话。
人：收藏这首歌。
已添加到我的收藏。
人：声音调大一点，换一首许嵩版的。
许嵩好听的《燕归巢》送给你。
人：现在几点了？
现在是下午1点7分。
人：都1点了，我去点外卖了.
你帮我也点一个。
人：好，退出。
（视频结束）
这段视频主要想要给大家演示，用户唤醒小爱之后，可以连续地发出不同的指令，包括闲聊、听音乐、调整音量和问时间，并且小爱能识别出周围人聊天的声音，不做出响应。
下面就介绍一下小爱在全双工上落地的设备。我们内部把全双工分为两种模式：
第一类是场景式的全双工，是针对全领域而言的。场景式的全双工，只会响应一个或者多个领域的指令，比如听音乐的场景，音箱会响应听歌、选歌、调音量的指令；看视频的场景，设备可以在用户看视频的过程中，允许连续地搜片、选片、快进。目前小爱触屏音箱支持听音乐、控制设备等场景，小米电视支持看视频的场景。
第二类全双工，我们称之为全领域。这种方式对用户的请求没有任何领域限制，是全领域的，同时允许用户与小爱聊天和问答，场景式的模式，实现起来会相对容易一点，而全领域对拒识要求比较严格。
全双工关键技术
接下来介绍全双工的一些关键技术。
首先是回声消除，由于小爱音箱在说话的时候会把自己的声音也录音，所以需要消除音箱自己的声音。这部分主要是通过前端声学算法解决，而回声消除也是全双工非常必要的部分。
第二是拒识，小爱音箱会一直开着麦克风，难免录入很多背景噪音，比如周围人的说话声，拒识的功能就是把无效的语音过滤掉。
第三是多轮对话，连续的对话模式，对基于上下文的意图理解有更高的要求，用户可以在多轮交互中让小爱完成更复杂的任务，并允许任务的切换。
第四是节奏控制，用户会以更加自然的方式对话小爱音箱，就会存在着停顿、节奏的变化，这时需要通过判不停更加智能地适应用户的说话节奏。当用户连续发出多条指令时，也需要对每一条指令的回复进行优先级控制。
第五是主动对话，全双工的场景下，不仅是用户问小爱，小爱还可以主动地抛出话题，引导对话。
最后对服务架构也有比较高的挑战，由于小爱音箱会实时连续不断地把语音传上来，对系统的效率有很高的要求，需要有高效的通信协议，同时能支持多模态的输入和异步的处理。
总结一下，全双工交互的实现，涉及到的技术链条相对比较长，从声学、语音到 NLP，涉及到算法与架构，需要各个模块的配合，才能达到相对比较好的体验。下面我会对中间的两部分内容：拒识和节奏控制中的语义判不停，分享一下我们在这方面做的一些实践、一些思考，希望能对大家有一些启发。
拒识功能就是识别出哪些话是同小爱说的，哪些不是同小爱说的。为什么拒识很重要呢？有统计数据表明，在全双工场景下无效人声占比大约在 15%~30% 之间，这个比例非常高，如果对所有的请求都响应，会对用户产生很大的干扰，导致全双工的可用性非常差。
无效音拒识，首先是非人声部分，非人声主要指的是一些背景噪音以及周围环境产生的声音，这一部分目前通过 VAD 已经能比较成熟地解决。另一部分是不清晰的人声，通过 ASR 可能识别不出文字或者对文字不是太置信，这时候可以通过 ASR 拒识。另外，还有很多无效人声需要拒识处理。
拒识具体要解决哪些问题呢？上图给了一些具体的例子：比如周围人的聊天声，需要被拒识；用户在小爱音箱旁，跟周围的人说话，小爱音箱要能识别出来，将其拒识；假设在会议室里其他人在发言，要怎样识别？假设在家里，小孩在朗读课文，怎么识别出来不是同小爱音箱说话？所以这种与小爱没有交互意图的声音需要拒识。
还有一类是电子人声，比如在电视旁边放了一个小爱智能音箱，电视里有人说话，小爱音箱如何识别出来？这是我们要解决的问题。
在拒识方面我们的做法大致可以分为四个阶段：
第一个阶段是场景拒识，对应场景式全双工。这种方案相对来说比较直接，首先我们定义好场景，确定场景下的意图集合，这是一个有限的集合。然后在意图集合中识别出用户意图，如果不在意图集合内的指令就可以不做响应。这种方式对于场景式全双工来说，基本上能达到可用的效果。
然后我们需要做全领域的全双工，这时我们直接想到的是采用策略拒识的方法，策略拒识顾名思义是人工设计的一些策略。制定策略要分析需要拒识的声音有什么样的规律，根据我们能用到的特征设计策略，这种方法在系统冷启动的阶段是比较适合的，因为我们拿不到太多的数据。
有足够多的数据的时候，就要向端到端数据建模的方式发展，就有了后续的语义拒识和多模态拒识。
关于策略拒识，我们的做法是将策略拒识的架构分为两层，底层是特征提取层，上层是策略层。
特征提取层通过各种模块提取特征。关于特征，首先是 NLU 部分，NLU 是利用小爱大脑意图识别的能力，给出 domain 和意图的打分。
还有一部分是语言模型，语言模型会给每一个 query 计算出困惑度，表示一个 query 合法的程度，然后通过 ASR 模块，提供一些语音方面的特征，包括用户说话的语速、信噪比，包括音量等，ASR 可以对 query 提供置信度信息，置信度表征的是语音清晰的程度。
策略的制定采用启发式，我们人工针对具体的 case 设计了各种策略，系统里大概有十来种策略，比如根据 query 是不是无意语义进行拒识、对于超长的 query 进行拒识、对于一些长尾的闲聊很有可能是周围人在聊天，进行拒识。还会根据用户说话的语速，假设用户在很短的时间内说了很长的话，有可能不是正常地在与小爱对话。
策略拒识的优点首先是比较适合在系统的冷启动阶段使用，比较易于快速迭代。另外一点是可解释性比较强，能针对具体问题，理解背后原因，而且能制定相应的策略进行修正。策略拒识还存在缺点，由于拒识策略的设计是基于一部分特征，而不是综合利用所有特征，也就无法学习特征的组合。
当不同特征的策略有冲突的时候，这种办法就很难处理了。
我们的解决思路是数据建模的方式，基于当前的 query 和历史的 query，建立二分类的模型，通过模型学习各类特征的最佳组合策略。这个思路有一个前提假设，用户“跟小爱说”和“不是跟小爱说”的 query 在语义空间上是不同的，用模型把两个空间划分出来，这样两个语义空间交集的部分，决定了这个问题能解决的上限。
介绍一下我们的做法，数据方面，人工标注大约 26K 的训练集，采用的特征，首先策略拒识中用到的一些文本特征，针对 query 提取表示向量，然后加一些统计特征，比如 query 的频次、统计特征，从一方面也能反映 query 的合法性和热门程度。我们还用了上下文特征，对上一轮 query 的 domain 打分。
模型采用了 BERT 二分类，首先通过 BERT 提取出 query 和上一轮 query 的向量表示，通过外部的模块提取出刚才提到的一些可解释的特征，以拼接的方式，接上全连接层和 softmax 进行分类。
介绍一下效果，我们使用了 1 万的测试集，相对于策略拒识，语义拒识的准确率能提升 10%，召回率能提升 10%。效果是非常明显的，但语义拒识也存在着问题。
首先语义识别比较依赖于文本，如果 ASR 有错误的话，会产生比较大的干扰。比如一段无意义的人声如果被识别成有头部意图的 query 的话，很容易干扰拒识的工作。
第二个问题是有些时候我们无法单纯从文本确定是不是在和小爱说话，比如用户对着旁边的孩子说给我背一下《弟子规》。其实小爱音箱收到这条指令的时候，也可以执行。这个 case 说明“跟小爱说”和“不是跟小爱说”，语义空间是有交叉的，这一部分问题单纯通过语义是解决不了的。
这就引入了我们的下一个方案：多模态的拒识。解决思路是通过 DNN 从原始的音频信号中提取语音特征的模式，同语义特征联合优化，得到更优的结果。
这就涉及到语音特征的提取，语音信号如果想在神经网络中处理，需要先进行预处理，输入是一维的声音序列，对应到每个时间点，是信号的强度。通过处理之后，会产生一个二维的 M 乘 N 矩阵，M 是每一帧能拿到的特征维度，N 对应到每一帧是时间维度。
语音特征的提取有非常通用的流程，很多开源的工具就可以实现这样的操作。通过一系列的处理，可以提取到各类特征，比如常用的 fbank、MFCC。
可以利用这些特征做下一步的处理。关于模型的选择，我们对比了很多类模型，这里列出两种，一种是单语音模型，另一种是语音加语义的模型。
单语音模型的输入只有用户的语音，语音加语义模型会把用户的语音和 ASR 取得的文本以及其他的一些语义特征，都输入到模型中去。最终效果，语音加语义的模型效果是要优于单语音模型的。单语音模型效果比之前的语义模型是更优。
我们采用的是语音加语义的模型的结构，也就是我们实验中效果最好的模型的结构。这个结构里最初的输入是语音，然后会有两路处理，一路是语音处理，一路是文本处理。
语音处理会经过特征提取模块，得到一些二维的特征矩阵，还会经过语音的 encoder，语音 encoder 可以选择适合处理语音的一些模型，比如 CNN、CNN+LSTM，这里我们选用的是 CNN+LSTM。
语音经过 ASR 处理之后会得到文本，然后经过文本的 encoder，文本的 encoder 也有很多种选择，我们可以选择比较流行的 BERT。语音和文本分别得到表示向量一步融合。这一步融合是根据下层的网络设计确定，可以采用 attention 的机制，也可以通过门控的机制进行融合。
另外两边是一些高阶特征，包括从声音能提出来的一些比如音量、语速、信噪比，上图右边是通过 NLU 模块提到的语义的高阶特征，然后把三类特征做拼接，最后综合分类。
经过30K训练集，10K测试集，语音加语义拒识的模型准确率相对于语义拒识提升22%，召回率能提升10%。以上就是关于拒识部分的一些工作。
接下来介绍一下语义判不停的部分。
语义判不停要解决的问题是如何更加准确地对用户说话中存在的一些停顿判断句子是否结束。根据小爱的用户日志统计，我们发现大约 5%~10% 的 query 是没有说完的，这说明用户的很多请求还没来得及说完，小爱音箱就提前响应了。
判断用户说完通用的方案是采用的 VAD 判停，这是一种声学方案，根据尾部的静音时长，设置一个固定的阈值，比如 300 毫秒到 500 毫秒，如果静音时长超过阈值就认为用户的话说完了，但如果用户的停顿超过这个时长就会出现过早判停的问题。
针对这个问题的解决方案是在 vad 判停之后，再从语义的角度判断用户的 query 是不是完整。如果没有完整的话，继续延长收音时长，让用户话完请求。
我们采用的方案，处理流程主要分为三步：第一步是规则系统。如果通过规则系统能给出判断的结果，就不会走下一步了。如果规则系统无法确定，就会进行第二步，单轮判别模型。如果单轮判定模型认为用户没说完的话，假设在多轮的场景下，会进行第三步多轮修正，给出最终的结果。
规则系统主要解决三类 query，一类是数量较少相对集中的头部的 query，，这一类 query 通过文本精确匹配的方式能很好地解决。第二类是一些有特定模式的 query，可以去做正则的匹配。还有一类是短 query，短 query 用模型相对难处理，我们采用了词性序列匹配的方式进行处理。
规则扩充一部分是手动补充，还可以基于用户的 session 挖掘。如果一个 query 用户没有说完就被打断了，用户往往会重新再说一遍，这样我们可以计算一个 query 在历史上被重说的概率，从而拿到很多的候选，然后再做进一步的处理。
关于模型的部分，模型主要是解决一些中长尾的 query，我们先后尝试了两种方法。第一种是基于语言模型的方法，第二种是基于分类模型的方法。
基于语言模型的方法是根据语言模型估计句子说完的概率，这种想法是非常直观的。因为语言模型比较擅长根据句子的前一个词计算出下一个词在词表上的分布。我们在 NLP 任务中一般会把句尾也当作一个词，这时候我们计算下一个词是句尾的概率，就可以表示一个句子说完的概率。
我们采用的是 LSTM 模型，模型的训练使用了中文的公开的一些数据集，也加入了小爱的一些 query。
判不停的条件用到三个：第一个条件是 EOS 的概率，就是句子下一个词是句尾的概率，这个概率越大，说明句子结束的概率越大。第二个条件是句子的混乱度，它表征了一个句子符合语法的程度，如果一个句子的混合度非常高，我们认为它可能是一些无效的 query，这时候就不会做判不停。第三个条件是字数。
相对于规则系统，加 LSTM 之后，准确率是有所下降的，因为规则系统是人工审核过的一些规则，准确率相对比较高。
加 LSTM 之后，在召回上大概有 6% 的提升，不是太大。这种方法存在一个问题：因为语言模型训练是基于非常大量数据的。如果想优化语言模型，周期相对比较长，经过一版优化之后，对于具体任务可能并没有太明显的效果，而且判别时可以用的参数也比较有限。所以说这种方法，比较难针对具体的任务进行特定的优化。
所以我们又尝试基于有监督的方式，用到的是 BERT 的二分类，也是比较容易想到的一种方法。这种方法的优点是利用大规模预训练模型学到的一些知识，针对特定的任务，对模型效果进行优化，所以理论上能达到更好的效果。由于分类模型其实是比较成熟的，对这样一个具体任务的优化，主要还是在数据建设还有数据增强方面。
然后关于数据集的构建，对于判不停任务，我们把不完整的 query 看作正样本，正样本的比例在实际的 query 分布中是很低的，所以我们的重点是如何寻找到更多的正样本。
可以利用已有的规则系统，语言模型筛选出一批正样本，但是仅用这些的样本是不够的，如果只用这些样本，只能学到系统已有的一些知识，所以还需要在线上随机抽样一批 query 进行人工标注，这样能增加样本的多样性。
模型效果的继续优化，主要是采用数据增强的方式，针对一些错误的 case，寻找出一些类似的表达的 query，挖掘出更多错误的样本。
经过上面的优化，模型的效果已经达到了可用状态。这时候模型需要到线上提供服务，但是 BERT 模型实际在线服务的延时和 QPS，离我们系统的要求是有一些距离的，所以需要继续对性能做优化。
这时我们尝试采用模型蒸馏的方式，训练一个更小的模型，具体的做法是：首先利用训练集训练了一个大的 BERT 模型，在 BERT 模型上效果比较好。然后将这个模型作为 teacher 模型，最终目标是训练一个更小的 ALBERT tiny 模型，这是一个层数更少更窄的模型，这个模型如果在线上提供服务，性能会非常高。
我们通过大的 BERT 模型对小的 ALBERT tiny 蒸馏，蒸馏的方法是在训练小模型时，计算 Loss 的时候，除了包含真实 label 产生的 Loss，还会根据 Teacher 模型计算出来的 logits 和 Student 的模型计算出来的 logits，计算蒸馏损失，最后把两种损失做加权求和，得到总的 Loss。
通过这种方式，最终得到小的模型可以学到 BERT 大模型的一些知识，在效果没有太明显下降的情况下，性能可以达到系统的要求。所以最终优化后的 ALBERT tiny 模型，在三个 GPU 的条件下，P99 能在 20 毫秒以内，QPS 能到 250 左右。
上图是分类模型的效果，规则系统加上 ALBERT 之后，相对于原有的规则系统，准确率是有些下降的，但是召回率增长了 14.8 个点，比 LSTM 要好一些。
接下来介绍一下多轮判不停，这是对于一些单轮判不完整的 query。基于多轮的情况下，可以完整地表达用户意图，这时不需要判不停。这里列了一个例子：上一轮用户说下载《王者荣耀》，小爱音箱回答确定要下载吗？用户说下载。如果用户首轮说下载，我们往往会认为接下来是要下载某一款软件，比如下载《王者荣耀》，但是在多轮情况下，就是完整的。
针对上面这种 case，只是对上一轮单轮判不完整的 query 才会出现，所以处理的流程是针对单轮模型判不停的 query，采用多轮模型对结果修正。
如何进行建模呢？如何把上一轮或上几轮的信息，用到单轮模型的分类上呢？
我们是这样思考的。分析这一类 case 会发现，这种情况的次轮，跟上一轮有一些承接关系，或者是对上一轮小爱音箱反问的回复，或者是在当前轮会省略掉之前的一些槽位。比如用户在上一轮需要定个闹钟，小爱音箱反问定个几点的？用户就说 8 点的，这时小爱会把上轮意图省略掉。
其实这里有着非常明显的承接关系，所以我们可以把这个任务定义成对上下文的承接关系进行建模，就比较自然地想到可以用 BERT 句对分类任务去做。我们实际做的时候是把前三轮的 query 和 answer 作为上句，当前轮的 query 作为下句，经过 BERT 模型做分类。
这种方法经过实践验证，效果确实不错，能够把刚才的那些 case 相对比较准确地识别出来，提升了系统 3 个点的准确率，召回率有微弱下降。
最后是我们目前做的其他工作和展望，在复杂任务方面，除了之前支持一轮、两轮完成的任务，目前还能支持通过多轮交互完成的任务，比如已经上线的语音点餐，还有正在做的语音购物。
目前我们也在把这套复杂任务的框架做成通用方案，方便扩展到更多的任务上。另一部分是在多模态上，我们现在在小爱音箱上已经能够引入一些视觉信息，包括人脸、手势和眼神，未来会增加更多有趣的交互。而在全双工的拒识方面，如果能利用多模态的信息，可以对拒识的准确率有更好的提升。
再一方面是情绪对话，也是小爱在尝试的一个方向。情绪对话包含两方面：一方面是小爱的情绪，一方面是用户的情绪。
小爱的情绪是说我们会在小爱的回复中增加一些情感，让小爱看起来有自己的喜、怒、哀、乐，与用户的情绪进行呼应。用户情绪需要根据用户各种模态的信息，包括声音、内容，甚至视觉信息识别用户的情绪，针对用户的情绪做出合适的反馈，给用户做更好的这种情感陪伴。
最后在主动对话方面，我们也做了很多工作。目前小爱音箱除了被动地与人交流，还会在对话中根据用户的兴趣推荐一些用户感兴趣的内容，比如推荐音乐；还能够对用户做一些提醒，比如对于极端天气的提醒，目前已经有很多的提醒的能力，未来会不断地完善用户画像，增加对用户的理解，这样可以给用户推荐出更多更好玩的内容。我们也在丰富提醒能力，希望能对用户有更大的帮助。
Q：全领域会不会很容易被小爱乱搭话？
A：全领域乱搭话是我们重点要解决的问题，这个问题处理比较困难。
Q：FBank 和 MFCC 都使用？
A：不是，刚才介绍的语音处理的流程是常用的语音处理的方式，能用到的一些特征，包括了 Fbank 和 MCCF，甚至一些其他的更多的特征。但我们并不是都使用，是根据自己的需求去选择合适的特征使用。
Q：单语音有麦克风阵列相关特征吗？
A：语音这一块的内容可能需要声学的同学去解释，我理解应该是没有用到麦克风阵列的相关特征。
Q：用 Query 完整性的模型.
A：其实我们分类的方式可以理解成是 Query 的完整性，可是这种方案在我们实验之前不太确定它的有效性或者完整性。这个问题的 Query 完整性，处理的数据和我们数据可能不太一样。
Q：线上拒识模型和策略共存吗？
A：是共存的。
Q：全双工在哪个场景下用得比较多？
A：听音乐场景下会比较多，一些特定场景下用得会多一些。
Q：多个说话人，背景有短暂噪声特殊解决方法。
A：对于多个说话人的问题，目前是实际上在语音识别上也没有特别好的解决办法，特别针对多个说话人，如果中间有一个是有效人声的话，这种还是比较难处理的。
Q：小爱的 ASR 和 NLU 是分开两个模型?
A：是分开的。
Q：全双工和连续对话是一回事吗？
A：不是一回事，全双工比连续对话的范畴更大一些，连续对话是说用户唤醒小爱音箱之后能够不断地聊，全双工的话可能会包含比如可以打断、可以支持自然的停顿、或者是支持主动的交互，全双工的范畴更大一些。这个范畴也是我们赋予的，其实没有一个比较科学的定义说全双工语音交互包含哪些？
Q：小爱的 ASR 识别纠错是怎么做的？
A：这是我们其他的团队做的，我这边不太好去解答里面会用到语言模型的一些技术。
Q：判不停分类，技能非常多，数据分布不均衡？
A:这个与技能关系不太大。我们不是针对技能去处理的，采用的方案与业务不是太绑定的。
Q：全双工场景下对 NLU 有特殊要求吗？
A：没特殊的要求。
Q：语音向量加入拒识，架构有没有调整？
A：语音架构加入拒识，在架构上有相应的一些解决方案。现在我们多模态模型，是有语音和文本两路输出，语音和 NLU 其实是在不同的环节处理的。所以说，关于语音向量与 NLU 的结果同时生效，我们在架构上是有一些特殊做法的。
Q：每一轮用户等待回复的时间有多少？
A：我理解这个问题是问响应时长，这与用户的网络，还有具体的 query 都有关系。
Q：多模态拒识中用到了哪些语音和文本高级特征。
A：语音特征，在 PPT 中都提到了一些在策略拒识中用到的特征。文本高级特征也是策略拒识中用到的一些特征，包括意图、domain 打分，或者频次等等。
Q：关于主动提问
A：其实我们是有主动的推荐，比如用户在晚上睡觉前，同小爱说晚安的时候，这时有可能会提醒用户,比如有些灯没关，这时问用户，要不要放一些睡眠音乐之类的。
Q：服务端设备每个用户单独开设一个通道吗？
A：这是涉及到服务架构方面。我们的服务会与用户的设备保持长连接的，相当于会给用户单独通道。
Q：线上效果怎么样？
A：全双工的效果体现用户平均的交流轮数，相对于非全双工用户是有明显提升的，请求量是增长了 20%~30%。
Q：多轮场景下，语义判不停是用于提高召回吗？
A：语义判不停是用于提高判不停的准确。
Q：BERT 会不会超时？
A：P99 延时，是能控制到 20 毫秒，还是非常快的。
Q：模型上线会有语义和语音依赖？
A：对的，会有依赖的。
关于数据实战派
数据实战派希望用真实数据和行业实战案例，帮助读者提升业务能力，共建有趣的大数据社区。
更多阅读
#投 稿 通 道#
让你的论文被更多人看到
如何才能让更多的优质内容以更短路径到达读者群体，缩短读者寻找优质内容的成本呢？答案就是：你不认识的人。
总有一些你不认识的人，知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁，促使不同背景、不同方向的学者和学术灵感相互碰撞，迸发出更多的可能性。
PaperWeekly 鼓励高校实验室或个人，在我们的平台上分享各类优质内容，可以是最新论文解读，也可以是学习心得或技术干货。我们的目的只有一个，让知识真正流动起来。
📝 来稿标准：
• 稿件确系个人原创作品，来稿需注明作者个人信息（姓名+学校/工作单位+学历/职位+研究方向）
• 如果文章并非首发，请在投稿时提醒并附上所有已发布链接
• PaperWeekly 默认每篇文章都是首发，均会添加“原创”标志
📬 投稿邮箱：
• 投稿邮箱：hr@paperweekly.site
• 所有文章配图，请单独在附件中发送
• 请留下即时联系方式（微信或手机），以便我们在编辑发布时和作者沟通
🔍
现在，在「知乎」也能找到我们了
进入知乎首页搜索「PaperWeekly」
点击「关注」订阅我们的专栏吧
关于PaperWeekly
PaperWeekly 是一个推荐、解读、讨论、报道人工智能前沿论文成果的学术平台。如果你研究或从事 AI 领域，欢迎在公众号后台点击「交流群」，小助手将把你带入 PaperWeekly 的交流群里。