企业官网建设流程全解析

审计里的 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%）。审计场景不可接受——查错数比不查更危险。

三、路线 B：Schema-Aware Prompt

把数据库 Schema（表名、字段、注释、样例数据）塞进提示词，让模型在已知结构下生成 SQL。

• 优点：准确率显著提升，能处理多表 JOIN；
• 缺点：Schema 很长会超上下文，需裁剪；仍可能选错近似字段；对"期末余额"这类需计算的语义仍易错。

四、路线 C：Agent 多步校验

让 Agent 分步工作：①理解意图并定位相关表；②生成 SQL；③在影子库先执行看是否报错、结果是否合理；④不对就修正重跑；⑤返回带说明的结果。

• 优点：执行校验能拦掉大部分语法/语义错误，结果可信度最高；
• 缺点：多步调用延迟高、成本高；需要可安全执行的沙箱库（只读、脱敏）；复杂跨年合并查询仍可能绕晕。

以审小匠是什么这类产品为例，它提供的"审计师用中文查数据"能力，底层正是 Schema 感知 + 执行校验的路线：先把清洗后的科目余额表、序时账等结构化进库，再让模型在已知 Schema 下生成查询并实际执行校验。代价也很现实——前提是数据已经清洗入库，对未标准化的原始账套要先做清洗；涉及多科目、跨年度、合并抵消的复杂查询，模型生成的 SQL 仍需审计师确认后再用，不能盲信。

五、工程对比矩阵

六、工程落地要点

• 必须有可执行的影子库：只读副本 + 脱敏，避免模型误执行写操作；
• 结果要可解释：返回 SQL + 行数 + 取样，让审计师能验证；
• 高风险查询加人工确认：凡是涉及调整分录、合并抵消的，SQL 先给审计师过目再跑；
• Schema 要持续同步：客户改科目表后，提示词里的 Schema 必须同步更新，否则准确率断崖。

小结

Text-to-SQL 在审计里不是"玩具"，但绝不能当"黑盒"。智能审计工具把这项能力做扎实的关键，不在模型多大，而在三件事：Schema 接得准、执行前先校验、结果给审计师看得到。把"中文查数"定位成"审计师的查询助手"而非"自动出数机器"，才是工程上站得住的用法。