项目背景与Laya核心定位

博主小木头在上一期视频中利用两个公开数据集对未开源的决策引擎Jev进行了两轮基本的质量评估，发现其仅通过API提供服务。这引出了一个自然的问题：是否存在可以在本地运行的开源替代方案？近期备受关注的开源项目Laya，官方将其定义为支持多语言、采用非自回归架构的System 1决策系统。它提供与Jev兼容的HTTP接口，返回的数据结构也与Jev相同。

“最近被提到比较多的一个开源项目叫Laya，官方把它称为一个支持多语言采用非自回归架构的System 1决策系统。”

Laya专门处理答案范围明确的决策任务。与Jev类似，用户输入一段state（状态）并提出一组有固定答案空间的问题。问题类型包括choice（多选一）、score（按等级打分）以及noul（返回事件成立的概率，类似布尔型）。模型在一次前向计算中直接给每个候选答案打分，最终返回选项概率和confidence（置信度）。目前支持的英文模型底座为ModernBERT-large，参数规模为4.21亿；此外还有3.22亿参数的多语言版本及针对typed decisions微调的版本。模型权重遵循Apache 2.0许可，托管于Hugging Face。

DataCamp曾将Laya定位为“purpose-built multilingual Jev alternative”，即专门为决策设计、支持多语言的Jev替代方案，并认为其在架构上是目前最接近Jev的项目之一。博主指出，通俗来讲两者解决的是同一类问题，接口和输出也很接近，但实际效果仍需单独验证。DataCamp也提醒该项目非常新，部分示例缺乏独立的端到端验证。

架构原理与本地部署流程

Laya的设计关键在于使用双向encoder。输入中包含问题选项和状态，每个候选选项都有独立的marker。模型读完整段输入后，decision head直接给这些marker打分，再通过softmax转化为概率值。这种机制省去了文字生成的解码过程，使得新增选项可以沿用同一种输出格式。

“它使用双向encoder输入里包含问题选项和状态每个候选选项都有自己的marker模型读完整段输入以后decision head直接给这些marker打分。”

博主将演示版本固定在0.3.11，使用uv安装依赖。在Apple Silicon Mac上设置device为MPS以利用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选一”问题。

“这组结果中的差距非常大，理解这个差距还需要结合Laya官方写的那个架构限制来理解。”

共计662条样本的ID、state标准答案及questions JSON均从上一期复制，Jev原始响应也保留。新增对Laya provider的支持，将本地模型反馈答案写入JSONL格式文件。运行脚本逐条读取样本：Jev通过OpenRouter调用decisions API，Laya在本机逐条决策。输出由相同的Python脚本score.py处理。

评估指标采用Macro F1和准确率。准确率看总答对比例；Macro F1先计算每个类别的F1再赋予同等权重。在Banking77中每类样本数量一致，两指标接近；但在垃圾短信数据集中正常短信远多于垃圾短信，Macro F1能更明显地反映模型忽略小类（垃圾短信）的问题。

性能延迟与初步运行表现

Laya模型加载完成后，处理200条短信任务耗时约11秒，处理462条Banking77数据耗时约140秒。统计时间为任务执行总用时，不含模型下载、加载及计分脚本运行时间。662次本地任务执行全部顺利完成。

为理解单条延迟，采用逐条调用单独计时。Laya在短信任务上的中位延迟为50毫秒，95分位为66毫秒；在Banking77任务上中位延迟为294毫秒，95分位为354毫秒。作为对比，上一期中Jev的中位数分别为447毫秒和432毫秒。

“两组延迟对应的是完全不同的运行环境，Laya是在我的电脑上运行而Jev呢是通过托管服务访问的服务。”

博主强调，延迟数据反映的是不同使用环境下的等待时间：Laya为本地运行，Jev为云端API调用。因此这些数字仅作为直观参考，不具备极强的直接对比参考价值。

垃圾短信场景决策质量对比

在SMS Spam垃圾短信场景中，Jev答对193条，准确率为96.5%，Macro F1为0.926。Laya答对168条，准确率为84%，Macro F1为0.759。错误分析显示：两边都回答错误的仅有3条；Jev单独答对29条，Laya单独答对4条。

模型 总样本数 正确数量 准确率 Macro F1
Jev (API) 200 193 96.5% 0.926
Laya (本地) 200 168 84% 0.759

在垃圾短信这一相对简单的二分类任务中，Laya虽然准确率低于Jev，但仍具备基本决策能力。Macro F1的下降主要源于对少数类（垃圾短信）识别能力的不足，这符合该指标对小样本类别敏感的特性。

Banking77场景下的性能瓶颈分析

在Banking77的“77选一”场景中，差距显著扩大。Jev答对377条，准确率81.6%，Macro F1为0.806。Laya仅答对183条，准确率降至39.6%，Macro F1仅为0.346。错误分布显示：两边都错74条，Jev单独答对205条，Laya仅单独答对11条。

“因为Banking77正好触碰到了这个限制，Laya官方建议一道choice类型的问题尽量控制在大约20个选项以内。”

这一巨大差距源于Laya的架构限制。所有选项共享固定的head budget，当前模型中该预算约为192个token。当只有5个选项时，每个标签可获得相对完整的说明；但当77个选项挤在一起时，每个标签仅剩约3-4个token，导致意图说明被严重压缩。

Banking77官方报告默认结果为0.425，并明确指出高基数标签空间会让准确率快速下降。官方建议将77个选项拆分为两层：先选大类，再在类内选具体意图。这一策略同样适用于Jev或Laya的未来应用场景。

测试局限性与最终结论

本次实验包含两个英文数据集共662条样本。Laya使用的是支持英文的base checkpoint，测试前保持原始状态未做任何微调。Banking77的77个选项超出了官方建议范围，因此这既是一次真实对比，也是一场超越Laya推荐用法的压力测试。

“当前版本处理11个以上选项时还会限制温度参数temperature，所以返回的confidence并不适合做直接的比较。”

此外，由于Jev运行于云端而Laya在本地，延迟数据反映的是不同环境下的耗时。面对新任务和新数据，最可靠的方式仍是按照相似方法重新评估。

结论

本次实测表明，Laya作为Jev的开源本地替代方案，在简单决策任务（如垃圾短信分类）中具备可用性，但在处理高基数选项（如77个意图的分类）时性能显著下降。这主要受限于其共享token预算的架构设计，导致多选项下标签说明被压缩。官方建议将复杂选择拆分为两级分类以优化效果。对于需要本地部署且选项数量适中（建议20个以内）的场景，Laya是一个值得考虑的备选方案；但在高复杂度分类任务中，其表现尚无法完全平替Jev。