如果你的RAG系统不好用，请收藏一下这份RAG系统优化指南

昨天有个同学来咨询我，说他们做的智能客服很不好用，明明问题答案就在知识库里，但智能客服就是一直胡说。这种问题在RAG系统中太常见了，大概率是在某些地方配置的不合适。

今天我总结了几个关于RAG系统的优化的策略方法，大家可以参考一下。当然，在这提醒一下大家，这些方法不见得一定适合你的RAG系统，你最好是根据你实际的场景针对性地去做调整，并且这个优化工作也并不能一蹴而就，而是需要持续优化。

对于RAG优化，无外乎就这几点：

1）找得准：用户问啥，它得从资料库捞出最相关的那几段“真材实料”。

2）答得对：基于找到的资料，生成准确、靠谱的答案，不能瞎编。

3）啥都懂：简单问题、复杂推理、总结归纳，各种类型都能应对。

4）反应快：别让用户等太久，嗖嗖地出结果。

5）脾气好：遇到用户问题模糊、有歧义甚至跑题，也能得体应对，不崩溃。

而我做对RAG做的优化，主要分成两部分：检索器、生成器。

检索器层面优化

1）用户查询问题理解与改写 

目的是将用户提问的问题做进一步分析，让大模型更能理解用户的目的，这样大模型给出来的答案才更加贴合用户想要的答案。策略有：

• 关键词提取/扩展： 使用传统技术（TF-IDF, BM25）或小型模型提取核心关键词，或使用同义词库扩展。

• 查询重新/扩展：提示LLM将用户查询改写/扩展为更清晰、更完整、包含潜在相关术语的形式（例如：“将用户查询改写为适合在知识库中进行文档检索的形式，补充可能缺失的关键上下文。”）。
  

• 让LLM根据查询生成一个假设的理想答案文档，然后用这个生成的文档去检索真实的相关文档。这能更好地捕捉查询意图。

• 让LLM基于原始查询生成多个不同角度的相关问题，分别检索后合并结果（需注意效率）。

• 上下文感知改写： 在多轮对话中，利用对话历史重写当前查询。

2）嵌入模型优化

• 微调嵌入模型： 这是最有效的方法之一。使用你特定领域的语料（问答对、相关文档）对开源嵌入模型进行微调，使其向量空间更符合你的领域语义。对比学习损失函数（如MultipleNegativesRankingLoss）效果显著。

• 模型选择： 评估不同开源模型（text-embedding-ada-002, bge, e5, multilingual-e5 等）在你领域数据上的表现（使用检索评估指标）。考虑模型大小（速度 vs 效果）和多语言需求。

• 池化方法： 尝试不同的池化方法（Mean, CLS）对token embeddings进行聚合。

3）索引与分块优化

• 分块策略：

• 大小： 尝试不同块大小（128, 256, 512 tokens）。太小丢失上下文，太大引入噪声。没有最佳值，需实验！

• 方法： 固定大小滑动窗口？按句/段落/章节？按语义分割（使用嵌入模型或LLM）？

• 重叠： 在块之间添加重叠（10-20%）有助于保留跨块边界的上下文。

• 结构化分块： 利用文档结构（标题、章节、表格）进行更智能的分块。

• 多粒度索引： 索引不同粒度的块（句子、段落、小节），检索时融合结果或根据查询复杂度选择。

• 元数据： 为每个块附加丰富的元数据（来源文档ID、标题、章节、日期、作者、实体等）。在检索时利用元数据进行过滤或加权。

• 向量索引选择： 根据规模选择合适索引（FAISS, Annoy, HNSW, Pinecone, Weaviate, Milvus, Qdrant）。调优索引参数（nlist, efConstruction, efSearch, M 等）以平衡召回率和速度。

4）检索算法优化

• 相似度度量： 尝试不同的相似度计算（Cosine, Dot Product, Euclidean）。

• Top-K 设置： 检索多少个候选文档？太小可能遗漏关键信息，太大增加噪声和生成器负担。需与生成器能力平衡。

• 混合检索 (Hybrid Search)：

• 加权融合 (RRF - Reciprocal Rank Fusion)： 分别排序后融合两个列表的排名。

• 重新排序 (Re-ranking)： 用向量检索结果作为初筛，再用关键词检索精排（或反之）。

• 串联： 先关键词过滤缩小范围，再进行向量检索。

• 结合语义与关键词： 将向量检索（语义）与传统关键词检索（如BM25/Elasticsearch）结合。方法：

• 查询转换： 如 Step-Back Prompting，先让LLM生成一个更抽象的“概念性”问题，用这个问题检索，再将原始问题、检索结果和抽象问题一起给LLM生成最终答案。

• 多向量检索： 将单个文档表示为多个向量（摘要向量、标题向量、关键短语向量等），检索时融合这些向量表示的结果。

生成器层面优化

1）提示工程

• 清晰指令： 明确要求LLM基于且仅基于提供的上下文作答。强调不可捏造信息。

• 结构化输出： 要求LLM以特定格式（JSON, Markdown, 带引用的段落）输出答案，便于解析和后处理。

• 引用来源： 要求LLM在答案中明确指出引用了哪个文档片段（使用元数据如文档ID、标题）。

• 处理不确定性： 明确指导LLM在上下文不足或问题超出范围时如何回答（如“根据提供的信息，我无法确定...”）。

• 角色扮演： 让LLM扮演特定角色（专家、助手）可能改善语气和风格。

• 思维链 (CoT)： 对于复杂推理问题，提示LLM展示推理步骤。

• 上下文压缩/聚焦： 在Prompt中显式指出最关键的部分，或让LLM先总结检索到的上下文再生成答案（增加开销但可能提升效果）。

• 迭代优化： 不断测试不同的提示模板和指令措辞。

2）LLM模型选择与配置

• 模型选择： 根据任务复杂度、预算、延迟要求选择合适模型（GPT-4-turbo, Claude, Gemini, Command R+, Llama 3, Mixtral 等）。更大模型通常效果更好但更慢更贵。

• 模型参数： 调整 temperature (控制创造性，答案类任务通常设低如0.1-0.3)， top_p (核采样)， max_tokens (限制生成长度)。

• 微调LLM： 使用领域特定指令数据微调LLM，使其更擅长遵循你的RAG提示模板和利用上下文。指令微调是关键。

3）上下文管理

• 长度限制： LLM有上下文窗口限制。确保检索到的文档片段总长度 + Prompt 长度不超过限制。需要智能地选择或压缩Top-K结果。

• 上下文排序： 将最相关的文档片段放在Prompt的靠前位置可能对某些LLM有帮助。

• 上下文压缩/摘要： 在传入LLM前，先对检索到的长文档进行摘要压缩（可用另一个小型LLM）。风险是丢失细节。

最后介绍下我的大模型课：我的运维大模型课上线了，目前还是预售期，有很大优惠。AI越来越成熟了，大模型技术需求量也越来越多了，至少我觉得这个方向要比传统的后端开发、前端开发、测试、运维等方向的机会更大，而且一点都不卷！