摘要：数据界的同仁，现在估计都在想着搞一个数据质量智能体，把数据扔进去，然后让智能体吐出被清洗干净的数据。这是每个数据从业者的梦想。

数据界的同仁，现在估计都在想着搞一个数据质量智能体，把数据扔进去，然后让智能体吐出被清洗干净的数据。这是每个数据从业者的梦想。

但我现在得给你破盆冷水：根本不可能。

因为，在数据质量领域，大模型应用受到了“四个诅咒”。

诅咒一：成本与性能的“物理定律”

这是最硬的约束，直接决定了大模型不可能深入到数据处理的“行级别”。

1、天文数字的计算成本

一次传统的SQL WHERE或CASE WHEN操作，在一行数据上花费的计算成本可能不到0.000001美分。而一次GPT-4级别的API调用，处理几千个token（约等于几百行简单数据）的成本就在1美分以上。

假设要用大模型去“校验”一个10亿行的大表，哪怕只是做简单的枚举值归一化，其API调用成本可能会飙升到数百万甚至上千万美元。而用传统的Spark或SQL，成本可能就是几百美元的计算资源。这个成本差异是指数级的，在商业上完全不可行。

2、无法逾越的延迟与吞吐量

现代数据仓库处理数据的速度是毫秒级的，一个ETL任务要求在小时甚至分钟级内处理完TB级的数据。而大模型一次API调用的返回速度是秒级的。

一个处理1亿行数据的ETL任务，如果每一行都需要调用一次API，即使是并行处理，整个任务的耗时也将是天文数字，完全无法满足任何生产环境的时效性要求（SLA）。

3、有限的上下文窗口

即使是目前最长的上下文窗口（如200K token），也只能容纳几万行简单数据。你不可能把一个百万行、百列表的大表一次性“喂”给大模型去寻找异常。

这意味着大模型无法获得数据的“全局视野”。它无法进行需要全表扫描的复杂分析，比如计算全局分布、识别离群值、进行复杂的跨行校验等。

仅凭以上三点，就可以得出结论——任何试图让大模型直接参与“海量行级别数据”处理或验证的想法，在当前技术和商业环境下都是不切实际的。

诅咒二：确定性要求与模型幻觉的冲突

数据质量的核心是“确定性”，而大模型的特点恰恰是“非确定性”。

1、数据工作流需要100%的确定性

数据管道必须是可复现和稳定的。同样的输入必须产生完全相同的输出。然而，大模型的输出（即使设置了Temperature=0）仍然具有一定的随机性，难以保证结果的绝对一致性。

2、幻觉的致命风险

大模型可能会“自信地”给出错误的判断。在清洗数据时，模型可能会过度解读或错误关联，将正确的数据“清洗”成错误的数据（例如，错误地标准化一个罕见但正确的公司名称，或者在提取信息时张冠李戴）。这种“帮倒忙”的行为对数据质量是致命的。

3、“黑盒”的不可解释性与合规挑战

当传统的代码或规则出错时，我们可以调试并修复它。但当大模型给出一个错误的判断时，我们很难理解其深层原因。在金融、医疗等强监管行业，这种不可解释性是不可接受的，因为它无法满足审计和追溯的要求。

诅咒三：信任与安全的工程鸿沟

将一个“聪明的建议者”转变为能自主干预生产数据的“可靠执行者”，中间隔着一道巨大的工程鸿沟。这不仅是简单的API集成，而是构建一个能驾驭高风险、复杂生态且必须100%可问责的信任与安全框架。

1、从“聊天框”到“手术台”的责任鸿沟

在ChatGPT界面获得修复建议很简单。但将其嵌入生产流程，意味着它将从一个“助理”变成一个能执行UPDATE/DELETE的“医生”。一次错误执行，就可能污染核心数据，且后果难以逆转。

工程挑战的核心不再是API重试或成本监控，而是必须构建一个滴水不漏的“行动审批”与“审计”系统。任何修改操作都必须先生成“行动计划书”，经人类审批后才能执行，这种高强度的信任与问责机制，是绝大多数团队难以逾越的工程门槛。

2、从“局部知识”到“全局感知”的上下文鸿沟

编写一个针对孤立问题的Prompt很简单。但数据质量问题往往根植于复杂的生态系统中，一个可靠的智能体必须瞬间理解血缘、依赖、业务影响等全局信息。

工程挑战不再是如何写好Prompt，而是必须构建一个强大的“上下文引擎”。这个引擎需要通过RAG等技术，实时地将海量、动态的元数据注入到智能体的思考链中。构建并维护这样一个高时效、高准确度的引擎，本身就是一个巨大的工程。

3、从“尽力而为”到“绝对安全”的控制鸿沟

智能体具有非确定性，可能会“好心办坏事”。

工程上必须构建一个多层级的“安全驾驶”框架。这包括强制的“沙箱试运行”、严格的“最小权限原则”以及防止灾难性操作的“自动熔断机制”。为戴着镣铐的智能体构建一个绝对安全的舞池，其复杂性远超智能体本身。

诅咒四：应用场景的“定位不清”

很多被吹捧的场景，用传统工具不仅能做，而且做得更好、更便宜、更可靠。例如，检查一个字段是否为空（IS NOT NULL），校验一个字段是否唯一（UNIQUE），这些用SQL或dbt测试是成本最低、100%准确的。

很多人被大模型的通用能力所迷惑，试图让它去解决一个已经被高效解决的问题，这是典型的“技术锤子找钉子”。

以上的诅咒，使得大模型在“数据平面”上硬碰硬地处理海量数据的设想变成了泡影，其在成本、性能、安全和可靠性上都行不通。

要真正让大模型在数据质量领域落地，必须将应用重点转移到“控制平面”——即利用大模型的“智能”来设计、优化和管理数据处理的流程和规则，而不是让它去执行数据处理本身。

那么，具体怎么做呢？

下面，给出基于大模型提升数据质量“控制平面”的七个典型场景。

场景一：代码“考古”与文档自动化

大模型是地球上最强的代码阅读器和总结器，只需要将代码文本（SQL、Python、Shell等）作为输入，就能获得高质量的文本输出。这是最容易落地、ROI最高的场景，没有之一。因为几乎所有数据团队都面临“祖传代码”、文档缺失以及系统迁移的困境。

下面是三种典型做法：

随便找一段没有任何注释的复杂SQL脚本，直接扔给大模型。

Prompt示例：“你是一名资深数据仓库架构师，请用中文逐段解释以下SQL脚本的业务逻辑。特别是，说明每个CTE（WITH子句）的作用。最后，请尝试将其从Hive SQL改写为Snowflake SQL兼容的语法。”

将建表语句（DDL）或整个数据模型的代码喂给大模型。

Prompt示例：“请为以下数据模型的SQL代码生成一份Markdown格式的数据字典。表格需要包含字段名、数据类型、以及根据代码逻辑推断出的业务含义和备注。对于枚举值（如订单状态），请尽可能列出所有可能的取值。”

对于单个脚本，大模型可以精准识别输入和输出。

Prompt示例：“分析以下ETL脚本，以JSON格式返回该脚本的上游依赖表和下游产出表。”

价值主要体现在：

场景二：代码审查与优化的“智能副驾”

在代码合并前，让大模型进行一次预审查，能过滤掉大量低级错误、不规范写法和潜在性能问题。这项任务完美契合了IDE插件（如GitHub Copilot）和API调用的模式。大模型对通用的代码规范、性能“坏味道”以及特定数据库（如 Hive）的最佳实践有非常深刻的理解。

下面是二种典型做法：

在GitLab/Jenkins的CI流程中，增加一个步骤，通过API调用大模型对提交的代码进行审查。

Prompt示例：“你是一名数据开发专家，请对以下提交的SQL代码进行Review。重点关注：1. 是否遵循了团队的命名规范；2. 是否存在潜在的性能问题（如笛卡尔积、未使用分区键、SELECT *）；3. 代码可读性如何。如果发现问题，请直接提供修改建议。”

Prompt示例：“请优化以下在Hive上运行缓慢的SQL查询。重点考虑数据倾斜和JOIN顺序的问题。[附上SQL代码]”

价值主要体现在：

场景三：测试用例的“创意大师”

数据开发人员往往不擅长或没时间编写全面的测试用例，特别是那些刁钻的边缘场景（Edge Cases）。而大模型擅长“举一反三”，能基于一段逻辑代码，联想出各种可能的边界条件、异常数据和业务场景组合。

下面是二种典型做法：

将一段计算逻辑（如Python函数、SQL UDF）交给大模型。

Prompt示例：“你是一名专业的软件测试工程师，请为以下计算用户折扣等级的Python函数编写一组全面的单元测试用例（使用pytest框架）。需要覆盖：正常值、刚好达到临界值、超出最高等级、输入为0或负数、输入类型错误等场景。”

将数据模型的SQL代码和业务描述交给大模型。

Prompt示例：“这是我dbt项目中的一个模型dwd_orders。请为它生成一些推荐的数据质量测试，写在models/schema.yml文件中。例如，order_id应该是唯一且非空的，payment_amount必须大于0。”

价值主要体现在：

场景四：文本数据清洗与标准化“规则引擎”

大模型在理解非结构化文本、识别模式和实体对齐方面具有天然优势。它能从少量示例中学习并生成可执行的清洗逻辑（如Regex、Python代码、复杂SQL CASE WHEN），这些逻辑可以直接嵌入到现有的ETL流程中。

下面是三种典型做法：

提供少量脏数据样本和期望的清洗后结果，让大模型反向生成处理逻辑。

Prompt示例：“我有一列包含公司名称的数据，例如：['苹果公司', 'Apple Inc.', '苹果(中国)有限公司']。我希望将它们标准化为'Apple'。请生成一段Python Pandas代码或SQL UDF来实现这个逻辑，并处理可能的大小写、标点符号和后缀差异。”

编写用于提取关键信息的正则表达式极其繁琐且易错，大模型可以帮大忙。

Prompt示例：“我需要从以下用户设备信息字符串中提取手机品牌和操作系统版本。请帮我写一个Python的正则表达式。示例数据：'Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X)...'”

Prompt示例：“我有一列关于省份的数据，非常杂乱，例如：'京'、'BJ'、'北京市'。请生成一个SQL的CASE WHEN语句，将这些变体全部标准化为'北京'。请尽可能覆盖你能想到的所有常见变体。”

价值主要体现在：

场景五：元数据富集与智能打标

仅有技术元数据（如字段类型）是不够的，数据治理需要更丰富的业务上下文和合规性信息（如PII识别）。手动打标工作量巨大且容易遗漏。大模型可以通过分析字段名称、数据类型、注释、代码甚至历史查询日志，来推断其业务含义和敏感等级，其语义理解能力远超传统的正则表达式匹配。

下面是三种典型做法：

将数据模型的Schema（DDL）提供给大模型。

Prompt示例：“请审阅以下数据表的Schema。根据字段名称、类型和注释，识别出所有可能包含PII的字段。请按照['字段名', 'PII类型（如电话、邮箱、地址）', '敏感等级（高/中/低）', '判断依据']的格式列出。”

将技术字段名与预定义的业务术语表（Business Glossary）进行映射。

Prompt示例：“这里有一份我司的业务术语表：{...}。请分析以下数据表结构{...}，为每个表和关键字段推荐最合适的业务术语进行关联，并给出置信度评分。”

利用检索增强生成（RAG）关联知识库，为数据资产找到最相关的业务定义。

Prompt示例：“表名是fact_sales_daily，字段名是cust_ltv_30d。请推测这个字段的中文业务定义。另外，请在已有的指标知识库中搜索最相关的业务定义，并返回Top 3个最可能的关联文档链接和摘要。”

价值主要体现在：

场景六：需求澄清的“翻译官”

在开发前，利用大模型审阅需求文档（PRD），它能扮演一个“吹毛求疵”的虚拟业务分析师，对逻辑的严谨性极其敏感，能提前发现模糊不清的业务逻辑，实现数据质量的“左移”（Shift-Left）。

下面是典型做法：

将业务方提供的需求文档（哪怕只是一段聊天记录或会议纪要）复制给大模型。

Prompt示例：“你是一名资深数据产品经理。请审阅以下关于‘月活跃用户看板’的需求描述。请识别出其中所有定义模糊（例如，‘活跃’的定义）、存在歧义或缺少关键信息（例如统计周期、是否包含测试用户等）的地方，并以提问的方式，列出一个问题清单，方便我向业务方进行二次确认。”

价值主要体现在：

场景七：监控告警的“智能解读员”

当传统监控工具发出告警时（如空值率突增、行数骤降），大模型可以对告警信息进行丰富和解读，缩短故障排查时间（MTTR）。

下面是典型做法：

当收到告警后，将告警信息和预先准备好的元数据模板一起发给大模型。

Prompt示例：“你是一个数据运维专家。收到告警：‘表dwd_user_activity在2024-09-08分区的user_id字段空值率为15%’。已知该表的元数据如下：{业务含义: '用户日活明细', 责任人: '张三', 上游核心依赖: 'ods_app_log_v2', 下游核心应用: ['核心用户增长日报'] }。请生成一段告警分析报告，包括：1. 用通俗的语言解释问题；2. 推测最可能的原因（例如上游数据变更）；3. 评估问题的影响严重等级；4. 建议的初步排查步骤和需要立即通知的人员。”

价值主要体现在：

结语

考虑到大模型在数据处理上面临的诅咒，当前阶段，我们不应让大模型去直接操作和判断海量数据，而是要让它成为数据团队每个成员的“外挂大脑”。

聚焦于代码、文档、测试、清洗规则、元数据、需求这些以“文本”和“逻辑”为核心的环节，就能以极低的成本、最小的系统改动，撬动数据质量的提升。

希望于你有所启示。

来源：一个数据人的自留地