桌上笔记本电脑与绿植的安静工作台

一个被问了十年的问题

2015 年，Leis 等人写过一篇论文，问的是「查询优化器到底好不好用」。十年后他们又写了一遍，结论差不多：还是不怎么样。这件事乍看很反直觉——数据库明明知道表里有什么、有多少行、分布如何，挑一个执行计划能有多难？答案是真难。查询优化里最核心的一环，连接顺序的选择，本身就是 NP-hard 问题。

这次的做法：把优化变成可判分的题目

一位工程师把这个问题重构成了机器学习的题目。他的逻辑很干净：挑选好计划很难，但验证一个计划好不好却很容易——跑一遍，看耗时。有了单一、可度量的目标，问题就退化成强化学习最擅长的形态：只奖励更快的计划。

实验用的是一个 40 亿参数的开源模型，走监督微调加智能体式强化学习两步。初始状态下，这个模型在 113 条重连接查询里有 99 条根本产不出合法计划；经过训练之后，作者给出的成绩是整体延迟下降 44.7%（标题里那个「快 81%」是更激进的口径）。为了让测量可信，他还专门搭了一套 Postgres 测量环境来压低 Linux 页缓存的争用噪声，并把训练和推理拆到两台机器上跑。

真正的教训在奖励函数里

文章里最有价值的一段，其实是失败经验。最初的奖励设计对「产出非法计划」罚得很重，结果模型被吓坏了：它开始反复提交 Postgres 的默认计划，宁愿接受一个很小的扣分，也不愿冒险。用作者的话说，模型变得「胆小」。这不是模型能力问题，是目标函数问题——当你惩罚错误远重于奖励正确，理性策略就是什么都不做。

后来他为此改造了 GRPO 的做法，让优势估计在噪声环境里更稳，同时调整了惩罚结构。这段经历对所有做 AI 落地的人都是一次提醒：奖励函数不是工程细节，它本身就是产品需求。

为什么小模型能赢

这个案例最值得记住的不是参数量，而是边界。任务被限定得很窄：输入是固定的 schema 和查询，输出是执行计划，评价标准只有一个——快不快。窄边界加上清晰反馈，才是小模型能越级挑战的土壤。

反过来说，很多企业在做的事正好相反：边界模糊、目标不清、反馈要等三个月。这种情况下换多大的模型都不会有效果。可验证性才是 AI 落地的第一性条件，不是模型规模。