别再死磕大模型了！我们把ChatSQL准确率从5%拉到60%的深度复盘

我曾分享过《任何不涉及流程重构的大模型应用，都是在装样子!》和《ChatSQL生死劫：数据建模师，放下代码，拿起提示词！》等文章，记录了我们在企业内部署ChatSQL的心路历程。

近期项目有了阶段性进展，在此做一次深度复盘，希望能为同行者带来一些启示。

我们将ChatSQL的探索与实践，总结为五个环环相扣的阶段：

▌第一阶段：技术狂热期的探索

大约两年前，我们的精力高度集中于大模型的选型与优化。

当时，即便是最前沿的开源大模型，其SQL生成能力也远未成熟。为了弥补模型能力的短板，我们投入了大量精力设计复杂的补偿策略。

例如，当时的大模型在区分维度、指标和时间这三个基本要素上表现不佳。

我们不得不采用"曲线救国"的方案：

先用定制的小模型分别从用户自然语言中提取这些核心要素，再将这些结构化信息喂给大模型，由它最终组装成SQL。

这个过程不仅繁琐，而且极为脆弱，任何一个环节的微小失误都可能导致整个查询的失败。

幸运的是，随着近年来大模型在代码生成领域取得的飞跃式进步，这些复杂的补偿措施已逐渐成为历史。

但正是这段"弯路"，为我们后续的工作奠定了坚实的技术认知和工程基础。

▌第二阶段：应用初探的"滑铁卢"

我们落地的第一个ChatSQL应用是ChatBI，定位是帮助一线业务人员通过自然语言对话，快速获取他们关心的指标数据。

为了降低项目难度，我们将业务范围严格限定在"关键营销考核指标"上，并为此专门构建了几张核心的指标宽表。

理论上，大模型只需根据用户的提问（如"本月XX渠道的新增用户数是多少？"）在这些有限的表上生成查询即可。

然而，即便场景如此简化，挑战依然超出预期。

首先是元数据"黑洞"。

公司内部存在大量非标准的指标和维度术语。我们不得不投入巨大的人力去补充和梳理元数据。

例如，业务人员口中的"杭州"，在数据库里可能存储为代码"571"，这就要求我们必须在元数据中明确标注这一映射关系。

但这还不够。

一线人员的提问充满了大量的俗语、简称和口语化表达，这些"非官方"语言对模型的理解构成了巨大障碍。

我们尝试在产品层面解决，比如开放配置界面，让业务团队自己补充"黑话"词典；在交互上，我们也增加了"意图澄清"环节，让用户在SQL执行前，先行确认模型解析出的维度和指标是否准确。

最终，我们发现一线营销场景对语料质量的要求极高，而市场指标又日新月异，依赖项目组临时补充语料的模式难以为继。

这个看似美好的ChatBI项目，最终因投入产出比过低而被搁置。

这次代价不菲的探索让我们深刻认识到：

企业级ChatSQL的成功，高质量、可持续的领域语料是不可或缺的基石，其重要性甚至超过模型本身。

▌第三阶段：选择比努力更重要

现在回看，当初选择ChatBI作为切入点，更多是出于对行业热点的跟风。

除了语料困境外，其业务价值也远比我们想象的有限。

ChatBI服务于一线员工，但他们的核心需求往往由固定的报表和看板满足，这已经解决了80%-90%的日常看数问题。

即席查询（Ad-hoc Analysis）对他们而言，是一个低频、非刚需的场景，ChatBI更像一件"锦上添花"的奢侈品，而非"不可或缺"的生产力工具。

随着开源大模型能力的持续增强，我们意识到，单纯在技术上死磕的边际效益已经递减。

是时候跳出技术的牛角尖，重新审视场景的价值了。

我们为ChatSQL的理想应用场景定义了四大黄金法则：

刚需、高频、价值高、语料可控。

循着这个标准，我们找到了当前企业环境下唯一符合所有条件的场景——"取数"。

"取数"是业务人员进行经营分析的起点，是公司数据消费的绝对刚需。

我们现有的线上取数流程每年要处理数以万计的工单，其价值不言而喻。目前，取数工作仍以人工为主，一个工单的平均处理周期在1-4天，耗费了大量数据分析师的宝贵时间。

想象一下，一个由大模型驱动重构后的取数流程：

业务人员提交的取数工单，不再直接流向人工队列，而是首先由一个"ChatSQL Agent"进行处理。

大部分简单、明确的需求，Agent可以在几秒内自动生成SQL、执行并返回结果。只有当Agent处理失败或用户不满意时，工单才会转入传统的人工处理流程。

这种流程重构，将为业务人员带来10倍乃至100倍的效率提升，其价值是革命性的。

研究表明，将AI集成到核心业务流程中以实现自动化，是释放其商业价值的关键途径。

然而，当前市场上90%以上的ChatSQL应用，无论形态如何，都深陷于语料和价值的泥潭。

语料问题，本质上不是技术问题，而是管理问题——这恰恰是大多数技术团队的短板。

▌第四阶段：背水一战，啃下硬骨头

即便选对了方向，我们的"取数大模型"项目在近一年的时间里也步履维艰。

因为解决语料问题的过程，对数据团队而言，不亚于一场全面的数字化转型。

我们曾天真地以为，线上取数流程中积累的"需求描述-SQL代码"对，会是高质量的语料金矿。

但深入分析后，现实给我们泼了一盆冷水。

◆ 第一个挑战：用户需求的"隐性知识"

业务人员提交的需求描述往往极其简略，大量的关键信息隐藏在线下沟通中。

一句简单的"用户活跃度"，背后可能对应着多种复杂的计算口径和业务规则。

最典型的场景是：

业务员在线上系统里提一个模糊的需求，然后立刻通过电话或即时通讯工具找到数据分析师：

"小王，那个需求我提了，就是上次邮件里那个口径，但这次要把A渠道的用户排除掉，时间范围改成上个月……"

期望大模型能准确"猜到"这些未明确表述的"隐性知识"，无异于天方夜谭。

我们尝试强制用户在线上填写结构化表单，但收效甚微。

改变用户习惯，远比攻克技术难题更具挑战性。

我们只能退而求其次，要求需求管理员在审核环节对不规范的需求进行"翻译"和"补全"，但这无疑增加了他们的工作负担，也改变了他们固有的工作模式。

在缺乏强力推动的情况下，改变的阻力巨大。

一个相对有效的技术补偿方案是利用历史相似性。

我们发现，很多需求在历史上曾以不同的形式出现过。通过大模型进行语义匹配，找到历史上的相似需求及其对应的SQL代码，再进行微调，这个方案在一定程度上提升了成功率。

◆ 第二个挑战：数据资产元数据的"阿喀琉斯之踵"

大模型需要根据需求描述，从企业数千张表中，精准地选择正确的表、正确的字段，并理解枚举值的含义。

任何一张表、一个字段的描述缺失或模糊，都可能导致SQL生成逻辑的"蝴蝶效应"。

这对于企业数据资产元数据的完整性、准确性和时效性提出了近乎苛刻的要求。

权威机构的研究也一再证实，数据质量问题是阻碍企业AI项目成功的首要因素。

尽管我们经过了多年的数据治理，元数据质量有了大幅提升，但离支撑大模型自由查询的"精细化"标准仍有巨大差距。

项目初期，端到端的SQL准确率仅有5%。

许多宣称达到很高准确率的ChatSQL应用，往往是在一个极度限定的、几张"黄金表"范围内测试的结果。

一旦放开到支撑企业数百上千张表的真实取数场景，其难度和价值都将是几何级的提升。

面对困境，我们最终下定决心，成立了专门的数据资产团队，对核心数据表的元数据进行全面治理。

我们将核心表按优先级分批次进行完善，第一批250张核心表，预计在1-2个月内完成。

根据初步测试，仅此一项工作，就有望将SQL的准确率从5%提升到40%-60%。

此外，我们观察到，当候选表数量增多时，大模型的"幻觉"会显著增加，导致选错表、选错字段的概率升高。

在模型能力达到新的瓶颈前，我们通过业务分类的方式，将需求和对应的数据资产进行"分区"，以降低单次查询的复杂度。

◆ 第三个挑战：从技术项目到管理变革的认知跃迁

我们最初将ChatSQL视为一个纯技术项目，这是最大的认知错误。

我们后来才恍然大悟：

ChatSQL的本质，从来不是一个纯粹的技术项目，而是一个由技术驱动的、深刻的数字化转型项目。

为此，我们进行了彻底的调整：

组织上：

我们任命了更高级别的管理者担任项目负责人，以获得足够的跨部门协调能力。

同时，从取数、报表等业务关联方抽调核心人员深度参与项目，负责元数据梳理、需求规范定义等关键工作。

成功的AI项目，无一不是技术与业务深度融合的结果。

流程上：

我们重构了整个取数流程。

从优化需求提交界面，到增加需求管理员的"标准化"环节，再到引入ChatSQL Agent实现自动处理，并在最后增设人工抽检与确认环节，形成了一个"人机协同"的全新闭环。

这正是AI+的精髓所在——任何不涉及流程重构的大模型应用，都只是在"装样子"。

制度与文化上：

未来，我们将适时发布新的取数管理办法，从制度上保障高质量语料的持续产生。

更重要的是，在企业内部建立一种全新的AI文化：

我们过去流程中留存数据，是为了审计和分析；现在，我们还要为AI的"学习"和"成长"负责。

将数据进行标准化、精细化的管理，不再仅仅是数据治理的要求，而是AI时代企业生产力的核心要素。

▌结语

ChatSQL的征途仍在继续，但我们对其最终的成功充满信心。

回望这条路，技术只是敲门砖，真正的挑战在于流程的重构、组织的适配和文化的升级。

未来，随着大模型本身逐渐基础设施化，企业在AI时代的终极护城河，将不再是模型本身，而是高质量、私有化的领域语料。

因为，语料的质量，直接决定了AI产品最终能达到的高度。

希望对你有所启示，转给有需要的人！

公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！