概率输出如何干掉幻觉：Kev 确定性判定的技术底牌

概率输出如何干掉幻觉：Kev 确定性判定的技术底牌

【免费下载链接】kevJev-like family of decision models built on top of Qwen3.5/3.8 you can train and run on your own项目地址: https://gitcode.com/gh_mirrors/kev2/kev

大模型落地到业务判定场景，最让工程师头疼的不是精度，而是"不可复现"。同一张工单，同一套提示词，跑两次结果不一样；模型自信满满地输出一段流畅的推理，结论却是编的。幻觉的根源在架构：生成式模型的任务是"续写 token"，推理只是续写过程中的副产物，采样温度、beam、随机种子都会让结果漂移。

Kev 给了一个近乎反直觉的答案：判定不是生成出来的，而是算出来的。它不产出任何文本，只对调用方给定的选项打分，输出一个归一化的概率分布——同样的输入永远得到同样的输出，幻觉在源头被堵死。本文结合 Kev 仓库源码，拆解"概率输出干掉幻觉"的三层底牌：从 softmax 分布到业务判定的映射机制、确定性判定与生成式随机性的对比实验、以及概率"该信"与"不该信"的边界。

从 softmax 分布到业务判定的映射机制

Kev 的架构一句话就能说清：一个冻结的 Qwen 基座（Qwen3.5/3.8），一个 rank-16 的 LoRA 适配器，加一个极小的指针头（Pointer Head）。关键区别在于——基座只做 prefill，不挂词表头，整个前向过程零生成。

# backbone only (no vocab head): we never generate text. self.lm = AutoModel.from_pretrained(name, revision=revision, **load).model self.head = PointerHead(self.lm.config.hidden_size, dp=head_dim)

这一行注释写在 kev/model.py 里，是整个项目设计哲学的浓缩。Kev 把"判定"拆解为指针头的打分：每个选项的结束标记</opt>的隐状态，与问题结束标记<decide>的隐状态做投影点积，得到该选项的 logit，再过 softmax 变成概率。

def forward(self, h_decide, h_opts): # [d], [K,d] -> logits [K] z = (self.k(h_opts) @ self.q(h_decide)) * self.scale return z if self.training or self.temperature == 1.0 else z / self.temperature

PointerHead只有两个可学习投影q、k（维度 256），加上一个刻度因子。它不预测下一个 token，不拼接任何自然语言答案，而是把"模型读懂了什么"压成一组标量。从这个单点原语出发，kev/api.py 把 TypeSafe 的三原语 API 一一映射过去：

序列化层把概率分布翻译成业务可直接消费的字段（kev/api.py 的to_answers）：choice 返回choice、probabilities、confidence；score 返回均值索引score和按档位的分布。置信度不是"模型感觉有多确定"，而是两个确定的公式：choice 是(p_max − 1/K) / (1 − 1/K)，score 是max(0, 1 − E|level − mode| / D)。这是从概率分布派生出来的确定性量，不是另一个神经网络的输出。

配套的工程细节同样为确定性服务：调用方传入的文本在分词前会重写<|...|>特殊标记，从根上杜绝伪造分隔符注入额外选项（user_tokens，kev/model.py）；答案序列化的 token 数被计为output_tokens，但 README 明确注明"counts tokens in the serialized answers, not generated tokens"——服务端没有任何生成动作，latency_ms里就没有采样开销。这也是 Kev 在风控、审核、工单分诊等业务闭环里能拿到低延迟、高一致性的原因。

确定性判定 vs 生成式随机性：对照实验说了什么

"确定性"在 Kev 的评测体系里不是一句口号，而是一组可复现的实验事实。

实验一：温度只校准、不改变判定。每个 checkpoint 发布时都带一个拟合好的温度（Kev-4B 是 2.41，Kev-27B 是 1.32），推理时 logits 除以温度后再 softmax。这里有个容易误读的点：这个温度不是"生成温度"——Kev 不生成，所以它不会引入随机性。它只做一件事：把概率分布的尖锐度调整到与真实正确率一致，即校准。PointerHead.forward里写得很明白，argmax由构造保证不变（"the argmax is unchanged by construction"）。也就是说，调温度之前和之后，同一个输入永远判出同一个答案，变的只是概率值本身。

对照数据来自 README 的 Benchmark 章节：在从未训练过的新源数据上，仅一个温度，就把 Kev-9B 的期望校准误差（ECE）从 0.103 压到 0.041，把"概率≥0.9 却答错"的自信错误率从 8.2% 压到 2.4%——低于 Jev 的 3.7%。准确率数字前后完全不变，Brier 分数（评价整个分布而非只看榜首）则显著改善。这正是"用概率输出替代文本输出"的核心收益：分布变诚实了，但判定没被扰动。

实验二：删掉证据，看模型敢不敢说"我不知道"。这是 Kev 评测里最有设计感的一组。transfer-v9套件里有 90 条"不可知"记录：从程序化生成的政策案例中删掉决定证据句，使答案在文本上根本不可恢复（kev/transfer_v9.py）。评测规则很明确：不可知记录不评准确率，只评置信度——模型必须学会"没有证据就压低所有选项的概率"。

更狠的是训练侧也这么教。evals/night2的构建脚本把不可知记录的软目标直接设成均匀分布：

for q in r["questions"].values(): keys = question_keys(q["type"], q.get("criteria")) q["target"] = {k: 1.0 / len(keys) for k in keys}

对应注释是 "Teaches 'no evidence -> no confidence'"（scripts/build_night2_data.py）。结果：在不可知记录上，Kev-9B 以 ≥0.9 置信度作答的比例是0%，而 Jev 是 9%。生成式模型的幻觉往往出现在"信息不足却硬要编一个答案"的时刻；Kev 用训练目标直接消掉了这个行为——它被允许输出"每条选项都一样不靠谱"。

实验三：确定性输入的严格复现。同一请求打包发送与逐条单独发送，fp32 路径下概率差异在 4e-6 以内（tests/test_model.py）；对比性配对（contrastive pairs）测试验证模型确实在读 state——把决定证据的句子换掉、标签翻转，模型必须跟着翻转（paired_flip，kev/contrastive.py）。整条链路没有采样、没有随机种子、没有 beam search，可复现性是构造成本，不是运气。整体能力对比见下图——Kev 家族与 Jev 在各类新源数据上的准确率分布：

哪些场景该信概率，哪些场景概率也不够

概率输出的最大价值，是让业务系统获得"分级处置"能力。README 里那个工单例子是最好的注脚：一条消息同时含退货、延迟、扣款三个话题，Kev 的department选项分布是 returns 0.47 / shipping 0.28 / billing 0.25——返回分布而不是单个标签，代码就能自动处理高置信案例，把骑墙案例转人工。这正是 Kev 概率输出的典型用法：置信度阈值路由 + 人工兜底。在 5% 错误预算下，Kev-4B/9B/27B 可以自动化 52%–69% 的新源决策，微调后这个比例还会涨（示例工作负载从 34% 升到 48%）。

但概率不是万能的。Kev 的模型卡和 README 用"Limitations"清单画出了清晰边界，这本身就是值得传播的工程态度：

• 单一温度无法重排置信度。校准只能整体缩放分布，不能把"低置信但正确"和"高置信但错误"分开。所以阈值必须在自己的带标签样本上实测后冻结，不能照搬发布数字。
• 校准不跨域迁移。温度是在训练分布上拟合的，未必适配你的 workload——kev/calibrate.py 记录过一个真实反例：Kev-9B 在 WANLI-256 上服务置信度均值 0.82，准确率只有 0.70。对应做法是把kev.calibrate当成部署流程的一环，在自己的标注集上重拟合温度；而scripts/calibrate_checkpoint.py甚至会拒绝在训练同源数据上拟合（round 19 的失败模式），强制使用 held-out 数据集。
• 知识类问题取决于基座，概率救不了。MMLU-Pro 上 Kev-4B 0.565 vs Jev 0.840，这是"模型不知道"而非"置信度没标对"。
• 日期算术是明确短板。deadline政策题 Kev-4B 只有 0.65，但配合KEV_DATE_FACTS=1预处理（把日期对换算成确定性的天数差句子）能拉到接近 Jev 的水平——注意，这里用的还是"确定性预处理 + 概率判定"的组合拳。
• 选项顺序仍可能翻转答案。问题隔离只保证问题之间互不干扰，不保证同一问题内部选项排列无影响（playground 专门提供了 "Permute" 功能来暴露这一点）。

把这些边界合起来看，结论很清晰：概率输出消灭的是"幻觉"这一类随机性故障，消灭不了"能力不足"这一类系统性故障。前者靠架构解决——不生成、只打分、输出可复现的分布；后者靠数据与领域注入解决——微调、温度重拟合、日期预处理。Kev 的价值在于把这两件事分开：先用确定性架构把不可复现的噪声剔除干净，剩下的误差才真正属于"可被标注、可被训练"的范畴。

这也是整个项目最值得借鉴的设计哲学：在风控、审核、客服路由这类场景里，业务的诉求从来不是"模型会写作文"，而是"模型给个靠谱的概率，让我决定信还是不信"。Kev 用一枚 256 维的指针头，把大模型的千亿参数压缩成一个可审计、可复现、可设阈值的判定信号——幻觉没有机会出场，因为它根本没有发言权。

【免费下载链接】kevJev-like family of decision models built on top of Qwen3.5/3.8 you can train and run on your own项目地址: https://gitcode.com/gh_mirrors/kev2/kev