给 RAG 装上判断何时停检索的 Dispatcher 调度器

很多 RAG 实现只把检索到的内容塞给模型，跑起来最让人头疼的却是模型陷入死循环，或者在信息还没凑齐时就匆忙给出错误答案。把 RAG 从简单的线性流改成循环流（Loop Engineering），关键就在于引入一个类似 Dispatcher 的调度机制，实时判断当前检索结果能不能回答问题。

调度器若判定信息不足，就重写查询词回溯检索；若发现已进入重复循环，就强制跳出。这其实是 Agentic RAG 的雏形，光靠 Prompt 里那句“请仔细检查”不行，得在工作流层面把逻辑写死。

循环流的核心逻辑落在调度函数上，通过设定 max_loops 上限来约束检索轮次。每一轮循环先评估当前上下文是否足以支撑回答，若判定为 SUFFICIENT（足够），直接生成最终答案；若判定为 NEED_MORE_INFO（信息不足），则基于已有上下文重写查询词，再检索补充文档，并递增循环计数；当判定为无法回答或已陷入循环时，返回兜底提示。若循环次数用尽仍未满足条件，则强制返回当前上下文对应的答案。

def rag_dispatcher(query, context, max_loops=3):
    loop_count = 0
    while loop_count < max_loops:
        # 评估当前上下文是否足以回答问题
        decision = evaluate_sufficiency(query, context)
        
        if decision == "SUFFICIENT":
            return generate_final_answer(query, context)
        elif decision == "NEED_MORE_INFO":
            # 重新生成检索词并更新 context
            new_query = rewrite_query(query, context)
            context += retrieve_documents(new_query)
            loop_count += 1
        else:
            # 判定为无法回答或陷入死循环
            return "无法从现有文档中找到准确答案"
            
    return generate_final_answer(query, context)

实操中最容易踩坑的就是 evaluate_sufficiency 这个判定环节。阈值设太高，模型会不停检索直到撞上 max_loops 上限，响应延迟飙高；设太低，又会产生幻觉。

部署这种循环工作流时，建议重点优化几个维度：

• 判定状态机： 明确定义 SUFFICIENT（足够）、INSUFFICIENT（不足）、IRRELEVANT（无关）三种状态，别只用简单的 Yes/No。
• 查询重写机制： 每轮 Loop 后必须对 query 做语义漂移修正，否则检索回来的永远是同一批文档。
• Token 成本控制： 循环次数越多，上下文窗口堆积越快，每轮循环后得对 context 做精简或摘要处理。

这种架构虽然增加了复杂度，但比单次检索的 RAG 稳健得多，尤其在处理复杂多跳问题时。