构建基于 Elasticsearch 的企业级 AI 搜索应用  

摘要：本文整理自Elastic首席解决方案架构师朱杰老师在云端问道12期方案教学关于构建基于 Elasticsearch AI 搜索实现RAG应用的分享。

本次主题是基于阿里云上的 Elasticsearch AI 搜索，实现 RAG 的整套的方案。

先作为理论部分，首先介绍整个 RAG 的整体的流程，RAG 的整体流程并不简单，主要和准确度是有高度关系的。

一、流程阶段划分：

1.第一阶段

绿色的流程是属于离线的流程，就是企业知识库，为达到比较好的效果，需要对知识库的文档进行加工，它并不是非常简单的把文字抽取出写到 Elasticsearch。首先要保证能够从各种各样的文档中能够抽取出，还要有很好的策略对它进行长段的文本进行切分，之后构建索引，索引也会是向量和普通的文本的搜索，或者是稀疏的索引联合构建的索引，写到 Elasticsearch 里边

2.第二阶段

中间流程属于查询之前的流程，如果只输入关键词查询，很可能搜索质量并不好，特别是搜索比较简短，并没有很明确的告知意图时，是需要利用很多大语言模型的能力对原始的问题进行意图的识别，会对问题进行各种各样的分类，基于分类进行原始问题的扩充改写，能够让所问的问题会更加的明确，进行问题的向量化，可能会把原始的问题和向量化以后的整个内容都交给 Elasticsearch，做多路的召回。

3.第三阶段

黄色流程就是召回和重排，最后交给大语言模型的流程，很明显的注意到现代的 RAG 架构一般都是会采用多路召回的架构，并不是单纯的向量，因为单纯向量在实际做的效果当中不理想，所以往往会结合稀疏向量和的稠密向量甚至是 BM25 的多路召回，因为有现在大语言模型，包括现在很多基于 Bert 架构的模型的赋能，现在可以借助于非常好的重排的模型，对于多路召回的结果再进行语义上的重排序，能够让内容能够更加精准的符合提的问题。最后交给大语言模型，这个地方对于提示词的各种优化也是比较重要的。

在整个上面三个流程之外，还可以看到两个非常重要关键的概念，一个是评测的指标，因为评测的指标就是最终的问题，和回答的准确度的问题，往往需要建立量化的指标，有指标之后，才能够进行上面每一步的优化的调优能够让指标朝着越来越高的准确度走。如果没有量化的评价指标，很难讲前面做的很多的优化有效果，最后交给大语言模型时，问题就是往通用的大语言模型，往往在针对行业时，回答都可能有些问题，往往会涉及到对于基础模型的微调，能够适应更加行业的问题，所以现在的图就是整个 RAG 的整体的流程。

前面的整体流程对应的每个环节是都非常复杂，现在阿里云上 AI 搜索平台正是为解决之前它的整体的流程很复杂，每一步都需要非常深度的调优和知识，都非常复杂，可以看到刚才的离线流程，里边就会涉及到如何切片，如何数据提取等，这里边的每部分都涉及到很多的算法和优化，已经相当于独立的微服务，可以直接调用引擎层面，也会适配很多的引擎，可以看到在 Query 的对应中间的流程，也已经有对应的解决方案，在最底下可以看到它不仅是传统的文档等，对于大数据的接入也做的非常的好，在云上可以做到一站式，这是现在AI搜索的一张整体的大图。

二、RAG

举例讲所有做 RAG 的第一步就是对于知识库文档的抽取的动作，抽取的动作包含很多的优化的细节，不光是要兼容各种各样的文档格式，文档里边会涉及大量的表格和图表，图表里边还蕴含很多的知识，而且之间有逻辑关系，还有图文混排的包含各种各样的段落结构，先后顺序，还有各种各样的原数据，各样的图，前面这张图的认识，对于数据和解析提取是非常大的工程，通过前面 AI 搜索平台的整体解决方案,可以极大的降低复杂程度，因为这里很多的问题都是公用的，把它抽出做服务，不断的迭代增强服务的可用性，能够帮助最快速的实现 RAG 的效果。

第二个比较有挑战的例子就是文本切片，文本切片是不简单的，文档里边往往会涉及到层级，层里边是一层嵌套一层，层级对于整个 RAG 的召回结果有非常大的影响，很多的层级代表语义的关联程度，有的层级之间有非常强的语义关联关系，有的层级之间可能会比较松散，最想达到的效果是需要根据语义做非常好的切分，上面是一种机械的切分。如果对语义进行切分，需要依赖很多大模型的工作包，甚至包括对它的微调，才能非常好的理解各种各样的语义，甚至为行业的文档做特殊的训练和调优才能够做的非常好。比较好的消息是现在 AI 搜索平台已经帮做很多复杂的工作，不需要再关注于重复实现这一套，简单的调用可以帮做到比较好的效果。如果自己的企业有各方面特殊的需求，也可以进行各自的微调，因为它都是微服务形式，可以对它进行调整。

三、混合搜索

下面介绍 RAG 场景下非常重要的概念混合搜索，之所以需要混合搜索，主要原因是召回的准确率，在前面准备上下文窗口时的准确率，现在自然语言处理。

基本上看到除原文本搜索外，有两个主流的方向，一个是稠密向量的模型，平常提到的很多的模型是稠密向量，它把原始的一句话编码成 1000 多维度的向量。不管是一句话还是一段文本，还是一整篇的文章，它都会编码成 1000 多维度的向量，所以把它叫做稠密向量。

还有另外技术路径，特别是在自然语言，它是做稀疏向量。稀疏向量大体上可以想象成关键词的编号，它会切分成很多关键词。大文档可能有几万个关键词，它通过稀疏向量的模型，可以针对其中的关键词，给出权重的估计。它就可以比传统的基于的 BM25 算法，它可以做到更好的召回效果。看到现在基本上在向量搜索领域都会采用混合算法，一路或者 n 路进行密集的召回，另外一路基于稀疏向量进行召回，通过算法后续进行排序，最后得出结果。向量模型的质量就很关键。同样在 AI 搜索平台提供文本向量化的服务，它帮助大家能够提高效果,减少开发的负担。

四、Elastic 的向量数据库

下面讲的核心的部分是 Elastic 的向量数据库，Elastic 在做经典的搜索时已经非常的强大，不管做结构化的搜索，还是做非结构化的文本匹配，甚至是地理位置的搜索，做完搜索之后还可以做分析和统计，已经做的非常强大。

在进入到 8.X 之后，Elastic 社区已经真正成为原生的向量数据库，从零开始写基于 HNW 的索引，还有整套的搜索的算法，它是原生的向量数据库，除提供基本的向量搜索以外，很大的特色是要继承原 ES 非常强大的搜索和统计的能力，做到混合搜索和计算的能力，能够提供非常强大的混合搜索，这是 Elastic 社区向量数据库的最大的特色。除此以外，不仅帮助存储和搜索，还会有全栈的链路帮助比如创建 Embedding，帮助做推理，可以用上传模型，也可以对接在线的服务，特别是阿里云上的服务。

ES 要达到目标，肯定离不开对于向量搜索的各种各样的优化措施。简单介绍 ES 向量数据库做很多的优化，从向量数据开始，ES 会采用大量的硬件加速完成，因为向量它是计算密集型，不仅会用 Java的 PNAMA 项目，确定性的调用 CPU 的指令做比较昂贵的向量计算，甚至在场景，手动写 C 的代码，在 Java 里调 c 的代码，完成最为昂贵的计算的部分，充分利用硬件的能力。

第二会增加单个查询的并发程度，和以往 ES 的搜索模型是不一样的，原 ES 更加关注多少个并发，但现在要增加单个查询的并发,主要因为计算的昂贵程度，并且因为现在的计算的体系架构里边多核心是越来越多，比如 Arm 的系统体系架构的核心可能有上百个核心，可以让大家堆自己的硬件，做到更高效的查询，与之配套的是在多个并发查询之间也会做非常智能的协同，能够提前终止没必要的并发的查询，尽快的返回客户结果，最后也是向量数据库的标配，ES 同样也支持向量的量化，因为现在应用到生产情况下，必须要平衡精度和速度和成本，向量的量化基本上经常被讨论，现在会支持把 Float 压缩到 Int8 和 Int4，而且可以自动化的完成。

ES 要做最好的混合搜索，现在支持哪些混合,比如 BM25，传统的稠密向量和稀疏向量，三路都可以进行混合,提供非常强大。

采用比较流行的 RRF 的算法。简单介绍 RRF，因为 RRF 算法用的比较多，它的效果不错,不需要特别的调优，可以看到任意多路的结果，都可以进行归并。它的逻辑比较简单，主要是按照它的排名，比如 BM25，它会有一、二、三、四排名，在另外一路的召回里边也会有排名，多路合并就是把它的排名取个倒数，把整体加起就能得到个最后的分数。算法比较简单，但比较高效，也不需要为特定的场景做优化，又能取得比较好的结果，这就是采用的原因。

五、推理 API

下面介绍的推理的 API，因为最近阿里的 AI 搜索团队已经把推理平台 API 实现。提交到Elasticsearch 社区的代码里边。推理的 API 就是解耦层，能够解耦 ES 通常查询的链路还有推理的链路，在后续做 RAG 场景下面推理可能会有很多个选择，比如把推理部署到 ES 内部，或者在阿里云上有自己的推理的模型部署，或者直接调用阿里云自己的在线的推理服务，有很多的选择，有这一层通用的结构层，可以做到非常干净和整洁的逻辑的架构，可以插拔的适配到不同的需要适配的 AI 推理的模型上面，它对于 ES 在整个 RAG 场景下是至关重要的一点。现在阿里云上的 ES 已经可以完美和 AI 搜索的很多的比如 Embedding 模型、Rerank 模型，还有大语言的主权等已经可以非常完美的进行工作。

最后讲方向性的东西，AI 搜索很重要，和开源生态的结合，不仅和ES 结合，还会和其他的相量引擎结合，同样前端的编排的框架也会进行整合，在模型方面也会适配比较著名的开源大模型，在大数据底座接入方面，也会和阿里云上的数仓数据湖做到对接，在多模态也会不仅仅局限于文本，也会涉及到图片语音，视觉的其他的方面。同样，在整个最后的召回里，甚至会采用 Agent，能够更好的理解用户的搜索习惯和用途，能够更加接近搜索和推理，它会比单纯的 RAG 更好，甚至会紧抓最新的前沿，是 Graph RAG，借助于知识图谱的能力进一步的提升整个 RAG 的效果。