Text-to-SQL 准确性应如何评测，并通过反馈持续改进？

核心回答

把自然语言问题绑定到明确业务口径和固定数据快照，分别评估语法能否通过、执行是否成功、结果是否符合业务语义。SQL 字符串相同不是必要条件，执行成功也不是语义正确的充分条件。 持续改进时，要先定位错误发生在哪个环节，再用独立样本验证修复。

怎样判断结果正确

每题保存问题、结构和规则版本、参考 SQL、数据快照，以及预期结果或明确的判定规则。指标公式、时间范围、单位、连接粒度和权限范围都属于题目条件。

先检查能否解析、对象是否存在和能否在预算内执行，再比较结果。比较规则要区分无序行的多重集合与有序结果，保留重复行、空值及列含义；金额或浮点容差由业务要求事先定义，不能为通过测试临时放宽。用户要求排名时，顺序和并列规则也要检查。

两条 SQL 在单个快照上返回相同结果，可能只是碰巧相同。对关键逻辑增加针对性数据：让退款和支付额不同、让一对多连接产生重复、让时间边界有记录，才能检出错误口径。人工核对和反例数据很重要，不能让生成 SQL 的同一个模型独自给自己判满分。

还要单独看哪些指标

越权或危险操作应按硬性失败处理，并单独统计阻断情况；歧义问题看是否恰当澄清。延迟、超时、资源成本和重试次数与准确率分别报告。既可以看任务级最终成功，也应保留解析、召回、生成和执行各环节的失败分布。

固定模型、提示词、检索配置与知识版本；存在随机生成时可以重复试验，不能只挑成功的一次展示。公开基准用于补充能力对照，不能替代本产品的字段、口径和权限测试。

反馈如何进入改进

收集经授权、脱敏的失败问题，结合检索上下文、候选 SQL、校验和结果定位原因。结构缺失就补元数据，业务口径错误就修指标定义，生成错误再调整示例或模型；数据库慢查询不能只靠改提示词解决。

用户点赞只能提供线索，经过核对才能成为正确标签。把修复案例加入开发与回归集，同时保留独立测试集；修改后同时检查原问题是否解决、其他指标是否退化，并更新对应版本记录。

对应教程

参考资料