标准的检索增强生成（RAG）系统虽然功能强大，但通常只进行一次操作：检索相关文档，然后生成答案。当面对需要多步推理、整合来自不同来源的信息，或需要迭代完善才能得到满意答案的查询时，这种方法可能力有不逮。为满足这些更复杂的信息需求，多跳和迭代式RAG架构得到分析，旨在通过顺序或循环处理来分解问题和完善理解。这些高级模式在大规模分布式环境中尤为适用，因为在这些环境中，管理状态、协调复杂工作流以及优化多阶段性能是主要的工程难题。
多跳RAG：规模化分解复杂问题
多跳RAG将检索-生成过程扩展为一系列步骤。系统不是执行一次检索动作，而是进行多次检索，通常利用前一步的输出作为下一步的输入。这使得系统能够建立上下文，审视查询的不同方面，或遵循一系列推理。
多跳系统的设计
在分布式环境中有效实施多跳RAG，需要仔细考量几个架构组成部分：
-
查询分解：
最初的复杂查询必须分解成一系列更简单、可回答的子查询。
- LLM驱动的分解：大型语言模型擅长此项任务。思维链提示等技术可以引导LLM生成一系列子查询。例如，像“过去十年可再生能源的主要技术进步有哪些，它们具体如何影响太阳能电池板效率？”这样的查询，可能被分解为：
- “YYYY年至YYYY-10年间，可再生能源的主要技术进步有哪些？”
- “这些进步中哪些与太阳能电池板技术相关？”
- “【特定太阳能进步1】如何影响太阳能电池板效率？”
- “【特定太阳能进步2】如何影响太阳能电池板效率？”
- 结构化分解：对于定义明确的问题范围，基于规则的系统或预定义模板可以分解查询。这种方法提供更高的可预测性，但灵活性较低。
一个重要挑战是管理原始查询中的模糊性，因为分解过程中的误解可能导致错误在后续步骤中蔓延。
-
中间状态管理：
每一步都会生成信息：子查询、检索到的文档，以及可能的中间答案或摘要。这些状态必须得到有效管理并传递给后续步骤。在分布式系统中，这通常涉及：
- 分布式缓存或键值存储：Redis等系统可以存储中间结果，供处理不同步骤的微服务访问。
- 工作流编排负载：编排器（第5章已讨论）可以将状态作为工作流定义的一部分进行管理，在任务之间传递数据。
设计时必须考虑这些中间状态的数据大小、序列化和访问模式。
-
每跳检索与合成：
每个子查询都会触发一次检索操作。这些检索可以利用第2章讨论的分布式策略，例如分片向量搜索或混合模型，以处理庞大的数据集。
- 独立检索：每个子查询都被视为独立的搜索。
- 上下文感知检索：来自前几步的信息（例如，已识别的实体、初始文档集）可用于完善或聚焦后续步骤中的检索。例如，子查询可能专门在前一步检索到的文档集中进行搜索。
每次检索后，LLM可能会为该特定子查询合成一个中间答案或摘要，然后该摘要成为下一步的上下文的一部分。
-
最终合成：
所有步骤完成后，一个基于LLM的最终合成步骤会整合所有阶段收集的信息，为原始复杂查询生成一个全面的答案。管理此最终LLM调用的上下文长度非常重要，尤其是在收集了大量文档或中间摘要时。在最终合成前，对每一步的证据进行摘要等技术变得必要。
多跳RAG的规模伸缩性与操作考量
- 并行性：当子查询相互独立时，它们的执行（检索和中间合成）可以并行化，从而降低整体延迟。
- 延迟与成本：每一步都会增加延迟和计算成本（用于检索、LLM调用）。系统设计时必须权衡推理的深度（步骤数量）与可接受的性能和资源利用率。根据查询复杂性或可用资源动态调整步骤深度可以作为一种优化。
- 错误处理：某一步的失败可能危及整个过程。强大的错误处理、针对瞬时问题的重试机制以及潜在的备用策略（例如，如果子查询严重失败则用部分信息回答）对于系统的弹性很重要。
- 编排：复杂的多跳流程需要精密的编排，如第5章所述。Airflow或Kubeflow Pipelines等工具在定义、执行和监控这些多步骤过程中发挥作用。
图示为广义的多跳RAG过程。子查询被生成，每个子查询都会触发检索，结果会输入到最终的合成阶段。
迭代式RAG：通过循环完善答案
迭代式RAG在检索和生成过程中引入了反馈循环。系统不是采用线性的多跳路径，而是在一个或多个循环中完善其查询、检索到的上下文或生成的答案，直到获得满意结果或达到终止条件。当初始查询模糊不清，或所需答案需要逐步聚焦时，这种方法特别有用。
迭代式系统的设计
迭代式RAG架构中的重要要素包括：
-
迭代触发器：
什么促使系统启动另一个循环？
- 置信度分数：如果LLM生成器生成的答案置信度分数较低（如果模型或自定义分类器提供了此分数）。
- 歧义检测：如果系统（或辅助LLM）检测到检索到的上下文不足或冲突，或查询本身不明确。
- 自我审查：可以提示LLM根据检索到的证据批判性地审查其自身生成的答案。如果审查显示出缺陷（例如，“根据文档Y，答案未能充分回应查询的X部分”），则可以触发一次迭代。
- 用户反馈：在交互式应用中，明确的用户反馈（例如，“这不是我的意思”，“你能找到更多关于Z的信息吗？”）是直接的触发条件。
-
查询完善：
如果触发了迭代，查询本身可能需要完善。
- 基于LLM的重写：LLM可以重新措辞查询，根据之前的失败尝试添加澄清细节，或合并来自最初检索到（但可能并非完全相关）的文档中的术语。例如，如果最初查询“捷豹速度”返回的是关于动物的信息，而系统（或用户）表示对汽车感兴趣，则查询可以完善为“捷豹汽车最高速度”。
- 扩展/收缩：添加同义词、相关思路或更具体的关键词。反之，如果查询过于狭窄，则可以进行拓宽。
-
上下文完善：
检索过程本身可以调整。
- 重新排序：初始结果可以使用更复杂的模型（如第2章所述）或根据前一次迭代的反馈进行重新排序。
- 过滤器调整：如果元数据可用，可以收紧或放宽过滤器（例如，日期范围、来源类型）。
- 负面反馈：在一次迭代中被识别为不相关的文档，可以在后续检索尝试中明确排除或降低权重。
-
收敛与终止：
迭代过程需要明确的停止条件，以避免资源过度使用或无限循环。
- 最大迭代次数：对循环次数的硬性限制。
- 质量阈值：如果答案质量（通过自动化指标或用户满意度衡量）达到预设水平，则停止迭代。
- 收益递减：如果连续迭代对答案或检索到的上下文的改进微乎其微。
迭代式RAG的规模伸缩性与操作考量
- 状态管理：每次迭代都建立在前一次的基础上。管理不断演变的状态（完善的查询、累积的文档集、中间答案、反馈信号）非常重要，尤其是在分布式系统中。
- 资源消耗：每次迭代都会消耗检索和LLM调用的计算资源。设计必须权衡改进的潜力与迭代成本。
- 延迟：迭代过程本身会增加延迟。对于面向用户的应用程序，提供中间结果或进度指示符会很有用。在结果完善时流式传输部分结果是一种高级技术。
图示为迭代式RAG循环。答案被评估，从而完善查询或上下文，用于后续的检索和生成步骤，直到满足终止条件。
组合与混合方法
多跳和迭代式RAG并非相互排斥。一个系统可以结合两者：例如，多跳序列中的每个“步骤”本身就可以包含一个迭代完善过程，以确保在继续之前中间结果的质量。此类混合模型在处理异常复杂问题方面具有巨大作用，但也会使设计和操作挑战更加复杂。
规模化多步骤RAG的高级挑战
实施这些多步骤RAG模式的规模化应用引入了几个高级挑战：
- 错误传播与放大：在多跳RAG中，早期步骤中的错误或次优结果（例如，形成不佳的子查询或不相关的检索文档）会显著降低所有后续步骤和最终答案的质量。如果完善逻辑存在缺陷，迭代式RAG也可能受到影响，导致其走上无益的路径。每个组件的稳定性，以及错误检测和潜在纠正或回溯机制，都很重要。
- 延迟管理：每个步骤或迭代都会增加总处理时间。对于交互式应用，管理用户感知的延迟是主要考量。这涉及优化每个步骤：高效的分布式检索（第2章）、快速的LLM推理（第3章）和简化的状态转换。可以研究潜在后续步骤的推测性执行或并行完善路径等技术，但这会增加复杂性。
- LLM的上下文管理：随着信息在步骤或迭代中积累，馈送给LLM的总上下文（检索到的文档、中间摘要、查询历史）可能超出其上下文窗口限制。需要精巧的上下文管理策略：
- 摘要：对每个步骤/迭代的结果进行摘要。
- 选择性上下文：启发式方法或模型，用于从累积的上下文中选择最相关的信息片段进行下一次LLM调用。
- 上下文压缩：更密集地表示信息的技术。
- 计算资源分配：多步骤过程可能资源密集。检索器集群、LLM服务端点和编排工作器的动态扩展对于处理不同的负载和查询复杂性是必要的。成本优化（第5章）成为一个重要因素，特别是对于基于云的部署。
- 复杂评估：评估多跳或迭代式RAG系统的性能比单步RAG更为复杂。不仅需要最终答案质量的指标，还需要中间步骤有效性的指标（例如，查询分解的质量、每步检索的相关性、完善的有效性）。这通常需要人工评估来细致评判推理链。
- 调试与可观测性：在分布式多步骤过程中追踪信息流并识别瓶颈或故障点，需要全面的日志记录、监控和分布式追踪工具（第5章）。能够检查中间状态和决策对于调试非常有价值。
通过应对这些设计和操作考量，可以构建多跳和迭代式RAG系统，以处理数据集上的复杂推理任务，显著扩展检索增强生成在生产环境中的能力。这些架构虽然更复杂，但代表了通向更智能、更具适应性信息系统的一条道路。
