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

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

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

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

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

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

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

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

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

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

https://github.com/xetdata/RagIRBench

#01

SQuAD 数据集

在本文的比较分析中，我们将使用 SQuAD 数据集作为参考。SQuAD 数据集包括了一系列段落及各段落的问题，共涵盖约 87,000 个问题和 19,000 个段落。每个问题都只能通过相应段落中的信息来找到答案。

以下是一个示例段落：

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

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

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

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

#02基于向量的检索与 OpenAI 向量技术

我们首先来评估一下使用 OpenAI 的嵌入式向量（embedding vector）服务进行信息检索的表现。

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

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

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

#03经典的 BM25 方法

现在，我们来将这个方法与一个较为传统的方法 BM25 进行比较，这个方法主要是基于简单的词频统计。BM25 基本上是一种带有额外规范化处理的 tf-idf 方法。我们用 Spacy 进行词语分割和一些基本的规范化处理，比如去除标点和转换为小写字母。

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

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

#04用向量重排 BM25

不过，我们可以做得更好。

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

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

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

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

#05结论

进行 RAG 时，你不需要文档嵌入。考虑使用更简单的信息检索方法。向量嵌入仍然非常有用，它是增加更高精度过滤的好方法。但要用向量嵌入作为后期过滤器，你实际上只需要一个向量检索服务（任何 KV 存储），就可以对少量向量进行高效且精确的 k-NN 重排。无需向量数据库。

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