在人工智能领域，大模型RAG技术（Retrieval-Augmented Generation）已成为近年来研究的热点。它结合了检索和生成两大关键技术，为自然语言处理任务带来了革命性的进步。本文将带领大家深入了解大模型RAG技术的全流程，让你轻松掌握这一前沿技术。

一、RAG技术概述

RAG技术，即检索增强生成技术，是一种将检索和生成相结合的自然语言处理技术。它利用大规模的语料库进行信息检索，为生成过程提供丰富的背景知识和上下文信息，从而提高生成结果的准确性和多样性。RAG技术广泛应用于文本生成、对话系统、问答系统等领域。

二、RAG技术工作流程

1. 预处理：首先，对大规模的语料库进行预处理，包括分词、去除停用词、构建词汇表等步骤。这些预处理操作有助于提取出文本中的有效信息，为后续的检索和生成过程奠定基础。

2. 检索：在生成过程中，RAG技术会根据当前的上下文信息，在语料库中检索相关的文本片段。这个检索过程通常基于某种相似度度量方法，如余弦相似度、TF-IDF等。检索结果将作为生成过程的参考和补充。

3. 生成：在得到检索结果后，RAG技术会利用生成模型（如Transformer、GPT等）来生成新的文本。生成过程会综合考虑当前的上下文信息、检索结果以及生成模型自身的知识库，从而生成更加准确、多样的文本。

4. 后处理：最后，对生成的文本进行后处理，包括去除重复、修正语法错误等步骤。这些后处理操作有助于提高生成结果的质量。

RAG架构

下面我们来了解一下RAG，它有非常多的组件，但是我们可以化繁为简。我喜欢把RAG——Retrieval Augmented Generation理解为Retrieval And Generation，也就是检索与生成，在加上一个数据向量和索引的工作，我们对RAG就可以总概方式地理解为“索引、检索和生成”。

以下就是RAG的主要组成，依次是数据提取——embedding（向量化）——创建索引——检索——自动排序（Rerank）——LLM归纳生成。当然这里少了使用环节，我们暂时先忽略用户提问的环节。

RAG技术细节概览

在技术细节上，我们还可以分成更细的组成。

一、数据索引

• 数据提取

  • 数据清洗：包括数据Loader，提取PDF、word、markdown以及数据库和API等；
  • 数据处理：包括数据格式处理，不可识别内容的剔除，压缩和格式化等；
  • 元数据提取：提取文件名、时间、章节title、图片alt等信息，非常关键。

• 分块（Chunking）

  • 固定大小的分块方式：一般是256/512个tokens，取决于embedding模型的情况。但是这种方式的弊端是会损失很多语义，比如“我们今天晚上应该去吃个大餐庆祝一下”，很有可能就会被分在两个chunk里面——“我们今天晚上应该”、“去吃个大餐庆祝一下”。这样对于检索是非常不友好的，解决方法是增加冗余量，比如512tokens的，实际保存480tokens，一头一尾去保存相邻的chunk头尾的tokens内容；
  • 基于意图的分块方式：
    • 句分割：最简单的是通过句号和换行来做切分。当然也有通过专业的意图包来切分的，常用的意图包有基于NLP的NLTK和spaCy；
    • 递归分割：通过分治的方法，用递归切分到最小单元的一种方式；
    • 特殊分割：还有很多不常见的，用于特殊场景，这里就不提了。
  • 影响分块策略的因素：
    • 取决于你的索引类型，包括文本类型和长度，文章和微博推文的分块方式就会很不同；
    • 取决于你的模型类型：你使用什么LLM也会有不同，因为ChatGLM、ChatGPT和Claude.ai等的tokens限制长度不一样，会影响你分块的尺寸；
    • 取决于问答的文本的长度和复杂度：最好问答的文本长度和你分块的尺寸差不多，这样会对检索效率更友好；
    • 应用类型：你的RAG的应用是检索、问答和摘要等，都会对分块策略有不同的影响。

• 向量化（embedding）：这是将文本、图像、音频和视频等转化为向量矩阵的过程，也就是变成计算机可以理解的格式，embedding模型的好坏会直接影响到后面检索的质量，特别是相关度。关于embedding大家可以看我之前的一篇文章《大模型应用中大部分人真正需要去关心的核心——Embedding》，一般我们现在可以选择的embedding模型有这些：

  • BGE：这是国人开发的中文embedding模型，在HuggingFace的MTEB（海量文本Embedding基准）上排名前2，实力强劲；
  • M3E：也是国人开发的中文embedding模型，我们之前用的就是这个模型，总体来说也算可以，这个还看大家的使用场景，也许你的场景会比我们更加适用；
  • 通义千问的embedding模型：因为是1500+维的模型，所以我们在国庆节后准备用用看；
  • Text-embedding-ada-002：这是OpenAI的embedding模型，1536维，我感觉上应该是目前最好的模型，但是它在MTEB上排名好像只有第六，但是国内应该也不太能用，所以我们就放弃了；
  • 自己训练embedding模型：这是最酷的了，我过几天会专门写一篇如何训练embedding模型的文章，没有关注我的可以先关注，哈。当然，训练是基于一个既有embedding模型的，一般我们有希望让它在原来的基础上提升3%-10%的性能。

二、检索环节（Retriever）

检索环节技术含量依然很高，而且对于我们目前来说，还有一两项工作正在进行中。

检索优化一般分为下面五部分工作：

• 元数据过滤：当我们把索引分成许多chunks的时候，检索效率会成为问题。这时候，如果可以通过元数据先进行过滤，就会大大提升效率和相关度。比如，我们问“帮我整理一下XX部门今年5月份的所有合同中，包含XX设备采购的合同有哪些？”。这时候，如果有元数据，我们就可以去搜索“XX部门+2023年5月”的相关数据，检索量一下子就可能变成了全局的万分之一；

• 图关系检索：如果可以将很多实体变成node，把它们之间的关系变成relation，就可以利用知识之间的关系做更准确的回答。特别是针对一些多跳问题，利用图数据索引会让检索的相关度变得更高；

• 检索技术：前面说的是一些前置的预处理的方法，检索的主要方式还是这几种：

  • 相似度检索：前面我已经写过那篇文章《大模型应用中大部分人真正需要去关心的核心——Embedding》种有提到六种相似度算法，包括欧氏距离、曼哈顿距离、余弦等，后面我还会再专门写一篇这方面的文章，可以关注我，yeah；
  • 关键词检索：这是很传统的检索方式，但是有时候也很重要。刚才我们说的元数据过滤是一种，还有一种就是先把chunk做摘要，再通过关键词检索找到可能相关的chunk，增加检索效率。据说Claude.ai也是这么做的；
  • SQL检索：这就更加传统了，但是对于一些本地化的企业应用来说，SQL查询是必不可少的一步，比如我前面提到的销售数据，就需要先做SQL检索。
  • 其他：检索技术还有很多，后面用到再慢慢说吧。

• 重排序（Rerank）：很多时候我们的检索结果并不理想，原因是chunks在系统内数量很多，我们检索的维度不一定是最优的，一次检索的结果可能就会在相关度上面没有那么理想。这时候我们需要有一些策略来对检索的结果做重排序，比如使用planB重排序，或者把组合相关度、匹配度等因素做一些重新调整，得到更符合我们业务场景的排序。因为在这一步之后，我们就会把结果送给LLM进行最终处理了，所以这一部分的结果很重要。这里面还会有一个内部的判断器来评审相关度，触发重排序。

• 查询轮换：这是查询检索的一种方式，一般会有几种方式：

  • 子查询：可以在不同的场景中使用各种查询策略，比如可以使用LlamaIndex等框架提供的查询器，采用树查询（从叶子结点，一步步查询，合并），采用向量查询，或者最原始的顺序查询chunks等；
  • HyDE：这是一种抄作业的方式，生成相似的，或者更标准的prompt模板。

  三、生成（Gen）

  这一部反而是我比较疏忽的，因为有大量的现成框架可以使用，而且，这一步真正发挥巨大作用的是LLM。

  这里面我们使用的框架有Langchain和LlamaIndex，而且我们因为有之前的AI产品积累，所以还有一套完整的Java框架可以使用，所以这一块我没有太多研究。唯一非常关注的就是Prompt工程，我们团队内部，这一部分的工作是交给了原来AI产品的知识库运营团队来做的，他们原来做的更多是BERT相关的知识库预训练，应该说工作内容还是比较匹配的。

 本文系转载，版权归原作者所有，如若侵权请联系我们进行删除！