想要更好地控制您的搜索设置?了解我们的灵活的基础设施定价

回到主页Meilisearch 的标志
返回文章

为什么您不应该将向量数据库用于 RAG

关于构建更好的检索增强生成系统的反向观点。

2025年4月30日阅读时长4分钟
Thomas Payet
Thomas PayetMeilisearch 联合创始人兼首席运营官@totolapaille
Why you shouldn't use vector databases for RAG

什么是RAG,以及为什么要关注它?

每天都有数百万人与ChatGPT、Claude和其他大型语言模型互动,这从根本上改变了我们与计算机互动的方式。其吸引力显而易见:用户无需学习特定界面,只需用自然语言进行交流。机器适应人类,而不是反过来。

这种转变使得各组织争相利用自己的数据创建类似的体验。无论是构建能够理解产品文档的支持聊天机器人,还是设计能够编写个性化电子邮件的助手,亦或是开发帮助员工访问公司知识的内部工具,所有这些都需要相同的根基:让大型语言模型能够访问专有信息。

检索增强生成(RAG)应运而生,其概念看似简单却具欺骗性:

  1. 用户提出问题
  2. 系统根据问题检索相关文档
  3. 大型语言模型利用这些检索到的文档作为上下文生成答案

如果正确实施,RAG 可以提供更准确、最新的回复,同时减少幻觉。但大多数工程师都在这里犯了错误:他们默认使用向量数据库,却没有考虑这是否是最佳方法。

工程师的捷径:向量数据库

典型的RAG实现大致如下:

User Question → Convert to Embedding → Query Vector DB → Retrieve Similar Documents → Generate Answer

这在直觉上是说得通的。向量嵌入捕捉语义含义,因此相似的概念在向量空间中会聚类在一起。通过将问题和文档转换为相同的嵌入空间,即使关键词不完全匹配,你也能找到相关信息。

工程师们喜欢这种方法,因为它看起来很优雅。你不需要复杂的查询解析或关键词匹配——只需将所有内容转换为向量,然后让相似性算法完成工作。

但这种捷径却造成了两个严重问题,显著降低了结果的质量。

问题1:未经优化的查询导致不相关结果

第一个主要问题出现在最初的步骤:我们直接将原始用户查询转换为嵌入,并用它来检索文档。

想想你使用Google时会发生什么。你并不总是用实际的问题来搜索——你会将其提炼成更可能产生相关结果的关键术语。如果你想知道“在大型项目中组织React组件的最佳方法是什么?”,你可能会搜索“React组件组织最佳实践大型应用”。

大型语言模型擅长这种查询优化,但在标准向量数据库方法中,我们却跳过了这个关键步骤。嵌入捕获了原始问题的语义含义,但这并不总是与最佳搜索查询对齐。

问题2:向量搜索牺牲了精确度以提高召回率

第二个问题更为根本:与传统的全文搜索相比,向量相似性搜索在召回率方面表现出色,但在精确度方面往往较弱。

向量搜索擅长查找概念相关的内​​容(召回率)——即讨论相似主题的文档,即使它们使用不同的术语。但是,它在精确地找到您所需内容(精确度)方面效果较差。

另一方面,全文搜索则优先考虑精确度。当存在精确关键词匹配时,它们通常高度相关。但其缺点是,全文搜索可能会错过使用不同术语但概念相似的内容。

这解释了为什么许多完全依赖向量数据库的RAG系统在初始检索后还会实施额外的重新排名步骤。这也是为什么向量数据库越来越多地添加全文搜索功能的原因——它们认识到纯向量搜索的固有局限性。

一种更人性化的RAG方法

既然我们试图构建模仿人类智能的系统,那么我们的 RAG 管道不应该模仿人类实际搜索信息的方式吗?

当人们需要查找信息时,他们会

  1. 将他们的问题重新表述为有效的搜索词
  2. 使用针对检索相关信息进行优化的搜索引擎
  3. 扫描结果以识别最有用的内容

一个更好的RAG设计将遵循这种模式:

User Question → LLM Refines Into Search Query → Hybrid Search (Combining Full-text and Semantic) → Retrieve Relevant Documents → LLM Generates Answer

这种方法解决了两个问题:

  1. 大型语言模型将用户的原始问题细化为优化的搜索查询
  2. 混合搜索结合了全文搜索的精确度和语义搜索的召回率

解决方案:使用搜索引擎实现更简单(更优)的RAG

这是我的反主流观点:与其直接跳到向量数据库来实现RAG,不如从一个结合了全文和语义功能的优质搜索引擎开始。

Meilisearch 等现代搜索引擎提供混合搜索功能,其整体相关性优于纯向量检索。它们还具有以下优点:

  • 更易于部署和维护
  • 针对大规模快速查询进行了优化
  • 以相关性为主要目标进行设计
  • 调试搜索结果更直观

对于大多数RAG应用程序,工作流程变得更加简单:

  1. 用户提交问题
  2. 大型语言模型将问题转化为有效的搜索查询
  3. 搜索引擎使用混合搜索检索相关文档
  4. 大型语言模型利用这些文档作为上下文生成响应

这种方法与人类实际搜索信息的方式相符,充分利用了大型语言模型和搜索技术的优势,同时避免了不必要的复杂性。

RAG中简单性的力量:回归搜索基础

向量数据库在机器学习生态系统中确实有其地位,但它们并非总是RAG系统的最佳基础。通过退一步思考人类如何搜索信息,我们可以构建更有效、更简单的RAG架构。

下次设计RAG系统时,考虑一下优秀的搜索引擎是否是更好的选择。你的用户(以及将来维护系统的你)都会感谢你。

立即构建更好的RAG系统

使用 Meilisearch 的混合搜索功能,跳过向量数据库的复杂性,在几分钟内为您的 RAG 应用程序实现生产级搜索。

What is RAG (Retrieval-Augmented Generation) & how it works?

什么是 RAG(检索增强生成)及其工作原理?

RAG(检索增强生成)的完整指南。了解它的含义、工作原理、不同 RAG 类型、RAG 系统的组成部分等等。

Ilia Markov
Ilia Markov2025 年 8 月 14 日
What is search relevance: Everything you need to know

什么是搜索相关性:你需要了解的一切

了解什么是搜索相关性,它对用户体验和业务成果为何如此重要,以及如何通过实用策略和见解来改进它。

Ilia Markov
伊利亚·马尔科夫2025年8月12日
On-site search: Definition, implementation, best practices & more

站内搜索:定义、实现、最佳实践及更多

了解什么是站内搜索、它如何运作、其优势、如何实现、最佳实践等。

Ilia Markov
Ilia Markov2025年8月7日
© . This site is unofficial and not affiliated with Meilisearch.