用大模型生成并验证数据质量规则

Indegene 把大语言模型接进了企业数据质量流程：先读数据画像和业务规范，再推荐校验规则、生成代码，最后经过验证与审批进入统一规则库。据作者披露，生产部署中，每个数据集定义和实现规则的投入从约 30 小时降至约 4 小时。

这套方案值得看的地方，是它把模型放在了一个有上下文、有审批、有执行出口的位置。对程序员来说，更有参考价值的问题是：哪些工作适合交给 AI 起草，哪些判断仍然得由业务人员负责。

为什么字段校验过了，数据还是不能用

传统数据质量检查擅长回答结构问题：字段是否为空、类型是否正确、标识符是否重复、外键能否找到对应记录。这些检查必不可少，但覆盖不了业务含义。

例如，HCP ID（Healthcare Professional ID，医疗专业人员标识符）格式正确，不代表这位医生符合某款产品的业务准入条件；市场份额字段都是合法数字，也不代表同一辖区内各产品的份额加起来等于 100%。

难点还在于规则分散。技术规则通常放在 SQL 和流水线代码里，业务规则却可能藏在术语表、标准操作规程（SOP）和专家经验中。字段结构、业务定义、阈值发生变化时，两边很难同步更新。

Indegene 的做法是把 Data Quality Agent 放进 NEXT Unified Data Platform（NEXT UDP），让数据接入、转换、质量管理、元数据、血缘和分析共享一套治理环境。平台还提供 Data Ingestion、Orchestration、Data Catalog 和 SQL Bot Generator 等独立 Agent，可以单独使用，也支持进一步定制 Agent 间通信。

这里的核心判断是：模型生成规则之前，必须先知道企业认为什么才算正确。

如果只有表结构，模型最多猜出一些通用检查。要判断医生专业与产品资格是否匹配，就得拿到企业已经认可的业务定义。

两套知识库怎样让规则贴近业务

Data Quality Agent 使用两套互补的知识库。

内部企业知识库收集业务术语表、数据字典、SOP、监管指引、已批准规则、验证过的脚本、数据画像结果、历史异常和领域专家（SME）反馈。内容经过向量化后，通过检索增强生成（RAG）提供给模型。可以把它理解为：先查企业资料，再根据查到的依据起草规则。

外部参考知识库则定期吸收经过批准的数据质量框架，并通过网络搜索和受控网页抓取补充参考标准。比如遇到 NPI（National Provider Identifier，美国医疗服务提供者标识符）列，可以建议检查其是否符合 10 位数字格式，并进行参考数据验证。

但知识库只是输入的一部分。生成建议时，Agent 还结合表与列的元数据、数据画像、异常结果和现有规则。原文称上下文来自六类来源，但提供的正文没有展开对应清单，无法核对完整划分。

数据画像由 AWS Lambda 上的 Python 流程计算，指标包括空值率、不同值数量、类型符合度、模式和值域；同一 Lambda 还会与历史基线做统计比较，发现空值率突增、基数变化等异常。这里的异常检测有明确的统计处理环节，并非全部交给模型判断。

原文用 HCP Product Performance 表说明规则如何落地。字段包括 HCP_ID、Specialty、Territory_ID、Product_ID、Prescription_Volume、Market_Share_Pct、Switch_Pct、Rating_Scale 和 Reporting_Month。

对应检查分为几类：

• 技术检查要求处方量为非负数，市场份额和转换比例在 0 到 100 之间，月份符合日期格式，辖区和产品能匹配参考表。
• 业务检查要求每个辖区、每个报告月份的产品市场份额合计为 100%，医生产品资格符合其专业，目标分群只包含符合资格的医生。
• 异常检查关注负转换比例、处方量突然升降、产品排名与份额不一致，以及评分超出量表范围。

这些例子体现了上下文的价值，也暴露出对业务定义的依赖。比如市场份额必须合计 100%，需要先确认数据是否覆盖完整市场。

生成代码以后，谁决定规则能不能上线

整个工作流从选择 Amazon Redshift 或 Snowflake 等数据源开始，随后浏览数据库和 schema、查看数据画像与异常，再管理现有规则或创建新规则。

创建界面提供 Column Level、Table Level 和 Custom Query 三种模式。用户审阅、修改或批准建议后，模型生成 SQL、Python 和 PySpark 代码。入库前还要检查语法、核对目标 schema，并在语言支持时用样本数据试运行。通过的规则进入中央规则库，交给现有 ETL 和编排工具执行。

它的部署分工也比较清晰：Amazon Bedrock 提供基础模型，Strands Agents 用于构建和更新 Agent，并提供评估工具，Amazon Bedrock AgentCore 承载运行。原文还使用另一个 LLM 作为 Validation Agent，复核生成的规则和脚本。

不过，第二个模型同意第一个模型的判断，仍不足以证明规则正确。语法检查、schema 检查、样本执行和业务审批各自解决不同问题，不能互相替代。

审批并非一律人工处理。每条规则都有置信度分数，只有高置信度、低风险规则可以自动批准，关键规则和业务规则始终交给 SME 审核，所有决定都会记录下来。原文没有披露置信度如何计算，也没有给出自动批准阈值。

原文还介绍了 Amazon Bedrock 的隐私与合规支持，以及 Amazon Bedrock Guardrails 对个人身份信息、提示词注入和检索依据一致性的防护。这些是平台提供的控制能力，具体业务规则是否成立，仍要回到企业定义与验证结果。

我的判断

我认同这套方案对职责的划分：统计程序发现数据特征，模型起草规则和实现，专家处理业务判断，规则库负责留痕。它把模型输出变成了可以审查、执行和追溯的工程产物。

但收益要结合前提看。Indegene 服务于生命科学行业，已经积累了领域资料、规则和专家反馈。一般团队如果连字段含义、表粒度和业务口径都没统一，先接 RAG 也未必能得到可靠规则。

原文自己的例子就有需要复核的地方：它要求 HCP_ID 不重复，但表中同时包含产品和报告月份。同一医生能否跨产品、跨月份出现，取决于表的粒度。原文没有解释，不能直接把这条建议当作通用约束。

效果数据也应按作者披露理解。每个数据集从约 30 小时降到约 4 小时，作者概括为投入减少约 85%、生产率约提高 7 倍；新表接入从 2–5 个工作日缩短到 2–4 小时。这些来自其生产部署估算，但正文没有提供样本量、数据复杂度、规则准确率或完整对照方法，提到的四张效果表也没有具体内容。

这些数字支持继续评估方案，尚不足以承诺同等收益。

与 AWS Glue Data Quality 这类根据数据统计推荐基础规则的能力相比，本文方案强调业务上下文和审批流程。但作者没有给出同条件对照数据，无法据此判断它在准确率或总成本上更好。AI 辅助修复建议和异常根因分析，则被列为后续增强方向，不能算作已交付成果。

能拿来做什么

• 为 Node 数据导入或企业报表后台增加 AI 规则推荐前，先整理字段字典、表粒度和已批准规则，再让模型结合画像起草建议，避免只凭列名猜业务。
• 如果要做规则审核界面，可以参考三种创建模式，同时展示规则依据、严重程度、代码和验证结果，让业务人员有足够信息决定是否批准。
• 在日常 AI 编程中生成 SQL 或 Python 校验脚本时，把语法检查、目标 schema 核对、样本试运行和业务验收分开执行，保留每一步结果。
• 评估接入收益时，同时记录人工耗时、建议采纳率、错误规则和后续维护投入，再判断是否适合扩大自动审批范围。