心法利器
本栏目主要和大家一起讨论近期自己学习的心得和体会。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。
2023年新的文章合集已经发布，获取方式看这里：又添十万字-CS的陋室2023年文章合集来袭，更有历史文章合集，欢迎下载。
往期回顾
- 心法利器[121] | 读源码：用mT5训练一个自动摘要模型（含代码）
- 心法利器[122] | 效果提升的根本来源讨论
- 心法利器[122] | 算法面试的八股和非八股讨论
- 心法利器[123] | 24年算法思考-大模型的应用与训练篇
- 前沿重器[48-54] 合集：四万字聊搜索系统
因为很多原因，今年应该是我做的算法最杂的一年了，传统NLP、大模型、RAG、机器学习等多个领域*内容基本我都有涉及，同时，很多技术也在今年有了很多革新和进步，因此我想在这里总计一下我的视角下这些算法的情况以及我使用下来的经验感受。具体我就按照下面几个方面来划分，系统总结一下。
- 大模型的应用与训练（心法利器[123] | 24年算法思考-大模型的应用与训练篇）
- RAG技术论文与实践小结
- 传统NLP的生存空间
- 机器学习与特征工程的必要性
- 个人的成长小结
今天是第二篇，主要讨论的是RAG的研究思考以及我的实践小结：
- 我视角下的RAG研究思考
- 个人RAG的实践经验
我视角下的RAG研究思考
先叠个甲，之前RAG看得多是因为自己的兴趣+项目需求，并不代表我有多深入了解这个领域的全貌，仅代表我自己视角下的观点。
从23年末到24年，我写了很多有关RAG方面的文章，从基础的和比较流行热门的RAG技术，到一些应用上的思路选型和使用方法，我都给出了一些自己的理解，在24年3月我也对之前RAG的文章做了总结（心法利器[111] | 近期RAG技术总结和串讲（4w字RAG文章纪念）），并在后续还跟进了很多文章，包括一些比较流行的综述，我先都列举下来。
- 首先是24年3月份的RAG文章小结：心法利器[111] | 近期RAG技术总结和串讲（4w字RAG文章纪念），此前的文章我就不展示了，直接可以在这里面看。
- 心法利器[112] | 考古RAG-20年RAG概念提出的论文
- 前沿重器[44] | Adaptive-RAG:根据难度自适应检索方案
- 心法利器[113] | RAG结构思考：搜索系统范式和大模型作用压缩
- 前沿重器[45] RAG开源项目Qanything源码阅读1-概述+服务
- 前沿重器[46] RAG开源项目Qanything源码阅读2-离线文件处理
- 前沿重器[47] | RAG开源项目Qanything源码阅读3-在线推理
- 前沿重器[48-54] 合集：四万字聊搜索系统
然后RAG的进展，我根据自己的整理展开聊，这里部分观点会参考这篇文章：https://mp.weixin.qq.com/s/wNvH4YSp1Evi\_t4lfX2ycg。
从去年RAG概念重新火起来至今，我从目前看到的论文和工业界开源项目下明显感受到的几个迹象：
- 精细化&模块化
- 遇事不决大模型->小模型试试看
- 卷通用和开源
- 极力推图RAG模型
精细化&模块化
RAG从23年简单一个向量召回+大模型的navie模式升级为现在各种模块组装的Modular RAG，可以说是“亭亭如盖也”，今年下半年感官上发力更猛，出现了各种名头的RAG开源项目，内部可以说是各种功能一应俱全，热闹非凡。
首先先说一下原因，我理解是两点：追上限和提升灵活性。追上线对科研论文而言，争当sota是大趋势，为了进一步提升效果，在某些问题或者是某个细节部分上做进一步的优化的收益是非常高的，宏观上增强搜索和大模型推理的合作（CRAG：前沿重器[43] | 谷歌中科院新文：CRAG-可矫正的检索增强生成），微观上考虑改写、向量模型优化的工作，都是不错的。至于提升灵活性，是对应用而言的，应用场景的多样性，让很多科研界的方案失效，可能只有一些可用的，而结合实际问题，bad case分析等，可以进行针对性解决，为了快速解决这些问题而构造出了插件，能自由选择用还是不用，于是灵活性就体现了。
然后是模块化的趋势，在24年初，就已经初见端倪，在24年早期的综述里就有讲过模块化的事，相信大家对这个图应该挺熟悉的：
图片
模块化后，通过拆解步骤，各自做好各自擅长的事，效果好自然就是水到渠成了，尽管拆解的方式各有不同，在今年内也出了很多新的组件，在7月份，就已经升级成这样了（Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks）：
可以看得出来，一方面模块化内的组件越来越丰富，针对问题有了更多精细化的优化，下面的routing、knowledge-graph也非常潮，另一方面结构和功能也趋向于稳定，已经分为了索引、检索前处理、检索、检索后处理、生成等多个模块，各自在各自的模块下有优化，算是在结构上逐渐迭代收敛了。
另外一个有意思的事，在今年年中的时候我系统总结了一下搜索系统的整体思路（前沿重器[48-54] 合集：四万字聊搜索系统），从上面这个图上看，其实很大程度都有往搜索系统外部架构靠近的趋势，两者异曲同工，因此我还是非常建议大家互相参考借鉴使用的。
这个应该是大趋势，大家的系统内部，应该多多少少需要或者已经孵化出类似的模块了，在调校你的RAG系统时，也要学习在这方面打开思路，别只剩调数据和微调这两个方案了。
遇事不决大模型->小模型试试看
有了COT作为指导思想，我们了解到大模型是需要引导的，而引导这事，毫无疑问就会用大模型来尝尝鲜，于是就有了类似self-rag（前沿重器[42] | self-RAG-大模型决策的典型案例探究）、adaptive（前沿重器[44] | Adaptive-RAG:根据难度自适应检索方案）、crag（前沿重器[43] | 谷歌中科院新文：CRAG-可矫正的检索增强生成）之类的方案出来，除了用于整理答案，还可以用来做结果确认、查询决策等功能，甚至还有尝试用来做精排的工作。
但是经过一段时间的实践，大家逐渐冷静后，挺多人会发现大模型的能力边界，以及在某些问题上，大模型并不那么优秀，甚至比不上一些微调的模型，因此一些部分上大家也开始尝试小模型，例如路由、改写、精排等，小模型的调优代价会更快，也更容易达到上限。在这里，灵活选择合适的方案，是一项非常重要的能力。
卷通用和开源
RAG本身是一个系统，模块化这个事定调后，大家的在应用开发上也就有了比较固定的格式，于是，大家非常喜欢卷开源。最早的langchain里就已经嵌入了RAG的功能，后来有了ragflow（https://github.com/infiniflow/ragflow）、lightrag(https://github.com/HKUDS/LightRAG)、graphrag（https://github.com/microsoft/graphrag）、QAnything（https://github.com/netease-youdao/QAnything）、OmniSearch（https://github.com/Alibaba-NLP/OmniSearch）、Chinese-LangChain（https://github.com/yanqiangmiffy/Chinese-LangChain）等等，里面有些是大厂开源的开箱即用RAG工具，有些是个人练手用的RAG项目。诚然，RAG一般的应用场景是一个系统工程，需要集成出一个完整的系统功能提供整体解决方案，从大量开源项目中都有把文档解析的功能加入进来就能感受到。
因此，非常建议大家多读多看这里的源码，内部的很多操作细节都能让自己收获很大，部分有用的工具甚至可以自己提炼然后保存下来，成为自己的工具库方便使用，这种学习方式能让自己在短时间内有非常大的提升。
这里我推荐最近看到的这篇，里面推荐的开源项目都挺建议大家多看看。（https://mp.weixin.qq.com/s/\_pnezCv-sKmzhho7Xw3D2g）
极力推图RAG模型
图RAG这个事我想单独拿出来聊一下，叠个甲，这里只是我个人视角的发现，没有拉踩，大家谨慎参考。
我理解图RAG这个事大都是因为微软提出graphrag（https://github.com/microsoft/graphrag）概念后才逐渐火起来，于是挺多人会开始去尝试，甚至开始吹捧，后台也有不少小伙伴会问我这方面的事，然而我自己其实并不太建议像舆论热度的那个模式去考虑应用，这里正好集中回应，这里说几个原因。
- 上个版本的图谱能解决的问题，一般的FAQ和文档MRC不是完全解决不了；图RAG能解决的问题，一般RAG同样也不是完全解决不了。图所关注的问题是“关系”，社区也好，知识点关系也罢，核心描述的都是节点和边的关系，是一种知识的结构化方法，诚然图谱能解决很多复杂关系的问题，但是这里的简单关系，一般的FAQ或者MRC模式也已经解决的不错。因此，这里需要回答一个问题：你的场景下有多少需要优化处理“复杂关系”的问题，是否是当下的关键问题。
- 反过来，图谱能解决的问题范围可能不如一般MRC和FAQ。不得不说MRC和FAQ这个模式的泛用性很高，类似检索式对话之类的模式一直在发展且在没大模型之前一直在被使用，例如大家经常说的客服，但是图谱却并不那么好解决，更多情况是，FAQ一定要有，图谱是后面锦上添花的事。
- 图谱的构造有成本，通用图谱的成本很高，还有准召风险。如此看来，至少通用图谱的构造并不是一个性价比高的事。
在这几个原因下，图RAG并不是一个好的首要方案选择，老老实实分析目前的技术现在和用户需求，当“复杂关系”的问题 多了，变成卡点了，再来考虑也不迟。
补充，有些场景大家也是可以考虑的，例如长文档的阅读要求连贯性、多相似知识的比对等，图RAG是可以尝试的。
个人RAG的实践经验
从23年到24年全年，大小项目内都有用到RAG的有关技术，用的多了自然有些自己的理解，当然这里我不聚焦具体的方案了，更多是思路，在这里我都分享一下吧。
- 先完成baseline
- 一定要做case分析
- 扩充知识面，补充更多方案
- 灵活应用，禁止生搬硬套
- 别只把RAG当做一个系统，可以是一个任务的方案
先完成baseline
RAG任务属于系统工程，能很轻易想到未来会面对的问题，而且大概率就会出现，于是就会开始去考虑很多解决方案；另外，目前RAG开源项目琳琅满目，里面也有各种各样的功能，很容易让人挑花眼，但是用起来又会觉得非常冗余，自己的场景可能并不那么能用到，例如各种文档的处理，类型很多但不见得都要用到。
因此，与其花时间在这些想象、挑花眼上花时间，不如先用最简单的方式来把东西做好，然后通过bad case、需求反馈来逐步迭代优化，先考虑把R和G做起来，即关键的检索和生成的流程跑通，即naive rag部分做好，然后再来逐步优化。
由此，我们会发现：
- 很多想象的问题，可能在短期并不会出现，或者并不那么重要。
- 开源框架里的绝大部分功能，我们可能用不上，或者用起来不见得就很好。
- 框架用得太多，因素叠加太多，不好定位重要问题。
- 某些问题，可能弄个并不需要很复杂的操作即可轻松解决。
所以在做rag的时候，尤其是开始，不要一开始就做的很复杂，尽量用最简单的方式先把baseline跑起来。
一定要做case分析
case分析是发现问题的重要来源，很多人都习惯在效果调优上只关注最终的指标，然后开始换模型之类的，这种方式的针对性可能不如从bad case分析中来，类似标注错误、标准没对齐之类的问题，无法从指标上体现，而是要看具体的bad case才能够发现。尤其是带有大模型的项目，真的需要多看，例如最终的输出，可能是大模型错误，也可能有解析的问题，有时候对不上不见得是错误的。
另一方面，针对RAG，因为至少有R和G两个模块，指标只能指出好坏，但是不知道哪里出问题，是检索没查出最文档，还是给了正确文档后大模型的生成不对，这个不去深入分析是肯定不知道的，此时像无头苍蝇式的换，一个迭代节奏慢，一个也不精准。在模块多了以后，例如多了改写，多了意图识别，多了精排，此时还需要分析是哪一步出的问题，哪一步是短板，这对优化方向也非常重要。
因此，我不断在很多文章里强调大家要多看case，看样本，真的非常有用。
扩充知识面，补充更多方案
RAG在现在的研究环境下，涌现了很多优秀的方法，但各个优秀的方案都有各自擅长解决的问题，实验下来并非银弹，而且在使用过程也会发现很多问题，因此多积累的同时深入学习则非常有必要。很多方案其实是个意识的问题，没学过不了解，自然就不会在实践中想到要使用，因此，学习，是非常重要的。
要想系统、概括地学，最简单的方式就是看综述、总结类文章，例如最近比较优秀的这几篇：
- RAG七十二式：2024年度RAG清单：https://mp.weixin.qq.com/s/\_pnezCv-sKmzhho7Xw3D2g
- 2024年RAG：回顾与展望：https://mp.weixin.qq.com/s/wNvH4YSp1Evi\_t4lfX2ycg
- 检索增强生成(RAG)与相关技术综述：问题、分类、数据、模型、挑战：https://mp.weixin.qq.com/s/N\_tSYZrRy7JGjrjAF1G9vA
如果想有针对性地学习，则可以在综述下看到比较好的方案时深入学习甚至自己动手尝试，则能更加精进。
在这一步学习下，自己在实践中会多很多可以打出的牌，而且更有效更有针对性。
别只把RAG当做一个系统，可以是一个任务的方案
这是在24年中期接触的一个项目感受到的，具体的事我就不说了，我就说一个我最近开源的一套利用RAG模式来做文本分类的项目：心法利器[114] | 通用大模型文本分类实践（含代码）。很早之前我就提过以搜代分的方式来做文本分类（心法利器[60] | 以搜代分的生效机理），对类似样本空间比较集中、少样本、高度要求灵活性的分类场景有奇效，而配合大模型的推理能力，能进一步提升以搜代分的效果，此时，不就正好是一个RAG的模式。
当然会有人说，分类问题用大模型压力不小，但是有些常见还是可以，另外还有些预标注的情况也可以考虑，总之我想说的是，RAG本身是一个检索增强的方案，但是他不只能做问答，很多具体的任务也可以考虑尝试，当做一个打开思路的角度吧。
小结
上面总结的更多是我自己在学习和实践RAG中得到的启发和经验，希望对大家有用吧。