把RAG和推理割裂开，是当前大量企业知识库项目效果不佳的根本原因。传统做法是先检索Top-K文档，一股脑塞进提示词，然后指望大模型自己消化。这种一次性的检索模式在面对多跳问题、需要证据链的问题时几乎必然失败。检索增强推理的核心思想是：让检索成为推理循环中的一个可调用动作，模型在思考过程中主动决定查什么、查几次、什么时候停。本文围绕这一思路，给出一套可以直接落地到生产环境的完整方案。
为什么传统RAG撑不起复杂推理任务
先看传统RAG的典型流程：用户提问后，系统把问题向量化，去向量库里召回Top-K条相似文档，拼接后交给大模型生成答案。这个流程在事实型问答上表现尚可，比如“公司的年假有几天”，一条文档就能回答。但一旦问题变成“对比A产品和B产品在近三年的售后政策差异，并给出采购建议”，问题就暴露了。
第一个问题是检索与推理的粒度不匹配。复杂问题往往需要拆解成多个子问题，每个子问题对应不同的检索需求，而一次性检索只能覆盖问题表面的语义，无法命中子问题需要的证据。第二个问题是证据噪声干扰推理。Top-K召回里混入了不相关文档后，模型的注意力被稀释，反而更容易产生幻觉。第三个问题是缺乏证据校验机制，模型把检索内容和自己的参数知识混在一起输出，用户根本无法分辨哪句话来自文档、哪句话是模型编的。
曾有团队做过测试，同一个多跳问答数据集上，一次性检索RAG的准确率只有47%，而引入迭代检索与推理链后准确率提升到了78%。差距主要来自中间环节：模型在第一跳检索后能发现信息不足，主动生成第二跳查询。这个“发现不足”的能力，正是检索增强推理要解决的核心问题。
检索增强推理的整体架构设计
生产级的检索增强推理系统，建议采用“规划-检索-推理-校验”的四层循环架构。每一层职责明确，通过一个中央调度器协调，调度器本质上是一个带工具调用能力的大模型。
规划层负责把用户问题拆解为可执行的子任务列表。比如问题“我们公司去年在华东区的销售额比前年增长了多少”，会被拆成三个子任务：查去年华东区销售额、查前年华东区销售额、计算增长率。拆解本身也由模型完成，但需要用结构化输出约束格式，避免拆解结果不可解析。
from pydantic import BaseModel
from typing import Optional
class SubTask(BaseModel):
task_id: int
question: str # 子问题文本
depends_on: list[int] # 依赖的前置任务ID
retrieval_query: str # 用于检索的查询语句
done: bool = False
answer: Optional[str] = None
class Plan(BaseModel):
goal: str
tasks: list[SubTask]
# 用结构化输出约束规划结果
plan = llm.create_chat_completion(
messages=[
{"role": "system", "content": "你是任务规划器，把用户问题拆解为有序子任务"},
{"role": "user", "content": user_question}
],
response_format=Plan
)检索层不再是一次性调用，而是接收调度器下发的查询语句，执行“改写-召回-重排-截断”四步。查询改写很关键，子任务的表述往往不适合直接检索，需要改写成陈述式的检索友好语句。重排建议使用交叉编码器，虽然延迟比向量召回高一个量级，但相关性精度提升明显，生产上可以对召回量做限制来控制耗时。
推理层负责根据已有证据判断下一步动作：信息足够就总结答案，不够就发起新一轮检索，证据冲突就标记待澄清。校验层做最后一道把关，检查答案中的每个关键论断是否有检索证据支撑，没有支撑的部分要么删除，要么明确标注为模型的推测。
核心环节的工程实现细节
迭代检索的终止条件
迭代检索最大的坑是无限循环：模型觉得信息永远不够，反复发起检索，延迟和成本双双爆炸。必须设置硬性熔断条件，实践中常用的组合是：最大迭代次数不超过4次、每轮检索的证据置信度阈值递增、连续两轮新增证据量低于阈值即终止。终止后无论证据是否完整，都进入答案生成阶段，证据不足的部分如实告知用户。
MAX_ROUNDS = 4
CONFIDENCE_STEP = 0.1
EVIDENCE_DELTA_THRESHOLD = 2
def should_continue(round_id: int, base_confidence: float,
new_evidence_count: int, last_count: int) -> bool:
if round_id >= MAX_ROUNDS:
return False
threshold = base_confidence + CONFIDENCE_STEP * round_id
if current_confidence < threshold:
pass # 置信度不足，可能需要继续
if new_evidence_count < EVIDENCE_DELTA_THRESHOLD and round_id > 1:
return False # 新增证据太少，继续检索收益有限
return current_confidence < threshold证据校验与引用溯源
校验环节推荐用句子级别的证据对齐。生成答案时要求模型对每个论断标注证据来源ID，校验器再逐条检查该证据是否真的包含对应内容。实现上可以用一个轻量模型做蕴含判断，判断证据文本是否支持论断。支持率低于设定阈值（建议0.8）的答案会被打回重新生成。这个机制看似增加成本，但能显著降低幻觉率，对生产系统的可信度至关重要。
缓存与降级策略
生产环境必须考虑三个兜底。一是语义缓存：对相似问题的中间检索结果做缓存，命中率高的知识库场景能节省40%以上的检索开销。二是降级链路：当推理模型超时或出错，自动降级为一次性检索加直答模式，牺牲质量保住可用性。三是流式输出：迭代过程对用户是黑盒，长时间无响应体验极差，建议把每个推理步骤的摘要以流式方式推给前端，让用户感知到系统在工作。
评测指标与上线迭代
检索增强推理系统的评测不能只看最终答案的对错，需要分层看指标。检索层看召回率和重排后的精确率；推理层看子任务拆解的正确率和迭代次数分布；生成层看答案忠实度（答案是否被证据支持）与引用准确率。忠实度是最关键的指标，一个答案宁可说“知识库中没有相关信息”，也不能编造。
评测集的构建建议从线上真实问题采样，人工标注理想证据链，这样能同时考核检索和推理两个环节。上线后建立badcase回流机制，每周把失败案例归类分析，常见问题类别包括：查询改写质量差导致检索偏航、文档分块策略不当切断上下文、迭代熔断条件过紧导致证据不足。
最后谈一下成本。迭代检索意味着多次调用大模型，单次问答的token消耗可能是一次性RAG的三到五倍。控成本的常用手段包括：规划和小模型能胜任的环节用小参数模型、中间步骤只保留结构化结果不传完整历史、对高频问题建立答案级缓存。把这套组合拳打下来，检索增强推理完全可以在可接受的成本内稳定运行，真正发挥出大模型加外部知识的组合威力。