做文本核验这行被问得最多的一类问题是“这两句话到底算不算一个意思”。有人拿它做检索结果校验有人拿它做问答答案兜底还有人拿它做内容发布的合规预检。刚接触的人通常第一反应是丢给相似度模型算个余弦结果立刻翻车——反义句相似度能到0.9否定句相似度0.95加个“不”字语义完全反转向量却几乎没动。这时候就需要把NLI自然语言推理搬出来了。NLI做的事情非常朴素给定一句前提premise和一句假设hypothesis判断假设是被前提蕴含、被前提否定还是跟前提没关系。输出只有三个标签任务定义简单到一句话就能讲完但它的难点、坑点和落地价值,远不是一句“三分类”能概括的。这篇东西面向的是想真正把NLI跑起来的人——不管你是刚接触NLP、准备拿它做第一个项目还是已经在业务里踩过几轮坑、想找找别人是怎么处理的下面这些内容都能直接抄或直接对照排查。1. NLI到底在判断什么任务定义与标签空间的本质1.1 三个标签不是平等地位的三分类先把这个任务的输入输出钉死。NLI的输入是一对句子通常记作 P前提和 H假设输出是一个标签常见三分类定义标签英文含义例子蕴含entailment从P能推出H成立P桌上放着两个红苹果。H桌上有水果。矛盾contradiction从P能推出H不成立P桌上放着两个红苹果。H桌上没有任何水果。中性neutralP既不支持也不否定HP桌上放着两个红苹果。H苹果是刚摘的。很多人第一次看这个表会觉得简单但实际动手就会发现问题这三个标签在逻辑上并不对称。蕴含和矛盾都是“有确定方向”的关系中性则是一个“信息不足”的兜底类别。这带来一个很现实的后果——中性的判定边界是模糊的它本质上是一个“开放世界”的判断而蕴含和矛盾是“封闭世界”的判断。模型在训练时中性样本的梯度信号会明显弱于另外两类因为中性样本内部差异极大可以是话题完全不同也可以是话题高度相关但缺一个关键事实。我做过一个统计在一个公开英文NLI基准的训练集上中性类样本的词汇重叠度分布前提与假设的word overlap比蕴含类低了将近一半方差却大得多。这意味着模型如果偷懒很容易学到“词汇重叠高就是蕴含/矛盾重叠低就是中性”这种表面规则在训练集上准确率刷得很高实际用起来一塌糊涂。所以工程上第一件要做的事是不要把它当成一个普通的均衡三分类。损失函数上可以考虑类别权重或者在采样时对中性类做适度上采样更重要的是评估阶段一定要分开看三类的F1只看整体准确率会掩盖掉最致命的那一类问题。1.2 “中性”才是最考验功力的那一类为什么中性这么难因为它要求模型区分“不知道”和“不成立”。这两件事在分布式表示里非常接近——都是前提没有给足信息区别只在于一个是信息缺失一个是信息冲突。模型需要判断的是“缺什么”而不是“有什么”这对表征能力的要求高出一截。举个我实际遇到的例子。前提是“这台设备的保修期是两年”假设是“这台设备的保修期是三年”。这是典型矛盾因为保修期是一个单值属性两年和三年互斥。但如果前提是“这台设备支持有线连接”假设是“这台设备支持无线连接”这就未必是矛盾——很多设备两种都支持正确的标签应该是中性。模型要能识别出“支持有线”和“支持无线”不是互斥关系这需要常识而常识恰恰是纯文本训练最难补的部分。实操上的一个有效手段是在训练数据里显式增加“属性互斥 vs 属性可共存”的对比样本。具体做法不需要人工标注太多拿同一批实体构造属性对标注哪些属性是单值互斥的如生效日期、编号、型号哪些是多值可共存的如支持的功能、包含的配件。用规则生成一批弱标注样本混进训练集实测能把中性类的召回提升几个点。这个技巧的核心逻辑是把“常识”从模型的隐式学习里拉出来变成显式的数据分布。1.3 一个容易被忽略的前提方向性NLI是有方向的。P蕴含H不代表H蕴含P。这个性质听起来废话但在实际工程里经常被搞混尤其是在做批量校验的时候。举个真实场景你的系统要校验“用户提问”和“知识库条目”是否匹配。如果你把知识库条目当前提、用户提问当假设模型判蕴含含义是“这条知识能回答这个问题”反过来把用户提问当前提、知识库条目当假设判蕴含的含义就变成了“这个问题能推出这条知识”逻辑上完全是另一回事而且通常不成立。我见过一个项目在这里翻车离线评估时用A方向线上推理时数据处理管道的字段顺序反了指标直接掉了一大截排查了两天才定位到是列名顺序问题。所以工程上建议在代码里把字段名写死成premise和hypothesis不要用text_a/text_b这种模糊命名并且在数据加载层加一个断言检查输入长度分布是否符合预期方向——前提通常比假设长如果反过来占了多数多半是字段串了。2. 数据集与评测基准你训练出来的模型到底在和谁比2.1 数据构建方式决定了模型能学到什么公开的NLI数据集主流构建方式有两种理解这一点非常关键因为它直接决定了你训出来的模型擅长什么、不擅长什么。第一种是人工撰写假设。给标注员一段前提通常来自图片描述、百科段落、新闻让他们自己写三种假设一定能推出来的、一定推不出来的、推不出来的。这种方式构建的数据假设句往往比较自然但存在一个系统性偏差——标注员写“矛盾”的假设时倾向于直接否定前提里的某个词导致矛盾类样本和否定词高度相关写“蕴含”时倾向于做同义改写或抽取子集导致蕴含类和词汇重叠高度相关。这个偏差在整个领域里被讨论了很多年是模型“作弊”的主要来源。第二种是自然发生的句子对。从已有的文本资源里抽取成对的句子由人工标注关系。这类数据分布更接近真实业务但标注成本高规模通常小得多而且中性类占比会明显偏高。实操建议如果你的业务文本和公开数据集的领域差异大比如你做的是工单、合同、医疗记录公开数据集只能当预训练信号用不能当最终评估集。正确做法是从自己的业务里抽300到500对做人工标注作为内部测试集每次模型迭代都在这个集合上跑。这个集合不用大但必须固定且标注规范要提前写清楚——尤其是中性的判定标准必须给出明确的“信息不足”判定规则否则不同标注员之间的一致性会低到没法用。2.2 对抗数据集的意义把“捷径”堵死后来社区陆续发布了一批对抗性质的NLI数据集专门针对上面说的捷径构造样本。典型的构造手法包括词汇重叠很高但标签是中性比如前提和假设共享大量实体词但假设引入了一个前提没提的属性词汇重叠很低但标签是蕴含用完全不同的表达说同一件事加入大量否定、量词、条件句、比较级这些是模型最容易翻车的地方引入需要数字推理、时间推理、常识推理的样本这些数据集刚出来的时候同一个模型在常规测试集上能到九十多分在对抗集上直接掉到六十几分。这个落差非常值得警惕——它说明常规指标严重高估了模型的真实能力。我自己的做法是内部测试集必须包含至少20%的“反捷径”样本。构造方法不难从业务数据里挑那些字面像但语义不像的、字面不像但语义一样的各凑一批。这批样本在模型迭代时的参考价值比几千条普通样本都大。2.3 评测时的三个必查项跑完评估别只看一个数字下面三项必须查。第一项是标签分布。如果你的测试集里蕴含类占70%那模型全predict成蕴含也能拿到70%准确率。这时候要算macro-F1或者直接看每一类的召回。第二项是只用假设的基线hypothesis-only baseline。把前提去掉只喂假设给模型看能拿多少分。这个基线在很多数据集上能到六成以上原因是假设句的措辞本身带标签信号——比如带“not”“no”的假设大概率是矛盾带“also”“too”的假设大概率是蕴含。如果你的完整模型只比这个基线高几个点说明模型压根没在认真读前提这时候要回头检查数据构造和损失设计而不是继续调参。第三项是混淆矩阵。重点看两格中性被判成蕴含的比例以及蕴含被判成中性的比例。前者高说明模型过于宽松后者高说明模型过于保守。这两个比例决定了你在业务里该怎么设置置信度阈值——如果中性被判蕴含的比例高那在“蕴含”这个结论上就要加更严格的阈值宁可放过不可错杀。3. 建模路线的演进与选型逻辑3.1 早期双塔结构为什么退场早几年主流的做法是双塔siamese结构前提和假设分别过一个编码器得到两个句向量然后拼接、相减、相乘送进一个分类头。这个结构有个明显优势——两句之间没有早期交互编码可以缓存推理快。但它在NLI任务上有一个结构性缺陷交互发生得太晚。NLI需要的往往是对齐级别的信息——假设里的某个词到底对应前提里的哪个词这个对齐必须在编码过程中就建立起来。双塔结构里两句各自编码成定长向量对齐信息在池化那一步就损失掉了后面再拼接也补不回来。我做过对比实验同一个预训练编码器双塔结构在常规测试集上比交叉编码结构低了三到五个点在对抗集上差距拉大到十个点以上。这个差距在业务里是完全不可接受的所以现在做NLI几乎默认用交叉编码。3.2 交叉编码成为主流的原因与代价交叉编码cross-encoder的做法很直接把前提和假设拼成一个序列中间加分隔符整体送进编码器取特殊标记位置的输出接分类头。这样每一层注意力都能同时看到两句对齐信息在浅层就建立起来了。代价是推理成本。双塔可以把两句分别编码一次之后任意配对只需要算相似度交叉编码每换一个配对就要完整跑一次前向批量推理时显存和算力消耗都大得多。这个代价在离线批处理场景可以接受在在线低延迟场景就要认真算账了。我按实际压测算过一个基础规模的编码器单条前向在单张消费级卡上大约十几毫秒batch 32的情况下吞吐能到每秒几百对。如果你的业务是每秒要校验上千对那就得考虑降级方案——要么用小一号的模型加蒸馏要么用双塔做粗筛、交叉编码做精排的两阶段方案。这个两阶段思路我下面会展开。3.3 模型选型对照与参数权衡选型上不要一上来就追最大的模型。NLI任务的特点是标签空间小、单句长度中等中等规模的编码器通常就够用。下面是我在实际项目里总结的对照表数据来自我自己的测试环境仅供量级参考方案类型典型规模单条延迟量级相对效果适合场景小型编码器微调千万参数级极低及格线高吞吐粗筛、端侧基础编码器微调一亿参数级低良好绝大多数在线业务大型编码器微调三亿参数级中优秀离线批处理、精度优先超大模型微调或蒸馏十亿参数级高最优但边际收益小有充足算力且精度卡得很死我的经验结论是从基础规模起步把数据处理和评估体系做扎实收益远大于换更大模型。很多项目一开始就上大模型结果测试集本身有标注噪声指标上去了也不知道是真的强还是过拟合了测试集。3.4 双塔加精排的两阶段方案如果延迟确实是硬约束两阶段是值得认真考虑的。第一阶段用双塔或向量检索做召回把候选从几万条压到几十条第二阶段用交叉编码对这几百对做精判。这里有个细节容易被忽略第一阶段的召回目标不是准是全。你要保证真正的蕴含对不会被漏掉所以第一阶段的阈值要设得宽松宁可多召回。实操上我会把第一阶段的相似度阈值卡在明显偏低的水平然后看第二阶段的输入规模能不能压住延迟。如果压不住就调第一阶段的召回数量而不是调高阈值。另一个细节是两阶段的分数不能直接混用。第一阶段的相似度和第二阶段的蕴含概率是两个尺度混在一起做加权会引入难以解释的偏差。我的做法是只用第二阶段做最终判定第一阶段纯粹当过滤器用不参与决策。4. 从零跑通一个NLI基线数据、训练、评估全流程4.1 数据格式与预处理标准格式就是三列前提、假设、标签。用表格或JSONL都行我习惯用JSONL一行一条字段名固定{premise: 这台设备的保修期是两年。, hypothesis: 这台设备的保修期超过一年。, label: entailment} {premise: 这台设备的保修期是两年。, hypothesis: 这台设备的保修期是五年。, label: contradiction} {premise: 这台设备的保修期是两年。, hypothesis: 这台设备是去年生产的。, label: neutral}预处理上有几个必须做的动作顺序不能乱清理不可见字符。中文文本里经常混入全角空格、零宽字符、软连字符这些在分词后会产生大量噪声token直接影响注意力分布。用正则统一清洗。长度截断策略。不要简单地从尾部截断。NLI的信息往往在句子的后半段因为后半段常带修饰和限定我倾向于对前提做头尾各保留一半的截断对假设做保留头部的截断。前提长度设到190个token左右假设设到60两者拼起来不超过最大长度。标签映射表固化。写成常量字典训练和推理共用一份避免两边映射顺序不一致导致标签错位——这个错误极其隐蔽指标不会报错但结果是全错的。这里有个坑要说一下不要把前提和假设的分隔符和普通标点混用。如果句子本身可能含分隔符要在拼接前先做转义或替换否则序列切分会错位。4.2 训练脚本与关键超参下面是一个可以直接改改就跑的训练骨架用主流的序列分类接口import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification from transformers import TrainingArguments, Trainer from datasets import load_dataset MODEL_NAME your-encoder-checkpoint LABELS [entailment, neutral, contradiction] LABEL2ID {l: i for i, l in enumerate(LABELS)} tokenizer AutoTokenizer.from_pretrained(MODEL_NAME) model AutoModelForSequenceClassification.from_pretrained( MODEL_NAME, num_labels3, id2label{i: l for l, i in LABEL2ID.items()}, label2idLABEL2ID, ) def preprocess(examples): return tokenizer( examples[premise], examples[hypothesis], truncationonly_first, max_length256, paddingmax_length, ) dataset load_dataset(json, data_files{train: train.jsonl, valid: valid.jsonl}) encoded dataset.map(preprocess, batchedTrue) encoded encoded.map(lambda e: {labels: [LABEL2ID[x] for x in e[label]]}, batchedTrue) args TrainingArguments( output_dir./nli-out, learning_rate2e-5, per_device_train_batch_size32, per_device_eval_batch_size64, num_train_epochs4, warmup_ratio0.1, weight_decay0.01, eval_strategyepoch, save_strategyepoch, load_best_model_at_endTrue, metric_for_best_modelmacro_f1, greater_is_betterTrue, fp16torch.cuda.is_available(), ) trainer Trainer( modelmodel, argsargs, train_datasetencoded[train], eval_datasetencoded[valid], ) trainer.train()超参上有几个值的逻辑值得说清楚。学习率设2e-5是基于基础规模编码器的经验值太大容易在第一个epoch就把预训练学到的语言知识冲掉表现为loss前几百步剧烈震荡太小则收敛慢四五个epoch都到不了平台期。如果换成更大的模型这个值要往下调到1e-5甚至更低。batch size设32是显存和梯度稳定性的折中。如果显存不够用梯度累积凑等效batch不要把batch降到8以下——小batch下批归一化和dropout的随机性会让训练曲线抖得没法判断。epoch设4是因为NLI数据集通常不大训太多轮必然过拟合。判断过拟合的信号很直接训练loss继续降验证集macro-F1开始掉这时候立刻停。用load_best_model_at_endTrue配合按macro-F1选最优比按loss选更靠谱因为loss对类别不平衡不敏感。truncationonly_first这个参数很多人会忽略。它的作用是只在第一个序列前提上截断保证假设句完整。因为假设句通常短且信息密度高截掉假设的代价比截掉前提大得多。4.3 训练过程监控与早停训练的时候不要只盯着loss。我一般会同时看四个数训练loss、验证loss、验证macro-F1、以及每一类的F1。第一个epoch结束时如果验证macro-F1还在随机水平附近三分类大概0.33说明学习率太大或者数据有问题直接停掉查数据。正常情况下第一个epoch末应该能到0.7以上。如果验证loss在第二个epoch开始上升而训练loss还在降这是过拟合的典型信号。这时候不要急着加正则先看看训练集和验证集的标签分布是否一致——分布不一致导致的“假过拟合”很常见实际是数据切分的问题。早停的耐心值我通常设2也就是连续两个epoch没提升就停。因为NLI任务收敛快超过两个epoch没提升基本就是到顶了。还有一个实用技巧在每个epoch结束后把验证集上置信度最高的错例打印出来看。这批样本信息量最大往往能直接看出模型学到了什么错误的规则。我有一次就是通过这些错例发现模型在靠“假设句长度”做判断——短假设判蕴含长假设判矛盾原因是训练数据里矛盾类样本平均长了一截。这个问题只看指标是发现不了的。4.4 推理封装与批量处理推理侧要处理的核心问题是批量和阈值。封装的时候注意三点import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification torch.inference_mode() def predict_pairs(pairs, model, tokenizer, batch_size64, max_length256): results [] for i in range(0, len(pairs), batch_size): batch pairs[i:i batch_size] enc tokenizer( [p for p, _ in batch], [h for _, h in batch], truncationonly_first, max_lengthmax_length, paddingTrue, return_tensorspt, ).to(model.device) logits model(**enc).logits probs torch.softmax(logits, dim-1).cpu() for (p, h), prob in zip(batch, probs): pred_id int(prob.argmax()) results.append({ premise: p, hypothesis: h, label: model.config.id2label[pred_id], confidence: float(prob[pred_id]), probs: prob.tolist(), }) return results第一不要把置信度当准确率用。模型输出的softmax概率普遍偏高尤其在分布外样本上会出现“错得很自信”的情况。我的做法是在验证集上做温度缩放校准或者干脆按分位数定阈值——取验证集上准确率达到某个目标时的最低置信度作为上线阈值。第二推理时的padding策略要和训练一致。训练用了固定长度padding推理用了动态padding看起来没问题但如果模型里有位置相关的操作分布会偏移。稳妥做法是两者统一或者至少在验证集上验证过动态padding不掉点。第三批量里的长度差异会拖慢速度。按长度排序后再分批能让每个batch内的序列长度接近减少padding浪费。实测在长度分布差异大的数据上这个处理能提速三成以上。5. 落地场景NLI不止是做一个分类器5.1 事实一致性校验这是NLI目前最有价值的落地场景。做法是把“证据段落”当前提把“生成出来的陈述”当假设判蕴含就认为是事实一致的判矛盾就认为有冲突判中性则认为证据不足、无法确认。这里的关键设计是中性怎么处理。很多团队直接把中性当失败这是不对的。中性意味着“当前证据里找不到支持或反驳的信息”正确做法是走补充检索流程而不是直接判错。我的做法是三路分流蕴含直接放行矛盾直接拦截并记录冲突点中性则触发二次检索或降级到人工审核。还有个细节证据段落通常很长远超模型最大长度。这时候不要一次性截断而是按句子切块逐块做NLI取最强信号。判定规则是任意一块判矛盾则整体判矛盾全部块都判中性才判中性至少一块判蕴含且无矛盾块判蕴含。这个规则看起来粗糙但实测比把长文档直接截断喂给模型稳得多。5.2 内容重复与矛盾检测同一批内容里做自洽性检查NLI比向量相似度靠谱。具体做法是把任意两段内容互为正反两对——A当前提B当假设B当前提A当假设——两个方向都判蕴含才算“表述重复”一个方向蕴含、另一个方向不蕴含说明是包含关系两个方向都判矛盾才是真正的冲突。为什么要双向因为单向蕴含可能只是子集关系。比如A是“设备支持有线、无线、蓝牙三种连接”B是“设备支持无线连接”A蕴含B但B不蕴含A这两段不算重复只能算层级关系。把它当重复去重会丢信息。我实际用这个方案做过一轮内容库清洗几万条内容里找出了几十组真正的冲突对都是人工抽检几乎不可能覆盖到的长尾。这个过程里最有价值的是把置信度分布画出来看——冲突对通常置信度很高模型很确定而“疑似中性”的大量样本恰恰是最需要人工过一遍的。5.3 标注辅助与主动学习这个用法比较隐蔽但很实用。你有一批待标注的文本对先用模型跑一遍然后按策略挑选样本给人工模型判蕴含/矛盾且置信度高的人工只做抽检比如抽10%确认没有系统性问题模型判中性且置信度高的直接进入“疑似无关”池除非业务需要否则不标模型置信度在中间区间的全部送人工这个策略能把人工标注量压掉一大半同时保证标出来的数据分布对模型提升最大。我在一个项目里用这个思路标注预算没变的情况下两轮迭代就把内部测试集上的macro-F1提了六七个点——因为早期标注预算都花在了模型最困惑的地方。要注意的是别让模型自己给自己造闭环。高置信度的伪标注可以进训练集但比例不能太高我一般控制在总训练量的三成以内而且必须和真实标注混在一起打散否则模型会越来越自信地犯同一个错。6. 常见问题与排查实录6.1 训练集准确率接近满分线上效果却很差这个现象太普遍了原因基本跑不出三个。第一个是数据泄漏。检查训练集和验证集是否有重复样本或者是否有同一前提派生出多条假设的情况——这种情况会让验证指标虚高因为模型见过前提。排查方法很简单对训练集的前提做哈希去重然后统计验证集的前提有多少在训练集里出现过。如果比例超过5%切分方式就要重做按前提分组切分而不是按样本随机切分。第二个是表面线索依赖。前面说的词汇重叠、否定词、句长这些捷径在训练集上有效到线上分布变了就失效。排查方法是训练一个只用假设的模型看它准确率有多高。如果只比完整模型低一点点说明前提根本没被有效利用。第三个是领域漂移。公开数据集是百科和新闻风格你的业务是工单和口语句式长度、术语密度、标点习惯全不一样。这种情况只能靠领域内标注数据微调没有别的捷径。我的经验是哪怕只有两三千条领域内样本微调后的提升也比在公开数据上继续堆训练量明显得多。6.2 模型对否定词不敏感这是NLI的经典问题。表现是前提说“支持”假设说“不支持”模型还是判蕴含。原因是训练数据里矛盾类样本的否定表达模式比较单一模型没学到否定作用的范围。解法有两层。数据层做否定增强对训练集里的蕴含样本自动生成对应的矛盾样本方法是在关键谓词前插入否定词并同步调整标签。这一步要注意作用域不能无脑加“不”字——得先识别出谓词短语在正确位置插入。模型层可以在训练时加入对比学习信号同一条前提配一个蕴含假设和一个矛盾假设让模型的两个输出在表示空间里拉开距离。这个技巧实现不复杂但需要改训练循环得自己写loss不能直接用现成的Trainer。还有一个更简单的排查手段单独构造一个小测试集全部是“差一个否定词”的对子跑一下看准确率。如果低于八成说明这个问题在你的模型上确实存在值得专门处理。6.3 长前提与多句假设怎么处理单句对单句是理想情况实际业务里前提经常是整段假设往往是两三句话。直接拼接受限于最大长度效果会崩。分三种情况处理。前提长、假设短按句切前提逐块做NLI按前面说的“矛盾优先”规则聚合。前提短、假设长把假设拆成多个子命题逐个验证全部蕴含才算整体蕴含——这在事实校验里非常常见因为生成内容经常一段话里混着好几个事实点。两者都长先做句子级对齐找出最相关的句子对再做判定不要全量做笛卡尔积成本扛不住。这里有个容易忽略的点假设是复合句时标签的合成规则不是简单的“与”。比如假设是“设备支持无线并且保修三年”如果前提只支持了前者、对后者沉默整体标签应该是中性而不是矛盾。合成规则要按“是否存在矛盾”和“是否全部被支持”两个维度来定建议直接写成一个明确的状态机别靠直觉。6.4 常见问题速查表现象最可能原因快速验证处理方向验证指标虚高线上崩前提级数据泄漏统计验证集前提在训练集的命中率按前提分组切分前提似乎没被使用表面线索捷径跑假设单输入基线构造反捷径样本加对抗训练否定句判错否定作用域学习不足构造否定最小对测试集否定增强 对比损失中性类召回极低类别不平衡或标注规范不清看混淆矩阵中性行上采样 重写标注规范长文本效果差截断丢失关键信息对比截断前后指标分块 聚合规则推理延迟超标交叉编码逐对前向压测单条延迟两阶段方案或模型蒸馏置信度不可信未做概率校准画可靠性曲线温度缩放或分位数定阈值换领域后全线掉点领域分布偏移领域内小测试集领域数据微调6.5 几条踩过坑才明白的经验第一条标注规范比模型重要。同一个任务标注规范写得含糊标出来的数据噪声能到两成以上这种情况下无论怎么调模型天花板都被锁死了。规范里必须给出中性判定的明确边界最好配十个典型例子和五个边界例子。第二条别急着上大模型。我见过太多项目卡点根本不在模型容量而在数据质量和评估体系。先把内部测试集建起来把混淆矩阵看清楚再决定要不要换更大的模型。第三条阈值一定要用验证集定不能用训练集。训练集上的置信度分布和线上完全不同用训练集定的阈值上线必然失准。第四条保留原始概率别只存标签。业务侧后续要做分流、要做人工审核排序、要做置信度校准都需要原始概率。只存标签等于把后路断了回头补数据要重跑一遍全量。第五条NLI不是万能的它的结论是“相对于给定前提”的。前提本身错了NLI判蕴含也救不了。这一点在事实校验场景尤其要跟业务方说清楚——模型保证的是“这段生成内容与这段证据一致”而不是“这段生成内容是对的”。这两件事的边界必须在系统设计阶段就划明白。我在实际项目里最深的一个体会是NLI看起来是个三分类的小任务但它把所有“语义理解”的难点都压缩进去了否定、量词、时间、比较、常识、指代每一个都是独立的坑。所以真正决定成败的从来不是换哪个模型而是你有没有耐心把这些坑一个个挖出来做成固定的测试集然后每次迭代都跑一遍。这套东西建起来之后模型换不换、换多大反而成了最简单的那一步。
