微信扫码
与创始人交个朋友
我要投稿
大规模语言模型(LLMs)已经成为我们生活和工作的一部分,它们以惊人的多功能性和智能化改变了我们与信息的互动方式。
然而,尽管它们的能力令人印象深刻,但它们并非无懈可击。这些模型可能会产生误导性的“幻觉”,依赖的信息可能过时,处理特定知识时效率不高,缺乏专业领域的深度洞察,同时在推理能力上也有所欠缺。
在现实世界的应用中,数据需要不断更新以反映最新的发展,生成的内容必须是透明可追溯的,以便控制成本并保护数据隐私。因此,简单依赖于这些“黑盒” 模型是不够的,我们需要更精细的解决方案来满足这些复杂的需求。正是在这样的背景下,检索增强生成技术(Retrieval-Augmented Generation,RAG)应时而生,成为LLM时代的一大趋势。
从上图可以看出基础RAG架构的流程是十分简单的,其最大的特点是数据单向流通。因此搭建一个这样的系统是十分快捷的,但离真正能投入到生产环境中使用还是很远的。为了增强原有架构的文档召回率和系统鲁棒性,其优化路径大致有两条:增加召回管道和增加反馈机制。增加召回管道就是查询变换(子查询、rag-fusion)、混合检索这类通过多路召回来最大化召回率的优化方法;增加反馈机制就是rerank、后退提示、self-rag这类基于原始结果进行优化来最大化准确率的优化方法。
通过这两条路径,原来的RAG架构的数据和信息不再是单向流通,而是多向且并行流通。
为了给读者重呈现一个清晰的优化思路,本文将按照数据流动的方向从文本预处理、文本分块、嵌入、检索和生成等环节依次介绍各个优化方法。
不管RAG系统结构怎样复杂,由于其数据驱动的特性,高信噪比的数据仍然是十分重要的。在检索之前对原始数据的优化包括以下方法:
通常被检索知识库中的数据量是远超于LLM所能接受的输入长度的,因此合理的分块(Chunking)应尽可能做到在不超出LLM输入长度限制的情况下,保证块之间的差异性和块内部的一致性。当然这是最理想的状态,在实际应用中,可能有一篇文档像散文一般,不同段落之间没有明显内容区别,段落内部又特别地“散”,整篇文档又特别地长。当然我们不可能先验地将文本按内容完美分块,毕竟下游还有LLM这样智能的模型可以发挥其“智慧”来回答用户问题,我们提供的块不过是“提示”。但我们仍然还是需要尽可能提供有用的信息给LLM,而不是提供无关的信息分散其注意力。因此,可以采用以下高级的分块方法:
\n\n
)进行分割。然后检查这些块的大小,如果大小不超过一定阈值,则该块被保留。对于超过阈值的块,使用单换行符(\n
)再次分割。以此类推,不断根据块大小更新更小的分块规则(如空格,句号)。这种方法可以灵活地调整块的大小。例如,对于文本中的密集信息部分,可能需要更细的分割来捕捉细节;而对于信息较少的部分,则可以使用更大的块。分块还有一个因素比较重要,就是块的大小。除了嵌入模型,文档的类型和用户查询的长度及复杂性也是决定分块大小的重要因素。处理长篇文章或书籍时,较大的分块有助于保留更多的上下文和主题连贯性;而对于社交媒体帖子,较小的分块可能更适合捕捉每个帖子的精确语义。如果用户的查询通常是简短和具体的,较小的分块可能更为合适;相反,如果查询较为复杂,可能需要更大的分块。实际场景中,我们可能还是需要不断实验调整,在一些测试中,128大小的分块往往是最佳选择,在无从下手时,可以从这个大小作为起点进行测试。
接下来就是数据处理的最后一个环节,相当于数据的类型转换,即对文本数据使用嵌入(Embedding)模型进行向量化(Vectorization),以便于在检索阶段使用向量检索(Vector Retrieval)。嵌入阶段有以下几个可以优化的点:
在实际环境中,可能由于用户的表述多样性亦或是模糊的,导致在检索阶段召回率和准确率较低,这时就需要对查询做一个优化,能够规范和丰富查询所包含的信息,便于在系统中检索到与用户相关的文档。对查询的优化方法有以下几个:
检索(Retrieval)最终的目标就是获取最相关的文档或者保证最相关的文档在获取的文档列表中存在。为了达成这个目标,该环节有以下几个优化方法:
检索后处理这个概念还是很宽泛的,是对检索结果进行进一步的处理以便于后续LLM更好的生成,比较典型的就是重排序(Rerank)。向量检索其实就是计算语义层面的相似性,但语义最相似并不总是代表最相关。重排模型通过对初始检索结果进行更深入的相关性评估和排序,确保最终展示给用户的结果更加符合其查询意图。实现重排序除了可以提示LLM进行重排,更多的是使用了专门的重排序模型(例如闭源的有Cohere,开源有BAAI和IBM发布的模型)。这些模型会考虑更多的特征,如查询意图、词汇的多重语义、用户的历史行为和上下文信息,从而保证最相关的文档排在结果列表的最前面。
在生成(Generation)阶段的优化更多的是考虑用户体验,有以下几点可以供参考:
以上这些方法就是针对基础RAG在各个环节的优化方法,在实际开发过程中并不是所有方法都是有效的,不同问题有不同的解决方案,针对应用场景选择合适的优化方法组合才能最大限度发挥RAG的作用。
这里再贴一个Github链接:https://github.com/Jenqyang/LLM-Powered-RAG-System
收集了一些优秀的RAG项目以及开发框架,欢迎Star~✨
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-11-13
RAGCache:让RAG系统更高效的多级动态缓存新方案
2024-11-13
Glean:企业AI搜索,估值46亿美元,ARR一年翻4倍
2024-11-12
从安装到配置,带你跑通GraphRAG
2024-11-12
蚂蚁 KAG 框架核心功能研读
2024-11-12
【RAG】浅看引入智能信息助理提升大模型处理复杂推理任务的潜力-AssisTRAG
2024-11-12
体验完百度世界2024上的iRAG,我觉得AI绘图也可以没有幻觉了。
2024-11-12
提升RAG文档效率,10种有效策略
2024-11-12
揭秘RAG:全方位解析RAG检索中的意图识别,如何助力智能问答
2024-07-18
2024-07-09
2024-07-09
2024-05-05
2024-05-19
2024-06-20
2024-07-07
2024-07-07
2024-07-08
2024-07-09
2024-11-06
2024-11-06
2024-11-05
2024-11-04
2024-10-27
2024-10-25
2024-10-21
2024-10-21