RAG优化大法：20+招式助你玩转大模型应用！从零基础到精通，收藏这篇就够了！

关注

原创最新推荐文章于 2026-03-05 01:25:47 发布 1k 阅读 AI 写同款· GEO 优化 ›

检索增强生成(RAG) 优化策略篇本文详细介绍了检索增强生成（RAG）技术的各个优化策略，包括文档块切分、文本嵌入模型、提示工程、大模型迭代、架构优化、索引优化、索引数据优化等多个方面。通过这些优化策略，RAG 技术在处理复杂查询和生成信息丰富回应方面展示了巨大的潜力。未来，RAG 技术将在垂直优化、横向扩展以及生态系统构建等方面继续发展，为多领域应用提供更低的训练成本和更优的性能表现。阅读详情

RAG优化大法：20+招式助你玩转大模型应用！

大语言模型（LLMs）已经火到出圈，简直成了我们工作和生活中的“万金油”！它们聪明又全能，和信息的互动方式都被它们给颠覆了。

不过，可别以为LLMs就无敌了。它们有时候也会“抽风”，给你整出些“幻觉”，要么就是抱着过时的信息不撒手，遇到专业问题就“掉链子”，逻辑推理能力也时常让人捉急。

在现实世界中，数据得像“窜天猴”一样更新，生成的内容还得像“玻璃罩”一样透明可追溯，不然成本控制和数据隐私就都成了“老大难”。所以，光靠这些“黑盒”模型可不行，咱得有更精细的“武器”来应对这些挑战。这不，检索增强生成技术（Retrieval-Augmented Generation，RAG）就闪亮登场了，成了LLM时代的“弄潮儿”！

基础RAG架构

瞅瞅上图，基础RAG架构的流程简单得就像“1+1=2”，最大的特点就是数据单向流通。搭个这样的系统快得很，但离真正“上战场”还差得远呢。想要让这套系统召回文档更准、更“皮实”，有两条路子：一是多找几条“腿”走路（增加召回管道），二是加上“反馈机制”。增加召回管道就像“子查询”、“rag-fusion”、“混合检索”，多路召回，把召回率拉满；增加反馈机制就像“rerank”、“后退提示”、“self-rag”，优化原始结果，把准确率提上去。

这么一搞，RAG架构的数据和信息就不再是“单行道”了，而是“四通八达”、“并驾齐驱”。

进阶RAG结构

为了让大家看得更清楚，咱就按照数据流动的方向，从文本预处理、文本分块、嵌入、检索和生成这几个环节，挨个儿说说这些优化方法。

文本数据“整容术”

不管RAG系统多复杂，数据驱动的特性决定了，数据质量得高！检索之前，原始数据得这么优化：

实体解析：给实体和术语“正名”，消除歧义，统一说法。比如，把“LLM”、“大语言模型”、“大模型”都叫“大模型”，多省事！
文档划分：不同主题的文档，得像“分院帽”一样，分得清清楚楚。要是人眼都分不清哪个文档能回答问题，检索系统也“没辙”。
数据增强：用同义词、换个说法，甚至用“外语”翻译，让知识库更“丰满”。
处理特殊数据：比如那些“时效性”强的数据，对于更新快的主题，得有个机制让过时的文档“下岗”或者“翻新”。
增加元数据：给内容加个“摘要”、盖个“时间戳”、想想用户可能问啥问题，这些都能让知识库更“有料”。

文本分块“切西瓜”

通常，被检索的知识库里的数据量，比LLM能接受的输入长度大得多，所以“切西瓜”（Chunking）得讲究技巧，既不能超出LLM的“胃口”，还得保证块和块之间有区别，块内部又得“拧成一股绳”。当然，这是最理想的状态，现实中，可能有些文档像“散文”，段落之间没啥明显区别，段落内部又特别“散”，整篇文档还特别长。咱也不可能提前就把文本按内容切得“天衣无缝”，毕竟下游还有LLM这样的“聪明”模型呢，咱提供的块不过是“提示”。但咱还是得尽量提供有用的信息，别给LLM添乱。所以，可以试试这些高级的“切西瓜”方法：

句子分割：用NLTK或者spaCy库的句子分割功能，主流开发框架如langchain都集成了，直接“拿来主义”。
递归分割：像“套娃”一样，重复应用分块规则，把文本“大卸八块”。比如，在langchain中，先用段落换行符（\n\n）分割。然后看看这些块的大小，如果不超过“警戒线”，就留着。超过了，就用单换行符（\n）再切。以此类推，不断根据块大小更新更小的分块规则（比如空格，句号）。这种方法能灵活调整块的大小。比如，文本中信息“扎堆”的地方，可能需要切得更细；信息少的地方，就可以切得“粗犷”些。
语义分割：算算向量化后的文本的相似度，从语义层面“下刀”。
特殊结构分割：针对Markdown、LaTex、JSON这些“特殊”结构的内容，有专门的分割器，确保“原汁原味”。

“切西瓜”还有个重要的事儿，就是块的大小。除了嵌入模型，文档类型、用户查询的长度和复杂性，都影响着块的大小。处理长篇文章或书籍，大块头有助于保留更多上下文和主题连贯性；社交媒体帖子，小块头可能更适合捕捉每个帖子的“灵魂”。如果用户的查询通常简短又具体，小块头可能更合适；反过来，查询复杂，可能就需要大块头。实际操作中，咱可能还得不断“试错”，在一些测试中，128大小的块往往是“最佳选择”，没头绪的时候，可以从这个大小开始“摸索”。

嵌入“变身术”

接下来就是数据处理的“压轴戏”了，相当于数据的“类型转换”，就是用嵌入（Embedding）模型把文本数据变成向量（Vectorization），方便在检索阶段用向量检索（Vector Retrieval）。嵌入阶段有几个“加分项”：

尽量用动态嵌入：动态嵌入比静态嵌入更能处理“一词多义”。比如：“我买了一张光盘”，这里的“光盘”是圆盘；“光盘行动”里，“光盘”是把饭吃光，语义完全不一样。静态嵌入，向量是固定的。但引入自注意力机制的模型，比如BERT，能提供动态的词义理解，同一个词在不同语境下，向量也不同。
微调嵌入：大多数嵌入模型都是在通用语料上“修炼”的，有些项目为了让模型对垂直领域的词汇更“感冒”，会对嵌入模型“微调”，让模型对垂直领域词汇和通用词汇“一视同仁”，不“跑偏”。
混合嵌入：对用户问题和知识库文本用不同的嵌入模型。

查询优化“导航仪”

实际环境中，可能因为用户的表达“五花八门”或者“含糊不清”，导致检索时召回率和准确率“不给力”，这时候就得给查询“导航”一下，规范和丰富查询包含的信息，方便系统检索到相关的文档。查询优化有这么几招：

查询重写：让LLM或者用专门的“问题重写器”（通常是微调过的小Transformer）给用户的问题“改头换面”。
后退提示：让LLM提出一个关于高层次概念或原则的抽象通用问题（叫“后退”问题）。后退问题的抽象程度，得根据具体任务调整。最后，后退问题和原始问题一起检索。比如，问“Estella Leopold在1954年8月至11月期间上了哪所学校？”，这问题不好直接回答，因为时间限制太细。这时候，问个后退问题“Estella Leopold的教育经历怎么样的？”，就能帮系统检索。
Follow Up Questions：用LLM针对历史对话和当前问题，生成一个独立问题。这招主要针对这些情况：a. 后续问题建立在前一次对话的基础上，或引用了前一次谈话。比如，用户先问“我在意大利能做什么”，然后问“那里有什么类型的食物”——如果只嵌入“那里有哪种类型的食物”，LLM就不知道“那里”在哪。b. 嵌入整个对话（或最后k条消息）。如果后续问题和之前的对话完全无关，可能会返回无关结果，分散LLM的注意力。
HyDE：用LLM生成一个“假设”答案，把它和问题一起检索。HyDE的核心思想是，接收用户提问后，先让LLM在没有外部知识的情况下，生成一个假设性的回复。然后，把这个假设性回复和原始查询一起用于向量检索。假设回复可能“不靠谱”，但蕴含着LLM认为相关的信息和文档模式，有助于在知识库中找类似的文档。
多问题查询：基于原始问题，让LLM从不同角度“发问”，生成多个新问题或者子问题，用每个新问题检索，后续用RRF或者rerank合并不同问题的检索结果。比如，问“谁最近赢得了总冠军，红袜队还是爱国者队？”，可以生成两个子问题：a. 红袜者队上次赢得总冠军是啥时候？b. 爱国者队上次赢得总冠军是啥时候？

检索“寻宝图”

检索（Retrieval）的终极目标，就是找到最相关的文档，或者保证最相关的文档在找到的文档列表里。为了实现这个目标，有这么几招：

上下文压缩：文档块太大，可能包含太多“废话”，传递这样的文档块，可能导致LLM调用更贵，响应更差。上下文压缩，就是让LLM根据上下文，把单个文档内容“瘦身”，或者对返回结果“过滤”，只留下相关信息。
句子窗口搜索：反过来，文档块太小，会导致上下文“缺失”。有个解决方案叫窗口搜索，核心思想是，提问匹配好文档块后，把这块周围的块也当成上下文，一起交给LLM，让LLM对文档上下文理解更透彻。
父文档搜索：父文档搜索也是个类似的方案，先把文档分成尺寸更大的主文档，再把主文档分割成更短的子文档。用户问题和子文档匹配，然后把子文档所属的主文档发给LLM。
自动合并：自动合并是在父文档搜索上更复杂的方案。同样，先把文档“大卸八块”，比如按三层树状结构切割，顶层节点的块大小1024，中间层512，底层叶子节点128。检索时，只拿叶子节点和问题匹配，如果某个父节点下的大部分叶子节点都和问题匹配，就把这个父节点作为结果返回。
混合检索：RAG系统，本质上是开放域、基于自然语言的问答系统。为了获得开放式用户查询的高事实召回率，概括和聚焦应用场景，选择合适的检索模式或组合很重要。大多数文本搜索场景，主要目标是确保最相关的结果出现在候选列表里。混合检索，通过混合多个检索方法，实现不同检索技术的“强强联合”，最大化事实召回率。比如，可以用向量检索+关键词检索的组合，构建RAG系统的检索模块。
路由机制：建立了多个针对不同数据类型和查询需求的索引后，比如，有个索引专门处理摘要类问题，另一个专门应对直接寻求具体答案的问题，还有一个专门针对需要考虑时间因素的问题。这时候，就需要用路由机制，选择最合适的索引检索数据，提升检索质量和响应速度。
使用Agent：这招就是用Agent决定用啥检索方法，从不同的检索方法中选一个或多个召回。组合方式也灵活，可以是“垂直”关系，也可以是“平行”关系。比如，问“最新上映的科幻电影推荐”，Agent可能先把它“导”到专门处理当前热点话题的索引，然后利用专注于娱乐和影视内容的索引，生成相关推荐。

检索后处理“精修师”

检索后处理，概念很宽泛，就是对检索结果“精加工”，方便后续LLM更好地生成，典型的就是重排序（Rerank）。向量检索，其实就是算语义层面的相似性，但语义最相似，不一定最相关。重排模型，通过对初始检索结果进行更深入的相关性评估和排序，确保最终展示给用户的结果更符合查询意图。实现重排序，除了可以提示LLM重排，更多的是用专门的重排序模型（比如闭源的Cohere，开源的BAAI和IBM发布的模型）。这些模型会考虑更多特征，比如查询意图、词汇的多重语义、用户的历史行为和上下文信息，保证最相关的文档排在最前面。

生成“演说家”

生成（Generation）阶段的优化，更多的是考虑用户体验，有几点可以参考：

多轮对话：就是带聊天历史的RAG，AI搜索的“明星产品”perplexity就支持多轮对话，用户可以通过连续对话，深入了解解决某个问题。
增加追问机制：在prompt里加上“如果无法从背景知识回答用户的问题，则根据背景知识内容，对用户进行追问，问题限制在3个以内”。这招没啥技术含量，主要靠大模型的能力。不过能大大改善用户体验，用户在多轮引导中，逐步明确自己的问题，从而得到合适的答案。
prompt优化：RAG系统中的prompt，应明确指出回答只基于搜索结果，不要加任何其他信息。比如，可以设置prompt：“你是一名智能客服。你的目标是提供准确的信息，并尽可能帮助提问者解决问题。你应保持友善，但不要过于啰嗦。请根据提供的上下文信息，在不考虑已有知识的情况下，回答相关查询。”当然，也可以根据场景需要，适当让模型的回答融入一些主观性或其对知识的理解。此外，用Few-shot的方法指导LLM如何利用检索到的知识，也是提升LLM生成内容质量的“妙招”。
用户反馈循环：基于现实世界用户的反馈，不断更新数据库，标记它们的真实性。