Text2SQL准确率突然变化不一定是模型变聪明了也可能是数据库更新后某道题的标准结果变了。10月20日ClickHouse发布的Agentic Analytics Benchmark第二轮特意固定引擎和会话时区并说明此前引擎变化曾影响题目金标。它的201道题、合成仓库和预算构成一个明确评测环境。文章里的模型排名只能在这个环境里理解不能换个Schema就当企业验收分数。原理示意非真实系统截图或性能测量。先冻结能改变答案的东西下面的manifest示例不跑模型只验证配置可以被稳定编码与比对。数据库版本用“demo-engine”明确表示演示值不伪装成已安装的ClickHouse。import hashlib, json def digest(obj): raw json.dumps(obj,sort_keysTrue,separators(,,:)).encode() return hashlib.sha256(raw).hexdigest() manifest { engine:demo-engine, timezone:UTC, dataset_hash:hashlib.sha256(bsynthetic-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, timezoneAsia/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复现。示例只验证文中限定的逻辑不代表已接入数据库或模型。
)
)
)
