卖货小程序,seo批量建站,中国纪检监察报app下载,外贸网站销售方式前沿重器 栏目主要给大家分享各种大厂、顶会的论文和分享#xff0c;从中抽取关键精华的部分和大家分享#xff0c;和大家一起把握前沿技术。具体介绍#xff1a;仓颉专项#xff1a;飞机大炮我都会#xff0c;利器心法我还有。#xff08;算起来#xff0c;专项启动已经… 前沿重器 栏目主要给大家分享各种大厂、顶会的论文和分享从中抽取关键精华的部分和大家分享和大家一起把握前沿技术。具体介绍仓颉专项飞机大炮我都会利器心法我还有。算起来专项启动已经是20年的事了 2022年的文章合集累积起来有60w字在这CS的陋室60w字原创算法经验分享-2022版。 往期回顾 前沿重器[31] | 理性聊聊ChatGPT前沿重器[32] | 域外意图检测——解决“没见过”的问题前沿重器[33] | 试了试简单的prompt前沿重器[34] | Prompt设计——LLMs落地的版本答案前沿重器[35] | 提示工程和提示构造技巧 在顶会ACL2023上陈丹琦老师团队带来了一份长达近4小时的tutorialRetrieval-based Language Models and Applications内容非常丰富而且具有很强的使用价值本文主要总结一下这篇文章的内容并附带一些自己的理解和思考。 开始之前先把关键的参考资料给出 官方材料https://acl2023-retrieval-lm.github.io/PPT和阅读材料都给到。还不错的解读文章https://blog.csdn.net/qq_27590277/article/details/132399887 简介 简介章节讲的是比较基础的主要介绍了本次要介绍的概念即检索Retrieval和大语言模型LLM 简单的说其实就是通过检索的模式为大语言模型的生成提供帮助从而使之生成更符合要求的结果听起来其实就和最近比较火的另一个概念——检索增强生成RAGretrieval 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检索的场景我们需要知道的是有哪些优势场景在本文中作者总结了如下使用场景 28a54b52777965aa47928db679e52f9c.png 第一行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我自己感觉其实是一回事很难感受出区别如果有大佬了解的欢迎在评论区指点下感谢感谢。