当查询需要收集上下文、迭代优化或跨多个数据源进行推理时，单步检索策略就会失败。例如，如果用户问：“如何修复因内存泄漏导致的服务器崩溃？”单步方法可能会检索一篇关于服务器崩溃的通用文章，但会忽略与内存管理的特定关联。而多步策略会首先识别崩溃类型，然后交叉引用日志以检测内存问题，最后检索针对特定原因的缓解步骤。单步方法难以处理歧义、多跳依赖关系，或者初始结果表明需要更深入探索的场景。
这些失败通常发生在三种场景中：需要澄清的模糊查询、需要逐步分析的复杂问题，或依赖于综合来自不相关系统的信息的任务。例如，开发者问：“我的 API 为什么这么慢？”如果系统没有首先检查指标（如响应时间），将其与最近的代码变更关联起来，然后再查询文档以寻找潜在的瓶颈，那么可能会得到不相关的结果。检测这些情况涉及分析检索输出中的差距——例如缺少关键上下文、提供肤浅的答案或未能连接相关概念。查询日志、用户反馈或 A/B 测试等工具可以揭示用户重新提问或在初始结果后放弃任务的模式，这表明需要采用多步方法。
为了创建基准，定义单步检索明显遗漏了连锁检索能够捕获的关键信息的测试用例。例如
- 多跳问题：“使用 Node.js 的 Azure Functions 的推荐身份验证方法是什么？”首先需要检索 Azure Functions 文档，然后交叉引用 Node.js SDK 的具体信息。
- 模糊故障排除：“添加图表库后，我的应用 UI 冻结了”需要检查错误日志、库文档和线程并发模式。
- 依赖上下文的任务：“将 PostgreSQL 数据迁移到 BigQuery”需要顺序步骤：模式映射、导出工具和转换规则。衡量成功的标准是策略是否能呈现所有必要的组件及其关系。自动化测试可以标记单步结果缺乏特异性或关联性的场景，为多步改进提供明确的验证标准。
