当大模型遇上数据库：一个A/B测试撕开了Text-to-SQL的遮羞布

说实话，我一直对Text-to-SQL这个赛道有点“精神分裂”。

一方面，这几年行业里铺天盖地的演示太诱人了——老板们在台上随便问一句“去年Q3华东区的毛利率是多少”，AI秒出一个SQL，秒返回一个数字，全场鼓掌。你很难不心动。另一方面，每次我私下问那些真正在企业里搭过这套东西的工程师，他们的表情总是很微妙：有的是苦笑，有的是摇头，有的干脆建议我“别踩坑”。

这种割裂感终于被一份硬邦邦的A/B测试报告给捅破了。

一个被过度承诺的技术方向

先交代一下背景。2023年到2024年间，Text-to-SQL几乎是所有科技大会的“保留节目”。GPT-4、Claude 3这样的超大型语言模型横空出世之后，行业里弥漫着一种近乎亢奋的共识：自然语言直接查询数据库的时代终于来了。论据也很简单——LLM的训练数据里包含了海量的代码和SQL语法，只要把企业数据仓库的表结构“灌”给它，理论上就能实现零门槛的数据访问。

这个逻辑听起来无懈可击。所以那两年，大小企业纷纷上马Pilot项目：有的接上了Snowflake，有的接上了BigQuery，有的干脆让GPT直连MySQL。厂商们拍着胸脯说“我们的准确率已经超过85%了”，甲方们半信半疑地开始内测。

结果呢？我观察到一个非常有意思的现象：这些项目的存活率，和它们在大会上演示时的掌声烈度，呈现出一种奇妙的负相关。

这不是我在黑它们。实际上，站在工程角度想一想，问题几乎是必然的。大模型的本质是一个概率模型，它生成SQL的能力再强，也绕不过一个根本矛盾：企业数据仓库的复杂性，远超任何公开演示所能展示的边界。几百张表、层层嵌套的视图、自定义的业务逻辑、只有老员工才懂的字段命名惯例——这些东西对于一个语言模型来说，不是“稍微难一点”，而是“不可逾越的”。

所以2025年，行业开始悄悄转向一个没那么“性感”但更务实的概念：语义层（Semantic Layer）。

语义层到底是什么

你可能听过这个词，但不一定清楚它到底在解决什么问题。让我把它说人话一点。

想象一个企业的销售部门想查“本月销量”。在没有语义层的情况下，大模型需要自己理解“销量”这个概念对应数据库里的哪个字段——是order_amount？sales_amount？还是revenue_after_return？不同的表可能还有不同的口径，有的算退款，有的扣税，有的按发货算，有的按回款算。这种模糊性对于人类来说需要上下文，对于大模型来说则是致命的。

语义层的作用，就是在数据源和用户之间架一层“翻译官”。它不是让用户（或AI）直接读原始数据库，而是预先定义一套业务语义：什么叫“销量”、什么叫“活跃用户”、什么叫“毛利率”，每个指标的计算规则是什么，数据从哪里取，用什么口径。所有这些规则被封装在一个统一的语义模型里，对外暴露的只有清晰的API和定义好的查询接口。

这样做的好处是：无论底层数据库结构多复杂，用户看到的是一个干净的、受控的语义世界。AI Agent在查询时，调用的不再是原始SQL，而是经过语义层定义好的、具有明确业务含义的接口。

这其实不是什么新概念。BI领域的老兵们对此再熟悉不过——Looker的LookML、Metabase的这些问题定义，本质上都是语义层的变体。只不过在大模型时代，这套思路被重新赋予了战略价值。

那份A/B测试到底测了什么

好，终于说到关键部分了。这份来自Towards AI的A/B测试报告，做了一件非常实诚的事：在真实企业场景下，对比了两种方案——方案A是直接让LLM连接原始数据库（加上Schema描述），方案B是让LLM通过语义层进行查询。

测试的维度覆盖了几个关键指标：

查询准确率。这个是最核心的。直接LLM方案在面对复杂业务逻辑时，准确率大约在60%左右波动——听起来不算太低，但问题在于，这个数字的方差极大。简单的“各部门本月销售额”这类问题准确率确实高，可一旦涉及多表关联、时间窗口定义、特殊的业务排除条件，准确率就断崖式下跌。而语义层方案的准确率稳定在90%以上，且波动范围小得多。

响应时间。语义层方案多了一步“翻译”过程，理论上应该有额外开销。但实际测试显示，由于语义层把查询范围大幅收窄，LLM需要处理的信息量骤减，总体的端到端响应时间反而更短。在复杂查询场景下，直接LLM方案经常需要多次“LLM生成SQL→执行→发现结果不对→再问一遍”的循环，而语义层方案通常一次命中。

用户信任度和采纳率。这可能是最出人意料的一个指标。测试发现，即便直接LLM方案的返回结果看起来更“原生”，用户反而更愿意相信语义层方案给出的答案。原因很朴素：语义层能清楚地解释“这个数字是怎么算出来的”，而直接LLM方案给出一个数字之后，用户很难判断它有没有“幻觉”了一个字段或搞混了表关联。在数据决策场景里，可解释性有时候比准确率本身更重要。

跨部门一致性。当不同部门用直接LLM方案查询同一指标时，由于各自数据库的连接方式和上下文不同，经常得到不一致的数字。语义层因为有统一的指标定义，从根本上消灭了这种“数据打架”的问题。

我的判断：一个务实的技术选择

读完这份报告，我最直接的感受是：这不是语义层的胜利，这是直接LLM方案的一次必要修正。

行业的认知正在回归常识。任何在企业级环境里待过的人都知道，数据治理的核心从来不是“让更多人能访问数据”，而是确保每个看到数据的人理解的是同一个东西。语义层本质上解决的不是技术问题，而是组织协作和语义对齐的问题。大模型再强，也没法替你完成办公室里那些没说清楚的业务约定。

当然，语义层不是银弹。它的代价是前期需要投入精力做语义建模——你要和企业里真正懂业务的人坐下来，一条一条地把那些模糊的概念定义清楚。这件事很累，很慢，而且需要持续维护。但这份投入会在AI Agent时代收获巨大的回报，因为你定义的不是一套查询接口，而是一个可持续积累的企业知识资产。

从技术演进的角度看，我认为语义层将成为企业AI落地的基础设施，而不是一个可选项。单独的LLM会越来越强，但企业的数据复杂度会以更快的速度增长。两者之间需要一个稳定的中间层，这既是工程的必然，也是认知的必然。

最后说一个判断，不一定对，仅供参考：接下来一到两年，能帮企业快速构建语义层并且无缝对接大模型工具链的产品，会是一个被严重低估的赛道。不是说它会诞生下一个OpenAI，而是说它可能是目前企业AI落地链条里最短的那块木板。