AnyJev 指南：把开放 LLM 变成本地 Jev 风格决策层
理解 Nokia Applied Research 开源的 AnyJev：如何在 Qwen 等开放 LLM 上实现 Choice、Score 与是非判断，L0/L1/L2 有什么区别，以及它与官方 Jev、Laya、JevK5 和 Winnow 应该怎么选。
如果你已经在本地运行 Qwen 等开放模型，又需要分类质量、概率校准和数据留在本地，AnyJev 值得测试。它不是新的模型底座，也不是 TypeSafe AI 的官方 Jev：它在现有 LLM 上增加类型化问题、去偏、校准和可选的闭式决策头。
AnyJev 不是新底座，而是现有 LLM 的决策读出层
AnyJev 由 Nokia Applied Research 组织公开，作者单位包括 Nokia 与 Tencent Hunyuan。它把一个开放 LLM 的下一 Token 分布或中间隐藏状态读成封闭决策：Choice 选择一个命名选项，Score 放到有序量表上，Noul / yes-no 估计命题为真的概率。整个过程不生成正文，也不需要解析 JSON。
因此本站把它归入“兼容适配层”，而不是独立训练的 System One 模型。它与 TypeSafe AI 没有隶属关系，也不能因为接口相似就假设与官方 Jev 的质量、延迟或概率语义完全一致。
本地业务证据
Qwen / 其他底座
去偏 / 校准 / 决策头
Choice / Score / yes-no
L0、L1、L2 解决的是三个不同问题
不要把三个等级都理解成“更快的分类”。L0 主要处理选项位置与标签先验偏差；L1 用同一问题的标注样本校准置信度；L2 则从模型中间层闭式求解一个与“问题 + 模型”绑定的决策头。
| 等级 | 需要什么 | 得到什么 | 不能保证 |
|---|---|---|---|
L0 | 无需标签 | 轮换选项并修正标签先验，降低顺序偏差 | 概率已经校准；Choice 需要 K 次 prefill |
L1 | 每个问题 100–500 条标签 | 在 L0 上做温度缩放，改善概率校准 | 改变错误的排序或解决分布漂移 |
L2 | 通常每个问题 100–300 条标签 + 隐藏状态 | 闭式求解决策头；可在约三分之二深度读出 | 迁移到另一个问题或模型 |
先跑 L0，再决定是否值得收集标签
项目当前要求 Python 3.10 或更高版本。下面使用 Hugging Face backend 在本地加载 Qwen，并明确请求 L0。首次试验应选择可撤销、容易人工核对的路由任务。
python -m pip install "anyjev[hf]"from anyjev import Decider, Question
from anyjev.backends.hf import HFBackend
decider = Decider(
HFBackend("Qwen/Qwen3-4B"),
level="L0",
)
route = Question.choice(
"Which team should handle this ticket?",
["billing", "technical", "sales", "human"],
name="route",
)
state = "Enterprise checkout fails after payment confirmation."
decision = decider.decide(state, [route])["route"]
print(decision.argmax)
print(decision.distribution)
print(decision.level)这一步的目标不是立即上线，而是建立你自己的对照集：记录输入、人工标签、AnyJev 等级、完整分布、延迟和最终结果。拿到稳定的标签流后，再用 L1 校准，或为高价值固定问题拟合 L2 head。
官方结果有参考价值，但不能直接当成你的线上结论
仓库在 Qwen3-8B、BANKING77 20 分类的 300 条测试样本上报告：从 raw 到 L0，准确率由 0.747 到 0.803，选项反转导致的答案翻转率由 0.230 降到 0.073；加入 100–500 条标签的 L1 后，ECE 从 raw 的 0.240 降到 0.095。L2 表格则基于 typed-decisions 的 20 个问题，每题用 300 条标注拟合、100 条留出测试。
上线前必须看清的五个边界
- 仍然要运行完整底座
它复用现有 LLM，不会自动获得小型专用分类器的内存、成本或运维优势。
- L0 有多次 prefill 成本
K 个 Choice 选项通常需要 K 次轮换；Noul 两次，Score 一次。
- L2 与问题和模型绑定
更换问题、选项集合或底座后，原 head 不能被假定继续有效。
- 校准不能补知识缺口
底座不会做的任务，重新缩放概率也不会突然做对。
- 项目仍处于 Pre-Alpha
固定依赖版本、保存离线评测、默认人工复核，并在每次升级后重新验证。
按你的现有资产选择，不要只比宣传数字
希望数据留在本地，并愿意为固定问题持续收集标签。
接受部署或微调专用模型，优先考虑体积与推理成本。
逐项检查接口、校准证据、许可证和维护状态。
不想维护底座或标签管线，接受把请求发送到托管 API。
最稳妥的验证方式是拿同一批真实业务样本做并行评估：质量、校准、拒绝覆盖率、端到端延迟、硬件成本和维护负担一起比较。