一、开篇
上周，业务总监在会议上拍桌子：“为什么销售额是负数？这数据太假了！”
我点开系统日志——他用ChatSQL问：“最近三个月销售额情况。”
系统返回了1000行“销售额”字段，其中70%是负数。
真相是：他连“销售额”这个指标在数据库里叫什么都没搞清。
这场景太常见了。说清楚自己要什么数据的人，永远不用ChatSQL；用ChatSQL的人，往往连自己要什么都说不清。
今天，我就撕开智能问数的遮羞布，告诉大家为什么90%的企业在智能问数上踩了大坑。
二、Text2SQL
Text2SQL的致命伤：表元数据≠理解需求
很多厂商吹嘘“自然语言转SQL”，本质是用表元数据拼凑SQL，而不是理解业务逻辑。
✅ 为什么表元数据是基础？
数据库表结构（字段名、关联关系）是Text2SQL的“地图”
没有这张地图，AI就像盲人摸象
❌ 但为什么它失效？
因为业务人员说的“销售额”，在数据库里可能是：
sales_amount（财务系统）
revenue（电商系统）
order_total（ERP系统）
而AI只能根据表名猜——猜错了，就是负数！
📌 业内真相：ChatSQL的准确率=表元数据的完整性×用户描述的清晰度
两者缺一，结果必崩。
三、ChatSQL
谁在用ChatSQL？谁在骂ChatSQL？
|
用户类型 |
代表场景 |
为什么用ChatSQL |
结果 |
|---|---|---|---|
|
专业数据人 |
“查2023Q4华东区订单量” |
他们直接写SQL，效率高 |
从不碰ChatSQL |
|
模糊需求业务人 |
“看看最近销售情况” |
说不清要什么，只能问 |
得到一堆错误数据 |
|
技术决策者 |
“让业务自己查数据” |
以为ChatSQL能解决一切 |
误判数据，决策失误 |
>>延伸：AI + 数仓AI 不会取代数仓，但会增强数仓：•自动化建模、SQL 生成•智能调度优化•自然语言查询（NLQ）
这也是我见过最讽刺的场景：
CTO要求“用ChatSQL赋能全员”，结果业务部门每天问：“为什么我的销售额是负数？”
这不是技术问题，是认知问题。
四、语义层，不是ChatSQL的升级版
破局关键：语义层，不是ChatSQL的升级版
很多厂商还在做“NL2SQL”，但真正的破局点在语义层（Semantic Layer）。
为什么语义层是核心？
|
传统NL2SQL |
语义层方案 |
|---|---|
|
依赖物理表结构 |
抽象业务语义（销售额=收入-退款） |
|
一个指标多个口径 |
统一指标定义（全公司只用1个“销售额”） |
|
业务变化需重写SQL |
业务规则变更，语义层改1处，全链路生效 |
|
数据孤岛，口径混乱 |
跨部门数据一致，无歧义 |
🌟 语义层的本质：把“业务语言”翻译成“数据语言”的中枢
例如：
业务说“销售额” → 语义层映射到
revenue - refunds→ 生成精准SQL
这才是智能问数的正确打开方式：
用户问“销售额” → 语义层解析业务含义 → 生成SQL → 返回数据
五、别再盲目上ChatSQL
给企业的血泪建议：别再盲目上ChatSQL
❌ 你正在踩的坑：
以为ChatSQL=自助分析 → 实际是“自助造错”
用宽表+NL2SQL → 业务一变，IT就重排期
把指标库当摆设 → 业务人员依然用“销售额”“订单量”等模糊词
✅ 我的实战建议：
先建语义层，再上ChatSQL
→ 用指标平台（如 数势科技SwiftMetrics，Aloudata CAN）定义“销售额”“用户活跃度”等业务指标，统一口径。
让业务人员参与语义定义
→ 业务部门自己写“销售额=收入-退款”，比IT猜100次都准。
ChatSQL只做最后一公里
→ 业务人员问“Q3销售额”，语义层自动转成SELECT SUM(revenue - refunds) FROM sales WHERE quarter=3。
💡 我的铁律：
“没有语义层的ChatSQL，是数据灾难的加速器，不是解决方案。”
六、结语
智能问数的终极目标👇
智能问数不是“让AI替你写SQL”，而是让业务人员真正理解数据。
对专业DE：语义层解放了你的时间，让你专注数仓建设与数据治理，而不是救火。
对业务人员：不再需要问“销售额是什么”，而是直接问“Q3销售额对比Q2如何？”
对企业：从“数据孤岛”走向“数据统一认知”，决策效率提升10倍。
记住：
说清楚需求的人，永远不需要ChatSQL；
用ChatSQL的人，永远说不清需求。
破局的关键，不是让AI更聪明，而是让业务更懂自己。
范老师重申：
“我见过太多企业花百万买ChatSQL，结果数据还是错的。
真正的智能问数，是让业务人员先学会‘说清楚’，
而不是让AI去‘猜清楚’。”
来源（公众号）：数据仓库与Python大数据
