一个具体例子#

输入是一封客服邮件，Jev 面对的问题可以是：

• 这封邮件属于售前、售后、投诉还是其他？
• 紧急程度是 1 到 5 分里的几分？
• 是否需要人工跟进？

输出不是长文，而是类似 {type:"售后", urgency:4, needs_human:true} 的结构化结果。程序可以直接根据这个结果分流、报警或转给人工。

1
flowchart LR
2
    A["输入邮件"] --> B["拆小问题"]
3
    B --> C["接收结果"]
4
    C --> D{"套规则"}
5
    D --> E["高紧急且涉及退款<br/>进入人工队列"]
6
    D --> F["低风险咨询<br/>自动回复或知识库"]
7
    D --> G["不确定样本<br/>停止或升级，不让概率变成授权"]

普通 LLM 和 Jev 的差别#

建立基本认识#

把 Jev 理解成 Agent 系统里的“前置判断层”。很多 Agent 每一步都要问：该走哪个分支？这条信息相关吗？要不要交给人工？如果每次都用大模型，成本和延迟都会变高。Jev 的价值是把这些低层判断抽出来，让通用模型只在需要表达、推理或写作时才出场。

读链接前先记住三句话： Jev 不是聊天机器人；它的输出更像表单而不是作文；zero hallucination 指输出形状受 schema 约束，不等于判断永远正确。

1
flowchart LR
2
    A["理解边界<br/>确认 Jev 不是聊天模型"] --> B["掌握原语<br/>Choice / Score / Noul"]
3
    B --> C["看原理<br/>State / 并行问题 / 校准概率"]
4
    C --> D["做小实验<br/>50-200 条业务样本"]
5
    D --> E["再查资料<br/>官方 / 论文 / 第三方实测"]

怎么做：一次调用的实际形状#

1. 准备 state： 把客服邮件、工单、检索结果、JSON 数据或文本数组放进输入。
2. 预设问题： 不要问“帮我分析这封邮件”，而是拆成类别、紧急度、是否需要人工跟进等小问题。
3. 预设答案空间： 类别只能是固定枚举，分数只能是固定等级，真假判断只输出 0 到 1 的概率。
4. 批量提交： 同一 state 上的独立问题可以并行评估。
5. 接收 typed decision： 程序拿到结构化结果和概率，而不是自然语言文本。
6. 代码执行后续： 分支、副作用、权限、规则、加权求和和阈值处理都留在软件里。

这个设计把“语义判断”和“行动执行”分开。Jev 只负责前者，后者必须由可审计、可测试的代码控制。官方文档反复强调这一点，硅鱼之乐的实测也说明：如果 Agent 把概率当成授权，风险会直接进入系统。

为什么这么做#

传统 LLM 做 API 决策时，常见问题不是“不能答”，而是“答得太贵、太慢、太松”。为了让模型输出 JSON，需要约束解码、schema 校验、重试和解析；如果任务只是 20 个二值判断，用大模型生成文本再解析，成本和延迟都不划算。

Jev 的取舍是提前收窄答案空间。分类任务的答案本来就只有几个枚举值，评分任务本来就是几个等级，布尔任务本来就是真假；模型可以直接在这些受限空间上输出概率，而不必自回归地生成一段话。这样换来的是更低延迟、更低输入成本、更稳定的输出类型、可并行的小问题和可直接阈值化的概率。

训练目标是 RLCD（Reinforcement Learning for Calibrated Decisions）：优化决策和校准概率，而不是优化聊天文本。校准指模型长期说 0.8 时，相似置信度的一组预测大约应有八成正确；但校准不能保证某一次 0.8 的预测一定对。

RLHF / RLVR / RLCD： RLHF 面向人类偏好和对话有用性；RLVR 面向可验证奖励和推理任务；RLCD 面向可组合进程序的决策和可用不确定性。

1
flowchart LR
2
    A["模型输出 0.8"] --> B["群体含义<br/>相似置信度的一组预测中，长期约 80% 正确"]
3
    A --> C["单次含义<br/>仍可能错误，不能替代权限、规则和人工审核"]

和 LLM 的区别#

Jev 不是“更小的 ChatGPT”，而是另一种接口形态：把 LLM 的表达自由度换成决策效率和可组合性。更合理的架构通常是 Jev 前置做路由、筛选和验证，LLM 后置做理解、推理、写作和多轮交互。

1
flowchart LR
2
    A["Jev 前置<br/>分类 / 筛选 / 路由 / 评分 / 验证"] --> B["规则层<br/>阈值 / 权限 / 冷却时间 / 人工审核 / 成本预算"]
3
    B --> C["通用 LLM 后置<br/>深度理解 / 多步推理 / 写作 / 总结 / 多轮对话"]

为什么要用#

当任务满足四个条件时，Jev 值得优先试验：答案空间可以预先枚举；判断能拆成小问题；调用频率高或延迟敏感；概率可以转化为阈值决策。典型例子包括模型路由、客服工单分类、内容风险分级、检索相关性判断、Agent 是否调用昂贵工具、批量数据打标签。

如果任务需要开放式写作、长链推理、自然语言理由、图像音频视频输入、本地私有化部署或强中文同等可靠性，Jev 不是首选。概率也不能替代权限系统：高置信删除数据库不等于允许删除。

1
flowchart TD
2
    A["优先考虑 Jev"] --> B["答案可枚举<br/>类别 / 等级 / 真假"]
3
    A --> C["问题可拆分<br/>大判断变成原子小问题"]
4
    A --> D["高频或低延迟<br/>路由 / 筛选 / 审核 / 批量打标签"]
5
    A --> E["概率可用<br/>能设计阈值 / 转人工 / 停止动作"]

怎么用：入门路径#

1. 找真实小任务： 从 50 到 200 条业务样本开始，不要直接测试“智能”。
2. 定义标准答案： 没有 ground truth，就没有准确率、校准和召回可谈。
3. 拆问题： 把“这封邮件严重吗”拆成类别、情绪、退款请求、账号异常、是否需人工等原子判断。
4. 精简 state： 只放判断需要的上下文，避免塞入大段无关对话。
5. 设计阈值： 低风险任务自动处理，中置信转人工，低置信或高损失场景停止或升级。
6. 对比基线： 与现有 LLM、规则系统和小模型比较准确率、校准误差、延迟、成本和失败模式。
7. 再上生产： 先影子运行或灰度，确认校准稳定、边界清晰后再接自动动作。

三个原语#