大模型输出的 JSON 再规整，概率信息也常常在"取最大"那一步被扔掉。Jev 这类专用分类接口把原始概率直接交给代码，让"多确定"成为可编程的分支条件。这篇是六条真实请求的实测记录和由此整理的工程约束。
概率进代码，比"取最大"值钱
拿到概率分布后有三种比取最大值更有用的用法：双阈值分支——高置信自动执行、模糊地带升级人工、极低置信走降级路径；低置信兜底——分布太平说明问题本身模糊，硬分类不如转人工；连续分直接参与排序决策，"偏 high"的信息取整就丢了。判断类接口的核心卖点就在这里：把"智能"收窄成一次带置信度的打分。
实测数据
环境 Node.js v22.21.1，按顺序发六次真实请求，各含路由、紧迫度、明确退款三个问题；jev-latest 六次返回的实际版本均为 jev-1.13.0。中英文重复扣费样本都正确路由到退款；明确退款类 Noul 概率 0.99，明确否定类 0.03——两端都很干脆。
真正有信息量的是模糊输入。"昨天那个事情，能否帮忙处理？"得到 other 0.70、support 0.30，route confidence 只有 0.54。示例策略在置信度低于 0.8 时返回 human_review，这条样本没有自动执行——行为符合预期。计时仅作记录：首条 1962ms，其余 745~823ms（含网络往返，无预热无对照，不能外推性能结论）。
增量提醒（原文只点到未展开的分层设计）：概率分流要配一条分层管道——语义判断（接口打分）→ 确定性校验（查库核对订单是否真已退款）→ 执行或人工复核。第二步不可省：模型说"该退款"不等于事实已退款，接口再快也替代不存在的数据。分层还有个附带好处：换模型时，规则层和执行层一行不用改。
与通用大模型的分工
通用模型按 schema 输出 JSON 已经很可靠，所以专用接口的价值不是"不会写错括号"。分工原则：既要判断又要生成解释或方案的，用通用模型；只需在固定候选集里高频打分、且希望原生拿概率做风险分流的，用专用接口。两者还能级联——低风险高频判断走专用接口，低置信或复杂样本升级到推理模型或人工，把昂贵能力放在真正需要的位置。
会保留的五条工程约束
记录版本化 model ID，别只记 jev-latest（别名升级后行为可能变）；用自己的中文数据验证——官方明确说英语是主要训练语言；为候选缺失、低置信、多信号冲突设明确回退；高风险动作继续读真实数据并请求确认，模型只出语义信号；原始概率按条落库存档，阈值和执行策略写在代码里而不是 prompt 里。这五条加上四层管道，就是概率分类进生产的完整最小配置。
评论0