向量数据库不是必须的！

LLM 目前都有一个限定的上下文大小（比如 GPT-3.5 是约 16K），这给在大量文档中进行问答带来了不便，因为我们无法把所有文档的内容都放入模型的上下文中。

面对这个问题，一个可能的解决方案是在希望模型回应我们的问题之前，先对 LLM 针对这些文档进行微调。但是，如果文档集合变化频繁，微调 LLM 既复杂成本又高昂。比如，我如果想在笔记本电脑上运行 Llama 来便捷地查找电子邮件、文档等，显然不会想要每收到一封邮件就对 Llama 进行一次微调。

另一种方案是使用检索增强生成（Retrieval Augmented Generation，RAG），它包含两个阶段。首先是快速在全部潜在文档中搜索一小部分相关文档，接着把这部分文档的内容加入到模型的提示信息中，再将其发送给 LLM。

我们可以将第一个任务进一步细分为以下几个更具体的任务：

1. 一个通用的方法，用于确定相关文档子集（即第一个任务），是首先为每个文档创建一个向量嵌入（vector embedding），这个向量代表了文档的 “含义”。
2. 我们预期，彼此内容相似的文档在高维空间中也会彼此靠近。

3. 接下来，我们可以为我们的问题创建一个向量嵌入，并利用最近邻搜索技术来寻找最相关的文档。

以下是 Scriv.ai 团队制作的一张图，很好地描述了这个过程：

最近，向量数据库（例如 Pinecone、Milvus 等）作为存储和计算大量文档的最近邻信息的工具越来越受欢迎。在这篇文章中，我想阐述，在实施 RAG 时，并不一定需要使用向量数据库。

寻找少量相关文档以回答特定问题，这在信息检索（Information Retrieval，IR）这一计算机科学领域是一个很有历史的研究话题。这些解决方案的历史比向量数据库更久远。

这个问题的经典例子包括 Google、Bing、Apache Lucene、Apple Spotlight 等搜索引擎，它们已经实现了可扩展的解决方案。作为一个行业，我们在过去几十年里已经创造并完善了基于反向索引的高度可扩展和高度可用的技术。

尽管语义向量是该领域的重大创新，但它们应在我们构建可扩展 IR 系统的经验教训中得到使用和实施。

在这篇文章中，我们对向量嵌入与传统信息检索解决方案在找到适合回答特定问题的文档方面进行了基准测试和评估。我们还考虑了一种可能性，即使用向量嵌入来改进检索效果，但同时不必依赖于向量数据库。所有结果都展示在下面链接中。

https://github.com/xetdata/RagIRBench

#01

以下是一个示例段落：

Beyoncé Giselle Knowles 在德克萨斯州休斯顿出生，她的父亲 Mathew Knowles 是 Xerox 的销售经理，母亲 Celestine Ann "Tina" Knowles（娘家姓 Beyincé）是一位美发师兼沙龙店主。Beyoncé 这个名字是为了向她母亲的姓氏致敬。她的妹妹 Solange 同样是一名歌手，曾是 Destiny's Child 组合的成员。Beyoncé 的父亲 Mathew 是非洲裔美国人，母亲 Tina 则是具有非洲、美洲原住民、法国、卡真、爱尔兰和西班牙血统的路易斯安那克里奥尔人。从她母亲这边看，Beyoncé 还是阿卡迪亚领袖 Joseph Broussard 的后裔。她是在一个卫理公会信仰的家庭中长大的。

根据上面内容可以回答的几个问题：

• Beyoncé 的父亲是什么种族？
• Beyoncé 在哪种宗教信仰中成长？

• Beyoncé 的妹妹叫什么名字？

不过，我们这次不会直接用文段来回答这些问题，而是采用一种新方法：我们会提出问题，然后在数据集中找到包含答案的那一段内容。

这个数据集并不是专为这个目的而设计的。例如，有些问题如 “她是哪个 R&B 组合的主唱？” 需要足够的上下文来明确 “她” 的指代。尽管如此，大部分问题并不涉及此类问题，所以这个数据集对于我们的实验已经足够了。

我们首先为每篇文档和每个问题计算一个嵌入式向量。接着，对于每一个问题，我们找出最接近的前 20 个邻近文档。值得注意的是，我们这里采用的是精确的最近邻居方法，而不是大型向量数据库常用的近似方法，因此我们不用担心检索的准确性。

在接下来的对话中，我们会展示在不同 N 值下的召回率（recall at N）。也就是说，如果我只返回最接近的 N 篇文档，正确答案出现在这些文档中的概率是多少。

这意味着，如果我只查看最接近的一篇文档，大约 63% 的情况下我能找到包含答案的段落。这个比例在前 10 篇文档中提高到 88%，在前 20 篇文档中则提高到 91.7%。这个结果看起来非常不错！

BM25 的效果不如 OpenAI 的嵌入式向量（尽管有趣的是，在前 1 名的情况下表现似乎更好）。这是一个非常好的结果，说明 OpenAI 的嵌入式向量是有价值的！

但是，BM25 的表现并没有比 OpenAI 的方法差太多。让我们考虑一下我们将如何评估 RAG：也就是从最终的目标指标出发。如果我们的目标是达到 85% 的检索召回率，并打算使用向量数据库，那么我需要检索 7 篇文档。而如果我只使用 BM25 方法，我需要检索 8 篇文档。考虑到维护向量数据库和嵌入式向量服务的成本，这两种方法在实际应用中的差别其实并不明显。

传统上，信息检索（Information Retrieval，IR）被用于处理数十亿篇文档。标准的解决方案是首先使用非常高效、低精确度、高召回率的算法，这些算法能快速地在数十亿文档中筛选，并缩减到大约 1000 篇文档的更小子集。之后，就会采用成本更高、精确度更高的算法来对文档集进行重排和进一步缩减，以找出那些真正相关的少数文档。

我们可以采用相同的原则。BM25 是一种成本相对低廉的方法，能够通过倒排索引解决方案高效地实施，快速缩减到一个中等大小的数据集。接下来，向量嵌入则是一种更高精度的方法，我们可以用它来对数据集进行重排。

基于这个思路，我们结合了这两种方法。先用 BM25 提取前 50 个结果，然后用向量嵌入对它们进行重排。

这种方法在所有的检索数量上都清晰地超越了其他所有方法。在 85% 的召回率下，只需 5 篇文档就足够了。

原文链接：https://about.xethub.com/blog/you-dont-need-a-vector-database