把 GLM-5.3-Flash 变成一个 Jev 式的 System One 模型

作者：Johannes Hötter 与 Marko Rosenmüller 博士（Edgeless Systems / Privatemode）

摘要：这篇文章里，我们展示一个现成的 LLM 如何用一次前向传播做出类型化决策。这个做法让「把 LLM 变成 Jev 式决策模型」成为可能。

我们用跑在 Privatemode 上的 GLM-5.3-Flash 评估了这个做法。用一个从公开数据集构建的基准，我们展示了这套设置给出的结果在决策准确性和速度上与 TypeSafe 的 Jev 相当。

附带的好处是：GLM-5.3-Flash 这套设置能做图像上的类型化决策，而 Jev 做不到。

为什么需要类型化决策

软件问 LLM 的很多东西其实是一个决策。 「这张工单该由哪个团队处理？」或者「这条合同条款属于责任条款那一节吗？」

在这些场景里，软件通常要求 LLM 的回复遵循某种格式（比如 JSON），并且必须来自一个预定义的集合（比如 “yes” 和 “no”）。

给对了指令，LLM 通常已经能可靠地做到这一点。但在基础做法里，速度和成本会成为问题：每一个决策，LLM 都需要写出整个 JSON 对象，而一个推理模型在那之前可能已经思考了几百个 token。此外，你也没有拿到模型的置信度（除非你显式地去问）。所有这些方面在实践中都可能很关键，而它们至今阻止了人们在高并发场景里用 LLM 做决策。

Jev 和 Laya 这样的专用决策模型（或叫「System One」模型）就是为解决这个问题而设计的。 你传入一段状态和一组命名选项，拿回被选中的那个选项，以及每个选项的置信度（也就是概率）。

把 LLM 变成决策模型

一开始我们问自己：能不能把一个 LLM 变成具有 Jev 那样性质的决策模型？简短的回答是：「能」。

理解我们做法之前，先理解 LLM 是怎么工作的：

LLM 从不直接写文本。给定一个提示词，LLM 输出的是它整个词表上的一个概率分布。 在文本生成里，最简单的情况下，概率最高的那个 token 会被选为下一个 token。被选中的 token 随后被追加到提示词后面，整个过程重复。 如上面所说，如果你只是想在 JSON 对象里设几个字段，这是又贵又慢的。

我们的核心洞察是：没有必要让 LLM 去预测整个 JSON 对象，因为我们已经知道它的形状了。我们只关心 LLM 对给定输入的类型化判断。

我们意识到，可以构造提示词，让 LLM 在一次运行里就给出类型化判断——不用微调，模型就是它出厂的样子。 这就是与 Jev 和 Laya 的差别——那两个是为这个目的专门训练的模型。 基本步骤如下：

一、给选项编号。 状态、问题和输出选项以 JSON 形式进入提示词，每个选项带一个索引。指令要求模型用 choice_index: 加一个索引来回答。

二、预填答案。 提示词以 choice_index: 结束。因此模型产生的第一个 token 就会是一个指向预定义选项的索引。

三、评估输出。 与其读取模型吐出的那个 token，我们读取它在那个位置上给所有选项索引分配的概率。 在选项上归一化之后，这些就给出了每个答案的概率，我们直接取最可能的那个。

示意是这样的：

在答案内部结束提示词

user

{“state”: “I was charged twice for my order.”, “question”: “Which team?”, “options”: [

{“index”: 0, “name”: “payments”}

{“index”: 1, “name”: “complaints”}

{“index”: 2, “name”: “technical”}

]}

assistant

choice_index:

参数：

max_tokens: 1

temperature: 0

allowed_token_ids

保留选项，重新归一化

0 payments 62.1%

1 complaints 37.7%

2 technical 0.2%

→ 答案 payments，置信度 0.39（1 表示确定，0 表示所有选项等可能）

提示词给选项编号，并以已经开始的 assistant 回答 choice_index: 结尾，所以下一个 token 就是索引。 词表上的一个掩码只允许选项索引，API 返回它们的对数概率，在选项上归一化就给出了每个答案的概率。

我们为跑在 vLLM 上（在 Privatemode 里）的 GLM-5.3-Flash 实现了上述步骤。 我们用了 /chat/completions 端点，配 continue_final_message 和 add_generation_prompt: false，因为这两个参数让模型从第二步预填的 assistant 轮次继续，而不是新开一个。它们还让我们能在文本旁边传图片——这正是让图像上的类型化决策成为可能的原因。

三个实际的坑

对 vLLM 和 GLM-5.3-Flash，我们发现下面这些细节很重要：

① allowed_token_ids 可以把 LLM 的输出词表限制成只允许的选项。 它把其他每个 token 都降到 -inf。我们设了它，但它是一道护栏而不是必需项。

② top_logprobs 对第三步来说不够。 它报告的是限制生效之前的分布，所以像前导空格这样的格式 token 会占据靠前的槽位，而有些选项会掉出列表、看起来概率为零。 vLLM 的 logprob_token_ids 解决了这个问题：它返回你指定的那些 token id 的对数概率。

③ 索引的 token id 取决于模型的 tokenizer。数字不总是单个 token。 比如 GLM-5.3-Flash 中 12 是单个 token。与其随包发布一个特定于模型的 tokenizer，这个库从服务端获取 token id，这让它可以简单地用于任何模型：向 /completions 发一个带 echo 的提示词，就会返回实际提供服务的模型对它的精确分词。

实现代码在 edgelesssys/privatemode-decisions 这个仓库里。

基准测试结果

我们用一个自建基准评估了这个做法，基准也在仓库里。

我们在 29 个公开的、带标签的数据集上比较了三个系统：跑在 Privatemode 上、用上述技术查询的 GLM-5.3-Flash；TypeSafe 的 Jev；以及 Convai 的 Laya。

数据集有 2 到 151 个选项，覆盖意图路由、情感、主题分类、内容审核、蕴含、问答、法律文本和扫描文档。语料里既有英文也有德文。三个系统接收相同的状态、相同顺序的相同选项名、以及相同的指令。

每个数据集我们跑了两次。即使在温度 0 下，我们的 GLM-5.3-Flash 和 Jev 在两次相同运行之间会改变多达 3.5% 的答案：温度 0 消除了采样中的随机性，但批处理和浮点运算仍然让繁忙服务器上的一次前向传播不是逐位可复现的。因此我们把更小的差异视为噪声。

我们用默认设置跑 Jev 和 Laya，也没有在这些数据集上调过我们的提示词。

准确性

在 28 个文本数据集上比较，GLM-5.3-Flash 和 Jev 旗鼓相当。

· 各自在 10 个数据集上更准

· 剩下 8 个上，两者相差在一个百分点以内

· 中位数差距是 0.7 个百分点，略偏向 Jev，这在统计上不显著（p = 0.64）

· Laya（我们在本地跑的 4.21 亿参数模型）在大多数数据集上比两者都低。它的中位数差距是 13 到 15 个百分点，统计上显著（p < 0.001）

选项数量对准确性的影响，比「选 Jev 还是 GLM-5.3-Flash」更大。

三个数据集对相同的问题打了两遍标签——一遍粗一遍细——所以任务不变，只有选项数量变：

TREC，从 6 个选项到 42 个选项：

Jev: 92.1% → 85.6%

GLM-5.3-Flash: 91.2% → 79.6%

Laya: 88.4% → 51.2%

MASSIVE，从 18 个场景到 59 个意图：Jev 和 GLM-5.3-Flash 在两种语言上分数都上升，而 Laya 的分数下降。

所以选项数量本身并不能决定一个任务有多难。

延迟与成本

我们在单独的运行里测延迟，一次只发一个请求——因为在负载下测到的时序测的是队列，不是模型。

因为 Privatemode 托管在欧盟而 Jev 托管在美国，我们把其中四个数据集同时从德国和从美国跑了一遍：

从德国：Privatemode 180ms Jev 264ms

从美国：Jev 164ms Privatemode 299ms

成本上，Jev 更便宜。一百万次决策，GLM-5.3-Flash 约 62 欧元，Jev 约 16 欧元（按各自服务的标价）。

一个关于 token 的有趣发现

每个数据集一个点：GLM-5.3-Flash 每个问题发送的输入 token 数，减去 Jev 为同一个问题发送的 token 数。

因为问题文本对两者相同，它会抵消；剩下的就是「包装」的差异。

· Jev 加了一大块固定开销，每个选项加得很少

· GLM-5.3-Flash 加了一小块固定开销，每个选项加得更多

趋势是：GLM-5.3-Flash 起点比 Jev 低约 219 个 token，每增加一个选项多约 11 个。盈亏平衡点大约在 21 个选项。

多模态决策

状态不必是文本。GLM-5.3-Flash 是具备视觉能力的模型，所以一个问题可以带图片——比如扫描的发票、损坏包裹的照片、或者一张截图。

图片进入同一个提示词，而答案仍然是一个单 token、带每个选项的概率。

根据其文档，Jev 只能在文本上工作，而 Laya 是文本编码器，所以两者都不接受图像输入。

在 RVL-CDIP 上（1,600 份 16 类的扫描商业文档），GLM-5.3-Flash 达到 70.2% 的准确率，而且是三者中唯一能作答的。 一份文档比一句话贵：图像增加约 1,350 个输入 token，所以一百万次文档决策约 270 欧元。

能力上限

选项一多，每个系统都会撞到限制。

Laya 的选项名共享 192 个 token 的预算——这够 banking77 的 77 个意图，但不够 CLINC150 的 151 个意图。

Privatemode 部署的 GLM-5.3-Flash 在 logprob_token_ids 里最多报告 128 项，而 allowed_token_ids 里的掩码能覆盖每一个选项。 所以这个库把带 151 个选项的问题原样发两次，从第一个响应读 128 个选项的概率，从第二个读另外 23 个。 两个请求跑的是同一次前向传播，所以合并结果就是单个请求会返回的分布（在运行间噪声范围内）。

在 CLINC150 上，GLM-5.3-Flash 用这种方式达到 87.5%，而 Jev 是 78.4%。 第二次请求和长长的选项列表要花时间：一次决策 719ms，而 Jev 是 249ms。

再往上，天花板是 GLM-5.3-Flash 能拼成单个 token 的 191 个选项索引。

进一步的发现

① 有一部分剩余错误在标签里。 当大多数系统对某个答案达成一致、而数据集的标签不同意时，通常那个标签是两种都站得住脚的答案之一。banking77 有很多这样的对，比如 get_physical_card 和 order_physical_card，或者 declined_transfer 和 failed_transfer。大约 17% 的 banking77 样本属于这一类，所以那里任何系统能达到的最高分大约 85%，而不是 100%。

② 推理有帮助，但有代价。 作为对照，我们让同一个 GLM-5.3-Flash 先推理再作答，在全部 29 个数据集上。它在这个选项数的每个区间都更准——2 个选项时 89.9% 对 85.5%，21 到 80 个选项时 82.0% 对 79.2%。

但它每次决策写几百个 token 而不是一个，成本约是每百万次决策 350 欧元，而单 token 版是 62 欧元。

在最另一端，纯 embedding 相似度（完全不用决策模型，直接选离文本最近的选项）达到 45.9% 到 72.8%，取决于区间。

③ 重命名选项对不同系统影响不同。 我们把每个数据集重跑了一遍，每个选项都被替换成同义词，其他什么都没改。

在 boolq 上，true 和 false 变成 correct 和 wrong 之后，GLM-5.3-Flash 掉了 20 分，而另外两个掉了不到三分。

（作者注明：因为重命名同时也改变了问题的含义，它并没有隔离出「记忆」这个因素。）

自己动手搭

我们的库用 Python 写，可用于任何 vLLM 支撑的端点；它依赖 vLLM 对 OpenAI API 的扩展，比如 allowed_token_ids 和 logprob_token_ids。

README 说明了怎么配 Privatemode，而且有一个 AGENTS.md 文件告诉编码 agent 一个实现必须做对什么。

基准仓库包含方法论、数据集规格、测试框架、聚合方式，以及每一次原始运行的下载，所以这篇文章里的每个数字都可以在不重新跑任何东西的情况下复现。

在 Privatemode 上，这些决策受机密计算保护：你的数据即使在处理过程中也保持加密在内存里，客户端在发送任何东西之前会先验证部署的声明报告（attestation report）。

链接

原文：https://www.privatemode.ai/blog/system-one-from-glm-flash

实现仓库：https://github.com/edgelesssys/privatemode-decisions

基准仓库（可复现全部数字）：https://github.com/edgelesssys/privatemode-decisions-benchmark

Jev 文档：https://docs.typesafe.ai/models

Laya：https://huggingface.co/convaiinnovations/laya

#Jev #GLM #基准测试