RAG Workflow and Loop Engineering: The Dispatcher That Decides When to Loop and When to Stop
RAG Workflow and Loop Engineering: The Dispatcher That Decides When to Loop and When to Stop
Large Language Model RAG Workflow and Loop Engineering: The Dispatcher That Decides When to Loop and When to Stop 大型语言模型 RAG 工作流与循环工程：决定何时循环、何时停止的调度器
Enterprise Document Intelligence [Vol.1 #13] – Putting the patterns together, and why this is what “agentic RAG” should look like 企业文档智能 [第1卷 #13] —— 将模式整合在一起，以及为什么这才是“代理式 RAG”应有的样子
Over the last few articles, we built loop patterns one at a time: a re-parse when a page check fails, a second retrieval when the answer points to another section, an aggregation sweep when the question asks for a complete list. Each pattern has its own article, its own trigger, and its own test. Each one works fine on its own. 在过去几篇文章中，我们逐一构建了循环模式：当页面检查失败时重新解析，当答案指向另一个章节时进行第二次检索，以及当问题要求提供完整列表时进行聚合扫描。每种模式都有其对应的文章、触发条件和测试方法。它们各自都能良好运行。
Real questions do not arrive one pattern at a time. Take one a compliance officer would actually ask on the NIST Cybersecurity Framework: “What are all the Categories under GOVERN, and which one covers supply chain risk?” The question sounds ordinary. Inside the pipeline, it fires three patterns at once: TOC retrieval, to land on the right section; listing aggregation, to enumerate every Category, not just the most-cited ones; a synthesis step, to pick the one that covers supply chain risk. 现实中的问题并不会一次只触发一种模式。以合规官在 NIST 网络安全框架中实际会问的问题为例：“GOVERN 下的所有类别是什么，哪一个涵盖了供应链风险？”这个问题听起来很普通。但在流水线内部，它会同时触发三种模式：目录检索以定位到正确章节；列表聚合以枚举所有类别，而不仅仅是引用最多的那些；以及综合步骤，以挑选出涵盖供应链风险的那一个。
Each of the three carries its own iteration mechanic: a re-retrieval here, a re-generation there, an LLM flag that triggers a second pass. Run them on the same question and a practical problem shows up: which one decides when to stop? Leave that undecided and every new kind of question becomes another special case bolted on the side, and nobody can say what the pipeline will do next. 这三种模式各自带有迭代机制：此处进行重新检索，彼处进行重新生成，或者通过 LLM 标志触发第二轮处理。当它们同时作用于同一个问题时，一个实际问题就出现了：谁来决定何时停止？如果这个问题悬而未决，那么每一种新类型的问题都会变成一个额外添加的特殊情况，没人能预知流水线下一步会做什么。
The fashionable answer today is to hand that decision to an agent and let the model orchestrate. For an enterprise pipeline, we prefer a piece of code we can read: a dispatcher that turns the parsed question and the document profile into an explicit plan, and bounded loops that say, in code, how far each pattern may iterate. That is what this article builds: the feedback loops, the bounded iteration, and the dispatcher that composes them into one workflow. 目前流行的做法是将决策权交给代理（Agent），让模型进行编排。但对于企业级流水线，我们更倾向于使用可读的代码：一个将解析后的问题和文档配置转化为明确计划的调度器，以及通过代码定义每种模式迭代上限的有界循环。这正是本文要构建的内容：反馈循环、有界迭代，以及将它们组合成单一工作流的调度器。
This article closes Part III of Enterprise Document Intelligence, a series that builds an enterprise RAG system from four bricks: document parsing, question parsing, retrieval, and generation. 本文标志着《企业文档智能》第三部分的结束。该系列通过四个基石构建企业级 RAG 系统：文档解析、问题解析、检索和生成。
In production, real questions stack the patterns: “List the obligations of the seller, including any referenced standards” on a contract adds two-hop reference resolution on top of listing. The iteration mechanics ride alongside them. 在生产环境中，真实的问题往往会叠加多种模式：例如在合同中询问“列出卖方的义务，包括任何引用的标准”，这需要在列表功能之上增加两跳引用解析。迭代机制则伴随这些模式同时运行。
It helps to place this article on a five-rung climb, each rung a more capable version of the same PDF question-answering function. The baseline (Article 1) chains the four bricks once with keyword retrieval: one pass, return the answer. The upgraded version (Article 9) keeps the single pass but makes it richer, with a full relational parse and TOC routing, and it returns a typed answer carrying feedback fields. 将本文置于一个五级阶梯中会有助于理解，每一级都是同一个 PDF 问答功能更强大的版本。基准版本（第 1 篇）通过关键词检索将四个基石串联一次：单次处理，返回答案。升级版本（第 9 篇）保持单次处理，但内容更丰富，具备完整的关系解析和目录路由，并返回带有反馈字段的结构化答案。
The workflow rung, this article, turns that pass into one step inside a bounded loop: a dispatcher picks which patterns fire, and the loop reads the feedback fields to decide whether to retry, with the control staying in code. 本文所处的工作流层级，将上述处理过程转化为有界循环中的一个步骤：调度器选择触发哪些模式，循环读取反馈字段以决定是否重试，控制权始终保留在代码中。
The multi-intent rung (follow-up work) widens the entrance: a chat entry classifies what the user wants and routes to the right pipeline, the decision still in code. The agentic rung (further out) moves the control loop into the LLM, which picks the next step itself; this article stops two rungs below, where the pipeline is still reproducible and auditable. 多意图层级（后续工作）拓宽了入口：聊天入口会对用户需求进行分类并路由到正确的流水线，决策依然在代码中。代理式层级（更远期）将控制循环移交给 LLM，由模型自行选择下一步；本文停留在该层级之下两级，此时流水线仍然是可复现且可审计的。
This article is about the composite pipeline: a single orchestrator function that takes a question, decides which patterns to activate, runs them, manages the feedback loops, and produces an answer. The function is pdf_qa_loop: the single pass from the upgraded pipeline, grown one rung, dispatching across Part III’s patterns within (pdf, qa).
本文讨论的是复合流水线：一个单一的编排函数，它接收问题，决定激活哪些模式，运行它们，管理反馈循环，并生成答案。这个函数就是 pdf_qa_loop：它是从升级版流水线演进而来，向上提升了一级，在 (pdf, qa) 范围内调度第三部分的所有模式。
The dispatcher is where “amplify the expert” lands at the composition layer. The team’s routing wisdom gets written down once, in deterministic Python, and runs across every future question. The LLM appears at every brick. It never chooses the next call. Pattern selection is the dispatcher’s job; the iterate-or-stop decision is the loop machinery’s. Both stay in code, reviewable by the people whose judgment they codify. 调度器是“放大专家经验”在组合层面的落地。团队的路由智慧被一次性写入确定性的 Python 代码中，并应用于未来的每一个问题。LLM 出现在每一个基石环节，但它从不选择下一步调用。模式选择是调度器的工作；迭代还是停止的决策则属于循环机制。两者都保留在代码中，可由那些贡献了判断逻辑的人员进行审查。