Assemble Each RAG Generation Prompt from a Base Prompt Plus the Rules Each Question Needs
Assemble Each RAG Generation Prompt from a Base Prompt Plus the Rules Each Question Needs
Large Language Model Assemble Each RAG Generation Prompt from a Base Prompt Plus the Rules Each Question Needs Enterprise Document Intelligence [Vol.1 #8B] – A fixed BASE, the rules each question needs, one registry: the dispatcher that turns a parsed question into a typed LLM call
大型语言模型：通过基础提示词（Base Prompt）加上问题所需的规则来组装每个 RAG 生成提示词——企业文档智能 [第1卷 #8B] —— 一个固定的基础（BASE），每个问题所需的规则，以及一个注册表：将解析后的问题转换为类型化 LLM 调用的调度器。
Kezhan Shi Jul 5, 2026 30 min read Share
Kezhan Shi，2026年7月5日，30分钟阅读，分享。
This article is the second part of the generation brick of Enterprise Document Intelligence, a series that builds an enterprise RAG system from four bricks: document parsing, question parsing, retrieval, and generation. Article 8A (the answer contract) declared the typed schema family and the ANSWER_REGISTRY that maps each answer shape to its schema. This part builds the call that fills the contract: a ParsedQuestion comes in; the dispatcher picks the schema from the registry, composes the system prompt from a fixed BASE plus fragments, builds the user prompt, calls the model, and keeps the full trace. What happens to the answer after the call is Article 8C (validation).
本文是“企业文档智能”系列中“生成”模块的第二部分。该系列通过四个模块构建企业级 RAG 系统：文档解析、问题解析、检索和生成。第 8A 篇文章（答案契约）声明了类型化模式族以及将每个答案形状映射到其模式的 ANSWER_REGISTRY。本部分将构建实现该契约的调用逻辑：当 ParsedQuestion（已解析问题）进入时，调度器从注册表中选择模式，通过固定的 BASE 加上片段来组合系统提示词，构建用户提示词，调用模型，并保留完整的追踪记录。调用后的答案处理将在第 8C 篇文章（验证）中讨论。
Generation is the fourth brick. A reader landing here can pick up the first three from their own articles: Document parsing, the PDF turned into structured tables: Article 5A (what to read in a PDF) and Article 5B (the relational data model). Question parsing, the user string turned into a typed ParsedQuestion: Article 6A (the thesis), Article 6B (extraction), and Article 6C (dispatch). Retrieval, the passages filtered down to what should hold the answer: Article 7A (retrieval as filtering), Article 7B (anchor detection), and Article 7C (the LLM arbiter). where this article sits in the series: Article 8 (generation), the prompt-assembly part, inside Part II (the four bricks).
生成是第四个模块。读者如果刚接触本文，可以从各自的文章中了解前三个模块：文档解析（将 PDF 转换为结构化表格）：第 5A 篇（PDF 读取内容）和第 5B 篇（关系数据模型）。问题解析（将用户字符串转换为类型化的 ParsedQuestion）：第 6A 篇（论点）、第 6B 篇（提取）和第 6C 篇（调度）。检索（将段落过滤至包含答案的内容）：第 7A 篇（作为过滤的检索）、第 7B 篇（锚点检测）和第 7C 篇（LLM 仲裁者）。本文在系列中的位置：第 8 篇（生成），即提示词组装部分，属于第二部分（四个模块）。
1. From brief to prompt: the dispatcher
1. 从简报到提示词：调度器
One prompt per question shape, composed at call time. That is the dispatcher. The alternative is the mega-prompt every RAG codebase drifts into: one system prompt handling amounts, dates, lists, tables, and free text at once. It grows a new conditional clause on every call (“if the answer is a date, use ISO 8601; if an amount, ISO 4217; if a list, one item per element…”), the model reads all of it every time, and two months in nobody remembers which clause was added for which case. The dispatcher we’ll build replaces that mess.
每个问题形状对应一个提示词，在调用时进行组合。这就是调度器。另一种选择是每个 RAG 代码库最终都会陷入的“超级提示词”陷阱：一个系统提示词同时处理金额、日期、列表、表格和自由文本。它在每次调用时都会增加一个新的条件子句（“如果答案是日期，使用 ISO 8601；如果是金额，使用 ISO 4217；如果是列表，每个元素占一项……”），模型每次都要读取所有内容，两个月后，没人记得哪个子句是为了哪种情况添加的。我们将要构建的调度器将取代这种混乱。
Contract: a ParsedQuestion comes in; three things come out: the schema (picked from ANSWER_REGISTRY by expected_answer_shape), the system prompt (a fixed BASE plus the fragments the brief requests), and the user prompt (question + keywords + labeled passage lines). It calls the model, persists the full raw response on the trace, returns a typed result. Adding a new shape adds one fragment; adding a new constraint adds one fragment; nothing combinatorial.
契约：输入一个 ParsedQuestion；输出三样东西：模式（根据 expected_answer_shape 从 ANSWER_REGISTRY 中选择）、系统提示词（固定的 BASE 加上简报要求的片段）以及用户提示词（问题 + 关键词 + 标记的段落行）。它调用模型，将完整的原始响应持久化到追踪记录中，并返回一个类型化的结果。添加一个新形状只需添加一个片段；添加一个新约束只需添加一个片段；不存在组合爆炸问题。
1.1 The brief: ParsedQuestion
1.1 简报：ParsedQuestion
The dispatcher reads a ParsedQuestion produced by the question parsing brick. The full schema is relational (nested Pydantic objects, not a flat brief): keywords (typed objects, not strings), expected_answer_shape, decomposition, scope_filters, an execution plan, parsing notes, plus the two preparations for the next bricks (retrieval: RetrievalQuery and generation: GenerationBrief).
调度器读取由问题解析模块生成的 ParsedQuestion。其完整模式是关系型的（嵌套的 Pydantic 对象，而非扁平的简报）：关键词（类型化对象，而非字符串）、expected_answer_shape（预期答案形状）、分解、范围过滤器、执行计划、解析注释，以及为后续模块准备的两个对象（检索：RetrievalQuery 和生成：GenerationBrief）。
1.2 Structural hints from the question
1.2 来自问题的结构化提示
The user’s question phrasing scopes retrieval, without any new flag on the pipeline. When the question says “on page 1”, “pages 5 to 7”, or “on the Pricing sheet”, that pointer rides on ParsedQuestion.structural_hints. Retrieval reads it and filters the search space.
用户的提问措辞限定了检索范围，而无需在流水线中添加任何新标志。当问题提到“在第 1 页”、“第 5 到 7 页”或“在定价表上”时，该指针会携带在 ParsedQuestion.structural_hints 中。检索模块读取它并过滤搜索空间。