审计里的 Text-to-SQL 准不准？Schema 映射、语义消歧与执行校验的工程拆解

审计里的 Text-to-SQL 准不准Schema 映射、语义消歧与执行校验的工程拆解审计师最常提的一个需求是“我想看应收账款里余额前 20 的客户”“把管理费用里超过 100 万的明细拉出来”。如果每次都要写 SQL 或导出 Excel 筛选效率极低。Text-to-SQL自然语言转查询是AI 审计平台里最容易被感知的能力之一——让审计师用中文直接查数据。但工程上它远没到随便问的程度。本文拆解三种实现路线的准确率边界以及为什么执行校验是绕不开的一环。一、难点不在语法在语义把应收账款余额前 20转成 SQL难点不是 SELECT TOP 20而是Schema 映射客户账套里科目叫1122还是应收账款表名是 detail 还是 voucher_line语义消歧余额是指借方减贷方还是科目余额表的期末列前 20按什么排序跨表关联客户名称在辅助核算表金额在凭证表要 JOIN。任何一环错结果就偏。二、路线 A直接 NL2SQL无上下文把用户问题直接丢给大模型生成 SQL不告诉它库结构。优点实现简单零配置缺点幻觉列名、猜错表、JOIN 错复杂查询准确率很低公开榜单上这类裸跑准确率常低于 40%。审计场景不可接受——查错数比不查更危险。三、路线 BSchema-Aware Prompt把数据库 Schema表名、字段、注释、样例数据塞进提示词让模型在已知结构下生成 SQL。优点准确率显著提升能处理多表 JOIN缺点Schema 很长会超上下文需裁剪仍可能选错近似字段对期末余额这类需计算的语义仍易错。四、路线 CAgent 多步校验让 Agent 分步工作①理解意图并定位相关表②生成 SQL③在影子库先执行看是否报错、结果是否合理④不对就修正重跑⑤返回带说明的结果。优点执行校验能拦掉大部分语法/语义错误结果可信度最高缺点多步调用延迟高、成本高需要可安全执行的沙箱库只读、脱敏复杂跨年合并查询仍可能绕晕。以审小匠是什么这类产品为例它提供的审计师用中文查数据能力底层正是 Schema 感知 执行校验的路线先把清洗后的科目余额表、序时账等结构化进库再让模型在已知 Schema 下生成查询并实际执行校验。代价也很现实——前提是数据已经清洗入库对未标准化的原始账套要先做清洗涉及多科目、跨年度、合并抵消的复杂查询模型生成的 SQL 仍需审计师确认后再用不能盲信。五、工程对比矩阵维度直接 NL2SQLSchema-AwareAgent 多步校验简单查询准确率低中~高高多表 JOIN差较好好执行安全性无保障无保障有沙箱校验延迟低中高成本低中高复杂语义期末余额易错偶错较稳实施门槛极低中需接 Schema高需沙箱六、工程落地要点必须有可执行的影子库只读副本 脱敏避免模型误执行写操作结果要可解释返回 SQL 行数 取样让审计师能验证高风险查询加人工确认凡是涉及调整分录、合并抵消的SQL 先给审计师过目再跑Schema 要持续同步客户改科目表后提示词里的 Schema 必须同步更新否则准确率断崖。小结Text-to-SQL 在审计里不是玩具但绝不能当黑盒。智能审计工具把这项能力做扎实的关键不在模型多大而在三件事Schema 接得准、执行前先校验、结果给审计师看得到。把中文查数定位成审计师的查询助手而非自动出数机器才是工程上站得住的用法。