对标 Jev：开源决策模型 NeoHorse-Jev-4B

海边捡石子
3 阅读7分钟

封面：对标 Jev / NeoHorse-Jev-4B / 开源决策层

图：把「分类 / 路由 / 评分」从聊天大模型里拆成可自托管的决策层；接口是 Choice / Noul / Score + 概率。

背景：决策层为什么要从聊天模型里拆出来

智能体和工作流里，大量调用其实不是「写一段回复」，而是在给定上下文里做窄决策：这条请求去哪个队列、要不要调某个工具、当前置信度够不够自动放行。用聊天大模型做这类事，常见做法是再调一次、让它吐 JSON，再正则或 schema 抠字段。能跑，但成本高、延迟不稳，概率也难直接接到路由阈值上。

Jev 这类产品把这件事单独建模：输入是应用给出的 state 和一组原子问题，输出是类型化答案加概率，而不是散文。工程上需要的是可接线的决策信号，不是再开一个聊天窗口。

TokenRhythm（基元律动）随后放出了同接口形态、可本地部署的开源权重 NeoHorse-Jev-4B：

参数规模约 4B，基座 NeoHorse-1-4B，上游基础模型为 Qwen3.5-4B，许可证 Apache-2.0。它解决的是「结构化决策可自托管」，不是「再做一个会写文案的小模型」。

它是什么：state + 三类问题，prefill-only

调用约定可以压成一句话：给定状态（state）和一组应用定义的问题（questions），直接预测决策及其概率。

推理是 prefill-only：不对答案做自回归文本生成，而是在调用方给出的候选、是非题或有序等级上做结构化预测。三种决策类型：

类型输入输出典型用途
Choice有序候选（key → 描述）选中 key + 完整概率分布路由、工具选择、动作选择
Noul一个是 / 否问题P(true)闸门、过滤、条件检查
Score从低到高的有序等级等级分布 + 期望分紧急度、质量、严重程度

同一条 state 可以挂多个问题，一次请求拿回多个类型化答案。候选描述由应用侧写入请求；换工具列表、换队列名，一般不需要为每个标签重训——这和「标签写死在分类头里」的传统微调分类器不同。

和「LLM + JSON 分类」也不同：后者仍走生成链路，概率弱、易越界写解释；NeoHorse-Jev 不生成文本，概率是接口一等公民，适合直接喂给阈值规则。代价也很清楚：它没有生成能力，不能当聊天模型用。 架构：用户请求 → 决策模型 → 路由/闸门 → LLM 生成

图：决策层负责「选哪条路 / 是否放行 / 评多少分」；LLM 负责生成。二者叠加，而不是互相替代。

在 Agent 工作流里，它的位置更像闸门，而不是大脑：

flowchart LR
  U[&#34;用户请求<br/>工单 / 意图 / 截图&#34;]
  D[&#34;决策模型<br/>Choice / Noul / Score<br/>+ 概率&#34;]
  G{&#34;路由 / 闸门<br/>阈值 · 分流 · 护栏&#34;}
  LLM[&#34;聊天大模型<br/>生成回复 / 方案&#34;]
  H[&#34;人工 / 旁路&#34;]
  T[&#34;工具 / 子图 / 队列&#34;]

  U --> D --> G
  G -->|&#34;置信够 · 选路&#34;| T
  G -->|&#34;需要生成&#34;| LLM
  G -->|&#34;低置信 / 高风险&#34;| H
  T --> LLM

  style D fill:#dbeafe,stroke:#1d4ed8
  style G fill:#ccfbf1,stroke:#0f766e
  style LLM fill:#ffedd5,stroke:#ea580c

一句话：可编程的决策接口，不是会聊天的小模型。

三角对比示意

图：传统分类器、LLM+JSON、决策模型各自约束不同；NeoHorse·Jev 站在「结构化决策 + 可热换候选 + 概率路由」这一侧。

模型卡上的文本评测综合分约 77.70，Nimble / VitaminC / MASSIVE 三项均分约 83.26%（相对 NeoHorse-1-4B 基线有提升）。数字来自公开模型卡评测表，落地仍以业务独立集为准。

和 TypeSafe Jev：同类任务，不同产品

两者做的是同一类事：在给定状态下回答「选哪个 / 是不是 / 评几分」，并给出可用概率；接口形态也同构（Choice / Noul / Score，prefill-only）。 差别在产品边界。TypeSafe Jev 是托管闭源 API：少运维、跟官方网关与生态，权重细节不对外。NeoHorse-Jev-4B 是开源自托管：Apache-2.0 完整包（backbone + 独立决策头 + runtime），可走 vLLM、SGLang 或原生 Python / CLI / HTTP；另外支持单张图片 + 文本联合输入。校准指标（如 ECE / Brier）在公开材料里并不完整，阈值需要自己在业务数据上定——接口像，不代表分数和阈值可以直接照搬。

优点与缺点

优点（可验证、可落地）：

  • 本地可控。 Apache-2.0，权重进机房，可钉版本、可审计依赖链，适合内网与数据不出域场景。
  • 候选热换。 工具表、队列名、审核标签写进请求即可换，不必为每个标签扩头重训。
  • 概率可接线。 Choice 分布、Noul 的 P(true)、Score 期望分，都能直接驱动自动过 / 人工审 / 换更大模型 / 降级。
  • 把高频窄决策从生成链路抠出去。 闸门类调用多、问题窄；价值不在「更聪明」，而在形态更对口。延迟和成本取决于机器与后端，公开材料没有统一的跨方案计时对比。
  • 部署路径清楚。 vLLM、SGLang、原生均可；原生提供 /v1/systemone 风格接口，便于和 Jev 侧概念对齐。完整包必须下齐，只下半截权重不够。

缺点与边界：

  • 会错。 合法结构 + 归一化概率 ≠ 判断正确；证据缺失、候选措辞与顺序、领域漂移都会伤准确率。
  • 不是聊天模型。 不写文案、不写长回复；开放推理、长文档生成仍归 LLM。
  • 算术 / 时序数值类任务弱，不要指望它替代计算器或硬规则。
  • 生产阈值必须自测。 概率校准、多语种、长输入、多问题隔离等，公开材料不足以直接上线；图文路径每次限一张图、一个问题，业务截图场景要抽样验。
  • 应用侧仍要管权限与业务规则。 模型只给决策信号，不替你执行安全策略。

应用场景与边界

适合先想清楚三件事：问题是否够窄、候选是否可枚举、是否需要概率阈值。

常见落点：工单分流（Choice → 团队 / 队列，低置信进人工）；意图与紧急度（同一 state 上 Choice + Score）；Agent 工具 / 子图选择；LLM 护栏与置信度路由（Noul / Score：高置信自动，低置信升级或换更大模型）；内容审核粗筛（不是终审法务结论）；页面截图状态判断（单图 + Choice，如成功 / 失败 / 加载中 / 未知）。

不适合硬塞：开放式客服成文、长文档写作、需要逐步算术推导的任务、把模型输出当不可推翻的终审。

最小接入示意

下面只展示接口形状。数字是格式示意，真实概率以本地运行为准；不要把密钥写进仓库。

Choice / Noul 伪代码

engine = DecisionEngine(MODEL_DIR)
state  = "同一笔订单扣了两次钱，请今天把多扣的那笔退给我。"

# 一次请求：是非闸门 + 团队分流
result = engine.predict({
  state: state,
  questions: {
    refund: {
      type: "noul",
      instructions: "用户是否要求退款？"
    },
    team: {
      type: "choice",
      instructions: "应该由哪个团队处理这条消息？",
      criteria: {
        billing:   "账单、扣款或退款",
        technical: "产品故障或技术问题",
        other:     "其他事项"
      }
    }
  }
})

p_refund = result.answers.refund.noul          # P(true)
team     = result.answers.team.choice          # e.g. billing
probs    = result.answers.team.probabilities   # 完整分布

if p_refund >= 0.9 and probs[team] >= 0.8:
    route(team)
else:
    escalate_human()

curl 到本地 /v1/systemone

先按文档下载完整模型包并启动原生服务（目录与端口按环境替换）：

CUDA_VISIBLE_DEVICES=0 neohorse-decision serve \
  --model-dir "$MODEL_DIR" --port 8080

然后：

curl -sS http://127.0.0.1:8080/v1/systemone \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "NeoHorse-Jev-4B",
    "state": "同一笔订单扣了两次钱，请今天把多扣的那笔退给我。",
    "questions": {
      "refund": {
        "type": "noul",
        "instructions": "用户是否要求退款？"
      }
    }
  }'

对外暴露时用网关做 TLS，用环境变量配置的 API Key 做 Bearer。vLLM / SGLang 启动脚本与请求样例在 GitHub NeoHorse/jev 目录；细节以 ModelScope README 与 DEPLOYMENT.md 为准。

选型

约束对齐后选择很直接：

  • 内网自托管、可审计、可钉版本，且决策窄、候选可枚举、要概率阈值 → NeoHorse-Jev-4B（或同类决策层）
  • 要官方托管、少运维、跟 TypeSafe 生态 → TypeSafe Jev API
  • 要写回复、写方案、开放推理、长上下文生成 → 聊天大模型
  • 标签极稳、吞吐极高、问题极度单一 → 传统分类器往往更省

更短一点：生成用 LLM；窄决策加概率路由用决策模型；托管省事用 TypeSafe；权重进机房用 NeoHorse。

资源：

NeoHorse-Jev-4B 是可自托管的开源决策层。放在闸门与分流上它才值钱；拿去写文案，生成质量与决策可信度都会一起丢。

avatar
文章
阅读
粉丝