12.3.4 什么情况下值得引入“检索结果自检”机制？

先给结论：当你无法容忍检索质量波动，或错误成本高到必须可控时，就应该引入自检。自检不是“多问一次”，而是“把检索质量判断变成流程节点”。

值得引入自检的典型信号

只要出现其中两类，你就应该认真考虑引入自检：

• 同类问题时好时坏，质量波动明显
• 检索结果看似相关，但答案经常缺关键条件
• 证据之间出现冲突，模型难以自洽
• 业务对错误极其敏感（合规、财务、医疗等）

自检机制的四类常见目标

自检并不是一个动作，而是四类判断：

1. 相关性自检：检索结果是否真正回答问题
2. 覆盖度自检：关键条件是否被覆盖
3. 一致性自检：证据之间是否冲突
4. 可用性自检：证据是否可以支持生成

只做“相关性”往往不够，覆盖度和一致性才是稳定质量的关键。

一个可落地的自检流程

最小可用流程可以这样拆：

1. 检索候选
2. 自检评分（相关性、覆盖度、支持性）
3. 触发动作：改写查询、扩展检索或切换检索器
4. 再次自检
5. 生成（或拒答）

示意代码（伪代码）：

def verify_retrieval(query, candidates):
    rel = judge_relevance(query, candidates)
    cov = judge_coverage(query, candidates)
    sup = judge_support(query, candidates)
    return 0.4 * rel + 0.3 * cov + 0.3 * sup

def retrieval_with_self_check(query):
    candidates = retrieve(query)
    score = verify_retrieval(query, candidates)
    if score < 0.6:
        candidates = retrieve(rewrite_query(query))
    return candidates

重点不在分数公式，而在“有分数就能触发纠错”。

自检落地时的三个关键细节

1. 让自检可被度量

要避免“主观评估”，你需要让自检结果可度量：

• 定义评分或标签（相关/不相关、足够/不足）
• 记录阈值与触发次数
• 对触发后的结果进行对比分析

2. 给出明确的纠错动作

自检不是结论，而是触发器。你必须指定：

• 低相关 -> 改写查询或换检索器
• 低覆盖 -> 扩大召回或补充检索源
• 低支持 -> 进入二次检索或拒答

3. 控制开销

自检会引入额外成本，需要提前设置：

• 最大重检次数
• 自检的上限深度
• 低价值问题的跳过策略

自检机制不是万能药

自检解决的是“检索质量波动”，不是“知识不存在”。如果数据源缺失，自检只会让系统更快地意识到“没有证据”。

自检清单

• 是否定义了可度量的自检指标？
• 是否为每种自检失败准备了具体纠错动作？
• 是否设置了成本与次数上限？

一句话总结

当检索质量波动影响业务时，自检是最直接的稳定机制。它不需要重建系统，但必须有明确的指标与纠错动作。