吵了一年，我来下个结论：纯向量数据库和向量插件都没有未来！

数据库网红教授 Andy Pavlo 于 2024 年 1 月 4 日他的博客发表了 2023 年度数据库报告，正文开始就提到了向量数据库的兴起。对于所有数据库从业人员来说，都知道 2023 年是向量数据库的大年，这从 2023 年 3 月英伟达的黄仁勋在 GTC 大会上点名向量数据库开始，到 2023 年 4 月一系列向量数据库的巨额融资都可以感受出来。

截至 2023 第三季度，向量数据库的火热都是以它作为大语言模型的外挂记忆体作为场景定义而出现的，从 2023 年第四季度开始，这个场景的称谓，被更多的接纳为 RAG（Retrieval-Augmented Generation）——基于检索增强的内容生成， 并且 RAG 这个称谓逐渐流行，甚至已经有说法认为 2024 年是 RAG 元年。

因此在这里，我们结合 Andy 在博客中的观点，结合 2023 年以来 RAG 的出现和兴起，以及发展中出现的问题，给出我们对向量数据库未来发展的判断。

RAG 一开始就致力于解决大语言模型（LLM）本身存在的一些问题。当 LLM 刚刚火热起来时，就涌现了对其如何处理个人或企业内部的私有数据进行回答的需求。如果一切都仅凭 LLM 本身，这会导致三个问题：

1. 私有数据产生的任何变更，如果都送到 LLM 训练的话，那么如何保证实时性？

2. 如果任何数据都需要通过训练或者微调才能被回答出来，那如何解决这种成本太高的问题？

3. LLM 的上下文 Token 数有限， 如果用户的数据量大到超过了 Token 数限制，如何让 LLM 回答问题？

针对这些问题，RAG 的做法是：把私有数据先用工具切分好，然后通过一个 Embedding 模型转成为向量保存到向量数据库。回答问题的时候，先把问题也转化为一条向量，再用该向量去数据库内进行 Top K 相似度比对，然后把返回的结果拼接成提示词，交给 LLM 回答，就可以满足对私有数据提问的需求。

RAG 的工作流程如下图：

由于这种搭载向量数据库的做法直接解决了上面三个痛点，因此它一出现，就引起了众多注意，这就是 2023 年上半年向量数据库火热的主要缘起。

在这个生态中，核心组件包含三个部分：LLM 负责最后问题的摘要和润色；向量数据库保存数据；还有 LangChain 和 llama_index 这样的中间件负责其他的部分，主要包括：把文档切分好转化为向量，连接向量数据库和 LLM 以及拼接提示词。

由于单纯的向量搜索技术门槛有限，这一时刻也引发了对向量数据库的广泛讨论：

• 简单使用，拿 faiss 这样的索引库就可以嵌套在 RAG 中了，还容易部署，向量数据库不过就是把 faiss 包装成一个 Server 而已，那向量数据库的门槛在哪里？

• 即便有了云原生的向量数据库，降低使用门槛和使用成本，那直接给成熟数据库添加向量能力，也不是难以做到的事情，为什么还需要一款向量数据库呢？类似的产品比如 pg_vector，它可以轻松的让 PostgreSQL 具备向量搜索能力，而且其他的数据库实现向量搜索能力，也不过就是一两个月的工作量，只是增加一种数据类型而已。

• 随着 LLM 自己的 Token 上限增加，比如 Stream LLM 都可以达到百万 Token，只要 LLM 自身能力强，那么也不需要向量数据库了，RAG 本身只是 LLM 能力增强之前的临时解决方案。

这些问题似是而非，而支持向量数据库的一方却只是围绕着“向量索引的性能”、“对大规模向量查询的支持能力”以及“向量数据库的易用程度”来进行辩护，却未真正提供强有力的观点。

另一方面，随着 RAG 在更多场景中的应用，一些问题逐渐显露出来：

1. 向量无法表达准确信息。在神经网络中，我们使用一个多维向量表征一段内容，比如一个词、一段文字、一张图片、一段声音、一段视频等。然而，这种表征仅代表了语义的关联，一个词可以转化为一条向量，一篇文章也可以转化为一条向量，因此，要精确捕获具体某个词，向量是无法做到的。而在实际应用中，对信息的准确提取占据绝大多数场景，例如：如何让 LLM 根据使用手册精确回答问题；如何让 LLM 精确回答合同里的内容；如何让 LLM 对研报内容做精准摘要，等等。

2. 由于任何文本都可以表示为向量，那么文本与向量之间如何进行映射呢？这种映射关系的不便维护导致很多 RAG 仅仅停留在个人使用阶段，而无法在企业真正使用起来。

因此，由于 RAG 在使用过程中的效果不佳，而导致这些不佳的原因又不是向量数据库自身能解决的，因此针对向量数据库的技术讨论，逐渐迷失在 RAG 本身的循环反复之中。

让我们抽丝剥茧，来探讨 RAG 究竟需要什么。先抛论点在前：在我们看来，RAG 本质上是企业搜索引擎在 LLM 时代的进化。

搜索引擎是最早的人工智能之一，站在使用者的角度，搜索引擎与 LLM 大模型类似：由爬虫抓取的互联网数据经过处理后建立倒排索引，对于企业搜索引擎来说，就是连接企业内部的数据源，对它们建立好索引。用户的查询请求会被转化为若干关键词，然后由倒排索引返回 Top K 个粗筛结果。这 Top K 个粗筛结果根据一些相对固定的因子进行排序，比如 Web 搜索引擎中的 PageRank 或者企业搜索引擎中的文档词频统计信息如 TF/IDF 等。粗筛之后还需要对返回结果作精排。精排通常需要基于机器学习模型，模型根据用户以往基于查询和返回结果的点击日志训练得到。对于个性化搜索来说，还要加上用户的以往点击和搜索偏好等。精排的结果仍然是原始数据，但由于它是经过多轮从粗筛到精排乃至重排序后的结果， 可以尽可能地把用户最希望看到的结果放到最前。

而 LLM 大模型是一种生成式模型，它返回的并不是 Top K 记录，而是根据用户的提问生成的最终答案。当用户的提问意图是问答类型时，LLM 返回的结果就可以类比为对搜索引擎返回的 Top K 个结果的总结，从而避免用户再回到原始数据中去发现，极大提升了搜索体验。

当然 LLM 还可以处理其他类型的用户提问，比如逻辑推理、代码生成，跨模态内容生成等，跟 RAG 密切相关的主要就是问答。如果把 LLM 直接应用到企业内搜索，一样需要解决传统企业搜索引擎已经解决过的问题：企业内部数据如何访问，企业最新实时数据如何访问，如何根据权限返回用户权限内的内容，等等。

基于以上 RAG 架构的 LLM 与搜索引擎在使用上非常相似，但是它们有两个核心区别：其一 是向量数据库和倒排索引，其二 是 RAG 的最后一步必须要由 LLM 来根据 Top K 个返回文本生成最终答案。

搜索引擎采用的倒排索引，是基于分词后的结果，倒排索引会根据文章内的不同词的统计信息建立词与包含这些词的文档间的映射关系。相应的查询则是通过把问题变为关键词，再从索引中获取结果。倒排索引天然具备精确的特点，但它仅仅是关键词的映射，很难具备强语义关系，这跟向量数据库正相反：利用向量可以很轻松的对一段话查询容易到语义接近的结果，因为这段话可以表征为一个或者多个向量，只需要找出与查询向量最接近的 Top K 即可。

再来看其二，搜索引擎通过倒排索引得到结果之后，经历了从粗筛到精排乃至重排序的过程，最后展现给用户的实际是经过排序后的 Top K 个原始文本，用户仍然需要从这些 Top K 个文本中获取真正的答案。LLM 则是直接给出最终答案。在 RAG 架构中，这些最终答案是根据包含了语义关系的向量搜索返回的 Top K 结果生成的。可以说，RAG 架构的 LLM 的核心能力是从用户的查询结果中生成摘要，通过限定输入的方式减少非 RAG 架构的 LLM 可能产生的幻觉现象。此时，查询返回的 Top K 个结果就成了参考文献，用户只需查看 LLM 生成的最终答案，如果不确定答案再到这 Top K 个结果中查看原文验证。

因此，RAG 架构的 LLM，更符合企业内部检索的需求，RAG 其实就是 LLM 时代由企业搜索引擎进化而来。我们来看几个例子：

• Vespa：开源多年的搜索引擎。Vespa 的历史可以追溯到上世纪九十年代。Yahoo 于 2003 年收购的搜索引擎 Overture 就是 Vespa 的前身。2023 年 10 月，Vespa 从 Yahoo 独立出来并获得 Blossom 的 3100 万美元融资。它的重要融资项目就是一个基于互联网数据向 C 端用户提供高质量问答服务的大型 RAG。

• 百川：百川近期开放了基于 RAG 的 Turbo API 。其中后台就采用了增强 RAG 效果的技术。包括查询扩展、多路召回、排序在内，无一不是搜索引擎强大技术能力的体现。而百川的前身搜狗就是一个互联网搜索引擎，搜索引擎转型提供 RAG 可以说是水到渠成。

• perplexity.ai：面向 C 端最成功的 RAG 应用。本质也是搜索引擎的进化，只是比搜索引擎多做了以下几件事：

• 用 LLM 重新理解用户的提问，并解析为更清晰的搜索语句；

• 调用搜索引擎，比如 Google、Bing 的 API，创建了自己的索引库，来构建特定领域的索引库，保证搜索质量；

• 采用自研排序算法对所有的搜索结果重排序，筛选出数量不等、质量不错的网页；

• 用 LLM 来阅读排序返回网页中的内容，并输出与问题相关的答案。

  RAG 核心需求

根据我们对各行业 RAG 落地效果的总结，再结合其他不同行业的 RAG 实施经验，对如何提升 RAG 的效果，已经逐步形成体系。这些经验和体系，总结下来，可以归纳为三大核心需求：

1. 用更好的 embedding 模型获取更好的向量，在把文字送进数据库之前，需要对文字做足够好的预加工，文字分片切也需要做得足够好，才能确保获得的向量是恰当的。

2. 多路召回。只有多路召回，才能既保证基于语义的查询结果，也能保证企业场景必备的精确检索，没有多路召回的 RAG 在大多数企业场景下会失败。

3. 排序（cross-attentional re-ranking）。所谓“跨注意力”指的是多路召回的结果还需要经过良好的重排序（fused ranking）才能把最适当的结果交给 LLM。

这三大核心需求中除了第一点是在数据库以外完成，其余两点都可以在数据库内部完成，这本质上是综合了向量搜索和全文搜索的更高级搜索引擎——传统的数据库无法服务好 RAG ，是因为缺乏以下这些搜索引擎必备的组件：

• 高效率的全文索引；

• 多样化的排序手段；

• 无处不在的自然语言处理。

举个例子，PostgreSQL 是一款 OLTP 数据库，OLTP 的核心设计目标是确保数据写入的 ACID，而这跟向量和全文搜索都不相关。尽管 PostgreSQL 有全文搜索的功能，而且已经存在十多年了，为何至今企业仍然采用 Elasticsearch 而不是 PostgreSQL 进行全文搜索呢？这是因为 PostgreSQL 的全文搜索只适合小数据规模的简易搜索，而一款能够服务好 RAG 的数据库需要胜任各种数据规模，进行可定制的相关度排序，尤其还需要与向量进行多路召回的融合排序，这些都是 PostgreSQL 没有办法胜任的。

所以，纯向量数据库固然无法满足 RAG 的要求，而实现了向量搜索能力的传统数据库，同样无法满足 RAG 的要求。

那么，用一个搜索引擎比如 Elasticsearch 来服务 RAG，是否就足够了呢？它有多路召回（同时提供全文检索和向量搜索），也有基于 RRF 算法的融合排序。然而，即便如此，这仍然不够。

在企业内部会面临各种数据源，我们设想这样一个简单的场景：根据权限来查找出符合要求的答案，然后将这些答案交给 LLM 返回。假定权限是在一张表中，我们需要把这个表的字段同步到 Elasticsearch 的 collection，这意味着三件事：

1. 即便是这样简单的需求也要引入高成本的 ETL。

2. 原始权限表的数据不能及时体现到 LLM 返回的内容。

3. 引入不必要的数据膨胀。权限过滤仅仅是一个例子。如果完全依赖 ETL 解决来自不同数据源的其他各种查询，那相当于保存一张带有全部过滤字段的宽表。除了上述的系统维护和数据更新问题之外，这也是一种不必要的数据膨胀。在大多数情况下，企业数字化系统架构内只有离线场景的数据仓库才有引入宽表的必要。

因此，一个良好的企业级 RAG 需要一个以完整功能的数据库为核心，辅助以各类工具，包括良好的文字切分和 embedding 模型，更好的融合排序模型特别是针对垂直业务或者不同企业内部的各种排序模型和查询扩展，才能达到满意的效果。

Elasticsearch 在十多年前就是企业搜索引擎，它相比数据库的一个显著区别是它没有执行引擎组件：收到搜索请求以后，直接从倒排索引获取数据后排序返回，所有工作都在一个线程中完成。而执行引擎的一条查询请求进来之后会被编译成计算图，然后以流水线的方式在计算图流转，引擎会根据可用资源的数量决定计算图每个节点使用的并行度。缺乏执行引擎在应用层面的表现就是无法为企业内的各类精确信息查找提供足够的访问能力。

前面提到的关于向量数据库本身的似是而非的问题，我们已经解答完毕。还有一些问题，虽然并不重要，但它们在一段时间内确实也影响了很多人的判断，在这里一并回答：

• 过于追求模型的上下文 Token 数没有实际意义。RAG 通过检索缩小用户提问所需要的上下文窗口，是解决上下文 Token 数限制的最佳方案。在 2023 年 11 月 6 日 OpenAI 推出的 GPT4 Turbo，本质就是一个 RAG （根据一些出错日志信息， OpenAI 可能是采用了类似 Qdrant 的向量数据库， 由于 OpenAI 主要面临个人的简单场景，因此只用基于向量数据库的 RAG， 也能基本满足要求）。前期很火的项目 Stream LLM 是一个号称解决了上下文 Token 数限制的 LLM 的例子：它几乎可以被认为拥有无限 Token，但并没有真正解决推理过程中上下文 KV 缓存容量有限带来的瓶颈，只是借助滑动窗口的概念仅保留最近的注意力。换言之，就算我们把一整本书都放进 LLM 里提问，它也只能记得清最近的内容，之前的就很模糊了。因此，我们不能说 LLM 的能力强，就可以扔掉 RAG，更何况企业场景的数据，根本无法用 Token 数衡量，百万量级的 Token，对应的文本也不过几个 MB 而已，而企业级数据达到 GB 甚至 TB 级也轻而易举。即使解决了海量数据检索的问题，我们仍然需要考虑如何处理精确信息查询，比如权限等等。因此，RAG 将永远存在，它不是一个临时解决方案。

• 当前 RAG 最大的瓶颈其实是 LLM 本身，用 LLM 支撑业务的过程中的最大痛点从来都不是上下文的处理能力不足，而是在上下文有限的情况下依然控制不了 LLM 的胡说八道（幻觉）。因此，随着 LLM 能力的增强，RAG 的未来，将如下图所示：由 LLM 搭配一个专用的数据库，承担起企业各类数智化在线业务的门户级需求。企业会把各类数据都交给这个数据库——我们定义为 AI 原生数据库，其应用架构图如下所示：

• 适合用向量表达的数据，转化为向量保存下来。

• 不适合变为向量的数据（如各类结构化和半结构化数据），以原方式保存。

• 查询也不是用一条向量去查出相似的多条向量，而是在一条查询语句中包含多种查询条件：有向量搜索（也包含多向量搜索）、全文检索、对各类结构化数据的查询，还有针对多种搜索后的多路召回。

以上，也正是我们开发全新的 AI 原生数据库 Infinity 的初衷，它已于 2023 年冬至前开源（https://github.com/infiniflow/infinity/），具备多路召回，融合排序，也提供结构化数据查询能力。

让我们再回到开始，回顾 Andy 的 2023 年数据库年报。在年报中，Andy 和 Weaviate 的 CTO 讨论了向量数据库未来可能朝两个方向发展。

方向一，向量数据库支持传统 DBMS 的功能，支撑运营性质的负载（operational workloads，通常即为在线负载）；方向二，向量数据库充当一个索引数据库的角色，类似 Elastic 或者 Vespa ，它与主数据库协同工作。Infinity 其实是这两条路线的结合：相比传统数据库，它是一个更高级的搜索引擎，具备 RAG 所需要的一切能力；相比 Elasticsearch 这样的搜索引擎，它具备数据库的能力，拥有数据库必备的执行引擎，可以支撑企业内部对于在线业务的各类访问需求。

因此，我们把它看作是为 AI 配套的第三代数据库基础设施：

1. 第一代，以统计模型和数据挖掘为基础，基础设施的配套代表就是搜索引擎。因此配套的企业 AI 应用架构，往往是以 Elasticsearch，再加上 MySQL 等数据库共同支撑业务体系。

2. 第二代，深度学习催生了向量搜索的需求，也催生了向量数据库这个品类。由于向量数据库仅仅提供单一的向量搜索能力，在构建企业信息系统时，还需要搭配各类数据库、数据仓库等，形成所谓的 AI 中台。

3. 第三代，AI 进化到大模型之后解锁了更多场景。因此，它需要的不再是一款单纯的向量数据库，而是能够同时提供向量搜索、全文搜索和结构化数据检索，可以支撑大模型对于复杂数据的获取需求，能够配合大模型共同支撑起企业门户业务需求的基础软件产品。

张颖峰，英飞流（InfiniFlow）创始人，连续创业者，先后负责 7 年搜索引擎内核研发，5 年数据库内核研发，10 年云计算基础架构和大数据架构研发，10 年人工智能核心算法研发，包括两代广告和推荐引擎，计算机视觉和自然语言处理。先后主导并参与三家大型企业数字化转型，支撑过日活千万，日均两亿搜索动态请求的 C 端互联网业务。