01 # 行业大事件
语言大模型的终极目标是什么？
在自然语言处理（NLP）领域，暴力美学仍在延续。
自 2018 年谷歌推出 BERT（3.4 亿参数）以来，语言模型开始朝着「大」演进。国内外先后出现了参数量高达千亿甚至万亿的语言模型，比如谷歌的 T5（110 亿）、OpenAI 的 GPT-3（1,750 亿）、智源研究院的 WuDao2.0（1.75 万亿）……
有人不禁会问，语言模型的参数越来越大，它们究竟能做些什么，又智能到什么程度了呢？
9 月 28 日，浪潮人工智能研究院推出了中文巨量语言模型——源 1.0，让我们看到了语言模型超强的创作能力。
除了轻松应对大多数语言大模型都能完成的对话、故事续写、新闻生成和接对联等任务，源 1.0 还具备风格约束的诗歌创作能力，比如给出李白、杜甫或诗经风格的诗句，模型便能输出相应风格的诗句。堪称诗界的百变大师！
不仅如此，源 1.0 还具备强大的模仿能力，输入一个不存在的词语以及给出它的定义和示例。模型便能依葫芦画瓢，造出符合这个词语定义、逻辑和语境的语句。
这些只是源 1.0 一小部分创作能力的展示，一切都要归功于这个巨量中文模型具有的参数量——2,457 亿，以及它的全球最大中文数据集——5.02TB。并且，源 1.0 并不是由多个小模型堆砌形成，而是单体模型。因参数量巨大，所以称其为「巨量模型」。
相较于 GPT-3 的 1,750 亿参数，源 1.0 是其参数量的 1.404 倍。面对如此巨大的参数量，浪潮 1.0 在 2,128 个 GPU 集群上跑上 16 天完成了训练，每个 GPU 的实际训练性能达到 140 TFlops，消耗的总算力大约为 4,095 PetaFlop/s-day
相比之下，GPT-3 使用 10,000 块 GPU、花了 30 天才训练完了 1,750 亿参数，单 GPU 计算性能为 12TFlops，消耗的总算力为 3,640 PetaFlop/s-day。
从更直观的计算效率来看，GPT-3 完成训练需要 10,000 块 GPU，大约为 355 GPU 年。而源 1.0 使用 2,128 张 GPU，16 天就完成了训练，大约为 93 GPU 年。（GPU 年代表一张 GPU 跑 1 年能完成的工作量）
源 1.0 与 GPT-3 的参数量、算力对比
与此同时，在训练数据方面，源 1.0 不仅爬取了 2017 至 2021 年的网页数据，还使用了开源语料、中文百科和中文书籍等多个数据源，又通过粗筛和精筛，最终得到了一个 5.02TB 的全球最大高质量中文数据集。
训练出来的源 1.0 成功「兑现」了自己的能力，不仅在中文语言理解测评基准 CLUE 中刷榜文献分类、长文本分析等多项任务，更在零样本学习榜的成语阅读理解任务上超越人类水平。
更难能可贵的是，不同于 GPT-3 少量开放 API 的商用思路，浪潮的「源 1.0 开源开放计划」将包括模型 API、高质量中文数据集以及模型训练、推理和应用代码在内的资源向社区开放，还将开展面向国产 AI 芯片的模型移植开发。第一批计划合作对象包括大学或科研机构的 AI 研究团队、元脑生态合作伙伴和智能计算中心等。
单一ViT模型执行多模态多任务，谷歌用协同训练策略实现多个SOTA
Transformer 真的很全能。
Transformers 是一个灵活的神经端到端模型族（family），最开始是为自然语言处理任务设计的。近来，Transformers 已经在图像分类、视频和音频等一系列感知任务上得到应用。虽然近来在不同领域和任务上取得了进展，但当前 SOTA 方法只能为手头的每个任务训练具有不同参数的单一模型。
近日，谷歌研究院、剑桥大学和阿兰 · 图灵研究所的几位研究者在其论文《 PolyViT: Co-training Vision Transformers on Images, Videos and Audio 》提出了一种简单高效的训练单个统一模型的方法，他们将该模型命名为 PolyViT，它实现了有竞争力或 SOTA 的图像、视频和音频分类结果。
在设计上，研究者不仅为不同的模态使用一个通用架构，还在不同的任务和模态中共享模型参数，从而实现了潜在协同作用。从技术上来讲，他们的方法受到了「transformer 是能够在任何可以 tokenized 的模态上运行的通用架构」这一事实的启发；从直觉上来讲，是由于人类感知在本质上是多模态的，并由单个大脑执行。
论文地址：https://arxiv.org/abs/2111.12993
下图 1 为 PolyViT 的结构概览。
研究者主要使用的方法是协同训练（co-training），即同时在多个分类任务（可能跨多个模态）上训练单个模型。他们考虑了不同的设置，同时解决多达 9 个不同的图像、视频和音频分类任务。如上图 1 所示，PolyViT 模型能够执行多个任务，但对于给定的输入一次只能执行一个任务。虽然计算机视觉和自然语言领域探索过类似的方法，但研究者不清楚以往的工作是否考虑了多种模态以及是否使用这种方法实现了 SOTA 结果。
我们的协同训练设置简单实用。它不需要对协同训练数据集的每个组合进行超参数调整，因为我们可以很容易地调整标准单任务训练的设置。此外，协同训练也不会增加整体训练成本，因为训练步骤的总数不超过每个单任务基线的总和。
为了实现大量任务和模态协同训练的同时增加模型容量，研究者可以选择性地纳入 L_adapt ≥ 0 模态特定 transformer 层（他们表示为模态 - 适配器层），这些 transformer 层在 tokenization 之后直接应用。在这种情况下，所有模态和任务中会共享 L_=shared = L − L_adapt 层。
协同训练流程
在使用随机梯度下降（SGD）协同训练的所有任务中，研究者同时优化所有的 PolyViT 模型参数 θ。因此，在决定如何构建训练 batch、计算梯度以更新模型参数以及使用哪些训练超参数时有很多设计上的选择。
在所有情况下，研究者使用来自单个任务中的示例来构建自己的训练 minibatch。这一设计选择使得他们在使用相同的训练超参数（如学习率、batch 大小和动量）作为传统单一任务基线时，可以评估梯度和更新参数。这样一来，与单一任务基线相比，研究者无需任何额外的超参数就可以执行多个任务上的协同训练，从而使得协同训练在实践中易于执行，并减少执行大规模超参数扫描（sweep）的需求以实现具有竞争力的准确性。
在协同训练过程中，对于每个 SGD 步，研究者采样一个任务（或数据集），然后采样来自这个任务中的 minibatch，评估梯度并随后执行参数更新。需要着重考虑的是采样任务的顺序以及是否在不同的 minibatch 和任务上累积梯度。研究者在下图 2 中描述了几个任务采样计划，包括如下：
任务 1：逐任务（Task-by-task）
任务 2：交替（Alternating）
任务 3：统一任务采样（Uniform task sampling）
任务 4：加权任务采样（Weighted task sampling）
任务 5：累积梯度（Accumulating gradients）
02 # 极链新动态
1.情感分析/关系抽取模型SSAN上线
最近创建的一种新的神经网络，自我关注网络（SAN），其利用注意力机制作为基本构建块。自我关注网络已被证明对序列建模任务有效，同时没有复现。在这项工作中，我们探讨了SAN对情感分析的有效性，并且探讨了各种SAN修改的效果，如多头注意以及两种将序列位置信息合并到SAN中的方法。
2.图像分类模型AlexNet上线
AlexNet是2012年ImageNet竞赛冠军获得者Hinton和他的学生Alex Krizhevsky设计的。也是在那年之后，更多的更深的神经网络被提出，比如优秀的vgg,GoogLeNet。
3.文本生成模型MojiTalk上线
主要是生成带有情感语言是构建具有共情能力的自然语言处理主体的关键一步。然而，这一研究路线面临的一个主要挑战是缺乏大规模的带标签的训练数据。在这篇文章中，我们采取了一种激进的方法：我们借用了Twitter数据的想法，这些数据自然地被贴上了表情符号的标签。就是先假设twitter上emoji的表情可以用来表达整句含义，再利用emoji表情建立一个有标签的情感数据集。
4.文本分类/情感分析模型conv-emotion上线
对话情绪识别（Emotion Recognition in Conversations，ERC）是对话情感研究中的一个主要任务，用于实现具有情感理解能力的对话系统。该任务是一个分类任务，旨在对一段对话中的所有话语进行情绪分类。任务的输入是一段连续的对话，输出是这段对话中所有话语的情绪。
03 # 程序员专区
IntelliJ IDEA 2021.2.4 发布
IntelliJ IDEA 2021.2 的第四个错误修复版本正式推出，该版本值得关注的变化包括：修复了主菜单，使其现在可以立即加载；修复了主菜单中图标出现低分辨率问题；修复了 File mask 下拉列表，现在它可以正确显示可用的 mask；修复了结果选项卡，使其在你关闭选项卡时只响应对应的选项卡
Ember 4.0发布
Ember项目正式发布了Ember.js、Ember Data和Ember CLI 4.0版本。该版本通过删除了一些过时的API和对传统平台的支持，使其更加聚焦框架本身。Ember 3.15以来，Ember "Octane "API一直是新应用程序的默认配置，但根据我们的语义版本承诺，该框架继续支持 "Classic "框架功能。Ember 4.0虽然放弃了已经过时的经典API，但基础的EmberComponent和EmberObject/computed API在这个版本中并没有被删除。官方还表示，他们正在推动Ember 3.28成为Ember最新的长期支持（LTS）版本，对于使用LTS版本的用户，官方不鼓励直接升级到4.0，而是建议尽快升级到Ember 3.28 LTS版本。
XCode 13.2版本存在Log4j漏洞
有位TekGeeki用户在苹果开发者论坛提问，“在XCode 13.2版本中似乎包含了Log4j漏洞，请问该问题是否会发版解决？”对此，官方团队回复到，Xcode团队已经意识到这个问题，但通常不会为修复错误的时间提供 ETA，但团队已经意识到这个安全问题。在Xcode 13.2 .1中已经注明了该问题的存在。
Apache Log4j 2.17.0 发布
Apache Log4j正式发布Apache Log4j 2.17.0，该版本重点解决当前曝光的三个漏洞，分别是安全漏洞CVE-2021-45105、安全漏洞CVE-2021-45046、安全漏洞CVE-2021-44228、除此以外还带来了一些新功能，如API与实现分开，这样，开发人员就可以清楚地知晓使用了哪些类和方法，该功能也实现了向前兼容，Log4j团队将以安全且兼容的方式改进实现。此外还支持多种API，添加对对 Log4j 1.2、SLF4J、Commons Logging 和 java.util.logging (JUL) API 的支持。
Elasticsearch 7.16.2 发布
目前，搜索引擎库Elasticsearch正式发布Elasticsearch 7.16.2，该版本的基础设施已经升级到了log4j 2.17.0，此外，还对部分功能进行了增强和Bug修复，如将 boost 映射的弃用通知添加到API、改进Docker镜像的cacert脚本、kibana_system为APM和端点ILM策略实现了删除功能。
