ChatSQL之我见
这两年，AI技术越来越成熟，在很多场景上给不同的岗位提供了大量的生产力。 但是作为数据行业从业人员，其中有个场景我想泼一下冷水。 比如被讲得很热的ChatSQL。 接个大模型，挂上数据库，做个对话框，让业务一句话取数，仿佛传统 BI 的门槛一下子就要被抹平。 这种想象不是完全没有根据。只要场景足够干净，问题足够标准，今天的模型确实已经能生成一段相当像样的 SQL，甚至把结果也答得像模像样。 但我对 ChatSQL 的判断一直比较克制。不是因为它没用，而是因为它在企业里真正要解决的，从来都不是"写出一条 SQL"这么简单。 一，ChatSQL 最难的不是生成，而是语义 很多人第一反应是：模型还不够强，等下一代就好了。 这个判断的问题在于，它把 ChatSQL 的核心难点理解成了生成能力。 可在企业环境里，模型最先撞墙的地方往往不是不会写 SQL，而是不知道你们公司到底在说什么。 “活跃客户"怎么算？ “新增付费用户"包不包含试用转正？ “业绩下滑"看收入、利润，还是回款？ 这些问题本质上都不是自然语言理解问题，而是业务语义问题。模型可以把一句话翻成查询，但它翻不了一家企业内部本来就没有统一好的口径。 所以 ChatSQL 如果一上来就做成"人话转 SQL”，最后大概率不是输在模型，而是输在语义基础太薄。 二，语义层很重要，但它不是银弹 讲到这里，很多团队会自然转向另一个答案：那就建语义层。 这个方向没错，但也很容易被误解。 语义层的价值在于，把常见指标、维度、实体关系和口径规则结构化，让模型不必每次从数据库字段里重新猜业务世界。没有这层东西，系统几乎很难稳定。 但语义层本身不是一个轻巧组件，它更像是一种治理成果的交付形式。 换句话说，语义层不是补丁，而是地基的外化。 如果企业本来就没有统一指标、没有稳定口径、没有明确的责任边界，那语义层也只是把混乱包了一层更漂亮的壳。它让问题显得更工程化，但并不会自动把问题解决。 所以我更愿意把它理解成入场券，而不是终局方案。没有它，很难上线；只有它，也过不了关。 三，Demo 证明不了产品成立 ChatSQL 最容易骗人的地方，就是 Demo 总是很好看。 因为 Demo 里的问题通常都被精心挑过：定义清楚，范围有限，口径提前对齐，数据表也知道该怎么连。这样的条件下，模型表现出色并不奇怪。 但产品成立的标准完全不是这个。 真正的用户问题通常带着模糊、跳跃和上下文缺失。很多人问的不是一个可以直接翻译的问题，而是一个需要先被澄清的问题。 比如：“最近业绩下滑的团队有哪些？” 一个靠谱的分析师听到这句话，第一反应不会是立刻写 SQL，而是先追问。最近是多久，业绩看什么，下滑按什么基线，异常值要不要去掉，外包团队算不算。 也就是说，真实分析过程本来就不是一次翻译，而是一段澄清和收敛的过程。 而大多数 ChatSQL 产品，目前只接住了"生成查询"这一步，却没有接住分析师原本承担的职责：澄清、解释、回退、修正、多轮一致性。 所以 Demo 证明的是模型有翻译能力，不等于产品已经具备交付能力。 四，ChatSQL 最脆弱的地方是信任，不是准确率均值 很多讨论喜欢问：“准确率做到 80% 多，能不能上线？” 这个问题本身问得就有点偏。 如果 ChatSQL 只是给分析师自己做探索，用来找方向、提假设、少写点重复 SQL，那么它不需要像财务系统一样严苛。因为分析师本身有判断力，答偏了也知道怎么纠回来。 但如果它要直接进入经营分析、财务对账、审计追责这种高责任场景，标准就完全不同了。 这些场景里，决定系统能不能活下来的，不是平均准确率，而是关键问题能不能稳定答对，答错了能不能被及时发现，发现之后能不能追溯。 因为用户对这类系统的信任建立得很慢，崩塌得却很快。十次答对未必能让人真正依赖它，但一次关键错误，足以让整个部门彻底弃用。 ...