微信扫码
添加专属顾问
我要投稿
RAG系统在结合外部知识库和生成模型方面表现出色,但在工程实践中面临诸多挑战。 核心内容: 1. RAG系统的原理与应用场景 2. RAG系统在工程实践中的7个常见问题 3. RAG系统的另外5个问题及潜在解决方案
随着大语言模型(LLM)的广泛应用,检索增强生成(RAG)技术作为一种结合检索技术和LLM提示的创新架构,因其在结合外部知识库和生成模型方面的卓越表现而备受关注。RAG系统通过将LLM与结构化或非结构化的外部数据源相结合,显著提升了生成内容的准确性、相关性和可信度。
RAG在聊天机器人、知识密集型任务和企业应用中表现出色。然而从理论到工程实践,开发和优化一个高效的RAG系统并非易事,RAG系统面临着诸多挑战。尽可能的系统性地分析RAG系统的开发难点与优化路径。
首先看下澳大利亚吉朗应用人工智能研究所 Scott Barnett等人撰写的论文 《Seven Failure Points When Engineering a Retrieval Augmented Generation System》, 探讨了RAG系统在工程实践中的问题,论文中总结了7个常见的问题:
当用户的问题无法从文档库中检索到时,可能会导致大模型的幻觉现象。理想情况下,RAG 系统可以简单地回复一句 “抱歉,我不知道”,然而,如果用户问题能检索到文档,但是文档内容和用户问题无关时,大模型还是可能会被误导。
由于大模型的上下文长度限制,我们从文档库中检索时,一般只返回排名靠前的K个段落,如果问题答案所在的段落超出了排名范围,就会出现问题。
包含答案的文档已经成功检索出来,但却没有包含在大模型所使用的上下文中。当从数据库中检索到多个文档,并且使用合并过程提取答案时,就会出现这种情况。
答案在提供的上下文中,但是大模型未能准确地提取出来,这通常发生在上下文中存在过多的噪音或冲突信息时。
问题要求以特定格式提取信息,例如表格或列表,然而大模型忽略了这个指示。
尽管大模型正常回答了用户的提问,但不够具体或者过于具体,都不能满足用户的需求。不正确的具体性也可能发生在用户不确定如何提问,或提问过于笼统时。
考虑一个问题,“文件 A、B、C 包含哪些关键点?”,直接使用这个问题检索得到的可能只是每个文件的部分信息,导致大模型的回答不完整。一个更有效的方法是分别针对每个文件提出这些问题,以确保全面覆盖。
Wenqi Glantz撰文《12 RAG Pain Points and Proposed Solutions》,又提了另外5个问题:
RAG管道中的数据摄取可扩展性问题是指当系统难以有效管理和处理大量数据时出现的挑战,从而导致性能瓶颈和潜在的系统故障。此类数据摄取可扩展性问题可能会导致摄取时间延长、系统过载、数据质量问题和可用性受限等问题。
根据用户的问题准确检索出所需的结构化数据可能很困难,尤其是当用户的问题比较复杂或比较模糊时,由于文本到 SQL 的转换不够灵活及当前大模型在有效处理这类任务方面仍然存在一定的局限性。
复杂的PDF文档中可能包含有表格、图片等嵌入内容,在对这种文档进行问答时,传统的检索方法往往无法达到很好的效果。我们需要一个更高效的方法来处理这种复杂的PDF数据提取需求。
在使用单一大模型时,我们可能会担心模型遇到问题,比如遇到 OpenAI 模型的访问频率限制错误。这时候,我们需要一个或多个模型作为备用,以防主模型出现故障。
如何有效地防止恶意输入、确保输出安全、保护敏感信息不被泄露等问题,都是每个AI架构师和工程师需要面对的重要挑战。
从RAG的工作流程来看,其中的各个环节均有着极大的优化空间。我们将从工作流程5个环节中,结合上述12个问题详细了解具体优化策略。
高性能RAG系统依赖于准确且清洁的原始知识数据。
一方面为了保证数据的准确性,需要优化文档读取器和多模态模型。特别是处理如CSV表格等文件时,单纯的文本转换可能会丢失表格原有的结构。因此,我们需引入额外的机制以在文本中恢复表格结构,比如使用分号或其他符号来区分数据。
另一方面也需要对知识文档做一些基本数据清洗,其中可以包括:
在RAG系统中,文档需要分割成多个文本块再进行向量嵌入。在不考虑大模型输入长度限制和成本问题情况下,其目的是在保持语义上的连贯性的同时,尽可能减少嵌入内容中的噪声,从而更有效地找到与用户查询最相关的文档部分。如果分块太大,可能包含太多不相关的信息,从而降低了检索的准确性。相反,分块太小可能会丢失必要的上下文信息,导致生成的回应缺乏连贯性或深度
。
在RAG系统中实施合适的文档分块策略,旨在找到这种平衡,确保信息的完整性和相关性
。一般来说,理想的文本块应当在没有周围上下文的情况下对人类来说仍然有意义,这样对语言模型来说也是有意义的。
在大多数情况下推荐的方法
。其通过重复地应用分块规则来递归地分解文本
。例如,在langchain中会先通过段落换行符(\n\n
)进行分割。然后,检查这些块的大小。如果大小不超过一定阈值,则该块被保留。对于大小超过标准的块,使用单换行符(\n
)再次分割。以此类推,不断根据块大小更新更小的分块规则(如空格,句号)。这种方法可以灵活地调整块的大小
。例如,对于文本中的密集信息部分,可能需要更细的分割来捕捉细节;而对于信息较少的部分,则可以使用更大的块。而它的挑战在于,需要制定精细的规则来决定何时和如何分割文本
。128大小的分块往往是最佳选择,在无从下手时,可以从这个大小作为起点进行测试
。过嵌入模型能够将文本转换成向量,显然不同的嵌入模型带来的效果也不尽相同,例如Word2Vec模型,尽管功能强大,但存在一个重要的局限性:其生成的词向量是静态的。一旦模型训练完成,每个词的向量表示就固定不变,这在处理一词多义的情况时可能导致问题。
比如, “我买了一张光盘”,这里“光盘”指的是具体的圆形盘片,而在“光盘行动”中,“光盘”则指的是把餐盘里的食物吃光,是一种倡导节约的行为。语义完全不一样的词向量却是固定的
。 相比之下,引入自注意力机制的模型,如BERT,能够提供动态的词义理解。这意味着它可以根据上下文动态地调整词义,使得同一个词在不同语境下有不同的向量表示。“光盘”这个词在两个句子中会有不同的向量,从而更准确地捕捉其语义。
有些项目为了让模型对特定垂直领域的词汇有更好的理解,会嵌入模型进行微调。但在这里我们并不推荐这种方法:
一方面其对训练数据的质量有较高要求,
另一方面也需要较多的人力物力投入,且效果未必理想,最终得不偿失。
在这种情况下,对于具体应该如何选择嵌入模型,我们推荐参考Hugging Face推出的嵌入模型排行榜MTEB。这个排行榜提供了多种模型的性能比较,能帮助我们做出更明智的选择。同时,要注意并非所有嵌入模型都支持中文,因此在选择时应查阅模型说明。
当在向量数据库中存储向量数据时,某些数据库支持将向量与元数据(即非向量化的数据)一同存储。为向量添加元数据标注是一种提高检索效率的有效策略,它在处理搜索结果时发挥着重要作用
。
例如,日期就是一种常见的元数据标签。它能够帮助我们根据时间顺序进行筛选。设想一下,如果我们正在开发一款允许用户查询他们电子邮件历史记录的应用程序。在这种情况下,日期最近的电子邮件可能与用户的查询更相关。然而,从嵌入的角度来看,我们无法直接判断这些邮件与用户查询的相似度。通过将每封电子邮件的日期作为元数据附加到其嵌入中,我们可以在检索过程中优先考虑最近日期的邮件,从而提高搜索结果的相关性。
此外,我们还可以添加诸如章节或小节的引用,文本的关键信息、小节标题或关键词等作为元数据。这些元数据不仅有助于改进知识检索的准确性,还能为最终用户提供更加丰富和精确的搜索体验。
元数据无法充分区分不同上下文类型的情况下,我们可以考虑进一步尝试多重索引技术。多重索引技术的核心思想是将庞大的数据和信息需求按类别划分,并在不同层级中组织,以实现更有效的管理和检索
。
这意味着系统不仅依赖于单一索引,而是建立了多个针对不同数据类型和查询需求的索引。例如,可能有一个索引专门处理摘要类问题,另一个专门应对直接寻求具体答案的问题,还有一个专门针对需要考虑时间因素的问题。这种多重索引策略使RAG系统能够根据查询的性质和上下文,选择最合适的索引进行数据检索,从而提升检索质量和响应速度。但为了引入多重索引技术,我们还需配套加入多级路由机制。
多级路由机制确保每个查询被高效引导至最合适的索引
。查询根据其特点(如复杂性、所需信息类型等)被路由至一个或多个特定索引。这不仅提升了处理效率,还优化了资源分配和使用,确保了对各类查询的精确匹配。
例如,对于查询“最新上映的科幻电影推荐”,RAG系统可能首先将其路由至专门处理当前热点话题的索引,然后利用专注于娱乐和影视内容的索引来生成相关推荐。
总的来说,多级索引和路由技术可以进一步帮助我们对大规模数据进行高效处理和精准信息提取,从而提升用户体验和系统的整体性能。
可以利用索引筛选数据,但说到底还是要从筛选后的数据中检索出相关的文本向量。由于向量数据量庞大且复杂,寻找绝对的最优解变得计算成本极高,有时甚至是不可行的。加之,大模型本质上并不是完全确定性的系统,这些模型在搜索时追求的是语义上的相似性——一种合理的匹配即可。从应用的角度来看,这种方法是合理的
。
例如,在推荐系统中,用户不太可能察觉到或关心是否每个推荐的项目都是绝对的最佳匹配;他们更关心的是推荐是否总体上与他们的兴趣相符。因此查找与查询向量完全相同的项通常不是目标,而是要找到“足够接近”或“相似”的项,这便是最近邻搜索(Approximate Nearest Neighbor Search,ANNS)。这样做不仅能满足需求,还为检索优化提供了巨大的优化潜力。
但是在”法律“、”医疗“、”金融“等垂直领域,大模型的这种不确定性,会带来致命的结果,因此LLM+RAG结合互补,以期望解决LLM在某些场景的短板。
在RAG系统中,用户的查询问题被转化为向量,然后在向量数据库中进行匹配。不难想象,查询的措辞会直接影响搜索结果。如果搜索结果不理想,可以尝试以下几种方法对问题进行重写,以提升召回效果:
通过这些方法,RAG系统能够更精准地处理和响应复杂的用户查询,从而提升整体的搜索效率和准确性。
把查询问题准备好,可以进入向量数据库进行检索。在具体的检索过程中,可以根据向量数据库的特定设置来优化一些检索参数,以下是一些常见的可设定参数:
最为关键和复杂的步骤是在向量数据库检索之上如何具体开发或改进整个系统的策略。这部分的内容足够写成一篇独立文章。为了保持简洁,我们只讨论一些常用或者新提出的策略。
检索评分(令牌)和反思评分(令牌)来提高质量
。它主要分为三个步骤:检索、生成和批评
。Self-RAG首先用检索评分来评估用户提问是否需要检索,如果需要检索,LLM将调用外部检索模块查找相关文档。接着,LLM分别为每个检索到的知识块生成答案,然后为每个答案生成反思评分来评估检索到的文档是否相关,最后将评分高的文档当作最终结果一并交给LLM。在完成语义搜索的优化步骤后,能够检索到语义上最相似的文档,但不知你是否注意到一个关键问题:语义最相似是否总代表最相关?答案是不一定
。例如,当用户查询“最新上映的科幻电影推荐”时,可能得到的结果是“科幻电影的历史演变”,虽然从语义上这与科幻电影相关,但并未直接回应用户关于最新电影的查询。
重排模型可以帮助我们缓解这个问题,重排模型通过对初始检索结果进行更深入的相关性评估和排序,确保最终展示给用户的结果更加符合其查询意图
。这一过程通常由深度学习模型实现,如Cohere模型。这些模型会考虑更多的特征,如查询意图、词汇的多重语义、用户的历史行为和上下文信息等。
举个例子,对于查询“最新上映的科幻电影推荐”,在首次检索阶段,系统可能基于关键词返回包括科幻电影的历史文章、科幻小说介绍、最新电影的新闻等结果。然后,在重排阶段,模型会对这些结果进行深入分析,并将最相关、最符合用户查询意图的结果(如最新上映的科幻电影列表、评论或推荐)排在前面,同时将那些关于科幻电影历史或不太相关的内容排在后面。这样,重排模型就能有效提升检索结果的相关性和准确性,更好地满足用户的需求。
在实践中,使用RAG构建系统时都应考虑尝试重排方法,以评估其是否能够提高系统性能。
大型语言模型的解码器部分通常基于给定输入来预测下一个词。这意味着设计提示词或问题的方式将直接影响模型预测下一个词的概率。这也给了我们一些启示:通过改变提示词的形式,可以有效地影响模型对不同类型问题的接受程度和回答方式,比如修改提示语,让LLM知道它在做什么工作,是十分有帮助的。
为了减少模型产生主观回答和幻觉的概率,一般情况下,RAG系统中的提示词中应明确指出回答仅基于搜索结果,不要添加任何其他信息。例如,可以设置提示词如:“你是一名智能客服。你的目标是提供准确的信息,并尽可能帮助提问者解决问题。你应保持友善,但不要过于啰嗦。请根据提供的上下文信息,在不考虑已有知识的情况下,回答相关查询。”
当然你也可以根据场景需要,也可以适当让模型的回答融入一些主观性或其对知识的理解。此外,使用少量样本(few-shot)的方法,将想要的问答例子加入提示词中,指导LLM如何利用检索到的知识,也是提升LLM生成内容质量的有效方法。这种方法不仅使模型的回答更加精准,也提高了其在特定情境下的实用性。
最后一步——LLM生成回答。LLM是生成响应的核心组件。与嵌入模型类似,可以根据自己的需求选择LLM,例如开放模型与专有模型、推理成本、上下文长度等。此外,可以使用一些LLM开发框架来搭建RAG系统,比如,LlamaIndex或LangChain。这两个框架都拥有比较好用的debugging工具,可以让我们定义回调函数,查看使用了哪些上下文,检查检索结果来自哪个文档等等。
建设RAG系统需要兼顾技术深度与工程实践,从检索精度、生成质量到系统稳定性均需精心设计。通过结合最新的优化策略与工具链(如Cursor、MCP技术),能够有效解决开发中的核心问题,构建高效、可靠且适应性强的RAG系统。随着多模态技术、大模型上下文理解、动态学习机制和隐私保护技术的不断成熟,RAG系统将在更多垂直领域场景释放其潜力,成为下一代智能应用的核心技术之一,同时为用户提供更加智能、可靠的服务。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2025-03-30
SuperRAG:超越RAG的布局感知图建模
2025-03-30
专利申请从2周到3天,Claude 3.7 Sonnet让我成为专利能手
2025-03-30
RAG没Rerank,等于开车没带方向盘
2025-03-30
一个轻量级 AI 自动标注 Excel 插件
2025-03-30
揭秘Embedding模型选型:如何用向量技术突破知识库的智能天花板?
2025-03-29
RAGFlow自动化脚本套件:自定义解析+回答质量评估+参数自动调优
2025-03-29
万字长文:说清MCP的前世今生+RAGFlow整合应用示例
2025-03-29
三种RAG部署方案:自购GPU硬件 vs 大模型一体机 vs 云端GPU
2024-10-27
2024-09-04
2024-07-18
2024-05-05
2024-06-20
2024-06-13
2024-07-09
2024-07-09
2024-05-19
2024-07-07
2025-03-30
2025-03-28
2025-03-27
2025-03-27
2025-03-25
2025-03-19
2025-03-18
2025-03-18