上周帮一位做企业问答系统的朋友排查线上工单现象很典型用户问“去年 Q3 各区域营收分别是多少”系统检索到了正确的财报片段生成的答案数据也完全对但对着一张三列的表格模型只挑了两列回答。从传统 ROUGE 指标看答案质量分很高从业务角度讲这个回答等于漏报了一半信息。这类问题在 RAG 落地里太常见了——检索到了但不一定用全、用对了。业界把它叫做 groundedness依据性验证目前也是各种幻觉检测方案最想解决的核心问题之一。最近一支由云厂商与两所高校联合的研究团队放出了一个叫 Auto-GDA 的工作方向很对我的胃口他们用自动化的数据合成流程训练轻量级模型让参数量小了至少一个数量级的小模型在 RAG 依据性判别上逼近大模型水平推理速度提升约 10 倍。这篇文章我把它的技术思路、数据构造方法、轻量模型训练细节和工程接入方式完整拆一遍并补上我自己复现和落地时踩过的一些坑。适合正在做 RAG 生产系统、幻觉治理或者想给生成式应用加一道质量闸门的读者。1. 为什么“依据性验证”成了 RAG 落地最难啃的骨头1.1 一个典型事故答案看着对其实在“漏说”和“胡说”之间反复横跳RAG 系统的幻觉问题很多人以为只是“模型不懂装懂”。实际接入过生产环境的人会告诉你更隐蔽的是“答案里的每一句单独挑出来都对但组合在一起就超出了检索文档支持的范围”。比如我问“某产品的主要竞争对手有哪些”检索到的文档只提了两家模型在列举时自作主张地补上了一家它“印象中”的对手。对的那部分掩盖了错的那部分自动化评估很难抓。这类问题之所以难解是因为它发生在“检索到的证据”和“生成的文字”之间的夹缝里。传统方法要么只看检索相关度用向量距离判断但向量相关和语义被支持是两回事要么整体评估生成质量用一个打分模型看答案好不好但整体分掩盖了局部的不忠实。直到今天团队里做质量评估的人最头疼的依然是怎么让机器明确告诉你“这句有依据、那句没依据”。1.2 依据性“三分类”标签体系支持、部分支持、不支持从业界主流做法看依据性验证最实用的是把问题拆成一个离散分类任务而不是让模型输出长串解释。Auto-GDA 延续了类似 Self-RAG 反思机制和 CRAG 可信度分类的思路把“答案与检索上下文是否对得上”分成三类支持Fully Supported答案中的所有关键实体、数据、结论都能在检索上下文中找到对应证据没有超出文档的额外信息。部分支持Partially Supported答案的某些片段有依据但至少一个关键信息点缺失或与文档矛盾。无支持Not Supported答案的核心主张在上下文中找不到任何证据属于纯粹的模型记忆性生成。为什么不用连续分数而用离散标签我在实际评测里发现连续分数很难标定阈值不同领域、不同文档风格下同样的分数含义不一样。三类标签天然对应三种动作——放行、降级重写、阻断重新检索——生产管线里可以直接映射成策略不用再做一层模糊判断。1.3 为什么大模型能做、小模型做不好如果你把这个问题丢给一个大参数模型让它判断“以上答案是否被文档支持”它能做得不错原因是长上下文理解、跨句推理、实体级比对这些能力需要足够的模型容量。但问题是在线服务的预算撑不住每个生成结果都跑一遍大模型校验。生成已经花了 2 秒校验又花 3 秒延迟直接翻倍。而小模型做这件事的难度在于依据性验证不是“记住知识”是“比对知识”。它要求模型同时理解一段长上下文和一个多句答案找出其中的矛盾点。这不但是理解任务更是对齐任务。纯靠小模型在通用语料上学到的能力很难稳定胜任。Auto-GDA 整个设计围绕的核心就是一件事——怎么把大模型的“比对能力”迁移给一个足以跑在线推理的小模型同时不依赖昂贵的人工标注。2. Auto-GDA 的思路拆解它到底“自动”在哪里2.1 从公开信息看为什么团队强调“合成数据”我最初看到这个项目名时第一反应是它大概率又是一个“大模型生成训练数据小模型蒸馏学习”的流程。从目前放出的信息看核心没有脱离这条主线但有几处设计很讲究。所谓“Auto”我理解包含两层含义一是训练数据不需要人工标注完全用大模型自动产出二是数据构造和标签生成都是自动管线可以批量扩展到任意领域。这里有一个很现实的背景想训练一个能用的依据性判别模型少说要几万条标注样本。如果靠人工标注标注员需要读一遍检索文档再对照答案逐句打标签平均一条成本几十块几万条就是几十上百万。而且跨领域还要重标。所以团队选择用大模型做自动标注模型成本可能只有人工的几十分之一。2.2 关键点不是“蒸馏答案”而是“蒸馏判断”很多蒸馏工作会把大模型的推理过程或答案文本直接当作训练目标比如让小模型学大模型写的解释。Auto-GDA 的做法在我看来更偏“行为对齐”大模型的角色不是给答案而是给groundedness 标签。小模型学的不是“说什么”而是“怎么判断有没有依据”。这个差异很关键因为判断任务本身输出空间很小三个标签大部分信息不在标签里而在“什么样的输入组合推出这个标签”的映射关系里。换句话说训练数据真正值钱的地方是什么样的 query、什么样的检索上下文、什么样的生成答案组合在一起会让答案落入“部分支持”这个类。这种边界样本才是判别模型能力的来源。所以在数据构造上团队花了更多心思在制造边界情况上——答案只差一个数字、多了一句推测、漏了一个限定词。这些样本决定了模型上线后会不会在模糊地带频繁误判。2.3 为什么不直接拿大模型做在线推理这是工程上绕不开的问题。即使大模型判断准确在线调用依然要面对几个现实瓶颈单次推理的 GPU 显存占用、token 级延迟、并发吞吐上限。一批 70B 级模型做依据性校验每秒钟能处理的请求数极其有限放到高并发问答系统里根本扛不住。Auto-GDA 选择把判别能力沉淀到 1B 以下的轻量模型付出少量准确率代价换来约 10 倍的推理加速。这个“10 倍”的来源也很直接小模型单次前向传播的浮点运算量低、显存占用小、可以在同一张 GPU 上同时跑多个实例做批量推理。从成本账看一个 70B 模型 GPU 推理的价格和一个 1B 模型的价格差距远不止 10 倍省下来的是实打实的运营成本。3. 训练数据是怎么“造”出来的四步合成流程3.1 第一步构造 query 与检索上下文的配对合成数据的起点是一批语料文档。一个常见做法是先收集一个大型文本语料库用反向生成的方式制造 query——让大模型读一段文档然后提出一个“该段文档可以回答的问题”。这种方式能保证每个 query 都能在对应文档里找到答案天然就是正样本的基础。但这里有个动作很关键不能只做“文档-问题-答案”的一一配对。真实 RAG 场景中检索系统拿回来的上下文经常是多篇文档拼接的其中有相关片段也有干扰片段。所以 Auto-GDA 在构造训练数据时会把相关文档与随机采样或语义相似的干扰文档混合模拟检索召回结果不纯的情况。模型学到的就是对“混着噪声的证据”做判断而不是总面对干净上下文。3.2 第二步大模型多次采样生成答案制造天然对比同一个 query配上不同的温度参数和不同的上下文生成多个版本的答案。由于大模型生成有随机性同样的文档下采样的答案质量会上下浮动有的忠实引用文档数字有的凭印象加工细节有的干脆跑偏。这些不同版本恰好构成“支持/部分支持/不支持”的天然候选集。具体操作上温度一般设 0.7 到 1.0 之间每个 query 采样 3-5 次。采样后的答案会和文档一起交给另一个大模型做标注标注指令写得非常细要求模型先判断答案中每个独立的“语义片段”而不是全篇是否有对应的文档证据再根据出现问题的片段数量判断整体类别。这个过程相当于把粗粒度三分类拆成了“先微观、再宏观”的两层标注准确率会比直接读全文打一个分数高很多。3.3 第三步刻意制造“边界样本”和“负样本”只靠模型自然采样出来的错误答案边界分布可能不够丰富。比如答案多了一个年份、少了一句限定、把 A 公司的数据安到 B 公司头上——这些细小的替换大模型采样时不一定每次都出现。团队在数据管线里会额外做一步自动改写。具体做法是把原始答案中的关键实体、数字、限定词做替换或删除比如把“2025 年营收 1.2 亿”改成“2025 年营收 2.1 亿”或者删掉某个前提条件。改造后的答案和原文档组合在一起就变成了高质量的“不支持”或“部分支持”样本。这类样本的价值在于它让模型注意到了“实体级错位”和“数字替换”这些最典型的幻觉形式而不是只学会判断“有没有相关内容”。3.4 第四步置信度过滤与数据分布校准大模型自动标注不是万无一失的。有些边界样本大模型自己也会犯迷糊比如文档里模棱两可、答案里有一半对一半错时标注可能随机落在“部分支持”或“不支持”上。团队的处理方式是让标注模型输出一个置信度或打分低于阈值的样本直接丢弃。这个过滤步骤很容易被忽略但影响很大。如果训练集里有 5%-10% 的标签是错的小模型的准确率会掉得比想象中快。为了控制成本也可以用两个大模型对同一批样本分别标注只保留两者一致的样本一致性过滤比单一模型置信度过滤更稳定。我在自己的小规模复现里试过双模型一致率大概在 85% 左右取交集后数据量虽然有折损但下游模型准确率能涨 2-3 个点。4. 轻量模型选型与训练细节判别式永远比生成式划算4.1 两条技术路线生成式理由 vs 判别式标签把依据性验证做成一个生成任务让模型输出“这段答案是否被支持的判断理由”优点是可解释性强结果能追溯到具体句子。但代价是输出一串 token推理慢而且小模型的自由文本生成本身不稳定可能自己边写边“编理由”。Auto-GDA 走的是判别式路线训练一个带分类头的轻量模型输入是“检索上下文 生成答案”输出是三分类 logits。这种方式有两个直接好处第一推理时只需要一次前向传播不需要自回归解码延迟是生成式方案的几十分之一第二训练更稳定目标函数就是交叉熵不会出现生成模型那种“理由写得好但结论判断错”的情况。4.2 输入拼接方式与分类头设计我复现时把输入设计成如下结构[CLS] 检索上下文: {chunk_text} [SEP] 生成答案: {answer_text} [SEP]上下文和答案之间用显式的分隔符拆开让模型清楚知道哪部分是证据、哪部分是待检验对象。编码器选 encoder-only 的小模型结构参数量在 500M-1B 之间输出取[CLS]向量接一个三层 MLP 分类头。训练时学习率用 2e-5batch size 按单卡显存尽量放满线性 warmup 加余弦衰减这些和常规分类任务没有太大区别。有一点值得提醒输入长度非常影响推理时延。如果上下文动辄三四千 tokenencoder 的注意力计算量会指数级上涨。我的经验是把上下文限制在 1024-1536 token 内超出部分按文本块滑动窗口处理先对每个窗口分别判一次再综合判整体。虽然多跑了几次前向总延迟仍然远低于生成式方案。4.3 推理提速 10 倍的成本账本到底怎么算很多读者看到“10 倍”会追问这个数字怎么来的。我按一个典型场景算笔账。假设用 70B 级模型做依据性校验输入 1500 token输出 100 token 的判断理由单次推理耗时约 2.8 秒一张 A 系列 GPU 上并发开到 8并发吞吐约 2.8 req/s。换成 1B 级判别模型输入 1500 token输出 3 个 logits单次推理耗时约 280 毫秒同样一张卡并发能开到 64吞吐大约 45 req/s。吞吐提升接近 16 倍如果算端到端延迟则大约是 10 倍标题里说的 10 倍是合理且保守的。更重要的是单位成本。在线服务计费是按 GPU 小时算的同样的校验吞吐量用 1B 模型需要的 GPU 数量比用 70B 模型少一个数量级以上。当一个系统每天有几百万次请求时这一项的年度成本差异可能是几百万与几十万的区别。对比项70B 生成式校验1B 判别式校验输入长度1500 token1500 token输出方式自回归生成约 100 token直接输出 3 分类 logits单次推理延迟约 2.8 秒约 280 毫秒单卡并发约 8 路约 64 路有效吞吐约 2.8 req/s约 45 req/s部署成本需要多卡集群单卡可覆盖5. 工程落地把 Auto-GDA 接进 RAG 管线5.1 第一种接入方式放在检索之后、生成之前如果你的场景是“想在没有依据时不让模型硬答”可以把判别模型放在 RAG 的检索和生成中间系统先把召回的文档切块、重排然后让 Auto-GDA 判断这些文档是否能充分回答用户的问题。注意这里和标准流程有个关键差异——不是判断“文档相关”而是判断“文档对这个问题是否构成完整依据”。比如用户问“诺基亚手机现在的市场份额”检索回来的文档可能只有一条新闻提到该品牌在欧洲市场的情况向量相关分很高但作为答案依据并不完整。Auto-GDA 如果输出“不支持”或“部分支持”系统可以触发二次检索、扩大召回范围或者直接告诉用户“信息不足请细化问题”。这种方式的好处是避免了模型已经生成错误答案才事后弥补的尴尬但代价是你必须额外训练一个“文档-问题”层级的判别模型而不是简单的“答案-文档”验证模型。5.2 第二种接入方式放在生成之后做最后一道闸门大部分团队会先做这条路模型生成答案后把“检索上下文”和“最终答案”一起喂给 Auto-GDA输出三类标签。对应动作很直接支持直接返回用户。部分支持把对应句标记为低置信触发一次局部重写只重写无依据的句子或者让大模型补充检索后再生成一次。无支持阻断答案重新检索或返回“无法回答”。这个流程的好处是不改动原有生成链路推理层完全隔离。缺点是已经浪费了一次生成算力。但在上线初期、不想动主链路的阶段这是最稳妥的灰度方式。我建议先做这一层跑通数据回流和指标监控再考虑前移到检索后阶段。5.3 阈值与兜底策略宁可漏报也不误杀三分类和阈值配套使用时有个容易被忽视的问题softmax 输出的概率不等于真实置信度。我见过直接拿“不支持”类的概率超过 0.5 就阻断的做法结果真实场景中误杀率很高。因为训练数据的标签分布和线上分布往往不一致线上“不发生幻觉”的样本占比明显更高。实操中更稳的做法是留一个不确定性区间。比如“支持”类的概率低于 0.7、且“不支持”类的概率低于 0.5就把它当作“不确定样本”走人工审核或降级处理而不是直接放行或阻断。误杀一个本来正确的答案对用户体验的伤害远大于放掉一个幻觉。6. 实操中的坑与调优经验6.1 长文本跨块引用引发的“部分支持”误判我在自己的数据集上复用时最先遇到的是长答案跨多个检索块的问题。一个答案有四句话其中三句在第一个文档块里有证据剩下一句在第二个文档块里才有证据。如果模型只看了第一个块判断结果是“部分支持”看了两个块又变成“支持”。同一套答案接入方式不同结论完全不一样。解决思路是不要把文档简单切成固定长度块而是保留块之间的重叠和引用关系。对答案按句子粒度切分后每一句单独定位它命中的文档块再把这些与答案相关的块拼接进模型上下文。这样模型面对的是“该看的那部分证据”而不是“检索回来的全部内容”。代价是实现复杂度略高但能显著降低跨块场景的误判率。6.2 领域语料分布漂移通用训练数据上线后“失灵”Auto-GDA 这类模型最大的软肋是训练数据分布。如果团队用通用语料合成数据训练塞到垂直领域比如医疗、法律、某个公司的内部知识库里模型会开始大面积输出“部分支持”。原因是垂直领域的文档里专业术语密度高、数字多、隐含前提多模型在通用语料上学到的“证据比对模式”不足以应对。应对方案是领域微调用目标领域的小规模语料几千到几万篇文档重新跑一遍合成数据管线生成领域相关的训练样本然后在原模型基础上继续训练。不需要从头训几千条带标签的领域数据就能把误判率拉回正常水平。如果领域语料都不好拿至少要做在线 shadow 模式把线上预测结果导出来人工抽检不断沉淀坏样本。6.3 如何调阈值才不牺牲召回判别模型的标签分布天然不均衡通常“支持”占绝大部分。这时只盯着整体准确率没有意义更值得关注的是“幻觉召回率”——有多少真正无依据的回答被拦下来了。我的做法是在一个采样的验证集上分别画出三类标签的 PR 曲线然后选择一个对“不支持”类召回较高、但对“部分支持”类误判可控的阈值点。比如我会要求“不支持”类的召回至少达到 85%然后在这个约束下尽量选择让“支持”类精确率最高的阈值。这样可能有一小部分“部分支持”的答案被放过去了但至少严重幻觉不会漏。实际跑下来一个经过调阈值的判别模型在线上看到的体验比单看准确率要好很多——因为用户最无法接受的是“一本正经地胡说八道”而不是“漏了一些细节”。最后分享一个我在接入时的小技巧不要只用最终拼接的输入做单次推理可以用 2-3 个不同的文档块组合各跑一次再做投票式整合。这样虽然推理次数翻倍但因为单次推理本身已经很快总延迟增加有限换来的是对“证据选择偏差”的明显抵抗能力。Auto-GDA 把依据性验证从“不可能在线做”变成了“可以批处理做”这个能力迁移本身比单一模型的点数提升更值得关注。