聊聊现阶段RAG 的状况

写在前面

笔者之前从论文和实际工程的角度零零碎碎的介绍了当前RAG 的一些问题和进展。今天，笔者准备从一个一线工程师的角度尽可能全的阐述当前RAG（检索增强生成）的优势和瓶颈。

结合传统搜索引擎对RAG进行理解

各位读者可以脑补一下，平时上网用搜索引擎查资料的过程，输入关键字或者直接输入一个查询句子到搜索引擎中，再根据返回的结果，通过网页的标题和高亮摘要等因素来决定是否点开这个网页进一步阅读。这个过程由粗到细，然后对打开的网页根据人自身的知识水平进行鉴别和理解，选择参考、验证、相信等结果，如果结果符合预期则检索过程结束，反之，浏览下一个网页，或者修改关键字，如此循环，直到找到了结果或者放弃。

而RAG 的作用就是替代人从检索到的网页中进行筛选和理解，生成汇总的信息。从这里我们能发现几个点：

第一：搜索本身的性质并没有改变。也就是说依旧需要一个搜索引擎先行进一步过滤筛选。

第二：人本身具有一定的知识水平，鉴别、理解和接受知识的过程，必然会对自身的知识和理解产生冲突或者补充。替换成模型也是一样，而这也就是RAG 中非常棘手的知识冲突类问题。

模型决定下限，数据决定上限

在结合了搜索引擎对RAG的定位进行了理解后，显然，我们需要先行设计一个搜索引擎，来对用户的查询进行相关知识的检索召回。假如Google搜索引擎开源的话，这无疑是最优的解决方案，然事与愿违，所以我们需要做的工作首先是复刻一个搜索引擎。

传统搜索引擎一般包括以下几个部分，Query分析（包括纠错，切词，词扩展，词权，词紧密度，意图识别等等），召回（包括底层数据清洗，索引构建，召回策略），排序（粗排，精排）。流程复杂，工程量大，并不是所有的企业都愿意去搭建这样一套流程，于是乎就有了很多简易版的实现，比如最常见的chunk方式：

chunk-embedding 方式。对文档D 进行chunk 切分再embedding存入向量库，再通过类似KNN 的方式与用户查询的向量进行相似度计算，返回Top- N，完成召回逻辑。这种办法是实现成本最低的办法，同时也是效果最差的办法。因为实际的业务场景中，数据复杂多样，不是一个chunk 就能hold 住的，于是就有了围绕着chunk 的一系列工作，比如：chunk 上下文扩展，递归chunk 等等，然而收效甚微，因为本质上chunk 的办法只是玩具Demo 性质，而这种demo 性质的方法能产生效果还是得益于大模型时代下embedding 的效果提升。向量化的召回效果会受限于长度这个因素，不同长度原生句子向量化后进行横向比较其本身是存在偏差性的，而这也决定了衍生出的按句chunk 的办法本身的局限性。

接着我们来聊RAG 中的Rerank 策略，在传统搜索引擎中排序策略很重要，因为用户的浏览习惯一般只看前3-5个，所以尽可能的把最相关的排第一，能够给用户带来非常好的体验。

RAG 中的排序有两个含义，第一个指的是混合检索后的融合排序（为了做筛选），这里的难点主要在于多来源，比如调第三方的搜索，自搭的检索，数据库，KB等，不同的召回来源统计分值的计算逻辑不在同一个尺度，从而导致筛选困难。笔者的建议是，在来源的数量不是特别大的情况下，按照不同来源的尺度都进行保留。也就是说，每个来源单独计算统计筛选，最后进行合并。简单的说就是不对源进行过滤，而是对源下的数据进行过滤。而单源下的融合则可以采用 RRF（Reciprocal rank fusion）。

RAG 排序的另一个含义是指模型的 Lost Middle 现象，这个在笔者之前的文章中有介绍过，感兴趣的读者可以去查阅。这个现象的程度取决于模型，通常情况下，只有当上下文足够长时才会出现。而至于“长”的具体值可以参考论文的统计和实际中的测试来结合考虑。另外，很多长上下文模型都会比较看重“大海捞针”的能力，这一块也是一个研究方向，论文也比较多。

接着我们再聊一下数据。首先检索的质量和数据的质量之间存在非常大的关系，而实际项目中，数据类型多样，比如doc, pdf 等，且多为非结构化的情况，这个时候，数据的清洗和结构化就显得尤为重要，通常情况下，如果能够把一个文档的文本按照目录结构进行拆分，再根据拆分后的数据建立多级索引，那么文档的检索效果会很好。另外，从大面上看这个问题，RAG 的出现在某种程度上倒逼文档的结构化工作。

聊到这里，让我们回忆一下整篇文章的内容，召回模块尽可能的把相关的信息检索出来作为参考内容，而模型这一块就是尽可能的从参考信息中挑选，补充，总结出有用的信息，如果模型的能力足够强，那么召回的候选就可以足够多，因为理论上越多的候选，越有可能包括更多有用的参考信息，尤其是在长尾数据上。简单的说，就是模型决定了下限，而数据决定了上限。

从RAG 的角度看模型

笔者在上篇文章介绍了一篇论文有尝试探索过知识冲突类问题的来源和解决方案。大模型本身的训练中并没有学习如何利用不同质量的输入文本。从而导致模型容易被误导或者忽略的情况。

在文章的开头，笔者用传统搜索的例子介绍过模型的角色就是替代人做筛选和总结。从这个角度出发，再去理解知识冲突类的问题，我们应该把模型当作信息的提炼者和补充者，而不是决策者。在出现知识不一致等情况下，模型需要做的就是把差异性进行总结并呈现出来。在这个思路下，对模型进行微调或者预训练阶段进行干预，毕竟在RAG 场景下，我们需要的不是一个决策模型，而是一个汇总模型。

从RAG 的角度看搜索

毫不夸张的说，RAG 是下一代搜索引擎的进化形态。当越来越多的人意识到langchain，llamaindex等一些开源项目中的示例在实际中效果不合理想时，一个专门的，比elasticsearch更高级框架的出现会变得越来越迫切。就跟当年elasticsearch 出现一样，大家不关心你索引内部是倒排还是正排。我们需要的是，虽然我的知识库组成多样，但框架能兼容多种类型，甚至全部类型，我们只需要做文件上传的工作就OK。至于内部RAG 的配置啥的，其实大家并不关心。

写在后面

有读者可能会疑问，既然是从一线工程师的角度看RAG，那么为什么没有介绍设计流程和一些评测方案。我的答案是：一切从数据出发，没有固定的设计方案，也没有固定的评测方案，很多时候一些很简单的配置会比一些看起来很高大上的设计要更有效。