详细阐述了检索增强生成（RAG）系统的 12 种核心调优策略，涵盖数据索引与推理两大阶段。索引阶段涉及数据清洗、分块技术、嵌入模型选择、元数据管理、多索引架构及索引算法优化。推理阶段重点讲解查询转换、检索参数调整、高级检索策略、重排序模型应用、语言模型微调及提示工程设计。文章还补充了评估指标与常见陷阱分析，旨在帮助开发者构建高性能、低延迟的 RAG 生产级应用。
数据科学是一门实验性科学。它始于'无免费午餐定理'，即不存在适用于每个问题的通用算法。因此，数据科学家们使用实验跟踪系统来帮助调整他们机器学习项目的超参数，以实现最佳性能。
检索增强生成（Retrieval-Augmented Generation，以下简称 RAG）是一种比较有效的大模型使用场景中的补充模型能力的机制，在实践中可以通过调整其各种参数提高 RAG 流程的性能。类似于深度学习中的实验，数据增强技术不是超参数，而是可以调整和实验的旋钮。
本文从数据索引阶段和推理阶段分别阐述 RAG 流程的'超参数'和调优建议。
请注意，本文的用例是基于文本类的 RAG 应用。对于多模态的 RAG 应用，可能需要考虑其他不同的因素。
数据索引阶段是构建 RAG 的准备步骤，类似于机器学习中的数据清洗和预处理。数据索引阶段通常包括以下步骤：
数据质量在 RAG 中起着至关重要的作用，因此在进行以下任何步骤之前，需确保数据集符合以下标准：
在 RAG 中，对文档进行切块是处理外部知识源的一项重要步骤，会直接影响性能。分块是一种生成有逻辑关联的信息片段的技巧，通常做法是通过将长文档分割成小节（也可以将小片段组合成段落）。
分块技术是影响分块效果的一个因素。如在 LangChain 中，不同的文本拆分器根据不同的逻辑拆分文档，比如按字符、标记等。这要根据你的数据类型来决定。常见的策略包括：
分块长度（chunk_size）也要具体情况具体分析：若使用场景是问答，可能需要更短的、更具体的切块；但如果是摘要，可能需要更长的切块。此外，如果一个切块太短，可能不包含足够的上下文。另一方面，如果切块太长，可能包含太多不相关的信息。
另外，还需要考虑在切块之间引入一些额外上下文的'滚动窗口'（overlap），来提高信息连贯性。通常建议重叠部分占 chunk_size 的 10%-20%。
# 示例：LangChain 中的递归字符分块配置
from langchain.text_splitter import RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50,
length_function=len,
)
chunks = text_splitter.split_text(text)
嵌入模型是检索的核心，嵌入的质量直接影响检索结果。通常来说，生成的嵌入的维度越高，嵌入的精度就越高。虽可以直接使用通用嵌入模型，但在某些情况下，对嵌入模型进行微调以适应特定用例可能是有意义的，因为这样可以避免后期出现领域外问题。根据 LlamaIndex 的实验证明，微调嵌入模型通常可以导致检索评估指标提高 5-10%，但不是所有嵌入模型都可以进行微调。
将向量嵌入存储在向量数据库中时，一些向量数据库可以将它们与元数据（或未向量化的数据）一起存储。使用元数据注释向量嵌入可以对搜索结果进行后处理，例如元数据过滤，或者添加日期、章节或子章节引用等元数据。这有助于在检索后进行二次筛选。
若元数据不足以在逻辑上区分不同类型的上下文，可以尝试使用多索引。如可以为不同类型的文档使用不同的索引。需要注意的是，若对元数据和独立集合 (separate collections) 感兴趣，可能也会想要了解原生多租户。
为了在大规模情况下实现快速相似性搜索，向量数据库和向量索引库使用的是近似最近邻搜索（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 系统的开发人员通常不会改动。
RAG 的主要组成部分是检索和生成。本节主要讨论提升检索效果的策略（查询转换、检索参数、高级检索策略和重新排序模型）。因为相对于生成，检索对结果的影响更大。但检索也会简单涉及到一些生成的策略（LLM 和提示工程）。
RAG 中，用于获取额外上下文的搜索查询也被嵌入到向量空间中，因此查询的表达方式会对搜索结果产生影响。若搜索查询没有得到满意的结果，可尝试一些查询转换技术，如：
检索是 RAG 的重要组成部分，在检索中首先要考虑的是，语义搜索是否足够满足用例，或者是否希望使用混合搜索。
在采用混合搜索的情况下，需要尝试调整混合搜索中稀疏和密集检索方法的加权聚合。因此，调整参数 alpha 将变得至关重要。
此外，检索结果的数量也很重要。检索到的「上下文数量」将影响「所使用的上下文窗口的长度」。同时，若使用重排序模型，则需要考虑将多少上下文输入到模型中。
虽然语义检索相似性度量方式可以设置，但应根据所使用的嵌入模型来修改，而不是进行不必要的实验。如 text-embedding-ada-002 支持余弦相似度，而 multi-qa-MiniLM-l6-cos-v1 支持余弦相似度、点积和欧几里得距离。
高级检索的基本思想为用于检索的块不一定要与用于生成的块相同。理想情况下，会把检索嵌入为较小的块，去检索较大的上下文。
语义搜索是基于上下文与搜索查询的语义相似性来检索的，但**'最相似'并不一定意味着'最相关'**。重排序模型，例如 Cohere 的重排序模型，可以通过计算每个检索到的上下文与查询相关性的分数来消除不相关的搜索结果。
如果使用重排序模型，可能需要重新调整输入到重排序器的搜索结果数量，以及您希望将多少经过重新排序的结果输入到 LLM 中。和嵌入模型一样，您可能需要根据您的用例来微调重排序模型。
LLM 是生成响应的核心组件。类似于嵌入模型，根据您的需求（如开放式与专有模型、推理成本、上下文长度等），有各种各样的 LLM 可供选择。与嵌入模型或重排序模型一样，您可能希望尝试对 LLM 进行微调来适应特定用例。
Prompt 极大地影响 LLM 的生成结果。
请仅基于提供的搜索结果回答问题，切勿参考其他信息！ 这一点非常重要！您的回答必须建立在提供的搜索结果之上。请解释您的答案为何基于搜索结果。
此外，在提示中使用少量示例可以提高完成结果的质量。
上下文长度是一个应该尝试实验的参数，虽然通过增加相关上下文可以改善 RAG 的性能，但如果将相关上下文放置在过多上下文的中间，可能遇到'中间迷失'效应，即 LLM 可能无法识别中间位置的相关上下文。
# 示例：提示工程模板
prompt_template = """
你是一名助手。请仅基于以下上下文回答问题。
上下文：{context}
问题：{question}
回答：
"""
随着越来越多的开发人员在创建 RAG 流程的原型方面积累经验，讨论如何使 RAG 流程达到投入生产所需的性能变得更为重要。本文主要阐述了以下调优点：
数据索引阶段中的策略：
在推理阶段（检索和生成）的策略：
RAG 为大模型的落地和使用提供了更多可能，但如何使用 RAG 又是一项关键技术，因此 RAG 的调优显得尤其重要。本文整理了 12 种调优策略，在实际场景中，还存在其他的策略，以上内容仅供参考和探讨。
优化不仅仅是调整参数，还需要建立有效的评估体系。常见的 RAG 评估指标包括：
在生产环境中，建议搭建自动化测试集，定期运行回归测试，确保调优后的版本性能不低于基线版本。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online