东莞专业的单位网站建设,网站开发 价格,济南网络推广网络营销软件,做网站用的文本编辑器心法利器 本栏目主要和大家一起讨论近期自己学习的心得和体会。具体介绍#xff1a;仓颉专项#xff1a;飞机大炮我都会#xff0c;利器心法我还有。 2023年新的文章合集已经发布#xff0c;获取方式看这里#xff1a;又添十万字-CS的陋室2023年文章合集来袭#xff0c;更… 心法利器 本栏目主要和大家一起讨论近期自己学习的心得和体会。具体介绍仓颉专项飞机大炮我都会利器心法我还有。 2023年新的文章合集已经发布获取方式看这里又添十万字-CS的陋室2023年文章合集来袭更有历史文章合集欢迎下载。 往期回顾 心法利器[103] | 大模型bad case修复方案思考心法利器[104] | 基础RAG-向量检索模块含代码心法利器[105] 基础RAG-大模型和中控模块代码含代码心法利器[106] 基础RAG-调优方案心法利器[107] onnx和tensorRT的bert加速方案记录 最近其实挺多文章都有在聊RAG的但我回过头来分析发现缺少一篇有关使用时机的文章。我本身非常喜欢RAG所代表的实践方案但不代表所有情况下都推荐使用RAG毕竟我们需要因地制宜结合实际情况来进行方案选择本文就带大家一起分析RAG的优劣势。 经过调查还是有不少人了解所以我照例还是把最近有关的rag文章放在这里后续我会弄合集 前沿重器[40] | 高级RAG技术——博客阅读前沿重器[41] | 综述-面向大模型的检索增强生成RAG前沿重器[42] | self-RAG-大模型决策的典型案例探究前沿重器[43] | 谷歌中科院新文CRAG-可矫正的检索增强生成心法利器[104] | 基础RAG-向量检索模块含代码心法利器[105] | 基础RAG-大模型和中控模块代码含代码心法利器[106] 基础RAG-调优方案 目录 为什么用微调和RAG对比微调和RAG的优劣势对比技术方案分析案例 为什么用微调和RAG对比 开始可能有小伙伴会问我为什么要拿微调和RAG进行对比我自己的理解主要是因为这个两个所代表的其实是在现实情况中对系统的调优方案即调整模型内和调整模型外。 纵观整个算法领域对模型内部调整不外乎是那几种方案特征变化带来的模型结构调整特征可以是隐式的内部特征也可以是输入端或输出端的显式调整以及通过数据变化带来的内部参数更新。无论是哪种方案都会很大程度地影响模型的预测效果一般情况会为以模型为中心的系统效果带来很大的影响。 模型外的调整不外乎就是增加一些外部的组件例如规则、检索模块等从而让整个系统的效果带来一些变化在全新版本大模型时代大模型为我们提供了更灵活的输入接口即我们可以用prompt的方式灵活指导模型输出可以给参考材料、额外信息、提特别要求甚至是通过描述、样例的方式即可让大模型的输出符合我们预期。 而RAG的出现一方面是因为大模型具有很强的指令生成能力另一方面是模型内调整在现实应用情况一些局限性从而形成了一个目前重要的应用思路实践上最鲜明的两个特点一个是内容批量的可控性和及时性另一个是这种更新并不需要更新模型参数从而规避效果波动的风险。至于规则等的方案某种程度上其实就是RAG的一种特殊情况例如什么情况需要触发什么回复策略的约束。 因此我自己是认为要去权衡RAG不得不把他和微调进行对比探索两者各自的优势进一步在方案选型的时候从感性理解到理性对比判断。 微调和RAG的优劣势对比 这里我写我的分析调研总结过程吧然后汇总结论。 论文讨论 首先是论文层面有一篇论文对这方面进行了讨论“Fine-Tuning or Retrieval?Comparing Knowledge Injection in LLMs”这又是一篇微软的论文怎么最近老是无意间碰到微软的论文频率很高这篇论文本身是从信息注入的角度来进行讨论的从文章的实验看来微调的效果始终比不过RAG的效果而究其原因作者在前文中其实有提到具体的表现摘录一下 领域知识不足。对未接触过的内容效果就会很差。信息过时。知识的更新只取决于训练集的截止时间。记忆力问题对训练过程接触的知识很大可能会忘记说白了就是没学会对已经学会的知识也可能因为后续的训练而遗忘。推理失败。对已有知识可能也会因为使用失败而让回答出现问题。 另外还发现了一篇还不错的论文RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture嗯这篇也是微软的这里面也是做了比较多的实验和尝试给出一些基于实验的分析这篇更像是一篇调研报告挺建议大家回头去精读的我这里把比较重要的这张图摆出来。 这篇相比上面一篇分析的维度更丰富了有考虑成本等问题但论文的分析还是有一定局限性很多情况其实不会考虑到现实情况的很多问题例如数据数量和质量问题实际业务需求等。 社区讨论 有关社区的讨论一般是通过百度谷歌等渠道来检索类似的文章讨论另外知乎、微信搜索也是不错的渠道。我找到的比较好的讨论我都列举出来吧 何时应微调 LLM何时又该使用 RAGhttps://www.zhihu.com/question/638730387如何选择最适合你的LLM优化方法全面微调、PEFT、提示工程和RAG对比分析https://zhuanlan.zhihu.com/p/661830285大模型优化RAG还是微调https://blog.csdn.net/qq_41929396/article/details/132689632RAG与微调—哪个是提升LLM性能的最佳工具https://zhuanlan.zhihu.com/p/679528711专补大模型短板的RAG有哪些新进展这篇综述讲明白了https://www.jiqizhixin.com/articles/2024-01-08-8 这里尽量不要读个一两篇就完事了最好多读几篇能理解的更加全面完整。 汇总结论 这里我分几个方面来进行对比吧。 首先是知识层面这个应该是RAG使用者最关心的。 RAG对知识的更新时间和经济成本更低。不需要训练只需要更新数据库即可。RAG对知识的掌控力会更强相比微调更不用担心学不到或者是遗忘的问题。但是如果模型强缺乏某个领域的知识足量数据的微调才能让模型对该领域有基本的概念如果不具备领域知识基础RAG仍旧无法正确回答。 然后是具体任务效果的问题。 RAG相比微调能更容易获得更好的效果突出的是稳定性、可解释性。有点经验之谈了对任务模式比较简单的任务微调能触碰到更高的上限但是对训练、数据等方面的要求会更苛刻。幻觉方面RAG从各种实测来看短板基本都在检索模块只要检索不出大问题整体效果还是RAG比较有优势的。 第三块来聊成本了现实应用很难避开成本的问题。 训练角度RAG的成本就是更新数据库但是微调就需要大量的显卡、时间资源。推理角度考虑到RAG本身需要检索而且检索层为了确保检索准确还需要很多额外工作所以推理的耗时会比微调多但具体多多少就要看检索模块的复杂程度了如果这里面还需要额外调大模型那成本就会多很多如果只是小模型之类的那这个增加可以说是忽略不计。微调后的大模型直接使用和原本模型的耗时一致。系统拓展角度。随着项目的发展大模型训练不一定能支撑多任务而拿着大模型训好几个对部署而言并不方便。 上面的内容所体现出来的更多是RAG的优势看起来似乎微调就没有什么好处了。但事实并非如此RAG还是有很多不适用的环境的。 RAG依赖知识库。如果不具备构造知识库的条件那RAG无从谈起例如没有具体的业务数据或者是机器不支持支撑检索之类的。业务需求并非对知识依赖。例如某些业务的话术生成更多是对语言风格的约束此时要么通过prompt解决要么就是构造业务数据来进行训练即可根本没有构造RAG的必要。依赖实时信息而非固有信息。直接举例对话摘要应该是大模型具有的比较强的能力这种任务更多是依赖收到的对话记录而非一些固有存储好的内容此时通过工程手段直接把信息获取导入到模型即可不需要把对应内容入库了。如果对对话摘要的内容不满意则应该是通过prompt和微调来解决。当然有人可能会说通过few-shot的方式可以用RAG这个当然是可以的但就不是必须了。指令不生效或者领域知识完全不具备。这个不多解释了大模型此处是短板那即使是RAG把答案摆在面前也解决不了问题。内容会受到检索结果局限。有些创造性的任务本身是想通过大模型获取新的灵感然而检索结果给到大模型后大模型往往容易受到限制这个限制在有些时候是好事但并非所有时候。 技术方案分析案例 借助两个比较典型的案例大家应该能体会这两者的区别了。 产品百科问答 电商场景下客服都要具备一个能力就是产品百科问答用户会需要咨询某些商品的属性等细节消息这是一个很具体的场景了。然而实际我们需要面对的除了这个功能本身还需要解决一个问题即商品信息是需要更新和变化的例如新商品上架、价格优惠修改等这个信息是需要快速反映在问答系统中的此时我们RAG非常有必要性。 商品信息的更新不定期且频繁这种更新通过微调来做敏捷度不足风险也比较高。知识如果是结构化本身用于微调训练并不方便需要转化但是数据库存储则比较方便。商品型号很多很接近容易混淆大模型很容易出现“张冠李戴”现象。 日常工作工具 写周报、灵感、工作日志、修改一份材料、查错查重、话术推荐、会议纪要之类的类似这些问题我们更多的日常使用方式就是prompt大模型完成我们做起来非常自然可能顶多会根据自己的需求加一些例子但往往不会优先考虑RAG。 对固有信息要求不高甚至没有需求。供给检索的数据如果不是因为产品本身的信息收集一般情况下很难获取对RAG而言可以说是无米之炊了。类似灵感的任务案例反而可能限制模型发挥。要求的更多是指令的执行能力这个如果不具备很可能就要考虑通过微调来整了。
