前沿重器
栏目主要给大家分享各种大厂、顶会的论文和分享,从中抽取关键精华的部分和大家分享,和大家一起把握前沿技术。具体介绍:仓颉专项:飞机大炮我都会,利器心法我还有。(算起来,专项启动已经是20年的事了!)
2022年的文章合集,累积起来有60w字,在这:CS的陋室60w字原创算法经验分享-2022版。
往期回顾
前沿重器[31] | 理性聊聊ChatGPT
前沿重器[32] | 域外意图检测——解决“没见过”的问题
前沿重器[33] | 试了试简单的prompt
前沿重器[34] | Prompt设计——LLMs落地的版本答案
前沿重器[35] | 提示工程和提示构造技巧
在顶会ACL2023上,陈丹琦老师团队带来了一份长达近4小时的tutorial:Retrieval-based Language Models and Applications,内容非常丰富而且具有很强的使用价值,本文主要总结一下这篇文章的内容,并附带一些自己的理解和思考。
开始之前,先把关键的参考资料给出:
官方材料:https://acl2023-retrieval-lm.github.io/,PPT和阅读材料都给到。
还不错的解读文章:https://blog.csdn.net/qq_27590277/article/details/132399887
简介
简介章节讲的是比较基础的,主要介绍了本次要介绍的概念,即检索(Retrieval)和大语言模型(LLM):
简单的说,其实就是通过检索的模式,为大语言模型的生成提供帮助,从而使之生成更符合要求的结果,听起来,其实就和最近比较火的另一个概念——检索增强生成(RAG,retrieval augment generation),在我的理解下,就是一件事。
众所周知,LLM其实已经在很多领域和问题下都取得了很好的效果,那为何还需要依赖检索做进一步优化,在本文看来,主要有5个原因:
LLM无法记住所有知识,尤其是长尾的。受限于训练数据、现有的学习方式,对长尾知识的接受能力并不是很高。
LLM的知识容易过时,而且不好更新。只是通过微调,模型的接受能力其实并不高而且很慢,甚至有丢失原有知识的风险。
LLM的输出难以解释和验证。一方面最终的输出的内容黑盒且不可控,另一方面最终的结果输出可能会受到幻觉之类的问题的干扰。
LLM容易泄露隐私训练数据。用用户个人信息训练模型,会让模型可以通过诱导泄露用户的隐私。
LLM的规模大,训练和运行的成本都很大。
而上面的问题,都可以通过数据库检索快速解决:
数据库对数据的存储和更新是稳定的,不像模型会存在学不会的风险。
数据库的数据更新可以做得很敏捷,增删改查可解释,而且对原有的知识不会有影响。
数据库的内容是明确、结构化的,加上模型本身的理解能力,一般而言数据库中的内容以及检索算法不出错,大模型的输出出错的可能就大大降低。
知识库中存储用户数据,为用户隐私数据的管控带来很大的便利,而且可控、稳定、准确。
数据库维护起来,可以降低大模型的训练成本,毕竟新知识存储在数据库即可,不用频繁更新模型,尤其是不用因为知识的更新而训练模型。
问题定义
首先,按照文章的定义:
A language model (LM) that uses an external datastore at test time。
关键词两个:语言模型和数据库。
语言模型这块,我们其实都熟悉了,早些年以bert代表的模型,到现在被大量采用的大模型,其实结构都具有很大的相似性,而且已经相对成熟,模型结构这事就不赘述了。更为重要的是,prompt受到关注的这件事,在现在的视角看来是非常关键的发现,prompt能让大模型能完成更多任务,通过引导能让模型解决不同的问题,同时,效果还是不错,在现在的应用下,prompt精调已经成为了经济高效的调优手段了。
至于数据库,配合大模型,构造成如下的推理结构:
datastore是数据源,构造成索引后,可以接受query进行检索,检索结果和大模型配合,就能输出结果。
架构
此时,就出现一个问题,大模型和检索查询之间的关系是什么,拆解下来,就是这几个问题:
查什么:query如何构造以及检索的。
如何使用查询:查询结果出来后如何跟大模型协同。
何时查:什么时候触发查询,或者换个说法,如何构造查询query。
section3中,通过论文讲解的方式,讨论了多篇论文在解决上述3个问题下的解决方案,并且讨论了他们的优缺点。
这里总结一些关键要点给大家,让大家理解这些检索策略的不一样会有什么优缺点:
检索不一定检索一次,可以切句,例如机械地n个token地切后查询,会比只查一次要强一些。
RETRO中构造了临时层对检索结果进行解析,提升检索结果的理解和使用能力,但这也意味着这些层需要进行训练后才可使用,训练成本是增加的。
KNN-LM在检索上,从词降级为token,能对低频或域外(out of domain)数据有很好的支持,但存储空间会变大很多,同时该方法缺少输入和检索结果的交互信息。
后续的FLARE和Adaptive-LM采用了自适应检索的方式,能提升检索的效率,但当然与之对应的检索策略并不一定是最优的(误差叠加)。
Entities as Experts直接检索实体,能提升效率,但这个位置是需要额外的实体识别的。
训练
在LLM-Retrieval的框架下,训练除了为了更好地让LLM做好推理预测,还需要尽可能让LLM和检索模块协同,而显然,同时训练LLM和检索模块的模型,无疑是成本巨大的,就这个背景,文章总结了4种LLM和检索模块的更新策略。(注意,此处我把training翻译为更新)
首先是独立更新(Independent training),即两者各自更新,互不影响。这个应该是目前我看到最常见的一种方式了。
优点:对频繁更新的索引,大模型不需要频繁更新,甚至不需要更新;每个模块可以独立优化。
缺点:大模型和检索模型两者之间并无协同。
然后是依次训练(Sequential training),即训练其中一个的时候,另一个固定,等此模块训练完训练完以后再训另一个。
优点:和独立更新有相似点,大模型不需要频繁更新,甚至不需要更新;不同的是,大模型可以进行适配检索模块的训练,反之亦然。
缺点:因为是依次训练,所以在训练其中一个时,另一个是固定的,不能做到比较彻底的协同,而且大模型更新的频率不见得跟得上索引库的更新,如果紧跟,成本会变高。
第三种是异步索引更新下的联合训练,即允许索引过时,定期更新即可。这种方式的难点是需要权衡,索引更新的频率是多少,太多了则训练成本昂贵,太少了则索引过时,导致有些问题会出错。
第四种也是联合训练,但考虑到更新索引的频次问题,所以索引通过批次的方式来更新,当然了,这种方式的同样会带来成本的问题,无论是训练阶段,还是索引更新阶段。
总结一下,有关训练阶段,两者协同,有如下优缺点。
应用
应用这块,通过这几个月我们的深入使用,大模型给了我们很多的使用空间,到了LLM+检索的场景,我们需要知道的是有哪些优势场景,在本文中,作者总结了如下使用场景:
第一行3个任务主要优势表现在知识密集型的任务中,中间和下面的6个则是比较经典的NLP任务了,中间3个偏向生成,后面3个倾向于分类,此时,我们需要回答两个问题:
如何把LLM+检索这个模式应用在这些任务中?
使用LLM+检索这个模式的时机是什么?
首先是第一个问题,如何应用,这里给出了3种使用方法,分别是微调、强化学习和prompt。我们日常使用的更多的可能是prompt,但是从一些实战经验上,可能还有别的模式可能能让模型更好地利用。
微调方面,只要把整个流程串起来其实就能发现,是完全可行的,ATLAS这篇论文比较典型,再处理知识库的更新上选择了相对独立的策略,从实验来看,效果还是不错的,作者的评价是这样的:
微调能为知识密集型任务提供很大的提升。
对检索库本身的微调也十分重要。
而强化学习,也算是最近比较热门的研究方向了,RLHF能把全流程串起来,有人工的评价能为结果带来更多的提升,作者用的是“alignment”,是对齐用户的偏好,然而实际上,这种人工的数据其实还是比较难获得并使用的。
在prompt这块,作者首先提出一个问题:“What if we cannot train LMs for downstream tasks?”,这个问题很现实,因为很多原因,我们可能没法训练模型,只能用开源的或者是固定通用的模型(心法利器[102] | 大模型落地应用架构的一种模式),此时,prompt就是一个非常好用的方案了。从结果层面显示,这种方案可以说是非常“effective”,同时作者还提及不用训练和并不差的效果(用的strong),但缺点也比较明显,可控性还是不够,相比微调的效果还是要差点。
然后,下一个问题,就是使用检索这个模式的时机了。说到时机,其实回归到前面所提到的原因就知道了,即长尾知识、知识过时、内容难验证、隐私问题和训练成本问题,经过作者的整理,从使用检索的原因,转为提及检索这个模式的优势,则是6点:长尾知识、知识更新能力、内容可验证性、参数效率、隐私以及域外知识的适配性(可迁移性)。
多模态
多模态是让自然语言处理超越文字本身的窗口了,知识的形式是丰富多样的,可以是文章、图谱、图片、视频、音频等,如果能把多种信息进行解析,那对知识的支撑能力无疑是新的提升(毕竟不是所有信息都通过文字传播),在这章,更多是给了很多知识应用的思路,论文还不少,此处不赘述,大家可以去PPT里面钱问题记得网站上面找参考文献。
挑战和展望
总算到了挑战和展望,本章在总结前文的基础上,提出了很多新的问题,研究者们可以参考作为新的研究方向。
首先是基于检索的LLM的规模,第一个问题是小模型+大数据库,是否能约等于一个大模型,
小模型+大数据库,是否能约等于一个大模型?两者在规模上的关系是什么样的。
两者的缩放规则是什么样的,当知识库能支撑知识层面的需求后,语言模型的参数量、token量对结果有什么影响。
检索效率问题,一个是速度,另一个是空间。
第二个问题是,需要探索其应用。
开放式文本生成下,基于检索的大模型在蕴含和推理能力上还有局限性,毕竟光靠相似度的检索不太够,同时知识库大了以后,面对相似但是困难的知识点也会对推理造成干扰。
对于复杂的推理任务,有没有更好的潜在方案可探索,例如多次检索、query改写等策略。
再然后,是一些开放的问题:
基于检索的LLMs下最优的结构和训练策略是什么样的。
对模型的规模,我们无法比较好地去拓展和提升,尤其在具有检索能力支持的情况下。
下游任务上,需要更多更好的解码、推理等方案,甚至是自适应的。
小结
这篇文章写了挺久的,可以说是大开眼界吧,里面的论文看了不少,收获还是挺大的,让我知道有关检索-LLM这个模式下有那么多前人尝试过的玩法,后面有些我应该也会去尝试,看看提升如何。
补充一下,有关RAG和这个Retrieval-based LLM,我自己感觉其实是一回事,很难感受出区别,如果有大佬了解的,欢迎在评论区指点下,感谢感谢。