什么是Rag？

RAG，Retrieval-Augmented Generation，中文名检索增强生成，是AI领域非常重要的一种技术方案。其核心作用是给LLM大模型外挂专门的知识库，指导大模型生成更准确的输出。

为什么要给LLM大模型外挂知识库呢？因为虽然大模型的能力越来越强大，但其内在的缺点也非常明显。

第一，存在幻觉问题。LLM大模型的底层原理是基于数学概率进行预测，其模型输出本质上是一种概率预测的结果。所以LLM大模型有时候会出现胡言乱语，或者生成一些似是而非的答案，在大模型并不擅长的领域，幻觉问题会更加严重。使用者要区分幻觉问题是非常困难的，除非使用者本身就具备了相应领域的知识，但这里就会存在矛盾，已经具备相关知识的人是不会采用大模型生成的答案的。

第二，缺乏对生成结果的可解释性。LLM大模型本身就是一个黑盒，这个模型使用了什么数据进行训练，对齐策略是怎么样的，使用者都无从得知。所以对于大模型生成的答案，更加难以追踪溯源。

第三，缺乏对专业领域知识的理解。LLM大模型知识的获取严重依赖训练数据集的广度，但目前市面上大多数的数据训练集都来源于网络公开数据，对于企业内部数据、特定领域或高度专业化的知识，大模型无从学习。

因此大模型的表现更像是一个及格的通才，但是在一些专业场景，比如企业内部的业务流，一个及格的通才是无法使用的，需要利用企业的专属数据进行喂养和训练，打造为优秀的专才。

第四，数据的安全性。这是对上面第三点的延伸，没有企业愿意承担数据泄露的风险，将自身的私域数据上传第三方平台进行训练。因此，完全依赖通用大模型自身能力的应用方案，在企业场景下是行不通的。

第五，知识的时效性不足。大模型的内在结构会被固化在其被训练完成的那一刻，但是当你询问大模型一些最新发生的事情，则难以给出答案。

为了克服这些问题，第一种方式是微调，即Finetune。但是由于生成模型依赖于内在知识，也就是各类参数的权重，即使做了微调，模型还是无法摆脱幻觉问题。此外在实际场景中，很多新的信息、数据、政策每时每刻都在产生，除非对模型进行高频的微调，否则模型的训练速度永远赶不上外部信息更新的速度，而高频微调的成本就太高了，

在2020 年，Meta AI 的研究人员提出了检索增强生成（RAG）的方法，为LLM大模型提供了一种与外部信息高效互动的解决方案。其主要作用类似于搜索引擎，找到用户提问最相关的知识或者是相关的对话历史，并结合原始提问，创造信息丰富的prompt，指导LLM大模型生成更准确的输出。

这就是Rag技术产生的背景和原因。

Rag技术的基本原理

RAG可分为5个基本流程：知识文档的准备、嵌入模型 、存入向量数据库、查询检索和生产回答。

现实场景中，我们面对的知识源可能包括多种格式，如Word文档、TXT文件、CSV数据表、Excel表格，甚至图片和视频。因此需要使用专门的文档加载器（例如PDF提取器）或多模态模型（如OCR技术），将这些丰富的知识源转换为大语言模型可理解的纯文本数据，然后开启RAG的五个核心步骤。

第一步，文档切片/分块：在企业级应用场景中，文档尺寸可能非常大，因此需要将长篇文档分割成多个文本块，以便更高效地处理和检索信息。分块的方式有很多种，比如按段落、按内容或者其他特殊结构。同时，需要注意分块的尺寸，如果分块太小，虽然查询更精准，但召回时间更长；如果分块太大，则会影响查询精准度。

第二步，嵌入模型：嵌入模型的核心任务是将文本转换为向量形式，这样我们就能通过简单的计算向量之间的差异性，来识别语义上相似的句子。

第三步，存入向量数据库：将文档切片和嵌入模型的结果存储进入向量数据库。向量数据库的主要优势在于，它能够根据数据的向量接近度或相似度，快速、精确地定位和检索数据，实现很多传统数据库无法实现的功能，比如根据旋律和节奏搜索出特定的歌曲、在电影中搜索浪漫的片段、在文档中找出意图相近的段落等等。

第四步，用户查询检索：用户的问题会被输入到嵌入模型中进行向量化处理，然后系统会在向量数据库中搜索与该问题向量语义上相似的知识文本或历史对话记录并返回，这就是检索增强。

第五步，生成问答：最终将用户提问和上一步中检索到的信息结合，构建出一个提示模版，输入到大语言模型中，由大模型生成最终的结果并返回。

Rag技术一经问世，就取得了非常广泛的使用，成为AI大模型产品落地中必不可少的一环。根据具体的使用场景，可以分为以下几类。

通用问答系统：RAG可以根据检索到的相关信息生成准确的答案，帮助员工更快地获取所需信息，提高决策效率，比如搭建企业内部知识库、公司规章制度查询、新员工入职培训、公司合同资料解读和查询等。

智能客服系统：RAG可以结合产品资料知识库、聊天记录、用户反馈等数据，自动为用户提供更精准的回答，已经有非常多的初创公司选择用RAG技术构建新一代的智能客服系统。

智能数据分析：RAG可以结合外部数据源，如数据库、API、文件等，为用户提供更便捷的数据分析服务。传统企业的数据分析主要靠BI分析师，每天都需要写大量的SQL语句进行查询，而在RAG的支持下，企业的每个员工都能以自然对话的方式获取数据。比如门店店长直接用语音对话，“请帮我找出上周销量排名前10，但本周销量下滑最快的品类”，系统即可直接给出答复。

自动化文档处理：企业还可以利用RAG和LLM大模型自动化文档处理流程，例如自动生成合同、撰写周报、总结会议纪要等，节省时间和人力成本。

Rag实施路径

Rag技术虽然相对比较容易入门，但是要部署到生产环境并且对外提供稳定的服务，还是有很多路要走的，尤其是其流程的各个环节都有非常多的优化空间。

从优化的方向来看，主要包括四个方面，知识分块与索引优化、用户query改写优化、数据召回优化和内容生成优化。当然，“罗马不是一天建成的”，Rag相关项目的实施也需要分阶段逐步进行迭代和优化，风叔建议可以按照以下三个阶段来实施。

第一阶段，可运行，即系统能跑通整体流程

1. 知识分块与索引

在RAG系统中，文档需要分割成多个文本块再进行向量嵌入。在不考虑大模型输入长度限制和成本问题情况下，其目的是在保持语义上的连贯性的同时，尽可能减少嵌入内容中的噪声，从而更有效地找到与用户查询最相关的文档部分。

如果分块太大，可能包含太多不相关的信息，从而降低了检索的准确性。相反，分块太小可能会丢失必要的上下文信息，导致生成的回应缺乏连贯性或深度。

第一阶段可先按固定字符拆分知识，并通过设置冗余字符来降低句子截断的问题，使一个完整的句子要么在上文，要么在下文。这种方式能尽量避免在句子中间断开的问题，且实现成本最低，非常适合在业务起步阶段。

2. 用户Query改写

在RAG系统中，用户的查询问题会被转化为向量，然后在向量数据库中进行匹配，因此查询的措辞准确度会直接影响搜索的结果。在向量空间中，对人类来说看似相同的两个问题其向量大小并不一定很相似

我们可以采用“查询重写”方案，即直接利用LLM大模型重新表述问题。在进行多轮对话时，用户提问中的某些内容可能会指代上文中的部分信息，可以将历史信息和用户提问一并交给LLM大模型进行重新表述。

总体来说，第一阶段可以先直接使用大模型的理解能力，结合上下文，突出用户意图。此时不需要做过多的Query改写，以测试大模型理解能力和跑通流程为主。

3. 数据召回

第一阶段可以先使用最简单的向量召回方式，找到在语义向量维度最近似的答案进行召回。这里需要注意的是，要找一个和自己业务比较契合的embedding模型和向量数据库。

召回结果的数量是另一个关键因素，更多的结果可以提供丰富的预料，有助于系统更好地理解问题的上下文和隐含细节。但是结果数量过多可能导致信息过载，降低回答准确性并增加系统的时间和资源成本。第一阶段我们可以先把召回数量设置为10。

4. 内容生成

内容生成环节更多的是考虑用户体验，在第一阶段我们可以先简单一些，能顺利输出答案即可。因为数据召回环节只有向量召回，因此这一步可以只将上一步召回环节返回的top 10的知识筛选出来，然后提供给大模型生成答案。

第一阶段的系统可能会存在较多问题，大家会发现生成答案的相关性和准确度都比较低。但是没关系，这一阶段的首要任务是跑通系统流程，优化的工作我们放在第二和第三阶段再做。

第二阶段，可使用，即系统初步达到可上线水平

1. 知识分块与索引

知识的分块与索引，对最终答案生成的准确性有非常大的影响，尤其是在处理超长文本的时候，会出现索引混淆问题。

索引混淆是指知识文档的核心关键词被湮没在大量的无效信息中，比如大量无关紧要的助词、语气词、或无关信息，导致建立的索引中核心知识比重少，从而影响生成答案的质量。针对这个问题，我们可以采用三种优化方案，索引降噪、多级索引和HYDE。

索引降噪：是根据业务特点，去除索引数据中的无效成分，突出其核心知识，从而降低噪音的干扰，保障核心知识的比重。比如原文档内容是“How can I download source code from github.com”，其核心内容是“download source code、github”，其他噪音可以忽略。 

多级索引：是指创建两个索引，一个由文档摘要组成，另一个由文档块组成，并分两步搜索，首先通过摘要过滤掉相关文档，然后只在这个相关组内进行搜索。这种多重索引策略使RAG系统能够根据查询的性质和上下文，选择最合适的索引进行数据检索，从而提升检索质量和响应速度。但为了引入多重索引技术，我们还需配套加入多级路由机制，比如对于查询“最新发表的Rag论文推荐”，RAG系统首先将其路由至论文专题的索引，然后根据时间筛选最新的Rag相关论文。

HYDE：全称是Hypothetical Document Embeddings，用LLM生成一个“假设”答案，将其和问题一起进行检索。HyDE的核心思想是接收用户提问后，先让LLM在没有外部知识的情况下生成一个假设性的回复。然后，将这个假设性回复和原始查询一起用于向量检索。假设回复可能包含虚假信息，但蕴含着LLM认为相关的信息和文档模式，有助于在知识库中寻找类似的文档。

2. 用户Query改写

直接使用原始的用户query进行检索，会存在一些问题。比如知识库内的数据无法直接回答，需要组合多种知识才能找到答案；此外，涉及细节比较多的问题，大模型往往无法进行高质量的回答。可以使用Rag-Fusion进行优化。

RAG-Fusion：首先对用户的原始query进行扩充，即使用 LLM 模型对用户的初始查询，进行改写生成多个查询；然后对每个生成的查询进行基于向量的搜索，形成多路搜索召回；接着应用倒数排名融合算法，根据文档在多个查询中的相关性重新排列文档，生成最终输出。

3. 数据召回

在第一阶段，我们使用了单纯的语义向量做召回，但是当文本向量化模型训练不够好时，向量召回的准确率会比较低，此时需要利用其他召回方式作为补充。

分词召回：一种有效的稀疏搜索算法是最佳匹配25（BM25），它基于统计输入短语中的单词频率，频繁出现的单词得分较低，而稀有的词被视为关键词，得分会较高。我们可以结合稀疏和稠密搜索得出最终结果。

多路召回：多路召回的结果经过模型精排，最终筛选出优质结果。至于使用几种召回策略，根据业务而定。

4. 内容生成

根据前几个环节的优化策略，内容生成环节也需要有相应的调整。

文档合并去重：多路召回可能都会召回同一个结果，针对这部分数据要去重，否则对大模型输入的token数是一种浪费；其次，去重后的文档可以根据数据切分的血缘关系，做文档的合并。

重排模型：重排模型通过对初始检索结果进行更深入的相关性评估和排序，确保最终展示给用户的结果更加符合其查询意图。这一过程通常由深度学习模型实现，如Cohere模型。这些模型会考虑更多的特征，如查询意图、词汇的多重语义、用户的历史行为和上下文信息等。

经过第二阶段的优化，答案生成的相关性和准确度都会大幅提升，但是仍然会有较大概率出现答非所问的情况，我们还需要对系统做更进一步的优化。

第三阶段，很好用，即系统回答的准确率达到用户满意水平

下面，风叔介绍一些更高级的Rag优化策略。

1. 知识分块与索引

虽然在第二阶段，我们通过索引降噪、多级索引、HYDE等方式，大幅提升了知识库的准确度，但是按固定字符切，有时候会遇到句子含义联系比较紧密的片段被切分成了两条数据，导致数据质量比较差。

这个情况下可以尝试训练专门的语义理解小模型，然后使用实际语义进行句子拆分，使拆分出来的知识片段语义更加完整。

另外一种方法是构建元数据，增加内容摘要、时间戳、用户可能提出的问题等附加信息来丰富知识库，而元数据不需要被向量化。此外，我们还可以添加诸如章节或小节的引用，文本的关键信息、小节标题或关键词等作为元数据，有助于改进知识检索的准确性。

还有一种更加有效的方式是建立知识图谱。嵌入模型虽然简单，但是没法有效捕捉实体之间的复杂关系和层次结构，所以导致传统RAG在面对复杂查询的时候特别吃力。比如，用户询问“《跨越鸿沟》这本书的主旨是什么”，传统Rag技术是肯定回答不出来的。但是知识图谱技术可以做到，因为利用知识图谱对数据集建立索引的时候，会做提取实体（Entity）以及实体之间的关系（Relationship），这样就能构建一种全局性的优势，从而提升RAG的精确度。

但是，知识图谱虽然很强大，可惜成本太高了，会大幅提升token使用量，大家需要综合产品体验和成本进行评估。

2. 用户query改写

Step-Back Prompting：如果果原始查询太复杂或返回的信息太广泛，我们可以选择生成一个抽象层次更高的“退后”问题，与原始问题一起用于检索，以增加返回结果的数量。例如，对于问题“勒布朗詹姆斯在2005年至2010年在哪些球队？”这个问题因为有时间范围的详细限制，比较难直接解决，可以提出一个后退问题“勒布朗詹姆斯的职业生涯是怎么样的？”，从这个回答的召回结果中再检索上一个问题的答案。

3. 数据召回

图谱召回：如果在知识分块环节使用了知识图谱，那么我们就可以直接用图谱召回，大幅提升召回准确度。

Agentic-rag：RAG应用退化成一个Agent使用的知识工具。我们可以针对一个文档/知识库构建多种不同的RAG引擎，比如使用向量索引来回答事实性问题；使用摘要索引来回答总结性问题；使用知识图谱索引来回答需要更多关联性的问题等。在单个文档/知识库的多个RAG引擎之上设置一个DocAgent，把RAG引擎作为该Agent的tools，并利用LLM的能力由ToolAgent在自己“负责”的文档内使用这些tools来回答问题。最后设置一个总的顶级代理TopAgent来管理所有的低阶DocAgent，将DocAgent看作自己的tools，仍然利用LLM来规划、协调、执行用户问题的回答方案

4. 内容生成