为了防止LLM在多步骤检索中偏离主题，需要实施严格的上下文管理和迭代验证。一种方法是设计流程，使每个步骤的输出都与原始查询明确相关联。例如，您可以构建提示，在每个步骤中都包含原始问题，并指示仅关注该上下文。这迫使模型将推理重新锚定到用户的意图。另一种方法是将原始查询预先分解为更小、自包含的子查询，确保每个步骤都解决问题的特定方面。例如，如果用户问“如何优化Python脚本的内存使用？”，子查询可能包括“识别内存密集型Python模式”和“在Python中分析内存的工具”。通过预定义这些步骤，您可以降低切线探索的风险。此外，可以添加中间验证检查 - 例如，使用相似性指标比较生成的查询与原始问题的相关性 - 以尽早标记和纠正偏差。
评估包括测量每个步骤的相关性和整体连贯性。一个指标是查询与原始问题的相似度：计算原始问题的嵌入与每个步骤输出的嵌入之间的余弦相似度，以量化对齐度。例如，如果一个步骤为专注于“Python内存”的问题生成有关“数据库优化”的查询，则较低的相似度得分会将其标记为离题。人工评估也很关键。注释者可以按比例（例如，1-5）对每个步骤的相关性进行评分，并跟踪系统在验证后自我纠正的频率。使用预定义场景的自动化测试可以模拟多步骤交互 - 例如，测试医疗诊断助手是否始终关注初始查询中提到的症状 - 并测量成功率。诸如精度（相关步骤的百分比）和召回率（所需子主题的覆盖率）之类的工具提供了定量基准。例如，如果检索管道中的10个步骤中有8个步骤直接解决了原始问题，则精度为80％。
一个实际的例子是处理多问题工单的技术支持聊天机器人，例如“我的应用程序在启动时崩溃，并且日志显示内存错误。” 第一步可能检索“应用程序在启动时崩溃的常见原因”，第二步可能侧重于“解释与内存相关的日志错误”，第三步可能收集“用于内存泄漏的调试工具”。每个步骤的查询都必须排除无关主题（例如，网络问题）。在评估期间，您将跟踪所有检索到的信息是否与崩溃和内存有关。如果第二步检索“网络延迟诊断”而不是内存工具，则系统将自动调整查询（通过验证）或标记以供审核。结构化提示、验证层和相关性指标的这种组合可确保 LLM 保持在轨道上，同时为开发人员提供可衡量的性能指标来改进系统。
