2024年,RAG(Retrieval-Augmented Generation)技术经历了从狂热到理性的蜕变,成为大模型应用领域不可忽视的关键力量。年初,AI的“无所不能”让市场充满乐观情绪,RAG被视为解决复杂问题的万能钥匙;然而,随着技术落地和实际应用的深入,行业逐渐回归理性,开始聚焦于小而难的具体场景,追求技术的实用性和稳定性。
作为大模型应用的创业者,我们见证了RAG在架构和技术细节上的快速迭代,也深刻感受到市场需求从“大而全”向“精而专”的转变。展望未来,RAG的价值将更加体现在实际应用中,成为推动AI落地的核心引擎。这一年,不仅是RAG技术的进化之年,也是从业者从探索到深耕的转折点。
RAG架构演变
根据RAG技术结构可以分成三类,代表了不同的技术复杂度,越复杂也代表实现难度越大。但是可能会收到更好的效果,适应更多的场景,这三类类型是:
-
Naive RAG 简单RAG,这就是大部分人都知道RAG,把文本分段,根据用户的Qurey,去查找分段,输入给模型,然后输出。但是这种方法 Too Simple, Some Time Naive。有各种问题,首先生硬的对文本分段就不科学,然后可能查询到的分段有可能和Qurey并不相关,再有输入给LLM的文本分段可能有大量的冗余、重复或者噪声信息,让模型不能输出和期望一致的内容。
-
Advanced RAG 高级RAG,针对简单RAG的不足,"高级"RAG进行了针对性的改善。主要是针对检索进行了改善,包括Preretrieval(检索前),Post-retrieval(检索后) 和Retrieval Process(检索中) 的各种改善方法(废话…)。检索前包括建立多种文档索引、利用滑动窗对文本进行分块;检索中包括多路召回,Embedding模型微调;检索后包括重排(Re-rank)等。
-
Modular RAG 模块化RAG,模块化方法并不局限在“检索”-“阅读”的框架,利用大模型自身的"反思"能力等,构建起RAG的新的范式。简单点说,上面两种方法都是一个单一的流水线模式,检索结束之后交给模型,然后模型输出结果。但是在论文中的Modular RAG方法中,递归的调用了LLM的能力,例如利用模型来反思、评估第一次输出,然后再输出新的结果。或者让模型自己决定什么时候调用检索工具。这其实有点像实现一个RAG Agent。论文表示这种模块化的 RAG 范式正逐渐成为 RAG 领域的趋势。
Retrieval-Augmented Generation for Large Language Models: A Survey
我们回顾去年年末到今年年末,发现RAG逐渐完成三个架构的演变,笔者也在RAG工作中参与了第一个和第二个架构的开发,其中代表项目分别是Chinese-LangChain
和TrustRAG
。
RAG框架开发
以下通过两个笔者参与的开源项目,来大致讲解Naive RAG和Advanced RAG
开源工作1:Chinese-LangChain
在2023年末,当时LLM概念盛行,RAG技术开始展露头脚,机缘巧合下笔者参加了一个线下黑客马拉松的活动,我在大约一天时间内开发了Chinese-LangChain项目,在Github进行了开源,当时收到了朋友圈和社区的关注,可谓捷足先登,在短时间内收获了2.7k累计的Star。
https://github.com/yanqiangmiffy/Chinese-LangChain
这个项目可以视为是Naive版本的RAG,在实现中比较简洁地实现了文档解析、索引构建、查询检索以及答案生成模块,并基于duckduck-go
引入联网检索,并提供了Gradio的演示代码。
从效果来看,Naive RAG可以基本可以满足演示的Demo需求,但是如何让 RAG 在更多场景和企业用起来,随着用户需求的增加,Naive RAG能力显现的捉襟见肘。
此阶段代表的RAG框架有早期的Langchain、Llama-Index等。
开源工作2:TrustRAG
在2024快速发展的RAG技术环境中**,Advanced RAG架**构因其显著的效果和相对易于实现的特点,占据着主流地位。
在实验室需求和工作中出发,我们将系统工作开源出一个项目TrustRAG,中间穿插了RAG优化相关组件,比如文档解析、文本切块、查询改写、内容压缩、向量提取、索引构建、答案生成以及答案引用等,可以理解为是Advanced级别的RAG框架。具体模块组件可以参考下图:
https://github.com/gomate-community/TrustRAG
当时国内开始出现一些比较欢迎的项目,我印象里是一个是网易的QAnything,之后是Infiniflow的ragflow,之后国内有很多开源的RAG框架,比如haystack、升级之后的Langchain等。TrustRAG改名之前叫GoMate,在6月份受到爱可可博主的关注转发,还是很幸运的!
下面是比较欢迎的RAG框架:
框架名称 | 文档切分 | 召回 | 检索 | 重排序 |
---|---|---|---|---|
RAGFlow | 强调文档的精细化解析,能够从复杂格式的非结构化数据中提取信息,提供基于模板的文本切片功能,文本切片过程可视化,支持手动调整。 | 基于多路召回,融合重排序,提供可靠的问答和有理有据的引用。 | 兼容各类异构数据源,支持丰富的文件类型,包括Word文档、PPT、Excel表格、PDF等。 | 提供有理有据的答案,降低幻觉(hallucination),答案提供关键引用的快照并支持追根溯源。 |
FastGPT+ | 提供自动数据预处理,支持手动输入、直接分段、LLM自动处理和CSV等多种数据导入途径,自动对文本数据进行预处理、向量化和QA分割。 | 支持混合检索和重排,提供强大的RAG引擎,能够高效地处理和检索大量数据。 | 采用直观的可视化界面,支持多种数据导入方式,自动化工作流程编排,提升检索效率。 | 支持工作流编排,基于Flow模块设计,提供简易模式和工具调用,提升重排序能力。 |
QAnything+ | 文档处理能力一般,主要依赖于现有的文档解析工具,未强调特定的文档切分技术。 | 强调Embedding与Rerank模型的联合使用提升文档召回质量,Rerank模块设计优秀。 | 采用Embedding技术进行检索,结合Rerank模型提高检索精度。 | Rerank模块设计优秀,能够有效提升文档召回质量。 |
MaxKB+ | 提供简单易用的界面,支持多种数据格式的导入和导出,内置知识库管理系统,便于用户管理和利用知识资源。 | 内置知识库管理系统,支持多种数据格式的导入和导出,便于用户管理和利用知识资源。 | 支持多种数据格式的导入和导出,内置知识库管理系统,便于用户管理和利用知识资源。 | 提供高效的Workflow设计,支持拖拽式操作,使得非技术人员也能快速上手。 |
Dify+ | 功能完善,支持从PDF、PPT和其他常见文档格式中提取文本,提供丰富的预设模板和集成工具。 | 支持跨知识库召回,提供丰富的召回模式,适用于复杂业务逻辑和数据处理需求。 | 提供丰富的预设模板和集成工具,支持多种检索模式,适用于复杂业务逻辑和数据处理需求。 | 支持工作流编排,提供丰富的预设模板和集成工具,适用于复杂业务逻辑和数据处理需求。 |
在实际效果中,估计大家有一个共同的认识,就是文档解析太难了,当时一度认为文档解析做好了,RAG效果会好很多,事实也是这样,包括我在TrustRAG框架开发的过程中参考了deepdoc以及QAnything项目的文档解析,这块工程量很大,不过说实话到现在也没有一个很完美统一的方案。不过下半年MinerU
、TextIn
、Doc2X
、PyMuPDF4LLM
等多模态文档解析框架的开源,给复杂文档的统一处理带来的希望,笔者也做了基于MinerU文档解析的PR并接受。
这些多模态开源框架处理的思路是将各种形式的文件转换成或者直接基于PDF,解析出来半结构化的Markdown内容,之后映射成结构化的Json内容。
框架名称 | 主要功能 | 支持的文档格式 | 输出格式 | 特点 |
---|---|---|---|---|
MinerU | 将PDF转换为机器可读格式,如Markdown、JSON,支持公式和表格的识别与转换。 | Markdown、JSON、LaTeX、HTML | 支持复杂公式解析,适用于科技文献的符号转换。 | |
Marker | 提取PDF文档内容,支持文本、表格和图像的解析。 | Markdown、JSON | 能将表格解析为Markdown结构,但在复杂表格处理上可能存在问题。 | |
PaddleOCR | 基于深度学习的OCR系统,支持多语言文本检测和识别。 | 图片、PDF | 文本、JSON | 具备文字识别和版面分析能力,但缺乏必要的后处理步骤。 |
Unstructured | 处理多种文档格式,提取文本和元数据,适用于非结构化数据的解析。 | PDF、DOCX、PPT、HTML等 | JSON、文本 | 支持多种文档格式的解析,适合处理非结构化数据。 |
Zerox | 基于GPT的OCR工具,将PDF、DOCX等文件转换为Markdown格式。 | PDF、DOCX、图像 | Markdown | 零配置,易于使用,支持批量处理,转换速度快。 |
Docling | 多格式文档解析和导出工具,支持高级PDF理解和OCR功能。 | PDF、DOCX、PPTX、XLSX、图像、HTML、AsciiDoc、Markdown | HTML、Markdown、JSON | 支持多种文档格式的解析,易于与LlamaIndex和LangChain集成。 |
OmniGen | 文档解析和生成工具,支持从多种格式的文档中提取内容并生成结构化数据。 | PDF、DOCX、PPTX、HTML等 | JSON、XML、Markdown | 支持多种文档格式的解析,提供结构化数据输出,适用于数据提取和内容生成。 |
由于相关技术限制以及系统需求的应对,TrustRAG有很多地方还需要继续完善,不过确实摸着石头过河完成了Advacned RAG模块开发,如果做到更加广泛的使用还需要完成企业级的数据支撑,接入相关向量数据库引擎以及API开发等工作,也希望大家多提建议和Issue。
相关模块技术的文章,论文和博客笔记有很多,笔者在这里不做过多赘述,建议大家可以根据需求找一些综述性文章阅读可以整体系统的了解,比如专门围绕查询改写《A Survey of Query Optimization in Large Language Models》。下面我们可以多多聊一些痛点和未来发展趋势。
RAG痛点
RAG的12个痛点
检索增强生成(RAG)技术虽然在提升内容准确性和相关性方面具有显著优势,但在实际应用中也存在一些痛点。根据参考资料,我们可以大致总结下存在的共性痛点以及解决方案:
-
内容缺失:当知识库中缺少上下文时,RAG系统可能会提供一个看似合理但不正确的答案,而不是表示不知道。解决方案包括清理数据和精心设计提示词。
-
错过排名靠前的文档:重要文档可能未出现在系统检索组件返回的顶部结果中,导致系统无法提供准确的响应。解决方案包括调整检索策略和嵌入模型调优。
-
不在上下文中 — 整合策略限制:文档整合长度限制超过LLM窗口大小,导致整合策略受限。解决方案是调整检索策略和嵌入模型调优。
-
文件信息未提取:文档中的关键信息未被提取出来。解决方案包括数据清洗、提示词压缩和长内容优先排序。
-
格式错误:输出格式与预期不符。解决方案是改进提示词、格式化输出和使用大模型的Json模式。
-
答案不正确:缺乏具体细节,导致特需求的答案不正确。解决方案是采用先进的检索策略。
-
回答不完整:回答不全面。解决方案包括查询转换和细分问题。
-
数据提取可扩展性:数据摄取的可扩展性问题。解决方案是并行处理和提升处理速度。
-
结构化数据QA:结构化数据问答问题。解决方案是链式思维表格包和混合自洽查询引擎包。
-
从复杂PDF中提取数据:从复杂PDF中提取数据困难。解决方案是嵌入式表格检索技术。
-
后备模型:需要一个后备模型策略。解决方案是Neutrino路由器或OpenRouter。
-
LLM安全性:大语言模型的安全性问题。这是一个需要持续关注和解决的问题。
下面是一些RAG落地过程中问题:
-
检索效率低下:
- 痛点描述: 在庞大的数据集中进行有效检索是一个挑战,尤其是当需要实时响应时。
- 相关问题: 如何优化检索算法以减少查询延迟?
-
信息融合困难:
- 痛点描述: 将检索到的信息与生成的内容无缝融合是一项复杂任务,需要精确的算法来确保信息的准确性和连贯性。
- 相关问题: 如何设计有效的信息融合策略?
-
上下文理解的局限性:
- 痛点描述: 模型可能难以准确理解查询的上下文,特别是在复杂或模糊的情境中。
- 相关问题: 如何提高模型对上下文的理解能力?
-
数据偏差和噪声:
- 痛点描述: 检索到的数据可能包含偏差和噪声,这会影响模型的输出质量。
- 相关问题: 如何识别并减少数据中的偏差和噪声?
-
答案准确性和可靠性问题:
- 痛点描述: 生成的答案可能不够准确或可靠,尤其是在需要精确事实性回答的情况下。
- 相关问题: 如何验证和提高生成答案的准确性?
-
可扩展性问题:
- 痛点描述: 随着数据量的增加,模型可能难以保持高性能和可扩展性。
- 相关问题: 如何确保模型能够处理大规模数据?
-
资源消耗:
- 痛点描述: RAG技术通常需要大量的计算资源,这在资源受限的环境中是一个挑战。
- 相关问题: 如何优化模型以减少资源消耗?
-
隐私和安全问题:
- 痛点描述: 处理敏感数据时,需要确保用户隐私和数据安全。
- 相关问题: 如何实现隐私保护的数据处理?
在知乎话题大家觉得做一个大模型检索增强生成(RAG)系统,最难搞定的是那部分工作?下,我们也可以看到一些共性的回复,比如最头疼的两个问题是:数据清洗和权限区分、文档的处理、短文本的语义挖掘是最难搞定的、图表理解等。
整体感觉RAG下半年可谓是:一周出Demo,半年用不好。在实际场景中可以说很快打通的一个RAG流水线,并进行演示效果。在Advanced的模块加持下,我们可以针对具体模块进行优化,比如文档解析、检索等,虽然流程繁琐,但是也可以取得一个比较好的效果。
不过在此也抛出一个问题,相比Kimi、豆包、ChatGPT这种工具来说,对于中小开发团队或者研究人员来说,怎么定制化一个比较靠谱的RAG系统。为什么对于Kimi等,我们随便上传一个文档,它们回答的都还算可以,为什么我们基于自己的RAG模块或者开源框架总是还是面临各种形形色色的问题。笔者猜测:
- (1)数据源充足,除了给定上传文件,还可以支持联网搜索,比如bing作为额外背景知识补充;
- (2) 文档解析几乎完美,内容自己积累了相关文档解析技术,或者多模态统一处理的框架,能够覆盖大部分文档文件的解析与清洗,并快速形成结构化内容
- (3) 强大大模型加持,因为在一些实现过程中,有时候Demo级别尝试是用一个小的模型,比如9b、14b大一点就是32b或者72b,个人认为越大的模型兜底能力越强,起码生成的答案会大差不差,遇到噪音或者不相关信息拒识率很高,幻觉很小。
- …
RAG发展趋势
GraphRaG
GraphRaG是一种结合了图结构知识索引与检索能力的RAG技术。它在处理涉及复杂实体关系、语义推理与多步逻辑关联的查询上更具优势,特别是在隐式事实查询的任务中表现出色。
GraphRaG通过构建Graph结构的知识索引,能够更广泛适配多样化场景,不同索引方式在不同数据类型和查询需求下各有优势,融合多种索引技术后,RAG系统能够更广泛适配多样化场景。
多模态RAG
多模态RAG技术将RAG的能力拓展到了文本之外的更广阔领域。通过集成图像、视频等其他模态数据,RAG系统可以访问更加广泛的源材料,实现文本和视觉数据之间的无缝交互。
这不仅有助于系统产生更加彻底和细致的响应,还为未来实现多模态信息处理及跨模态推理奠定了坚实基础。例如,DSE(Document Screenshot Embedding)是一个不使用广义OCR的多模态RAG方法,直接把原始文档的扫描图片,切片后,使用视觉语言模型的编码器编码,验证了这一想法的可行性。
AgenticRAG
AgenticRAG,即基于代理的RAG实现,通过引入创新的代理框架,彻底改变了我们回答复杂问题的方式。与传统上完全依赖LLM(大型语言模型)的方法不同,AgenticRAG利用智能化代理来高效解决那些需要复杂规划、多步骤推理和利用外部工具的棘手问题。
这种技术赋予了LLM和RAG前所未有的智能化能力,通过引入基于人工智能的智能代理,这些系统不再是被动响应查询请求,而是能够主动分析任务复杂性、评估当前信息状态,并战略性地选择最有效的工具和方法进行多步骤的数据检索和处理。
参考资料
- RAG的2024—随需而变,从狂热到理性(上)
- RAG的2024—随需而变,从狂热到理性(下)
- 【活动回顾】数聚大咖 —《RAG:AI落地的低垂果实》
- AI开发者工具(1)——2024 年 8 个开源 RAG 项目对比:功能解读、应用场景分析及优缺点比较
- RAG年终总结之12篇综述:从2022到2024看架构、策略、评测及演化
- RAG的2024—随需而变,从狂热到理性
- 万字长文梳理 2024 年的 RAG
- 12 个 RAG 痛点和建议的解决方案-解决检索增强生成的核心挑战
- 大模型RAG难点、痛点、常见面试题
- 大家觉得做一个大模型检索增强生成(RAG)系统,最难搞定的是那部分工作?