ChatGPT4 横空出世，其强大的语义泛化能力以及针对 Zero-Shot、Few-Shot 等场景的特性让 AI 的使用门槛进一步降低，也为各行各业带来了更多想象空间。本文将分享海南数造科技对 DataOps 加大模型驱动数据创新的思考与实践。

一、传统数据管理面临的挑战

企业做数字化转型会制定自己的数字战略，在数字战略与业务战略对齐的过程中，企业也完成了数据从收集、管理到分析的流程，这个流程就是企业数字化转型的体现。

企业数字化转型呈现出三大战略趋势：

• 首先是数据分析民主化。数据分析不再只是少数人的工作，各个岗位都会去看报表，也会用一些统计算法，以实时支撑业务决策。
• 第二是数据技术多元化。现在信息系统多元化，数据开发同学面临着各种多元异构的数据。在复杂的数据环境下，我们需要多元化的一些技术组件来支撑，比如 Flink、Spark 等计算组件和存储组件。又比如在很多金融反欺诈场景中，会用到知识图谱建模和分析的数据组件。整体上变成了一个很庞大的、复杂的系统化工程。
• 第三是业务价值精益化。对于业务部门来说，也希望数据能实现快速变现。

在上述趋势下，我们面临着供需不平衡的痛点。现在市场变化很快，业务同学需要快速响应市场变化，所以经常会有大量的、临时的，且有高时效性要求的数据需求。开发在早期会面临开发环境与测试环境不一致，部署和集成需要大量人工介入，系统之间存在数据孤岛问题。导致调研数据口径要耗费大量时间，数据开发从交付到上线往往超过一周，甚至更长时间。同时也存在数据语义缺失、业务用数困难等其它一些问题。

数据开发工作也像软件工程一样，不应该是瀑布式的流程，即所有事情都要先计划好、设计好才去开发，而是要实现敏捷交付，能够实时地响应需求。当前研发进度是落后于市场需求的。

二、DataOps 与大模型的结合驱动数据工程创新

在数字化转型的趋势下，也是在上述痛点的驱动下，企业亟需新的数据研发范式，需要满足以下要求：

• 形成敏捷数据研发流水线。
• 构建高效的跨域协同机制。
• 打造自助的用数体验。
• 建立精细化的运营体系。

这样才能实现快速交付数据的目的。

在这样的背景下，我们提出了 DataOps 的理念。DataOps 是在 DevOps 的基础上发展而来的，其本质是数据工作流的编排、数据的开发、测试、部署上线、回归这套机制需要达到持续集成的效果，有标准化的体系，实现自动化部署，同时优化整个数据发布的流程，优化资源达到敏捷开发交付的效果。

从 2018 年开始，DataOps 的理念度被 Gartner 列入了技术成熟度曲线，并有着逐年上升的趋势。数造科技在 2022 年与信通院联合成立了一个专家工作小组，制定了 DataOps 的能力标准。

介绍了 DataOps 的背景后，让我们再回到 AI。从 AlphaGo 为代表的深度学习技术的发展，到去年 ChatGPT 大语言模型技术的出现，AI 使用门槛越来越低，我们的信息化系统越来越智能化。

仅仅一年时间里，出现了很多基于大语言模型的 AI 工具。我们团队使用了一款名为 Bito 的代码自动生成和检查的开源插件，使得工作效率提升了 20% 以上。

上图展示了我们 DataOps 的标准化流程，在数据的开发、发布的过程中，使用大模型支持代码生成、代码解释以及代码审查的工作，让整个流程更加智能化。

上图中对比了传统数据开发模式和“DataOps+大模型”模式。传统数据开发模式，从数据建模、数据开发到测试、部署、回归，步骤繁杂，需要大量的人力介入。在最早的时候，我们有开发环境、测试环境和准生产环境，不同的环境中会有不同的开发人员维系其参数配置文件。当部署的时候，就要手动改配置文件，往往会引入潜在的风险。

有了 DataOps 这一套敏捷数据开发发布的标准后，就能达到自动化的效果。这些配置文件会被统一、自动化地管理起来，达到一套数据开发，一套数据建模的脚本，能在多套环境里面去使用，配置参数会自动替换。同时还具备数据沙箱的功能，测试数据可能无法体现生产环境的情况，所以可以使用准生产环境的数据去验证脚本。在这种自动化的体系下，加入了一些大模型的能力，可以帮助我们生成一些数据指令，比如自动生成 SQL 或者加入注释，以及自动审查等等。所以“DataOps+大模型”就是在 DataOps 这套标准化流程的体系上，加入自动化和智能化，让数据的开发和交付更加高效。

三、DataOps+大模型产品实践探索

大模型有很多有趣的应用场景，例如文案生成、数字人、知识检索增强等等。还有一个比较热门的场景就是 Text2SQL，让大模型去生成指令，接下来将介绍我们在这一方向上的探索与实践。

Text2SQL 就是基于以自然语言描述的问题，结合表的元数据信息（包括表名、列名以及表之间的关联关系），生成一个准确的 SQL 语句。2022 年，在大模型出现之前，Text2SQL 基于预训练模型的准确率能够做到 75-77% 左右。这一数据来自 Spider 的评测榜单，这是一个跨域的，在 Text2SQL 领域比较权威的榜单。大模型出现后，每两个月榜单会更新一次，GPT4 做的 Text2SQL 任务，准确率也从原来的 78% 一路飙升到 91%。

而 Text2SQL 任务，产生正确的 SQL 只实现了其一半的价值，对于数据开发人员来说，另一半的价值是快速找到想要的数据。现实的生产环境中有大量的数据库、表，要基于自然语言的提问，找到准确的表和列，也就是准确数据口径。所以我们认为 Text2SQL 的定义还要包括在不同 schema 下面能产生正确 SQL 的任务。

在大模型出现之前的做法，是用 Seq2Seq 的模型。对于提问，表的元数据信息做嵌入，基于嵌入的向量信息，生成 SQL 语句，这里会有 mismatch problem in literature 的问题。我们做文本时，中文转英文或者中文转德文，词语表述不一样，语法结构不一样，但可能语义是一样的。而对于 Text2SQL 的任务来说，语义是不一样的，问题用 SQL 是没办法准确表述的，比如 SQL 中的 group by、intersect、union 是不会在自然语言里面出现的，你不会说：“帮我查这个季度的总销售额，用 group by 这个语句”，所以就会存在语义不对等的问题。

基于这个问题，在模型架构上，比如 Encoder Decoder 上做了很多优化策略。在大模型出来之前，我们常用的就是谷歌 T5-3B、Electra 或者 RoBERTa 这些预训练模型作为模型底座，不断优化其 Encoder，一开始只是简单的 input representation，一个简单的嵌入的任务，但是会发现有 schema-linking 不准确的问题。为了更好地将问题与需要用到的表或者列关联起来，后面有了更复杂的 Structure Modeling 的建模，会对问题建模，对元数据采用更复杂建模的策略，以找到问题相关的表和列。

近几年比较流行的一种方法是基于知识图谱的建模方式，一开始大家会用 GNN 图神经网络的方法去做建模，但存在一个问题，模型更多的是对节点的建模，没办法泛化到两度以上深度的信息。所以后面又提出了 RAT-SQL、RASAT 模型，本质是在知识图谱上去定义 meta-path，把元数据的关联关系定义出来，在 Encoder 会去做多头注意力，把关系的向量信息嵌入到里面，加强问题跟本地元数据的关联性。

Encoder 的优化策略解决完，就到 Decoder，怎么把 encoder 的编码生成 SQL 语句，开始大家会用 Sketch-based 的方法，把生成 SQL 语句拆解成一个个的子部分，生成 select，生成 where，生成 from，基于小的语句去做词槽，把之前 encoder 识别到的表名、列名填到这个词槽里，但实际上效果并不好，会产生很多错误的、不符合语法的 SQL 语句，所以我们用 Generation-based method 的方法，最经典的就是 AST 语法树的结构，让它遵循一定的语法树来生成 SQL，还有 PICARD，在 search 的时候不断地去一个记忆空间检查生成的 SQL 跟前面的 Encoder 的 schema-linking 内容是不是对等的、是不是合语法的，包括 RESDSQL，这样的优化策略，让它生成更加准确的 SQL。

但是仍然不够准确，经过分析，还是存在语义不匹配的问题，于是我们又加入了 Intermediate representation 的架构，发明了基于自然语言跟 SQL 之间的中间语言，NatureSQL、SemQL，先生成中间语言，再基于中间语言生成 SQL，准确率又进一步得到了提升。

大模型出现后，其生成 SQL 的准确度，尤其是 GPT4 基于策略的生成，准确度越来越高。大模型目前主要使用有两种方法，一种是提示工程，一个是基于指令的监督微调，让大模型产生对应的 SQL。

今年这篇论文来自 SQL，也是大模型生成 SQL 任务的常用方法，即基于思维链的方法。在传统 Seq2Seq 的方法中，输入自然语言和 schema 信息，让它去生成 SQL，结果发现这种端到端的方法效果很差，所以才有了 Encoder Decoder 的优化策略。大模型其实也一样，一开始通过 prompt 把自然语言、schema 喂给它，让它生成 SQL，发现准确率有问题，所以后面把大模型的任务拆解成一个个子任务，比如先用一个 schema-linking 的 prompt 的模板，找关联的表、列，再基于表、列，根据问题的复杂性来进行分类，是简单的一个单表查询的 SQL，还是有一些 join 语句的 SQL，还是在 join 的基础上有一些复杂子查询的 SQL。为什么这样分类呢？因为对于很简单的单表查询的 SQL，如果用复杂的 prompt 模板去生成，效果反而会下降，所以加了一个分类的 prompt。在这篇论文里，还加了 self-correction 的 prompt 的模板，告诉大模型再帮我优化一下 SQL。基于这一系列子任务，还有思维链的工程，最终才能让 GPT4 生成比较准确的 SQL 语句。

实践过程中发现，无论是传统的预训练模型还是大模型，都面临着很多挑战。传统预训练模型的语义泛化能力肯定比大模型弱，它的生成能力也不一定比大模型强，容易出现 missmatch 的问题，复杂查询语句的生成能力也比较弱，加上 Encoder、Decoder 采用了大量复杂的优化策略，尤其是基于 graph based 方法，还要人工先生成 meta-path，维护这些 meta-path 也需要大量的工作，相比于大模型的 zero-shot、few-shot 能力，还要准备一些标注语料，工作量也是很大的。比如 T53B 模型用的显卡资源并不比大模型少。

大模型也同样面临一些挑战，最近发表的所有的 Text2SQL 论文全部集中在 GPT4 的研究，对于本地化、私有化的大模型研究偏少。Prompt 的良好实践，比较依赖于思维链，还有 in-context learning，也就是要给大模型一些样例数据去引导它生成更加准确的 SQL，但对于复杂的 schema，就会超出大模型的 token。所以有一种做法是先把表预处理成宽表，生成的 SQL 就没那么复杂了，就变成了基于宽表去生成查询语句，不用做 join 操作。但生成宽表的时候，面临着 schema 非常大的问题，很容易超出它的 token。基于私有化大模型的微调也是非常少的。

我们认为传统预训练模型和大模型都面临着一个共同的挑战，用户在实际使用过程中其实不知道数据是在哪一个数据库中，怎么去从大量的库、表、几千行的 schema 中找到问题对应的列和表，高效的完成 schema-linking 是非常困难的。现在很多 Text2SQL 的评测任务是已经假定了要用哪个库，这个库中的表和列往往是非常少的，所以没有遇到复杂的 schema 中找数的问题。

我们提出了一些实践和方法，先构建一个元数据的语义图谱，语义就是问题加上表名加列名，这就是生成 SQL 需要用到的所有语义。当我们去生成一个语义图谱的时候，有更多的 label 信息，还有指标的描述，能补充到这个语义里，让 prompt 生成的准确率更高。生成语义图谱，需要一套完备的数据治理工具。我们在数据建模的时候，有一套自动化的数据标准工具，把这套数据标准落到数据模型中，称为模型落标的过程。基于数据标准完成数据模型的时候，会把逻辑层、概念层的元数据，还有管理元数据共同落到元数据目录上，再基于元数据目录最终生成语义图谱，这个是生成元数据血缘的过程。

另外有些客户在搭建数仓的过程中，会抄一些事实表、维度表，这种数仓建模的形式，整个数仓建模直接做成从逻辑层开始建模，但是当建模完成后，数据开发人员不知道这个表对应到什么业务口径，而业务口径也不知道这个业务指标需要用到哪些表，有哪些工作流，这也导致了语义不对等的问题。更多业务口径的语义在哪里？其实是在概念层上面，现在大家做概念层的语义其实全部是用知识图谱去做的，所以这个血缘图谱在 Text2SQL 的任务上是非常重要的。很多论文中的数据预处理的工作是在做语义转换，比如表名叫 department，其实就用 DEPT 简称来缩写，DEPT 是一个没有任何意义的列名，SQL 模型怎么能识别得到呢？所以需要一些数据治理的前期准备工作。

现在业界都是基于 GPT4 去做 Text2SQL 任务，我们与一些国产大模型开展生态合作，接入了它们的一些接口去做测试。现在所有测试是基于特定场景、特定数据、特定私有化的大模型去做的，仅供参考，不一定是具有很高的代表性。我们发现私有化大模型的指令微调在 Text2SQL 任务上的效果是有限的，这个问题相信很快会得到解决。另外基于 schema-linking 所选取出来的元数据信息，再去生成 prompt，在私有化的大模型上，Text2SQL 任务有 5% 到 10% 的提升。先用一个 schema-linking 的模型，先找出和问题相关的表名、列名，再基于表名、列名去做prompt 模板，模型的准确率会有提升，而不是直接把所有元数据信息喂给大模型。基于预训练模型 schema-linking 的效果是好于大模型的。In-context learning 对私有化大模型的提升效果是最明显的，大概有 10% 的提升。我们之前 Text2SQL 经常用的 Intermediate Representation 的方法，生成自然语言和 SQL 语句的一种中间语言策略在部分大模型上没有化学反应，甚至效果更差。Self-correction 对私有化大模型有小幅提升。相比于私有化大模型，目前 GPT4 的效果还是遥遥领先的。

这就是我们提出的方法，schema-linking 是基于预训练模型去找到问题相关的表和列名，再基于 prompt 去做大模型，现在很多评测，尤其榜单的评测数据，用到的表名和列名非常少，所以在做 schema-linking 的时候，也加大了难度，给它更多不同的数据库、不同的表、不同的列名，其 AUC 并没有明显的下降。

这是我们基于人大今年发表的一篇 RESDSQL 的论文所做的 schema-linking。其底层是 RoBERTa，基于 RoBERTa 做 Pooling Module，把切的词对应到完整的表名或者列名上，在做多头注意力的时候，对列名做多头注意力，把一些列的信息嵌入到表名上来提升它对问题相关的表名、列名做排序。我们是基于这个模型做的 schema-linking。

我们也参考了阿里发表的 Dail SQL 这篇论文，其中提出了 prompt 模板的一个标准方法，基于 prompt 模板，再加上 GPT4，准确率能达到 85-86%。一开始用了 Code Representation 来表示 schema，然后用了 Intermediate Representation，同时最重要的是加入了 in-context learning。这篇论文中，同时使用了相似的问题和相似的 SQL 去组成 prompt 模板中的示例，提示大模型去生成正确的 SQL。其实这里缺失了 schema 结构的相似性，很多时候sql语句的结构不光取决于问题，还取决于对应的数据库 schema 结构，如何在相似问题和相似 SQL 的基础上引入相似 schema 的判断，我们认为是大模型生成SQL下一个可以探索的方向。

上图中列出了一些 Prompt 的成功实践。比如分割符的应用和结构设计，可以让大模型知道哪一个部分是在提问，哪一个部分是在讲 schema，哪一部分是讲 in-context learning。另外我们会加入一些输出前缀，能让大模型在生成答案的时候更加稳定。这就涉及到大模型的鲁棒性，以及指定遵从性的问题，因为测试的过程中，我们会用大模型去尝试做 schema-linking，让它按 JSON 格式输出问题相关的列名和表名，可能 10 次中会有 1 次报错，比如 JSON 里有个反括号漏掉了，所以鲁棒性还是有一定问题的。

接下来介绍数造科技的产品是如何实现 DataOps 与大模型融合的。

上图是数造科技的产品体系架构。对 DataOps 的整个过程，包括数据集成、开发，提供了标准化的流程和方法，同时基于数据湖仓适配了不同的私有化大模型，基于私有化大模型去完成代码生成、代码解释的工作，帮助 DataOps 提效。同时有统一元数据的服务，对于 Text2SQL 任务来说，语义就在表名、列名和问题上，因此要提供更多的语义信息，构建元数据血缘图谱。

开发治理一体化的数据管道包括管理域、开发域、治理域。其中，治理域包括一套自动化的数据标准和工具，帮助我们在数据建模的时候落地数据标准，不允许生成毫无意义的表名、列名，这些会严重影响 Text2SQL 任务效果。开发域会基于大模型做代码生成、代码解析，还有注释标注的工作。

最后，产品会有持续集成与发布的能力，包括一套代码在多套环境运行的这种多环境创建和管理的能力。

上图展示了我们产品的部分功能界面。有些企业采用 Altas 等开源的图数据血缘工具，它有一个最大的问题是一张表可能有几十个列，一展开就是爆炸式的、很多的点，读起来非常困难。所以我们在数据血缘方面做了很多优化的工作，不光是把底层元数据的数据血缘管理起来，也做了一些可视化的优化，让数据开发人员能真正的基于可视化的界面去探查整个数据血缘。

上图展示的是数据自动落标、工作流编排等功能。

这是我们做的初版 Text2SQL 的智能小助手，基于输入的问题可以找出相关的元数据信息，如果不准，还能根据之前的数据治理标准，手动修正相关的主题域，再去喂给大模型生成 SQL。

生成的 SQL 不单单只是看，有一个比较方便的富文本编辑器，直接在编辑器上选定 SQL 运行，可以查看报表。

最后是持续集成和持续发布的功能。

四、未来展望

最后分享一些对未来的展望。

我们构建元数据的语义图谱，尤其是指标层，包含了更多的业务语义、业务口径等。如何把每个数据标准自动化工具嵌入到模型中，这是我们未来要做的工作，基于更多的语义，看模型的提升效果怎么样，现在需要一些人工去给 Spider 数据去做语义的补充。

知识图谱有很多子图检索增强问答的方法，我们也在思考，把语义元素去图谱后，能不能借鉴知识图谱基于子图检索增强的方法去嵌入子图的信息，基于子图去提升 schema-linking 的效果，这也是我们未来想要探索的方向。

另外我们看到大模型，把整个 SQL 任务拆成不同的子任务，基于这些子任务的 Prompt 模板，引导模型生成正确的 SQL，那么能否基于大模型去做一个 agent，用不同的子模型去完成各个阶段的 SQL 生成任务，这也是我们目前的一种设想。

近几个月来我们看到了很多 long-context 大模型的出现，现在的大模型可能就是 2k、4k，有一些长文本的大模型已经输入到了 200k。现在 Text2SQL 最大的问题就是怎么把大量的生产环境的元数据喂给模型，所以我们也在想 long-context 的大模型能不能直接把所有的元数据喂给它，不需要再做元数据分片的工作，让它去生成 SQL。当然，关于 long-context 大模型的效果，大家也还在观望中，这种大模型的注意力在于头尾，中间的信息可能会缺失，所以这也是我们关注的一个点。

数造科技专注于数据治理、DataOps、数据开发，是新一代敏捷数据管理平台的供应商，具有大数据赋能能力。

我们的产品是一站式的数据开发管控平台，包括数据治理、血缘图谱的构建，还有自动化标准数据治理的工具，以及行业大数据解决方案。