转转大数据与AI——数据治理安全打标实践

一、导读

这次主要分享介绍的是转转在大数据治理方面应用AI大模型技术实现的自动安全打标，本文主要从以下几个方面逐一介绍，首先是应用背景介绍、技术方案的实现与落地、以及对整个应用的优化实践，最后对后续的规划和展望进行总结，希望读者可以从本文中获取到前进的动力。

二、应用背景介绍

2.1 什么是数据治理，为什么要做安全打标

2.1.1 数据治理是什么

数据治理是从业务流到信息流、数据流、数据库表的流转。业务系统中的物理表字段，哪怕短期内由于无法改变业务系统不能完成源头治理，也要在数仓的ODS层完成治理，形成能还原业务本质的数据映像，总体来说，整个数据治理的核心动作包括两个部分，一个是业务数据的治理 （形成真实数据映像），另一个是分析体系的治理（基于数据映像面向管控目标做合理性的分析结构设计及实现）。

安全打标也是数据治理的一个环节，为了满足安全管控，合规使用，权限隔离需要对每一张表和字段合理打上标记，它也是属于数据治理两大体系中的分析体系治理中的一个重要环节。

对于数据治理核心内容可概括为三块内容：数据治理体系设计、业务数据深化治理、分析数据体系设计

数据治理体系设计：主要设计数据架构、数据标准、主数据，通过机制设计固化专项治理能力，保障数据治理活动持续开展。
业务数据深化治理：资产目录主要厘清业务数据资产（划分责任田），数据模型定义了数据对象之间的关系（指导系统开发），数据标准设计统一了数据语言消除歧义，数据分布定义用于识别数据的来龙去脉（定位数据问题），数据质量用于改善重点领域数据质量专项提升。
分析数据体系设计：指标管理体系和运营绩效指标体系设计主要用于理清分析数据资产，数据应用需求设计主要作用帮助数据能力供给设计。

2.1.2 为什么要做安全打标

安全打标主要受制于管控的需要，安全等级是灵活的可支持追加额外的等级规范制度，当某个表有了相应的安全等级，就可以根据等级的不同来授予相应的权限给业务减少不必要的安全问题。
安全打标一方面是管理并控制了某个业务的授权等级，另一方面他也是分析治理体系中的重要一环，它支撑了分析治理的安全基石，制定了分析规范的条件。

2.2 AI安全打标解决的核心问题

AI安全打标支持表和字段粒度的打标，并支持表和字段增量变更捕获逻辑，对于人工打标来讲，不但打标结果慢，而且会出现很多主观臆断导致表打标的安全等级不正确，在AI打标的统一元数据管理下，可以有效减少这一问题，使正确率大大提高，AI打标结果不但速度快，可自动化打标成本大大降低。

及时性： AI打标采用微批处理 机制，分钟级别自动响应元数据的变更，相较于人工不定时响应来比（不包括模式进化），实现了近实时的敏捷响应，平衡了处理效率与系统负载。
细粒度：支持从数据表到字段级别的精准打标，满足不同业务场景下对数据安全分类的差异化管控需求。
准确性：基于优化后的提示词模型与规则元数据进行自动化判断，最大限度地消除了人为主观臆断，确保安全等级判定的标准统一与准确可靠。
成本：自动化流程显著减少了持续投入的人力成本，一次建设即可长期、规模化运行，优于人工这种短期回报模式。
增量变更：系统自动监测并捕获元数据的结构化变更（如增删改字段），并在下一个处理周期内触发针对变更部分的智能重打标，确保数据资产在演进过程中，其安全标签始终保持最新且有效。

通过AI打标，平台能够在保障数据安全合规的基石上，构建起一个高效、精准、可自适应演化的智能数据治理体系，为数据价值的持续释放提供坚实保障。

2.3 AI技术的发展与应用

AI安全打标的背后，是过去近十年人工智能技术，特别是自然语言处理（NLP）领域的根本性突破的集中体现。其发展历程有波峰和低谷，其中有几次关键性的突破

2017年前使用的是循环神经网络RNN以及变体LSTM等处理序列化数据，他们通过循环连接传递信息，但计算无法并行，难以捕获长距离的依赖瓶颈
2017年Google 提出的Transformer 架构彻底改变了这一局面，其核心创新在于自注意力（Self-Attention）机制和算法
2018-2022年预训练 与规模化时，基于Transformer确立了预训练 + 微调的范式，模型参数呈指数级增长
2023年至今可以看成**MASS（模型作为一种服务）**时代，也就是模型作为一种服务提供商业价值，业内从追求规模转向创造价值，模型服务也可以创造价值，并构建应用生态，用户更注重如何 "用好模型"

2.4 ZZ-Dify平台的作用

ZZ-Dify平台可以看做是加速AI打标应用落地的基座，Dify本身是一种开源的MASS平台，尽管平台模型能力以及能支撑应用的底座，但是将其转化为一个稳定、可运维的AI打标应用，仍需要设计复杂的工程作业，Dify作为一个开源的LLM应用开发平台，其核心价值在于缩短AI应用开发周期，其作用体现到以下几个层面：

降低技术门槛，实现可视化的开发，配套设施比较齐全
构建运维和应用的优化闭环，支持持续迭代功能，一站式部署
支持多模式部署，工作流（workflow）和智能体（agent）可满足不同业务场景的需求

2.5 大模型技术的缺陷和问题

**高负载下的脆弱性：**需要一次性处理海量表结构变更或复杂嵌套数据结构时，模型的推理能力可能崩溃，输出质量急剧下降
**抗干扰能力弱：**打标任务中可能存在大量无关信息或格式混乱的元数据信息（如冗长的注释），模型容易受到这些"干扰信息"的污染，从而偏离核心判断逻辑
**过度助长导致的捏造：**当模型在Markdown文档中找不到明确的分类依据时，出于"完成任务"的倾向，可能会编造一个看似合理但实际上错误的规则或标签

三、技术实现与落地

3.1 技术方案设计

3.1.1 架构设计

Rest Api：提供对外API服务，暴露统一服务能力，主要负责AI打标相关接口
LockManager & Mysql Distributed Lock: 封装的锁管理工具，内置Mysql 分布式锁，实现在多xxl-job service 并发下单表AI打标功能的原子性
AI Module：主要提供AI打标应用所需业务方法，包含元数据组装，Onservice/星河调用逻辑的封装，配合ZZSchedule（XXL-JOB）完成AI打标自动化闭环处理
ZZSchedule：xxl-job分布式高性能调度程序，用于微批自动AI打标程序，自动处理模式演进模式
Notify Module：通知模块，用于监听AI打标结果变更并通过企业微信等其他方式通知到相关负责人
Log Storage：日志存储工具，主要记录AI打标从头到尾链路追踪，方便问题排查，分析打标结果并用于二次模型打标使用
Rate Limiter：内置限流器抽象工厂，支持令牌桶和漏桶限流，限制单秒内最大AI打标并发数量，用于控制线程池任务队列，防止任务排队过长导致异常队列告警
Schedule Module：调度模块主要用于控制调度任务正常运转，记录任务的执行元数据，管理自动调度程序状态机扭转
Local Caffine Cache：AI打标本地缓存，记录AI打标元数据相关信息，定期更新表元数据信息，在保障高性能下的数据的最终一致性
OneService / 星河：主要负责调用外部数据接口应用，可支持任意Hive SQL查询，通过调用统一的接口服务来获取数据真实数据
Mysql MetaData：用于管理整个AI打标元数据，协调AI打标程序自动化闭环处理，管控打标元数据

3.1.2 Schema Evolution 模式演变

Schema Evolution（模式进化）：模式进化通俗理解就是业务数据库字段发生变更，上游字段变更会导致下游离线任务出现错误，模式进化也是数据湖技术需要重点关注的一个点，对于AI打标需要考虑到上游字段变更后的原打标结果是否适用新的模式，需要适当进行版本管理，一般通过程序解决的方式是定时一个异步任务来监听哪些字段发生变更然后最终一致性的修改元数据结构

监听机制：捕获上游数据源的DDL变更事件，直接利用定时元数据对比，感知元数据是否发生变更
解析机制：提取变更类型（增/删/改列）、影响范围，找到未被打标的字段以及表关系映射
同步机制：原子性重新调用AI并打标，并根据字段打标等级推断出表的安全等级，重写原打标元数据
通知机制：持续监听并对比结果是否存在差异，告警到企业微信

3.1.3 统一元数据结构

markdown 复制代码

              图7 元数据结构

统一元数据结构主要包含四大部分，第一部分是数据库元数据信息包含表、类型、字段相关信息，第二部分包含字段真实数据，第三部分是规则元数据包含相应的规则描述和对应的安全等级第四部分包含一些额外的扩展信息，比如压缩类别和元数据格式

3.1.4 任务时序图

基础数据平台：主要负责元数据的管理，用于AI打标规则元数据管控，调用OneService或者直接调用星河API查询实例数据，作为AI打标的起始点
OneService/星河：提供数据查询入口，58内部大数据管理平台，提供统一API查询，创建离线实时任务，OneService为内部服务查询网关层，支持不同数据源查询
Dify平台：大模型平台应用，主要提供Rest API服务，支持工作流创建、构建统一参数的AI打标服务，内部可构建Python、Scripts语音工具，支持多模态组件，适配多种插件
DeepSeek/Doubao：商业化大模型基座，主要用于支撑转转内部快速构建内部大模型应用，在一定程度上可以保证业务数据的安全性

3.2 Dify平台企业级工作流设计

3.2.1 WorkFlow设计

初版AI打标工作流

合并后最终版AI打标工作流

初版AI打标工作流：该版本拆分多个任务并行跑一份相同的元数据，按照元数据结构拆分三个部分，第一个部分包含了实例数据，第二部分不包含实例数据仅包含基本数据结构，第三部分包含全部元数据 + 实例数据并通过动态知识库，最终三个部分汇总并交给AI得出最终结果，其中包含分词知识库的建立
合并后最终版AI打标工作流：由于上述过程存在结果冗余，并且大模型分词系统不够完善，分词Token过大过长导致最优匹配出的结果出现很大的偏差，从而导致整个结果出现较大误差，经过权衡现有技术与成本考量，取代三分支聚合工作流，仅由一条主干路来来完成AI打标，配合Java程序对AI结果在分析（二阶段升级打标处理）来提高整体正确率

3.2.2 Python脚本处理元数据组装

Python处理过程主要分为四大步① 接受到Json结构的元数据，解析元数据 ② 提交SQL任务并等待任务执行完成 ③ 按照压缩算法以及元数据指定的格式，生成AI模型易识别的MarkDown语法结构

3.2.3 编写Prompt提示词

Markdown语法是现阶段AI模型比较容易精准识别分析的结果，下面是AI打标调优后的Markdown提示词结构

提示词主要包含四个部分：AI承担的角色、**打标元数据、元数据描述的规则、打标结果格式规范，**这四部分主要告诉大模型你现在的工作主题，都有哪些需要提前学习了解的，按照相应的逻辑来学习并记录下得出一个规范化的结果

四、优化案例

4.1 AI打标Prompt优化（提高准确率）

AI打标提示词经过多个版本迭代，目前已经支持上千张表，在保证完成整个功能的前提下，最大限度提高AI打标准确率，总结出提示词优化五大步骤，现将优化步骤以及最终模板做如下阐述

清晰完整的目标角色定义：让AI成为特定领域的专家标注员，提前说明当前AI承担的主要责任，并要带有确定性的柔性条件，一个清晰完整的目标角色定义在一定程度上会提高整体准确率
结构化Promtpt设计 ：使用带有标签包围的特征值例如使用<table_info></table_info>来说明内容是表元数据，使用<rule_info> </rule_info>来说明内容是规则元数据，标签内部的数据要符合markdown语法，尽量使用 #、##、{name}、这种带有分级且清晰的说明元数据中每一项，这样下来整体的结构就比较清晰确定，减少计算不确定性带来的差异性

输出格式限制词：不同的业务场景都会有相应的规则限制，对于AI打标要制定清晰的规则说明，对于识别的顺序逻辑要从小范围到大范围说明，AI打标有明显的格式数据要求，比如可以明确这样要求输出格式，这样输出格式总是json格式
- 请在打标过程中，先在<思考>标签内详细分析每个字段打标的依据和推理过程，然后按照以下JSON格式输出打标结果，仅返回打标结果，无任何额外文本/解释："json{}"
A/B系统测试对比：优化后的提示词要进行每一项对比，对比准确性、完整性、响应时间、稳定性、Token数量对比并综合一个最优方案，完整的提示词优化必须要经过系统的整体把控从而得出上线后的方案
约束特殊场景：对于AI打标来讲存在一些特殊场景，当元数据中不包含某个字段的规则描述时，此时需要AI自动全网分析得出一个比较符合结果，或者找不到条件的字段不会打标，这些约束要明确制定，特殊场景会让AI先匹配符合约束条件的结果大致相同，对于顺序的逻辑规则可以按序号标号并制定

4.2 打标后重计算结果优化（提高准确率）

由于在分析数百张打标后的结果后，发现AI打标仍存在诸多问题，比如幻读问题，相同数据字段打标的结果不一致等问题，需要对打标后的字段结果进行二次业务处理，处理过程如下

一阶段判定公式

二阶段升级公式

一阶段公式：基本推导表安全等级公式，仅由L4、L3占比以及是否raw表或者ads表来确定最终的表安全等级
二阶段公式 ：二阶推导公式主要用到极值占比概率来提高整体表打标结果，其中会用到自定义敏感词，以及该表包含的子业务信息占比，比如该表有7个子业务域，包含订单信息、商品信息、基本信息、浏览信息、点击行为、搜索行为，其中敏感业务包含订单信息、商品信息、基本信息、浏览信息并且对应字段存在L4安全等级，则会判定 |B_L4| / |B| > 1/3 条件
经综合测试二阶段升级过程大大提高了整体的打标率，配合自定义的敏感业务信息，可灵活控制升级过程，打标升级受限于配置敏感词内容

4.3 分批次打标（提高准确率）

原有模式会将表的全部字段交给模型处理，但是这种模式会出现以下问题
- 超长阶段：模型一次处理的TOKEN数量是有限的，默认是32k大小如果超长会被截断
- 正确率下降：过长的文本会导致模型难以准确识别元数据信息，从而导致结果不一致或者不正确问题
- 打标时间过长：文本过长会导致打标完成时间倍数增长，由原来的一张表2分钟变为5+分钟
优化后模式变为可指定阈值字段数量，在Dify平台接受步长参数，分批次交给大模型，应用层面聚合每一页的结果从而的出最终结果，这种方式不但提高了整体的正确率，而且程序更加稳定，大大提高了AI打标应用的闭环能力

五、AI打标未来规划与展望

5.1 AI打标覆盖全部业务，数据源兼容统一

过去已经完成了Hive元数据的对接和整个链路搭建，但是业务数据存放在各个存储介质上，目前转转会将大部分T+1离线数据存放到Hive上面，实时任务会存到doris、ck、redis、hbase上面，极少数据会放到mysql
未来AI打标系统会将这些存储都集成过来，实现全域元数据的打通，构建统一健全的数据

5.2 AI打标响应速度提高，持续关注模型迭代，适应新模型

响应速度优化：通过使用更加轻量化的模型、推理引擎升级与并发处理增强，显著降低打标延迟，提升实时响应能力。
跟踪模型最新技术： 主动跟踪主流大模型（如 GLM-4.6V 、OpenAI 、Gemini 等）的技术演进路径，探索其在业务信息抽取、意图理解等场景的应用潜力，推动打标逻辑从"规则为主"向"语义主导 + 规则"演进。
**标注效率与准确性双提升：**结合主动学习与反馈闭环，优化标注流程，实现效率与准确率的同步增长。

5.3 AI多数据源自适应表优化服务

Schema Evolution：支持多数据源的增加、删除和修改，统一兼容不同数据源（如Hive、MySQL、Kafka等）的Schema差异
Concurrency Control：支持多数据源并发控制，支持动态调整并发度，适配不同负载场景

六、总结

本次分享系统地介绍了转转在大数据治理领域，应用AI大模型技术实现自动安全打标的完整实践与探索。通过回顾了项目的应用背景、技术方案实现、核心优化策略以及未来规划，展示了一个从概念到落地的AI驱动数据安全治理项目从0到1的完整构建过程。

此工程不仅证明了AI技术在实际数据治理场景中的可行性和价值，更让我深刻体会到几个核心认知：

"用好模型" 比 "追求大模型" 更为关键：我们并非单纯追求模型规模，而是通过Prompt工程、任务拆分、后处理逻辑等技术手段，将大模型能力与具体业务场景深度适配，实现了技术与业务的真正融合。
工程化能力是AI应用落地的根本保障：AI应用要走向成熟可靠，离不开稳定的系统架构、高效的任务调度、完善的监控运维等工程化体系的支撑。此次实践，我们构建了自动化闭环与优化机制，确保了系统在生产环境中的持续稳定运行。
持续优化与迭代是AI应用的生命线：AI应用的性能会持续被优化。项目需要建立基于反馈的迭代机制，持续对提示词、工作流、业务规则进行调优，并紧跟技术演进，才能保持系统的准确性和生命力。

未来，将在现有基础上持续精进，关注AI社区与数据治理领域的最新动态，积极吸收行业先进经验。我们期望通过持续的探索与贡献，推动转转在大数据治理与AI技术融合方面形成更加成熟、统一的解决方案，为企业的数据安全与价值释放提供更坚实的智能支撑。

关于作者

张龙严，转转数据智能部高级数据开发工程师，专注于数据开发与数据治理平台建设。

> 转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。

> 关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~