生产问题不是“能不能回答”，而是“能不能放心自动执行”
诺基亚应用研究团队开源了 AnyJev，这是一个 Python 库，用来把开放大语言模型包装成 typed decision model。它面向的不是让模型写出更流畅的文本，而是让模型在固定选项中选出一个答案，并返回可以设定阈值的概率。AnyJev 支持三种问题：从多个选项中择一的 choice、回答是或否的 yes/no，以及把结果放入有序区间的 score。
这类任务看起来比生成简单，却有一个生成式应用通常不会正面暴露的问题：同一个输入，只要交换选项顺序，模型就可能改变决定。直接读取下一词分布还会受到标签先验影响，例如模型无论输入内容如何都偏好“Yes”，或者偏好选项列表中的某个位置。对于客服路由、工单分流和人工升级判断来说，答案是否随展示顺序变化，往往比模型能否写出漂亮解释更接近上线门槛。
AnyJev修正的是打分接口，不是模型知识
AnyJev 借鉴了 TypeSafe AI 于 2026 年 9 月推出的 Jev 接口，但把重点放在如何让开放模型的下一词分布更适合做决定。调用时，系统声明一个带类型的问题和一组候选项，然后读取模型对这些选项的下一词概率。整个过程不生成答案，不解析自然语言输出，也不需要训练新的模型，因此它更像是模型前端的一层决策校准，而不是新的分类器。
L0 是默认层级，包含两项修正。第一项是循环位移：如果有 K 个选项，AnyJev 会把选项列表旋转 K 次，让每个选项依次出现在每个位置，再把结果放到对数空间中求几何平均。若位置偏差在 logit 空间中表现为可加的固定项，这种聚合可以精确抵消它。第二项是先验校准，系统根据真实输入上的预测分布维护运行均值，再按默认 0.75 的强度除去标签偏好，校准在积累 8 个项目后开始生效。
基准结果说明：稳定性和置信度确实改善了
AnyJev 给出的证据集中在一个很具体的生产问题上：选项顺序是否会改变答案，以及模型给出的置信度是否可信。在 Qwen3-8B 配合 BANKING77 的测试中，任务包含 20 个类别和 300 条测试样本。直接读取选项分布时，反转选项后的翻转率为 0.230，准确率为 0.747，校准误差 ECE 为 0.240，只有 7.7% 的样本能在 5% 错误率阈值下自动决定。
加入 L0 后，翻转率降至 0.073，准确率升至 0.803，ECE 降至 0.184，自动决策比例升至 46.3%。再用 100 到 500 个标签拟合 L1 的温度缩放后，翻转率为 0.077，准确率为 0.807，ECE 降至 0.095，自动决策比例达到 52.0%。L1 不改变答案排序，它主要重新塑造置信度，因此它的价值在于帮助系统决定哪些请求可以自动处理，哪些请求应该转交人工。
代价是每个选项都要付一次推理成本
位置偏差并不是免费消除的。L0 对一个包含 K 个选项的 choice 问题需要 K 次 prefill，因为每次旋转都要重新评估列表。AnyJev 通过共享前缀和批处理压低了这笔成本，材料给出的参考是：在单张 H100 上以 32 为批次、K 等于 20 时，每个决策约需 0.25 秒。它同时提供 Transformers 和 vLLM 后端，服务部署可以使用带前缀缓存的 vLLM。
这意味着 AnyJev 的架构取舍很清楚：它用额外计算换取对选项顺序的可解释修正。选项数量增加时，prefill 成本仍然线性增加，共享前缀只能改善吞吐，不能消除单次决策的额外工作。对于四个团队之间的路由，这种成本可能可以接受。对于几十个甚至更多候选项的高并发分类，团队需要先把候选空间设计成层级路由，或者重新评估是否应该使用这种逐选项校准。
它适合做窄域决策层，不是通用能力替代品
AnyJev 最有现实感的落点，是把开放模型接入一个已经存在的工作流，而不是让它独立承担复杂判断。诺基亚团队称其在内部路由问题上试用过 AnyJev，并观察到有希望的结果，但材料没有披露准确率、延迟或自动化比例。因此，这个案例可以支持“适合路由类任务”的判断，却不能被当成生产收益的证明。
结果也显示，校准和内容判断必须分开看。L0 在测试的 9 个模型与任务组合上都降低了顺序翻转，Qwen3-32B 配合 L1 时 ECE 达到 0.036，而 Jev 已公布的数值是 0.144。但在准确率上，经过微调的 Laya 仍然领先。更可信的落地路径，是先用 AnyJev 为固定标签任务提供概率和人工升级阈值，再用真实流量评估它是否足以替代专用微调模型，而不是因为置信度看起来更规整就直接扩大自动化范围。