做文本核验这行，被问得最多的一类问题是“这两句话到底算不算一个意思”。有人拿它做检索结果校验，有人拿它做问答答案兜底，还有人拿它做内容发布的合规预检。刚接触的人通常第一反应是丢给相似度模型算个余弦，结果立刻翻车——反义句相似度能到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：桌上没有任何水果。 |
| 中性 | neutral | P既不支持也不否定H | P：桌上放着两个红苹果。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_labels=3, id2label={i: l for l, i in LABEL2ID.items()}, label2id=LABEL2ID, ) def preprocess(examples): return tokenizer( examples["premise"], examples["hypothesis"], truncation="only_first", max_length=256, padding="max_length", ) dataset = load_dataset("json", data_files={"train": "train.jsonl", "valid": "valid.jsonl"}) encoded = dataset.map(preprocess, batched=True) encoded = encoded.map(lambda e: {"labels": [LABEL2ID[x] for x in e["label"]]}, batched=True) args = TrainingArguments( output_dir="./nli-out", learning_rate=2e-5, per_device_train_batch_size=32, per_device_eval_batch_size=64, num_train_epochs=4, warmup_ratio=0.1, weight_decay=0.01, eval_strategy="epoch", save_strategy="epoch", load_best_model_at_end=True, metric_for_best_model="macro_f1", greater_is_better=True, fp16=torch.cuda.is_available(), ) trainer = Trainer( model=model, args=args, train_dataset=encoded["train"], eval_dataset=encoded["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_end=True配合按macro-F1选最优，比按loss选更靠谱，因为loss对类别不平衡不敏感。
truncation="only_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_size=64, max_length=256): 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], truncation="only_first", max_length=max_length, padding=True, return_tensors="pt", ).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看起来是个三分类的小任务，但它把所有“语义理解”的难点都压缩进去了：否定、量词、时间、比较、常识、指代，每一个都是独立的坑。所以真正决定成败的从来不是换哪个模型，而是你有没有耐心把这些坑一个个挖出来，做成固定的测试集，然后每次迭代都跑一遍。这套东西建起来之后，模型换不换、换多大，反而成了最简单的那一步。
