在人工智能领域，RAG（Retriever-Augmented Generation）技术正逐渐成为提升自然语言处理任务性能的关键。这种结合了检索与生成的模型架构，通过从大量文档中检索相关信息，并利用这些信息生成响应或文本，显著提高了预测的准确性。
最近在负责调研RAG产品，虽然之前通过Dify和Coze使用过其中知识库的RAG功能，但始终对其相关配置能力的理解还较为有限。
RAG（Retriever-Augmented Generation）是一种将检索与生成相结合的人工智能模型架构。
当大模型回答问题或生成文本，首先从大量文档中检索相关信息，随后再利用这些检索到的信息来生成响应或文本，从而提高预测的质量。
其主要用于知识密集型的自然语言处理任务，尤其是在需要结合外部知识库的信息生成高质量文本的场景中。
于是在恶补了2周知识后，结合自己所关注的点，现梳理出一篇关于RAG到底是什么的文章（其中大部分信息来源于整合，小部分内容为个人见解）。
本文将分为3大部分：
1、RAG到底是什么？
2、RAG能帮助企业做什么？
3、RAG未来将怎样发展？
2020年，首次出现了RAG这个概念，但其真正火起来也是自ChatGPT发布以后（2022年12月）才开始的。前面应用ChatGPT给出了官方一些的说明，本质上其给大模型带来的价值可以粗略提炼为：没有应用RAG技术的大模型在回答问题时是闭卷考试，而应用了RAG技术的大模型则是——通过外挂了一个知识库来实现开卷考试。
目前大模型在生成回答时有3大问题：容易出现幻觉、缺乏专业知识、回答缺乏可解释性，而RAG技术通过外挂专业的知识库、在生成答案时结合知识库回答问题、同时在最终生成结果中展示知识库信息来源，一定程度上有效的解决了这3大问题。
那么，RAG是怎样解决上面这3大问题的呢？
首先我们来看一下RAG的架构，整体分为索引、检索、增强、生成4个大的阶段：
这一步指通过内容分块、向量化等方式，生成索引并存入向量数据库。为什么这里这么麻烦，既要分块又要做向量化处理来建索引，而不是像一些关系型数据库直接去建立索引呢？
这是核心因为2个点：
（1）大模型需要通过向量化去建立语义理解。
通过将包含高维信息的知识降维拍到向量空间里，这些知识就变成了一堆数字串；此时，当用户去提问时，先将提问的知识向量化变成一串数字后，再从知识库中通过余弦计算等方式找出和用户提问数字串最相似的信息出来，这就完成了所谓的语义理解（当然这块还有复杂的对称和不对称计算等，不做展开了）。
（2）分块能够有效提升检索效率和缓解上下文长度限制。
理想状态下，在检索时将每个信息都遍历一遍肯定就不会漏信息了，但是当信息量大且不能让用户等待过久的时候，还是需要更高效和更具性价比的方式；同时，大模型一次能输入的上下文有长度限制，虽然已经有大模型将上下文长度延伸至了更高量级，但似乎实验证明更大的上下文窗口不一定对检索结果更有效。
而分块技术，则可以理解为将一篇50w字的书籍文档按照段落或者语义等方式划分成n个块。这样，既能够有效解决上下文长度限制问题，同时也对于检索有一定的效率提升；但同时也存在可能会丢失文档的全局结构、不同块之间的前后逻辑等问题（不过这些问题都在陆续通过建立重叠上下块内容、建立块的类似索引结构等方式逐渐解决中）。
当用户提问后，通过检索技术则可以从知识库中召回相关内容块。根据2024年一篇很火的RAG论文，其将RAG划分为3大范式：原生RAG、先进RAG、模块化RAG。
目前2024年基本大部分厂商已经在第二步（先进RAG）这一层面了，例如Dify就有全文检索和向量检索2种模式。
因此，在检索这一步，我特地画了2种混合检索来做示意，个人判断混合检索会是未来的一大趋势，因为每种检索都有其优势和弊端，只有结合才能取长补短。而检索方式将不局限于关键词检索和向量检索，最终的形态一定是多种检索方式的结合和互补。当混合检索结束后，再通过一个Rerank的机制重新对不同渠道的检索结果做一个最终的整合和排序。
当重排序结束后，将生成最终前n个匹配度最高的内容块，将这些内容块与用户的查询、系统配置的prompt等做整合，一并让大模型根据这些信息生成最终的回答。
在整个完整的RAG过程中，索引和检索将极大的影响最终生成的质量。
从下述生成式AI技术应用跟踪来看，目前最常见的几大使用场景：知识助手、智能客服、数据分析等无一例外都应用到了知识库及RAG技术。
当企业某一业务存在大量重复性、知识密集型且标准化较高的特征时，则可以考虑使用RAG来搭建一个问答机器人。如果是搭建基础知识问答助手，FastGPT、Dify社区版、Coze都可以很快捷地进行知识库的搭建，也有完整的FAQ支持。
以我们公司为例，产品本身专业性强所以使用门槛较高，因此搭建了围绕产品使用的问答助手；
某医疗公司每年都会推出新的医疗器械、医药等，医药代表不一定能及时记忆最新的产品和细节，则可以通过新产品问答助手随时查询围绕产品的细节；
而某高端社区打造了社区内部的社群服务，每天都要频繁被咨询如何创建社群、如何参加活动、停车、wifi等问题，此时他们则选择通过AI客服助手来解决重复回答效率低的问题。
如今的AI问答其优势在于能够很好的理解自然语言、并很好的生成自然语言，这让对话不再显得是那么的「人工智障」和生硬（虽然又会容易存在幻觉问题，但问题总在解决的过程中嘛）。
当然，如果是搭建复杂的知识问答助手，其难点还是在于：
例如某产品推荐场景下，针对结构化的产品数据则不需要做内容分块，直接针对字段进行向量化和关键词检索即可；
针对某医疗问诊助手场景下的大量非结构化和疾病相关的pdf文档，则需要分块向量化；
而针对某社区提供的社群问答助手场景，其直接提供了数十个Q&A结构的文档，那自然按照原始的Q&A结构去做问题的分块，才能更好的保证最终的检索结果。
2024年这一年，RAG领域出现了非常多的论文，夸张的时候一周可能有十多篇。同时，根据下图这篇报告，2024年RAG占据设计的主导地位，而提示词和微调已逐渐有些弱化掉了。这说明，RAG正处在一个大家对其充满期望和肯定的蓬勃探索期。
这一年，RAG领域涌现了诸多新思路和新技术，以下列举比较热门的3个：
以GraphRAG为例，这是一种微软在24年中开源的图RAG技术，其本质上是将知识图谱和RAG做了融合。
通过利用大模型自动抽取文档内的命名实体，然后利用这些实体自动构建知识图谱。在图谱中，同样利用聚类产生实体聚集的“社区”，并利用 LLM 生成这些社区的摘要。在召回的时候，知识图谱的实体、边、以及社区摘要，它们连同原始文档一起来做混合召回。
由于这些数据同样形成了文档中跨 Chunk 的关联信息，因此对于宏观性提问，多跳提问，有着更好的效果。GraphRAG 可以看作是解决语义鸿沟的当下行之有效的策略和架构。
RAG 本身是 Agent 的重要算子，它可以解锁 Agent 访问内部数据的能力；Agent 直接用于 RAG，可以提供高级 RAG 能力，这就是所谓 Agentic RAG。
在RAG的过程中，诸如该如何进行分块、该如何选择检索方式、如何选择最终召回结果、召回效果怎么样评估、基于多跳问题该如何补足等，都可以利用大模型的能力打造一个独立的Agent来实现。
未来的 RAG 系统不仅限于文本检索，还将能够处理图像、音频等多种媒体类型。大模型将能够理解并生成包含文本、图像和声音的信息，为用户提供更丰富的互动体验。
对于RAG未来将怎样发展这个命题，我同意RAGFlow负责人的观点：
RAG 就相当于过去的数据库，对外暴露的接口无比简单，内部却无比复杂，它不仅仅包含了数据库本身，还包含了各种小模型以及把它们串接起来的工具，从本质上来说，它就是过去的企业搜索引擎在大模型时代的进化，但它又大大超出了搜索引擎本身的范畴。
最后呢，我对未来的RAG的设想有如下3个：
1）未来的RAG应该是在数据源和上层AI应用中间去搭建桥梁的关键角色。
基于上层AI应用的诉求，对数据源制定不同的RAG策略，从而让RAG能够更好的服务于应用的效果。
2）未来的RAG会因为微调和大模型本身的技术/性能突破而变得更加简单和统一化。
现在的很多RAG策略其实都是为了补足微调和大模型的短板而设计的，就像2023年最火的技术是门槛最低的Prompt、2024年最火的技术是RAG、2025年最火的技术将是Agent一样，未来门槛越高的技术（如微调）将逐渐变低，这对原来更为简单的技术会造成极大的影响。
而关于RAG的各类思路、技术也将逐渐收敛，其范式也将逐渐趋于稳定和主流。
3）未来的RAG将作为关键支撑层服务于Agent。
讲到这里，一定会有很多伙伴提出问题，就是未来的演进究竟是RAG把自己变成一个Agent平台，还是各种Agent平台把自己的RAG能力增强？这个趋势很难预测：正如我们在数字化时代，究竟是做数仓的，把做中台这种包含业务的事情也做下来，还是做业务的最终下沉自身技术能力提供更好的数仓，两者都有先例。
针对RAGFlow负责人对于RAG和Agent关系的如上观点，我有不一样的看法：我认为RAG最终还是要服务于Agent的。
客户不可能用A平台去做独立的知识库、B平台去做独立的Agent；客户也不可能停留在做一个以RAG技术为主的问答助手，除了基础问答外，肯定会伴随着希望更多的流程和SOP自动化智能化。此时，就会优先选择Agent平台去做集成：既能做流程、又能做知识。
因此，如果选择继续做RAG类产品：
That’s all，以上就是对RAG的一些初步整合和浅见，如有问题烦请指正～后续也将针对RAG领域做更多产品类调研，欢迎关注。
专栏作家
冰冰酱；公众号：冰冰酱啊，人人都是产品经理专栏作家。5年产品经验，创过业、带过人、踩过坑；独立负责从0-1搭建业务中台，持续深耕B端及SaaS领域。
本文原创发布于人人都是产品经理，未经许可，不得转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。