开源 Laya 能替代 Jev 吗：14 道 SQL 只对 6 道，微调 3.9 小时后

中文旁白 · 720p · 字幕轨道 · MP4

文章：给 Laya 做微调后，SQL 安全判断从 7/14 提升到 14/14

把 AI 放进业务流程时，很多场景并不需要它写一大段解释，只需要它在几个选项里选一个。比如一封咨询邮件该转给销售还是客服，一条 SQL 能不能直接上生产环境。

专门做这类判断的 AI，叫作“决策模型”。Jev 和 Laya 都属于这一类。它们不生成文章，而是接收一段描述当前状态的文字和几个带类型的问题（多选、打分、是非），然后返回每个选项对应的概率。两者接受的请求格式完全相同，所以可以把一模一样的输入分别发给它们，直接比较答案。

Jev 是 TypeSafe 提供的闭源服务，只能通过 API 调用，看不到内部。Laya 则由 Convai Innovations 以 Apache 2.0 协议开源，底座是双向编码器 ModernBERT，只有约 4.21 亿参数，在 Mac 的 CPU 上就能运行。模型公开意味着可以用自己业务的数据继续训练它，也就是“微调”。

这次我选的题材是 SQL，也就是操作数据库的语言。我想知道：把 SQL 的判断样例教给 Laya 之后，它能进步到什么程度？和 Jev 相比又如何？

先说清楚要判断什么

审查 SQL 时，“执行起来安不安全”和“能不能得到想要的结果”是两个不同的问题。

比如一条删除订单的 SQL，如果条件写错，会把本该保留的数据一起删掉，这是安全性问题。而一条把销售额重复计数的统计 SQL，虽然不会改动任何数据，却会返回错误的金额，这是正确性问题，也就是逻辑是否符合意图。

为了检验模型能否分清这两者，我手写了 14 条 PostgreSQL 语句，其中既有可以直接上线的正确语句，也有各埋了一个 bug 的语句。bug 包括：JOIN 写错导致求和被重复计数、写成 = NULL 导致条件永远不成立、DELETE 把 OR 写错而多删两年的订单、UPDATE 漏写 WHERE 而改掉整张表、误用 CROSS JOIN、在 8000 万行的大表上建索引却没加 CONCURRENTLY 而锁表、BETWEEN 多算进一天，以及残留的注入条件让 WHERE 永远为真。

在不做微调的情况下，Laya 的安全性判断 14 道只答对 7 道，正确性判断只答对 6 道。作为对比，Jev 的安全性 14 道全对，正确性答对 13 道。这里用的 Laya 是官方公开的三个版本中成绩最好的 typed-decisions 版。

原样使用时差距很明显。那么，如果给它喂 SQL 的样例再做微调，结果会不会改变？

教它正确的例子和错误的例子

官方的训练数据只有客服、发票这类流程，里面没有 SQL，所以教材需要自己准备。我使用了 Hugging Face 上公开的 SQL 数据集（gretelai 的 synthetic_text_to_sql），把原句当作正确的例子，再把其中一处按规则改坏，当作错误的例子。

举例来说，把限定更新对象的 WHERE 条件删掉，原本只改特定订单的 SQL 就变成了修改所有订单的 SQL。其他改法还有把 AND 和 OR 写反、挪动比较符号、让 GROUP BY 少一列等。因为改坏的方式都是固定规则，每条样例的判断标签也按规则自动生成。

这样一共得到 2,924 条教材，其中 2,684 条用于训练，其余 240 条留作评估，训练时不给模型看。

训练沿用 Laya 官方的训练流程，原本跑在两张 T4 GPU 上，我把它移植到了手边的一台 M4 Mac。把教材完整学两遍（2 个 epoch）共花了约 3.9 小时，不需要租用大型计算资源。

安全性提升了，但训练越久不一定越好

训练完成后，我让模型重新判断最初那 14 条 SQL。结果如下：

学完第一遍，Laya 的安全性判断就全部答对，在这 14 道题上和 Jev 打平。

可是学完第二遍，它反而错了一道：把残留注入条件的那条危险 SQL 判成了安全。进入第二遍时训练 loss 已经很低，模型很可能已经开始死记教材，也就是过拟合。可见训练时间加长，效果不一定跟着变好。

另外，这 14 道全对只说明在这批题目上表现良好，并不代表它对任何 SQL 都能判断安全。换一批 SQL 是否同样有效，还需要进一步验证。

判断“SQL 是否正确”的能力，差距仍在

除了安全性，我也检查了 SQL 是否按意图运行。

这一项 Laya 学完第一遍答对 8 道，学完第二遍答对 10 道，仍然不及 Jev 的 13 道。

它漏掉的题目里，有 BETWEEN 把日期范围多算一天的那条，而且 Laya 以很高的概率（0.94）判断它“正确”。= NULL、CROSS JOIN、没加 CONCURRENTLY 的建索引这几条也一样，都被它自信地判成了正确。这意味着“只在它犹豫时请人确认”的做法行不通。

反过来，教材里明确教过的改法，它都学得很快：JOIN 重复计数那条，它给“正确”的概率只有 0.11；残留注入那条只有 0.04。在留出的 240 条评估数据上，安全性的正确率也达到 1.000。问题在于，没教过的 bug 它仍然看不见，而即使教过相近的 bug，换一条 SQL 也可能漏掉。记住教材里的例子，和在新情况下发现问题，中间还有一段距离。

微调确实有效果，但要把 SQL 审查整个交给它，还远远不够。

Jev 对企业的价值：低成本地先试起来

把这个结果放到企业场景中会怎样？以下是基于这次实验的使用设想，并没有在实际业务中测量过效果。

Jev 不需要企业自己训练模型，也不需要准备运行模型的服务器，就能先试用。可以直接拿业务里的实际案例去问它，看看它的判断有多准。

比如一家想自动分派咨询的公司，可以用过去的咨询记录让 Jev 猜负责部门，再和人工标注的分类对比。

它的价值在于省去搭建模型运行环境的负担，把精力集中在验证“对业务有没有用”上。分类和分派也是 Jev 官方介绍里设想的用法。

不过真正交给它之前，还是要用自己公司的案例确认准确率。数据能不能发送到外部服务，也是决定能否使用的条件之一。

Laya 对企业的价值：在公司内部运行，并培养成自己的模型

Laya 可以部署在企业自己的环境里，输入不必发送到外部服务。公开模型和微调方法的说明见 官方模型卡。

同样是分派咨询，如果公司有自己独特的分类方式，又积累了足够多的历史正解，就有可能把它们当作教材。

这时的价值在于能按照公司自己的判断标准去改进模型；想让数据留在公司内部时，这也是选择它的理由。

代价是整理教材、训练、验证准确率这些工作都要自己承担，运行模型的设备也需要成本。即使处理量很大，是否真的比外部服务便宜，也要把这些运维成本算进去再比较。

这次的情况，我会怎么分工

如果想先确认对业务有没有帮助，可以先考虑省去训练和部署准备的 Jev。如果有自己的教材和运维能力，又希望在内部处理，可以考虑培养 Laya。

就这次的 SQL 审查而言，也可以把两者组合起来：已经充分评估过的那部分分类交给 Laya，需要仔细核对 SQL 语义的环节交给 Jev 或人工审查。

不过，单凭 Laya 给出的概率就决定“免审”，恐怕行不通，因为它有过高概率判错的情况。对数据更新、删除等影响较大的操作，应另设规则转人工审查；不能发到外部的 SQL，则在内部确认。

最终要确认的是：审查工作量能否减少，同时把漏检控制在可接受的范围内。这次 14 道全对，是寻找这种用法的第一步。

实验数据和脚本放在 DDnim/jev-vs-laya，各模型的详细成绩和训练条件也请参考这里。日文版视频和日文文章在 /ja/。