DataOps+大模型促进数据工程创新(模型数据生成语义创新)

主要内容包括以下五大部分：

1. 传统数据管理面临的挑战

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

3. DataOps+大模型产品落地实践

4. 未来展望

5. 问答环节

分享嘉宾｜杨明皓 海南数造科技有限公司 高级大数据技术专家

编辑整理｜彭爽

内容校对｜李瑶

出品社区｜DataFun

01

传统数据管理面临的挑战

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

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

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

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

02

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

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

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

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

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

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

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

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

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

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

03

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 运行，可以查看报表。

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

04

未来展望

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

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

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

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

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

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

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

以上就是本次分享的内容，谢谢大家。

05

问答环节

Q1：我们现在的实现方案，首先在找数、找表是单独请求了一些模型，可能在找表的时候有一些表的字段翻译，通过翻译之后，确定哪些表可用，然后再去生成 SQL，因为这个环节有一个召回的过程，前几位的表并不是我们想要的表，这方面该如何实现？

A1：如果是表名的翻译召回，还是得看模型底座的能力。

Q2：在测评模型的时候，对 SQL 复杂度的评级，按照 group by 或者列的数量，对 SQL 复杂度做评级，我们现在测出来复杂度较低的，比如说单表、没有 join 的这种成功率比较高，但是复杂度一旦提高，SQL 就可能有一部分没法执行，也有些 SQL 执行出来的数不是我们想看的数。
想请教一下，如何解决这类问题？

A2：我们也遇到同样的问题，比如带 wikisql 这种单表的查询，效果是确实不错。
但是对于有 join，又有子查询嵌套的 SQL，效果也是不太理想，哪怕基于大模型做了一些监督微调，尤其是我们基于 spider 数据去测，很多问题也遇到过。

Q3：您刚刚有提到关于 Text2SQL，有落地到业务方开始用了吗？

A3：业务方还在尝试中，因为准确率有一定限制。

Q4：我们在实际落地的时候遇到了一个问题，因为其背后是个概率模型，所以它每一次的召回可能是不一样的。
第二个就是 meta-data 可能质量很差，需要大量数据治理，比如我们面对的是分析师或者开发工程师，他就觉得我如果要用上 CHAT 的能力，代价非常大，如何去平衡这个问题？如果他不来用，那模型就没有办法继续调优，因为我们没有真实的数据来训练它，如果一直都是预训练模型的话，其实在实际落地场景的时候就会存在问题。

A4：对，这个问题很经典。
比如冷启动的问题，预训练的数据或评测的数据中没有过多你自己掌握的语料或在里面。
另外很多语义信息，包括表名、列名，需要做数据治理。
对于我们本身就是做数据治理的厂商，我们认为不光是为了 Text2SQL，其实下游的所有的业务系统、模型，如果不去做数据治理的话，一样会产生非常多的问题。
所以对于我们来说这个不是一个选择题，数据治理这件事是必须要做的。

但是这就会面临一个问题，不能快速变现，业务方希望从帮我更好地管理资产到更快地发现生产价值，周期会非常长。
我们目前也没有很好的答案。

Q5：元数据信息是通过什么方式喂给大模型的？

A5：我们输入给大模型，其实还是自然语言的表述，我们的 Prompt 就是一个自然语言的表述，并不是一个向量化的方法，模型内部会有 embedding 层，去做向量化的事情。

Q6：喂给大模型是以一种什么样的形式，包含哪些内容？

A6：元数据 Prompt 模板是看不同的策略，有一些会把它全部拼装成一个序列，表名：列名，列可能有个括号代表它是主键、外键。
也有些就把一个 DDL 的语句直接放到 Prompt 上面，这也是一种方法。
如果 schema 用 DDL 语句的形式，可能它对大模型的效果会更好一些。

Q7：关于写 SQL 过程 Prompt 的设置，这个设置是有在智能助理里面有做一些提前的设置，还是这些设置都得让用户来写？比如一个场景中，我们有一些枚举的字段，性别这个字段在数据表里面存的是 0 和 1，业务的问题是请统计这个表里面所有男性玩游戏的时间，那么怎样让 GPT 理解到性别的那个字段 0 表示的就是男性，同时在 SQL 里面显示出来。

A7：我们的智能小助手背后已经有一套标准化的模板，基于接入的不同的模型，比如 GPT4 或者私有化部署的大模型，我们会定义一个默认模板，后面我们会考虑可能用户希望自己去探索他的 Prompt 的模板，我们可能会开放 Prompt 编辑的功能，目前是系统内置好的。

如果它是一些枚举值，在你的问题中，你告诉大模型，要找出性别等于男的，可能大模型不一定能 get 到这个信息，有可能会报错。

Q8：你刚刚是说后台有一个 Prompt 模板，相当于用户在登录在对话框里去输入一个问题，其实是会和那个模板结合起来，一起给 GPT 来回答，然后生成 SQL 的？

A8：是的，没错。

以上就是本次分享的内容，谢谢大家。