企业级 RAG 全链路优化关键技术

2024 云栖大会 - AI 搜索企业级 RAG 全链路优化关键技术

在2024云栖大会上，阿里云 AI 搜索研发负责人之一的邢少敏先生带领大家深入了解如何利用 RAG 技术优化决策支持、内容生成、智能推荐等多个核心业务场景，为企业数字化转型与智能化升级提供强有力的技术支撑。并解读了企业级 RAG 全链路优化的关键技术，其主要内容分为四个部分：企业级 RAG 关键链路、企业级 RAG 效果优化、企业级 RAG 性能优化、企业级 RAG 应用实践。

企业级 RAG 关键链路

1. RAG 链路图

RAG 的定义就是 Retrieval-Augmented Generation（检索增强生成），简单来说就是用搜索结果引导 LLM 的生成。下面是我们阿里云 AI 搜索开放平台的一个 RAG 的链路图，红色的部分是离线链路，蓝色的部分是在线链路。

2. 企业大规模落地 RAG 核心问题

我们团队经过了很长时间对 RAG 的研发，总结出了企业 RAG 落地的关键点，分别是效果、性能和成本。

效果：今天很多企业并没有大规模的落地 RAG，或者说是在一些关键场景上没有去使用 RAG，是因为企业担心用了以后，会因为效果问题，影响他们核心场景的业务。所以效果问题是现在 RAG 落地最关键的因素。
性能：在 RAG 链路里很多环节是需要使用大模型的，比如说向量化、文档解析，最后大模型的生成、大模型 Agent 等。这样整个链路多次调用大模型，会导致离线和在线性能都会有不同程度的下降。比如说像 GraphRAG ，一个30K 的文档需要将近1个小时时间才能把数据处理好，这样的话很难在一个生产环境中去落地。
成本：相对于其他的应用来说，RAG 应用需要去多次调用大模型，而大模型背后就是 GPU , 但 GPU 资源是紧缺和昂贵的，这就不可避免的导致这类应用比其他应用的成本高很多，所以很多客户无法接受这个成本。

企业级 RAG 效果优化

1. RAG 优化效果—数据提取和解析

首先在效果层面，离线链路里第一个优化点就是文档解析。文档有很多格式，比如说 PDF、Word 、PPT,等等，还有一些结构化数据。然而最大的难点还是一些非结构化的文档，因为里面会有不同的内容。比如说像表格、图片，这些内容 AI 其实是很难理解的。在通过长期大量的优化以后，我们在搜索开放平台里面提供了文档解析服务，支持各种各样常见的文档格式和内容的解析。

2. RAG 优化效果—文本切片

文档解析完，从文档里面能够正确的提取出内容后，接下来就可以进行文本切片。切片有很多种方法，最常见的有层次切分，把段落提取出来，对段落里面的内容再进行段落级的切片；还有多粒度切分，有时除了段落的切片，还可以增加单句的切片。这两种切片都是最常用的。另外对于一些场景，我们还可以进行基于大模型的语义切片，就是把文档的结构用大模型处理一遍，然后再提取一些更精细的文档结构。那么经过了多种切片以后，我们就可以继续进行向量化了。

3. RAG 优化效果—混合检索

阿里云研发了统一向量化模型，这个向量化模型能够同时产出稠密向量和稀疏向量，产出向量以后就可以进行混合检索，然后重排得到检索结果。并且这个向量化模型于今年3月份，在中文向量化的榜单上 C-MTEB 上拿到了第一名。

4. RAG 优化效果—NL2SQL

前面讲的三个是核心的离线链路，接下来就进入在线链路，在线链路的第一步是 query 的理解，query 理解通常情况下我们其实是用向量的，也就是说 query 进来以后，需要做简单处理先向量化再去召回。但是有些场景上，向量召回之后也是解决不了问题的。比如说我们要查询所有的电商企业里员工少于50人的企业的名称，对于小于50人这样一个数据，用向量的话，小于50人、小于40人、小于49人其实是很相似的，这是很难解决的问题。

对于这类场景，我们可以将自然语言转为一个 SQL ，在 SQL 数据库中进行精确的查找。还有一种就是查询实体和关系的，我们可以将自然语言转换成图查询语句在图数据库中进行查询，最后得到准确的结果。

5. RAG 优化效果—基于 LLM 的Rerank

在 query 处理完了以后，通常情况下在向量召回这一路还会做 Rerank 。Rerank 模型一开始的时候，我们使用开源的 Bge-reranker，这个也在整个效果上起到了很大的一个作用。

近期我们基于 Qwen 模型研发了新的 Rerank 模型，这个新的 Rerank 模型在各个方面都有了提升。我们把它用在了阿里云的 Elasticsearch AI 搜索的解决方案中，发现整体效果提升了30%。

另外也可以看到图表中，在这八个数据集三种不同指标上，效果相对于开源的 Bge-reranker 有很明显的提升。做完了 Rerank 以后，召回链路就已经完成了。

6. RAG 优化效果—大模型微调和测评

召回链路完成了以后，就进入了大模型生成。我们最开始用初版 Qwen 大模型的时候，大模型的各种能力其实不太完善，所以我们更多的是去优化大模型的能力。比如说使用 NL2SQL 时，需要去用大量的数据去微调大模型 NL2SQL 的能力。而随着大模型的快速迭代，能力变得越来越强。

这时我们就把精力转变到去优化大模型的幻觉率，让幻觉率不断的降低。我们在 Qwen 14b 的模型基础上进行微调，微调以后在客户场景上已经能够接近 GPT-4O 的模型效果。为什么要在一个14b 的模型微调上去呢？因为14b Qwen 模型会比72b Qwen 的模型要小很多，它会带来很大的性能提升。在效果打平的情况下，有很大的性能提升，其实是有很好的落地优势。

7. RAG 优化效果—Agent 解决复杂问题

以上链路上的解决方案，能帮我们处理一些简单的问答场景，但对于复杂的问答场景，还是不能解决。

比如像以下这两个例子，这是一个多步推理和多次搜索才能解决的问题。我们以第二个为例，问“黎曼的生肖是什么？”，首先第一次搜索会搜索出来：黎曼出生在1826年。然后大模型进行思考，会发起第二次搜索：这个时候1826年的对应的生肖是什么？在得到1826年的生肖是狗，大模型会最后做一个总结，黎曼的出生于1826年，生肖是狗。当然有些大模型是能够把这个年份和生肖对应起来的，可以直接回答，不用二次搜索。左边这个例子同样也需要大模型去做思考，两次检索才能得出结果。这就是我们用 Agent 解决复杂问题的例子。

8. RAG 优化效果—Agent 效果和挑战

我们阿里云团队在一个特定场景上进行了测试，使用原生的 RAG ，能解决78%的问题，平均搜索次数是1次。这个比较好理解，就是 RAG 通常搜索一次，然后生成答案。而在用了 ReAct 以后，能解答85%的问题，平均搜索1.7次。然后我们对 ReAct 进行了一些改进，Search-First ReAct 就是先搜索再让大模型去思考，这样的话能解决90%的问题，平均速度次数要减少到1.2次。所以可以看到使用了 Agent 之后，能够有效的减少搜索的这个次数，并且能够提升解答率，整体效果有了明显的提升。

当然目前 Agent 也面临一些挑战。比如，无法解决全部问题：一些复杂问题，暂时只能解决70%的问题，还有30%的问题无法解决，这还需要我们继续研究。另外还有性能下降：由于使用 Agent 之后，需要多次与大模型交互，所以查询性能会下降。另外大模型进行 Agent 推理的时候，如果第一步的推理总结错了，那么再往后继续推理的时候，就会错上加错，所以幻觉率可能就会变得很高。当然这些问题并不是不能解决，只是需要经过迭代优化。

9. RAG 效果优化迭代

最早的时候，我们使用初代的 Qwen 加上向量检索，能够获得48%的问题解决率。然后去做 Prompt 工程、多路召回、层次切片，能够做到61%。后来做的 Qwen SFT 提升到了72%。再后来加了Rerank，做了向量模型的优化和多粒度的切片。到现在我们在文档解析领域做了大量的优化，加上 Agent 的优化，再加上 CPU 的优化还有一定的语义切片等等一系列的优化叠加，问题解决率已经提升到了95%。因为面临的客户场景是非常复杂的，这一路走来的也很不容易。

企业级 RAG 性能优化

效果优化接下来就是性能层面的优化，在性能上我们首先需要看向量检索，向量检索我们有一个 VectorStore CPU 算法，还有个VectorStore GPU算法。

1. RAG 性能优化—VectorStore CPU 图算法

CPU 的算法使用的是 HNSW 算法，在这个算法基础上，我们做了图构建和检索两方面的优化，同时还有大量工程上的优化。优化完成以后 CPU 算法的性能，可以做到同类产品的2倍左右。大家可以在云上直接去搜索我们 Open Search 的向量检索版，然后去测试它的性能，以下是整个CPU的算法。

2. RAG 性能优化—VectorStore GPU 图算法

GPU 图算法使用的是 Nvidia 的算法，在实现了这个算法后我们带来的收益是在 Nvidia T4 的卡上能够有3至6倍的性能提升，在 Nvidia 的 A100/A800/H100 这些高性能卡上有30倍到60倍的性能提升。不过这样的一个性能提升，由于用了 GPU，同时也带来了一个成本的上升。

对于这个场景，我们做了一些测试，结论是在 QPS 很高的时候，或者说是达到一定阈值的时候，我们使用 GPU 的性价比会比使用 CPU 的性价比更高，大概的预值是在3000 QPS 左右。如果说我们的 QPS 很高，几千或者上万的时候，我们使用 GPU 就会有性价比优势。但是如果我们 QPS 很低的时候， GPU 算法是没有性价比优势的，以上是向量检索方面我们做的工作。

3. RAG 性能优化—大模型推理加速

我们使用缓存、大模型量化、多卡并行等多种不同的方法对大模型进行推理加速。

现在能做到的是在14b 的 Qwen 模型上，能够在1到3秒的时间内生成一个200 token 的答案，然后72b 的 Qwen 模型上能够在4秒左右的时间内生成一个200 token 的答案。因为随着 token 数的增加，时间也是增加的，如果平均答案长度在200 token 的话，能做到在3到4秒内生成答案，这就是用了大模型的推理加速的收益。

4. RAG 成本优化—大模型的微调

为了降低大模型微调的成本，我们研发了基于 Lora 的大模型微调。

微调客户模型时，如果一个卡给一个客户，这个客户就需要独立承担这张卡的成本，但是我们如果把多个客户的模型微调放在一张卡上，就可以节约成本。我们现在把40到50个客户的模型微调放在一张卡上，把原来每个月4000的微调成本降低到每个月100，这样成本降低为原来的40分之1。

Lora 实现方式有两种，一种是单卡 Lora，一种是多卡 Lora 。单卡Lora就是每张卡放客户的40-50个模型，多客户共享单卡。多卡 Lora 就是说把所有的模型都切开，模型切片放在多张不同的卡上。这是实现方式的不同。

企业级 RAG 应用实践

1. 企业级 AI 搜索开放平台

企业级 AI 搜索开放平台是把上面介绍的各种技术能力，以微服务的方式在一个服务广场上暴露出来。

首先它有很多的微服务，像文档解析、向量化、NL2SQL、LLM Agent、LLM 评测、LLM 训练、LLM 推理等都以微服务的形式暴露出来。用户可以用 API 的方式去调用。除了使用 API 调用单个服务之外，用户还可以使用 SDK 把微服务串联起来，然后串联一个场景。

除了支持阿里云的 SDK 之外，我们还支持 OpenAI SDK 、LangChain SDK、Llamalndex SDK。也就是前面我们提到的开源生态。这个平台就是为了让客户使用这些 SDK 或者用 API 调用的方式将这些微服务串联起来，去开发各种不同的场景，比如多模态搜索、 RAG问答、还有各种 AI 搜索相关的一些场景。

我们现在是支持 Havenask 引擎和 Elasticserach 引擎，后续的话会我们还会支持关于 GraphCompute 这样的图引擎和 Milvus 这样的向量引擎。

在最底下还会有一个统一的多模态数据管理。这个数据管理会支持像 PDF、Word、PPT 非结构化的文档，也支持数据湖、数据库的对接，还有 OSS 、HDFS 这些存储的对接。那么为什么要做数据层呢？这是因为做一个平台，如果让用户把自己的数据往这上面去搬迁的话，搬迁成本是很高的。如果有一个统一的数据管理层，就可以让客户把自己的数据库、数据源直接对接到平台，不需要迁移，直接在平台上开发应用场景。

2. 应用场景

我们在平台上还开发出来的，还有多模态搜索和多模态 RAG 的场景。我们需要去对接平台上的几个服务，比如向量化，图片理解等等，然后去串联出一个多模态搜索和多模态 RAG 的场景。

如果有一个复杂的 RAG 问题，在离线链路，会将一个 PDF 先把它处理成一个Markdown，然后这个 Markdown 会切成几个切片，最后这些切片进行向量化，这是搜索开放平台 RAG 的离线流程。

在线链路的话，会进行首次检索，把问题搜索出两个切片，再进行总结，然后进行推理，生成子问题进行二次检索，并进行切片再做二次总结。在经历了两次的 agent 的搜索以后再得到一个最终总结。

3. OpenSearch LLM 版

除了面向开发者的搜索开放平台以外，我们还有 OpenSearch LLM 版。这个产品可以在三分钟搭建一个 RAG 服务。基本上只需要用户上传数据测试即可，此产品拥有基于 NL2SQL 可以基础表格问答的能力，以表格方式输出、推荐等等。

最后是我们依托 AI 搜索开放平台和 Elasticsearch Inference API 、Ingest API 框架的实现。在 ES 的离线链路、在线链路里也可以引入搜索开放平台，使用 Elasticsearch 的 AI 搜索的使用方式是和原生的使用方式，没有任何区别，这兼容了用户习惯。这些能力大家在阿里云 Elasticsearch 8.13 的版本、 Elasticsearch 8.16 的开源版本里都能看到。
读者福利：如果大家对大模型感兴趣，这套大模型学习资料一定对你有用

对于0基础小白入门：