信息检索/检索增强生成（RAG）

除了使用上一篇文章（在使用大语言模型 (LLMs) 构建产品一年中的经验总结 (第一部分)）的提示来引导大语言模型（LLM）外，另一种有效的方法是将知识作为提示的一部分提供。这种方法将 LLM 锚定在提供的上下文上，用于上下文学习，这被称为检索增强生成（RAG）。实践中发现，RAG 在提供知识和改进输出方面非常有效，而且所需的努力和成本远低于微调。RAG 的效果取决于所检索文档的相关性、信息密度和细节程度。

RAG 输出的质量取决于所检索文档的质量

第一个也是最明显的指标是相关性。相关性通常通过排名指标进行量化，例如平均倒数排名（MRR）或归一化折扣累计增益（NDCG）。MRR 评估系统将第一个相关结果放在排名列表中的能力，而 NDCG 则考虑所有结果的相关性及其位置。这些指标衡量系统将相关文档排在更高位置、不相关文档排在更低位置的能力。例如，如果我们检索用户摘要以生成电影评论摘要，我们会希望特定电影的评论排名更高，而排除其他电影的评论。

与传统推荐系统类似，检索到的项目排名将对 LLM 在下游任务中的表现产生重大影响。为了衡量这种影响，可以运行一个基于 RAG 的任务，但将检索到的项目顺序打乱，然后观察 RAG 输出的表现如何。

其次，我们还要考虑信息密度。如果两个文档同样相关，我们应该选择更简洁且细节较少的那个。回到电影的例子，我们可能认为电影剧本和所有用户评论在广义上都是相关的。然而，顶级评论和编辑评论的信息密度可能更高。

最后，要考虑文档提供的细节程度。想象我们正在构建一个 RAG 系统，从自然语言生成 SQL 查询。我们可以简单地提供表结构和列名作为上下文，但如果包括列描述和一些代表性值，额外的细节将帮助 LLM 更好地理解表的语义，从而生成更正确的 SQL。

别忘了关键词搜索：把它作为基线并在混合搜索中使用

由于基于嵌入（Embedding）的 RAG 方案演示的流行，很容易让人忘记或忽视信息检索领域几十年的研究和解决方案。

尽管嵌入技术无疑是强大的工具，但它并不是万能的。首先，虽然它们擅长捕捉高级语义相似性，但在处理更具体的基于关键词的查询时可能会遇到困难，比如用户搜索人名（如 Ilya）、缩写词（如 RAG）或 ID（如 claude-3-sonnet）时。关键词搜索，例如 BM25，就是专门为此设计的。经过多年的关键词搜索，用户可能已经习以为常，如果他们期望检索到的文档没有返回，可能会感到沮丧。

向量嵌入并不是搜索的万能解决方案。事实上，在使用语义相似搜索进行重新排序之前的步骤才是最关键和费力的。要真正实现比 BM25 或全文搜索更好的效果是非常困难的。— Aravind Srinivas, CEO Perplexity.ai

几个月来我们一直向客户和合作伙伴反复强调：使用简单的嵌入进行相似检索会产生非常杂乱的结果，还不如从关键词搜索开始。— Beyang Liu, CTO Sourcegraph

其次，使用关键词搜索更容易理解为什么会检索到某个文档——我们可以查看匹配查询的关键词。相比之下，基于嵌入的检索则不那么容易解释。最后，得益于经过几十年优化和实战测试的 Lucene 和 OpenSearch 等系统，关键词搜索通常更具计算效率。

在大多数情况下，混合搜索是最有效的：关键词匹配用于明显的匹配，而嵌入用于同义词、上位词和拼写错误，以及多模态（如图像和文本）。

优先选择 RAG 而不是微调以获取新知识

我们可以通过 RAG 或微调来将新信息融入大语言模型（LLM），并提升其在特定任务上的表现。那么，我们应该先尝试哪种方法呢？

最新研究表明，RAG 可能更具优势。一项研究比较了 RAG 与无监督微调（即继续预训练），并在 MMLU 的一个子集和当前事件上进行了评估。结果显示，无论是对训练中遇到的知识还是全新的知识，RAG 的表现都优于微调。在另一篇论文中，他们在农业数据集上比较了 RAG 与有监督微调。结果同样显示，RAG 的性能提升比微调更大，尤其是在大语言模型 GPT-4 上（见该论文的表 20）。

除了性能提升之外，RAG 还有一些实际优势。首先，与继续预训练或微调相比，保持检索索引更新既容易又便宜。其次，如果我们的检索索引中包含有毒或有偏见内容的文档，我们可以轻松地删除或修改这些有问题的文档。

此外，RAG 中的 R 提供了更精细的文档检索控制。例如，如果我们为多个组织托管一个 RAG 系统，通过分区检索索引，我们可以确保每个组织只能检索到自己索引中的文档，从而避免无意间将一个组织的信息暴露给另一个组织。

长上下文模型不会让 RAG 过时

随着 Gemini 1.5 提供了多达 1000 万个 tokens 的上下文窗口，一些人开始质疑 RAG 的未来。

我认为 Sora 对 Gemini 1.5 的宣传大大夸大了。一个 1000 万 tokens 的上下文窗口实际上使大多数现有的 RAG 框架变得不必要——你只需将你的数据放入上下文中，像往常一样与模型对话。想象一下，这对那些大部分工程努力都集中在 RAG 上的初创公司/智能体/LangChain 项目会产生怎样的影响 ? 简单一句话：这个 1000 万的上下文杀死了 RAG。干得好，Gemini。

— Yao Fu

虽然长上下文在分析多份文档或与 PDF 对话等用例中将是一个变革性的工具，但有关 RAG 消亡的传闻被大大夸大了。

首先，即使有 1000 万 tokens 的上下文窗口，我们仍然需要一种方法来选择输入模型的信息。其次，除了狭义的“大海捞针”评估之外，我们还没有看到令人信服的数据表明模型可以有效地在如此大的上下文中进行推理。因此，没有良好的检索（和排序），我们有可能让模型被干扰信息淹没，甚至可能将完全不相关的信息填充到上下文窗口中。

最后，是成本问题。Transformer 的推理成本随着上下文长度呈二次方（或在空间和时间上呈线性）增长。仅仅因为存在一个可以在回答每个问题之前读取你组织整个 Google Drive 内容的模型，并不意味着这是个好主意。类比我们如何使用 RAM：即使存在内存容量达到数十 TB 的计算实例，我们仍然需要从磁盘读写数据。

所以不要急着把你的 RAG 丢掉。即使上下文窗口的大小在增加，这种模式仍然有用。