什么是RAG
RAG，全称Retrieval-Augmented Generation，译为检索增强生成，是由Facebook AI Research于 2020 年提出的一种将信息检索与文本生成相结合的技术，主要用于问答系统、聊天机器人。
简单来说，是把查资料和写答案结合起来，根据用户问题，再从外部资料中检索相关信息，再利用这些信息生成更准确的回答。在目前的大模型应用中，RAG 有助于缓解模型生成文本时的事实性幻觉，并提升回答的准确性、时效性和可溯源性。
RAG的工作流程
RAG的核心思路一直都是先查资料，再写答案
查资料
用户进行提问后，系统通过查找资料的函数/工具在知识库（例如向量库、数据库等）进行查询写答案
将用户的问题+知识库中查找出来的资料一同塞给大模型中，大模型通过对问题+资料进行总结，最后生成出最终的回答
RAG的优点
能够使回答更准确，减少模型产生幻觉的概率
知识库可以处于实时更新的状态，使大模型摆脱了知识截止的困境
能够提升模型在回答特定专业领域问题时的准确性
RAG的技术类型
经典RAG（Naive RAG）
经典RAG是RAG的最初形态，其奠定了未来RAG的一个走向，他的大体思路是帮助大模型找到对的资料
流程
用户提问-->资料召回-->文档资料-->LLM-->结果
涉及技术
资料召回
经典RAG的核心部分，负责给大模型找到对应的问题的资料
具体流程为：用户提问通过Embedding模型变成向量数据，再通过与向量库中的文本向量进行ANN相似度查询，返回得到相关文档资料
Embedding模型：负责将文本变成向量化信息
向量库：负责存储向量化文本的数据库
ANN：负责计算两个向量化文本之间的相似度
文档资料
从当时技术上来说，大模型能支持的上下文窗口是有限的，例如早期的128k的上下文窗口，而专业性的文档资料，例如学术论文、法律文本等资料的全文早已超过了128k的上下文窗口，那么由此就诞生出了将文本进行分块的Chunk技术，而现在大模型的上下文窗口虽然已经达到了百万token级别，但经过相关的测试可以发现，当输入的token量达到上下文窗口的50%以上时，模型就会出现相应的文本遗忘，虽然这都是后话了。继续回到Chunk，正如上文所说的，Chunk解决的是一篇文档资料内容过长的问题。将Chunk切割成不同的小块之后，同样是需要使用Embedding模型对Chunk块进行向量化操作后，再存入向量数据库中。这里要注意的是，提问时使用的Embedding模型和对Chunk块进行向量化的Embedding模型要同一个，这是因为不同的Embedding模型出来的词向量是不同的
Chunk：负责对长文本进行分割，包括固定长度分块、句子分块、递归分块、Markdown分块、父子分块、语义分块
Advanced RAG
这一阶段的RAG着重于讨论如何将资料召回环节变得更精准
流程
用户提问-->问题重构-->混合召回-->Reranker-->上下文压缩-->LLM-->结果
涉及技术
问题重构
例如，在经典RAG的情况下，问大模型“为什么A产品利润下降？”，那么就会将向量库中和“为什么A产品利润下降？”相似的文档资料都给到大模型进行回答，而换成Advanced RAG的环境下，“为什么A产品利润下降？”会先经过大模型进行问题拆解，例如会拆解成”A产品2026利润变化“、”A产品2026销售变化“、”A产品2026成本变化“、”A产品2026退货变化“等多个问题
具体流程分为了多种路线，都差不多
LLM Rewrite：将原来的查询问题改写为更便于检索的问题
Multi-Query：将一个问题生成多个语义相同、表述不同的查询，可以通过经典RAG中的文档召回来实现召回同质化的问题，也可以用大模型来生成相关问题
Query Expansion：将原本的问题进行扩展，例如加入些同义词、领域词等
Query Decomposition：将原本的查询问题拆分成多个子问题，主要适用于复杂任务
混合召回
混合召回主要涉及两个技术，一是稠密检索，一个是稀疏检索，稠密检索即经典RAG中所涉及到的Embedding+ANN的技术，而稀疏检索则是更为简单暴力的BM25检索。两个检索方式同时进行检索，并都返回对应的文档片段，就叫做混合检索/混合召回
BM25：即Best Match 25，是基于TF-IDF的升级版，目前普遍应用于与文档相关的搜索引擎
Reranker
Reranker模型的作用主要是起到精排的效果，即混合召回时，可能会汇集Top-50、Top-100条相关文档，而Reranker模型正如其名，对这些相关文档进行一次重排，一般筛选出Top-20的文档内容进行下一步的操作
Reranker：将问题与混合召回的文档内容的关联程度进行排序
上下文压缩
这一步产生的原因主要还是因为当时大模型的上下文窗口不够，但返回的上几步返回的文本内容又太长，可能会导致模型遗忘问题、爆token等问题，所以会选择将上下文进行文本压缩，提取和问题相关的内容，这一步要么就靠着大模型来压缩上下文，要么就是复用Chunk时用到的方法再进行一次句子分割，要么就是再进行一次Reranker的操作，但主流还是使用大模型进行压缩总结，这样的效果是最好的
LLM Extraction：让大模型自己做文本的压缩
CRAG
CRAG又全程Corrective RAG，译为纠正性RAG，其核心就是让大模型自己按需检索，并对检索的结果进行反思，当检索结果不理想的时候，就会触发纠正动作，也可以说从这一步开始，越来越接近Agent的概念
流程
大模型决策，让大模型自己判断是否需要检索，需要检索什么问题，是的话跳到第2步，不是的话跳到第5步
检索结果，从知识库中进行查找数据，这里技术基本上复用前面的稠密检索、稀疏检索、混合召回、甚至于说使用网页搜索的爬虫、API等，完成后跳到第3步
评估结果，总结检索出来的结果是否符合预期，符合跳到第5步，不符合跳到第4步
重试，把第3步的不符合预期的内容加进提示词中，重新跳到第1步进行执行
LLM结果生成，将检索结果和评估结果给到大模型进行生成
涉及技术
大模型决策
这个时候有了Tool的概念，那么就能让大模型自行决定要不要使用搜索用的工具
Tool Calling：一种让大型语言模型生成结构化响应以与外部系统交互的技术，早期叫Function calling
评估结果
通常评估结果都是使用Reranker模型，将每个搜索结果的相关分值都输出出来，人为指定一条基准线，例如0.8则采纳搜索结果，如果分数低于0.4，那么就不采纳，当搜索结果少于10或者5条时，就触发重试的流程。当然还有一种方法是将搜索结果和问题都给大模型，让大模型来判断，这条搜索结果是否需要保留，同样是结果少于0或者5条时就触发重试
GraphRAG
GraphRAG，又称Knowledge GraphRAG、KG RAG、知识图谱RAG，主要改变就是将向量查找文本数据改为使用知识图谱的图关系来查找数据
流程
文档-->大模型抽取实体-->知识图谱-->相关摘要-->大模型生成结果
涉及技术
主要涉及的就是将向量库查找改为了使用图数据库来查找相关文案，例如搜索A产品，可以关联出A产品是生产地、生成公司、配料表等等
图数据库
经典的图数据库引擎就是Neo4j，入库流程基本上就是输入三个值：实体A、实体B、关系类型，然后剩下就交给图数据库自己去处理就好了，然后通过图数据库的查询语句，就能把实体A相关的其他全部实体给查询出来，最麻烦的就是图数据库的入库前的数据治理工作吧（
Ontology RAG
Ontology RAG，又称本体论RAG，主要是为了解决KG RAG中出现的关系爆炸的问题，即我想知道的答案可能只需要其中的2、3条关系，但图数据库返回了几千条关系。实际上就是DDD里面的领域实体、属性、关联关系、约束关系
流程
先定义概念（TBox）-->定义关系规则（RBox）-->写入实例事实（ABox）
用户提问-->问题拆分出实体和关系-->拆分的实体和TBox概念进行语言统一、关系和RBox概念进行语言统一-->生成查询语句-->查出ABox-->结果给到大模型生成最终答案
涉及技术
其中没涉及到太多新的的技术，主要还是一些关于本体论的概念，并把这概念运用到KG RAG中，依旧是要写入到图数据库
TBox：存了什么类型的东西
RBox：允许两个类型之间存在什么关系
ABox：两个类型实际发生了什么关系
Agentic RAG
终于到目前的最后一个了，简单来说这个Agentic RAG就是用智能体来实现RAG，将上述的什么Naive RAG、Advanced RAG、KG RAG、Ontology RAG全部包装成为Tool（当然这里还可以加入NL2SQL，让智能体能够直接在数据库中查询到相关数据），再结合CRAG的重新评估方法，让大模型自行决定使用哪种查找资料的方式，然后再进行问题+查询结果的输出，存在了前面的技术路径之后，这一个便自然而然的出来了，聪明地你应该早早的就想到了吧
