Loop Engineering for RAG Question Parsing: The Small Loop That Runs Before Retrieval
Loop Engineering for RAG Question Parsing: The Small Loop That Runs Before Retrieval
RAG 问题解析的循环工程：检索前运行的小循环
Large Language Model Loop Engineering for RAG Question Parsing: The Small Loop That Runs Before Retrieval Enterprise Document Intelligence [Vol.1 #6quinquies] – Prompt engineering, then context engineering, then loop engineering. On the question side, the loop is small by design: read the doc, ask what is missing, re-parse. 大语言模型 RAG 问题解析的循环工程：检索前运行的小循环。企业文档智能 [第1卷 #6quinquies] —— 从提示词工程，到上下文工程，再到循环工程。在问题处理端，这个循环被设计得很小：阅读文档，询问缺失信息，重新解析。
Kezhan Shi Jul 19, 2026 13 min read Share Photo by Ferdi Noberda, via Pexels. Kezhan Shi，2026年7月19日，阅读时长13分钟。图片来源：Ferdi Noberda (via Pexels)。
A user asks the pipeline: “what is the premium?” on a fifty-page insurance policy. The parser looks at the doc profile it just got from the parsing brick: doc_type: insurance_policy n_pages: 47 toc_df names General Information, Coverages, Exclusions, Endorsements. No section called Premium. 用户向流水线提问：“保费是多少？”（针对一份五十页的保险单）。解析器查看从解析模块获取的文档概况：文档类型：保险单；页数：47；目录名称：基本信息、承保范围、除外责任、批单。没有名为“保费”的章节。
Naive top-k embeds “premium” and scans the whole document. It returns exclusion clauses that mention the word, endorsement boilerplate, and a few incidental references. The actual premium schedule sits under General Information on page 3, but nothing in the query said so. 朴素的 top-k 检索将“保费”进行嵌入并扫描整个文档。它返回了提到该词的除外条款、批单模板以及一些偶然的引用。实际的保费明细表位于第3页的“基本信息”下，但查询中并未提及这一点。
A loop-engineered pipeline does something different. The parser sees “premium” has no match in the TOC, holds the pipeline, and sends one plain question back to the user: “I don’t see a ‘Premium’ section in this policy. Where should I look?” 经过循环工程设计的流水线则不同。解析器发现“保费”在目录中没有匹配项，于是暂停流水线，向用户发送一个简单的问题：“我在该保单中没有看到‘保费’章节。我应该去哪里查找？”
The user replies in free form. They might type “General Info” (short), “generale information” (typo), or “try under coverages” (rephrased). None of that matters. The parser re-runs on the enriched question, the LLM fits whatever came back into section_hint or another typed field, and the pipeline continues. That single turn removes the ambiguity and scopes retrieval.
用户以自由格式回复。他们可能会输入“General Info”（简写）、“generale information”（拼写错误）或“try under coverages”（改述）。这些都不重要。解析器基于丰富后的问题重新运行，大模型将返回的内容填入 section_hint 或其他类型字段中，流水线随之继续。这一轮交互消除了歧义并限定了检索范围。
The fuller mechanism (an explicit list of candidate values, a proposed default, an audit trail so the answer can be cached and applied silently next time) is what Article 6bis develops. This article stays on the smallest possible version: a question in, an answer out, one LLM pass. 更完整的机制（候选值的显式列表、建议的默认值、审计追踪以便下次静默缓存和应用答案）将在第 6bis 篇文章中展开。本文仅关注最小可行版本：输入问题，输出答案，进行一次大模型调用。
Enterprise Document Intelligence builds enterprise RAG on four bricks (document parsing, question parsing, retrieval, generation). This article re-reads brick 2 through the loop-engineering lens, the emerging discipline that names the loops built around the LLM as the place where production quality is won. 企业文档智能基于四个模块（文档解析、问题解析、检索、生成）构建企业级 RAG。本文通过循环工程的视角重新审视第 2 个模块——这是一门新兴学科，它认为围绕大模型构建的循环是决定生产质量的关键所在。
Articles 6A (thesis), 6B (extraction), and 6C (dispatch) code the brick. Article 6bis codes the clarification loop’s mechanics. This one names why that mechanic is the loop-engineering pattern applied at the smallest possible scope. 6A（论文）、6B（提取）和 6C（调度）文章对该模块进行了编码。6bis 文章对澄清循环的机制进行了编码。而本文则阐述了为什么这种机制是应用于最小范围的循环工程模式。
1. From prompt to context to loop engineering
1. 从提示词工程到上下文工程，再到循环工程
The frame has moved twice in eighteen months. 在过去十八个月里，这一框架已经发生了两次演变。
Prompt engineering (2023). The user does the work. Learn to write the right prompt, add few-shot examples, use “think step by step”. The LLM is a stateless oracle. Quality is a wording problem. 提示词工程（2023年）。 用户承担工作。学习编写正确的提示词，添加少样本示例，使用“一步步思考”。大模型是一个无状态的预言机。质量是一个措辞问题。
Context engineering (mid-2025). The engineer does the work. Tobi Lütke and Andrej Karpathy rename the practice: “the delicate art of filling the context window with just the right information for the next step.” The prompt is one slot among many. See Article 6quater (context engineering for question parsing) for that framing applied to this brick. 上下文工程（2025年中）。 工程师承担工作。Tobi Lütke 和 Andrej Karpathy 将此实践重新命名为：“在上下文窗口中填入下一步所需的最精准信息的精妙艺术。”提示词只是众多槽位中的一个。关于该框架在模块中的应用，请参阅第 6quater 篇文章（问题解析的上下文工程）。
Loop engineering (2026). The engineer designs the loops around the LLM call. LangChain puts it plainly: “the potential in agents is in the loops you build around them.” MindStudio frames it as “designing AI systems that operate in iterative cycles, repeating until a goal is met”, the discipline that “closes the feedback gap.” 循环工程（2026年）。 工程师设计围绕大模型调用的循环。LangChain 直言不讳地指出：“智能体的潜力在于你围绕它们构建的循环。”MindStudio 将其定义为“设计在迭代周期中运行、直至目标达成的 AI 系统”，这门学科旨在“弥合反馈差距”。
The three are not a race. They stack: prompt engineering shapes what one call reads, context engineering picks what enters that call, loop engineering wraps the call in a bounded iteration. 这三者并非竞争关系，而是叠加关系：提示词工程决定单次调用的读取内容，上下文工程选择进入调用的信息，循环工程则将调用包裹在有界的迭代中。
Loops come in sizes. A big loop is agentic RAG (plan, act, observe, replan, many turns). A small loop is a single ask-answer-continue turn. This article is about the smallest useful loop, sitting on question parsing. 循环有大小之分。大循环是智能体 RAG（规划、行动、观察、重规划、多轮交互）。小循环是单次的“询问-回答-继续”交互。本文讨论的是最有用的小循环，即应用于问题解析的循环。
2. The loop fills a fixed schema
2. 循环填充固定模式
Before the loop, name the fields it will fill. Question parsing writes into a fixed set of typed fields, defined once for the whole series and consumed deterministically by retrieval and generation. 在循环之前，先命名它将要填充的字段。问题解析写入一组固定的类型化字段，这些字段在整个系列中定义一次，并由检索和生成模块确定性地消费。
Vol.1 ships with these: 第 1 卷包含以下字段：
- keywords: content noun phrases for retrieval detectors. keywords（关键词）： 用于检索检测器的内容名词短语。
- intent: a bounded enum (factual, listing, section_retrieval, open_scoped, open_corpus_wide). intent（意图）： 一个有界的枚举值（事实型、列表型、章节检索型、开放范围型、全语料库型）。
- retrieval.section_hint: a section name or number to filter toc_df. retrieval.section_hint（检索章节提示）： 用于过滤目录（toc_df）的章节名称或编号。
- retrieval.layout_hint: “table”, “figure”, or “glossary” when the answer sits in a specific layout. retrieval.layout_hint（检索布局提示）： 当答案位于特定布局中时，为“表格”、“图表”或“术语表”。
- structural_hints.pages_hint: an explicit page list the user pinned in the question. structural_hints.pages_hint（结构提示页码）： 用户在问题中指定的明确页码列表。
These names are not article-local. They live in the docintel.question module and every downstream brick (retrieval detectors, dispatcher, generation schema lookup) reads them. Add a field and the whole pipeline changes. That is a design decision, not a JSON tweak.
这些名称并非仅限于本文。它们存在于 docintel.question 模块中，每个下游模块（检索检测器、调度器、生成模式查找）都会读取它们。增加一个字段意味着整个流水线都要改变。这是一个设计决策，而非简单的 JSON 修改。
The loop’s only job is to fill one of these fields when the parser cannot fill it alone. It never invents a new one. 循环的唯一任务是在解析器无法独立填充字段时，填充其中一个字段。它绝不会凭空创造新字段。