前言
在大语言模型(LLM)飞速发展的今天,LLMs 正不断地充实和改进我们周边的各种工具和应用。如果说现在基于 LLM 最火热的应用技术是什么,检索增强生成(RAG,Retrieval Augmented Generation)技术必占据重要的一席。RAG 最初是为了解决 LLM 的各类问题而产生的,但后来大家发现在现阶段的企业痛点上,使用 RAG 好像是更好的解决方案。在介绍 RAG 之前,我们先来看一下现在 LLM 存在的问题。
LLM 的问题
尽管 LLM 拥有令人印象深刻的能力,但是它们还面临着一些问题和挑战:
幻觉问题:大模型的底层原理是基于概率,在没有答案的情况下经常会胡说八道,提供虚假信息。
时效性问题:规模越大(参数越多、tokens 越多),大模型训练的成本越高。类似 ChatGPT3.5,起初训练数据是截止到 2021 年的,对于之后的事情就不知道了。而且对于一些高时效性的事情,大模型更加无能为力,比如帮我看看今天晚上有什么电影值得去看?这种任务是需要去淘票票、猫眼等网站先去获取最新电影信息的,大模型本身无法完成这个任务。
数据安全:OpenAI 已经遭到过几次隐私数据的投诉,而对于企业来说,如果把自己的经营数据、合同文件等机密文件和数据上传到互联网上的大模型,那想想都可怕。既要保证安全,又要借助 AI 能力,那么最好的方式就是把数据全部放在本地,企业数据的业务计算全部在本地完成。而在线的大模型仅仅完成一个归纳的功能,甚至,LLM 都可以完全本地化部署。
解决这些挑战对于 LLMs 在各个领域的有效利用至关重要。一个有效的解决方案是集成检索增强生成(RAG)技术,该技术通过获取外部数据来响应查询来补充模型,从而确保更准确和最新的输出。主要表现方面如下:
- 有效避免幻觉问题:虽然无法 100% 解决大模型的幻觉问题,但通过 RAG 技术能够有效的降低幻觉,在软件系统中结合大模型提供幂等的 API 接口就可以发挥大模型的重要作用。
- 经济高效的处理知识&开箱即用:只需要借助信息检索和向量技术,将用户的问题和知识库进行相关性搜索结合,就能高效的提供大模型不知道的知识,同时具有权威性。
- 数据安全:企业的数据可以得到有效的保护,通过私有化部署基于 RAG 系统开发的 AI 产品,能够在体验 AI 带来的便利性的同时,又能避免企业隐私数据的泄漏。
上图展示了 RAG 如何使 ChatGPT 能够提供超出其初始训练数据的精确答案。
什么是 RAG
说了这么多,下面我们来介绍一下什么是 RAG。
RAG 是检索增强生成(Retrieval Augmented Generation)的简称,它为大语言模型 (LLMs) 提供了从数据源检索信息的能力,并以此为基础生成回答。简而言之,RAG 结合了信息检索技术和大语言模型的提示功能,即模型根据搜索算法找到的信息作为上下文来查询回答问题。无论是查询还是检索的上下文,都会被整合到发给大语言模型的提示中。
RAG 的架构如图中所示。它既不是一个特定的开源代码库,也不是某个特定的应用,是一个开发框架。
完整的 RAG 应用流程主要包含两个阶段:
- 数据准备阶段:(A)数据提取 -> (B)分块(Chunking) -> (C)向量化(embedding) -> (D)数据入库
- 检索生成阶段:(1)问题向量化 -> (2)根据问题查询匹配数据 -> (3)获取索引数据 -> (4)将数据注入 Prompt -> (5)LLM 生成答案
下面让我们展开介绍一下这两个阶段的关键环节。
数据准备阶段
数据准备一般是一个离线的过程,主要是将私有数据向量化后构建索引并存入数据库的过程。主要包括:数据提取、文本分割、向量化、数据入库等环节。
- 数据提取:将 PDF、word、markdown、数据库和 API 等多种格式的数据,进行过滤、压缩、格式化等处理为同一个范式。
- 分块(Chunking):将初始文档分割成一定大小的块,尽量不要失去语义含义。将文本分割成句子或段落,而不是将单个句子分成多部分。有多种文本分割器实现能够完成此任务。比如根据换行、句号、问号、感叹号等切分文本,或者以其他的合适大小的 chunk 为原则进行分割。最终将语料分割成 chunk 块,在检索时会取相关性最高的 top_n。
- 向量化 (embedding):将文本数据转化为向量矩阵的过程,该过程会直接影响到后续检索的效果。常用的 embedding 模型:moka-ai/m3e-base、GanymedeNil/text2vec-large-chinese,也可以参考 Hugging Face 推出的嵌入模型排行榜 MTEB Leaderboard。
- 数据入库:数据向量化后构建索引,并写入向量数据库的过程可以概述为数据入库,适用于 RAG 场景的向量数据库包括:facebookresearch/faiss(本地)、Chroma、Elasticsearch、Milvus 等。一般可以根据业务场景、硬件、性能需求等多因素综合考虑,选择合适的数据库。


