作者：卢建晖

排版：Alan Wang

1. Jev 的意义：加速下一步行动，而不只是生成下一条回复

让我们回到之前一直在探讨的自动点餐场景。

顾客说：“我要一份套餐，不过饮料别太甜。”

对话模型可以给出友好的回复。但对于点餐应用来说，真正的工作才刚刚开始。顾客是否已经选定了某一款套餐？“别太甜”是否对应系统支持的定制选项？应用应该追问、更新购物车，还是进入确认环节？

应用需要的不是另一段文字，而是一个能够推动工作流向前发展的决策。

传统规则非常擅长处理明确的约束：售罄的商品不能下单，结账前必须确认，支付必须获得授权。模型不应该取代这些规则。但随着输入变得模糊、越来越依赖上下文，规则树中的分支也会不断增加。反过来，如果每一个细小的路由决策都要经过大型模型的推理与生成流程，也可能带来不必要的等待。

这就是我对 Jev 价值的理解：将语义理解转化为结构化的行为决策，缩短从理解到行动之间的距离。

点餐应用可以将对话拆解为几个范围明确的问题：

这些输出并不代表授权。模型可以建议进入确认环节，但这一建议不能绕过库存检查、过敏原规则或支付授权。应用仍然需要明确的状态转换、约束条件和工具调用边界。

从点餐场景的探索中，我得到的启示是：结构化不仅能让答案更容易解析，还能减少智能体工作流中不必要的决策步骤。 如果提前定义好问题、选项和执行边界，模型就不必在每一轮交互中重新设计整个处理流程。

在继续之前，有一点需要说明。本项目并未对官方 Jev 模型进行微调，也没有复现其私有实现。它借鉴了 Jev 风格的类型化决策接口设计思路，遵循开源 Hmm 项目的提示词约定，并探索如何基于我们自己的小模型构建可部署的组件。

2. 边缘小语言模型的适用场景：让决策靠近行动发生的位置

在基础规则之外，我最感兴趣的机会来自垂直领域应用：能否让模型在实际执行操作的位置，直接做出有用的语义决策？

SLM（小语言模型）并不意味着模型天然适合在边缘设备上运行。模型规模、上下文长度、运行时、内存和硬件都会决定它能否适配目标设备。尽管如此，小模型为职责划分提供了一种有价值的思路：

使用大模型处理开放式问题，使用小模型处理高频且范围明确的语义决策，并使用确定性代码处理约束和执行。

从点餐终端到具身系统

在点餐终端上，本地模型可以识别顾客提出的修改请求，判断必要信息是否完整，并选择合适的业务模块。网络中断时，部分决策仍然可以继续执行；敏感上下文也可能因此避免不必要的传输。这些优势取决于应用的完整数据流，而不仅仅是将模型权重存储在本地。

在具身系统中，类似的问题会转化为任务层面的意图判断，例如：“用户是要求机器人靠近某个位置，还是只是在描述一个地点？”“任务应该继续执行，还是等待进一步澄清？”

这里有一条必须明确的边界：语言模型可以参与任务层面的决策，但不应该成为避障、紧急停止或底层运动控制的唯一机制。

毫秒级响应是值得追求的工程目标，但使用小模型或将模型导出为 ONNX，并不意味着系统就能自动达到这一目标。我们需要在目标设备上测量完整的执行链路，包括输入处理、推理、策略评估和工具执行。

从单个助手到多智能体编排

多智能体系统也提供了另一个机会。一个复杂请求可能涉及研究、规划、执行和验证，但并非每一次任务交接都需要开放式讨论。

本地决策组件可以判断：

• 应该将请求交给哪个智能体？

• 执行所需的信息是否完整？

• 工具返回的结果是否需要独立审核？

• 工作流应该继续、重试，还是请求人工介入？

我正在探索如何让托管智能体负责较长流程的编排，同时让受约束的自主执行机制推动任务向前发展。在这种设计中，小模型可以充当高频的本地决策节点。

“自主”并不意味着不受限制：工具权限、超时时间、重试次数上限和人工审批仍然属于应用需要负责的范畴。

这也是 ONNX 一个很有吸引力的应用方向：将学习得到的决策能力打包为推理运行时可以加载的制品，而不要求每个部署目标都携带完整的训练环境。

不过，ONNX 是一种部署路径，并不保证模型在所有硬件上都具有可移植性或出色的性能。 本工作流导出的是 CUDA FP16 模型。若要将其迁移到 CPU、移动设备或 NPU，需要使用兼容的执行提供程序和算子，并可能需要重新导出、量化以及回归评估。

3. 先微调通用决策组件，再进行垂直领域适配

我没有一开始就构建复杂的行业系统，而是从一个通用的类型化决策实验入手：

Qwen3.5-0.8B → 使用 Olive 进行 LoRA 微调 → 通过 Olive ModelBuilder 导出 → 在 ONNX 上测试概率 → 发布到 Hugging Face 的工作流。

具体实现位于 Qwen3_5_0.8B_FT.ipynb。这个实验的目的并不是声称一个 Notebook 就能解决某个垂直领域的问题，而是将从数据到可部署决策能力的完整路径具体呈现出来。

第一步：学习范围明确的选项，而不是生成长篇回答

基础模型是 Qwen/Qwen3.5-0.8B，使用的数据集是 n4ze3m/typed-decisions-synth。

一个状态中可能包含多个问题。预处理时，会将每个问题展开为一个训练样本，同时保留数据集按照案例划分的训练集和验证集。这可以避免同一状态下的问题分别进入训练集和验证集，造成数据泄漏。

每个问题都会转化为在若干选项字母之间进行选择：

待评估的状态：
救命！我的款项已经连续 3 天无法到账了。我今天就需要这笔钱。

问题：
应该由哪个团队处理？

选项：
A：billing（账单）——付款、发票、退款
B：technical（技术）——程序错误、服务中断、系统集成
C：sales（销售）——定价、套餐升级、新账户

只返回选项字母。

choice 表示从多个类别选项中进行选择；noul 使用 false / true；score 使用有序等级。在预处理过程中，choice 的选项会根据状态和问题 ID 进行确定性随机打乱，以减少模型对固定选项位置的偏向。score 的等级以及布尔选项则会保留预期的顺序。

一些细节有助于确保整个过程遵守既定约定：使用相同的聊天模板、关闭思考模式、验证训练文本是否以推理提示词开头、确认每个选项字母都对应一个 Token，并丢弃长度超过 768 个 Token 的样本，而不是直接截断。

这并不是无关紧要的数据清理工作，而是在定义模型与应用之间的交互协议。

第二步：将实验设置转化为可检查的 Olive 工作流

该 Notebook 从固定的源码版本构建 Microsoft Olive。它使用 olive finetune --dry_run 生成与当前版本匹配的配置，然后调整预处理和验证逻辑。

替换默认的 JOIN 策略，可以避免将彼此独立的问题拼接成连续文本。训练开始前，使用 RunConfig.model_validate(...) 检查配置。实际执行通过 Olive 的 Python API 完成，这样出现错误时，Notebook 可以直接显示相关信息，而不是将问题隐藏在通用的 CalledProcessError 异常之后。

这里必须明确一个重要区别：这个 Olive 工作流使用标准的全序列语言模型监督微调（SFT），而不是 Hmm 所采用的候选字母硬标签与教师模型软标签相结合的训练方式。 教师模型的概率会保留下来用于分析，但不会参与此次训练损失的计算。因此，不能将 Hmm 的准确率和校准结果直接套用到这个 0.8B 模型上。

第三步：导出完整的运行时约定，而不仅仅是计算图

LoRA 适配器本身并不是最终的部署端点。基础模型、适配器、分词器、配置和运行时必须彼此兼容。

该 Notebook 使用 Olive 的 ModelBuilder，将基础模型与适配器导出为 CUDA FP16 格式的 ONNX 模型。最终产物不只有一个 .onnx 文件，还包括外部权重、分词器资源和 genai_config.json，这些都是可部署单元的一部分。使用方应加载完整的目录。

整个过程中最值得记录的部分，是如何处理不同版本之间的兼容性问题：

这些记录反映的是当前环境中的实际情况，并不是适用于所有环境的通用修复方案。兼容性代码会形成技术债务：升级时，应重新检查相关接口和输出，而不是无限期地沿用旧的临时解决方案。

固定 Olive 的某个 Git 提交版本，也不能保证整个实验完全可复现。更完善的发布记录还应包含基础模型和数据集的版本、完整依赖清单、GPU 与驱动信息，以及最终发布时对应的提交记录。

第四步：在测试中回答两个不同的问题

第一个问题是：模型能否正常运行？

独立的 Python 测试脚本 会加载导出的模型，读取一条验证样本，生成答案并提取选项字母。这是对模型、分词器和生成流程的基本冒烟测试，而不是完整的质量评估。

第二个问题是：应用能否实际使用这个决策结果？

参考 Hmm 的方法，ONNX 概率计算部分会读取提示词之后第一个生成位置的 logits，只选取有效选项字母对应的 logits，再应用 softmax：

**# candidate_logits contains only valid first-token option logits.**
shifted = candidate_logits - candidate_logits.max()
probabilities = np.exp(shifted)
probabilities /= probabilities.sum()

对于 A、B、C 三个选项，这会得到一个仅针对这三个选项的概率分布。但这并不能证明候选选项已经覆盖所有可能情况，也不能提供针对所有潜在答案的绝对置信度。

随后，应用会解释这些结果：noul 读取 P(true)，choice 选择概率最高的选项，score 则计算有序等级上的期望值。示例中的置信度公式为 (n × p_max - 1) / (n - 1)，用于衡量概率分布的集中程度。它并不是模型预测正确的校准概率。

因此，评估需要从多个维度展开。准确率、候选选项的负对数似然（NLL）和期望校准误差（ECE）用于衡量决策质量；P50/P95 延迟、峰值内存、回退率以及目标设备上的任务完成情况，则用于衡量应用价值。

目前，Notebook 中完整的验证指标计算部分使用的是 PyTorch/PEFT 路径，而 ONNX 部分测试的是样本级概率。前者不能被当作后者的评估报告。在导出前后比较候选选项的概率分布和实际决策结果，仍然是必要的工作。

本文没有声称任何未经记录的训练耗时、准确率提升或已经得到验证的毫秒级边缘推理延迟。

第五步：发布只是垂直领域应用探索的起点

该 Notebook 包含一个发布工作流，用于将 ONNX 目录和模型卡上传至 lokinfey/Qwen3_5_0.8B_jev。这是配置好的发布目标，并不意味着本文已经验证了远程上传成功。

模型卡应说明基础模型、数据集、训练目标的差异、运行时版本、预期用途以及尚待完成的评估。身份验证通过交互式输入 Token 的方式完成，而不是将凭据直接写入源文件或提交历史。

通用流程建立之后，真正重要的工作才是领域适配。以点餐场景为例，需要定义真实的业务状态和操作，包括菜单版本、购物车内容、修改历史、缺失信息、必须澄清的事项，以及始终需要顾客确认才能执行的操作。

领域数据应体现这些边界，并按照对话或业务实体划分验证集。对于低置信度、分布外输入以及与规则冲突的情况，需要设计明确的拒绝处理或升级机制。目标不是强迫模型为每个请求都做出选择，而是帮助系统在已知边界内，以恰当的方式继续推进工作流。

4. 总结：真正的机会在于缩短决策路径，而不是缩小聊天窗口

一个需要澄清的点餐请求、机器人对任务意图的判断，以及多智能体工作流中的本地任务交接，都面临着相同的核心问题：系统拥有各种工具，但仍然需要判断何时使用工具、由谁执行，以及何时停止。

Jev 风格的结构化决策提供了一种接口设计思路；SLM 让部分语义判断有机会更靠近设备执行；Microsoft Olive 将微调和模型导出组织为一套工作流；ONNX Runtime 则为模型部署提供了执行路径。

它们结合起来，有望带来比小型聊天机器人更实用的东西：一个可衡量、受约束且可替换的决策组件。

我希望继续验证的方向，是让托管智能体负责长流程的协调，让边缘小模型处理高频的本地决策，并让确定性代码守住业务与安全边界。衡量成功与否，不应只看回复听起来是否聪明，更应关注系统能否以更快、更可靠的方式完成正确的操作。这就是从聊天走向决策的下一步。

实现代码与参考资料

• 微调 Notebook

• Microsoft Olive

• ONNX Runtime GenAI

• Qwen3.5-0.8B 基础模型

• Hmm 模型卡与提示词格式

• typed-decisions-synth 数据集