大家好，我是小木头。上一期我用两个公开数据集对 Jev 做了两轮基本的决策质量评估，Jev 并未开源，目前通过 API 提供的服务。这也带来一个非常自然的问题：我们能否找到一个可以在本地运行的开源替代呢？最近被提到比较多的一个开源项目叫 Laya，官方把它称为一个支持多语言、采用非自回归架构的 System 1 决策系统。它提供与 Jev 兼容的 HTTP 接口，返回的数据结构也和 Jev 相同。今天呢我就想直接重用上一期视频中完全相同的数据集、完全相同的问题，咱们原封不动的交给 Laya，看看它和 Jev 的决策质量会有什么样的差别。

接下来我会从安装开始把 Laya 跑起来，再把 Laya 和 Jev 的决策结果交给同一个计分脚本。所有的命令执行呢都是我真实的运行的代码，和原始的响应也会一起的公开，大家可以在视频描述中获取到链接。先简单介绍一下 Laya：Laya 专门处理答案范围明确的决策任务，和 Jev 一样，你给它一段 state，再提出一组有固定答案空间的问题。问题可以是 choice（也就是多选一），可以是 score（也就是按等级打分），还可以是 noul，它返回某个事件成立的概率，就像咱们在编程语言中常用的布尔型那样。

它在一次前向计算里直接给每个候选答案打分，最后呢返回选项概率和 confidence。当前支持的英文模型有 4.21 亿参数，底座是 ModernBERT-large；它还有一个 3.22 亿参数的多语言版本，以及一个针对 typed decisions 做过专门微调的版本。模型权重在 Hugging Face。代码和权重的使用呢遵循的是 Apache 2.0 的许可。

关于 Laya 与 Jev 的关系，我可以采用 DataCamp 一篇文章对它的定位。DataCamp 把 Laya 称为一个 purpose-built multilingual Jev alternative，也就专门为决策设计、支持多语言的 Jev 替代方案。并且认为它是架构上目前最接近 Jev 的项目之一。对于这个说法，我认为通俗的讲呢，他们解决的是同一类问题，接口和输出也很接近。替代方案的描述是这个项目的方向，那么实际效果呢仍然需要做一些单独的验证。

当然了 DataCamp 也提醒到，这波项目呢目前非常新，文章中的一部分示例仍然缺少独立的端到端的验证。今天呢我们就自己来验证一波吧！Laya 的设计有一个很关键的特点：它使用双向 encoder，输入里包含问题选项和状态。每个候选选项都有自己的 marker，模型读完整段输入以后 decision head 直接给这些 marker 打分，再通过 softmax 变成一个概率值。因此它直接完成候选项的评分，省去了文字生成的解码过程。新增选项可以沿用同一种输出格式。

从应用的角度看，输入和 Jev 很像；输出呢当然也很像。但从内部实现看，它是一套我们能够下载、检查和本地运行的模型。Laya 的安装非常简单：我把这一期的演示呢固定在版本 0.3.11 上，用 uv 安装依赖；然后从 Laya 导入 Agent，加载 Laya device。设成 MPS（我会用到在 Apple Silicon 的 GPU 来运行）。第一次运行会从 Hugging Face 下载权重，后面直接使用咱们本地的缓存了。英文权重大约 1.6 GB，本次演示的完整的 Python 环境我看了一下大约在 0.9 GB。

模型开始工作以后呢，在我这台 M3 的 Mac 上 MPS 分配大概 1.6 GB，连同驱动呢整体上占用了大约 2.1 GB。所以实际使用时我会给它预留 2 到 3 GB 的内存，这个呢大家可以来了解一下。CPU 同样可以运行，我做的一个短问题测试中位数大约在 113 毫秒。当然这些数字呢只代表在我目前这台机器上的表现。这次对比完整沿用上期的数据和问题：第一组还是 SMS Spam 数据集，关于垃圾短信的 200 条英文短信是从咱们从数据集中提取出来的一个子集，其中呢 27 条是垃圾短信。问题很简单只有一个：这条短信是不是垃圾？

第二组还是 Banking77，包含了 462 条银行 APP 的用户提问，一共分类为了 77 个意图。咱们每个意图呢抽取 6 条数据，问题实际上就是一个 77 选一：那这条消息属于哪个意图？这 662 条样本的 ID、state、标准答案以及 questions JSON 都直接从上一期复制过来，Jev 的原始响应我们也保留过一份。那唯一新增的就是对 Laya provider 的支持，把本地模型反馈的答案呢也同样写成一份 JSONL 格式的文件。

运行脚本逐条读取同一批样本，Jev 依然走的是 OpenRouter 它的 decisions API；Laya 则在本机逐条决策。两边的输出最后由同样的 Python 脚本 score.py 来处理。这里顺便解释一下 Macro F1：准确率是看 100 道题总共答对多少；Macro F1 会先分别计算每个类别的 F1，再让每个类别拥有同样的权重。这也意味着一个模型即使主要答对了样本中很大的或很多的大类，只要它忽略了小类，Macro F1 就会明显下降。

Banking77 每类样本数量是一样的（这是我们刚才已经约定的每个意图抽 6 条），所以两个指标呢通常都非常接近。垃圾短信里面正常短信远多于垃圾短信，所以 Macro F1 的补充价值会变得非常的明显。Laya 模型加载完成以后在本机逐条处理 200 条短信，大约用了 11 秒；处理 Banking77 的 462 条数据大约用 140 秒。这里统计的是 Laya 完成任务执行的总用时，并不包括下载模型、加载模型和运行这个计分脚本 score.py 的耗时。

662 次的本地的任务执行全部都顺利完成。为了让单条的延迟可以理解呢，我们采用逐条的调用，每一条都单独计时。Laya 在短信任务上的中位延迟呢是 50 毫秒，95 分位是 66 毫秒；Banking77 的中位延迟是 294 毫秒，95 分位呢是 354 毫秒。那上一期中 Jev 的中位数分别是 447 毫秒和 432 毫秒。两组延迟对应的是完全不同的运行环境：Laya 是在我的电脑上运行，而 Jev 呢是通过托管服务我们调用 API 所访问的服务。

因此呢这里延迟表示两种实际使用方式在我自己电脑上的等待时间，并不一定具有特别强的参考价值或者对比的可能性，只是给到大家一个参考直观的体会他们的响应究竟是什么样的。那我们来看看最后的结果吧！先看垃圾短信的场景：同样 200 条，Jev 答对了 193 条（准确率呢 96.5%，Macro F1 是 0.926）；Laya 答对了 168 条（准确率呢是 84%，Macro F1 是 0.759）。把出错部分呢放在一起看：两边都回答错误的只有 3 条，Jev 单独答对 29 条，Laya 单独答对 4 条。

再来看另外一个场景也就是 Banking77（也就是咱们刚才提到的 77 选一的这个场景）：Jev 在 462 条里面答对了 377 条（准确率呢 81.6%，Macro F1 是 0.806）；而 Laya 答对了 183 条（准确率 39.6%，Macro F1 是 0.346）。两边呢都错的是其中的 74 条，Jev 单独答对 205 条，Laya 单独答对只有 11 条。这组结果中的差距非常大，理解这个差距还需要结合 Laya 官方写的那个架构限制来理解：因为 Banking77 正好触碰到了这个限制。

Laya 官方建议一道 choice 类型的问题尽量控制在大约 20 个选项以内，原因是所有选项共享了一个固定的 head budget。当前模型里面这个预算大约是 192 个 token：5 个选项时每个标签能得到相对完整的说明；那 77 个选项挤在一起的时候，每个标签就只剩下大约 3 到 4 个 token。我们给每个 Banking77 意图写的说明会被压缩得非常严重。

从 Banking77 官方的数据看，它报告的默认结果是 0.425，并且明确说高基数标签空间会让准确率快速下降。官方的建议是把 77 个选项拆成两层：先选择一个大类，再在这个大类里面选择具体的意图。看起来这个策略呢也能够广泛应用在 Jev 或者 Laya 模型未来的应用场景中。另外 Laya 官方把它描述成了一个适合继续做任务专门化的快速的底座，提醒用户关注 base checkpoint（它的零样本能力边界）。

官方的 typed-decisions checkpoint 在对应的训练集上微调以后成绩呢也会明显的提升。我们这次使用的是英文的 base checkpoint，测试前保持了它的原始的状态并没有做任何的微调。所以 77 选一既是一次真实的相同条件对比，实际上也是一场超越 Laya 推荐用法的一个压力测试吧！这是大家需要注意的。

那我们总结一下吧：在这一次的实验里面我们包含了两个英文的数据集，一共呢有 662 条样本。Laya 使用的是支持英文的 base checkpoint，测试前保持原始状态没有做任何的微调；在数据集 Banking77 的 77 个选项这就超过了官方建议的范围。而 Jev 是在云端运行，Laya 在本地运行，因此延迟对应两种不同的使用环境。那真实的 API 调用的耗时、任务执行本地化的耗时呢给大家只是一个参考。

当前版本处理 11 个以上选项时还会限制温度参数 temperature，所以返回的 confidence 并不适合做直接的比较。因此这些数字的描述是咱们本次测试的结果，面对新的任务、新的数据最可靠的方式依然是按照相似的方法再做一次评估。这就是本期的主要内容，我们看到了如何本地安装并使用 Laya，也对它做了简单的评估。

你是否已经在真实项目里面用过 Laya 了呢？如果用过，你所面对的是几选一的选择题呢？你做过微调了吗？是否已经开始把大分类拆成两级的方案应用到自己的实战中呢？欢迎在评论区分享你的心得体会吧！我是小木头，那我们就下期再见。