Prompt-NLP新范式

Posted 2023-05-05

参考技术A

NLP技术发展的四种范式：

Prompt的起源可以追溯到GPT-2，T5，GPT-3等的一些研究，发现在输入样本前加入一个和任务相关的 前缀 ，就可以提示模型接下来要输出的内容。比如在GPT-3的预测阶段，只需要在输入样本前加上Translate English to French: 就可以提示模型接下来要进行翻译任务，即完全依靠模型在预训练阶段学到的知识来进行预测，不需要在下游任务上再依靠task-specific的 监督数据 对模型进行fine-tune就可直接使用，一方面减少了fine-tune模型的计算和存储代价，另一方面也给样本量极度缺乏的 少样本领域(zero/few-shot) 带来了福音。

这种依靠 提示信息(Prompt) 来激发模型的内在潜能，挖掘模型在大规模预训练阶段学到的知识的做法引领了NLP领域的第四范式。人们逐渐开始思考如何更加 高效地利用 预训练语言模型的大量参数，如何将各种下游任务都统一到一个 通用框架 下，使得模型能够根据不同的提示信息进行不同的任务，从而不需要再为每个下游任务训练单独的模型。

本文将对Prompt快速发展过程中一些重要论文的核心创新点进行简要介绍，而不会详细描述过多模型细节（欲知全貌建议直接读原论文）。

论文：Exploiting Cloze Questions for Few Shot Text Classification and Natural Language Inference (2020)

该论文对Prompt模式的研究进行了规范，提出了 Pattern-Verbalizer 的概念：

比如对于5分类任务，给定输入样本 a ，对应的模板函数 P 和标签映射函数 v 可为：

注意这里多种Prompt模板函数以及答案映射函数都是 人工手动设计 的。
然后利用新构建出来的 P(x)，v(l) 对预训练模型进行fine-tune，其他更多细节不再展开，实验结果显示该方法在少样本任务上表现很好。

论文：It’s Not Just Size That Matters: Small Language Models Are Also Few-Shot Learners （ PET原班人马 ）

GPT-3出来后显示了其在少样本学习上的惊人能力，但是其庞大的参数量也令人望而却步。而本文作者提出 “小模型在少样本学习上也可以有卓越表现” ，直接对标GPT-3这个庞然大物，从而奠定了 PET所提范式 在江湖的霸主地位，引起了各大武林人士的关注。

该文证明了PET所提范式的有效性，同时作者还分析发现设计不同的 Prompt 模板和标签映射函数 Verbalizer 对模型性能影响较大，从而引起后来人员涌入改进Prompt模板和标签映射Verbalizer构造的浪潮中。

论文：Making Pre-trained Language Models Better Few-shot Learners

取代PET中手动构建Prompt模板和标签映射函数的过程，自动化搜索模板和标签映射，同时参考GPT-3中的in-context learning，在输入样本中加入示例(demonstrations)作为上下文，帮助模型更好地理解要做什么。

实验表明，在少样本上，这种基于prompt的fine-tune效果能够明显好于标准的fine-tune，并且在样本中加入示例确实能够带来增益。

也许未必非要构建人能理解的 离散tokens式 的Prompt，构建模型能够接受的 连续向量式 的Prompt也未尝不可。

4.1 论文： Prefix-Tuning : Optimizing Continuous Prompts for Generation

该文针对 NLG(Natural Language Generation) 任务，提出了构建连续的prompts。在预训练模型的每一层加上一个Prefix前缀矩阵，固定预训练模型的参数，仅训练前缀矩阵的参数，在few-shot设定下，性能超过标准的fine-tune。

实验结果表明，在 全量 数据下，prompt-based fine-tune的效果能够 相当 standard fine-tune；在 少样本 下，能够 超过 standard fine-tune。

4.2 论文：GPT Understands, Too ( P-tuning )

该文针对 NLU(Natural Language Understanding) 任务，也提出了构建连续的prompts。与 Prefix-tuning 不同的是，这里的prompts仅需要加在输入层，而不用加在网络的每一层，就可以work well。

利用 biLSTM 对prompts进行 Encode ，然后将编码后的 prompts embedding 和样本 x 输入预训练语言模型(PLM)，之后同时fine-tune prompt embeddings 和 pretrained model 。

考虑到优化连续的prompt向量有两个问题：

因此作者提出先采用 biLSTM 作为 Prompt Encoder 来编码prompt向量。

具体Prompt模板设计为：

实验结果表明，在 全量 数据下，prompt-based fine-tune的效果能够 相当 或超过standard fine-tune。

论文：The Power of Scale for Parameter-Efficient Prompt Tuning

该文提出为每个下游任务设计自己的prompt，拼接到输入样本上，然后完全freeze预训练模型的权重，仅训练prompts对应的权重参数。发现随着模型体积的增大， Prompt-tuning 的效果逐渐追上标准 fine-tune 的效果。

这里 Model Tuning 就是指标准的 fine-tune ，即在下游任务上对预训练模型的参数进行更新。

最后对各论文实验结果的普遍规律进行一个总结。各论文采用的fine-tune策略主要有以下三种：

uSID：SRv6新范式

摘要：本文介绍最新的SRv6创新uSID（Micro Segment）。uSID兼容既有的SRv6框架，将极大地改变SRv6的设计、实现和部署方式，成为SRv6的新范式。

111111111111111

一、SRv6 101

Segment Routing（以下简称SR）指由思科院士Clarence Filsfils发明，并主要由IETF SPRING（Source Packet Routing In Networking）工作组进行标准化的新一代网络传送技术。SR基于源路由并且只在网络边缘维持状态，这使得SR非常适合于超大规模SDN部署，现已成为支持5G、物联网、多云、微服务发展的标准网络传送技术。

Clarence在发明SR的第一天，就为SR数据平面设计了两种实现方式（详见RFC 8402）：一种是SR-MPLS，其重用了MPLS数据平面，可以在现有IP/MPLS网络上增量部署；另一种是SRv6，使用IPv6数据平面，基于IPv6路由扩展头进行扩展（SRv6报头格式详见IETF草案draft-ietf-6man-segment-routing-header-21），可以在现有IPv6网络上增量部署。

如果说SR-MPLS可以简单地认为是“下一代MPLS”的话，那么SRv6则是代表了全新的思考、设计、运营网络的方式?——网络即计算机（详见IETF草案draft-ietf-spring-srv6-network-programming-01）。下图是笔者经常使用的一张类比示意图：

222222222222
图1 网络即计算机-X86架构vs SRv6架构
图中左侧是大家熟悉的X86体系，程序最终是通过X86的CPU指令来操控服务器；右侧是SRv6体系，SDN通过SRv6 Segment来操控网络。
与X86 CPU指令是固定的不同，SRv6 Segment指令是可以任意扩充的（我们建议把新的Segment指令提交IETF进行标准化，但私有的Segment指令也是允许的），这赋予了SRv6极高的灵活性和极强的可扩展性。
目前多个IETF草案定义了多种SRv6 Segment指令，包括Underlay的Segment(转发、TE)，也包括Overlay的Segment(L2/L3 ×××)，还包括服务编程的Segment(服务链)以及用于5G移动核心网用户面的Segment等。可以看出，SRv6早已超出了Underlay的范畴，朝着全功能、网络级指令集演进。
还需要强调的是，SRv6实现了网络极简：控制平面是支持IPv6的IGP/BGP，转发平面则是纯IPv6。“简单即力量”，SRv6无疑在降低OPEX/CAPEX方面有着非常好的前景。
SRv6极简和可编程两大特性得到了业界的广泛认可。事实上，SRv6的生态系统发展的很快，如下图所示：

3333333333333333333
图2 SRv6生态系统
但SRv6在实际网络中的部署却很少，部署的业务也只是尽力而为的L3××× over SRv6，没有SRv6流量工程，更没有服务链这类高级功能。与之相对的是，随着Linux/VPP/智能网卡对SRv6的支持，SRv6在主机侧的应用和创新则是蓬勃发展（详见本文作者发表的Linux SRv6系列文章）。

SRv6在网络侧和主机侧呈现完全不同的情况，原因是什么？如何加速网络侧的SRv6部署？网络侧SRv6与主机侧SRv6如何整合/联动从而实现“网络即计算机”的愿景？

二、SRv6的阿喀琉斯之踵

前面谈到了SRv6在网络侧和主机侧呈现出完全不同的发展速度，根本原因是两者在查找和转发机制上存在根本的差异。

网络侧：ASIC/NPU收到数据包后，把数据包存在外置的内存中。ASIC/NPU读取固定长度的报头内容（一般是96~128字节），然后查找芯片本地/外部内存中的转发表，进行转发。如果报文头太长，无法在一个处理周期完成读取，则需要使用两个处理周期进行读取（Recycle），这将导致吞吐量下降一半。
主机侧：CPU读取完整的（一组）数据包，查找路由表/缓存，进行转发。因此报文头的长度对主机的吞吐不会有太大的影响，当然代价就是吞吐量远低于ASIC/NPU。
在SR-MPLS下，协议引入的开销较小，因此现有的大多数网络设备硬件均可以在一个处理周期内读取完SR报头信息，完成转发，意味着现有的硬件无须替换，只需升级软件即可支持SR-MPLS。这是SR-MPLS能迅速得到大量部署的技术基础之一。

但SRv6引入的协议开销远大于SR-MPLS[1] ，Segment所对应的操作也比SR-MPLS复杂，因此SRv6对网络设备提出了非常高的要求。如果按照目前的SRv6协议实现，要么需要替换掉绝大多数的网络设备，要么网络吞吐降低一半（Recycle），这对于很多用户而言是难以接受的。毕竟SRv6虽好，但如果其前期门槛是如此高的话，网络业界都会踌躇不前；缺乏网络侧SRv6(Underlay)的支持，主机侧（APP/Overlay）的SRv6创新也难以大规模部署，因为无法确保端到端的用户体验——这成为了SRv6的阿喀琉斯之踵。

下面我们通过一个例子来具体分析SR-MPLS和SRv6在协议开销、承载效率、MTU和对硬件芯片要求等方面的异同。假设净荷是IPv4报文，净荷长度是IMIX 440B，需要经过具有5个Segment的路径转发数据包。

44444444444444444444
表1 SR-MPLS vs SRv6
从上表可以看出，SRv6在网络可编程性和负载均衡方面有着巨大的优势，但要发挥其优势，需要迫切解决SRv6在协议开销、承载效率、MTU和对硬件要求方面的问题。这几个问题，其实本质上都是同一个问题：如何提高SRv6 Segment效率？

三、uSID原理是什么呢？