2.3 生成模块：把资料变成可信赖的回答

2.3 生成模块：把资料变成可信赖的回答

本节摘要：生成模块是 RAG 管线的最后一棒，负责接收检索到的上下文与用户查询，产出最终答案。它的核心技术是提示词工程与解码参数控制，设计考量横跨模型选型、上下文长度、冗余处理与安全性。本节讲清这些旋钮的用法与直觉，并介绍答案精炼、事实核查、引用添加三类增强手段。读完你应当能把"资料"变成"回答"，并知道每个生成参数动了之后会发生什么。

学习目标

阅读完本节，你应当能够：

1. 写出包含指令、上下文、问题、格式四要素的检索问答提示词；
2. 解释温度与采样参数对生成结果的影响，并按场景设置初始值；
3. 应对上下文长度超限与信息冗余两类典型问题；
4. 说明三类生成增强手段（精炼、核查、引用）的适用条件。

一、最后一棒，也是聚光灯下的一棒

检索模块辛苦找回来的五个文本块，最终以一段自然语言的形式呈现在用户面前。这段话是整套系统唯一可见的输出——检索再准，生成拉胯，用户看到的就是一个答非所问的系统；检索一般，生成得法，反而可能化险为夷。生成模块的职责因此可以概括成五件事：理解上下文、融合信息、生成文本、控制风格、整合知识。

它的底层是大型语言模型，以 Transformer 架构为基础，通过自注意力机制捕捉长距离依赖。常用模型里，解码器-only 架构的生成模型是主力。但对搭建 RAG 的人而言，模型内部结构不是天天要操心的事，真正天天打交道的是两组外部旋钮：提示词与解码参数。

二、提示词工程：四要素与一个反例

一份合格的检索问答提示词包含四个要素：

• 指令：明确告诉模型做什么——"根据以下参考信息回答问题"，而不是"帮我看看"；
• 上下文：检索到的文本块，明确标注边界（如用标记包裹）；
• 问题：用户查询原文；
• 格式：期望的答案形态——段落、列表、是否附引用编号。

一个经过实战检验的提示词骨架大致是："请仅根据以下参考信息回答问题。如果参考信息不足以回答，请直接说明不知道，不要编造。〔参考信息开始〕……〔参考信息结束〕问题：……请用简洁的段落回答，并在句末标注所依据的资料编号。"

其中"不足以回答就明说"这一句，是压制幻觉的第一道闸门。没有它，模型面对不相关的检索结果也会硬答——毕竟它的训练目标就是生成连贯文字。

⚠️ 反例警告：把检索结果不加标记地与问题拼接，模型分不清哪句是资料、哪句是提问，容易把问题里的假设当成事实展开。边界标记不是可有可无的排版，是语义护栏。

三、解码参数：三个旋钮的直觉

温度控制随机性。温度低（接近零），模型每次都选概率最高的词，输出稳定保守——适合事实问答、代码生成；温度高，采样范围放宽，输出多样有创造性——适合文案创作、头脑风暴。检索问答的默认值我们建议设在零点一到零点三之间：宁可呆板，不要发挥。

Top-k 与 Top-p 采样从另一个方向限制候选词：Top-k 只在概率最高的 k 个词里采样，Top-p 在累积概率达到 p 的词集合里采样。它们与温度配合，共同决定"生成的发散程度"。

束搜索在早期小模型时代用于寻找整体最优序列，在当前的大模型对话场景用得不多，知道概念即可。

调这些参数时有个朴素原则：一次只动一个，跑同一组测试问题对比效果。全拧一遍再看，你永远不知道是哪个旋钮起了作用。

四、设计考量的四道关卡

模型选型：任务复杂度与资源预算的平衡。能调商用旗舰模型就用旗舰，本地化需求则选开源模型——答案质量的下限差距，往往在模型档次上体现得最直接。

上下文长度限制：模型的窗口是有限的。检索块太多、单块太长，就得截断或压缩。截断有原则：优先保留相关度高的块，宁可少而准，不要多而杂。

信息冗余处理：多个检索块常常你一句我一句说的是同一件事，直接全塞给模型，答案会啰嗦重复。去重与合并（简单的文本去重或摘要压缩）在塞入前完成。

安全性：防止模型生成有害内容，以及防止用户通过精心构造的查询让模型泄露系统提示词或知识库里的敏感信息。企业部署里这道关不能省。

四道关卡里再展开一下"冗余处理"，因为它最常见也最容易被误解决。多个检索块内容重复时，粗糙的做法是直接全塞给模型，赌它自己能去重——赌输的表现是答案里同一个要点翻来覆去说三遍。正确做法分两级：文本级去重（相似度极高的块只留一个，零风险）先做；语义级合并（把多个块的内容归纳成一段提要）视情况再做，它有信息损失的风险。去重的位置在拼提示词之前，而不是让生成模型边写边忍。

提示词还有两个值得单独点名的进阶技巧。分段指令：对长检索内容，要求模型"逐段核对资料后再综合"，比"直接回答"更能压制遗漏。拒答设计：明确列出允许拒答的情形（资料相互矛盾、资料与问题域不符），拒答不是失败，是系统诚实性的体现——一个会说"我不知道"的系统，用户信任度反而更高。

五、三类增强手段

基础生成之上，还有三类增强动作，分别对付三种病：

答案精炼对付"冗长病"：用模型对初稿再过一遍，压缩啰嗦、理顺逻辑。多一次调用，多一份成本，换来的是可读性。

事实核查对付"编造病"：对生成的关键事实再做一次校验，对照检索原文或外部知识源，发现无据可依的表述就删改。高风险场景值得这笔投入。

引用添加对付"无据病"：要求模型在答案中标注每段结论来自哪个资料块。它把"可溯源"从系统能力变成用户可直接核验的体验，也是第 1 章讲的溯源价值在生成侧的落地。

六、两种典型故障的排查

上线后生成环节最常见的两类故障，值得给出排查路径。

故障一：答案与检索资料不符。 模型明明拿到了正确资料，答案却另搞一套。排查顺序：先看提示词里有没有"仅根据参考信息回答"的硬约束；再看资料块的边界标记是否清晰（模型可能把资料当成了背景阅读）；最后看温度设置——高温会让模型"越狱"出自己的记忆。三步走完，九成的资料不符能定位。

故障二：答案永远三句话，该展开的不展开。 多半是格式指令缺失或最大长度限制太紧。在提示词里写明期望的结构（"先给结论，再分点展开依据"），并给足输出长度配额。反过来，答案啰嗦冗长则检查是否塞了太多冗余检索块——生成端的啰嗦，病根常在检索端的贪多。

两类故障之外还有一种更隐蔽的"慢性病"：答案正确但千篇一律。所有回复都是同样的句式、同样的结构，用户读多了会疲劳，信任感反而下滑。这在低温加固定模板的配置下最常见。解法不是升温（会牺牲准确性），而是在格式指令里给模型留出有限的措辞自由度——结构固定、表述可变，既守住可靠性又保住一点生气。诊断这类慢性病有个简单办法：随机抽二十条历史回答连着读，若你自己都读出了"模板感"，用户早已读出来了——此时就该调整格式指令的措辞空间了。

再给一张生成端配置速查表，覆盖三类典型答案形态：

配置之外，生成模块还有一处容易被忽视的接口设计问题：答案与证据的结构化返回。把答案正文、引用列表、置信提示分开字段返回，而不是揉成一段文字——前端要做引用跳转、审计要留证据链、监控要统计引用率，都依赖这个结构。早期把接口定成"返回一个字符串"的团队，后来几乎都经历了痛苦的接口改造。生成模块的输出不只是给用户看的，还是给下游系统用的，接口设计要有这个前瞻。

💡 我们的实践顺序：先把"仅根据参考信息回答、不足则明说"这句话加进提示词，再做引用添加，最后视场景决定要不要事实核查。前两步几乎零成本，能消掉大半的明显幻觉；核查的自动化做起来最重，留给合规要求高的系统。

带走这五条

• 五项职责：上下文理解、信息融合、文本生成、风格控制、知识整合——生成模块不只是"写一段话"。
• 提示词四要素：指令、上下文、问题、格式；边界标记与"不足则明说"是两道必需的护栏。
• 参数直觉：温度管随机、Top-p 管截断；事实问答低温保守，创作场景放宽；一次只调一个参数。
• 四道关卡：模型选型、上下文长度、冗余处理、安全性，逐项过，别默认。
• 增强三件套：精炼治冗长、核查治编造、引用治无据，按场景递进启用。
• 接口前瞻：答案、引用、置信提示分字段返回，别让下游系统去解析一段自由文本。

至此三段管线全部打通。但朴素管线跑起来后，你会发现一连串新问题：检索语义太浅、长文档处理不动、效果没法量化。第 3 章就为这些病而来——详见第 3 章。