如何打造一个大模型生成的数据目录？

今年以来，大模型应用怎么落地？这件事一直在琢磨。恰好，数据目录的元数据自动生成，是一个比较典型的切入点。随着“智典”应用正式上线，正好可以聊聊这段探索和思考。

说到底，数据目录的质量，直接决定了企业数据能不能被真正用起来。经过多年治理体系建设，我们的企业级数据目录已经搭起了框架，从下往上分成三层：数据资源目录、资产目录和开放目录，分别对应数据处理的不同阶段。目前纳管的数据资源已经超过2万项。

为了兜住这个目录的完整性，我们设计了40多个标准属性来约束。围绕这个目录，还建了一套闭环管理流程，当前盘点数据的周期已经能做到按天动态更新，月变更数据超过1000项。

按理说，从0到1这一步是走通了。但运营深了以后，挑战也跟着来了。

首先，企业级数据目录覆盖了B/O/M/S四大领域，但各个领域的管理水平差距挺大。源端提供的元数据信息缺失严重，质量也不稳定。数据目录的完整率只有10%，字段级元数据准确率不到70%。业务人员看不懂的情况很普遍，运维人员咨询量暴增，数据目录的价值被卡在了半道。

其次，要维护好企业级数据目录的元数据，需要跨领域的专业知识——数据运营团队目前还不具备这个条件。虽然有治理组织、机制和流程的支持，和各领域也建立了合作，但沟通成本依然很高。尤其当很多知识掌握在第三方合作伙伴手里时，问题就更加突出。

我们也想过不少办法来完善目录。组织专家补充信息、尝试众包吸收公众智慧——但都严重依赖专家的时间和投入，成本太高。粗略估算，要把数万条目录信息补全，大概需要数万人天的工作量，还得持续投入。这事儿不太现实，而且人工维护的质量也难以保证。

从经验来看，维护元数据大致有三种模式。

数据资源开发完再补元数据。不干扰正常生产流程，但代价很大——工作完成后回过头来补信息，又费劲又难坚持。

开发过程中就录元数据。能保证一开始就有，但会拖慢业务流程。开发人员忙着上线产品，还得分心处理元数据，这几乎没成功案例，质量也难保证。

靠代码解析等技术自动生成。听起来理想，但要求极高，很难做到准确和全面，大多数尝试都以失败告终。

维护元数据，本质上是对业务价值间接的工作，必须算性价比。大模型出现后，大家立刻想到一个低成本方案：基于大模型能力来完善数据目录的元数据信息。优势体现在三个方面。

业务数据我们熟悉，但网络侧的数据——接入网、传输网、核心网——了解得就不够全面。大模型擅长处理全球通用的知识，正好可以用来填补这块空白。这是“智典”能成的关键。

就算对业务数据再熟悉，团队成员如果没法用简单明了的语言描述数据，元数据也会变得模糊。大模型能用简单、精确、容易理解的方式表达专业知识。只要给足上下文，就能生成清晰的摘要。

前期在数据目录运营上花了大量精力。每次扫描到新数据资源，不仅要补录元数据，还需要业务和管理人员审核，确认流程很长。人工大量介入，数据一键入湖的目标迟迟实现不了。

目标很明确：让数据自动入湖，不需要人工干预，同时保证数据目录的质量。如果能开发一个基于大模型的元数据生成API，集成到流程里，就能实现这个目标。

那就来看看我们是怎么做的。

基础大模型的能力，直接决定了“智典”的成败。我们要求私有化部署，自己又不可能研发基础大模型，只能选开源方案。每种开源模型能力不同，必须基于特定场景自己测试。比如LLAMA2-13B，推理能力还行，但中文能力太差。

我们专门制定了一个针对数据目录元数据生成的基础大模型测试方法，从中文本理解、领域知识理解、逻辑推理等五个维度出发，对模型输出由专家打分，最终选定了表现最出色的通义千问模型作为基底大模型。下面是测试结果的示意：

企业数据目录涉及大量领域知识，对格式等输出也有特定要求。所以需要在通义千问基础上做微调，这就需要建立训练指令集。我们梳理了存量的数据目录元数据信息、设计了提示词模板，构建了一个拥有6000余条规范化问答结构的数据集：

基于通义千问大模型，使用LORA算法对指令数据集进行微调训练，构建出了自动生成数据目录元数据信息的领域大模型。核心思路是冻结基底大模型的权重参数，追加并训练额外神经网络，以注入领域知识和训练模型服从人工指令。

为验证“智典”生成的字典信息准确性，我们随机选择了各领域430张表，邀请业务专家人工审核。准确率高达97%。在这个场景，大模型生成的内容质量完全达标。

以网络侧某无线资源表为例，该表的中文名称、字段中文名称以及业务含义等数据字典信息，均由“智典”自动生成。相比原始的字典信息，生成的内容语义更准确、表达更流畅，也更容易被使用人员理解，如下所示：

最后是部署。我们采用CVL模式快速构建了数据目录元数据信息的自动生成服务。通过数据处理、信息检索以及调用大模型推理等流程，能够智能、准确地生成元数据信息，将补全耗时从天级缩短至秒级，准确率达到95%以上。下图示例了整个推理过程：

我们将推理能力封装成了一个API，替换了原本闭环管理流程中的人工录入环节。同时保留了人工快速审核的环节——大模型生成也会产生一定错误，比如无法基于拼音准确推理，审核人员需要保留这些错误信息，作为下次调优的依据。

大模型加持之后，企业数据目录的可用性大幅提升，体现在三个方面。

第一，元数据信息质量上了一个台阶。专业人员的评估是：大模型生成的元数据质量，不低于手工维护的水平。

第二，降本增效了。裁撤了ETL团队，大家能把精力更多地投入到业务赋能中去。

第三，响应能力提升了。数据资源纳管的周期已经缩短至小时级。

“智典”是我们在数据领域做成的第一个比较成功的大模型应用，但它仍然面临不少挑战。

第一，“智典”的生成只是第一步，“智典”的运营才是关键。需要把“智典”推送到需要它地方——需求分析、数据开发及数据开放的场景，不能自嗨。

第二，做推理的时候，输入的上下文信息并不完备。基本上是根据原始表名、字段名来推理，这限制了生成能力。更多上下文信息藏在数据中，要生成这些信息，挑战巨大。

第三，“智典”只是对实体信息进行了业务描述，缺乏相互关系和血缘描述，使用场景还很受限。可以说，这还是一个缺乏深度和内涵的数据目录。后续会考虑基于大模型解析代码来生成更多元数据。

第四，目录分类以系统为基础，大家通过“智典”看到的是流程割裂的业务数据，对业务人员并不友好。要改善这一点，就涉及到业务对象管理等更具挑战性的工作。

李彦宏说，大模型值得企业把所有的应用都重构一遍。这个方向我深信不疑。但也知道，现在企业要做成一个成功的大模型应用不容易——对场景和技术的要求极度苛刻。特别是当前国内基础大模型的能力还不够，只能在一些对准确性要求不高的场景尝试。十分之一的成功率，估计也悬。

但还是得努力去尝试，也期待国内基础大模型的进步。