RoBERTa:一种稳健优化的BERT预训练方法

https://arxiv.org/pdf/1907.11692

RoBERTa:一种稳健优化的BERT预训练方法

摘要

语言模型预训练已经带来了显著的性能提升,但对不同方法进行仔细比较具有挑战性。训练在计算上成本高昂,通常在不同大小的私有数据集上进行,并且,正如我们将展示的,超参数选择对最终结果有重大影响。我们提出了一项BERT预训练(Devlin等人,2019)的复制研究,该研究仔细测量了许多关键超参数和训练数据大小的影响。我们发现BERT的训练明显不足,并且可以匹配或超过其后发布的每个模型的性能。我们的最佳模型在GLUE、RACE和SQuAD上取得了最先进的结果。这些结果强调了先前被忽视的设计选择的重要性,并对最近报告的改进来源提出了质疑。我们发布了我们的模型和代码。

1 引言

ELMo(Peters等人,2018)、GPT(Radford等人,2018)、BERT(Devlin等人,2019)、XLM(Lample和Conneau,2019)和XLNet(Yang等人,2019)等自训练方法带来了显著的性能提升,但确定这些方法中哪些方面贡献最大可能具有挑战性。训练在计算上成本高昂,限制了可以进行的调整量,并且通常在不同大小的私有训练数据上进行,这限制了我们衡量建模进展效果的能力。

我们提出了一项BERT预训练(Devlin等人,2019)的复制研究,其中包括对超参数调整和训练集大小效果的仔细评估。我们发现BERT的训练明显不足,并提出了一种改进的BERT模型训练方法,我们称之为RoBERTa,它可以匹配或超过所有BERT后续方法的性能。我们的修改很简单,包括:(1)使用更大的批次、更多的数据对模型进行更长时间的训练;(2)移除下一句预测目标;(3)训练更长的序列;以及(4)动态改变应用于训练数据的掩码模式。我们还收集了一个大型新数据集(CC-NEWS),其大小与其他私有使用的数据集相当,以更好地控制训练集大小的影响。

在控制训练数据的条件下,我们改进的训练程序在GLUE和SQuAD上都优于已发表的BERT结果。当在更多数据上进行更长时间的训练时,我们的模型在公共GLUE排行榜上获得了88.5的分数,与Yang等人(2019)报告的88.4相匹配。我们的模型在GLUE的9个任务中的4个上建立了新的最先进水平:MNLI、QNLI、RTE和STS-B。我们还在SQuAD和RACE上达到了最先进的结果。总体而言,我们重新确立了BERT的掩码语言模型训练目标与其他最近提出的训练目标(如扰动自回归语言建模(Yang等人,2019))相比具有竞争力。

总而言之,本文的贡献在于:(1)我们提出了一系列重要的BERT设计选择和训练策略,并引入了能够带来更好下游任务性能的替代方案;(2)我们使用了一个新的数据集CC-NEWS,并确认使用更多数据进行预训练能够进一步提高下游任务的性能;(3)我们的训练改进表明,在正确的设计选择下,掩码语言模型预训练与所有其他最近发布的方法具有竞争力。我们发布了我们的模型,以及在PyTorch(Paszke等人,2017)中实现的预训练和微调代码。

2 背景

在本节中,我们简要概述BERT(Devlin等人,2019)预训练方法以及我们将在下一节中实验性地检验的一些训练选择。

2.1 设置

BERT以两个片段(标记序列)的连接作为输入,x1, ..., xN和y1, ..., yM。片段通常由多个自然句组成。这两个片段以单一输入序列的形式呈现给BERT,并用特殊标记来分隔它们:[CLS], x1, ..., xN, [SEP], y1, ..., yM, [EOS]。M和N受到约束,使得M + N < T,其中T是控制训练期间最大序列长度的参数。

该模型首先在大型未标记文本语料库上进行预训练,随后使用终端任务标记数据进行微调。

2.2 架构

BERT使用现在无处不在的transformer架构(Vaswani等人,2017),我们在这里不会详细回顾。我们使用一个有L层的transformer架构。每个块使用A个自注意力头和隐藏维度H。

2.3 训练目标

在预训练期间,BERT使用两个目标:掩码语言建模和下一句预测。

2.3.1 掩码语言模型(MLM)

输入序列中的标记被随机抽样,并替换为特殊标记[MASK]。MLM目标是关于预测被掩码标记的交叉熵损失。BERT统一选择15%的输入标记进行可能的替换。在被选中的标记中,80%被替换为[MASK],10%保持不变,10%被替换为随机选择的词汇表标记。

在原始实现中,随机掩码和替换在训练开始时执行一次,并在整个训练期间保存,尽管在实践中,数据会被复制,因此对于每个训练句子,掩码并不总是相同的(参见第4.1节)。

Read more

三台机器部署 ClickHouse 高可用集群实战记录

本文是一份可发布版部署记录。真实 IP、域名、账号、密码、下载链接、业务目录名、机器唯一标识等敏感信息已经替换为占位符。命令中的 <...> 需要按自己的环境替换。 目标与拓扑 这次目标是用三台数据节点部署一套 ClickHouse 高可用集群,拓扑采用: 1 shard x 3 replicas 含义是:集群只有一个逻辑分片,三台机器都保存同一份数据的完整副本。任意一台数据节点宕机时,只要 ClickHouse Keeper 仍然有多数派,剩余节点仍可继续提供读写服务。 规划节点如下: 主机名示例地址角色ch-01<ch-01-ip>ClickHouse Server + ClickHouse Keeperch-02<ch-02-ip>ClickHouse Server + ClickHouse Keeperch-03<ch-03-ip&

By ladydd

折腾记(二):接入火山引擎实时语音 API,家庭语音助手体验直接拉满

接上篇 上一篇用全开源组件(Whisper + Hermes + Edge-TTS)搭了个语音助手,能跑,但体验就是"能用"二字: * 中文识别只有 70 分,方言基本歇菜 * 英文唤醒词"Alexa"喊着别扭 * 说完到回复要等 4-8 秒 * 它说话的时候你插不了嘴 这些问题靠堆开源组件很难根治。于是我去试了火山引擎(字节跳动)的语音服务,结果直接换了条路。 这篇分两段:先讲怎么用火山引擎的 ASR/TTS 替换掉开源组件(小改),再讲怎么上端到端实时语音模型(大改)。 第一段:先把 ASR 和 TTS 换成火山引擎 为什么换 我用豆包输入法的时候发现它语音识别准得离谱。一查,豆包用的就是字节自家的火山引擎 Seed-ASR。开通后有免费额度(

By ladydd

折腾记(一):用全开源组件给家里搭一个语音助手,对接自己的 Hermes Agent

起因 事情是从一块 ESP32-S3 开发板开始的。 我手上有一块 Seeed Studio XIAO ESP32-S3 Sense,带摄像头和麦克风。最初的想法很美好:用这块板子做一个无线语音终端,对着它说话,连到我服务器上跑的 Hermes Agent(一个自托管的 AI agent),让它回答我。 但折腾到一半我突然意识到一件事:我的麦克风、音响、服务器全在家里,为什么要绕一圈用 ESP32?直接把麦克风和音响插到服务器上不就行了? ESP32 那条路(做无线拾音终端)当然也有价值,但那是"为了学嵌入式而学",不是解决问题的最短路径。于是这个项目就从"嵌入式项目"变成了"在服务器上拼一个语音助手"。这篇就记录后者。 教训零:先想清楚你要解决的是什么问题。很多时候最优解比你最初设想的简单得多。 目标

By ladydd

Kiro 的三种代理设置方法:本地、服务端、Remote

作为kiro的骨灰级用户,这篇是我自己折腾 Kiro / Kiro Remote / Ubuntu Server 代理问题后的复盘。 核心不是“怎么配一个代理”,而是先判断:到底是谁在访问外网? 谁访问外网,代理就要配给谁。 0. 先说结论 Kiro 相关代理大概分三类: 场景真正访问外网的进程在哪里代理应该配在哪里本地 KiroWindows / Mac 本机本机 Clash / Proxifier / 系统代理服务端 Kiro / CLIUbuntu Server 上的 shell、CLI、node、kiro 进程Ubuntu 的环境变量,比如 HTTP_PROXY / HTTPS_PROXYKiro Remote远程 Ubuntu 上的 ~/.kiro-server 和 extensionHost远程 Ubuntu 的 Kiro Server

By ladydd
陕公网安备61011302002223号 | 陕ICP备2025083092号