Chat2DB 智能问数工程化：从 Schema 理解到 SQL 审核闭环
Chat2DB 智能问数工程化：从 Schema 理解到 SQL 审核闭环
自然语言生成 SQL 的演示往往很顺利：输入“统计上月各地区新增客户数”，模型给出一条查询，执行后返回结果。但真实数据库环境很快会暴露另一面：同义字段散落在不同表中、指标口径没有写进字段注释、历史表与实时表并存、权限按部门拆分，甚至同一个“新增客户”在销售和财务系统里有不同定义。
因此，智能问数不是在聊天框后面接一个大模型。它是一条从业务问题到可信结果的受控数据链路，至少包含语义理解、Schema Grounding、SQL 生成、风险检查、受限执行和结果解释六个阶段。任何一环缺失，都可能把“看起来正确”放大成“稳定地产生错误”。
一、先定义指标，再生成 SQL
模型最容易犯的错误，不是 SQL 语法错误，而是业务口径错误。比如“销售额”可能指含税订单金额、已支付金额、已确认收入或扣除退款后的净额。SQL 即使成功执行，也不代表回答了正确的问题。
生产级智能问数需要一个轻量语义层，至少记录：
- 指标名称、业务定义和计算公式；
- 时间粒度、默认时区和统计截止规则；
- 可用维度及维度之间的层级关系；
- 事实表、维表和推荐 Join 路径；
- 负责人、版本和最近校验时间；
- 常见同义词、禁用旧口径和反例。
语义层不必一开始就建设成庞大的指标平台。可以先从高频问题中抽取二十个核心指标，用结构化文档维护定义，再把这些定义作为生成上下文。关键是让模型引用已确认口径，而不是临时猜测口径。
二、Schema Grounding 不是把全部建表语句塞给模型
当数据库有几百张表时，把完整 DDL 发送给模型会带来三个问题：上下文成本增加、无关信息干扰生成、敏感表结构被过度暴露。更稳妥的方法是分层检索。
第一层根据问题识别业务域，例如订单、库存、会员或结算；第二层召回相关表和视图；第三层补充字段注释、主外键、样例值类型和少量已验证查询；最后只把与当前问题有关的 Schema 交给生成器。
召回结果还需要可信度排序。推荐优先级通常是：经过治理的主题视图、指标口径指定表、带完整注释的业务表、历史查询中稳定使用的表，最后才是名称相似但缺少说明的表。这样可以减少模型因为表名相近而选错数据源。
三、把 SQL 生成拆成“计划”和“语句”
直接让模型输出最终 SQL，不利于发现逻辑偏差。更可检查的流程是先生成查询计划：
- 识别指标、维度、过滤条件和时间范围；
- 说明选择哪些表以及 Join 原因；
- 明确聚合口径、空值处理和去重规则；
- 列出可能存在歧义的业务词；
- 在确认计划后再生成 SQL 初稿。
这个中间层让开发者、数据分析师或 DBA 能在执行前发现问题。对高频问题，还可以把通过人工 Review 的计划和 SQL 保存为模板，后续优先复用，而不是每次从零生成。
四、SQL 审核必须独立于生成模型
生成模型不能同时担任唯一的安全裁判。SQL 审核应由确定性规则、数据库元数据和权限系统共同完成。
静态检查至少包括：
- 仅允许只读语句，禁止 DDL、DML 和多语句执行；
- 拦截无条件全表扫描、笛卡尔积和异常复杂子查询；
- 检查访问对象是否超出用户数据权限；
- 对敏感字段实施拒绝、脱敏或聚合后返回；
- 自动加入行数上限、查询超时和资源组限制；
- 对执行计划中的高成本扫描触发人工确认。
对于无法可靠解析的方言语句，应默认拒绝自动执行，而不是把解析失败当作安全通过。生产环境还应使用独立的只读账号，并把测试库、分析库和生产库连接明显隔离。
五、结果可信度来自证据链
智能问数的输出不应只有一张结果表。一个可追溯回答至少应同时展示：使用的指标定义、数据时间范围、涉及的数据表、关键过滤条件、生成 SQL、执行状态和结果更新时间。
如果系统对 SQL 做过自动改写，例如增加 LIMIT、替换敏感字段或切换到治理视图，也应明确提示。结果解释需要区分“数据库返回的事实”和“模型基于结果生成的总结”，避免把推断写成事实。
六、用评估集管理长期质量
上线前可以建立一组覆盖真实业务的评估问题，每个问题保存期望指标、允许使用的数据表、关键过滤条件和结果校验方式。评估不要只看 SQL 字符串是否一致，而要看语义是否一致、执行结果是否正确、权限是否合规、资源消耗是否可接受。
建议持续记录五类指标：Schema 召回准确率、SQL 首次通过率、人工修改率、执行拦截率和结果被用户采纳的比例。模型、Schema 或指标口径变更后重新跑评估集，才能发现能力回退。
七、Chat2DB 这类数据库管理工具适合放在哪一层
数据库管理工具可以承载连接管理、Schema 浏览、SQL 编辑、结果查看和团队协作，并把智能问数嵌入已有工作流。以 Chat2DB 这类工具为例，更合理的验证方式不是比较一次生成结果，而是检查它能否配合权限隔离、SQL Review、审计记录和人工确认形成闭环。
建议先在开发测试环境、只读数据源和有限业务域中验证，再逐步扩展指标和用户范围。任何 AI 生成 SQL 都应作为可检查的初稿，不能绕过数据库权限和组织审批直接执行。
常见问题
智能问数是否需要向量数据库？
不一定。Schema 数量较小时，关键词检索和结构化元数据过滤就能工作；规模扩大后，再引入向量检索召回表、字段和业务文档。无论采用哪种检索方式，都要有业务域和权限过滤。
只读账号是否足够安全？
不够。只读查询仍可能读取敏感数据或消耗大量资源，还需要字段脱敏、行级权限、超时、行数限制和查询成本控制。
SQL 执行成功是否代表回答正确？
不代表。执行成功只能证明语法和数据库运行正常，指标口径、表选择、Join 和过滤条件仍可能错误。生产级智能问数必须保留口径与数据来源证据。
结语
智能问数进入生产的关键，不是让模型写出更长的 SQL，而是建立从语义口径到受控执行的证据链。语义层减少业务歧义，Schema Grounding 限定数据来源，SQL 审核控制风险，评估集保证长期质量。本文不构成具体产品推荐，实际落地应结合数据库类型、权限体系、数据分级和合规要求验证。