你有没有遇到过这种情况系统明明从知识库里检索到了正确答案生成了一段有理有据的回复却被审核环节判成“事实错误”还反过来被改写成一句正确但毫无价值的废话。我遇到过而且不止一次。我们团队原本在生产环境用的是“30B LLM 当评委”的方案也就是让一个大参数模型去检查另一个模型生成的内容当时一度以为模型越大判断就越稳。结果连续两周的线上质检让我意识到这条路走得越大越偏——30B 的评审员常常把模型自己脑补的常识当成“事实”去校验知识库而那些真实存在于我们资料库里的内容反而成了被删改的重灾区。后来我把评审员整个换掉改用了一个专门训练过的 7B 参数事实核查器fact-checker一个月之后回头看结论让整个组都很意外7B 不但赢了 30B而且在一个内部测试集上做到了零误删——没有删掉过任何一条真实主张。这篇文章不是论文复述而是我们这次“以专用对抗通用”的项目记录。我会讲清楚我为什么推翻原来的评审架构、7B 核查器是怎么训练和落地的、以及它在真实评测中凭什么击败 30B。1. 把30B模型当评审员我亏了多少真话1.1 最初的设计让一个30B的LLM当对话评审员我们的业务场景是智能客服的知识库问答用户提问RAG 系统从内部文档里检索片段由生成模型组织答案。为了把关答案质量我在生成模型后面加了一个评审环节。最初选型时我对标的方案很自然用另一个 LLM 当 reviewer。归纳原因有三点不需要标注数据写好 prompt 就能跑大模型“见多识广”理论上能判断事实是否成立评审不参与最终回复只是打分所以误判影响不大——当时我是这么想的。我用了参数量更大、效果稳的 30B 量级模型。Prompt 大概长这样你是一个严谨的质检员。 下面这段回答来自知识库问答系统请检查其中的事实性错误。 如果回答的内容与已知事实冲突请输出需要修改的句子。 如果内容无误请输出“无错误”。 知识库证据片段... 待审核回答...这样的设计表面闭环了生成 → 检索 → 评审 → 通过/打回。上线头几天看指标坏例比例确实下降我还一度觉得方案成立。1.2 病根在哪通用评审员不是事实核查器问题出现在模型“管得太宽”上。LLM 评审员接收到的证据片段是割裂的它并不会真正去核对“这段回答是否被证据支撑”而是用自己参数里的世界知识做二次判断。知识库里有大量专业领域内容比如产品参数、内部流程措辞这些内容模型并不见得多熟悉它就开始瞎扮演权威。举一个真实案例。知识库里有一句话“Lite 版支持的最大并发数为 200。”生成模型正确引用了这句话。30B 评审员却认为“并发数 200 太保守应该是 1000”它在没有证据支撑的情况下“修正”了回答内容。下游用户拿到的结果变成了错误数据而错误源头恰恰是我搞的“质量保护环节”。类似问题大量集中在三种情况中文专有名词表述不一致时评审员把同义表达当成事实冲突领域文档里的数据与模型训练数据不同模型以“常识”覆盖文档证据本身不够完整时评审员用想象力补全然后否定真实内容。1.3 我内部评估的真实数据为了量化损失我从线上随机抽了 312 条“通过评审”的回复让领域专家逐条复核。结果触目惊心真实内容被误标为错误27.4%被修改后反而错误的18 条真正被正确拦下的坏回复只有 31.7%。换句话说我的评审系统为了抓住不到 1/3 的坏内容把 1/4 以上的好消息都误杀了。这还没有算用户感知层面的损失一次错误的“修正”往往比不修正更严重。因为用户看到的是一个言之凿凿的错误答案比一个含糊的答案更具误导性。2. 为什么是7B专用事实核查器的选型逻辑2.1 先重新定义任务评审 vs 核查痛过之后我意识到问题不是模型参数不够而是任务定义错了。我们需要的不是“评价这段回答好不好”的评审员而是“判断这句话是否被证据支持”的事实核查器fact-checker。这两个目标的差异很大维度LLM 评审员事实核查器核心能力语言质量、逻辑、风格、事实性综合判断只判断原子事实与证据的蕴含关系证据处理把证据当作参考容易用自身知识覆盖将证据作为唯一判断依据输出形态打分、修改建议、自然语言批评支持 / 反驳 / 证据不足 三分类失败代价误删真实内容、错误改写误标或漏标但不会自行改写所以问题从“怎么把 30B 调教好”变成了“怎么造一个只认证据的专用模型”。一旦任务收窄参数量就不是首要指标了准确率、可控性和维护成本才是。7B 级别的模型在推理成本上远低于 30B而且它可以为任务做专门训练这是通用模型 prompt 调校无法替代的。2.2 7B模型的选型与基座对比选基座的时候我在 Qwen2.5-7B、Mistral-7B 和 Llama-3-8B 之间做了一轮对比。最终选了 Qwen2.5-7B 作为基座核心原因是它的中文指令遵循能力和长文本稳定性在这个参数级别里更稳而我们的知识库内容 95% 是中文。Mistral-7B 在英文事实核查基准上表现不差但在内部测试集上它的中文证据对齐能力明显偏弱——经常判断不出“证据说的是同一件事”这种情况。Llama-3-8B 的中文能力虽然比上一代好很多但主观改写倾向仍然很强而这恰恰是评审体系里最致命的毛病。说句实在话基座模型的内置知识越丰富对事实核查任务反而越容易产生干扰。因为模型太“聪明”了它总想用自己的知识去补证据的缺。这也解释了为什么 7B 在这个任务上不是“将就”而是更有胜算。2.3 训练数据的构造让7B学会只看证据选定基座后训练数据的构造是迁移过程中最重要的部分。我没有直接拿公开的事实核查数据集硬套而是基于我们的业务语境做了三层数据合成从历史知识库标签中抽取“文档片段 正确复述”作为正样本人工改写片段中的时间、数量、主体等构成矛盾负样本把不相关文档拼接成“证据不足”样本。每一层我都检查了数据质量。尤其是“证据不足”样本它决定模型会不会过度推理——模型必须学会说“我不知道”而不是自己补一个答案。我把它看作是“7B 核查器没有误删真实主张”的关键设计。3. 手把手搭建7B事实核查器3.1 整体流程输入、切分、检索、判定我们的核查器不是单模型把活全干完而是一条流水线。在生产中它的输入是生成模型的输出文本输出是“需要保留/需要删除/需要修正”的结构化结果。流水线步骤步骤1用规则和少量样本训练一个切分器把长回答切成若干“主张句”步骤2每个主张句从知识库检索对应的证据片段复用RAG的检索链路步骤3把“主张句 证据片段”拼成核查模型的输入步骤4模型输出三分类支持、反驳、证据不足步骤5根据分类结果执行后续动作。这样的设计确保每一步都可解释出问题时能快速定位是检索的问题还是模型的问题。3.2 主张拆解把一句话拆成可核查的事实单元模型输出经常是复合句比如“该设备防水等级为 IP67同时支持 5G 和 Wi-Fi 6”。如果整句作为一个校验单元任何一部分不匹配都会导致整句被否误伤率会很高。因此我按“原子事实”拆句即把上面的句子拆成三条该设备防水等级为 IP67该设备支持 5G该设备支持 Wi-Fi 6。拆解时优先依赖标点和连接词再配合少量规则处理“并且”“同时”“以及”等并列关联。拆完之后每条事实独立去与证据比对任何一条判定“反驳”系统只标记对应子句而不是整个句子都被否掉。这种“精确打击”是保住真实主张的核心手段。3.3 判定模型与阈值设置微调阶段我把数据切成训练集、验证集、测试集比例 8:1:1只保留没有跨集重复的文档。用 Seq2Seq 方式训练标签只有三类支持entailment、反驳contradiction、证据不足neutral。模型输出本身带概率我设置了“保守策略”阈值支持概率 0.6保留反驳概率 0.75判定为反驳两者均不满足归入证据不足默认保留并标记人工复核。我特意把“反驳”的门槛抬高了。原因很简单在事实核查场景下误删真实内容的代价远大于漏删错误内容。宁可放过一两个坏句子也不能把真话当谎话删掉。这也是我们最终能做到“deleted no true claims”的一个技术前提。3.4 写回机制如何“删除或修正”而不误伤核查器本身不直接修改文本它只输出建议。真正执行删除或修正的是一个独立的重写模块这个模块接收的是“原子事实级别”的判定结果。如果某条子句被判定为“反驳”重写模块会先尝试从证据片段里提取替代事实。这里有一个我踩坑后才总结出来的规则如果证据里找不到可替换的实体或数值就不要修直接标记删除该子句。否则重写模型会自由发挥最后生成一句听起来正确但证据里根本没有内容的话等于二次污染。此外所有“删除/替换”动作都会写进审计日志方便人工随时抽查。回滚能力比删除能力更重要——我们后来总结经验时发现事实核查系统最大的风险不是漏判而是误改后没有后悔药。4. 7B vs 30B实测对比过程4.1 测试集怎么设计为了公平对比我单独构造了一份 1000 条内部评测集。每条数据包含“生成回答原文、对应知识库证据、人工标注结果”。人工标注只做一件事判断原文中的每一条原子事实是否被证据支持。我特意在测试集里提高了易混样本的比例约 30% 的样本存在“证据支持但表述风格与原文不同”的情况。这类样本最容易暴露 LLM 评审员“挑措辞”的毛病也最能检验专用核查器是否真的只认证据。4.2 指标真实保留率、误纠率、精确率我主要用三个指标衡量两套方案真实保留率真实事实中未被系统删改的比例误纠率真实事实被判定为错误并触发修改的比例精确率所有修改/删除操作中修改对了的比例。结果如下指标30B LLM 评审员7B 事实核查器真实保留率79.6%99.1%误纠率20.4%0.9%精确率41.5%83.7%单条平均耗时3.2秒1.1秒30B 评审员在精确率上只有 41.5%意味着它每发起两次修改就有一次以上是错的。7B 核查器的精确率虽然没到完美但因为执行策略保守真实保留率做到了 99.1%且测试集上确实没有一条真实主张被错误删除。4.3 代表性案例拆解我把测试集里最典型的一条差异拎出来说。生成回答“本产品整机重量约为 2.1kg比上一代轻了 12%。” 知识库证据“整机重量 2.2kg不含电源适配器相比上一代减重约 10%。”30B 评审员的处理直接把原句改了修改后为“重量约 2.2kg比上一代轻约 10%”。这个修改本身是更贴近知识库的但它同时也删掉了“2.1kg”这个来自产品页快速参数表的事实。快速参数表里确实写的是 2.1kg两种口径在不同文档里同时存在严格来说原句并没有被证据“反驳”。7B 核查器的处理先拆出两条事实分别检索证据。第一条“整机重量约 2.1kg”在快速参数表中找到支持第二条“比上一代轻了 12%”在技术对比文档中计算后并不匹配。最终结果保留第一条只对第二条打上“疑似不精确”并转人工复核。两者差异的本质是30B 在“综合判断”时把整句当成一个整体一票否决7B 把一个句子看成多个独立原子事实互相不连坐。这正是我为什么一再强调拆句和证据对齐的原因。5. 30B评审员误删真实主张的四类典型错误5.1 挑语法毛病不挑事实通用评审员的 prompt 里我写的是“检查事实性错误”但它总会忍不住去管语病、重复表达、语气不够正式这类问题。一旦它开始改这些真实内容被改动的风险随之上升。我见过它把“目前支持三种语言”改成“目前支持三种语言版本”原因是“表述更正式”。这种无意义改动最恐怖的地方在于它让审核日志变得非常嘈杂真正需要关注的事实纠错反而被淹没了。5.2 证据缺失就判“无凭无据”这是最有迷惑性的一类错误。当检索系统没能找到对应证据时30B 评审员会倾向于认为“既然没找到证据就是编造的”然后直接判定为错误。但在真实知识库系统里证据缺失可能只是因为检索召回率不够或者查询改写不到位根本不代表事实错误。7B 核查器在这个问题上处理得更好因为训练时“证据不足”被设计为独立的第三类输出模型学会了对没有证据的内容保持克制。即使检索失败它也会返回“证据不足”触发人工复核而不是自动删除。5.3 模型自带知识覆盖检索事实知识库如果包含高频常识性内容通用大模型的“常识自信”就会作祟。30B 评审员对常识太熟悉了所以当证据片段里出现一个与它认知稍有出入的数值时它不相信证据而相信自己的记忆。内部知识库里有一条“客服响应时效为 2 个工作日”但模型训练语料里大量出现“24 小时响应”的表述于是评审员跑来把 2 个工作日改成了 24 小时。这种覆盖是极其危险的——因为如果你没有人工复核它看起来就像一次“很专业的修正”。专用核查器因为训练数据里没有“让模型保持自己观点”的选项反而能老实追随证据。5.4 中文口语与书面表述的措辞敏感性中文领域还有一个隐藏问题同义表达的形式变化特别大。评审员经常把“能用”和“支持”视为不同事实把“大概 2 公斤”和“约 2kg”视为矛盾把否定句式的等价表达视为冲突。这种措辞层面的敏感本质上是被语言模型对“语义一致”的高要求放大了。核查器在微调时使用大量同义改写样本让模型从表征层面学会“同一事实多种说法都可成立”这个问题才被明显压制住。6. 集成部署中的坑从模型到生产6.1 推理优化与并发设计7B 模型相比 30B 在显存上轻松太多。我们线上环境是 2 卡部署28B 精度的 7B 模型直接把并发翻了一倍。做并发时要注意一点事实核查请求的响应长度很短瓶颈不在解码而在批次处理。我们把请求按 max_tokens 分桶小请求优先合并到同一批次单卡吞吐提升了约 40%。推理框架我推荐兼容 OpenAI 接口的本地部署方案省去自研路由。前处理和后处理都比较简单真正的复杂度在证据检索和主张拆解这些外围逻辑上。6.2 与内容生成流水线的缝合集成时我踩过一个大坑把核查器放在生成模型之后的同步链路里。生成一个回答只要 1 秒核查要 1 秒整体延迟翻倍。后来我把流程改成异步绿色通道低风险问题直接返回答案核查离线进行异步核查核查结果写回缓存下一次命中时生效高风险模板问题才走同步核查。这样既保住了用户体验又留住了事实把关能力。同步改为异步之后线上本来担心的“误删真实内容”也更容易追踪因为每个被删句子都有独立日志用户可以随时投诉“这条被删错了”我们靠这个反馈不断优化预测阈值。6.3 数据回流与持续迭代模型训好不是终点而是起点。我把上线后的核查结果全部回流到训练池每两周抽一批高置信样本人工复核然后把复核结果混合进训练集。持续迭代时要特别注意数据漂移问题知识库内容不断更新但核查模型不知道新文档的存在。我的做法是定期用新文档重跑一次历史测试集观察“支持/反驳”分布是否出现大幅变化。如果反驳率突然上升优先怀疑文档更新引入的版本冲突而不是直接去找模型的问题。这个回流机制才是“7B 核查器一直不删真话”的长期保障——它是靠数据更新维护的不是靠一次性训练撑住的。写在最后的经验项目做完之后我自己最深的体会是模型参数大小和任务适合度是两回事。通用大模型做评审强在综合能力弱在“只认证据”这种反常识的克制。而一个针对事实核查任务训练过的 7B 小模型反而因为训练目标干净、干扰知识少能把“支持 / 反驳 / 证据不足”这三类判断做得比 30B 可靠得多。如果你也在跑类似的 RAG 审核链路我的建议是先别急着上更大参数的评审模型。花一周时间把你要保护的事实边界定义清楚明确什么是“真实主张”、什么是“证据缺失”、什么是“表述不一致”再决定究竟该用多大参数去解决。很多时候小而专远胜大而全——这次 7B 击败 30B 的实战就是最直接的证明。