实用提示：第二部分——当RAG无结果返回时

可将此内容视为对“第二部分 —— 当RAG无结果时”中理念面向操作员的优化版本：清晰的阶段划分、有序的代码模块，以及能在交接过程中保留的恢复说明。

如何调试和修复AI系统中的空检索问题

将“调试方法”视为可量化的操作界面使用效果最佳。在扩大范围之前，先记录一份典型成功案例、一个故障实例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放于一个位置，以便操作员无需查看整个系统结构即可进行审核。 将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应强制要求重新编写另一项。

1. 从索引与嵌入开始

将“1. 从索引开始”阶段视为可度量的对象来处理效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。同时记录正常流程和恢复流程的文档。重试机制、人工审核环节以及死信处理都是产品本身的一部分，而非后续需要补充的内容。应将分块策略与检索策略分开，当质量指标发生变化时，修改其中一项不应强制要求重新编写另一项。

2. 检查阈值、语义评分及过滤规则

将“两个检查阈值得分”阶段视为可测量的对象来处理效果最佳。在扩大范围之前，先收集一份理想的转录结果、一个失败案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应迫使重新编写另一项。

results = vector_store.search(query_embedding, top_k=10)
for r in results:
    print(r.score, r.metadata.get('source'))

3. 查询重写与分块质量检查

将“三次检查查询重写”阶段视为可度量的工作面时，其效果最佳。在扩大范围之前，先记录一份理想结果、一个失败案例以及回滚说明。 把这一阶段视为输入与经过验证的输出之间的契约。为相关成果命名，明确成功标准，杜绝默许的半完成状态。 将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应强制要求重写另一项。

4. 采用混合检索以提高召回率

将“四阶段混合检索”视为可度量的对象时，其效果最佳。在扩大范围之前，需记录一份理想的处理结果、一个失败案例以及回滚说明。应在功能结果旁同时记录处理时间以及令牌或查询成本。提前了解成本情况，可避免在系统从演示环境过渡到共享环境时出现意外费用。应将分块策略与检索策略分开，当质量指标发生变化时，修改其中一项不应迫使重新编写另一项。将“四阶段混合检索”视为可度量的对象时，其效果最佳。在扩大范围之前，需记录一份理想的处理结果、一个失败案例以及回滚说明。需同时记录正常处理流程和故障恢复流程。重试机制、人工审核环节以及死信处理都属于产品功能的一部分，而非后续需要补充的内容。

5. 先广泛检索，再重新排序

在“5. 先广泛检索再筛选”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。相比冗长的脚本，更应采用小型且可测试的单元。当某个步骤失败时，故障原因应能指向单一责任模块，而非复杂的流程链。必须引用实际作为答案依据的段落；没有引用的话，操作人员就无法区分是虚假信息还是索引缺失所致。

6. 扩展查询范围并建立明确的备用路径

在“6 扩展查询”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 将此阶段视为输入与经过验证的输出之间的契约。为相关成果命名，定义成功判定标准，并拒绝默许的半完成状态。 需引用实际作为答案依据的段落。没有引用的话，操作人员就无法区分幻觉内容与索引缺失的问题。

docs = retrieve(query)
if not useful(docs): docs = retrieve(expand(query), hybrid=True)
if not useful(docs): return ask_for_clarification_or_no_answer()

7. 更具弹性的生产架构

在“7 A More Resilient”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 应在功能结果旁记录执行时间以及令牌或查询成本。提前显示成本可避免在流程从演示环境转向共享环境时出现意外费用。 需注明实际作为答案依据的段落。没有引用的话，操作人员就无法区分是幻觉内容还是索引缺失导致的错误。 在“7 A More Resilient”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及错误处理方式都是产品的一部分，而非后续需要补充的内容。

8. 使检索结果可观察

在完成“使检索结果可观察”这一阶段时，首先需明确相关规范：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 建议采用小型、可测试的单元而非冗长的脚本。当某一步骤失败时，故障应指向单一责任点，而非复杂的流程链。 在调整提示词之前，先使用固定的问题集来衡量检索的召回率。仅仅更换提示词很难解决检索效果不佳的问题。

log({
  'query': query, 'rewritten': rewritten_query, 'filters': filters,
  'candidate_count': len(raw_results), 'scores': scores,
  'selected_chunk_ids': selected_ids, 'fallback': fallback_stage
})

操作检查清单

在完成操作检查清单阶段时，首先需明确相关规范：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。

将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放，这样操作人员无需查看全部内容即可进行审计。

在调整提示词之前，先在固定的问题集上测试召回率。频繁更换提示词很难改善较差的检索效果。

锁定依赖项的版本，并记录用于演示的图像摘要。可重复性比经验知识更为重要。

同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及错误处理都是产品的一部分，而非后续需要补充的内容。

在调整提示词之前，先在固定的问题集上测试召回率。频繁更换提示词很难改善较差的检索效果。

在推广该技术栈之前，应先冻结版本，为关键路径生成标准记录，并确认回滚步骤。共享环境需要设置速率限制、租户检查机制，以及明确的密钥轮换负责人。与其展示花哨的一次性演示，不如注重扎实的可靠性。

关于429668e62b58的批量处理说明：请将提供商密钥存放在仓库之外，设定单会话令牌上限，并将记录与评估用文件放在一起，以便后续模型更换时保持可比性。

针对强化安全性的第0阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。配置文件应与应用程序代码分开存放，环境文件、密钥存储及功能开关应集中于一个位置，以便操作人员无需查看整个系统结构即可进行审计。

强化细节 0/735：测量该代码段的运行时间、错误类型以及代币消耗情况，然后依据固定的问题清单而非个人经验来判断是否保留该修改。

在处理强化建议的第一阶段时，首先写下合约的必要输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改更加规范。优先选择小型且可测试的单元，而非庞大的脚本；当某个步骤失败时，故障应能指向具体的责任模块，而非复杂的流程链。

强化细节 1/735：测量该代码段的运行时间、错误类型以及代币消耗情况，然后依据固定的问题清单而非个人经验来判断是否保留该修改。

将强化措施的第2阶段视为可测量的表面时效果最佳。在扩大范围之前，先记录一份理想的测试结果、一个故障案例以及回滚说明。在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。

强化措施细节2/735：为该措施测量实际耗时、错误类型以及令牌使用量，然后依据固定的问题集而非个人经验来判断是否保留该变更。