最近一直在调一个基于大模型的问答系统核心链路就是RAG。项目标题叫“RAG生成(大模型)”听起来像是个概念但真正上手后你会发现RAG的难点根本不在“检索”那一步而在“检索之后、模型张嘴之前”这段路——也就是生成端的设计。很多团队的RAG初版能做出来效果好不好的分水岭全在生成端怎么把检索结果喂给模型、怎么约束模型输出。这篇文章我用自己实际踩坑的经验把RAG生成端的链路、Prompt构造、模型参数、上下文组装、幻觉控制、评估和工程落地挨个拆开讲适合已经搭过RAG demo、正在往生产环境打磨的开发者看。新人也能跟着走一遍至少能避开我当年绕了很久的那些弯。1. RAG的生成链路到底长什么样很多人把RAG理解成“检索加拼接”觉得不就是把搜到的文档塞进Prompt里让模型回答吗。这个理解方向没错但颗粒度太粗导致后面一调就懵。RAG真正落地时生成端的链路是查询改写、检索、后处理、上下文组装、Prompt构造、模型推理、输出校验最后才是返回用户。1.1 别把RAG只当成“检索拼接”从架构上看一个完整的RAG系统至少包含这几个模块查询处理器、检索器、重排器、上下文构造器、生成模型、输出解析器。检索器负责召回候选文档但召回不等于可用召回结果里通常有大量冗余、噪声、甚至互相矛盾的内容。生成端的核心任务就是把召回结果转化成模型能高效利用的“证据”再让模型基于证据生成答案。我见过最多的问题就是把检索结果直接拼进Prompt。这样做的直接后果是上下文窗口被无效信息占满、模型被无关片段带偏、生成延迟变高。原因很简单大模型的注意力机制是“一视同仁”的不会自动区分哪些是证据哪些是噪声。你得在生成端替模型先做一轮筛选和整理把“有可能有用的”变成“确定有用的”。1.2 生成端的三段式输入结构我在实践里把RAG生成端的输入固定成三段式结构系统指令、上下文证据块、用户查询块。系统指令定义模型角色、回答边界、引用要求上下文证据块放检索后处理过的文档片段用户查询块放用户原始问题或改写后的问题。这三段不是随便拼的。系统指令要在最前面因为很多模型的指令遵循能力受位置影响放太靠后容易被长上下文稀释。证据块放在查询块之前模型在生成时会先“读到”证据再看到问题输出时更容易引用证据里的表述。查询块放最后还有一个好处配合部分模型的注意力实现能让模型对问题附近的token分配更高权重回答更贴题。1.3 从检索到生成之间到底发生了什么检索器返回的是一堆文档块但生成端拿到的应该是精炼后的证据列表。中间要经过去重、相关性过滤、重排、截断、关键片段抽取、按窗口预算裁剪。这些步骤我后面会展开讲这里先建立一个全局感检索决定上限生成决定下限。检索召回再准生成端不会组织证据答案依然是稀烂的反之召回一般但生成端组织得好回答质量反而能救回来不少。2. 生成端Prompt构造比想象中更讲究Prompt构造是RAG生成端最容易被低估的环节。很多人以为写了“根据以下文档回答问题”就够了实际上这个短短的指令承载了大量隐性的信息组织任务写不好模型就从“基于证据回答”滑向“凭记忆编造”。2.1 system指令怎么写我常用的系统指令模板分四个层次人格设定、任务定义、证据使用约束、输出格式约束。人格设定不用花哨说清楚“你是一个严谨的问答助手”就行任务定义要明确“基于提供的文档内容回答问题”证据使用约束要强调“如果文档中没有答案请直接说明不要推测”输出格式约束按业务需要来比如要求“答案后附引用编号”。有个关键细节证据使用约束不要只写“不要编造”要写“当提供的信息不足时明确回答‘根据现有资料无法确认’”。前者是禁止性的模型容易在高压下阳奉阴违后者是引导性的给了模型一条合规的退路反而能降低幻觉率。我测试过加了这句后退化为“编造答案”的比例能降三到五个百分点。2.2 文档块与查询块的编排检索回来的文档块不能原样塞进去。常用的编排方式是在每段文档前加一个引用标识格式类似[1]、[2]这种同时在文档块之间加入明确的边界标识符。这样做的目的有两个一是让模型区分不同来源便于输出引用编号二是避免多段文档粘连成一大坨模型读到后面忘了前面是哪份材料的。查询块的部分也要处理。用户原始问题可能口语化严重直接拼进Prompt会降低指令清晰度。先在查询处理器里做一轮改写把口语转书面、把指代消解、把模糊意图补全再用改写后的query去构造Prompt。这一步对多轮对话场景尤其重要原始问题往往是上一轮的延续直接丢给模型和证据块模型容易摸不着头脑。2.3 few-shot与输出格式约束有条件的场景建议在Prompt里加一两个few-shot示例特别是需要模型输出结构化结果时。示例不用多一正一反就够正面示例展示标准回答格式反面示例展示“资料不足时如何拒绝回答”。我在多个模型上验证过few-shot对输出格式稳定性提升明显代价是增加几十到几百个token的输入长度通常可接受。输出格式约束别只写在指令里可以在Prompt末尾加上“请以以下格式输出答案引用来源”。模型对靠近结尾的格式示例更敏感能显著提升JSON或Markdown格式的合规率。我踩过一个坑输出格式约束写在系统指令中间结果模型前几次回答格式飘逸后来挪到末尾格式合规率从70%多提到接近100%。3. 模型与参数选择生成质量差在哪几条模型选型和解码参数是RAG生成端的另一个大坑。同样的检索链路换一个底座模型效果天差地别。参数调优也是差一点点回答风格和事实性都会有明显变化。3.1 Base还是Chat版本直接给结论启动RAG项目时优先选用 Instruction Tuned 或 Chat 版本不要用 Base 模型。Base模型只学会了“续写”没有学会“遵循指令”。你把检索来的文档拼给Base模型它更大概率是在续写文档风格的内容而不是回答用户问题。Chat版本经过指令微调能识别出“这是要我基于证据回答”的意图生成质量稳定得多。选Chat版本时也要注意微调风格差异。有的模型在问答任务上表现好但在“长文本引用”上容易丢三落四有的模型对指令遵循能力强但对上下文中的矛盾信息敏感。我建议在定模型前先拿自己业务里的真实文档和问题跑一遍小样本对比不要只信公开榜单。公开榜单纯粹测通用能力RAG场景对“证据利用能力”的要求更特殊。3.2 解码参数怎么调RAG场景下解码参数的核心目标是在“事实准确性”和“表达丰富性”之间取平衡。我常用的起点配置是temperature 0.1到0.3top_p 0.8到0.95max_new_tokens按答案预期长度设置另加stop token控制结束时机。temperature调太低比如0.01模型输出过于机械遇到需要归纳多篇文档时会表现得很死板调太高比如0.7以上模型自由发挥空间大幻觉率显著上升。RAG生成端的温度上限我建议不要超过0.5除非你的场景强依赖多样性和创造性。top_p同理过高等于没约束过低会让模型措辞变得不自然通常0.85-0.9是个甜点区间。3.3 处理超长上下文的经验业务里的文档经常超过模型上下文窗口的一半这时候直接截断会丢失关键信息不截断又会超出窗口限制报错。我的处理方法是分层先限制检索条数再限制单条文档长度最后用滑动窗口切分。具体策略放在下个小节展开这里先说模型侧的注意事项。长上下文场景务必确认你的推理框架有没有应用 RoPE 或 ALiBi 这类位置编码方案以及是否做了长度外推。我遇到过位置编码切换后模型对长文本的注意力分布出现问题回答后期开始走神排查了半天才发现是推理框架的兼容选项没打开。这类问题不报错只表现为质量下降很容易被误判为Prompt问题。4. 上下文窗口组装与截断策略你手头有一堆检索结果怎么把它们装进模型的上下文窗口这个环节的操作空间比想象中大得多。我把它拆成三个子问题检索条数和窗口预算怎么分配、哪些内容值得放进去、放进去的内容怎么排列。4.1 检索条数与窗口预算首先要明确一个观念不是检索条数越多越好。检索返回的文档块数量多虽然覆盖率提高但上下文窗口被无关内容挤占模型注意力被稀释答案反而容易散。我实践下来的经验值是单轮问答检索条数控制在4到8条具体看文档块大小和模型窗口长度。窗口预算的分配逻辑是给用户查询块和系统指令预留固定空间剩下的按比例分给证据块。举例一个8K上下文窗口系统指令加查询块约占用1K剩下7K给证据块。如果检索返回6条每条平均1.2K那总量7.2K略超预算就需要按相关性排序后裁剪尾部保证核心证据完整。4.2 去重、重排与关键片段提取检索结果常常有重复内容特别是同一份文档被切分成多个块后相邻块之间内容重叠度高。直接去重可以用文本相似度算法比如计算嵌入向量余弦相似度超过阈值的块只保留得分更高的那条。这一步能减少10%到20%的窗口浪费。重排环节我推荐在生成端做一次轻量重排按检索得分和与查询的语义相似度做加权排序。有条件的用专门的重排模型没条件的用LLM自带打分能力也行。关键片段提取则是在单条文档过长时用文本分割算法抽取与查询最相关的句子序列而不是整块塞入。这三步做完证据质量会有质的提升。4.3 被忽略的stop token与max_new_tokens生成端还有个容易被忽略的参数停止符设置。RAG场景常见的生成末尾是“以上答案基于所提供文档”“引用编号”这类尾巴如果不设置stop token模型可能会补一堆废话。更常见的是模型输出到引用编号列表时就该停了但默认行为会继续补充解释性内容浪费延迟和token。max_new_tokens也要按答案类型设置。事实型问答答案一般短设置256左右足够总结归纳型回答可以放宽到512或更高。设置太长会增加等待时间设置太短会截断回答需要结合业务实际分布反复校准。5. 幻觉与引用控制RAG的一个重要目标就是减少幻觉但很多团队把希望完全寄托于“只要检索到就能不幻觉”事实并非如此。幻觉问题贯穿整个生成端从Prompt、参数到输出校验每一环都需要控制。5.1 幻觉来源分析RAG场景下的幻觉主要有三类上下文幻觉、记忆幻觉、混合漂移。上下文幻觉是模型读了证据块但并没有真正使用而是按照自己知识库里的固有印象回答记忆幻觉是证据块里没有相关信息模型被用户问题激活了预训练知识强行给出了答案混合漂移是模型把证据和自身记忆混在一起生成了一段真假参半的内容。三类幻觉里上下文幻觉占比最高处理办法是强化Prompt中的证据引用要求记忆幻觉次之处理办法是给足“资料不足时明确拒绝”的退路混合漂移最麻烦往往需要加输出校验和引用检查来兜底。5.2 出处的设计与Prompt约束引用编号机制是目前控制RAG幻觉最有效的手段之一。实现方式并不复杂在拼接证据块时给每个来源编号Prompt中要求模型在回答的每个关键句末标注引用编号比如“根据相关数据显示[1][2]”。这样好处是双重迫使模型在生成答案时持续对照证据块而不是放飞同时让后续的引用校验环节能自动检查答案是否有对应的证据支撑。Prompt里的约束用词要讲究。“必须引用”比“可以引用”效果好“每个关键信息都要标注来源”比“注意引用”效果好。我在实验中对比过启用强制引用后答案的事实性评分平均能提高10%以上同时显著降低了无中生有的比例。5.3 温度与抽样策略对幻觉的影响前面提到了温度偏低有利于事实性这里展开说一下抽样策略的选择。RAG生成端建议优先使用确定性较高的解码方案比如贪心解码或将temperature设为0.1以内的低随机采样。不是说你永远不能有创造性而是RAG的核心价值是“准确引用资料”随机性过高就破坏了立身之本。如果真的需要多样性输出比如生成多个候选答案再做重排可以在每次采样时固定随机种子保证同一查询在相同条件下输出一致方便回归测试。这个细节很多人忽略等到上线后发现问题复现不了才回过头来找随机性浪费时间。6. 效果评估不能只靠肉眼我见过太多团队把RAG生成的评估停留在“打开系统问几个问题看着觉得回答还行”的阶段。这在demo期没问题但进入迭代期就完全不够了。没有量化指标你无法判断改动是变好还是变坏也无法向上汇报。6.1 忠实度、答案相关性、上下文相关性评估RAG生成质量我至少会看三个维度答案忠实度faithfulness、答案相关性answer relevance和上下文相关性context relevance。忠实度考察答案是否严格基于证据块有没有凭空捏造答案相关性考察生成内容是否切题上下文相关性考察检索结果与用户问题的匹配度。这三个维度可以用模型打分或规则的方式自动计算。模型打分一般用较强的通用模型当裁判给定查询、证据、答案输出1到5分规则方式可以检查答案中是否包含证据块的关键实体。两者结合最稳。关键在于评估集的建设至少要准备200条覆盖不同业务场景的QA对包含正常问题、模糊问题、资料不足问题、多跳问题这几类。6.2 线上评测与回归集线下评估做得再好上线后还是会遇到新问题。我在实践中会维护一套线上日志回流机制把用户的真实查询和模型回答存下来每周抽取样本做人工标注评估。配合会话级反馈信号比如用户是否追问、是否点击了推荐文档做辅助判断。回归集的重要性不用多说了每次改Prompt、改模型、改检索策略前先在固定回归集上跑一遍打分对比差异再决定是否上线。没有回归集任何改动都是盲改出了方向性问题时你根本不知道是哪个环节引入的。7. 工程落地里容易踩的坑RAG生成端的工程化坑和算法层面的坑不一样它们更隐蔽通常只在并发和长尾场景才暴露。7.1 缓存与并发同一个问题重复被问到是常态不加缓存就是白白付算力。缓存键不能只按用户原始问题算要连同改写后的query、检索结果的指纹一起作为缓存因子。因为改写结果可能变化检索结果可能因知识库更新而变动这两项不稳定时命中缓存的答案可能已经过期。并发方面生成端要特别关注推理服务的排队机制。RAG查询通常比普通对话的输入长如果和普通请求混在同一个推理服务里长序列占用的显存和计算资源会让短请求的延迟也飙高。我的实践经验是把RAG生成请求和普通对话拆到不同队列或不同实例避免互相拖累。7.2 日志与TraceRAG链路长出了问题非常难排查。我强烈建议在生成端全链路加Trace ID从用户查询、改写结果、检索返回、重排结果、最终组装Prompt到最后生成的答案完整落日志。这样一旦线上反馈回答质量差你可以快速定位是检索阶段就偏了还是Prompt构造环节出了问题还是模型输出阶段发生了漂移。日志里Prompt部分建议脱敏后落盘方便后续分析但避免拷问隐私。答案与证据的对应关系要保留引用编号和文档块ID审计和追溯时会省下大把时间。7.3 版本回归RAG系统的组件多检索模型、重排模型、生成模型、Prompt模板都有可能单独更新。每次更新前在回归集上做一遍完整评估是底线操守但很多项目赶进度会跳过这一步结果上线后效果骤降。我的管理方法是对每个组件打版本标签Prompt模板的变更也要纳入版本管理不允许改完直接上生产。回归集的结果要记录存档方便做趋势分析。一个容易被忽视的细节是嵌入模型或检索存档更新后旧缓存中的检索结果指纹就失效了需要做缓存迁移或过期处理否则用户会拿到新旧混合的答案体验很割裂。8. 常见故障排查速查表最后整理一份我在实际运维中积累的排查表按症状、可能原因、处理建议三列列出。遇到问题直接对照着查能节约很多试错时间。症状可能原因处理建议答案偏离问题查询改写失败或Prompt中查询块与证据块顺序不当检查改写结果确认查询块位于证据块之后答案引用不存在的内容证据块被截断导致模型“脑补”缺失部分调整截断策略给模型完整证据或限制引用输出格式混乱格式约束放在Prompt中部模型没记住在Prompt末尾重复格式要求或用few-shot回答过于笼统温度偏高或top_p偏大模型自由发挥调低temperature到0.2以下重测回归集答案内容自相矛盾检索返回了互相矛盾的文档块模型没有识别在证据块组织时加入矛盾检测或Prompt强调矛盾时给出不同观点上下文超限报错检索条数过多或单条文档过长缩小检索数量启用关键片段抽取延迟突然升高并发请求里有大量长序列任务拆分队列长序列和短请求分离部署同query结果不稳定未固定随机种子或推理框架开启采样固定种子配置确定性解码模式答案中英文混杂或风格漂移证据块中包含非目标语言内容在证据块组织时做语言过滤或加语言约束指令上线后效果明显下降检索存档或模型更新导致缓存失效检查缓存指纹策略强制过期后重建这套速查表是我多轮迭代的沉淀未必覆盖所有场景但覆盖了我遇到过的绝大多数问题。RAG生成端没有银弹最佳路径还是搭建好评估体系用数据驱动地调整而不是凭感觉瞎试。我个人在实际操作中最深的体会是RAG的生成端本质上是一个“证据到答案”的翻译过程检索端负责把世界上的资料翻出来生成端负责把这些资料翻译成用户要的答案。翻译得准不准、稳不稳取决于你对Prompt、参数和上下文的精细控制。把前端这些细节打磨到位比追逐最新的模型或者折腾花哨的框架更能带来立竿见影的效果。希望这篇文章能帮你少走几步弯路把精力花在真正影响质量的地方。