只做选择题的AI模型到底行不行，一个开发者用150行Python试了出来
Two techniques for working with System One models
我最近写了关于 Jev 的文章，它是一个新的“System One”语言模型，只输出决策：即用户提供的多项选择问题的一组答案。这意味着它远不如 ChatGPT 这样的传统 LLM 灵活[^1]，但回报是它始终如一地快。
我们并不确切知道 Jev 是如何工作的。我见过有人说扩散，有人说对 Transformer 架构的各种调整，也有人说某种全新类型的模型。但这并不重要。正如我在此处论证的，将任何 LLM 变成 System One 模型并不难。通过批量处理使用结构化输出生成单个 token 的提示，你就能得到一个始终如一地快速的通用分类器。我在这里用大约 150 行 Python（其中大部分是错误处理）快速凑出了一个基本版本来玩。
注意这并不需要修改模型。只要你能访问 logits（用于结构化输出）并能将数据预填入提示，你就可以把任何 LLM 变成通用的快速分类器。用这种模型编程是什么感觉？在为我那个库连接演示时，我学到了两种想写下来的技巧：设定分层目标和锦标赛选择采样。
Doom
这是 Qwen3-8B 在玩 Doom：
将这段视频与同一个模型使用常规工具调用玩 Doom 的视频相比，很明显 System One 版本的模型做了更多事情，反应也更快。工具调用模型大约每 600ms 做一次决策，而 System One 模型每 190ms 做六七个批量决策[^2]。
Qwen3-8B 和 Jev 都只是文本模型，所以两个演示都需要一个步骤将游戏状态转换为文本。然而，通过选择多模态 LLM，支持图像（或音频）输入是微不足道的。
目标和子目标
实现 Doom 演示的有趣之处在于，仅仅将游戏输入作为选项提供并不太起作用。单次前向传播——200ms——足以对当前游戏状态做出反应，但不足以带来足够的计算量来推导当前的短期目标（例如“杀掉这个敌人”、“捡起这个道具”）并选择去执行它。当我这样连接时，模型 100% 的时间按住“射击”按钮（为什么不呢，我想），然后漫无目的地在这个关卡里游荡。
解决办法是定期让模型在一组固定的短期目标（例如“收集护甲”、“杀死敌人”）中进行选择，然后将该目标包含在每 200ms 的常规提示中。如果你看 Jev 演示中的 Doom 视频，你会看到他们正是这样做的。当我这样做之后，我的模型开始更像人类一样玩。
这是使用 System One 模型的一个有趣技巧。从某种意义上说，它等同于常规的 LLM 推理，因为它提供了一种在同一个问题上使用更多计算量的方法。我可以想象一个实时系统以这种方式管理多层目标：
- 每十秒循环设置整体战略目标
- 每五秒循环基于 (1) 设置战术子目标
- 每秒循环将当前战术子目标分解为具体目标
- 一个尽可能快运行（例如每 100ms）的紧密内循环，控制实际激活哪些输入
这种总体结构对于任何做过游戏或机器人 AI 的人来说都应该相当熟悉。理论上你可以用真正的 LLM 替换 (1)，并让它为步骤 (2) 和 (3) 生成选项列表。实际上我怀疑这会很难搞对，更好的做法是提前写下所有可能目标的列表。这对于玩游戏和已充分理解的任务来说应该完全够用。
Wikiracing
我还重新实现了 Jev 发布帖中的 Wikiracing 演示，模型必须从维基百科的“baseball”页面开始，尽可能快地导航到“sun”页面。你可以在这里观看该视频，虽然它不如 Doom 演示那么令人印象深刻。
Doom 演示的难点在于让模型足够快地循环并致力于短期计划。对于 Wikiracing，难点在于规模：“baseball”的维基百科页面有超过一千个内部链接。Jev 对单个问题只支持 255 个选项，而我拼凑的 System One 层也类似。虽然从技术上讲它可以扩展更多选项，但在一百个左右之后就不好用了[^3]。
Jev 的做法是“先独立评分，然后做出明确选择的两阶段系统”。这对我来说效果很不好。我认为 Jev 在这里受益于它专门针对给出置信度估计进行训练。Qwen3-8B 给几百个链接打了相同的最高分，这没什么用。结果花了很长时间才找到两个页面之间一条三十到四十个链接的路径。
我改用的方法是锦标赛采样：每次给每个选择喂入一百个链接，然后对选出的链接进行第二轮。效果很好。模型找到了理想的三链接路径（如果你好奇的话，是“baseball”/“scientific american”/“amateur astronomy”/“sun”）。如果你想在众多选项中找出最佳那一个，我推荐这种模式。普通 LLM 在相对判断上比绝对评分强得多。
结论
我仍然对 System One 模型的潜力持乐观态度——快速通用分类器——用于构建不只是聊天机器人的 AI 系统。感觉这是在实时场景或需要可预测推理时机的用例中，工具调用的一个有意义替代方案。就像通用 LLM 常常胜过特定领域模型一样，我认为通用 System One 模型有时也会胜过特定领域分类器（尽管它们总会更大、更慢）。
我确实认为大实验室肯定会尝试通过发布他们小而快模型的仅选择版本来竞争。如果 Jev 获得任何发展势头，我们很快就会看到 System One Terra 和 System One Haiku，而且我们肯定会看到我那个快速凑出的 System One 库的“真正”版本。我们现在就应该开始找出用这些模型编写程序的最佳方式。
你可以把 System One 模型看作通用分类器。不必为每项任务训练一个新分类器，你可以使用一个 System One 模型。它会比定制分类器模型更大、更慢，但灵活得多，而且你可以通过调整提示来调整它，而不是重新训练模型。
[^1]: 从技术上讲，你可以给它“下一个字母是什么”的多项选择问题，让它表现得像正常的自回归 LLM，但那实际上不会太好用。
[^2]: 我在 4090 上开始，它能每 500ms 做一次决策，但对 Doom 来说还不够快。我本可以进一步优化，但我只是租了一个 H100 十分钟来录制演示，循环降到 190ms。我同样在 H100 上录制了工具调用 Doom 演示，所以这是公平比较。
[^3]: 这里有一个有趣的研究问题，关于如何实现这种选择，因为它们必须能被单个 token 预测。我从索引开始，但发现“标签”（只是挑一个 token 与选项关联）在 Wikiracing（虽然不是 Doom）上表现好得多。你必须有多个选项才让标签优于索引？当然，你可以修改模型直接输出选择，但我喜欢在推理代码中为任何 LLM 做到这一点的想法。