92分门槛逼疯LLM：一个SQL评测引擎如何把成本砍到1/10

去年有个数据团队向我吐槽：他们的文本转SQL系统上线三个月，人工复核成本飙到每月4万多刀。问题不在模型——GPT-4生成的查询看着都对，一跑就崩。更糟的是，他们根本不知道崩在哪。

这像极了工厂质检。你请教授级专家逐件检查螺丝，发现90%的次品只是螺帽没拧紧。这位工程师的解法很产品经理思维：先过一道粗筛，把"螺帽问题"拦在外面，专家只处理真疑难杂症。他的双层评测框架把单次评估成本压到原来的1/10，同时给出了可落地的诊断报告。

第一层：确定性评估，0.5秒内宣判生死

核心代码用sqlglot做语法解析，对比预期结果和LLM输出。检查项很朴素——行数是否匹配、列覆盖率多少、有没有缺join。但组合起来的加权评分很刁钻：0.92分以上直接放行，低于阈值才触发第二层。

这个阈值不是拍脑袋。作者测试了数百条历史失败案例，发现0.92恰好卡在"机器能搞定"和"需要人看"的分界线上。漏过去的假阴性？后续AI层会兜底。但省下的API调用费是实打实的。

代码里有个细节很有意思：列覆盖率计算时，额外列（extra_cols）不计入惩罚，只记录备案。作者解释，业务查询里多出一两列备注字段很常见，直接判死刑会冤枉大量有效查询。这种"抓大放小"的评分策略，明显来自真实业务场景的摔打。

第二层：AI法官，被迫输出结构化JSON

通过第一层的查询，并非高枕无忧。它们拿到一个快速摘要；没通过的进入LLM深度诊断。但这里有个反常识设计：AI不直接给结论，而是填充一张预定义的诊断表格。

表格字段包括缺失元素、根因分类、建议修复方案。作者用Pydantic模型强制约束输出格式，配合litellm的acompletion做异步批量处理。这意味着你可以把失败的查询自动归档，喂给微调流水线——每一次失败都成为训练数据，而不是沉没成本。

提示词工程也有讲究。作者没让模型"分析为什么错了"，而是要求它扮演"资深数据工程师写代码审查意见"。角色设定带来的输出质量差异，在他之前的A/B测试里差了23个百分点。

架构的隐藏成本：没有存储，没有UI

这个框架刻意保持赤裸。没有数据库依赖，没有可视化面板，纯Python函数库。作者的理由很直接：评测引擎不该绑架你的技术栈。你可以把它塞进Airflow DAG，挂到FastAPI端点，或者直接在Jupyter里调试。

但赤裸也意味着责任。行数对比用的是pandas内存计算，万级数据量没问题，百万级就得自己改成分块处理。作者留了注释提醒，却没给实现——他认为这是使用者该做的功课，而不是框架该背的包袱。

另一个未言明的假设：预期结果（expected_df）必须提前准备好。这在离线评测场景天经地义，但想做成实时在线系统，你得自己解决"正确答案从哪来"的问题。作者没碰这个雷区，他的目标用户本就是拥有黄金数据集的团队。

这套代码在GitHub上被fork了1700多次，Issue区最常见的请求是"能不能加个可视化看板"。作者的回复很一致：PR welcome，但主干保持精简。这种克制的产品观，在开源工具里反而少见。

文本转SQL的评测难题，本质是大模型应用的缩影：生成端越来越便宜，验证端越来越贵。当所有人都在卷提示词和微调时，有人回头把评测 pipeline 做成了瑞士军刀——不是最 flashy 的，但是最能帮你省钱的。你的团队现在怎么审LLM生成的代码？还是靠人眼逐行过？