大规模语言模型（LLMs）的能力大家已有目共睹——它们能对话、能创作、能编程，几乎无所不能。然而，它们也远非完美。幻觉、信息滞后、在专业领域表现不足，这些短板始终难以回避。 在实际应用场景中，数据需要实时更新，生成内容必须可溯源，成本要可控，隐私也需要得到充分保护。单纯依赖这些“黑盒”模型显然不够。正是这些现实需求，推动了检索增强生成（RAG）技术从幕后走向台前，成为LLM应用落地的主流路径之一。 从上图可以看到，最基础的RAG架构其实非常直观，核心特征就是**数据单向流动**。搭建速度虽快，但距离真正的生产环境仍有不小差距。要提升文档召回率和系统鲁棒性，主要可以从两条路径入手：**一是增加召回通道**，例如查询变换、RAG-Fusion、混合检索等多路召回策略；**二是引入反馈机制**，比如通过Rerank、后退提示、Self-RAG等方法，对原始结果进行进一步优化，提高准确率。 这两条路走下来，原本单向的数据流就变成了多向并行，系统也变得更加灵活。 为了方便大家理解，下面我们顺着数据流动的方向，从文本预处理、分块、嵌入、检索到生成这几个环节，逐一探讨有哪些优化方法。 ### 文本数据预处理 无论RAG系统结构多复杂，数据质量始终是底线。在检索之前，对原始数据进行优化，包括以下几个方向： - **实体解析**：消除实体和术语的歧义，确保引用一致性。例如，将“LLM”、“大语言模型”、“大模型”统一为同一表述。 - **文档划分**：合理区分不同主题的文档。如果人类自己都不知道该翻哪本书才能回答问题，检索系统更不可能做到。 - **数据增强**：利用同义词、释义甚至其他语言的翻译来扩充知识库的多样性。 - **处理特殊数据**：对于时间敏感的内容，需要让过时的文档失效或及时更新。 - **增加元数据**：为文档添加内容摘要、时间戳、可能被问到的问题等附加信息，让知识库更加丰富。 ### 文本分块 知识库中的数据量通常远超LLM的输入长度上限，因此分块的核心目标就是在不超限的前提下，尽量做到**块之间差异明显**，**块内部内容连贯**。这自然是最理想的状态。实际工作中，你可能会遇到一篇散文式的文档，段落之间没有明显的主题切换，段落内部又特别散乱，整篇还特别长。我们不可能事先将文本按照内容完美切分——毕竟下游还有LLM这个“聪明”的角色，它自己也能处理一部分。但无论如何，我们仍要尽量为其提供有用的信息，而不是一堆无关的噪音来分散注意力。 下面几种分块方法值得关注： - **句分割**：使用NLTK或spaCy这类库进行句子分割，主流框架如LangChain已经集成了该功能。 - **递归分割**：反复应用分块规则来递归地分解文本。例如，在LangChain中，会先按段落换行符（`\n\n`）切分，如果切出的块大小未超过阈值就保留；超过阈值的，再用单换行符（`\n`）继续切，依此类推。这种方法灵活性高，可以动态调整块的大小。 - **语义分割**：计算文本向量化后的相似度，从语义层面进行分割。 - **特殊结构分割**：专门针对Markdown、LaTeX、JSON这类结构化内容的分割器，确保保留原有的结构。 另一个关键因素是块的大小。除了嵌入模型本身，文档类型以及用户查询的长度和复杂程度也很重要。处理长篇内容时，大块能保留更多上下文和主题连贯性；而社交媒体帖子这类短文本，小块反而更能捕捉精确语义。如果用户的查询通常短而具体，小块更合适；如果查询比较复杂，大块可能更优。实际项目中往往需要反复实验。不少测试结果表明，大小为128的分块常常是一个不错的起点，可以从此入手进行尝试。 ### 嵌入 嵌入环节本质上是数据的**类型转换**：将文本通过嵌入模型转换为向量，方便后续进行向量检索。这里有几个优化要点： - **尽量使用动态嵌入**：相比静态嵌入，动态嵌入能更好地处理一词多义。例如，“光盘”在“我买了一张光盘”和“光盘行动”中意思截然不同，静态嵌入只有一个向量，而BERT这类引入注意力机制的模型，能根据上下文动态调整词义。 - **微调嵌入模型**：大多数嵌入模型是在通用语料上训练的。如果项目涉及垂直领域的词汇，可以对模型进行微调，使其对这些专业词汇和通用词汇一视同仁，避免注意力分散。 - **混合嵌入**：对用户问题和知识库中的文本，使用不同的嵌入模型。 ### 查询优化 实际场景中，用户提问可能表述不清、不够完整，导致检索阶段的召回率和准确率都不够理想。这时就需要对查询进行优化，让信息更加规范、丰富。常见方法包括： - **查询重写**：通过大模型或专门的“问题重写器”（通常是微调过的小型Transformer）来改写用户问题。 - **后退提示**：让大模型先提出一个关于高层次概念或原则的抽象问题（即“后退”问题）。例如，问“Estella Leopold在1954年8月至11月期间上了哪所学校”，这个问题因时间范围限制很难直接回答。后退成“Estella Leopold的教育经历怎么样？”，反而更容易检索。 - **Follow Up Questions**：利用大模型基于历史对话和当前问题，生成一个独立的问题。主要应对两种情况：一是后续问题引用前文，比如用户先问“我在意大利能做什么”，再问“那里有什么类型的食物”，如果不处理，LLM不知道“那里”指哪里；二是嵌入整个对话，如果后续问题和前文无关，反而可能返回不相关的结果，分散注意力。 - **HyDE**：先让大模型不借助外部知识，生成一个“假设”答案，然后将这个假设答案和原始问题一起拿去检索。假设回复可能包含错误信息，但它蕴含了大模型认为相关的文档模式，有助于在知识库中找到相似内容。 - **多问题查询**：基于原始问题，让大模型从不同角度生成多个子问题，分别检索，然后用RRF或Rerank合并结果。例如，原始问题“谁最近赢了总冠军，红袜队还是爱国者队？”可以拆成两个子问题：“红袜队上一次赢总冠军是什么时候？”和“爱国者队上一次赢总冠军是什么时候？” ### 检索 检索环节的目标很简单：找到最相关的文档，或者确保最相关的文档出现在结果列表里。方法包括： - **上下文压缩**：文档块过大时，可能包含大量不相关信息，既增加成本又影响响应质量。压缩的思路就是借助大模型，根据上下文对单个文档内容进行压缩或过滤，只保留相关信息。 - **句子窗口搜索**：反过来，文档块太小又会导致上下文缺失。窗口搜索的做法是：找到匹配的文档块后，将其周围的块也一并交给大模型，增加上下文理解。 - **父文档搜索**：类似窗口搜索，但更结构化。先将文档分为较大的主文档，再切分成较短的子文档。用户问题匹配子文档后，将对应的主文档发给大模型。 - **自动合并**：比父文档搜索更复杂的方案。例如，按三层树状结构切分：顶层节点块大小1024，中间层512，底层叶子节点128。检索时只拿叶子节点匹配问题，当某个父节点下大多数叶子节点都匹配时，就将这个父节点作为结果返回。 - **混合检索**：RAG系统本质上是一个开放域的自然语言问答系统。要提高事实召回率，选择合适的检索模式或组合至关重要。最常见的是向量检索加关键词检索的组合，充分发挥不同技术的协同作用。 - **路由机制**：建立了多个针对不同数据类型和查询需求的索引后（例如一个处理摘要类问题、一个处理具体答案、一个关注时间因素），就需要用路由机制来选择最合适的索引，提升检索质量和响应速度。 - **使用Agent**：让Agent来决定采用哪种或哪些检索方法，以及它们之间是垂直关系还是平行关系。例如，查询“最新上映的科幻电影推荐”，Agent可能先路由到专门处理热点话题的索引，再结合娱乐影视内容的索引来生成推荐。 ### 检索后处理 检索后处理是对结果进行进一步加工，方便大模型生成。其中最常见的操作就是重排序（Rerank）。向量检索计算的是语义相似度，但语义最相似并不代表最相关。重排模型会考虑更多特征——查询意图、词汇多重语义、用户历史行为、上下文信息等，将最相关的文档排到最前面。实现重排除了可以提示大模型来做，更多时候是使用专门的重排模型，例如Cohere（闭源），或者BAAI、IBM发布的开源模型。 ### 生成 在生成阶段，优化更多是从用户体验出发。几点建议供参考： - **多轮对话**：带聊天历史的RAG。像Perplexity这样的AI搜索产品，支持多轮对话，用户可以深入追问。 - **增加追问机制**：在Prompt里加一句“如果无法从背景知识回答，就根据背景知识对用户追问，问题不超过三个”。这个机制没有技术门槛，主要依靠大模型的能力，但能极大改善体验。 - **Prompt优化**：RAG系统的Prompt要明确告诉模型：只基于搜索结果回答，不要添加其他信息。例如，“你是一名智能客服，目标是根据提供的上下文，在不考虑已有知识的情况下回答查询”。当然，也可以根据场景需要，适当让回答融入一些主观性。此外，使用Few-shot的方式指导模型如何利用检索到的知识，也是提升生成质量的有效方法。 - **用户反馈循环**：根据真实用户的反馈，不断更新数据库，标记哪些内容是真实的。 ### 结语 以上这些方法，都是针对基础RAG在各个环节的优化。在开发过程中，并非所有方法都适用。不同的问题有不同的解法，关键还是根据具体应用场景，选择合适的方法组合，才能将RAG的作用发挥到最大。