解密Prompt系列3. 冻结LM微调Prompt: Prefix-Tuning & Prompt-Tuning & P-Tuning
这一章我们介绍在下游任务微调中固定LM参数,只微调Prompt的相关模型。这类模型的优势很直观就是微调的参数量小,能大幅降低LLM的微调参数量,是轻量级的微调替代品。和前两章微调LM和全部冻结的prompt模板相比,微调Prompt范式最大的区别就是prompt模板都是连续型(Embedding),而非和Token对应的离散型模板。核心在于我们并不关心prompt本身是否是自然语言,只关心prompt作为探针能否引导出预训练模型在下游任务上的特定能力。
固定LM微调Prompt的范式有以下几个优点
- 性价比高!微调参数少,冻结LM只微调prompt部分的参数
- 无人工参与!无需人工设计prompt模板,依赖模型微调即可
- 多任务共享模型!因为LM被冻结,只需训练针对不同任务的prompt即可。因此可以固定预训练模型,拔插式加入Prompt用于不同下游任务
Prefix-Tuning
- Paper: 2021.1 Optimizing Continuous Prompts for Generation
- Github:https://github.com/XiangLi1999/PrefixTuning
- Prompt: Continus Prefix Prompt
- Task & Model:BART(Summarization), GPT2(Table2Text)
最早提出Prompt微调的论文之一,其实是可控文本生成领域的延伸,因此只针对摘要和Table2Text这两个生成任务进行了评估。
先唠两句可控文本生成,哈哈其实整个Prompt范式也是通用的可控文本生成不是,只不过把传统的Topic控制,文本情绪控制,Data2Text等,更进一步泛化到了不同NLP任务的生成控制~~
Prefix-Tuning可以理解是CTRL[1]模型的连续化升级版,为了生成不同领域和话题的文本,CTRL是在预训练阶段在输入文本前加入了control code,例如好评前面加'Reviews Rating:5.0',差评前面加'Reviews Rating:1.0', 政治评论前面加‘Politics Title:’,把语言模型的生成概率,优化成了基于文本主题的条件概率。
Prefix-Tuning进一步把control code优化成了虚拟Token,每个NLP任务对应多个虚拟Token的Embedding(prefix),对于Decoder-Only的GPT,prefix只加在句首,对于Encoder-Decoder的BART,不同的prefix同时加在编码器和解码器的开头。在下游微调时,LM的参数被冻结,只有prefix部分的参数进行更新。不过这里的prefix参数不只包括embedding层而是虚拟token位置对应的每一层的activation都进行更新。

对于连续Prompt的设定,论文还讨论了几个细节如下
- prefix矩阵分解
作者发现直接更新多个虚拟token的参数效果很不稳定,因此作者在prefix层加了MLP,分解成了更小的embedding层 * 更大的MLP层。原始的Embedding层参数是n_prefix * emb_dim, 调整后变为n_prefix * n_hidden + n_hidden * emb_dim。训练完成后这部分就不再需要只保留MLP输出的参数进行推理即可
个人感觉MLP的加入是为了增加多个虚拟token之间的共享信息,因为它们和常规的连续文本存在差异,需要被作为一个整体考虑,可能对prefix位置编码进行特殊处理也阔以??
- prefix长度
prefix部分到底使用多少个虚拟token,直接影响模型微调的参数量级,以及处理长文本的能力。默认的prefix长度为10,作者在不同任务上进行了微调,最优参数如下。整体上prompt部分的参数量都在原模型的~0.1%

- 其他:作者还对比了把prefix放在不同位置,以及使用任务相关的Token来初始化prefix embedding的设定,前者局限性较大,后者在后面的paper做了更详细的消融实验
效果上在Table2Text任务上,只有0.1%参数量级的prompt tuning效果要优于微调,

在Xsum摘要任务上,prompt的效果要略差于微调。

Prompt-Tunning
- Paper: 2021.4 The Power of Scale for Parameter-Efficient Prompt Tuning
- prompt:Continus Prefix Prompt
- Github: https://github.com/google-research/prompt-tuning
- Task: SuperGLUE NLU任务
- Model: T5 1.1(在原T5上进行了细节优化)

Prompt-Tunning是以上prefix-Tunning的简化版本,面向NLU任务,进行了更全面的效果对比,并且在大模型上成功打平了LM微调的效果~
简化
对比Prefix-Tunning,prompt-tuning的主要差异如下,
论文使用100个prefix token作为默认参数,大于以上prefix-tuning默认的10个token,不过差异在于prompt-Tunning只对输入层(Embedding)进行微调,而Prefix是对虚拟Token对应的上游layer全部进行微调。因此Prompt-Tunning的微调参数量级要更小,且不需要修改原始模型结构,这是“简化”的来源。相同的prefix长度,Prompt-Tunning(<0.01%)微调的参数量级要比Prefix-Tunning(0.1%~1%)小10倍以上,如下图所示

为什么上面prefix-tuning只微调embedding层效果就不好,放在prompt-tuning这里效果就好了呢?因为评估的任务不同无法直接对比,个人感觉有两个因素,一个是模型规模,另一个是继续预训练,前者的可能更大些,在下面的消融实验中会提到
效果&消融实验
在SuperGLUE任务上,随着模型参数的上升,PromptTunning快速拉近和模型微调的效果,110亿的T5模型(上面prefix-tuning使用的是15亿的GPT2),已经可以打平在下游多任务联合微调的LM模型,并且远远的甩开了Prompt Design(GPT3 few-shot)

作者也做了全面的消融实验,包括以下4个方面,最核心的感受就是只要模型足够够大一切都好说
- prompt长度(a):固定其他参数,作者尝试了{1,5,20,100,150}, 当模型规模到百亿后,只要prompt长度大于1,更长的prompt并不能带来效果提升
- Prompt初始化(b): 作者尝试了随机uniform初始化,用标签文本空间初始化,和用Top5K高频词采样初始化,在10^8规模,标签词初始化效果最好。作者发现预测label也会在对应prompt空间内。不过到百亿规模后,初始化带来的影响就会消失
- T5继续预训练(c):作者认为T5本身的Span Corruption预训练目标和掩码词,并不适合冻结LM的场景,因为在微调中模型可以调整预训练目标和下游目标的差异,而只使用prompt可能无法弥合差异。其实这里已经能看出En-Dn框架在生成场景下没有GPT这样的Decoder来的自然。因此作者基于LM目标对T5进行继续预训练
- 继续预训练step(d):以上的继续预训练steps,继续预训练步数越高,模型效果在不同模型规模上越单调。

可解释
考虑Prompt-Tunning使用Embedding来表征指令,可解释性较差。作者使用cosine距离来搜索prompt embedding对应的Top5近邻。发现
- embedding的近邻出现语义相似的cluster,例如{ Technology / technology / Technologies/ technological / technologies }, 说明连续prompt实际可能是相关离散prompt词的聚合语义
- 当连续prompt较长(len=100), 存在多个prompt token的KNN相同:个人认为这和prefix-tuning使用MLP那里我的猜测相似,prompt应该是一个整体
- 使用标签词初始化,微调后标签词也大概率会出现在prompt的KNN中,说明初始化可以提供更好的prior信息加速收敛
P-Tuning
- Paper: 2021.3, GPT Understands, Too
- prompt:Continus Prefix Prompt
- Task: NLU任务, 知识探测任务
- github: https://github.com/THUDM/P-tuning
- Model: GPT2 & BERT
P-Tuning和Prompt-Tuning几乎是同时出现,思路也是无比相似。不过这个在prompt综述中被归类为LM+Prompt同时微调的范式,不过作者其实两种都用了。因此还是选择把p-tuning也放到这一章,毕竟个人认为LM+Prompt的微调范式属实有一点不是太必要。。。
论文同样是连续prompt的设计。不过针对上面提到的Prompt的整体性问题进行了优化。作者认为直接通过虚拟token引入prompt存在两个问题
- 离散性:如果用预训练词表的embedding初始化,经过预训练的词在空间分布上较稀疏,微调的幅度有限,容易陷入局部最优。这里到底是局部最优还是有效信息prior其实很难分清
- 整体性:多个token的连续prompt应该相互依赖作为一个整体,不谋而合了!
针对这两个问题,作者使用双向LSTM+2层MLP来对prompt进行表征, 这样LSTM的结构提高prompt的整体性,Relu激活函数的MLP提高离散型。这样更新prompt就是对应更新整个lstm+MLP部分的Prompt Encoder。下面是p-tuning和离散prompt的对比

作者分别对LAMA知识探测和SuperGLUE文本理解进行了评测。针对知识抽取,作者构建的prompt模板如下,以下3是虚拟prompt词的数量,对应prompt encoder输出的embedding数
- BERT:(3, sub,3,obj,3)
- GPT(3,sub,3,obj)
在知识探测任务中,默认是固定LM只微调prompt。效果上P-tuning对GPT这类单项语言模型的效果提升显著,显著优于人工构建模板和直接微调,使得GPT在不擅长的知识抽取任务中可以基本打平BERT的效果。

针对SuperGLUE作者是做了LM+Prompt同时微调的设定。个人对LM+prompt微调的逻辑不是认同,毕竟1+1<2,同时微调它既破坏了预训练的语言知识,也没节省微调的参数量级,感觉逻辑上不是非常讲的通(哈哈坐等之后被打脸)。结论基本和以上知识探测相似

开头说优点,结尾说下局限性
- 可解释性差:这是所有连续型prompt的统一问题
- 收敛更慢: 更少的参数想要撬动更大的模型,需要更复杂的空间搜索
- 可能存在过拟合:只微调prompt,理论上是作为探针,但实际模型是否真的使用prompt部分作为探针,而不是直接去拟合任务导致过拟合是个待确认的问题
- 微调可能存在不稳定性:prompt-tuning和p-tuning的github里都有提到结果在SuperGLUE上无法复现的问题
更多Prompt相关论文,AIGC相关玩法戳这里DecryptPrompt
Reference
- CTRL: A CONDITIONAL TRANSFORMER LANGUAGE MODEL FOR CONTROLLABLE GENERATION。可以当做prefix-tuning的前导文来看
- WRAP: Word-level Adversarial ReProgramming。介于Prefix-Tunning和Prompt-Tunning之间,这里就不细说了
- 苏神https://kexue.fm/archives/8295
解密Prompt系列3. 冻结LM微调Prompt: Prefix-Tuning & Prompt-Tuning & P-Tuning的更多相关文章
- .NET Core加解密实战系列之——使用BouncyCastle制作p12(.pfx)数字证书
简介 加解密现状,编写此系列文章的背景: 需要考虑系统环境兼容性问题(Linux.Windows) 语言互通问题(如C#.Java等)(加解密本质上没有语言之分,所以原则上不存在互通性问题) 网上资料 ...
- Java 加解密技术系列文章
Java 加解密技术系列之 总结 Java 加解密技术系列之 DH Java 加解密技术系列之 RSA Java 加解密技术系列之 PBE Java 加解密技术系列之 AES Java 加解密技术系列 ...
- 11.Java 加解密技术系列之 总结
Java 加解密技术系列之 总结 序 背景 分类 常用算法 原理 关于代码 结束语 序 上一篇文章中简单的介绍了第二种非对称加密算法 — — DH,这种算法也经常被叫做密钥交换协议,它主要是针对密钥的 ...
- 10.Java 加解密技术系列之 DH
Java 加解密技术系列之 DH 序 概念 原理 代码实现 结果 结束语 序 上一篇文章中简单的介绍了一种非对称加密算法 — — RSA,今天这篇文章,继续介绍另一种非对称加密算法 — — DH.当然 ...
- 9.Java 加解密技术系列之 RSA
Java 加解密技术系列之 RSA 序 概念 工作流程 RSA 代码实现 加解密结果 结束语 序 距 离上一次写博客感觉已经很长时间了,先吐槽一下,这个月以来,公司一直在加班,又是发版.上线,又是新项 ...
- 8.Java 加解密技术系列之 PBE
Java 加解密技术系列之 PBE 序 概念 原理 代码实现 结束语 序 前 边的几篇文章,已经讲了几个对称加密的算法了,今天这篇文章再介绍最后一种对称加密算法 — — PBE,这种加密算法,对我的认 ...
- 7.java 加解密技术系列之 AES
java 加解密技术系列之 AES 序 概念 原理 应用 代码实现 结束语 序 这篇文章继续介绍对称加密算法,至于今天的主角,不用说,也是个厉害的角色 — — AES.AES 的出现,就是为了来替代原 ...
- 6. Java 加解密技术系列之 3DES
Java 加解密技术系列之 3DES 序 背景 概念 原理 代码实现 结束语 序 上一篇文章讲的是对称加密算法 — — DES,这篇文章打算在 DES 的基础上,继续多讲一点,也就是 3 重 DES ...
- 5.Java 加解密技术系列之 DES
Java 加解密技术系列之 DES 序 背景 概念 基本原理 主要流程 分组模式 代码实现 结束语 序 前 几篇文章讲的都是单向加密算法,其中涉及到了 BASE64.MD5.SHA.HMAC 等几个比 ...
- 4.Java 加解密技术系列之 HMAC
Java 加解密技术系列之 HMAC 序 背景 正文 代码 结束语 序 上一篇文章中简单的介绍了第二种单向加密算法 — —SHA,同时也给出了 SHA-1 的 Java 代码.有这方面需求的童鞋可以去 ...
随机推荐
- 【2020NOI.AC省选模拟#7】A. t1
题目链接 原题解: 由于$+$满足幂等性,我们可以设$f_{i,j}$为从$i$号点向根$2^j$个点的权值之和,并且倍增计算出$f$.在查询是,可以像ST表一样用至多四个$f$中的路径拼出询问路径. ...
- <四>JMeter数据库连接/后置处理器/断言简介
一.数据库连接 1.右键线程组添加--配置元件--JDB Cconnection Configuration 2.配置如下: URL为数据路连接地址,用户名密码为数据库用户名和密码 3.添加一个JDB ...
- 解决vuex“状态管理声明输错”后报错为:"Uncaught TypeError: __WEBPACK_IMPORTED_MODULE_1_vuex__.a.store is not a constructor"
//Vuex index.js 源码 import Vue from 'vue'; import Vuex from 'vuex'; Vue.use(Vuex); import actions fro ...
- oracle中查询表字段信息及主键字段
select a.owner, a.table_name, a.column_name, a.data_type, d.constraint_type, a.num_nulls from all_ta ...
- java mybatisplus+springboot服务器跨域问题
项目本地增删改测试正常,上传到 阿里服 页面出现了 跨域报错问题! 解决方案:添加一个过滤器 package com.rl;import org.springframework.stereotyp ...
- 写入自定义 ASP.NET Core 中间件
中间件是一种装配到应用管道以处理请求和响应的软件. ASP.NET Core 提供了一组丰富的内置中间件组件,但在某些情况下,你可能需要写入自定义中间件. 备注:本主题介绍如何编写基于约定的中间件. ...
- SQL server——基础篇之数据完整性
定义:保证数据库中的数据在逻辑上的一致性.正确性和可靠性. 作用:防止无效数据或错误数据进入数据库 数据完整性包括:实体完整性.域完整性和参照完整性 实体完整性 规定表的每一行记录在表中是唯一的 实体 ...
- deepin系统编辑pdf文件的两个简单方法(终端命令行模式)
DEEPIN深度系统编辑PDF文件有时竟然超级简单好用,比WINDOWS系统需要单独下载一个PDF编辑软件的方法强多了,而且windows系统PDF编辑软件还有版权限制,各种作啊. 下面的两条命令,使 ...
- PTA1003 我要通过! (20 分)
PTA1003 我要通过! (20 分) "答案正确"是自动判题系统给出的最令人欢喜的回复.本题属于 PAT 的"答案正确"大派送 -- 只要读入的字符串满足下 ...
- pytorch卷积模块
nn.Conv2d() 常用的参数有in_channels,out_channels,kernel_size,stride,padding; 除此之外还有参数dilation,groups,bias ...