LLM Agent 大规模用于数据治理之元数据补全

数据治理是企业对数据资产进行全方位管理的一套机制和流程，目的是确保数据质量、合规、安全性和可用。举一个简单的例子，业务想导出部分生产的数据，在合规的角度，我们必须知道这个表是否是敏感表，这个表的导出授权要经过哪些人审批等。

而元数据是数据治理的核心，由于管理规范和用户敏感信息保护，我们无法直接获取数据库中的真实数据记录，比如用户名，用户密码等。但我们可以通过管理数据库中描述数据的元数据，比如表描述、字段描述等展开管理，元数据就是描述数据的数据，在 mysql 表描述和字段描述可以在创建表和字段的时候开发同学进行定义。

然而，现实中，存在两个问题。1. 开发并未按规范在生成表和字段的时候添加注释。 2. 还有部分元数据是无法通过数据库原生的语法进行定义的，比如表的业务含义，字段加工口径，表更新方式，表更新失效，敏感等级等。这些信息带有业务含义，通常需要后期进行人工维护。

对于增量的数据，我们可以定义数据治理的管理规范，强制用户在生成表和字段的时候，人工补全这些信息。由于历史原因，存量待补全的表级数据量高达几百万，字段级数据高达上亿。这几乎不太可能全部由人工维护。

基于 LLM 的元数据自动化补全由此而生。

核心技术点

当我们面对几百万表和上亿字段的元数据补全任务时，传统的人工方式显然行不通。而传统的 NLP技术仅仅是简单的字符预测补全，无法推理，大模型的诞生让这个在过去不可能完成的任务变成现实。

多维上下文增强LLM推理

我们最初发现，如果只给LLM一个表名或字段名，它生成的描述往往过于泛泛，缺乏业务特性。这就像给你看一个名为"user_info"的表名，你能猜到它存储用户信息，但具体是哪类用户？存储了哪些关键信息？这些都无从得知。

为了解决这个问题，我们构建了"多维上下文"体系，这有点像给模型提供"全息视角"：

• 不仅告诉它表名，还提供所有字段及其类型

• 不仅有字段信息，还有表间的血缘关系

• 不仅有技术信息，还有业务域知识

• 不仅仅是关系，还有生成当前表的上游原始 SQL

举个例子，当我们处理一个名为"fund_trans_detail"的表时，我们不仅提供表结构，还会告诉模型这个表上游连接了哪些表、下游流向了哪里、它属于哪个业务系统、涉及哪类金融产品，如果这个trans_detail的下游人工注释是“贷款资金交易历史记录”，人类通常会判断 “fund_trans_detail” 表是用于贷款的一个资金交易明细。

这种立体式上下文让模型能够"站在业务视角"去理解数据，生成的描述也就更加贴近业务实际。有时候，甚至会惊讶于模型能从这些碎片化信息中推断出准确的业务场景， 这种理解能力远超一般的人类。我们验证了大量补全任务案例，特别是涉及生成 SQL 的推断场景，由于上游多层 SQL 综合影响结果，对于人类开发而言，本身是一个有挑战的预测任务。

想象给你分配一个不是你负责的表，没有注释，你必须通过上游关系，生成SQL（可能是多层），逐一推断这个表是什么含义，这对技术领域的知识广度有一定要求的。

其中有意思的一些案例是【不规范的命名表】，比如数据库中有些表是类似这样命名的，“sfzlist”,  初步看，人类有点懵逼，模型竟然能预测出 sfz 是身份证的缩写，但这种有点随缘，不规范的命名是预测失败占比最高的因素。这里也延伸出一个问题点，模型预测的准确性和“原始表的质量”正相关，比如命名规范，上下游应用规范等。观察了大部分预测失败或者效果不佳的案例，这些案例分发给人类开发（和当前表无关的开发）去看，也难以准确预测。 比如有的表命名为 loginuser_list 里面确实有用户信息，但实际因为历史债的原因，这个表已经成了“销户”用户列表～～ 这种情况，如果不深入追踪代码，基本无法预测。然而追溯代码的成本非常高，且涉及合规，以及团队协作等问题，我们并未把代码追溯作为 LLM预测的一个方案。 但能想象，在拥有代码知识的背景，AI 预测的准确性会提高，但 GPU 推理成本也会提高（Agent 迭代调用）。

多Agent专家架构

这里的 Agent 并不是我们想象的自主决策 Agent ，仅仅是针对不同的任务，定制化不同的提示词，以及应用不同的上下文。我们发现不同类型的元数据补全任务有着不同的特点。比如，表业务含义描述需要宏观的理解生产SQL，而判断敏感等级则需要内部定义的敏感等级规范细节等。所以 AI 预测必须是针对性调优，不同的任务不同的"Agent"

类似医院的专科体系 - 你不会让眼科医生去做心脏手术，对吧？于是我们设计了"专家Agent矩阵"：

- 表描述专家：擅长从上下游血缘和字段结构中推理

- 字段描述专家：专注解读单个字段的含义和用途

- 敏感等级专家：精通数据安全分类标准

- 更新频率专家：分析日志推断数据更新规律

- 表业务含义专家：擅长从宏观理解表的业务用途

... ...

每个"专家"都有自己独特的提示词设计和上下文处理逻辑。例如，敏感等级专家会被注入行内的敏感数据分类标准，而表业务含义专家则更注重业务流程理解。

这种专家分工制极大提高了各类任务的准确率。

知识增强与约束生成

普通的 LLM 知道什么是"客户号"、"账户"这样的通用概念，但对企业内部的特定术语如"非柜面"、"理财产品代码"等专有名词却知之甚少。

为了弥补这个差距，我们构建了企业特定的领域知识库，涵盖：

- 金融业务术语表

- 内部系统缩写词典

- 敏感数据分类标准

- 表名缩写等

这些知识被动态注入到提示词中，帮助模型理解特定行业和企业背景。但这里要提到一个评估（下面会讲）观察到的结果——领域知识的作用对 Agent 整体的效果不是很大。这一结果和我们预想的不一样，一会我也会分享下原因。

自动评估与质量控制

最初，我们用很少的时间快速搭建了整个 Agent 自动补全的项目。但随后一个多月的时间基本都在构建评估，包括评估的后台，以及管理台等。因为你没有评估，就无法度量，无法改进 prompts ，单纯的观察 1-2 个特例是无法成为优化提示词的原因，面对海量数据，必须要有自动化评估。

我们设计了"AI评审员"机制：用另一个经过特殊调优的评估模型来评价生成模型的输出质量。具体做法是：

1. 利用已有人工标注的元数据，或者已经有人类标注的数据（对于表描述和字段描述历史数据有存量的数据）

2. 遮掩人工标注的答案，让不同的 Agent 策略分别重新生成

3. 基于 AI 生成的结果和人工标注的答案，让评估模型判断元数据的好坏

4. 挑选平均得分最高的 Agent 策略。

选择范围配置 → 选择任务类型 → 选择提示词和评估提示词 → 启动评估 → 监控评估进度 → 查看评估结果 → 应用最佳提示词

评估提示词大概是这样的

你是一个资深数据库评估专家，现在需要你评估元数据库AI 生成和人工标注的一致性。

评估内容:

1. 原始内容: {original}

2. AI预测的内容: {predicted}

请根据以下标准评分(0-100分):

- 90-100分: 完全准确，且解释更清晰（包含了字段用途、业务含义等）

- 70-89分: 基本准确，核心含义一致

- 50-69分: 部分准确，但有遗漏或偏差

- 0-49分: 描述不准确或完全无关

请只返回一个数字分数，不需要其他解释。

————————

【以上提示词仅仅示例】

我们建立了0-100分的评分体系，设定一定的优化目标以及优化时间成本，当某个任务优化到一定阶段，分数无法增长时，通常就会降低在某个任务的优化投入。

前面我们提到过，业务提供的知识库对 Agent 预测的结果并无效果。这是因为这些知识过度关注上层概念，比如表命名规范，常识性缩写。这些知识是从业务的视角常规的知识，但开发在数据库建表的过程真正遵守了？从这个规范是否能推断出含义？ 实际上难倒模型补全的是这些开发在写代码过程的“私有知识”，比如拼音缩写“sfz”代表身份证，qq_applay代表手支付。这种东西通常是一个团队内的开发同学才能知道。 但我们无法一对一地收集这些知识。

于是在构建评估的过程，我们尝试自动优化的策略。即由 AI 生成知识库，并自动注入提示词，再评估——再生成——再评估的流程。

AI 自动化生成知识库有两个策略。

- 基于符号分割表/字段名获取高频率缩写。 比如 abc_name_list 自动拆分成 abc、name、list，然后统计在一定范围（比如部门，团队等）数据库表和字段的频率最高的 top 缩写（比如前 1000 个）。然后再排除掉常见的词汇（比如 id、name等），剩下的 top 高频缩写待生成知识。

生成知识的过程：基于缩写反向查表追溯到被使用到的原始表和原始字段以及相关注释，让 LLM 预测这个缩写的含义。

提示词大概如下

你是一个专业的数据库命名规范专家，帮助用户解析数据库中的缩写含义。   请根据以下上下文信息，推测缩写 {{ context(abbreviation) }}最可能的完整含义。 

请仅回答这个缩写代表的完整词语或短语，不要有任何解释、引导语或标点符号。   

上下文信息： {{ context(related_tables) }}   

请给出缩写{{ context(abbreviation) }}的完整含义

- Agent smart 模式——基于 bad_case 自动生成知识。

在评估环节，自动把打分较低的案例收集起来，其中包括 AI 预测的结果，人类标注的结果，以及表的相关上下文信息，让另一个 AI 分析，需要增加哪些知识，才会让 AI 的结果更准确，接近 人类的标注。

提示词大概如下

你是一位数据库知识提取专家，在帮我们分析大模型生成表描述/字段描述中失败的关键知识缺失。

请分析以下多个错误预测案例，识别出导致预测失败的共同关键缩写词（表名中的缩写），或者关键知识点（比如表的单词组合），并给出它们的真实含义。

举一个例子：

... ... more ... ...

我们把这些关键影响 AI 预测的因素，当成需要提取的 "知识"，或者缩写。

以下是从 AI 预测的结果表中取出需要被分析的案例：

{{ context('cases_text') }}

请综合分析以上案例，按如下格式返回识别出的关键缩写词或者知识术语，提高大模型预测得分:

```json

{

  "analysis": "一步一步分析每个案例，AI 会预测失败的原因，推理补充哪些知识，将会对 AI 的预测产生帮助",

  "result": [

    {

      "abbreviation": "知识名/缩写词1",

      "meaning": "含义1"

    },

    {

      "abbreviation": "知识名/缩写词2",

      "meaning": "含义2"

    }

  ]

}

```

... ... more

按 JSON 格式返回， 先在 analysis 中分析，再填充 result 结果。 

通过上面的评估 + 自动化收集的策略，我们发现 AI 生成的知识，比业务提供的知识更有效，在整体平均得分会提高2-3分，但这一提高不显著，有更大的细节优化空间。

但光有自动评估不够，因为评估的标准会影响结果，我们定期把 AI 预测的任务发给业务同学进行打分或者反馈，以此来改进评估本身。比如 AI 的预测可能会从上下游推断出更准确的含义，但人类标注可能会忽略这一点。这种情况单纯的相似度打分是不客观的，可能导致得分低，所以在后续我们改进了多个版本的评估提示词，并补充了更多的上下文信息，让评估更反映真实的情况。

这种自动评估机制不仅加速了我们的质量控制流程，还提供了持续改进的数据基础。通过分析低分案例，我们能够有针对性地优化提示词和上下文处理逻辑。

实践中的挑战与解决方案

理论很美好，实践中却处处是挑战和坑。

上下文信息过载

最初，我们想当然地认为"信息越多越好"，尽可能的把更多的上下文给大 Agent，结果发现一些认为上下文超过一定量后，模型反而表现更差。有时它会被无关信息干扰，平均得分会更低。比如把多层生成 SQL 给到表的描述任务后，整体得分降低。这些是因为不同的任务依赖的上下文信息不一样。 

我非常喜欢一个比喻，把人类自己想象成是一个有限出窗口的 LLM，当别人扔给你一堆信息后，那些无关紧要的信息占据着你有限的空间，你能更好的完成任务吗？

解决方法：我们建立了"上下文最优阈值"，通过实验确定各类任务的最佳上下文量。例如：

- 表描述任务：最多  N 个字段信息，3-5个血缘关系

- 字段描述任务：相关度前 N 的其他字段

- 生成 SQL ：仅仅在必要任务下才注入

这里也反映了评估的重要性，如果我们不建立评估，根本无法跟踪这类效果。

风格一致性问题

在把模型的预测结果给业务同学检查后，发现业务会在细节上提出一些问题，比如表描述不应该包含具体的字段内容，字段描述不应该包含类型等、字段加工规则不应该包含具体的时间等。

这些细节不会在评估的分数得分反馈，因为它是一种结果风格类的诉求。

解决方法很简单：针对特定范围的任务（业务定义的批次），我们在提示词中加入了格式示例和风格指南，引导模型生成风格一致的内容。比如为表描述指定"20字以内不要生成 xxx ，应该生成 yyy"，再添加几个 few shot 基本能控制整体格式要求。

但要注意的是，这里非常依赖提示词的可配置性，这也是我们花费了大量时间在评估管理台的原因，我们的提示词能根据不同的批次范围动态的配置，每个提示词均能通过 Jinja2 语法动态配置不同的上下文变量，比如领域知识、各种表、字段、血缘上下文信息，以满足快速批量化评估，以及不同业务的个性化需求。

处理速度与成本平衡

面对百万级表和亿级字段，处理速度和API成本成为不得不考虑的问题。在公司中台 rpm/tpm 限流下，我们需要尽可能的通过技术手段以及跨团队合作解决。

- 动态限流机制：实现动态 LLM 网关，根据白天和夜间不同时间段，分配不同的 rpm。

- 任务合并：在相同/相似上下文的任务中，复用上下文。合并返回结果。

- 缓存结果： 在已经生成的表/字段 ID+ 任务类型中，直接使用缓存。（可控制，如果结果优化，则直接覆盖）

- 分批次处理：按业务批次重要性，逐步评估、优化、执行不同的任务范围。这些批次通常是上层业务领域的概念，通常是以部门，系统等为单位。按批次优化处理非常重要，因为实际的元数据补全中，永远只有少数的数据才有业务利用和共享价值，并不需要在全公司范围内处理。

实际效果与价值 

经过一段的开发和优化，最终观察到实际效果在不同批次有显著差异。一些高质量的项目中（第一批次），准确率到达 80% 以上。但更多的批次，准确率在70%-80% 之间。通常在初步评估的批次，可能准确率是 60%+，经过优化提升到70%+非常轻松，但继续把 70% + 的准确率提高到 80%变得异常的困难。 深入到这些案例细节，普遍体现的问题在人工标注的不准确性、表/字段命名以及应用的不规范。这类数据的预测对人类也是挑战，想要继续提升投入会变得更高（比如利用代码，收集更多信息，多伦LLM调用等），但收益不会很明显。

所以，笔者认为AI任务的优化，最终达到一个合适的边际效益即可。更重要的是，这套系统带来的价值远不止于节省人力：

1. 数据资产透明化：元数据让业务人员更容易找到所需数据，促进数据共享和价值挖掘

2. 安全合规提升：准确标识敏感数据，降低数据安全风险

3. 数据治理基础：为后续的其他工作比如，AI 智能问答，数据质量、数据标准等工作奠定基础。

有趣的是，系统上线后，一些业务团队甚至反馈"AI生成的描述比原来的人工描述更准确、更全面"。这在某种程度上验证了的多维上下文方法的有效性 ——AI能够整合分散在多处的信息，生成更全面的理解，而普通的人类在全面理解上将会需要投入更多的思考时间。 但大模型不会简单的替代人类工作，它需要人类用正确的方法、寻找合适的上下文和持续的优化才能发挥最大价值。

如果你也在考虑将LLM应用于数据治理或者相似的任务，希望我们的经验能给你一些启发。记住，上下文是关键，专家化是方向，自动评估是保障。

将 LLM 应用于数据治理的道路很长，而我们才刚刚起步。希望本文能给你一些启发。

————

【本文涉及的表名非真实命名，相关业务信息均已脱敏处理】