RAG系统优化指南：查询生成与重排序实战策略2024

Introduction

在过去的八个月里，我和我的团队深入参与了检索增强生成（RAG）系统的构建与生产环境优化。我们为两个不同的用例实施了RAG：处理900万页的Usul AI，以及一个处理400万页的机密企业级法律AI应用。这段旅程让我们从快速原型构建的初始乐观，跌落到只有最终用户才能察觉的性能不佳的严峻现实，最终通过数月的迭代改进才得以解决。本文提炼了我们的核心经验，并按其最终对系统性能的影响进行了排序。

What Actually Moved the Needle: High-ROI Improvements

我们使用流行框架快速构建的初始原型未能满足真实世界的用户期望。以下按投资回报率（ROI）排序的改进，对于弥补这一差距至关重要。

Query Generation

我们认识到，用户的最终查询通常无法捕捉检索所需的完整语义上下文。为了解决这个问题，我们增加了一个步骤：让一个大语言模型（LLM）回顾整个对话线程，并生成多个查询——结合了语义和基于关键词的方法。这些查询被并行处理，其结果被传递给重排序器。这一策略极大地扩展了我们的检索覆盖范围，并减少了对任何单一混合搜索计算分数的过度依赖。

Reranking

集成一个重排序器可以说是我们代码库中价值最高的增补——改动极小，影响巨大。我们观察到块排名的剧烈变化，远超最初的预期。只要提供足够数量的初始块，重排序器通常可以弥补检索设置上的不足。通过实验，我们找到了一个最佳配置：向重排序器传递 50个块，并接收 15个 作为输出。

Chunking Strategy

这方面需要投入大量精力，并可能消耗你大部分的开发时间。我们为两家企业都构建了自定义的分块流程。关键在于深入理解你的数据：手动审查样本块，并确保 a) 块不会在单词或句子中间被截断，以及 b) 每个块都是一个逻辑上自包含的信息单元。

Injecting Metadata into the LLM Context

最初，我们只向LLM传递原始块文本。一项实验表明，注入相关元数据（如标题、作者、来源）与文本一起，能显著提升上下文的质量和LLM生成的最终答案。

Query Routing

我们遇到了许多超出RAG核心能力范围的用户问题（例如，“总结这篇文章”、“这是谁写的？”）。为了高效处理这些问题，我们构建了一个轻量级的路由器，用于检测此类意图，并将其重定向到一个更简单的流程——通常是API调用结合LLM——完全绕过完整的RAG检索设置。

Our Evolving Technical Stack

我们的基础设施选择基于性能、成本和特定功能需求而不断演变。

Conclusion & Open-Source Contribution

从一个可运行的RAG原型到生产级系统的道路，铺满了迭代优化的过程，其重点在于查询理解、结果重排序和智能数据分块等基础要素。为了整合这些经验并回馈社区，我们将我们的方法整合进一个开源项目：agentset-ai/agentset，该项目在宽松的MIT许可证下发布。我们欢迎任何问题、反馈和贡献。