ColBERT 杀死向量数据库？

昨天的英伟达 GTC Keynote 上，老黄二度提到了向量数据库，笔墨不多，但是个讨论的好时机。

今天不说别的，就和太可研究所（techinstitute）一起来聊聊 ColBERT 对向量数据库的影响。

时间还要退回 2023 年 12 月，一个名为 ColBERT 的模型突然火了，我当时粗粗看了一下，没有很理解它的价值在哪里。直到最近有空仔细翻阅了相关资料，发现 ColBERT 确实对现有的 RAG 系统有着不小的冲击，对向量数据库的冲击尤其强烈。当然，这不等于 ColBERT 模型能替代向量数据库。

Vol.1

大模型最常见的应用场景是 RAG(Retrieval-Augmented Generation)，最重要的两个组成部分是 Retrieval 和 Generation。

Generation 部分是各大模型的战场，开源界比较流行的两个框架 LangChain 和 Llama-Index 主要应用于 RAG 场景中的胶水层；而 Retrieval 的方案就百花齐放了，比较主流的是用向量数据库完成 Retrieval 这一步。

引用一下 LangChain 的一张图，看一下想做好一套 RAG 系统，心智负担得有多重：

图源｜https://twitter.com/LangChainAI/status/1758543746868936719

在这套系统画得非常复杂，但究其本质，讲的就是如何在大量文档中找出和用户的问题最相关的那一批，从而让大模型不要胡说八道，考虑到这一层，RAG 的本质就是个私有搜索引擎。

很多 RAG 的场景都会优先使用 VectorDB 作为 Retrieval 的核心，因为相比于其他方案，VectorDB 能进行语义搜索而不仅仅是关键词搜索，查询结果相对更准确。

但是，VectorDB 不能单独完成 Retrieval，需要有 Embedding 模型把文本 Embedding 成向量。同时，如果涉及到多路查询，查询结果还需要进行 Re-Ranking。此外，向量 kNN 检索还有比较大的问题，是缺乏可解释性，因为向量是通过 Embedding 模型生成的，向量本身并不可读，向量的质量和模型息息相关，通过相似度匹配查出来的结果也是近似查询，所以查询结果很难解释。所以，很多用户在一开始期待用了向量数据库+大模型就能很方便的搭建 RAG，但实际效果往往不佳。

经过业界不断地摸索，对 RAG 系统进行了多轮魔改，最终呈现效果如上面图所示，非常复杂。本来用户的期待是 AI 能帮助自己简化系统，谁知道用了之后系统反而更复杂了，这与 AGI 的初衷背道而驰。

Vol.2

了解完 RAG 系统的复杂度，接下来我们就来看看 ColBERT 是什么，以及它怎么解决问题的。

图源｜https://jonsaadfalcon.com/papers/colbert_v2

上图是 ColBERT 的原理图，左右两边分别是 Question 文本和原始文档 Passage 文本，分别经过自己的 Encoder 编码出来一组向量。这两组向量再两两计算一下相似度，最后再求和就得到一个分数，就是 Question 和 Passage 的距离分数；Question 文本和数据库中的每一篇文档都计算一个相似度分数，如此就可以对分数进行排序，分数越低说明越相似，这就是 ColBERT 的计算流程。

这么一看好像也没什么新颖的地方，无非就是 Embedding +新的距离算法。ColBERT 有几个非常大的优势需要列举一下：

文档和查询可以使用不同的 Embedding 模型，意味着文档可以使用基础模型进行预处理；

可以将文档中 token 上下文关系带入到距离计算中；

可以兼顾语义搜索和关键词搜索。

看完下图大家应该会有一个更清晰的认识：

图 a，目前向量数据库的做法，比较 Document 和 Query 的 Embedding 的距离，按照相似度排序；

图 b，Document 和 Query 拆分成一组 token，并使用深度神经网络匹配 token 之间的关系；

图 c，该模型更强大，它同时对 Document 和 Query 内部以及之间的单词交互进行建模；

图 d，就是 ColBERT，相比于 c 优势在于 Document 和 Query 分别计算，也可对两个模型分别微调。

Vol.3

ColBERT 的原理章节对不了解技术细节的同学来说有点难，下面会通过场景来举例说明。

据我观察，绝大部分 RAG 场景都是知识库、智能体长期记忆这两种。这类场景的特点是单用户体量都很小，单用户文档规模不超过 10 M。如果使用向量数据库的话一般不超过 10 万条向量，用户对搜索结果质量要求很高，topK 查询结果不超过 5 条，用户对于数据库查询延迟要求不高，因为还有更慢的大模型在后面。

这种场景如果单纯使用向量数据库的话，首先，用户需要学会如何分割文档，如果一个几万 token 的文档被 Embedding 成一条向量，查询结果势必很不准。其次，用户还得使用多路召回，单纯的向量匹配的问题前文也提到过了，可解释性不足。最后，需要对多路召回的结果进行重排，这就需要需要引入一个Re-Ranking模型。同时如果想查 top 5 条的文档，可能需要从向量数据库里搜索出来top 100，再经过 Re-Ranking 挑出来 5 条，这就是粗排加精排的过程。

还有一个关键问题就是 Embedding 模型管理的问题，开源的 Embedding 模型过于通用，在私有的知识库场景不一定合适，大概率需要做微调。但是模型微调之后意味着之前存到向量数据库里的数据统统需要删了重建一遍，因为模型不一样了，Embedding 出来的向量也会跟着变化，老的数据肯定没法继续用了。

而使用 ColBERT 的优势在于可以不用这么复杂的逻辑，因为 Document 和 Query 的模型可以不一样，所以 Document 就可以用一些 SOTA 的模型预处理好存起来即可。实际在查询时可以通过几轮的迭代微调出来一个适合自己的 Embedding 模型用于 Query，而 Document 预处理的 Embedding 数据还可以继续用，这大大简化了使用成本。ColBERT 是 token 级别的 Embedding，所以天然不用考虑如何切分文档的问题。

另外，ColBERT 的能力就兼具了语义检索和关键词检索的能力，所以完全通过它搜索出来的结果完全可省掉 Re-Ranking 这一步，同时只要进行单路的召回即可，无需向量数据库+关键词检索多路召回，可以大大简化系统架构，也就是文章最开头复杂的架构图简化成一两步。

看到这儿不少同学肯定会关心，使用 ColBERT 时，每个 token 都要计算 Embedding 会不会让存储放大很厉害，会不会有查询延迟的问题。

关于存储的问题确实会让存储放大，但是没有想象中的那么夸张，因为对于每个 token 进行 Embedding 只需要使用 128 维即可，不用 1536 维。此外，还可以做一些量化压缩会再有一个数量级的空间压缩，所以存储放大的问题不用特别担心。

至于查询延迟，目前还没有很好的 benchmark 对比，但从原理上来看肯定比各种 ANN 索引慢很多，但如果只是 10 万左右的数据量，ANN 的性能优势也没那么大，而且 ColBERT 的计算都是矩阵计算很适合 GPU 加速，未来性能提升还有很大的空间。

Vol.4

通过上面的分析，会让人感觉未来向量数据库的前景堪忧。其实也没必要这么早下结论，首先 ColBERT 确实火了一把，从理论上来看前景很诱人，但还没有真是落地的场景，都还是 demo 性质的产物，需要一段时间酝酿。

其次，向量数据库也不只是 RAG 这一个场景，还有很多其他的需求在，不用担心一个场景受到挑战就会如何（但确实会影响向量数据库公司的估值）。

另外，如果 ColBERT 真的如论文中说得那么厉害，向量数据库也可改变自己，把 ColBERT 融合进自己的查询能力，而不是死死抱着 ANN 索引不放手，与时俱进才是一个好产品的核心竞争力。

关注太可研究所（techinstitute）了解更多~