自然语言推理NLI：蕴含判定、事实校验与工程落地

一个做检索增强问答的团队曾经问我明明答案就在召回的那段文档里模型却仍然一本正经地编怎么自动判断答案说的和文档说的是不是一回事我给出的方案不是再调一遍生成模型的温度而是插一个自然语言推理Natural Language InferenceNLI模块把文档原文当前提、把生成的答案当假设让模型判断这两句话是蕴含、矛盾还是无关。这类判断听起来像语义相似度但两者的落脚点完全不同相似度问的是像不像NLI 问的是能不能从前者推出后者。正是这个差别让 NLI 成了文本分类、事实验证、数据清洗、幻觉检测里一个非常耐用的基础能力。这篇就围绕何为 NLI把它拆开讲任务定义到底怎么定的、模型为什么老在看起来很简单的地方翻车、数据集的历史遗留问题如何影响你今天选模型、以及在工程里怎么用一行 pipeline 跑起来又不被标签顺序坑到。不管你是刚接触 NLP 的入门读者还是已经调过几个 checkpoint 的工程师下面这些内容都应该能直接拿去用。1. 一对前提与假设三选一的判定问题1.1 任务的形式化输入两句输出一个关系标签NLI 的输入永远是成对的两段文本。学术界习惯叫premise前提和hypothesis假设我平时在代码注释里更愿意写成premise和hypothesis而不是句子 A、句子 B因为一旦写成 A 和 B你会很容易把它当成对称的相似度任务而 NLI 是严格不对称的交换两个输入结论往往会变。小明把杯子打碎了作为前提有个杯子碎了作为假设这是蕴含反过来前提是有个杯子碎了、假设是小明把杯子打碎了就推不出来只能算中性。这个不对称性是 NLI 区别于 STS语义文本相似度的第一条分水岭也是很多新手在构造训练数据时最容易搞错的地方——他们习惯性地把句子对当成无序集合去做数据增强一交换标签全错。标准 NLI 是三分类标签中文叫法含义判定要点entailment蕴含前提为真时假设必然为真假设的信息被前提覆盖或可推出contradiction矛盾前提为真时假设必然为假两者不能同时成立neutral中性前提为真也不足以判断假设真假信息不足、话题相关但推不出值得强调的是中性的定义方式。它不是两者无关——完全无关的两句话也可以判中性但中性的严格定义是既不能推出为真也不能推出为假。这个定义方式决定了 NLI 不是简单的相关性打分它要求模型对信息是否充分有判断力。我在给业务方解释时常用一个类比前提是一份证人笔录假设是检察官的一句陈述NLI 要回答的是凭这份笔录这句话能被证实、被推翻还是无法判断。第三种情况在真实业务里占比极高而它恰恰是模型表现最差的一档。1.2 中性为什么是最难的一档如果去翻几个公开榜单的混淆矩阵你会发现一个稳定的规律蕴含和矛盾之间的混淆相对少绝大多数错误发生在中性和另外两类之间。原因不复杂。蕴含和矛盾都有明确的证据触发点——数字对不上、否定词出现、实体不匹配这些是相对局部的信号而中性要求模型做一件更难的事确认信息缺失。确认缺失是一种否定性判断模型必须知道自己不知道这在判别式模型里没有直接的监督信号只能靠大量样本间接学出来。工程上的后果是中性类的召回率往往偏低模型倾向于在有词汇重叠时勉强判蕴含。这一点在把 NLI 用作答案正确性校验时非常致命——你希望它在你没有把握的时候说中性它却给你一个 0.6 的蕴含分数于是校验形同虚设。后面第 7 节会讲怎么用阈值和校准把这个问题压下去但根子还是在任务理解上不要把 NLI 的三分类当成三个平行的类别它更像确认真 / 确认假 / 都无法确认的决策结构第三类是需要单独设计策略的。还有一个小细节值得说明某些模型的输出标签顺序是contradiction / neutral / entailment某些是entailment / neutral / contradiction还有一些微调过的模型干脆换成了LABEL_0 / LABEL_1 / LABEL_2。这不是模型能力问题是配置问题但它造成的线上事故比模型本身的精度问题多得多。第 6 节会给出检查方法。1.3 别和语义相似度、事实核查混为一谈有三个概念经常被混着说我这里一次分清。语义相似度是对称的、连续的打分输出这两句有多像NLI是不对称的、离散的分类输出能不能推出事实核查fact verification是一个更大的流水线通常包含检索证据 NLI 判定两段NLI 只是其中的判定环节。用相似度代替 NLI 是最常见的误用两句话字面高度重合但意思相反的情况太多了这款药对孕妇安全和这款药对孕妇不安全相似度能到 0.9 以上NLI 应该给矛盾。反过来会议室在三楼和要开会得往上走相似度很低但可以是蕴含。所以只要你的业务涉及结论是否被支持就别拿相似度模型凑合。2. 六类硬骨头NLI 难在哪儿2.1 词汇重叠陷阱与只看假设的捷径NLI 数据集有一个著名的统计现象假设和前提的词汇重叠度与标签强相关。重叠高多半是蕴含重叠低多半是中性或矛盾。模型很快就能学会这条捷径于是出现了一个让人尴尬的基线——只输入假设、完全不看前提在早期的一个大规模数据集上也能拿到六成以上的准确率。这个数字说明数据里存在系统性的构造偏差标注者在写假设时写蕴含句会不自觉地复用前提里的词写中性句会换词。这个坑的现代表现是模型在你的业务数据上 offline 指标很漂亮一上线遇到用不同说法表达同一件事的真实文本就崩。比如前提写该订单在签收后七日内可申请退货假设写客户有一周的后悔期人一看就是蕴含但词汇重叠极低靠捷径学出来的模型会给中性。对抗这类问题有两个手段一是在训练数据里显式加入同义改写和句式变换二是在评测集里单独切一个低重叠子集看指标不要只看总体准确率。我自己的习惯是至少准备两份验证集——一份同分布、一份换说法两者差距超过 8 个点就说明模型在吃捷径。2.2 否定、量词与作用域模型最不擅长的那一类否定词是最经典的陷阱。所有参会人员都提交了材料对有个参会人员没交材料这是矛盾但模型很容易因为参会人员材料高度重合而判蕴含。比否定更难的是量词和作用域所有、大部分、至少一个、只有这几个词的组合会形成嵌套的作用域结构每个部门都有一个负责人和有一个负责人管所有部门字面词几乎一样语义天差地别。这类错误不是靠加数据就能彻底解决的因为它涉及组合语义。实际可用的缓解办法是在 prompt 或输入格式上做显式提示如果走生成式路线把三类关系的判定要点写进指令里尤其强调注意否定词和数量词如果走判别式路线可以在微调数据里针对性构造这类对比样本。我在一个合同条款比对的小项目里做过统计加入 3000 条人工构造的否定/量词对比样本后这类样本上的准确率提升了十几个点而总体指标只动了不到 2 个点——所以一定要分类型看指标总体指标会把局部崩溃掩盖掉。2.3 常识与指代模型必须自己补的那部分有些蕴含关系需要外部常识才能建立。他把冰箱里的牛奶放进了微波炉蕴含牛奶被加热了——这中间需要微波炉加热食物这条常识。她关掉了闹钟继续睡和她起床了是矛盾需要关闹钟继续睡意味着没起床这条生活常识。NLI 模型在需要多跳常识的样本上表现明显下滑这一点在各类压力测试集上反复被验证。指代消解是另一个隐藏难点。小王告诉小李他的车被刮了他的车指谁如果假设是小李的车被刮了那这个蕴含关系取决于代词解析结果而模型在单个句对的任务设定下拿不到更多上下文。所以做长文档场景时我一般会先跑一遍指代处理或者直接把上下文窗口扩大让前提包含足够多的前文而不是指望 NLI 模型自己消歧。2.4 长前提与多句推理标准 NLI 模型的输入上限通常是 512 个 token而真实业务里的前提经常是一整段文档。超长就得截断或者分块两种做法都有代价截断可能正好把关键证据切掉分块则会产生某一块与假设矛盾、另一块与假设蕴含的冲突。这时候单条 NLI 分数没有意义必须做聚合。我的经验是把矛盾的处理优先级提到最高——只要任何一个块给出了高置信度的矛盾就整体判矛盾只有在没有矛盾的前提下才用蕴含分数的 max 或加权平均来决定是否支持。这个策略偏保守但在事实校验场景里漏判一个矛盾比多判一个中性危险得多。2.5 领域黑话与专有表达通用 NLI 模型在通用语料上训练遇到垂直领域会明显退化。医疗记录里的简写、法律条文里的但书结构、工业设备日志里的缩写都会让模型的词汇表示失效。这时候有两个选择要么用领域语料做继续预训练或微调要么退一步先用大模型把领域表达改写成通用表达再送进 NLI。后者的成本低得多我在几个项目里都是先走改写路线效果不够再考虑微调。2.6 标注本身的歧义最后一条最容易被忽略NLI 的标注一致性天生不高。同一对句子不同标注者给出的标签可能不同尤其是涉及部分支持算不算蕴含这种边界。严肃的数据集通常会用多轮标注加仲裁来控制但即便这样标注者间一致性也很难做到很高。这意味着你在业务里自建 NLI 数据时必须先写清楚标注规范明确部分支持归到哪一类、信息不足和话题无关是否合并。规范不统一训出来的模型必然摇摆。3. 数据集的偏差史决定了模型的上限3.1 大规模众包数据集的构造方式与遗留问题NLI 这一波热潮是被大规模众包数据集带起来的。典型构造流程是给标注者一张图片让他们先写一句描述作为前提再分别写出必定为真、必定为假、无法判断的三句假设。这种构造方式效率很高规模能上到五十万级但它同时埋了两个雷。第一三句假设由同一批人在同一场景下写出来风格高度一致模型可以靠句式特征区分标签而不是靠语义。第二因为假设是照着前提写的词汇重叠被人为拉高前面说的捷径问题被放大。后来的多体裁数据集做了改进把前提换成来自十种不同文体小说、政府公告、旅行指南、技术文档等的真实句子并引入跨体裁评测训练集里没出现过的体裁单独做测试。这个设定更接近真实业务也第一次把领域泛化变成了 NLI 的显式考核项。我选模型时特别看跨体裁指标因为它比同分布指标更能预测上线表现。3.2 对抗集的思路专门攻击模型的启发式既然模型爱走捷径那就造一批专门克制捷径的测试数据。对抗构造的思路大致是拿一个已经训好的模型找出它答错的样本人工改写前提或假设让句子在保留原标签的同时去掉词汇重叠线索再把这些样本加回训练集反复迭代。经过几轮迭代模型被逼着放弃表层特征转向真正的语义匹配。这类数据集的绝对分数通常比常规测试集低十几到二十个点看着吓人但它的排名更能反映模型的鲁棒性。另一类测试集专门针对词汇重叠启发式做法是把高重叠但标签为中性的样本集中起来看模型会不会误判。我建议任何要把 NLI 用于生产的人都至少跑一遍这类测试因为它直接对应你最可能遇到的失败模式。3.3 指标怎么选准确率不够要看分类型和校准只看总体准确率是自欺欺人。我在项目里固定看四组数三类各自的精确率与召回率、宏平均 F1、低重叠子集上的准确率、以及置信度的校准情况。最后一组尤其重要——如果你打算用 NLI 的概率值做下游决策比如零样本分类里比较不同标签的分数那么概率是否可靠比准确率是否高一个点重要得多。一个准确率 85% 但分数全都挤在 0.5 附近的模型在做多标签排序时会非常难用。指标反映什么什么时候必须看总体准确率综合水平汇报用不足以做决策宏平均 F1三类是否均衡中性类占比低的场景低重叠子集准确率是否吃词汇捷径输入是同义改写的业务矛盾类召回率能否抓住反例事实校验、风控校准误差概率是否可信用分数做阈值或排序4. 四条模型路线与选型对照4.1 交叉编码器精度优先的默认选择把前提和假设拼成一个序列送进编码器[CLS] premise [SEP] hypothesis [SEP]然后接分类头输出三类概率——这就是交叉编码器也是目前精度最好、部署最简单的一档。它的优点是两段文本在每一层注意力里都能互相看到交互充分对否定、指代这类需要细粒度对齐的问题更友好。缺点是没法预计算每个句对都要完整跑一次前向N 个前提配 M 个假设就是 N×M 次推理。在实际项目里只要候选集不大比如校验一条答案和一段证据交叉编码器是最省心的选择。常见可用的预训练权重在开源模型库里有不少选的时候注意看它的训练数据是三分类还是二分类以及标签顺序。我一般会先用一个中等规模的版本做基线效果不够再换大的避免一上来就背一个跑不动的模型。4.2 双塔与句子向量为召回速度做的取舍双塔把前提和假设分别编码成向量再用余弦相似度或一个小分类头做判定好处是前提侧可以离线预计算在线只算假设侧能做大规模检索。代价是失去了词级交互精度通常比交叉编码器低几个点。这条路线适合的场景是从几万个候选里粗筛然后再用交叉编码器精排。两级结构在工程上很常见第一级追求召回第二级追求精度。需要提醒的是双塔模型如果只是用通用句向量加余弦相似度严格来说不叫 NLI因为它没有学过蕴含/矛盾/中性的判定边界。要真做 NLI得用专门的三分类目标训过的双塔权重而不是拿相似度模型硬套。4.3 生成式模型做 NLI灵活但要约束把 NLI 写成指令给定前提和假设判断二者关系只输出 entailment、contradiction 或 neutral 之一。这种做法上手极快不需要训练还能顺便让模型解释理由。但它有三个不稳定点输出可能带解释导致解析失败、标签词可能写成同义词比如把 entailment 写成 yes、以及分数不可比——你拿到的是文本不是概率。解决办法有两条。第一条是约束输出只允许三个候选词用打分的方式取概率最高的那个而不是让模型自由生成。第二条是用固定模板 打分的方式复用生成模型把判断转成给三个候选续写的概率比较这样能拿到可比的数值。我在做零样本分类时更倾向第二种因为它对提示词措辞的敏感度低一些。4.4 选型对照按场景而不是按榜单路线精度延迟可预计算适合场景交叉编码器中小规模高中否证据校验、单条判定交叉编码器大规模很高高否离线批量标注、精排双塔三分类中低是海量候选粗筛生成式模型 约束打分中高高否无标注数据、需要解释通用句向量 阈值低极低是只做粗排不单独用于判定选型的判断顺序我一般是这样的先问候选集规模超过一万就走两级再问有没有标注数据没有就先上生成式模型或零样本方案做出可用版本同时开始积累标注最后才比较具体权重之间的精度差。5. 把 NLI 当工具用三个真正落地的场景5.1 零样本文本分类把标签改写成句子这是 NLI 最被低估的用法。假设你要把用户反馈分成物流问题质量问题售后态度三类但一条标注数据都没有。做法是把每条待分类文本当作前提把每个类别改写成一句自然的假设比如这条反馈在说物流配送的问题然后让 NLI 判断前提对每个假设的蕴含概率取最高的一类。这个方法的学名叫自然语言推理式零样本分类本质上是把分类问题转成了这句话是否在讲某件事的判定。效果好坏几乎完全取决于假设句怎么写。我试过一个案例把这是一条关于退款的评论改成这位用户在抱怨退款流程太慢准确率明显提升因为后者更像一个具体的、可被蕴含的陈述而不是一个抽象的主题标签。写假设的经验是用完整的陈述句、带上典型的情感或事实倾向、避免抽象名词堆砌。另外标签之间要尽量互斥如果两个假设可以同时被蕴含排序就会失去意义。这种方法还有个变体给出几个标注示例一起塞进假设里形成示例 待判的模板相当于在推理时做小样本学习。它对标签体系的适配性更好但会让输入变长注意别超长度上限。5.2 检索增强问答里的事实一致性校验回到开头那个场景。生成模型给出答案后把召回的每段证据当前提、把答案拆成若干原子陈述当假设逐条跑 NLI。判定规则可以设计成任一陈述被高置信度判为矛盾则整条答案标记为存在冲突所有陈述都被判为蕴含标记为有据可依其余标记为部分支持。这三档比一个布尔值有用得多因为它能让你区分答错了和答对了但证据不全。实践中要注意三点。第一答案要拆成原子陈述一整段话直接当前提跑模型很难给出有意义的判定因为长句里往往一半有据一半没据。第二证据要按相关性筛过再送塞一堆无关段落进去只会引入噪声让矛盾判定变得随机。第三阈值要按业务调宁可多标部分支持也不要放过矛盾前者只会降低自动化率后者会直接产出错误结论。我在一个客服问答的校验模块里把矛盾判定的阈值调得比较激进最终约有 12% 的答案被拦下来人工复核其中真正有问题的占比超过六成这个拦截效率是可以接受的。5.3 数据清洗与合成数据过滤第三个场景偏工程侧。做指令微调时合成数据里常有答案与给定材料不符的脏样本。用 NLI 批量跑一遍把材料→答案判为矛盾的样本剔掉能显著降低训练噪声。同样的思路可以用在标注质检上人工标注的一致性检查传统做法是重复标注再算一致率成本高用 NLI 先筛出模型高置信度判矛盾的样本优先复核能用更少的人力覆盖更多风险点。这个用法有一个前提材料必须是自洽的。如果原始语料本身就有矛盾信息NLI 会把正常样本误判成矛盾清洗就变成了破坏。所以在跑批之前先抽样看一眼被判矛盾的样本确认它们真的是脏数据再决定是否全量执行。6. 最小可运行实现与标签映射6.1 用 pipeline 跑通第一条判定先跑通再说。下面这段是最小实现重点是它同时把标签映射打印出来——这一步千万别省。from transformers import AutoTokenizer, AutoModelForSequenceClassification import torch model_name facebook/bart-large-mnli tok AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained(model_name) # 先确认标签顺序不同权重顺序不一样 print(model.config.id2label) premise 该商品支持签收后七天内无理由退货。 hypothesis 我可以在收到货一周内申请退货。 inputs tok(premise, hypothesis, return_tensorspt, truncationTrue, max_length512) with torch.no_grad(): logits model(**inputs).logits probs torch.softmax(logits, dim-1)[0] for i, p in enumerate(probs.tolist()): print(model.config.id2label[i], round(p, 4))运行后你大概率会看到{0: contradiction, 1: neutral, 2: entailment}这样的顺序。不要凭记忆写死probs[2]一定要从id2label里取。我见过不止一次线上事故是因为换了权重但没改索引导致矛盾被当成蕴含用而且指标监控完全没报警——因为接口返回正常只是标签错了。6.2 把判定封装成可复用的函数实际项目里不会每次都手写前向封装成函数并显式返回字典是更好的做法def nli_judge(premise, hypothesis, threshold0.5): inputs tok(premise, hypothesis, return_tensorspt, truncationTrue, max_length512) with torch.no_grad(): logits model(**inputs).logits probs torch.softmax(logits, dim-1)[0] scores {model.config.id2label[i]: float(probs[i]) for i in range(len(probs))} label max(scores, keyscores.get) # 低置信度一律降级为中性避免勉强判定 if scores[label] threshold: label neutral return label, scores那个threshold的设计是有意为之。模型在边界样本上给出的最高分经常只有 0.4 出头这时候硬取 argmax 等于强行表态。把低置信度归到中性等于把我没把握显式暴露出来下游可以据此决定是否转人工。这个策略在我做过的几个校验模块里都明显降低了误判率代价是自动化率下降属于可以接受的交换。6.3 必须检查的三个配置项拿到一个新权重我固定检查三件事顺序不能乱。第一是id2label上面说过了。第二是最大长度max_length超过模型训练时的位置编码范围会报错或静默截断而截断位置在长前提场景里直接决定结论对不对。第三是输入顺序多数权重是(premise, hypothesis)但也存在训练时反着拼的跑一个已知答案的例子验证最稳——比如前提天在下雨、假设外面是湿的应该输出蕴含如果输出矛盾多半是顺序或者标签反了。检查项错误表现验证方法标签映射三类概率正常但语义反了打印id2label用已知样例回归最大长度长文本结论莫名变中性打印 token 数观察截断位置输入顺序蕴含判成矛盾用下雨 / 外面湿这类样例试模型语言中文输入效果奇差确认权重训练语料是否含中文最后一项值得多说一句。不少高分的公开权重是在英文语料上训的直接拿来跑中文效果可能还不如一个小规模的多语言模型。中文场景下优先找在中文推理数据上微调过的权重或者至少用多语言版本别只看榜单排名。7. 上线之后才会遇到的坑校准、分块与漂移7.1 概率校准分数不是置信度判别式模型的 softmax 输出经常是过度自信的——它给你 0.95 的蕴含实际正确率可能只有 0.8。如果你用这个分数做阈值决策或者用它给多个候选排序偏差会一路传下去。校准的标准做法是在一份独立的验证集上拟合一个温度参数把 logits 除以温度后再做 softmax让输出的分布更贴近真实正确率。实现上很简单几十行代码就够但对下游决策的价值很大。判断要不要校准有个快办法把样本按置信度分桶看每桶的实际准确率和平均置信度是否接近差得远就说明需要校准。还有一个更粗糙但有效的做法不要直接用绝对阈值而是用相对比较。比如零样本分类里只在最高分比次高分高出一定幅度时才采信否则标记为不确定。这个规则不需要校准也能用鲁棒性比较好。7.2 长文档分块与冲突聚合前面提过聚合策略这里给一个具体可用的流程。把长前提按段落切成不超过 400 token 的块块之间保留一定重叠避免切断句子每块与假设跑一次 NLI得到三类的分数聚合时按优先级处理——矛盾分数超过阈值的块数大于零整体判矛盾否则看蕴含分数最高的块是否过阈值过了判蕴含都不满足判中性。重叠窗口的作用是防止关键句正好横跨切分点代价是计算量增加实际调到 50 到 80 token 的重叠就够用。这里有个容易忽略的细节分块会制造假矛盾。比如前提里有一段说该功能在旧版本中不支持另一段说新版本已支持假设是该功能受支持。单看第一块可能判矛盾但整体语义是支持的。所以聚合时最好保留块的位置信息按原文顺序看或者干脆在分块前先做一遍段落级的相关性筛选把明显不相关的段去掉。7.3 领域漂移与持续监控NLI 模型上线后性能会缓慢下降原因通常是输入分布变了——新的产品线带来了新术语用户的表达方式随季节或活动变化。监控不能只看接口成功率要定期抽样人工复核并且把模型判矛盾但人工判无问题的样本单独收集起来这批样本最有价值既暴露了模型的误判模式又能直接变成下一轮的训练数据。我自己的做法是每周抽 200 条做盲评重点看两类高置信度判矛盾的误判代价最大、以及置信度集中在 0.4 到 0.6 之间的说明模型在这些样本上没有把握往往对应新的表达方式。前者用于修正规则后者用于指导数据补充。这套流程不复杂但坚持下来能明显延缓模型衰减。最后分享一个我在多个项目里验证过的小技巧用 NLI 给标注数据做预筛但绝不用它做最终裁决。让模型把明显蕴含和明显矛盾的样本先分出来人工只复核中性类和低置信度样本标注效率能提升不少同时保留人工对高置信度样本的抽检比例防止模型把自己的偏差固化进训练数据。这个闭环跑起来之后模型和数据会一起变好比单纯换更大的权重划算得多。