总有人喊RAG已死，至少看目前不现实。

     持这个观点的人，大多是Long context派，老实说，这派人绝大多数不甚理解长上下文的技术实现点，就觉得反正context越长，越牛B，有点饭圈化，当然我并不否认长上下文对提升理解力的一些帮助，就是没大家想的那么牛B而已（说个数据，达到128K以上的语料数据，不到百分之5。尤其是对齐数据，这边更甚，不到总对齐训练语料的百分之2.5,大家自己琢磨一下）。

      我这也是因为想写这个，才想起来，之前写过一个系列，还没写完，后面我会补齐的。

       RAG能干啥也这个就不用特意解释，就是给整个LLM系统，它其实也干不了别的。

•        加没有的数据，尤其是实时性。

•        减少幻觉

       但是这两项还是很有用的，但是大家实际用起来吐槽很多，因为没那么好用，从难用的角度上说RAG已死，没什么毛病。

       吐槽的主要原因是经常提出的问题和你的答案库里匹配度不高，大多数RAG的基本原理就是余弦距离匹配，计算出来的东西余弦距离最高的，还真不一定是正确答案。

      改进1，加BM25做关键字查找，作为补充，这个问题是查的慢，但是多少能提升一些准确性

      改进2，加知识图谱，其实和BM25实现不一样，解决问题的思路都一样

      改进3，把前面这些所有的东西加一起，然后rerank个答案的排序。能进一步提升准确性。

     那么现在的问题是，假如你的文档信息里就没有这种问题的答案呢？

     我举个例子，其实这个在我另一个系列最后有写，小周夜话第一期之负样本和RAG优化 (qq.com)我在这里在描述一下。

     比如你一个"公司HR定义的休假"文档被拆开（这里我们预先认为你拆文档，相对比较合理，每个chunk的内容比较语义精准和单一，而且和上下文，子chunk，父chunk都做好了link，这是最基本的，这块要是没做好，就谈不到今天后面谈的问题），其中一块的内容是产假。

     咱们国家以北京为例规定女的产假158天，男职工应该是15天，然后这文档上就有女职工产假158天，没写男职工，写的是配偶在我司，可以休假多少天陪产假，配偶不在我司可以休多少天陪产假。

     小张是一个男同事，比如他要休陪产假，直接一问“男职工能休几天产假”（你不可能指着每个做业务的人都要学会prompt engieering），然后系统调出它的性别，输入到RAG系统里，很可能你碰上的模型再次一点（过于浅层推理），就完全给不出想要的答案，比如回答“女的能休产假，男的休不了。”

      一个简单的解决办法是，通过预生成QA对，来搞这个事情，因为问题和答案的相似性，永远不可能比问题和问题的相似性高，因为余弦的作用机制，所以我们把每个chunk，通过prompt engineer让GPT预先生成了一堆针对这个chunk提出的问题，然后做2级查找结构，比如刚才的那个场景，我们在生成QA对的时候，就有可能被GPT的深层推理，推出来其中一个Q是"男职工的陪产假有多少天"

      这个解决办法是最简单的，但是它存在一个问题，就是由于Q变多和2级查找的原因，会让你的查询变慢，另外一个也很依仗你生成QA对的运气，你要倒霉正好没生成合适的Q，那也没办法。

      现在解决问题的思路，其实我们定义为Agentic RAG

      什么叫Agentic RAG，就是由Agent驱使的RAG系统。

      一个最朴素的Agentic RAG的实现深层推理

      比如你直接问RAG系统，海湾战争期间最火的音乐是什么？这一般RA没个回答，回答也是骂你，或者不想干的回答，如果你的余弦相似度设置太宽泛。

     就这种特别抽象的问题，其实大模型也没法很好的回答，比如

      实际上海湾战争是90年8月到91年2月的，Right here waiting是1989年的歌曲，91年，全美50张top专辑，这种歌怎么可能排得上号，而且年份也不对（为了方便我就没统计90年的专辑）

      BTW（我其实也纠结是枪花还是涅槃最强...，而且那时候还有MJ的dangerous...）

      但是如果我们做一个Agentic的RAG系统就不一样了

     如上图所示，Agent充当代理，可以很好的拆解不合理和不常见的问题，然后转变成逻辑单一的问题，最后由RAG正确的回答到用户，当然因为是Agentic化了，所以如果RAG完全解决不了的问题也可以由搜索引擎来回答。

     现在市面上实现Agentic化的RAG能部署的其实很多了，而且逻辑上比我讲的要复杂很多。这里就讲一个被很多企业部署了的Langraph，这个可以直接拿来用

   Langraph现在提供了3种比较成熟的Agentic或者类Agentic的RAG方案，各有各的好处，也可以混成chain来用，我们来简单介绍一下。

 1- SELF-RAG  

  论文地址：2310.11511 (arxiv.org)

      Self-RAG其实是Self-reflecive的缩写，就是自反思，最近比较火的吴恩达的项目，其实也是利用Agent的反思机制来不断矫正翻译的准确性，两者道理是一样的。比如左边按传统的K个rag答案然后拼凑，很显然红色部分和Prompt是没啥关系的，也是和原始信息有冲突。

      如果用Self-RAG来做，Self-RAG会把prompt+1,2,3，（比如K=3）这些prompt+completion，一起送给LLM，让LLM判断相关性,很显然答案相关性很差，然后LLM会不断的对答案进行排序，优化，最终输出最合理的答案。

      另外，Self-RAG其实本身也有对问题的判断的路由，比如说我夏天最好的假期这种问题，那就不要进rag了，直接LLM来帮着写，也节省了很多不必要的流程（问RAG也没用）

2- Corrective-RAG，又叫fall-back

论文地址：2401.15884 (arxiv.org)

       其实和Self-RAG有相似的地方，就是LLM去判断RAG系统给我的东西相关不，如果先关，那RAG要被优先选择，毕竟是黑纸白字，如果相关性判断不合适，那么就要启动外部搜索，在生成的时候，会对各个渠道获得的信息进行排序，比如优先RAG系统的，和Ambiguous的（就是模棱两可的）最后在加上外部的。

      并且，它还做得更细了。在每个大项内部，可以把获得的多个文件，进一步decompose，比如RAG系统获得了两个相关的文件，但是它可以把文件进一步解耦到strip的小级别，然后继续判断strip的和prompt的相关性，最后就留下游泳的strip，无关的strip都干掉，然后相关的strips合成一个答案，比如Kin,Kex的部分，关于外部搜索也是一样的道理。

      3- Adaptive-RAG， 又叫routing

  论文地址：2403.14403 (arxiv.org)

    上图对比了一下，单步apporach的rag和多步的优劣，其实没有优劣就看哪个合适，比如简单的query，它就最合适单步的approach，因为响应快，比如复杂的，那肯定得多步才能整明白。

    Adaptive-RAG就干这事的，就是来做个分类器，你的prompt到底适合单步还是多步approach，简单说就干这个的。

      好了，我们现在介绍完了这3个东西都干嘛的，Langraph做个整合把这三个东西融会贯通都进整个的端到端流程里面，最终能做到，选择合适的方（rag/搜索），然后剔除答案中的幻觉。

        反正开箱即用，我就给大家理顺一下思路和逻辑，这里也不演示了，大家下去自己去测试吧