博客
放弃ES，用向量数据库构建网站AI查询助手才是王道

放弃ES，用向量数据库构建网站AI查询助手才是王道

2025-03-11

By Zilliz

技术开发过程中，你是否也经常面临这种困境：

产品经理和老板催着快速交付结果，但开发过程中遇到的技术文档复杂又臃肿，对于一个新人来说，想要直观快速的了解开发平台上的各种功能和特性难如登天。

当然，多数平台都在其技术文档中提供基于ES的基本搜索功能，开发者输入关键词，平台就能提供一系列相关文档来回答问题，但这种基本搜索功一般都是基于关键词，做精准匹配，故而难以理解我们查询中的真正语义，从而导致返回不相关或者不完整的搜索结果。

例如，在浏览 Zilliz 的技术文档时，开发者通常会提出以下问题：“如何在检索中，同时使用稀疏向量和稠密向量？”或“如何动态扩展集群？”

用ES等方式构建的基础搜索通常准确回答这些细致且复杂的问题。

1.23-1.png

图一：开发者询问和 Milvus 相关的经典问题

加入 AI 助手则可以很好的解决这些问题。通过大模型、RAG__等自然语言处理（NLP）技术驱动， AI 助手可以通过理解开发者查询背后的意图和语义信息，进而提供答案或定位到精确的页面。

那么，如何构建一个聪明的文档检索助手？接下来，我们将对其基本原理以及实现路径进行解读。

01.

实现路径：检索增强生成（RAG）

通常来说，我们会用RAG（检索增强生成）来搭建文档内内容搜索的基础架构。通过结合向量搜索和大型语言模型（LLMs），RAG可以对用户查询生成准确的答案。

其工作流程大概是这样的：用户提出一个问题，RAG 对包含查询答案的相关文档进行检索，接着，查询和相关文档会被合并成一个连贯的 prompt发送给大型语言模型（LLM），并最终生成答案。

在以上流程中，RAG 的核心作用是为 LLM 提供相关上下文。这种方法至少有两个好处：首先，它减少了 LLM 产生幻觉的风险，即生成不准确和不真实的回答。其次，LLM 生成的回答会更加贴合上下文，并针对我们的查询进行调整。以上优势，使得RAG在查询内部文档内容时，相较单一的LLM而言，内容生成会更加的精准与高效。

1.23-2.png

在具体构建 RAG 时，主要有四个步骤：数据整理、索引、检索和生成。

数据整理： 主要包括数据的收集和预处理，可能会收集每条记录的相关信息和元数据。

索引： 使用优化的索引方法来存储数据，从而实现快速检索。在这个步骤中，预处理的数据会通过一个 embedding 模型，转换为向量 embedding，然后使用 FLAT、FAISS 或 HNSW 等高级索引算法，存储在 Milvus 等向量数据库中。

检索： 主要包括向量搜索操作，将用户的查询与存储的数据进行匹配。在这个过程中，用户的查询会通过与存储数据相同的 embedding 模型转换为 embedding向量。然后，在用户的查询和存储数据之间，执行相似性搜索，从而在向量数据库中找到最相关的信息。

生成： 利用 LLM 与检索结果生成最终答案。首先，将用户的查询和检索获得的最相关上下文合并成一个 prompt。然后，LLM 根据 prompt 中提供的上下文，生成对用户查询的响应。

1.23-3.png

图：RAG 的步骤

在实施上述每个步骤时，我们需要考虑几个因素。例如，在数据整理阶段，我们需要考虑数据来源、数据清理方法以及 chunking 方法。同时，在索引阶段，我们需要选择合适的 embedding 模型和向量数据库，以及适合我们的索引算法。

在下一部分中，我们将详细讨论，如何使用大模型和向量数据库构建 AI 助手，以及这个 AI 助手怎样用于 Zilliz 和 Milvus 网站内的文档查询。

教程：如何构建 AI 助手

如前所述，构建RAG 的第一步是数据整理。在这一步骤中，我们需要先从各种来源（如技术文档、支持与常见问题解答页面以及 GitHub ）收集与 Zilliz 和 Milvus 相关的文本数据。这些文本数据随后被清洗和 chunking，以确保每条信息既不过于宽泛，也不过于细碎。

在进入下一步之前，也会收集每条 chunking 记录的元数据。这些元数据包括：

来源类型：数据通常来自 GitHub 、技术文档、支持与常见问题解答页面等。
记录类型：包括数据的版本、文本与代码。如果是代码，还会记录所使用的编程语言。
层次结构引用：包括每个数据点的子节点、父节点和兄弟节点，这些数据是从 Zilliz 的网站收集的。
URL、标签、路径：例如数据来源的 URL。这些元数据非常有用，因为它们在 LLM 生成的响应中，提供了引用或来源链接。
日期：每条数据的发布日期。

收集了数据和元数据之后，接下来，我们需要将预处理的数据转换为向量 embedding，然后在检索环节中实现相似性搜索。

将数据转换为向量 embedding的过程中，我们往往需要思考，到底应该将其转化为稀疏 embedding ，还是稠密 embedding 。

其中，稀疏 embedding 通常用于关键词匹配以及是或非的布尔匹配。因此，通过稀疏 embedding 查询到的相关文档，通常包含查询的关键词。我们通常有两种不同类型的模型可以将数据转换为稀疏 embedding：基于传统统计的 embedding模型和基于深度学习的 embedding模型。本次 AI 助手的构建中，我们可以使用 BM25 作为基于传统统计的 embedding模型，使用 SPLADE/BGE-M3 作为深度学习的 embedding模型。

而稠密 embedding 则更适合捕捉查询中的细微差别或语义含义。通过稠密 embedding 获取的文档，不一定包含我们所查询的关键词，但它的内容通常与查询高度相关。要将数据转换为稠密 embedding，有许多深度学习模型可供选择，例如 OpenAI、Sentence-Transformers、VoyageAI 等的 embedding 模型。此次AI助手的构建，我们后续会使用三种不同的 embedding 模型：MS-MARCO、MPNET 和 BGE-M3。

1.23-4.png

图：稀疏和稠密嵌入

一旦所有数据都转换为稀疏向量和稠密向量表示后，这些数据就会被存储在向量数据库中，就可以实现快速检索。

但看到这里，你可能会有疑问，那就是为什么我们需要对多种稀疏 embedding 和稠密 embedding结合使用，而不是只选择一种模式呢？

答案是，在实际部署中，单纯的语义检索，或者单纯的关键词检索，都是比较少见的。例如，如果我们的查询较短（少于5个词）的内容，那么使用稀疏 embedding 可能就足够了。而如果我们的查询较长，那么在大多数情况下，使用稠密 embedding 会提供更好的结果。

此外，如果我们使用 Milvus 作为向量数据库，我们可以利用它的混合搜索能力，即结合稀疏 embedding 和稠密 embedding 进行相似性搜索。此外，在前不久推出的milvus 2.5中，我们还在2.4版本的稀疏向量检索和混合检索基础之上，还推出了全文检索（FTS,Full-Text Search）功能以应对不同客户的多种向量检索需求。

1.23-5.png