如果 LLM 无需微调就能做决策，我们还需要 Jev 这类模型吗？

通常，我们让模型写一段回复，只是为了从中提取一个决策。

TypeSafe 于 9 月发布的 Jev 正是围绕这一需求构建的：给它上下文和一个问题，就能直接得到一个选择、分数或概率。它把决策本身当作一项独立任务，并关注概率的可信度，以及如何在相同上下文上高效处理多个决策。

在我了解它的工作原理并尝试自己实现这个想法时，我产生了一个疑问：这种判断真的需要额外的微调吗？

语言模型已经学会了在给定上下文下不同文本续写的概率。我的直觉是，如果选项用词语表达并且有含义，那么模型在读完问题和选项之后，应该已经会倾向于某些答案。一个训练得足够好的模型，或许已经能够利用它学到的语言分布来分辨哪个选项更契合问题。

我们能否直接从分布中读出这种偏好，并用它来做选择，而不需要再为决策进行一轮微调？

这是我最想验证的想法：也许做出判断的能力早已存在于模型之中。我们通常让它以文本形式生成答案，但也许我们可以直接读出判断。

对于像 Jeff 和 Laya 这样经过专门训练的模型，我还有另一个怀疑：它们会不会过度适应微调时所针对的那类任务，存在严重的过拟合？在熟悉的任务上表现好是一回事。当我给它们出我自己的问题时，又会怎样？

因此，在主要测试中，我使用了一组我自己关心的问题，而不是复用那些模型微调时所用的任务集。我的首要目标是看看现有模型的概率偏好能否直接支撑有用的决策。我还想看看这些专用模型的优势有多少能迁移到不同的任务上。

直接读取模型中已有的判断

我使用了现有的 Qwen 和 Gemma 模型，没有进行额外的决策微调，也没有新训练分类头。

方法很直接：让模型读取上下文、问题和可选答案，然后取最终输入位置上答案标签的分数——也就是 logits。用这些分数来做选择，而不让模型逐 token 生成答案。

这仍然需要对整个模型做一次前向传播；在缓存允许的情况下，输入前缀可以复用。它跳过的是后续的文本生成。这些分数让我能比较答案，但不能直接解释为某个决策正确的概率。

我想弄清楚的是：在没有额外微调的情况下，模型已有的概率偏好能否在我自己的任务上变成有用的判断？

换一组问题会怎样？

我用自己构建的同一组问题，将这些直接评分的版本与包括 Jeff 和 Laya 在内的本地决策模型进行了比较。以下是主要结果，为便于阅读做了取整。

Jeff 是一个独立项目。我在这个实验中没有直接测试 TypeSafe 的 Jev。

这些测试在配备 64 GiB 内存的 M2 Max 上运行。准确率基于 300 个固定测试输入；计时涵盖重复运行中的有效调用，不包括模型加载和上下文准备。因长度被 Laya English 拒绝的输入仍计入其准确率分母。CLM 的所有正确结果都来自回退决策。模型大小、量化和输入格式各不相同，因此这不是对微调效果的受控比较。

对我来说最重要的是这一点：小型专用模型可以非常快，但有用的判断并不一定需要额外训练。Gemma 的直接评分在本次测试的配置中接近最高准确率。它并没有解决所有问题，但足以让我认真考虑使用已有的模型。

作为参考，我还测试了公开的 Typed Decisions 数据集。Laya Typed Decisions 在该数据集上得分约 77%，而在我的问题上约为 51%。这一差距加深了我对任务过拟合的怀疑。但任务、语言和输入条件同时发生了变化，因此仅凭这一比较无法确定过拟合就是原因。我关心的问题是，在熟悉任务上的表现能否迁移到我实际需要的任务上。

更仔细地看，一些模型能够选出答案，却难以识别何时不应直接做出选择。我的两个通用基线也有这个问题。这比继续比较几个百分点更重要：一个工作流需要的不仅仅是一个能选出答案的模型。

同一个模型可以走更快的路径

我还比较了直接评分与使用相同 Gemma 权重的完整生成流水线。这是一项单独的离线测试，因此其结果不应与第一张表合并。

两条路径都对 53 个测试输入各运行了两次，失败也计入计时。完整生成流水线还包括解析、验证以及需要时的修复，而两条路径的运行时和缓存机制不同。因此，这个实验改变的不仅仅是是否生成文本。直接评分的上下文准备单独计时，在缓存未命中时大约需要五秒。

这次比较让我感兴趣的是，同一个模型的能力可以通过不同方式获取。做出判断并不总是需要走完整的生成流水线。

直接评分仍有其适用范围限制。在本次测试中，它无法处理那些无法通过可用选项表达的请求；完整生成流水线在这些请求上也不可靠。这张表给了我保留一条受限决策路径的理由，但它并未表明这条路径可以取代所有生成能力。

更快的决策值得再引入一个模型吗？

如果任务稳定，且工作流只需要频繁做出决策，那么一个小型、快速的专用模型确实很有吸引力。

但我更感兴趣的是另一种情况：一个本地工作流已经需要一个模型来撰写回复。

一条输入的句子可能需要做出决策，也可能需要给出书面回答。系统必须先区分二者，才能选择路径。把这项工作拆分给两个模型，就会引入路由、切换、回退和维护等问题。如果两个模型都在本地运行，它们是否都需要常驻内存也很重要。

如果现有模型无论如何都得运行，并且已经能做出有用的判断，那么把决策和回复都交给这个模型可能更合适，即使单个决策耗时更长。

Jev 本身就有一种用决策来路由请求的设计。问题在于，把额外成本算进去后，这一额外层对特定工作流究竟有多大好处。单个模型也需要一种方式来区分何时做决策、何时做回复；使用一个模型并不能自动解决路由问题。

这些实验没有比较使用一个模型与两个模型的完整工作流，但它们为我目前所做的选择提供了依据。

到目前为止，我还没有在我的工作流中加入一个单独的、专用的决策模型。我改变的是调用现有模型的方式：当需要做出选择时，我直接读取答案标签的 logits，让它也能返回一个决策。

在我撰写这篇文章期间，一篇题为LLM-as-Jev: LLMs Are Already Jev-Style Decision Models—When and How to Fine-Tune Them的论文也发布了。它的主要发现之一与我的观察相似：能力足够的现有语言模型无需额外微调，也能直接做出有用的决策。