AI专栏 | 告别“黑盒评审”：我们让LLM为数据仓库模型打了分，效率提升70%+

作者简介

jinxin，携程资深数据仓库工程师，专注于AI技术在BI的应用；

Joomi Huang，携程资深数据仓库工程师，专注于AI在数仓领域的应用、数仓建模与治理等领域。

导读：长期以来，大型数据仓库的模型评审工作面临诸多挑战：业务场景复杂多变、建模规范难以统一、评审效率低下。传统模式下，非业务负责人或流程审批人往往需要投入大量时间理解背景上下文，才能对数仓模型进行专业评估。数仓建模本质上是面向业务的抽象过程，即便采用业界通用的维度建模方法论，不同工程师在实践中的理解与实现也存在显著差异，这使得建模质量的标准化评估成为行业难题。

本文提出一套可量化、可复用、可标准化的数据仓库模型评价体系。该方案首先利用大语言模型（LLM）深度挖掘数仓模型的结构化特征，随后将其与元数据体系整合，构建面向数据仓库的MCP（Model Context Protocol）知识服务。在此基础上，我们系统梳理了数据仓库建模最佳实践，设计了一套涵盖合理度、规范度、重复度、准确度四个核心维度的量化评估框架。

从技术专家视角，该方案能够在模型建设初期快速识别潜在问题，为企业数据资产健康奠定基石；从管理决策视角，该方案为数仓工程师的建模工作提供客观、可量化的评价依据，支撑团队绩效评估与能力建设。

一、背景

1.1 大语言模型在数据分析领域的应用瓶颈

1.2 AI与数据仓库融合的技术路径
二、模型的特征构建
2.1 血缘依赖
2.2 关联关系
2.3 主表
2.4 业务过程/粒度
2.5 其他特征构建
三、模型评价实践方案
3.1 落地架构
3.2 模型评价方案
3.3 模型规范数学模型
3.4 评审流程
四、总结与展望
4.1 核心贡献
4.2 方法论迁移性
4.3 未来展望

一、背景

1.1 大语言模型在数据分析领域的应用瓶颈

随着大语言模型技术的快速演进，其在前端开发和后端开发领域已展现出显著的生产力提升潜力。在前端开发中，根据产品PRD文档可在极短时间内完成界面开发；在后端开发中，凭借LLM强大的上下文理解能力，开发者通过调整Prompt即可快速实现功能模块。

然而，在BI（商业智能）领域，大模型的落地面临独特挑战：

知识碎片化：BI体系的上下文知识高度分散，单纯依靠代码与元数据难以构建完整的语义上下文

精度要求苛刻：BI场景对数据准确性的零容忍特性，与大模型"概率生成"的技术特点存在天然矛盾

领域知识壁垒：数仓建模涉及大量隐性业务规则，难以通过简单的Prompt工程传递给模型

1.2 AI与数据仓库融合的技术路径

AI与大数据的融合主要沿两条技术路径演进：AI for Data 与 Data for AI。前者聚焦于将AI技术应用于数据治理、智能运维等场景；后者则致力于构建支撑AI训练与推理的数据基础设施。

在数据仓库领域，AI技术的应用前景尤为广阔，主要体现在：

本文聚焦于第三个方向——通过大模型的智能化能力，将抽象的数仓模型特征进行量化提取，实现模型质量的系统化评价与治理。这不仅能为数仓工程师提供精细化的建模指导，更能推动团队建模思想的统一，从底层夯实数据架构规范，为后续AI应用奠定坚实基础。

二、模型的特征构建

2.1 血缘依赖

血缘依赖是数据仓库的"神经脉络"，描述了数据在模型间的流转路径。清晰可靠的血缘关系图谱，对于大模型理解数仓架构具有决定性意义。

核心挑战：生产环境中的SQL脚本往往包含大量临时表逻辑，导致正式表血缘与中间过程表血缘混杂，干扰模型理解。

解决方案：我们设计了一套基于SQL的血缘清洗算法，其核心思想是将任务输入的正式表向输出正式表进行广播链接，从而"跳过"中间临时表，还原正式表之间的直接依赖关系。

特殊场景处理：

图1 几种血缘关系的特殊处理

（从左到右：临时表处理、高热节点处理、循环依赖处理、临时表跨任务当正式表特判）

2.2 关联关系

表关联是数据仓库的"交叉节点"，承载了业务逻辑的核心复杂性。在大模型时代，关联关系不仅是AI理解SQL代码的关键线索，更是判定逻辑重复性的核心特征。

传统方法的局限：

大型数仓脚本动辄500+行，复杂度极高

执行计划仅能提取物理层面的表关联，无法处理CTE、视图、嵌套子查询等高级语法

临时表与正式表混杂，难以还原真实的业务关联关系

LLM驱动的解决方案：

我们设计了一套基于思维链（Chain of Thought）的关联关系抽取任务流：

Step 1: SQL脚本解析 → 提取原始关联关系 + 临时表血缘映射

Step 2: 非正式表识别 → 判断关联中是否存在临时表

Step 3: 血缘溯源 → 将临时表映射至源正式表

Step 4: 输出标准化 → 生成正式表间的关联关系清单

图2 大模型解析任务中表关联关系的思维链设计

其他优化措施：在投喂SQL至大模型前，我们对脚本进行预处理——隐匿无用的注释信息、精简字段列表，这显著降低了Token消耗并提升了解析效率。经过调优，关联关系抽取的召回率稳定在80%以上。

2.3 主表

主表指的是SQL脚本中的核心表，通常是关联关系链条的起始表。在明细层中，主表往往决定了目标表的业务过程与粒度，是数据仓库架构的关键事实节点。

我们通过大模型识别脚本中的主表，定位数据仓库数据脉络中的关键节点。主表血缘也是AI探索数仓架构的最优路径。

2.4 业务过程/粒度

业务过程：指产品运行过程中的关键动作，如用户下单、支付、浏览、注册等。这些动作以数据形式被系统记录，数仓工程师需要理清数据与业务过程的映射关系，这正是大模型理解SQL脚本的重要上下文。

粒度：表示一行数据所代表的业务主键（可为空），是AI辅助判定重复建设的关键依据。一般而言，若新建表的粒度与业务过程与已有表相同，则存在重复建设的可能性。

建模规范要求：在表中明确标识主键，并在表注释中清晰描述业务过程。

2.5 其他特征构建

其他模型特征包括：表名、任务ID、表类型、层级、数据域、业务域、业务过程、粒度、对应主表、字段明细、需求链接、飞书云链接、业务说明、关联关系、血缘明细、DQC明细等，均可通过公共元数据直接获取。

三、模型评价实践方案

3.1 落地架构

携程大市场BI团队借助MCP+Cursor架构，配合公司内部的FaaS+DevShare平台，实现背景知识与MDC规则文件共享，开发了AI自助数仓评审应用与一系列AI工作流。

我们将上文构建的模型特征整合为数据知识库（dw-map）部署在FaaS平台，并在Cursor中配置MCP服务。MCP服务不仅包含数仓元数据知识，还开放了飞书云文档、需求、DaaS数据接口，用户可便捷获取文档与数据。此外，我们统一了可视化MCP，提供丰富的图表类型模板，确保全组报告风格一致。

图3 大模型解析任务中表关联关系的思维链设计

轻量但完备的知识库与低成本的AI流程开发，为团队带来了更多AI工具开发的可能性，如自动梳理、分析报告等个人定制化AI小流程。此套AI架构在梳理、整备、绘图等场景展现出惊人效率。

3.2 模型评价方案

我们从工程实践中提炼出数仓模型质量的四个核心评估维度，构建了一套系统化的量化评价体系：

图4 模型评审设计角度

3.2.1 合理度检查项

合理度主要评估模型设计的逻辑合理性和业务合理性。

(1) 过滤条件合理性

检查内容：分析SQL脚本中的过滤逻辑是否合理

检查要点：

- 分区字段是否优先使用

- 是否存在全表扫描

- 过滤条件是否与业务逻辑匹配
- 过滤条件是否与同类任务一致

(2) 表关联方式合理性

检查内容：评估表之间的关联关系选择是否合理

检查要点：

- 关联类型选择是否合适（INNER JOIN、LEFT JOIN等）

- 关联条件是否正确

- 是否存在不必要的关联

- 关联性能是否优化

(3) 需求描述合理性

检查内容：结合需求链接中的描述判断合理性

检查要点：

- 脚本实现是否与需求描述一致

- 脚本更改范围是否合理

3.2.2 规范度检查项

规范度评估模型是否符合数据仓库建模规范和编码规范。

（1）表规范检查项

检查内容：分析新建表各项是否符合规范

检查要点：

- 表名是否符合命名规范

- 字段命名是否符合规范

- 分区字段设计是否合理

- 是否定义主键，主键设计是否合理

- 表注释是否包含业务过程描述、粒度描述

（2）代码规范检查项

检查内容：分析代码书写是否符合规范

检查要点：

- 是否包含需求链接、飞书文档链接

- 字段注释与关键逻辑注释是否完整

- SQL代码格式是否符合规范

（3）架构规范检查项

血缘架构是数据仓库整体构建基石，是数据健康清晰流转的保障。优秀的数据仓库血缘架构设计能节约算力与存储成本，帮助开发者减少梳理交接难度。

图5 架构规范检查项示意图

（从左到右事实表跨任务重复引入，事实表重复引入，维度表重复引入，ODS重复引入）

检查内容：开发架构设计是否规范

检查要点：

- 是否合理使用ODS/MID层表，不存在跨层调用问题，不存在复用问题

- 是否可以将维表上推到上游表

- 同一事实表是否被多次重复流入

3.2.3 重复度检查项

重复建设探查是数据仓库的重复建设评价核心量化手段，是控制数据仓库规模，节约算力成本的深度手段，是保障数据仓库健康成长的重要指标。

我们根据AI配合MCP检查，将这些明细项列入评审文档，方便用户更好地审查自己的模型。

图6 重复建设检查项示意图（从左到右关联重复，输入表重复，粒度重复，逻辑重复）

检查内容：重复度评估是否存在重复的数据处理逻辑和冗余设计。

检查要点：

- 关联关系重复：表之间的关联关系是否与其他任务重复，这会导致算力浪费，逻辑复杂。

- 输入表重复：输入的表的使用是否重复，只看存在两张输入表完全重叠、包含、被包含情况

- 主键与业务过程重复：主键列列表是否与同类表重复

- 逻辑重复：数据处理逻辑是否与上游表或其他任务重复

3.2.4 准确度检查项

检查内容：准确度评估数据质量和数据准确性，当前数据准确度检查只设置了DQC检查，后续会直接摄取数据进行检查，丰富数据质量的检查能力。

检查要点：

- 是否有DQC规则配置，DQC配置一般包括主键是否唯一、数据整体波动量、结合业务场景的重点字段监控等

3.3 模型规范数学模型

数据仓库单模型规范度评分（Standardization Score, SS）定义如下：

符号说明：

评分项汇总表：

3.4 评审流程

结合Cursor IDE和MCP服务协议，构建数据仓库知识库 + AI规则引擎 + MCP服务架构，实现了从传统人工评审到智能化评审的范式转变。

通过有着丰富数仓经验的工程师精心设计的Prompt模板，引导LLM进行专业的数仓代码评审。开发者输入SQL脚本/任务ID后，通过Cursor+MCP服务进行智能解析，提交DataOps建表系统，生成AI评审报告。AI评审结果与DataOps建表信息汇聚至人工快速审核环节，审核结果通过则进入DataOps审批流程，未通过则反馈至建表人修改，最终实现新表的标准化发布。

该流程基于MCP服务架构和AI规则引擎，采用人机协同模式，将建表评审效率提升70%+，显著改善数仓代码质量和架构规范性。

图7 市场BI新建表流程

四、总结与展望

4.1 核心贡献

本文提出了一套基于大语言模型的数据仓库模型量化评价体系，核心贡献包括：

特征工程体系：系统化构建了包含血缘依赖、关联关系、主表、业务过程/粒度等维度的模型特征提取方法

四维评估框架：设计了涵盖合理度、规范度、重复度、准确度的量化评估体系，并给出了数学模型定义

工程化落地方案：基于MCP服务架构，实现了知识库构建、Prompt工程与AI工作流的端到端集成

4.2 方法论迁移性

值得强调的是，本方案的核心价值在于方法论设计而非工具绑定。知识库构建、MCP服务设计和Prompt工程实践等核心要素具有良好的迁移性，可无缝适配Cursor、Copilot等主流AI编程工具。

4.3 未来展望

展望未来，AI与数据仓库的融合将持续深化。尽管离线数仓建模理论已发展数十年，我们坚信在AI技术的加持下，数据仓库将以更加科学、健康的姿态，持续承担企业级数据资产管理的核心角色。