让数据自己讲故事，
让业务同事不再排队等分析师。
业务部门用"上个月华东大区的退款率"问出图表,而不是排队等分析师写 SQL。语义层兜底,AI 不能瞎编字段;全部 SQL 可审计,默认只读不能跑 UPDATE。已交付 2 个项目,6–10 周可上线。
什么时候该考虑 BI + AI?
下面 4 类典型场景，是浩途从过去两年的真实项目里反复遇到的。如果有 2 项以上跟您的处境对得上，这条能力线值得评估。
业务部门想看数据,分析师是瓶颈
财务、运营、市场每周都在排队找分析师写 SQL。希望业务能自己问出数据。
数仓建好了,但用得很少
几百万的数据仓库,最后只有数据团队在用。业务想看的指标永远是下周再说。
怕 AI 瞎编字段或错聚合
看过 AI 写 SQL 把退款率算成退款单数 / 总订单数——表面对,实际错。希望 AI 不能瞎来。
敏感数据怕被乱查
财务、人力数据涉密。希望 AI 只能查授权的字段,且全程留痕。
它怎么落地到您的业务里？
每条能力线背后都是一套被反复验证的工程架构。下图是 BI + AI 的典型数据流，每个节点对应一组可验收的工程交付物。
每一项都可验收，写进合同。
已经在跑的 BI + AI 系统。
脱敏案例。真实客户名需 NDA 后披露。
微著 BI 平台 · 自然语言查询助手
企业级数据仓库之上加 AI 查询层。财务、人力、运营三大主题域开放自助分析。语义层兜底,SQL 全部可审计。
某金融集团 · 数据治理 AI 助手
数据团队的自然语言查询入口。语义层映射 200+ 业务字段,查询全审计,敏感字段权限隔离。
我们对 BI + AI 的理解
Text-to-SQL 这两年很热,但"让 AI 直接写 SQL"是错误的产品形态 —— AI 会把字段名瞎编、把聚合方式弄反、把时区算错。每一个错都比"写不出 SQL"更可怕。
浩途坚持把语义层放在 AI 和数据库之间:业务字段、计算口径、过滤规则全部在语义层显式定义,AI 只能从语义层里选 —— 它不可能瞎编一个不存在的字段。这套架构让 AI 输出的 SQL 100% 可审计、可解释、可追溯。
关于 BI + AI，
您可能想问什么？
Q01AI 会不会瞎编 SQL 字段?+
结构上不会。语义层是白名单——所有业务字段、计算口径、过滤规则都在语义层显式定义。AI 只能从语义层里选字段,没法瞎编。如果 AI 想用一个不存在的字段,系统会直接拒绝并返回未定义。
Q02跟开源 Text-to-SQL 方案有什么区别?+
开源 Text-to-SQL 让 AI 自由生成 SQL,浩途的方案是AI 只能调语义层提供的字段。前者准确率 60-70%,后者准确率接近 100%——代价是要前期定义语义层(这部分浩途负责)。
Q03支持哪些数据库?+
PostgreSQL / MySQL / ClickHouse / Greenplum 已经实战过。其他主流 OLAP(Doris / StarRocks / TiDB)理论上都支持,需要做小规模测试再确定。
Q04字段血缘怎么追溯?+
每张图表都能反向追溯:图表 → 生成 SQL → 用到的字段 → 字段在语义层的定义 → 字段的业务负责人。这套追溯链让为什么这个数字是这样永远有答案。