前几天刷 arXiv 看到一篇新论文，8 月 16 号挂上去的，叫 PLSQLBench，讲怎么评估大模型写可执行 PL/SQL 程序的能力。顺手翻了一遍，看完发现真正值得记的不是基准本身，而是它衡量“正确”的方式——不看代码像不像样，只看能不能跑通执行测试。这篇笔记就围绕这一点记，基准的其它细节只挑相关的说。
背景一段话带过。基准一共 2865 个测试实例，2594 个单轮任务，271 个多轮对话（多轮加起来 978 轮），任务来源有三块：企业风格 Spider 2 数据库上的复杂模式绑定任务、Spider 派生的较简单任务、MBPP 派生的程序性问题任务。作者团队 16 个人，第一作者是 Marianne Menglin Liu。这些数字本身不用记，记了也会忘，我记这篇的方式是把它的评估思路拆开看看，然后自己跑一个小实验验证一遍。
为什么“执行测试”这一条值得单独记
论文里有个论断，我一开始没觉得多重要，后来才想明白它戳的是什么：程序性数据库编程的能力，没法被传统的代码生成基准或者 text-to-SQL 基准直接评估。反过来讲就是——你拿一个模型在 HumanEval 或者某个 SQL 基准上的分数，去推断它写存储过程、写异常处理块的水平，推断不出来。PL/SQL 是过程式的，有控制流、有异常处理、有跨轮对话里的一致性要求，这些维度在“生成一条查询语句”的评估里根本不出现。
评估方式上，它用的是执行结果作为正确性标准。生成的代码不是给人看的，是丢给数据库跑的，跑通了、结果对了才算对。这个标准朴素，但比“看起来对”严格得多。我自己的体会是，让模型写一段带异常处理的 PL/SQL 块，肉眼读一遍经常觉得挺像回事，真丢进去跑，游标没关、异常分支漏了一种情况，各种小毛病就出来了。“能跑”和“看着对”之间的差距，在过程式 SQL 这块比在普通应用代码里还大。
论文里对八个模型的实验也印证了这个差距：模型普遍在模式绑定、方言保真度、过程控制流、异常处理、跨轮一致性这几个地方翻车。工具增强的 agent 在若干模式绑定评估上表现更好，但整体性能仍有明显差距。模式绑定这个点我特别有共鸣——模型经常凭训练数据里的惯性猜字段名和表结构，而不是老老实实去读 schema，这种错误在执行测试面前藏不住，在“读代码觉得差不多”面前藏得很深。
顺手做的一个小验证
看完论文我顺手试了一下，想验证“执行标准比肉眼审查严格”这件事在自己的工作流里是不是成立。做法很土：
- 找一个自己项目里真实存在的库，把某几张表的结构导出来；
- 让模型写一个带循环和异常处理的 PL/SQL 过程，需求里故意包含一个边界情况（空结果集时的行为）；
- 先自己读一遍代码，记下我觉得有没有问题；
- 再在测试库里实际执行，构造一个空结果集的场景跑一遍。
结果是第 3 步我读的时候觉得没问题，第 4 步跑的时候空结果集直接抛了 NO_DATA_FOUND，因为 SELECT INTO 没做异常分支。这个坑小到不好意思写出来，但它恰好就是论文里说的“异常处理”那一类失败——而且是我读代码的时候漏掉的。这条记下来了，下次应该用得上：边界情况不要靠读代码确认，构造数据跑一遍才是真的确认。
💡 小技巧：让模型在写代码之前先输出一遍“这段过程会处理哪些输入情况、每种情况走到哪个分支”，拿着这份清单去构造测试数据，比自己凭空想边界情况覆盖得全。
和我之前一个习惯对上了
之前记过另一篇笔记，讲的是看不懂的代码不该用，哪怕它能跑。这篇论文算是从评估的角度给了同一个判断的另一面：只看“能不能跑”的评估会漏掉过程式 SQL 里的结构性弱点，只看“代码写得像不像”的评估漏掉的更多。PLSQLBench 的价值在于它把标准钉在执行结果上，同时把任务设计成逼模型暴露模式绑定和异常处理能力的形式——这两件事合在一起，才让“模型到底会不会写 PL/SQL”从一个印象问题变成了一个可测量的问题。
作者公布了代码链接，我还没来得及完整跑一遍基准，只跑了上面那个自造的小实验。等哪天真把基准在本地复现了，再来补一篇。这里先留一个坑。
划重点：第一，评估生成代码的正确性，执行测试比肉眼审查严格，过程式 SQL 尤其如此；第二，模型在模式绑定和异常处理上的翻车是系统性的，不是个别模型的毛病，这两块要重点盯；第三，边界情况靠构造数据跑出来验证，不靠读代码的时候“感觉没问题”。你可以照着我那个四步的小验证在自己的库上试一遍，尤其是第 3 步和第 4 步之间的落差，试一次就知道我在说什么。