RAG检索增强生成系统一直是企业里使用大语言模型LLMs最有用的应用之一。我记得大约两年前我写过第一篇关于 RAG 的文章那时候这个词还没被大家广泛使用。当时我描述的 RAG 系统是最简单的实现方式。从那时起行业已经发展了很多引入了很多先进的技术。在本文中我们会探讨 RAG 的演变过程从最初的简单版本Naive RAG到现在更智能的版本Agentic RAG。读完之后你就会明白每一步的演变都解决了哪些问题。—1—Naive RAG 架构剖析2022年底ChatGPT 的出现让大语言模型LLMs变得非常流行。差不多同一时间一种叫做“检索增强生成”RAG的技术也出现了。这个技术主要是为了解决一些大语言模型本身存在的问题比如有时会“胡说八道”也就是生成一些不准确或不真实的信息。能处理的信息量有限就像一个人一次只能记住这么多东西。无法访问一些非公开的数据比如公司内部的资料。无法自动获取模型训练之后的新信息如果要更新知识就需要重新训练模型这既耗时又耗力。RAG 的最简单架构设计的实现方式是这样的预处理阶段把整个知识库的文本资料分割成一个个小块每个小块都是一段可以查询的文本。这些资料可能来自不同的地方比如公司内部的文档、PDF 报告等。用一个特殊的模型嵌入模型把这些文本块转换成一种特殊的代码向量嵌入。把这些代码存到一个特殊的数据库向量数据库里同时保存每个向量对应的原始文本和指向向量的链接。检索阶段在向量数据库里用同一个嵌入模型处理知识库中的文档内容和用户的问题确保查询和知识库中的信息能够准确匹配。在向量数据库的索引上运行查询选择要检索的向量数量这决定了你将用多少上下文信息来回答查询。向量数据库会执行一个搜索找到最相似的向量然后把这些向量映射回它们对应的原始文本块。把问题和检索到的上下文文本块一起通过一个提示词传递给大语言模型告诉模型只用这些上下文来回答这个问题。这并不意味着不需要设计好的提示词–你还需要确保模型返回的答案符合预期比如如果检索到的上下文中没有相关信息就不要编造答案。—2—Naive RAG 架构的模块组成在搭建一个能用在实际工作生产级的 RAG 系统时即使不使用什么高级技术也要考虑很多会变化的部分动态模块。检索部分分块策略决定怎么把用来提供额外信息的数据切成一块一块的。可以选择切小一点或大一点的块。可以用滑动窗口或固定窗口的方法来切。检索时可以选择是否带上块的“亲戚”信息父块/链接块或者只用原始检索到的数据。嵌入模型选择一个模型把额外信息转换成一种特殊的向量嵌入到 latent space或者用这个模型从这种向量中检索信息。这里需要考虑上下文嵌入。向量数据库选择用哪种数据库。决定数据库放在哪里。考虑除了向量嵌入还要存哪些额外信息元数据这些信息可以用来在检索前筛选和检索后过滤结果。确定如何构建数据库的索引。向量搜索选择用什么标准来衡量相似度。决定查询时是先看元数据还是先做近似最近邻ANN搜索。可以考虑混合搜索方案。启发式规则在检索流程中应用一些基于经验的规则。根据文档的时间来调整重要性。对检索到的上下文进行去重按多样性排序。检索时带上内容的原始来源信息。根据不同条件比如用户的查询意图、文档类型对原始文本进行特别处理。生成部分大语言模型为你的应用选择合适的大语言模型LLM。提示词工程即使可以在提示词中加入上下文信息也需要精心设计提示词调整系统以生成符合预期的输出并防止被“越狱”即防止模型生成不适当的内容。完成所有这些步骤后我们才能搭建起一个能运行的 RAG 系统。但不幸的是这类系统往往难以真正解决实际问题。由于各种原因这种系统的准确性可能并不高。—3—Naive RAG 架构设计的高级技术为了提升 Naive RAG 系统的精确度我们尝试了一些有效的方法查询调整- 这里有几个技巧查询重写让大语言模型LLM改写原始问题让它更适合用来检索信息。这可能包括修正语法错误或者把问题简化成更直接的表述。查询扩展让 LLM 对原始问题进行多次改写生成多个不同的版本。然后对每个版本都进行检索以找到更多可能相关的信息。重新排序- 对初次检索出来的文档使用比普通搜索更复杂的方法来重新排序。这通常需要用到更大型的模型并且在检索阶段故意获取比实际需要更多的文档。重新排序和前面提到的查询扩展一起用效果最好因为查询扩展通常能返回更多的数据。这个过程有点像我们在推荐系统中的做法。微调嵌入模型- 在某些领域比如医疗如果用基础的嵌入模型来检索信息效果不好你可能需要对嵌入模型进行定制化的微调。接下来我们再看看其他一些高级的 RAG 技术和架构。—4—上下文检索上下文检索这个想法是 Anthropic 团队去年提出来的主要是为了让用检索来加强生成的 AI 系统更精确、更靠谱。我觉得上下文检索既简单又直接而且效果确实不错。下面是上下文检索怎么操作的预处理阶段用你选好的方法把文档切成一块一块的文本。把每个文本块和整个文档一起放到一个提示词里。在提示词里加上指示让大语言模型LLM找出文本块在文档里的位置并给它写个简短的介绍。然后把这个提示词放到 LLM 里。把上一步做出来的介绍和原始文本块合在一起。把这些合并好的数据放到一个 TF-IDF 嵌入器里。再把数据放到一个基于 LLM 的嵌入模型里。把步骤5和步骤6做出来的东西存到一个能快速搜索的数据库里。检索阶段用用户的提问去找相关的介绍。用一种叫近似最近邻ANN的方法来做语义匹配同时用 TF-IDF 索引来做精确搜索。用排序融合技术把检索出来的结果合并、去重然后选出前 N 个选项。对上一步的结果重新排序缩小到前 K 个选项。把步骤3的结果和用户提问一起放到 LLM 里生成最终的答案。一些思考步骤3听起来实际上也是很费事但是用一个叫提示词缓存的技术可以大大减少这个成本。提示词缓存这个技术可以用在私有闭源模型上也可以用在开源模型上。—5—缓存增强生成Cache Augmented Generation2024年底社交媒体上出现了一份引起轰动的白皮书介绍了一种可能彻底改变 RAG检索增强生成的技术–CAG缓存增强生成。我们先了解一下 RAG再简单看看 CAGCAG会把所有的外部预先信息计算好存到大语言模型LLM的缓存里并存到内存中。这个计算只需要做一次之后就可以重复使用这个缓存不需要重新计算。把用户的提问和一些系统提示词和怎么使用缓存信息的提示词一起输入 LLM。把 LLM 生成的答案返回给用户。完成后清除缓存里的临时内容只保留最初缓存的信息这样 LLM 就可以准备生成下一个答案了。CAG 承诺通过把全部信息存在缓存里而不是每次生成时只检索一部分可以实现更精确的检索。但实际情况如何呢CAG 并不能解决因为信息太长而导致的不准确问题。在数据安全方面CAG 有很多限制。对于大公司来说把整个内部知识库都加载到缓存里几乎不可能。缓存不能动态更新添加新数据非常困难。实际上自从很多 LLM 供应商引入了提示词缓存技术后我们实际上已经在用 CAG 的一种变体了。我们的方法可以说是 CAG 和 RAG 的结合具体操作如下数据预处理在 CAG 中我们只使用变化不大的数据源。除了要求数据更新不频繁我们还会考虑哪些数据源最常被查询用到。确定了这些信息后我们才会把所有选定的数据预先计算好存到 LLM 的缓存里并缓存在内存中。这个计算只需要做一次之后就可以多次使用不需要重新计算。对于 RAG如果需要我们可以把向量嵌入预先计算好存到兼容的数据库里供之后检索用。有时候对于RAG来说只需要更简单的数据类型常规数据库就足够了。查询路径构建一个包含用户提问和系统提示词的提示词明确指导大语言模型怎么利用缓存的信息和外部检索到的信息。把用户提问转换成向量嵌入用来在向量数据库里进行语义搜索并从存储中检索相关数据。如果不需要语义搜索就查询其他来源比如实时数据库或互联网。把步骤4中获取的外部信息整合到最终的提示词中以提高回答的质量。把最终生成的答案返回给用户。接下来我们将探讨最新的技术发展方向–Agentic RAG。—6—Agentic RAG 架构设计Agentic RAG 引入了两个新的关键部分目的是在处理复杂的用户问题时让结果更加稳定可靠。这两个部分是数据源选择Data Source Routing。答案检查和调整Reflection。下面我们看看这两个部分是怎么工作的。Agentic RAG 的工作流程分析用户的问题把用户的问题交给一个基于大语言模型的智能助手来分析。在这个阶段原始问题可能会被改写有时候需要改写好几次最后变成一个或几个新的问题送到下一步处理。智能助手会判断是否需要额外的数据来回答这个问题。这是它展现自主决策能力的第一步。如果需要其他数据就会开始检索步骤这时会进行数据源选择。系统里可以预先设置一个或多个数据集智能助手可以自己选择哪个数据源最适合当前的问题。比如实时的用户数据比如用户现在的位置。用户可能感兴趣的内部文件。网络上的公开数据。一旦从多个数据源中检索到数据我们就会像在普通的 RAG 中一样对这些数据进行重新排序。这也是一个关键步骤因为不同存储技术的数据源都可以整合到这个 RAG 系统中。检索过程的复杂性都被智能助手用的工具所隐藏。尝试直接用大语言模型生成答案可能是一个答案也可能是多个答案或者是一组操作指令。这个过程可以在第一轮就完成或者在答案检查和调整之后进行。对生成的答案进行检查总结并评估它们的正确性和相关性如果智能助手认为答案已经很好就直接返回给用户。如果智能助手觉得答案还需要改进就会尝试重新改写用户的问题并重复这个生成循环。这是 Agentic RAG 和 Naive RAG 的第二个主要区别。最近Anthropic 的开源项目 MCP将会大大推动 Agentic RAG 的开发。—7—总结我们已经回顾了检索增强生成RAG技术的发展过程。RAG 技术不仅没有过时而且我认为它在未来还会继续发展。掌握这些技术架构并知道什么时候该用哪种方案会是一笔很值得的投资。通常来说方案越简单越好因为系统的复杂性增加会带来新的挑战。一些新出现的挑战包括评估整个系统从开始到结束的性能变得困难。多次调用大语言模型导致整个过程的延迟变长。运营成本也随之增加。总之虽然 RAG 技术在不断进步但我们在选择和应用时还是需要考虑到这些新挑战。如何学习AI大模型我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】第一阶段从大模型系统设计入手讲解大模型的主要方法第二阶段在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用第三阶段大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统第四阶段大模型知识库应用开发以LangChain框架为例构建物流行业咨询智能问答系统第五阶段大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型第六阶段以SD多模态大模型为主搭建了文生图小程序案例第七阶段以大模型平台应用与开发为主通过星火大模型文心大模型等成熟大模型构建大模型行业应用。学会后的收获• 基于大模型全栈工程实现前端、后端、产品经理、设计、数据分析等通过这门课可获得不同能力• 能够利用大模型解决相关实际项目需求 大数据时代越来越多的企业和机构需要处理海量数据利用大模型技术可以更好地处理这些数据提高数据分析和决策的准确性。因此掌握大模型应用开发技能可以让程序员更好地应对实际项目需求• 基于大模型和企业数据AI应用开发实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能 学会Fine-tuning垂直训练大模型数据准备、数据蒸馏、大模型部署一站式掌握• 能够完成时下热门大模型垂直领域模型训练能力提高程序员的编码能力 大模型应用开发需要掌握机器学习算法、深度学习框架等技术这些技术的掌握可以提高程序员的编码能力和分析能力让程序员更加熟练地编写高质量的代码。1.AI大模型学习路线图2.100套AI大模型商业化落地方案3.100集大模型视频教程4.200本大模型PDF书籍5.LLM面试题合集6.AI产品经理资源合集获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】