AI 的创新与领先地位显而易见，没有放缓的迹象。最近，Google 透露了在 Gemini 1.5 大型语言模型（LLM）之后仅仅两个月，这款能够处理高达令人印象深刻的 1000 万个令牌的上下文的最新模型。与此同时，OpenAI 推出了 Sora，这是一个基于文本生成视频的强大模型，以其迷人的视觉效果而闻名。这两项尖端技术的较量引发了对 AI 未来的讨论，尤其是关于检索增强生成 (RAG) 技术的未来及其可能的终结。
在这篇博文中，我们将探讨 Gemini 的长上下文能力的细微差别、局限性和对 RAG 技术演进的影响。最重要的是，我们将讨论 RAG 是否即将走向消亡以及如何优化 RAG 系统。
理解 Gemini 的长上下文能力
虽然 Sora 的视觉效果更引人注目，我对 Gemini 和其超过 50 页的技术报告更感兴趣，该报告探索了 Gemini 的长上下文和多模态能力的测试。根据这份报告，Gemini 1.5 Pro 支持长达 1000 万个令牌的超长上下文和多模态数据处理，使 Gemini 能够无缝地与各种数据交互，从整本书、庞大的文档集合、大量的代码库到长达一小时的电影。
Gemini 1.5 Pro 支持长达 10M 个令牌的上下文。图片来源：https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/
检索稳定性和准确性
这份报告介绍了一种“在一大堆中寻找一根针”的评估方法，用于测试和比较 Gemini 1.5 Pro 和 GPT-4 的检索能力。在测试中，Google 在长文档的不同位置插入文本段（“针”），Gemini 和 GPT 需要找到并检索它们。
测试结果显示，Gemini 1.5 Pro 可以从最多 530,000 个令牌中实现 100% 的召回率，并保持超过 99.7% 的召回率从最多 1M 个令牌。即使在 10M 个令牌的超级长文档中，该模型保持了令人印象深刻的 99.2% 的召回率。虽然 GPT-4 在处理少于 128,000 个令牌时表现出色，但 Gemini 在处理更长上下文方面更擅长。这些结果突出了 Gemini 在处理长达 10M 个令牌的极其长上下文中的出色检索稳定性和准确性。
图片来源：https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
长上下文 LLMs 是否会杀死 RAG？
将检索、生成和提示作为代码集成的 RAG 框架是一种前沿技术，它无缝地结合外部资源来丰富大型语言模型的知识库，以提供准确和相关的答案。这是解决大型语言模型的基本挑战（如幻觉和缺乏领域专业知识）的有效解决方案。
目睹了 Gemini 处理长上下文的能力之后，一些声音迅速预测了 RAG 的终结。例如，在 Twitter 上对 Gemini 1.5 Pro 的审查中，高华博士大胆地表示，“10M 上下文杀死了 RAG。”
这种说法是真的吗？在我看来，答案是否定的。RAG 技术的发展刚刚开始，并将持续进化。尽管 Gemini 在管理长上下文方面表现出色，但其面临由四大挑战组成的持续挑战：速度、价值、体积和多样性。
LLMs 的四大挑战
速度：Gemini 面临着在处理大量上下文时无法实现次秒响应时间的难题，例如在 360,000 个上下文中响应的时间延迟达到 30 秒。尽管对大型模型计算能力的乐观期待，但大型变压器模型在检索长上下文时在达到次秒级别的快速响应方面仍然面临挑战。
价值：大型语言模型的价值主张受到在处理长上下文时生成高质量答案的大量推理成本的挑战。例如，检索 1,000,000 字符的大量数据集按每 1000 字符 0.0015 美元的速率，可导致大量费用，单次请求的费用可能高达 1.5 美元。这种成本因素使这种高昂的支出在日常使用中变得不切实际，对广泛采用构成重大障碍。
体积：尽管 Gemini 能够处理长达 10M 个令牌的上下文窗口，但其容量与未结构化数据的广阔规模相比显得微不足道。例如，没有一个模型，包括 Gemini，能够充分容纳谷歌搜索索引中发现的大量数据。此外，私人企业数据将需要留在其所有者的范围内，他们可以选择使用 RAG、训练自己的模型或使用私有 LLM。
多样性：现实世界的应用不仅涉及像长文本、图像和视频这样的非结构化数据，还包括时间序列数据、图数据和代码变更等难以通过训练目的捕获的结构化数据。流程化数据结构和检索算法对于高效处理此类各种数据至关重要。所有这些挑战凸显了在人工智能应用开发中采取平衡方法的重要性，使 RAG 在人工智能进化的背景下愈发关键。
优化 RAG 有效性的策略
尽管 RAG 已经在降低 LLM 幻觉方面证明了其益处，但它也存在局限性。在本节中，我们将探讨优化 RAG 有效性的策略，以在准确性与性能之间取得平衡，使 RAG 系统能够适应更广泛的应用场景。
增强长上下文理解
传统 RAG 技术通常依赖于分块以矢量化非结构化数据，主要由于嵌入模型和上下文窗口大小的限制。然而，这种分块方法存在两个明显的缺点。
首先，它将输入序列分解为孤立的片段，破坏了上下文的连续性，从而对嵌入质量产生负面影响。
其次，存在将连续信息分离为不同片段的风险，这可能导致关键信息的不完整检索。
为了解决这些挑战，基于 LLM 的新兴嵌入策略越来越受到关注，它们能够提供更好的嵌入能力并支持扩展的上下文窗口。例如，SRF-Embedding-Mistral 和 GritLM7B 是在 Huggingface MTEB 领导板上性能最佳的嵌入模型，支持长达 32k 个令牌的上下文，显示出嵌入能力的显著提升。这提高了 RAG 系统理解和处理长上下文的能力。
为了解决上述挑战的另一种有效方法是最近推出的 BGE Landmark 嵌入策略。该方法采用无分块架构，根据连贯的长上下文可为细粒度输入单元，例如句子，生成嵌入。它还利用位置感知功能，以帮助完整检索长上下文内连续句子相关的有用信息。因此，地标嵌入有助于增强 RAG 系统理解并处理长上下文的能力。
地标嵌入的架构。地标（LMK）标记附加到每个句子的末尾。使用滑动窗口处理长度超过 LLM 上下文窗口的输入文本。
此图比较了帮助 RAG 应用程序回答问题的两种嵌入方法：句嵌入和地标嵌入。前者与分块上下文一起工作，倾向于选择关键句子。后者保持连贯的上下文，使其能够选择正确的句子。蓝色和紫色高亮的句子分别是两种嵌入方法检索的答案。仅依赖句嵌入的 RAG 系统给出了错误答案，而基于地标嵌入的 RAG 系统给出了正确答案。此图像改编自：https://arxiv.org/abs/2402.11573
利用混合搜索提高检索质量
RAG 响应的质量依赖于其检索高质量信息的能力。数据清理、结构化信息提取和混合搜索都是提高检索质量的有效方法。最近的研究表明，稀疏向量模型，如 Splade，在跨域知识检索、关键词感知和许多其他领域中都优于密集向量模型。
最近开源的 BGE_M3 嵌入模型可以在同一模型中生成稀疏、密集和类似于 Collebr 的令牌向量。这种创新极大地提高了检索质量，通过在不同类型的向量上进行混合检索。值得注意的是，这种方法与向量数据库供应商如 Zilliz 公认的混合搜索概念相一致。例如，即将发布的 Milvus 2.4 提供了对密集和稀疏向量的更全面的混合搜索。
利用高级技术增强 RAG 的性能
在本图中，文奇·格兰茨列出了构建 RAG 管道时面临的 12 个痛点，并提出了 12 个相应的解决方案来解决这些挑战。图片来源：https://towardsdatascience.com/12-rag-pain-points-and-proposed-solutions-43709939a28c
最大化 RAG 能力涉及解决众多算法挑战，并利用复杂的工程能力和技术。正如文奇·格兰茨在她的博客中指出的那样，构建 RAG 管道至少面临 12 个复杂工程挑战。解决这些挑战需要对机器学习算法有深入理解，并使用如查询重写、意图识别和实体检测等复杂技术。
甚至高级模型如 Gemini 1.5 也面临着重大挑战。它们在 Google 的 MMLU 测试基准测试中达到 90.0% 的准确率需要 32 次调用。这强调了在 RAG 系统中最大化性能的性质。
向量数据库是 RAG 管道中的前沿 AI 技术之一，其核心组件之一。选择更成熟和先进的向量数据库，如 Milvus，不仅可以从答案生成扩展到分类、结构化数据提取和处理复杂的 PDF 文档等任务。这种多方面增强为 RAG 系统在更广泛的应用场景中提供了适应性。
结论：RAG 仍然是 AI 应用持续成功的基石。
大型语言模型正在塑造世界，但它们无法改变世界的本质原理。自 1945 年冯·诺依曼架构问世以来，内存、计算和外部存储之间的分离一直存在。然而，即使如今单机内存达到太字节级别，SATA 和闪存磁盘在不同应用场景中仍然扮演着至关重要的角色。这表明，在技术演化的背景下，现有范式的韧性。
RAG 框架仍然是 AI 应用持续成功的基石。它为大型语言模型提供的长期记忆对寻求在查询质量和成本效益之间取得最佳平衡的开发人员来说不可或缺。在大型企业部署生成 AI 时，RAG 是控制成本而不牺牲响应质量的关键工具。
就像大型内存的发展无法驱逐硬盘一样，RAG 的作用，与其支持技术相结合，仍然是不可或缺的，并且具有适应性。它已准备好在 AI 应用不断演化的背景下持续存在。
