Text2SQL 评测先固定什么：读 10 月 Agentic Analytics Benchmark

Text2SQL准确率突然变化，不一定是模型变聪明了，也可能是数据库更新后某道题的标准结果变了。10月20日ClickHouse发布的Agentic Analytics Benchmark第二轮特意固定引擎和会话时区，并说明此前引擎变化曾影响题目金标。

它的201道题、合成仓库和预算构成一个明确评测环境。文章里的模型排名只能在这个环境里理解，不能换个Schema就当企业验收分数。

原理示意，非真实系统截图或性能测量。

先冻结能改变答案的东西

下面的manifest示例不跑模型，只验证配置可以被稳定编码与比对。数据库版本用“demo-engine”明确表示演示值，不伪装成已安装的ClickHouse。

import hashlib, json def digest(obj): raw = json.dumps(obj,sort_keys=True,separators=(",",":")).encode() return hashlib.sha256(raw).hexdigest() manifest = { "engine":"demo-engine", "timezone":"UTC", "dataset_hash":hashlib.sha256(b"synthetic-case-v1").hexdigest(), "max_turns":3, "answer_protocol":"rows-as-multiset-v1" } reordered = dict(reversed(list(manifest.items()))) assert digest(manifest) == digest(reordered) changed = dict(manifest, timezone="Asia/Shanghai") assert digest(manifest) != digest(changed) print("PASS stable manifest; timezone drift detected")

这里只固定了部分条件。真实运行还应保存Schema、数据快照、模型精确ID、提示版本、工具权限、停止条件与裁判规则。manifest的hash能帮助识别配置变化，但不能证明配置内容正确。

“执行成功”要拆开看

第一层是SQL能否被目标引擎接受。第二层是返回结果是否与业务金标一致。第三层是问题根本不该作答时，系统有没有说明缺少什么。

10月15日的PremiseSQL把错误前提与拒答纳入研究。增强拒答倾向还可能误拒正常问题，因此不能只报告“危险问题拦住了多少”，要同时报告正常问题被挡住多少。

结果比较也有细节：没有ORDER BY时按多集合比较；有明确顺序要求时，行序就是答案的一部分。浮点容差、金额精度、NULL和重复行都应在跑分前写清。不能看到某个候选得分低，再修改规则让它过关。

训练和评测之间留一条线

Spider 2.0项目提醒，不宜将公开Gold SQL直接用于SFT后再声称得到公平评测。企业内部也一样：拿失败题反复调提示，再把同一题计入最终准确率，得到的是开发集表现。

本地仅运行了manifest一致性示例，Python 3.9.6通过。没有训练、调用或测评任何模型。下一轮应该先留出独立题集，再在同预算下比较全量Schema、裁剪和纠错策略；失败和拒答也要进入分母。

本地示例使用Python 3.9.6；保存完整Python块为demo.py后可用python3 demo.py复现。示例只验证文中限定的逻辑，不代表已接入数据库或模型。