“用一句话查数据”听起来简单，实际落地要解决的问题很多：业务口径不统一、表结构复杂、模型生成的 SQL 可能查错、权限不能越界、结果还要能解释。数据分析 AI API 的核心不是让模型“会写 SQL”，而是把自然语言问题稳定地映射到可信的数据和报表。
本文给出一套企业落地方案，覆盖架构、Schema 设计、提示词、校验、权限、准确率测试与成本。
说明：不同数据库、BI 平台与模型接口存在差异，本文以常见的“只读数据库 + OpenAI 兼容对话接口”为例；模型与价格以站内 模型价格 为准。
一、整体架构
推荐把链路拆成可观测的几步：
自然语言问题
→ 意图识别（查询/解释/澄清）
→ Schema 检索（表、字段、指标、示例）
→ SQL 生成
→ 静态校验 + 权限注入
→ 只读执行（超时、行数限制）
→ 结果校验
→ 图表配置 + 文字解读
关键原则：
- 模型不直连生产库，只连只读副本或数仓。
- 权限在服务端注入，不能依赖提示词约束。
- 每一步都留日志：问题、召回的表、生成的 SQL、执行耗时、返回行数。
- 失败时给用户可理解的解释，而不是数据库原始报错。
二、Schema 设计比模型更重要
模型不知道你公司的“活跃用户”“有效订单”怎么定义。要把这些知识显式提供给模型。
建议为每张表维护一份“Schema 卡片”：
| 字段 | 内容示例 |
|---|---|
| 表名 | dwd_order |
| 业务含义 | 订单明细，一行一个订单商品 |
| 主键/粒度 | order_id + sku_id |
| 常用字段 | 下单时间、支付金额、订单状态、渠道 |
| 指标口径 | 支付金额=实付金额，不含退款 |
| 关联表 | 用户表、商品表、渠道表 |
| 禁用说明 | 不要用 create_time 代替支付时间 |
| 示例问题 | 最近 30 天各渠道支付金额 |
除了卡片，还要准备：
- 业务同义词：GMV、成交额、交易额指向同一指标。
- 指标字典：口径、分子分母、时间口径、数据延迟。
- 少量“问题 → SQL”示例，覆盖常见查询。
- 表之间的 join 路径，避免模型猜测关联键。
Schema 检索可以用关键词加向量召回，把最相关的 5–10 张表和指标定义放进上下文。全量 Schema 塞进去既贵又容易干扰。
三、提示词怎么写
提示词的目标是“约束”而不是“鼓励发挥”。一个可用的模板：
你是企业数据分析助手。根据给定的 Schema 和指标定义，把用户问题转成 SQL。
要求：
1. 只生成一条 SELECT 语句，禁止 INSERT/UPDATE/DELETE/DDL。
2. 只能使用提供的表和字段，不要臆造字段。
3. 指标口径以“指标字典”为准，并在 assumptions 中说明。
4. 时间范围不明确时，默认最近 30 天，并写明假设。
5. 问题有歧义时，先返回 clarifying_question，不要猜。
6. 输出 JSON：{"sql": "", "assumptions": [], "clarifying_question": null}
几个细节：
- 要求模型输出假设，方便业务方核对口径。
- 明确“先澄清再查询”，能显著减少答非所问。
- 对“同比/环比/占比”单独给公式，不要让模型自由发挥。
- 多轮对话里保留上一轮的指标和时间范围，但不要保留过期 SQL。
四、SQL 校验与执行护栏
生成 SQL 只是开始，执行前至少做五道检查：
- 语法解析：用 SQL parser 解析，拒绝多语句。
- 语句类型：只允许 SELECT，禁止写操作和存储过程。
- 对象白名单：表、字段必须在授权清单内。
- 权限注入：自动追加租户、部门、区域等过滤条件。
- 成本控制：加时间范围、LIMIT、超时和扫描量上限。
执行层建议使用独立只读账号，连接只读副本，并设置：
- 查询超时，例如 30 秒。
- 最大返回行数，例如 1000 行。
- 大表查询先 EXPLAIN，预估扫描量。
- 失败重试最多 1–2 次，把数据库报错回传给模型修正。
- 相同问题缓存结果，缓存键包含用户权限范围。
五、权限：模型不能代替权限系统
数据问答最容易出的事故，是“用户看到了不该看的数据”。正确做法是复用 BI/数仓的权限模型：
- 数据集级：用户能访问哪些表。
- 行级：按租户、部门、区域过滤。
- 列级：手机号、身份证、成本价等字段脱敏或隐藏。
- 指标级：敏感指标单独授权。
- 会话级：切换用户时清空上下文与缓存。
模型只负责生成查询意图，权限由服务端在 SQL 外层或视图层强制注入。日志中记录原始问题、最终 SQL、执行者与返回行数，便于审计。对导出功能单独授权，避免“能查就能批量下载”。
六、从结果到图表
查询结果不等于报表。建议让模型输出“图表配置 + 文字结论”，而不是直接生成图片：
| 数据形态 | 推荐图表 |
|---|---|
| 时间序列 | 折线图 |
| 类别对比 | 柱状图 |
| 占比 | 饼图或堆叠柱状图 |
| 相关性 | 散点图 |
| 单指标 | 指标卡 |
文字结论要包含：口径、时间范围、关键数字、异常点。比如“最近 30 天支付金额环比下降 8%，主要来自华东渠道”，并附上可点击的明细。不要只给一句“数据表现良好”。
七、准确率怎么测
准备 100–300 条真实业务问题，按难度分层：
- 单表查询、聚合。
- 多表 join。
- 同比/环比/占比。
- 需要澄清的模糊问题。
- 无数据或无权限的问题。
评测不只看 SQL 是否相似，而要看执行结果是否一致。建议记录：
| 指标 | 说明 |
|---|---|
| 执行准确率 | 结果与人工标准答案一致 |
| 澄清率 | 模糊问题是否正确反问 |
| 越权拦截率 | 无权限请求是否被拒绝 |
| 失败可解释率 | 报错是否转成用户能懂的话 |
| 平均延迟 | 从提问到出图 |
每周回归一次，模型或 Schema 变更后必须重跑。上线初期保留“人工确认 SQL”模式，稳定后再开放自动执行。
八、成本与性能
数据分析 AI 的成本主要来自三块：Schema 召回、SQL 生成、结果解读。
- 用向量检索减少上下文，只放相关表。
- 意图识别和简单查询用小模型，复杂查询再用强模型。
- 缓存高频问题与相同权限范围的结果。
- 结果解读只传聚合后的数据，不回传全量明细。
- 对长表结构做摘要，避免每次传完整 DDL。
估算公式：
单次成本 =
Schema 上下文 Token × 输入单价
+ 生成 SQL 的输出 Token × 输出单价
+ 结果解读 Token × 单价
+ 数据库执行成本
具体单价以站内 模型价格 为准；数据库成本要单独算，尤其是大表扫描。
九、常见失败与处理
| 现象 | 常见原因 | 处理 |
|---|---|---|
| 字段不存在 | Schema 未召回或模型臆造 | 白名单校验 + 报错回传重试 |
| 口径不一致 | 指标定义缺失 | 补指标字典，要求输出假设 |
| join 结果放大 | 关联键或粒度错误 | 提供 join 路径，校验行数 |
| 时间范围错 | 时区或默认值不清 | 统一时区，明确默认范围 |
| 权限越界 | 只靠提示词约束 | 服务端强制注入过滤条件 |
| 答非所问 | 问题有歧义 | 先澄清再查询 |
常见问题
数据分析 AI 会取代 BI 吗？
不会。它更适合“临时问题、快速取数、解释报表”，复杂的固定报表仍应由 BI 承担。
需要把数据库结构全部给模型吗？
不需要。用 Schema 检索只放相关表和指标，既省成本，也减少误用。
模型生成的 SQL 能直接执行吗？
不建议。必须经过语法、白名单、权限和成本四道校验，并在只读副本上执行。
准确率能达到多少？
取决于 Schema 质量、问题复杂度和评测口径。先用真实问题建立基线，再逐周优化，不要用演示问题代表整体。
小团队怎么开始？
先选一个主题域，例如销售或运营，整理 10–20 张表与指标字典，做 50 条问题的评测集，再决定是否扩展。
下一步
数据分析 AI 的成败，八成取决于 Schema、指标口径和权限设计，而不是模型参数。建议从一个主题域做 POC，跑通“提问—校验—执行—出图—解释”的闭环，再逐步扩展。需要统一模型入口与用量管理，可以先 注册中商起航 AI 网关，模型与价格以 模型价格 为准。
相关阅读：
