Indegene推出医疗数据质量智能体，自动生成并治理规则

摘要：Indegene 在 AWS 上构建了 NEXT Unified Data Platform 的数据质量智能体，利用 Claude Sonnet 4.5、Bedrock AgentCore、Strands Agents 与双知识库 RAG，根据数据剖析、异常检测、历史规则及医疗业务规范生成列级、表级和自定义 SQL/Python 规则。系统以人工审批、代码验证、置信度门控和版本化规则库控制风险。其生产部署据称将单表规则工时由约30小时降至4小时，但数据均来自厂商估算，仍需独立验证。

---

核心发布：把数据质量规则工程改造成智能体工作流

Indegene 在 AWS 上推出了 NEXT Unified Data Platform（NEXT UDP）中的 Data Quality Agent。该智能体并未试图取代 AWS Glue Data Quality 等传统规则引擎，而是负责补齐其中最昂贵、最依赖专家经验的一环：根据表结构、实际数据分布、历史异常、企业业务定义及外部规范，提出可执行的数据质量规则。

传统数据质量流程通常把工作拆成数据剖析、规则设计、SQL/Python 编写、测试、审批和持续维护。Indegene 的做法是将这些步骤串联为一条人机协作流水线：智能体负责搜索上下文、提出规则并生成代码，数据工程师与业务专家保留最终审批权。

架构机制：六类上下文与双知识库

智能体生成规则前会组合六类上下文：

1. Glue Data Catalog 中的表、列及数据类型元数据；
2. 空值率、唯一值数、取值范围和高频值等实际剖析结果；
3. 与历史基线比较得到的异常检测结果；
4. 规则仓库中已经生效的检查；
5. 外部数据质量标准与验证实践；
6. 企业内部术语表、SOP、已批准规则、历史异常和专家反馈。

其中，外部知识库通过经批准的框架、受控网页搜索和抓取周期性更新；内部知识库则汇集企业自身定义。文档进入 Amazon S3，并利用 Bedrock Knowledge Bases 与 Aurora PostgreSQL 的 pgvector 进行向量化和 RAG 检索。AgentCore Gateway 将两个知识库作为工具暴露给智能体。

这种设计的关键不是“更大的上下文窗口”，而是让检索结果成为规则生成的约束依据：例如，针对 NPI 字段，系统会结合十位数字格式、标准参考值和既有企业规则提出约束。其优势是减少企业知识与代码脱节；局限是知识库若存在过期术语、冲突政策或错误审批记录，RAG 只会更高效地检索并放大这些缺陷，因此文档版本、来源优先级和过期策略仍需独立建设。

从剖析到执行：规则生成链路

用户选择 Redshift、Snowflake 等数据源及目标表后，Lambda 执行 Python 剖析流程，计算列统计、值模式和表级特征；DynamoDB 保存结果。异常检测通过比较最新统计与历史基线，识别空值率突增、基数变化或越界值等信号。

随后，智能体按三种模式生成建议：

• Column Level：检查非空、数据类型、长度、范围、格式和唯一性；
• Table Level：检查重复记录、跨列一致性、引用完整性及业务逻辑；
• Custom Query：把自然语言业务条件转换为 SQL，并支持对话式修改。

以 HCP 产品表现表为例，智能体不仅可以生成 HCP_ID 非空且唯一、处方量非负等结构规则，还能提出市场份额按地区和月份合计为100%、HCP专长与产品资格一致等业务规则。这正是传统静态规则较难覆盖的部分。

规则获批后，Claude Sonnet 4.5 生成 SQL、Python 或 PySpark 代码。AgentCore Code Interpreter 执行语法检查、目标 schema 对齐和可行情况下的样本数据试跑；通过后，代码进入 S3，并可由 Lambda、Glue、Athena 或 Redshift 执行。规则元数据则保存在 DynamoDB 中，包括规则 ID、类型、列、状态、作者、严重级别和版本信息，形成集中治理入口。

为什么采用双智能体校验

系统让一个 LLM 生成规则，再由另一个 Validation Agent 审核规则与脚本。这种“生成器—验证器”分离可以降低单次生成中的逻辑错误，但也引入了模型相关性风险：如果两个组件共享相似训练偏差或上下文盲区，验证器未必能发现错误。

因此，生产系统不能把 LLM 评审当作形式校验。关键路径仍应叠加确定性检查，包括 SQL AST 解析、字段存在性检查、只读权限约束、资源成本估计、样本回放以及与人工基准规则的差分测试。涉及写操作、敏感数据或高业务影响的规则，必须执行最小权限和沙箱隔离。

工程权衡：延迟、成本与治理

在degene报告的性能数据包括：约100万行表的剖析耗时45至90秒，1000万行约2至5分钟；单表规则生成20至45秒；每条SQL生成3至8秒；标准规则执行20至30秒。整体流程通过异步编排降低交互等待，但复杂 SQL 仍会把端到端延迟拉长到数分钟。

Lambda 适合事件驱动和小规模剖析，但超大表的全量扫描会受并发、超时和成本约束。更稳妥的做法是按列执行统计型剖析，先读取元数据缩小候选列，再对高价值字段运行精确计算。系统声称采用“metadata-first profiling”可将计算量降低约45%至51%，但仍需按数据分布验证收益。

Bedrock prompt caching 可复用稳定的系统提示、知识库片段和 schema 上下文，据称可降低最高90%的输入 token 成本。其适用前提是缓存前缀稳定；若每张表都注入大量动态样本，缓存命中率会显著下降。总体成本仍包括向量检索、上下文 token、代码生成、验证执行、异常分析和人工复核，不能只按单次模型调用计价。

评测结果应如何解读

据 Indegene 估算，规则建议准确率为80%至90%，60%至75%的建议无需修改即可接受，schema-grounded SQL 首次有效率约90%至97%，自定义SQL约为80%至90%，幻觉率低于5%至8%。新表接入时间据称从2至5个工作日缩短至2至4小时，单数据集规则定义与实施工时由约30小时降至4小时。

这些数字适合证明架构可行，但不足以构成可泛化的基准：数据来自厂商自身生产部署，缺少独立测试集、人工标注规范、不同客户和不同数据模态的拆分结果，也没有给出置信区间。所谓“准确率”同时可能包含规则是否适用、逻辑是否正确和业务相关性，难以仅凭一个指标判断真实质量。尤其20%至35%的规则仍需人工修改，说明“接受率”与“正确率”之间存在明显差距。

更可靠的评测应至少公开：按规则类型拆分的精确率与召回率、跨客户留出测试、严重级别误判率、错误规则逃逸率、人工修改次数、每条规则的端到端成本，以及与静态规则生成器和纯 RAG 基线的对比。

开发者落地建议

1. 先从低风险列级规则开始：优先启用格式、长度、非空和取值范围检查，再逐步开放跨表业务规则。
2. 将知识库治理独立出来：为术语、SOP 和既有规则设置所有者、版本、有效期及冲突优先级。
3. 保留确定性防线：对生成 SQL 做解析、权限检查、成本估算、样本回放和结果回归。
4. 建立反馈闭环：只把专家批准与修改后的结构化反馈写入记忆，避免把未经验证的模型输出重新喂回知识库。
5. 按风险决定自动化边界：高置信度基础规则可自动部署，关键业务指标和敏感数据规则始终要求 SME 审批。
6. 建立可复现基准：用历史事故数据构造测试集，衡量漏检、误报、规则逃逸和人工修改量，而不只统计生成速度。

NEXT UDP 的价值不在于新增一个聊天式 SQL 生成器，而在于把数据质量规则视为可版本化、可审计的企业资产。其成败仍取决于知识库质量、确定性验证、权限边界以及人工审批能否嵌入日常工程流程。

---

消息来源：AWS Machine Learning Blog (2026-11-04)

—— 完 ——

主题标签： #数据质量智能体 关注 #RAG 关注 #AWS Bedrock 关注 #医疗数据治理 关注 #Agentic Workflow 关注