AIGC如何在大数据研发治理领域落地？

2023 年 9 月，火山引擎数智平台（VeDI）发布了数据产品大语言模型应用能力：DataLeap-找数助手与DataLeap-开发助手等。这两款能力聚焦企业数据资产查询与数据开发运维两大核心场景，为企业提供从数据资产的检索、到数据开发，再到数据应用的AI 能力。 

找数助手的功能在于：帮助用户，通过自然语言的方式快速找到所需的数据和知识，实现数据的查找和消费。 

开发助手的功能在于：帮助用户通过自然语言撰写SQL代码。此外，它还可以自动实现代码补全、问题调试，提高研发效率，降低研发门槛。

01

找数助手

AIGC在DataLeap数据资产方向的实践

/ 现状与问题

数据资产建设的核心目的，是促进数据消费。如前所述，找数助手主要用于解决数据消费领域的各种问题。在海量数据的场景下，“如何高效、准确地找到数据”成为一个非常耗时的工作，这也是大数据研发工程师在现阶段面临的一个重要挑战。

这个数据不仅限于结构化的表格或经过处理的数据，还依赖于业务知识。在进行数据开发时，我们是将其绑定在特定的业务知识领域，有目的、有需求地进行。因此，如何找到与业务知识相关的背景数据，为下一步数据的使用和研发做好铺垫，正是找数助手能够解决的问题。

我们通常会定义结构化数据和非结构化数据。结构化数据在研发中应用广泛，但许多数据并不适合用结构化方式存储。这些非结构化数据和知识在数据研发链路或数用数据中是缺失的，或者不在整体的闭环系统中。然而，这部分数据具有很大的价值，需要我们加以利用。

/ LLM在找数场景下的应用

LLM(大模型)这项技术具有参数量大、理解能力强、能进行对话式交互等特点，在找数场景中，大模型可以发挥重要作用。

● 理解：当我们提出问题时，模型能够以低门槛、低成本的方式理解问题的含义，即明确我们想要解决的问题。

● 推断：模型在理解问题后，能进一步判断意图。无论在人际或人机对话中，我们说的每句话都有其意图，而这种意图的判断可以依赖于模型的能力。

在结构化元数据描述能力不足的情况下，可以通过语言模型对其进行进一步的加工和丰富，使其变得更加易用和非结构化。

此外，在整个链路中，我们可以从对话和找数的过程中提炼出很多知识，进一步形成后续的语料。这是大模型所具备的能力，也是它在我们的场景中可以发挥的作用。

举例而言，电商领域的业务同学想统计与商家相关的 GMV 信息，他可能会提出一个问题：我想知道商家的 GMV，可以用哪张表来查询？从模型的视角来看，首先要理解业务同学的意图：他是要找一张表？或是询问 GMV 的含义？理解后，模型则会发现他是在找表，而非询问 GMV 的意义。

● 生成：在深入理解用户意图之后，模型能够推断出用户所需表格应具备的信息。在明确问题后，利用 IG 技术为问题提供候选表格。

模型会在候选表格中筛选出用户所需的表格，由于我们可能有大量的候选表格，模型可以通过筛选和理解表格的描述或元信息，以及建立问题和候选表格之间的联系，来确定哪些表格的字段可以解决问题。

通过这个全流程，模型可以自然地与用户进行对话，并提供用户所需的答案。

/ 找数助手的架构与细分介绍

● 整体架构

找数助手整体架构

我们整合现有搜索技术，并借助大模型进行强化，搭建了找数助手的整体框架。找数助手拥有一套完整、且对于传统对话式机器人而言相对成熟的对话框架。

在问题分析和理解这一关键步骤上，找数助手通过识别问题意图、提取关键词，以及合并前、后轮对话内容的上下文信息，以确保用户提出的每个问题都得到有效处理。在问题分析后，则主要借助搜索技术，进行表、元数据或文档方面的检索。

在找数场景中，它会根据不同的意图执行不同的检索流程。例如，业务知识类通常沉淀在公司的业务文档白皮书中，我们可以通过文档搜索技术找到候选集。又如，查找表、数据集等可以通过元数据检索进行垂类搜索。找到候选集后，模型会通过这些候选集来理解问题。首先，需要确定哪些候选集与问题相关，然后对其进行进一步的语义筛选和排序。接下来，通过找到相对集中的表或文档，进行进一步的总结。

这是大模型的优势所在，简单来说，就是让它进行阅读理解。例如，给模型一个表或文档，再告诉它用户的问题，让模型总结出哪些信息可以回答用户的问题。

● 问题理解

1.核心关键词提取

问题理解环节的核心难点在于两个方面：如何提取这些核心关键词？如何通过模型实现对话能力？实际上，这些部分都是大语言模型相对擅长的领域。我们可以给它一些提示，让它对问题中的内容进行提取。

举个例子，假如我们需要了解一些 shop ID、order ID之间的关系。如果我用 "shop" 这句话去做一些语义检索，可能会通过相关性检索到很多只与 shop ID 相关的，或者只与 order ID 相关的候选结果，但这些可能并不是我们特别想要的，或者不够精准。通过语言模型，我们可以提取出 shop ID 和 order ID 是两个非常重要的关键词，需要同时对这两个关键词进行检索，这样才能得到更加匹配的结果。

2.多轮对话问题合并

找数助手的对话能力体现在判断用户的新问题是否需要关联，以及合并多个问题。在对话环境中，我们会根据上下文提问或回答，因此上一轮和下一轮的问题存在关联性。模型可以识别这种关联性。

3.意图判断

在意图部分，需要根据不同场景进行定义。我们结合字节跳动内部的真实找数场景，将意图分为两级：第一级是查找数据，如查找表或数据集；第二级是使用数据，如了解具体指标的定义、枚举值的定义、口径的定义、表的区别，或进行其他方面的咨询。

再下一步是偏向业务的咨询类，涉及数据领域的通用知识。最后是面向研发的问题排查类意图。整体来说，有这么几种意图。使用大模型的通用模型可能无法很好地区分这些意图，我们通常会采用 prompt 工程和精调的方式，以提高准确率。

一级意图	二级意图	问题示例
找数据	找表、数据集	抖音是否有用户维度的消费视频表？
使用数据	问指标	xxx数据集中has_risk=0值的定义是什么？
	问口径	近7天直播间曝光次数口径是什么
	问区别	表xxx与表yyy中的user_id有什么区别？
业务咨询	–	什么是GMV？
问题排查	–	表xxx中的字段a为什么会有空的情况？
其他	闲聊

4.元数据生成

接下来，我们要处理候选集合。我们的目标是寻找表格或业务知识，关键在于其源数据是否丰富，业务描述能否解答问题。

举个简单例子，假如一个普通人拿到很多表格，别人问哪些表格能解决某个问题，他需要查看这些表格的元数据、模式（schema）和描述。如果他能回答这个问题，就说明元数据质量不错。然而，在很多公司，元数据积累并不注重质量，因此我们可以用语言模型提高效率，促使大家尽量丰富元数据。

在元数据整个链路中，低质量元数据资产识别、元数据分发、元数据质量三个环节基本可以通过现有工程手段完成。在元数据完善环节，我们可以借助语言模型提高效率。语言模型能读取表格，进一步推断出模式（schema）信息或描述信息的样子。之后，我们可以人工确认，用这种方式推动大家进一步丰富源数据信息。

5.业务知识沉淀与检索

在企业和公司中，会有很多文档类的知识积累，如何更好地利用这些知识是一个非常重要的问题。在找数场景中，我们可以基于之前的文档切块，进行向量切分和语义匹配。在使用找数功能时，用户与机器或人之间的对话过程非常重要，模型可以通过阅读对话，将知识进一步沉淀为文档或知识类的内容。

在这方面，模型非常擅长，它可以理解你的问题，并给出非常精准的候选结果。

6.答案总结

最后，模型通过对检索结果的阅读和与查询的理解关联，给出答案。举例而言，用户可能会问：有没有与好物直播间经营状况相关的表格？我们的数据库或表中可能有很多与之相关的表格。模型在检索后进行召回，然后对召回结果进行更直接或更精细的描述，以确定该表是否能回答用户的问题。

例如，有一张直播间流量明细表，模型在读取其元数据后可能会判断该表提供了一些直播间的流量信息，包括观看人数、互动等。假如用户想了解经营状况，那么通过该表进行挖掘可能会有所帮助。

再比如，有一些商品表，其中包含了一些商品信息，这些信息也可能与经营状况有关。用户可以通过商品维度来解决问题，该表可能也会有所帮助。因此，在检索结果后进行答案总结是非常关键的，这可以大大提高效率。综上所述，找数的关键在于如何利用模型来理解问题、总结已有语料，并为用户提供更有效的信息。

02

开发助手

AIGC在DataLeap数据研发方向的实践

/ 现状与问题

公司里与数据相关的人群可以分为三类：

● 专业的数据开发人员：这类人群具备较强的数据开发能力，能够轻松处理复杂的数据清洗逻辑，具备专业的数据建模理论。

● 具备一定数据开发技能的用户：这类人群的本职工作可能不是数据开发，但也掌握了一些数据开发技能，能够编写 SQL 语句并进行简单的数据分析。

● 日常工作中需要使用数据但不具备数据开发技能的用户：这类人群的数量较多，他们需要学习简单的 SQL 语句来处理数据。

从我们的角度来看，大模型或 AIGC 技术可以让更多需要使用数据的同学编写简单 SQL 语句，并且让能写简单 SQL 语句的同学具备处理复杂数据开发的能力。这样一来，专业的数据开发同学就能将更多的精力集中在自己擅长的领域，从而提高专业数据开发的效率。

/ 推动数据平民化

推动数据平民化是我们对 AIGC 技术的理解。那么我们该如何衡量这件事的价值呢？假设我们要将其打造成一个产品，又该如何评估这个产品的价值呢？

假设我们有一个数据开发的旧范式（如编写 SQL）和一个新范式（如编写自然语言）。那么产品价值简单来说，就是"原范式成本-新范式的成本-习惯改变成本"。由于我们之前习惯了编写 SQL，有一个 IDE 可以直接编写，因此需要考虑习惯转变的成本。在有了大模型之后，我们需要将其视为助手，并与之交互，实际上是一个相当大的习惯改变。

从上述角度来看，如果最大化产品价值，原范式成本是不变的，那么我们只能将AIGC范式成本与习惯改变成本尽量降低。这主要涉及几个关键问题：

1.为了降低新范式的开发成本，前提在于开发的可靠性。即自然语言编程是可靠的，大模型写代码是可靠的。

2.在该前提下，我们仍然要考虑到，能否将编写自然语言的成本降到最低？

3.如何在大家习惯改变不大的情况下，让他们更好使用这套产品？

/ 开发助手的架构与细分介绍

结合上述思考，我们设计了整个产品架构，分为三层：场景层、工程层、模型层，本文将重点讨论前两层。

开发助手产品架构

● 场景层

1.数据开发场景类型

Coding Copilot：一类场景是类似于软件开发的编程 Copilot，能够生成代码、进行补全、修复错误等。主要支持的语言是 SQL 和 Python，这两种语言在数据开发业务中应用广泛。

知识问答：一类场景是类似于软件开发的编程 Copilot，能够生成代码、进行补全、修复错误等。主要支持的语言是 SQL 和 Python，这两种语言在数据开发业务中应用广泛。

2.场景设计

在大模型应用设计过程中，不同场景有不同要求，也有不同优化方向。以下是两个对比鲜明的场景示例：

场景一：使用自然语言写 SQL（Text2SQL）。

简单来说，就是用户向大模型提问，大模型返回一段代码，整个过程是用户主动提问的过程。

这个场景类似于在工作中向另一位同事提出需求。一般情况下，我会详细描述需求，同时也对同事的回应抱有较高的期望。也就是说，既然我正式提出了需求，自然会希望同事能够提供可靠的交付。不过，我对交付时间的延迟并不敏感，只要结果正确，10 秒或 20 秒完成该需求都可以。在该场景中，准确率和编写提示的成本都是需要重点解决的问题。

场景二：补全。

补全功能，指当我们在 IDE 编写代码时，工具会自动弹出一段可能要编写的代码。如果推荐的代码正确，我们可以直接采纳；如果不正确，可以忽略并继续编写。

由于对用户来说，没有付出成本，因此用户对推荐准确率的期望不高，但对延迟却非常敏感。对用户而言，如果推荐的代码是他一分钟前要写的，那么他已经自己完成，再推给他则无法带来任何帮助，甚至会造成打扰。

● 工程层

1.工程层整体架构

工程层主要包含两部分：

Prompt Engineering：第一部分是 prompt，即输入到大模型的数据。prompt 的质量在很大程度上决定了大模型输出的质量，进而影响产品的质量。因此，我们在这方面做了很多工作，以确定哪些数据应该添加到 prompt 中，哪些不应该添加。

模型对接框架：第二部分是在此过程中沉淀的基础大模型框架，具有较强的通用性。其他做大模型应用的也会有类似的框架，具备多轮会话管理、模型对接以及与向量数据库交互等基础功能。此外，开源领域也有很多类似框架。

Prompt Engineering

以下通过具体实例，来说明Prompt Engineering带来的效率提升效果。

假设我们有一个需求，即查询昨天销量排名前 1000 的商品信息。在有了大模型之后，用户只需输入“一天销量 1000”这三个词，就能得到代码。从效果来看，效率提升巨大，用户输入三个单词，模型就能生成一段 30 行的 SQL 代码，且质量很高，还自动添加了注释。

这一效果得以实现，主要依赖于以下四项关键技术：

Prompt模板：即开发模板功能，旨在解决一些重复性问题。我们将问题中重复的部分做成模板，在遇到类似问题时，只需填写变量就能快速解决。

表结构填充：第二项技术与 SQL 语言和数据场景紧密相关。我们经常需要处理表格，只有在获得表的元信息后，模型才能生成高质量的代码。我们已经与后台的元数据系统进行集成。当用户需要某些元信息时，我们会从元数据系统中将该信息提取出来，并自动将其添加到提示中。

多轮对话：用于用户问题难以一次性描述清楚的场景。有时用户描述问题的成本较高，难免会有遗漏。当完成一轮描述后，用户可能需要补充内容。因此，在这种场景下，多轮对话的上下文非常重要。

字段裁剪：我们在输入信息时会添加很多内容，这样做会产生一些问题。首先，输入大量信息会导致模型性能下降，响应速度变慢。其次，模型的窗口大小有限，无法无限添加信息。因此，筛选有效信息并去除无效信息成为一个重要问题。

我们已经采取了一些措施，例如，当发现用户需求只涉及产品名称而不需要产品库存信息时，我们会在 prompt 中删除所有与产品库存相关的信息，从而大大压缩 prompt。经过这些处理，我们为模型提供了一个相对可靠的 prompt，其中用户编写的部分较少，平台自动添加的部分较多。

2.准确率

模型准确率不像软件工程那样可以一蹴而就，或者说通过一次优化就能完成，它更像是一个持续性的问题，需要不断改进。

在模型上线后，我们收到许多线上反馈，让我们了解模型在哪些场景下表现较好，在哪些场景下表现较差。我们会持续进行反思，考虑是否需要做更多的精调来优化或提升模型的准确性。

3.体验

正如前文所述，在与大模型相关的产品或应用中，用户需要切换工具或改变其开发习惯。因此，对于新产品，最基本的要求是不能比老产品差，更好的情况是让用户基本上无需改变习惯。因此，我们实现了以下三项优化体验：

桌面级IDE体验：Web 产品已经实现了几乎与桌面级IDE一样的体验。所有与大模型的交互都可以在该IDE内完成，无需跳转到其他地方或对话框。当然，用户也可以选择跳转，但在该IDE内即可完成所有交互，也就是能在一个工具中体验到所有相关功能。

关键链路的延迟优化：在模型效果和性能之间，我们需要进行权衡。我们给模型提供大量信息进行推理，会导致推理速度变慢。在某些场景下，推理速度过慢是无法接受的，因此我们尝试加快推理速度，同时减少提供给模型的信息。因此，我们在优化端到端链路延迟方面做了很多工作。

通过 A/B 实验优化模型策略：在许多应用中，难以确定许多策略的优劣与否。例如，我们需要考虑传递什么样的 prompt 才能获得更好的效果。如果不进行实验，很难知道哪种策略更好。因此，我们会通过这种方式进行大量的模型策略实验，以确定哪些策略应该保留并提供给用户在线使用。

● 技术架构

以下将介绍开发助手的整体技术架构。

开发助手技术架构

用户在 Web UI 上的操作包括两部分：用户直接向助手提供输入，如使用自然语言描述需求；同时，系统提供当前上下文信息，如用户正在开发的任务、已编写的代码、光标位置等。这些上下文信息构成原始输入，发送到前面的“输入处理器”（input handler)。

“输入处理器”执行过滤和缓存检查等操作，最终输出原始的prompt。原始的prompt进入下一个阶段，即系统接收到原始prompt后所执行的操作。其中一个重要的操作是，从多个外部系统中获取更多相关信息，以丰富prompt。

用户输入可能只是一句话，但我们丰富后可能变成 100 句。系统中有多种来源可以提供相关信息，如存储的历史记录、元数据系统，以及在线数据存储中存储的更多相关元信息。添加这些信息后，我们得到一个优化的prompt，认为它具有较高的质量，然后将其输入模型，以期获得良好的输出。

模型的输出在大多数情况下可以直接使用，但在某些情况下，需要进行更多的后处理。由于推理可能不够准确，因此需要进行一些工程上的或基于规则的裁剪，或者进一步丰富，以使结果更易于接受或具有更高的质量。最终，我们将得到的结果返回给最终产品或用户，由用户决定采纳或拒绝。

03

未来工作

未来工作将结合找数助手来进行规划，主要包括以下内容：

1.数据生产与消费全流程建设

目前，我们仅完成了消费的第一步（找表）和开发的第一步（写代码），还有很多流程尚未覆盖，比如开发完成后的测试、发布和运维。找到表后还需进行分析，拿到数据后还要检查结果。我们希望在整个数据全链路进行更多实践，并在这个过程中沉淀更多业务信息。这样才能为模型提供更可靠的输入，提升使用效果。

2.效果优化

在和模型本身性能更为相关的效果部分，存在多方面要求：

● 对话理解：准确识别用户意图，提取相关关键词。

● 召回准确率：注重语义、相似性及排序策略等。

● 大模型总结能力：擅长总结的同时，避免出现 Badcase 等。