重排与查询转换

尽管选择和优化向量 (vector)存储与索引策略是生产级 RAG 的主要考量，但要获得高质量结果，通常需要改进 搜索内容 和 检索结果的排序方式。纯粹基于向量相似度的初步检索，虽然高效，但可能无法完全捕捉用户意图或呈现从候选集中最相关的信息。本文将剖析通过查询转换和结果重排来提升检索关联性的方法。

改进搜索：查询转换

用户查询可能模糊、过于简洁或缺乏足够背景，不利于有效的语义搜索。查询转换方法旨在将原始用户查询调整为一个或多个优化查询，这些查询更有可能从向量 (vector)存储中产生相关文档。

查询扩展

最简单的形式是使用相关术语或理念（通常借助 LLM）来扩展查询。目的是稍微扩大搜索范围，以找到可能使用不同术语表达相同理念的文档。

例如，用户查询“RAG 性能问题”可以由 LLM 扩展为包含“检索增强生成 (RAG)延迟”、“向量搜索优化”、“RAG 吞吐量 (throughput)瓶颈”或“索引效率”等术语。

• 实现方式： 这通常涉及在检索步骤之前进行初步的 LLM 调用。LangChain 的 MultiQueryRetriever 是一个标准实现，它自动化此过程，生成查询的多个变体以扩大搜索范围。
• 注意事项： 尽管可能有效，但过度激进的扩展可能导致主题漂移，即扩展后的查询检索到不相关的文档。需要谨慎的提示工程 (prompt engineering)，并可能限制扩展的范围。

查询分解

复杂的用户问题通常包含多个子问题。尝试通过一次检索来回答它们可能效率不高。查询分解将一个复杂查询分解成几个更简单、独立的子查询。每个子查询针对检索器执行，然后对结果进行综合（通常通过最终的 LLM 调用）以生成全面的回答。

考虑查询：“LangChain 中上下文 (context)窗口管理策略和持久化内存存储有何区别？”

这可以分解为：

1. “LangChain 中有哪些上下文窗口管理策略？”
2. “LangChain 中有哪些持久化内存存储？”
3. “LangChain 中的上下文窗口管理和持久化内存有何不同？”

• 实现方式： 需要进行初步的 LLM 调用以执行分解，随后为每个子查询进行并行或顺序检索，以及一个最后的综合步骤。此逻辑通常通过自定义链或代理工作流来实现，它们将复杂查询解析成独立的问句列表。
• 注意事项： 由于有多个检索步骤和 LLM 调用，增加了操作的复杂性和延迟。它对于真正的多方面问题最有效。

文档嵌入 (embedding) (HyDE)

HyDE 采用不同方法。它不修改查询文本，而是使用 LLM 生成一个能完美回应用户查询的文档或回答。该文档随后被嵌入，其嵌入被用于搜索向量存储。假设是，一个完美回答的嵌入将在向量空间中更接近相关文档的嵌入。

• 实现方式： 包含一个 LLM 调用来生成文档，该文档的嵌入步骤，然后使用生成的嵌入进行标准向量检索。
• 注意事项： 可能非常有效，特别是对于需要细致理解的查询。质量很大程度上取决于 LLM 生成相关且结构良好回应的能力。它在检索前增加了 LLM 调用和嵌入步骤。

提高关联性：重排检索结果

初步检索方法，如向量 (vector)相似度搜索，针对大规模语料库的速度和召回率进行了优化。它们通常返回 k 个候选文档（例如，前 20 个）。然而，与查询最相关的文档可能分散在此初步集合中，不一定排在最前面。重排引入了第二个计算密集度更高的阶段，以基于更细致的关联性评估来重新排列这些初步候选文档。

修改后的 RAG 流程，包含了可选的查询转换以及初步检索后的强制重排阶段。

交叉编码器模型

不同于初步检索中使用的双编码器（它们独立嵌入 (embedding)查询和文档），交叉编码器将查询和候选文档 一起 作为单个输入处理。这使得模型能够直接比较查询和文档文本，从而得到更准确的关联性评分。

• 工作原理： 预训练 (pre-training)的交叉编码器模型以 (查询, 文档文本) 作为输入，并输出一个表示关联性的分数（例如，0 到 1 之间）。您为初步检索到的每个 top-k 候选文档运行此评分过程。
• 模型： 示例包括在 MS MARCO 等关联性数据集上微调 (fine-tuning)的模型（例如，cross-encoder/ms-marco-MiniLM-L-6-v2）或现代先进选项，如 BAAI/bge-reranker。像 Cohere Rerank 这样的托管 API 也可作为强大的远程交叉编码器使用，在无需本地基础设施管理的情况下提供高性能。
• 实现方式： 遍历初步的 k 个文档，将每个 (查询, 文档) 对传递给模型，并根据输出分数进行排序。LangChain 的 ContextualCompressionRetriever 支持本地 Hugging Face 嵌入和基于 API 的集成，如 CohereRerank。
• 注意事项： 交叉编码器比双编码器显著更慢，因为它们必须单独处理每个查询-文档对。这种延迟影响意味着它们通常只应用于少量初步候选文档（例如，前 10-50 个）。

基于 LLM 的重排

您可以使用强大的 LLM 本身来执行重排。这包含使用原始查询和每个候选文档的内容（或相关片段）提示 LLM，并要求它评估关联性，或许通过分配分数或分类判断（例如，“高度相关”、“有点相关”、“不相关”）。

• 实现方式： 流程与交叉编码器类似，但不是调用专门模型，您为每个候选文档进行 LLM API 调用。细致的提示设计对于获得一致且可靠的关联性判断很重要。
• 注意事项： 可以获得非常高的关联性准确度，可能捕捉到较小模型遗漏的难以察觉的细节。然而，由于有多个 LLM 调用，这通常是最昂贵、延迟最高的重排选项。指导 LLM 同时对一批文档进行排序等方法可以缓解这种情况，但可能影响准确度。

纳入其他信号

重排不限于语义关联 (semantic relationship)性。您可以将交叉编码器或 LLM 的语义分数与其他信号结合起来：

• 文档时效性： 优先考虑最近更新的文档。
• 来源权威性： 提升来自可信或权威来源的文档。
• 用户反馈： 如果可用，纳入显式（点赞/点踩）或隐式（点击率）反馈。
• 多样性： 对与已选 top 文档语义过于相似的文档进行降权，以避免冗余。

最终排名可以通过这些分数的加权组合来确定。公式可能很简单，例如 $\text{最终分数} = w_1 \times \text{语义分数} + w_2 \times \text{时效性分数} + ...$，或者涉及一个更复杂的学习排序 (LTR) 模型，该模型根据您的具体数据和关联性标准进行训练。

结合转换与重排

查询转换和重排是互补的。转换查询有助于提高快速双编码器检索到的初步候选集的 质量。重排随后细致地排序这个改进的候选集，将最匹配的结果排到最前面。同时使用这两种方法可以带来显著改进，提高 LLM 生成时提供的最终背景信息。

生产环境实用建议

• 延迟预算： 查询转换（特别是使用 LLM）和重排都会增加延迟。仔细分析您的流程。仅对前 N 个（例如 10-20 个）候选文档应用重排是平衡准确度和速度的常见策略。如果延迟很要紧，可以考虑使用更小、更快的交叉编码器模型。
• 成本： 用于转换或重排的 LLM 调用会增加运营成本。追踪 token 使用量，如果成本变得过高，可以研究更小的模型或采样策略。
• 评估： 实施这些方法需要细致的评估。不仅要衡量重排后的检索指标（如 NDCG@k、Hit Rate@k），还要衡量生成答案的端到端质量。使用评估集并可能进行 A/B 测试以确认这些新增的操作确实改进了用户体验或应用性能。

通过策略性地应用查询转换和重排，您可以显著提升 RAG 系统的关联性和准确性，从基本的语义相似性转向为 LLM 提供更准确、更符合语境的信息。