RAG 的 12 种核心调优策略

2.3、嵌入模型

嵌入模型是检索的核心，嵌入的质量直接影响检索结果。通常来说，生成的嵌入的维度越高，嵌入的精度就越高。虽可以直接使用通用嵌入模型，但在某些情况下，对嵌入模型进行微调以适应特定用例可能是有意义的，因为这样可以避免后期出现领域外问题。根据 LlamaIndex 的实验证明，微调嵌入模型通常可以导致检索评估指标提高 5-10%，但不是所有嵌入模型都可以进行微调。

2.4、元数据

将向量嵌入存储在向量数据库中时，一些向量数据库可以将它们与元数据（或未向量化的数据）一起存储。使用元数据注释向量嵌入可以对搜索结果进行后处理，例如元数据过滤，或者添加日期、章节或子章节引用等元数据。这有助于在检索后进行二次筛选。

2.5、多索引

若元数据不足以在逻辑上区分不同类型的上下文，可以尝试使用多索引。如可以为不同类型的文档使用不同的索引。需要注意的是，若对元数据和独立集合 (separate collections) 感兴趣，可能也会想要了解原生多租户。

2.6、索引算法

为了在大规模情况下实现快速相似性搜索，向量数据库和向量索引库使用的是近似最近邻搜索（Approximate Nearest Neighbor，ANN）而不是 k 最近邻搜索（k-nearest neighbor，kNN）。顾名思义，ANN 算法近似最近邻，因此可能比 kNN 算法精度略低。

其中，有许多不同的 ANN 算法，例如 Facebook Faiss（聚类）、Spotify Annoy（树）、Google ScaNN（向量压缩）和 HNSWLIB（接近图）。这些 ANN 算法一般都有可以调整的参数，比如 HNSW 中的 ef、efConstruction 和 maxConnections。

此外，可以对索引算法启用向量压缩，使用向量压缩会损失一些精度。但是，你也可以（根据场景）对压缩算法的选择和调整进行优化。在实践过程中，算法的参数通常已经由数据库研究团队在基准实验中进行调整了，RAG 系统的开发人员通常不会改动。

03、推理阶段 - 优化方案

RAG 的主要组成部分是检索和生成。本节主要讨论提升检索效果的策略（查询转换、检索参数、高级检索策略和重新排序模型）。因为相对于生成，检索对结果的影响更大。但检索也会简单涉及到一些生成的策略（LLM 和提示工程）。

3.1、查询转换

RAG 中，用于获取额外上下文的搜索查询也被嵌入到向量空间中，因此查询的表达方式会对搜索结果产生影响。若搜索查询没有得到满意的结果，可尝试一些查询转换技术，如：

• 重新表达：使用语言模型（LLM）重新表达查询，然后再次尝试。
• 假设性文档嵌入（HyDE）：使用语言模型生成对搜索查询的假设响应，然后将两者一起用于检索。
• 子查询：将较长的查询分解为多个较短的查询。

3.2、检索参数

检索是 RAG 的重要组成部分，在检索中首先要考虑的是，语义搜索是否足够满足用例，或者是否希望使用混合搜索。

在采用混合搜索的情况下，需要尝试调整混合搜索中稀疏和密集检索方法的加权聚合。因此，调整参数 alpha 将变得至关重要。

此外，检索结果的数量也很重要。检索到的「上下文数量」将影响「所使用的上下文窗口的长度」。同时，若使用重排序模型，则需要考虑将多少上下文输入到模型中。

虽然语义检索相似性度量方式可以设置，但应根据所使用的嵌入模型来修改，而不是进行不必要的实验。如 text-embedding-ada-002 支持余弦相似度，而 multi-qa-MiniLM-l6-cos-v1 支持余弦相似度、点积和欧几里得距离。

3.3、高级检索策略

高级检索的基本思想为用于检索的块不一定要与用于生成的块相同。理想情况下，会把检索嵌入为较小的块，去检索较大的上下文。

• 句子窗口检索 (Sentence-window retrieval)：不仅检索相关句子，还要检索句子之前和之后的窗口。
• 自动合并检索 (Auto-merging retrieval)：文档以类似树状结构组织。查询时，可以将单独但相关的较小块合并成更大的上下文。

3.4、重排序模型

语义搜索是基于上下文与搜索查询的语义相似性来检索的，但**'最相似'并不一定意味着'最相关'**。重排序模型，例如 Cohere 的重排序模型，可以通过计算每个检索到的上下文与查询相关性的分数来消除不相关的搜索结果。

如果使用重排序模型，可能需要重新调整输入到重排序器的搜索结果数量，以及您希望将多少经过重新排序的结果输入到 LLM 中。和嵌入模型一样，您可能需要根据您的用例来微调重排序模型。

3.5、语言模型微调

LLM 是生成响应的核心组件。类似于嵌入模型，根据您的需求（如开放式与专有模型、推理成本、上下文长度等），有各种各样的 LLM 可供选择。与嵌入模型或重排序模型一样，您可能希望尝试对 LLM 进行微调来适应特定用例。

3.6、提示工程

Prompt 极大地影响 LLM 的生成结果。

请仅基于提供的搜索结果回答问题，切勿参考其他信息！ 这一点非常重要！您的回答必须建立在提供的搜索结果之上。请解释您的答案为何基于搜索结果。

此外，在提示中使用少量示例可以提高完成结果的质量。

上下文长度是一个应该尝试实验的参数，虽然通过增加相关上下文可以改善 RAG 的性能，但如果将相关上下文放置在过多上下文的中间，可能遇到'中间迷失'效应，即 LLM 可能无法识别中间位置的相关上下文。

# 示例：提示工程模板
prompt_template = """
你是一名助手。请仅基于以下上下文回答问题。
上下文：{context}
问题：{question}

回答：
"""

04、优化方案总结

随着越来越多的开发人员在创建 RAG 流程的原型方面积累经验，讨论如何使 RAG 流程达到投入生产所需的性能变得更为重要。本文主要阐述了以下调优点：

数据索引阶段中的策略：

• 数据清洗：确保数据清洁且正确。
• 切块：选择切块技术、切块大小（chunk_size）和切块重叠（overlap）。
• 嵌入模型：选择嵌入模型，包括维度，以及是否进行微调。
• 元数据：是否使用元数据以及元数据的选择。
• 多索引：决定是否为不同的数据集使用多个索引。
• 索引算法：ANN 和向量压缩算法的选择和调整是可以进行调整的，但通常不由 RAG 应用开发者进行调整。

在推理阶段（检索和生成）的策略：

• 查询转换：尝试重新表达、HyDE 或子查询。
• 检索参数：选择搜索技术（如果启用混合搜索，则为 alpha）和检索到的搜索结果数量。
• 高级检索策略：是否使用高级检索策略，如句子窗口或自动合并检索。
• 重排序模型：是否使用重排序模型，重排序模型的选择，输入到重排序模型的搜索结果数量，以及是否对重排序模型进行微调。
• LLMs：LLM 的选择以及是否对其进行微调。
• 提示工程：尝试不同的措辞和少量示例。

RAG 为大模型的落地和使用提供了更多可能，但如何使用 RAG 又是一项关键技术，因此 RAG 的调优显得尤其重要。本文整理了 12 种调优策略，在实际场景中，还存在其他的策略，以上内容仅供参考和探讨。

05、评估与监控

优化不仅仅是调整参数，还需要建立有效的评估体系。常见的 RAG 评估指标包括：

• 召回率 (Recall)：检索到的相关文档占所有相关文档的比例。
• 精确率 (Precision)：检索到的相关文档占所有检索文档的比例。
• MRR (Mean Reciprocal Rank)：第一个相关结果的位置倒数的平均值。

在生产环境中，建议搭建自动化测试集，定期运行回归测试，确保调优后的版本性能不低于基线版本。

06、常见陷阱

1. 幻觉问题：即使有检索增强，模型仍可能编造事实。需在 Prompt 中强调'不知道就说不知道'。
2. 延迟过高：过多的检索步骤和重排序会增加响应时间。需平衡精度与速度。
3. 上下文丢失：过长的上下文可能导致关键信息被淹没。注意 Chunking 策略和滑动窗口。
4. 数据泄露：确保训练数据或知识库不包含敏感信息，特别是在公有云部署时。