用户向流水线提出问题：“保费是多少？”，提问对象是一份50页的保险保单。问题解析模块首先读取文档解析单元输出的文档特征信息：

文档类型：保险保单

总页数：47页

目录包含模块：基本信息、保障范围、免责条款、附加条款，无「保费」相关章节。

传统朴素的Top-K嵌入检索会对「保费」一词做全局匹配，遍历整篇文档，最终匹配到提及该词汇的免责条款、附加条款模板文本及少量零散无关内容。而真正的保费明细位于文档第3页的「基本信息」板块，但用户的提问中未给出任何相关定位线索。

经过循环工程优化的流水线则采用完全不同的处理逻辑：解析模块检测到目录中无「保费」对应章节后，暂停流水线运行，向用户发起一次简洁的澄清提问：

「未在本保单中检索到『保费』相关章节，请问需要定位至哪个板块查询？」

用户可自由输入回复内容，可能是简写的「基本信息」、存在拼写错误的「基础资讯」，或是改写后的「试试保障范围板块」。无论输入格式是否规范、是否存在误差，解析模块均可兼容适配。大模型会基于用户回复重新解析问题，将有效信息填充至「章节提示」等结构化字段，随后流水线恢复正常运行。

仅此一轮人机澄清闭环，即可消除提问歧义，精准锁定检索范围。

完整的机制（候选值枚举、默认推荐策略、可缓存复用的审计日志，实现后续静默复用）将在第6bis篇文章中详细阐述。本文聚焦最简核心版本：单次提问、单次应答、仅一次大模型调用。

企业文档智能体系的企业级RAG架构，依托四大核心单元搭建：文档解析、问题解析、检索、生成。本文从循环工程的全新视角，重新拆解第二大核心单元（问题解析）。循环工程是当下新兴的技术范式，核心逻辑为：围绕大模型构建可控循环机制，以此打造生产级高质量RAG系统。

系列第6A、6B、6C篇文章已完整实现问题解析单元的核心原理、信息提取规则与任务分发逻辑，第6bis篇文章详解澄清闭环的运行机制，本文则重点阐释：为何这套轻量化澄清机制，是问题解析场景下最具落地价值的循环工程范式。

📓 本文第三章的三类实战案例均已开源至配套代码仓库，可直接运行复现：基于arXiv论文数据集、经纪合同文档实测澄清闭环效果，直观观察大模型如何根据文档特征动态识别信息缺失项。仓库地址：doc-intel/notebooks-vol1

一、从提示工程、上下文工程到循环工程

过去18个月，AI工程的核心技术范式历经两次迭代升级：

1. 提示工程（2023年）：核心工作由用户完成。用户通过优化提示词、添加少样本示例、设置分步推理指令提升模型效果，大模型为无状态的应答工具，输出质量完全依赖文本措辞优化。

2. 上下文工程（2025年中）：核心工作由工程师完成。Tobi Lütke与Andrej Karpathy对其定义：「为模型每一轮调用，精准填充最优上下文信息的精细化工程方法」。提示词仅为模型输入的一部分，不再是优化核心。系列第6quarter篇文章已基于该范式，完成问题解析单元的上下文工程优化。

3. 循环工程（2026年）：核心工作由工程师设计模型外围闭环链路。LangChain对此有精准定义：「智能体的核心潜力，源于围绕大模型构建的迭代循环机制」。MindStudio将其定义为：「设计迭代式运行的AI系统，持续迭代直至达成目标」，核心价值是补齐AI系统的反馈闭环缺口。

三大范式并非迭代替代关系，而是层层叠加、相辅相成：提示工程定义单轮模型调用的输入逻辑，上下文工程筛选进入模型的有效信息，循环工程为模型调用封装可控的迭代闭环。

循环机制分为大小两种形态：大型循环为智能体RAG，包含规划、执行、观测、重规划的多轮迭代流程；小型循环为单次问答澄清、单次流程修正的极简闭环。本文聚焦问题解析场景下的最小有效闭环。

二、闭环机制：基于固定结构化字段补全信息缺口

所有闭环迭代的核心目标，都是补全预设的固定结构化字段，字段规则在本系列中统一约定，检索、生成等下游单元均严格按照字段内容确定性执行。第一卷体系预设核心字段如下：

• 关键词（keywords）：用于检索匹配的核心名词短语

• 意图（intent）：有限枚举类型（事实查询、列表提取、章节检索、开放范围查询、全文档检索）

• 检索-章节提示（retrieval.section_hint）：用于筛选文档目录的章节名称/编号

• 检索-布局提示（retrieval.layout_hint）：当答案固定存在于特定布局时生效，可选值：表格、图片、术语表

• 结构提示-页面提示（structural_hints.pages_hint）：用户明确指定的检索页面范围

• 表单/幻灯片专属提示字段（适配第二卷格式，本文未启用）

上述字段为体系级固定配置，统一封装在docintel.question模块中，检索检测器、任务分发器、生成范式匹配等所有下游模块均统一读取。新增字段会触发全流水线适配调整，并非简单的JSON参数修改，属于核心架构级设计决策。

轻量化闭环的唯一职责：当问题解析模块无法独立填充某一核心字段时，通过人机澄清补全缺口，绝不自定义新增字段。

完整运行流程分为六步，仅第三步至第四步支持闭环回滚迭代：

以开篇的保费查询问题为例，核心代码运行逻辑如下：

# 1-2. 基于原始问题+文档上下文完成首次解析
parsed = parse_question(
    raw="what is the premium?",
    doc_context=doc_context,  # 传入文档类型、目录数据等全局特征
)

# 首次解析结果：核心字段填充状态
assert parsed.keywords == ["premium"]
assert parsed.intent == "factual"
assert parsed.retrieval.section_hint is None   # 核心缺失字段：章节提示为空
assert parsed.structural_hints is None

# 3. 检测字段缺失，触发闭环澄清机制
if parsed.retrieval.section_hint is None and _topic_looks_sectioned(parsed, doc_context):
    # 生成面向用户的澄清提问
    question_to_user = (
        f"I don't see a '{parsed.keywords[0].title()}' section in this policy. "
        "Where should I look?"
    )
    user_reply = ask_user(question_to_user)   # 人机交互，获取用户自由格式回复

    # 4-5. 基于用户补充信息重新解析问题
    parsed = parse_question(
        raw=f"{parsed.original_question} (look under {user_reply})",
        doc_context=doc_context,
    )

# 迭代完成：章节提示字段已补全，流水线正常分发执行
plan = dispatch(parsed)                       # 第六步：下游流程无感知正常运行

两次问题解析调用的核心特点：仅补全缺失字段，其余所有结构化字段完全保留首次解析结果。最终的任务分发逻辑与无闭环的常规流水线完全一致，下游模块无感知、零改动。

并非所有字段都为必填项：若文档无有效目录、章节提示天然缺失，只要页面提示等其他字段可以锁定检索范围，流水线即可正常运行。循环工程的核心设计难点在于：结合文档特征精准判断需要澄清的目标字段，并生成适配用户认知的简洁提问。

含候选值枚举、默认推荐、缓存复用的增强版闭环机制，详见第6bis篇文章。

三、三类实战场景：针对不同缺失字段的闭环适配方案

以下三类典型场景，分别对应问题解析模块无法独立填充的核心字段、触发闭环的文档特征、标准化澄清提问。所有场景均复用同一套结构化字段体系，无自定义新增逻辑。

3.1 场景一：章节提示缺失——检索主题未匹配文档目录

保险分析师首次查看一份47页的保单文档，文档目录仅包含四大基础板块，无任何保费相关标识。分析师提出问题：「第一季度的保费是多少？」

解析模块结合文档特征完成首次解析：

关键词：["premium（保费）"]

查询意图：事实查询（仅需单一数值答案，非列表、非综述）

核心缺口：检索章节提示字段为空，无匹配目录板块

流水线不会将字段残缺的解析结果传入下游检索模块，而是主动暂停流程、发起澄清提问：

「未在本保单中检索到『保费』相关章节，请问需要定位至哪个板块查询？」

用户可自由输入「基本信息」「基础板块」「常规信息」等任意表述，无需严格匹配标准章节名。大模型会统一归一化解析为标准章节名称，填充至章节提示字段，其余所有解析字段保持不变。

至此流水线恢复确定性运行：下游检索模块仅遍历目录中「基本信息」对应的第3页内容，过滤全文冗余噪声，模型仅基于干净的上下文生成答案，分析师秒级获取精准保费数据。

3.2 场景二：页面提示缺失——检索主题分布多位置

法务人员需要快速归档一份47页的合同文档，向流水线提问：「客户名称是什么？」

文档特征显示为标准合同，目录仅标注条款编号，无「合同主体」等明确板块名称。首次解析结果：

关键词：["client name（客户名称）"]

查询意图：事实查询

核心缺口：结构化页面提示字段为空

该场景存在典型检索陷阱：合同的客户名称通常分布在三个固定位置——封面页、每页页眉、文末签署栏。若直接放行无页面定位的检索请求，流水线会全局扫描全文，匹配大量正文内零散的「客户」指代文本，信噪比大幅降低，最终导致答案失真。

解析模块触发闭环，针对性提问：

「合同的客户名称通常位于封面、页眉或签署栏，请问需要检索哪个位置？」

用户回复「封面」「第一页」「首页位置」等任意内容，模型均可归一化为页面提示：[1]。关键词、查询意图等核心字段不变，下游检索模块仅扫描第1页内容，基于纯净上下文生成精准答案。

3.3 场景三：页面提示缺失——长文档目录解析失效

研究员针对一份32页的内部风险报告提问：「总结风险相关章节内容」

文档特征显示为研究报告，解析模块因文档层级嵌套混乱、编号不统一等问题，未能提取有效目录，目录数据完全为空，章节提示字段彻底无法生效。

此时闭环机制聚焦可补全的核心字段——页面提示，向用户澄清：

「本文档未解析出有效目录，请问风险相关内容大致分布在哪些页面？」

用户回复分为两种情况，流水线自适应兜底：

1. 「不清楚」：页面提示保持为空，流水线降级为全文档扫描检索，保证结果完整，同时告知用户检索开销；

2. 「文档中部」：模型归一化为页面范围[11,12...22]，激活页面提示检索策略，检索范围缩减为原文档的1/3，推理速度大幅提升、模型调用成本降低2/3。

三类场景的核心共性：所有闭环迭代均基于预设的固定结构化字段，仅根据文档特征动态选择需补全的缺口字段，下游调度、检索、生成逻辑零改动、零适配成本。

四、闭环机制的定位：区别于智能体RAG的轻量化设计

该澄清闭环完全内嵌于问题解析单元内部，对下游检索、生成模块完全透明：下游仅能接收字段完整、置信度达标的标准化解析结果，无法感知上游是否经过人机澄清迭代。

这也是该轻量化闭环看似类似智能体迭代、但本质完全不同的核心原因：

• 单次迭代，无多轮循环：仅执行一次人机澄清、一次重新解析，无持续规划、复盘、自我迭代的复杂逻辑

• 工程预设逻辑，非模型自主规划：候选匹配规则、目标补全字段、降级兜底策略均为代码预设，大模型仅负责生成用户提问、归一化用户回复，无自主决策权限

• 基于真实文档状态触发，无开放式臆断：闭环触发条件明确且可量化（主题无目录匹配、主题多位置分布、目录解析失效），属于落地态自我修正，完全依托真实执行数据，而非模型主观思辨

• 延迟可控，边界固定：区别于多轮智能体的无固定耗时，该闭环仅增加一次人机交互、一次模型调用，流程可控、延迟可预期

行业主流循环工程认知多聚焦于复杂多轮智能体闭环，而单文档RAG流水线的核心落地价值，恰恰源于这类极简、可控、高性价比的轻量化闭环。

五、本文覆盖范围说明（边界界定）

本文刻意规避三类非相关闭环场景，明确技术边界：

• 不覆盖多轮智能体闭环：流水线自主规划、多轮重规划的复杂智能体逻辑，属于第四卷「工具型智能体单元」的研究范畴

• 不覆盖生成后校验闭环：答案生成后的自我校验、修正迭代逻辑（第8C篇文章的范式校验重试机制），属于下游生成单元的闭环体系，技术载体与应用场景完全不同

• 不覆盖跨文档检索闭环：多文档场景下的文档筛选、范围界定闭环，属于第二卷「语料上下文」的研究范畴

以上各类闭环均遵循统一的循环工程技术体系，但适配场景、技术层级、服务模块完全不同，需独立拆分设计。

推荐学习书籍 《CDA一级教材》适合CDA一级考生备考，也适合业务及数据分析岗位的从业者提升自我。完整电子版已上线CDA网校，累计已有10万+在读~ !

免费加入阅读：https://edu.cda.cn/goods/show/3151?targetId=5147&preview=0