跳到正文

RAG Generator Prompt 整合原理

查询与上下文整合技巧,提示工程+推理策略生成高质量回答

原题：请详细描述RAG系统中生成模块（Generator）如何整合用户查询与检索到的上下文信息，设计有效的Prompt模板，并结合提示工程原则与模型推理策略，生成高质量回答的完整过程。

Prompt工程 · 字节真题

回答与解析

一、上下文整合策略

检索结果预处理

  • 按相关性得分重排序，优先放置高置信度文档
  • 动态截断：根据模型上下文窗口预留20%给系统提示和用户查询，剩余分配给检索文档
  • 去重与冲突检测：相似度过高的文档合并，矛盾内容标记供模型判断

上下文格式化

[Document 1] 来源: {source_id}
{content}

[Document 2] ...

二、Prompt模板设计

三层结构

  • 系统指令：定义角色（"你是专业助手"）、任务目标、约束条件（"仅基于提供文档回答，不确定时说明"）
  • 上下文区块：用明确分隔符包裹检索内容，标注来源便于后续引用
  • 用户查询：置于末尾，利用模型对近期token的注意力偏好

关键技巧

  • 添加Few-shot示例：展示"有答案/无答案/多文档综合"三种典型场景
  • 输出格式约束：强制JSON或带引用标记的结构化输出
  • 反幻觉指令："若文档未提及，回答'根据现有资料无法确定'"

三、推理策略配置

场景 Temperature Top-p 特殊设置
事实性问答 0.1-0.3 0.9 高重复惩罚，强制确定性
创意生成 0.7-0.9 0.95 放宽约束
多文档综合 0.3-0.5 0.9 启用beam search获取多个候选

四、生成后处理

  • 引用溯源：正则提取模型输出的[source_id]，与原文对齐验证
  • 置信度过滤：对低概率生成的token序列触发二次检索或人工复核
  • 答案重排序：多候选生成时用轻量模型打分，选最优输出

学习建议

建议先掌握RAG基本流程，理解Prompt构成要素，再学习常见模板设计与推理优化方法，结合实际案例练习Prompt编写。

口语版讲法(约4分钟)

  • 这道题核心问的是怎么把检索回来的碎片拼成连贯回答
  • 先说检索结果怎么整理
  • 再讲Prompt模板怎么设计
  • 推理策略和生成后处理
  • 最后收尾加个可延伸点

这道题我觉得本质在问一件事：你手头有一堆碎片化的检索结果，怎么把它拼成一句人话，而且拼的时候不能瞎编，也不能漏掉关键信息。说白了就是检索和生成中间的衔接，这是RAG落地最容易翻车的地方。

先说检索结果怎么整理。直接拿Top-K文档拼起来肯定不行，我一般会做三件事。先说按相关性得分重排，把最靠谱的放前面，因为模型对开头的文档注意力更集中。然后看动态截断，模型上下文窗口就那么长，我会预留20%给系统提示和用户问题，剩下的才分给文档，超长的直接切掉。另外还要看去重和冲突检测，比如两段文档都在讲同一个政策但说法不一样，我会把相似度高的合并，矛盾的内容保留并在Prompt里让模型自己判断。

然后就是Prompt模板设计。我习惯用三层结构：最上面是系统指令，定义角色和任务，比如“你是电商客服助手，只能根据提供的文档回答，不确定就说不知道”；中间是上下文区块，用清晰的标记把每段文档包起来，标注来源ID；最下面是用户查询，因为模型对最近看到的Token更敏感。这里有个小技巧，我会加两三个Few-shot例子，覆盖“有答案、无答案、多文档综合”三种情况，模型学得很快。还有一个反幻觉指令特别重要：如果文档里没提，必须回答“根据现有资料无法确定”，这个指令能显著降低幻觉率。

推理策略上，我会根据场景调参数。事实性问答比如退款政策，Temperature设到0.1到0.3，让模型尽量确定，不瞎发挥。如果是创意生成比如写商品描述，可以调到0.7以上。多文档综合时我还会用Beam Search生成多个候选，选一个最合理的。生成完之后还有后处理，我会正则提取模型输出的来源ID，跟原文对一下，确保每句话都能溯源。如果模型生成某个Token的概率特别低，我可能会触发二次检索或者直接标记出来让人工复核。

举个例子，电商客服场景下用户问“满减和优惠券能一起用吗”。如果文档里只说了满减规则，没提优惠券，模型很容易自己推断说“可以”，这就幻觉了。所以我会在Prompt里强调“如果文档没提，就说不知道”，同时后处理时检查引用，如果答案引用了文档1但文档1根本没提优惠券，就拦截掉。

这里有个延伸点：当文档特别多的时候，单纯靠截断可能会丢掉关键信息。我最近在研究用 Agentic RAG 的思路，让模型先判断还需要什么信息，主动去检索第二轮，而不是一次把所有文档塞进去。这样能更精准，但延迟会高一些，需要做取舍。

所以整体上，我更愿意把生成模块看作一个受约束的翻译器，它的核心任务是把检索结果忠实地转成自然语言，不是自由创作。上线前我会特别关注反幻觉指令的效果和引用溯源的覆盖率，这两个点是最容易暴雷的。

关键一句:当文档数量多到上下文窗口装不下时，单纯截断会丢信息，可以考虑用Agentic RAG让模型主动二次检索。

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你在做一个智能客服系统，用户问“这个订单什么时候发货”，系统检索到一堆相关文档。你会怎么把这些文档和问题拼到一起，让模型给出既准确又带引用的回答？

  2. 问法 2 · 层层追问

    RAG生成器怎么把检索到的文档和用户问题整合起来？……那如果文档很长，上下文窗口有限，你怎么处理？……怎么设计prompt让模型只基于文档回答，还能标出引用？

  3. 问法 3 · 直球架构

    详细说一下RAG生成模块的完整流程：怎么整合用户查询和检索文档？prompt模板怎么设计？推理参数怎么调？生成后怎么处理输出以保证质量？

同模块相关题目