人工智能
Indegene 如何在生命科学领域实现企业数据质量的现代化与规模化本文与 Indegene Limited 的 Shravan K S 共同撰写。
企业级 AI 正在为生命科学组织创造新的机会，帮助其改善商业、医学、市场准入及其他业务职能领域的决策。但每一个 AI 模型、仪表盘和业务洞察的质量都取决于一件事：可信的数据。随着企业数据在多个平台、管道和业务领域不断增长，保持一致的数据质量变得越来越困难。手动创建数据质量规则、治理碎片化以及不断变化的业务定义，使得在企业范围内扩展数据质量变得极具挑战。
本文探讨 Indegene 如何在 AWS 上的 NEXT Unified Data Platform（NEXT UDP）中构建一个生产级、由大语言模型（LLM）驱动的 Data Quality Agent。该 Agent 可生成上下文感知的数据质量规则、对其进行校验，并在集中式、human-in-the-loop 治理下产出可直接运行的 SQL 和 Python 代码。这些能力共同帮助组织在企业规模上提升数据质量，同时减少构建和维护数据质量项目所需的投入。
关于 Indegene
Indegene Limited （BSE: 544172，NSE: INDGN）是生命科学行业的战略运营合作伙伴，在产品全生命周期内统筹商业、医学、研发和安全运营。Indegene 受到全球前 20 大生物制药公司的信赖，帮助其在全球范围内运行复杂且高度受监管的工作流程。Indegene 将深厚的生命科学专业知识与 AI 嵌入式平台和受治理的运营模式相结合，提升关键任务运营的速度、一致性和合规性。通过将技术融入工作的执行和扩展方式，Indegene 帮助生命科学组织在受监管环境中交付可衡量的成果。
传统数据质量项目为何失效
大多数组织已经建立了数据质量流程，但随着企业数据生态系统的演进，保持这些流程的有效性变得越来越困难。
最大的挑战之一是技术规则与业务规则所有权之间的割裂。数据工程师通常定义技术规则，用于确认数据在结构上是否正确。例如，验证 HCP ID（Healthcare Professional ID）不为空、符合所需格式、具有唯一性，并映射到有效的参考记录。业务团队则定义规则，用于判断数据在其运营语境中是否合理。例如，确认某区域内的产品市场份额合计为 100%，或某 HCP 的处方活动与其专业领域和资格标准相符。由于技术规则通常以代码形式维护，而业务规则存在于术语表、SOP 和领域专家知识中，因此要在不同数据集和平台之间保持二者一致并实现统一治理变得十分困难。
传统校验技术也存在固有局限。对空值、数据类型、唯一性或引用完整性的检查仍然必不可少，但它们无法捕捉业务特定的语境。验证产品层级、客户细分、区域对齐或商业业务规则需要领域知识，而静态校验逻辑难以轻易表达这些知识。
创建和维护数据质量规则同样要求很高。每个新数据集都需要数据剖析、规则定义、SQL 开发、校验和持续维护。这些规则往往分散在 SQL 脚本、管道代码、电子表格、数据目录和特定工具的配置中。随着模式、业务定义或校验阈值发生变化，更新和治理这些规则所需的工作量会显著增加。
此外，运营影响也十分显著。由于许多活动需要手动重复执行，新数据集的接入变得更慢。在数百个数据集上维护质量规则会消耗宝贵的工程投入。当校验规则难以理解、难以追溯或难以与业务语境关联时，业务用户会失去信心。
因此，数据质量往往沦为周期性的治理活动，而非持续、可扩展的能力。
以生成式 AI 重新思考数据质量
传统数据质量工具往往作为独立能力运行，与更广泛的企业数据生态系统脱节。随着组织扩展 AI 和分析，数据质量需要嵌入数据平台本身，让治理、元数据、血缘和分析协同运作。
Indegene 通过 NEXT Unified Data Platform（NEXT UDP）应对这一挑战，这是一个专为生命科学打造的现代化、AI 驱动的数据平台。NEXT UDP 将分散的商业、医学、临床和企业数据汇聚到单一受治理的环境中，使组织能够管理从数据摄取到分析的完整数据生命周期。NEXT UDP 提供多个独立 AI Agent，例如 Data Ingestion agent、Data Quality agent、Orchestration agent、Data Catalog agent 和 SQL Bot Generator agent。你可以在数据管道中单独使用它们，也可以进一步定制以实现 agent-to-agent 通信。
通过将数据摄取、转换、数据质量、治理、元数据管理和分析集成到统一平台中，NEXT UDP 帮助组织：
- 将分散的企业数据整合为可信的单一事实来源。
- 在各业务领域统一数据质量和治理标准。
- 提升元数据可见性、血缘和可追溯性。
- 减少数据工程工作流程中的手动投入。
- 为企业分析和决策提供可信、AI 就绪的数据。
图 1：NEXT Unified Data Platform 仪表盘，包含用例和 AI Agent
图 2：NEXT UDP 在 AWS 上的技术架构
Indegene 的生命科学客户需要一个能够在生产环境中可靠运行并满足严格治理要求的智能体，同时让团队在构建方式上保持灵活性。在 NEXT UDP 中，生成式 AI 驱动着一个智能数据质量智能体，用于增强现有的数据质量流程。该智能体通过加速规则创建、简化校验，并帮助在企业规模上保持一致的治理，从而提升数据工程师和数据管理员的生产力。
Indegene 在一系列 AWS 服务上构建了数据质量智能体，其核心是 Amazon Bedrock、Strands Agents 和 Amazon Bedrock AgentCore。 Amazon Bedrock, 提供多种基础模型（FM）选择，并建立在 安全、隐私和负责任 AI 控制的基础之上。对于生命科学组织而言，这一点很重要，因为他们的数据通常包含敏感的医疗专业人士和患者信息。 Strands Agents 简化了智能体的构建和更新，其评估工具帮助 Indegene 测试规则准确性，这在受监管的生命科学环境中至关重要。该智能体运行在 Amazon Bedrock AgentCore, 这是一个可使用任意框架或模型大规模构建、连接和优化智能体的平台。该解决方案还继承了现有的 AWS 安全和审计控制，因此 Indegene 可以专注于数据质量逻辑，而不是智能体基础设施。
数据质量智能体的独特之处是什么？两个知识库驱动上下文感知的数据质量
任何数据质量工具都能检查空值、重复项或无效数据类型。AWS Glue Data Quality（AWS Glue 的一项功能）等服务已经可以根据数据统计推荐此类规则，它们仍然是坚实的基础。更难的问题在于判断数据对其业务目的是否合理。为此，数据质量智能体使用两个互补的知识库，将精选的领域知识与从受治理使用中获得的经验相结合。
第一个是 内部企业知识库： 它整合了内部业务术语表、数据字典、SOP、监管指南、已批准的数据质量规则、经验证的脚本、剖析结果、历史异常以及主题专家（SME）反馈。内容经过摄取、向量化，并通过检索增强生成（RAG）进行检索，以生成基于企业标准和已验证成果的数据质量规则。
第二个是 外部参考知识库： 它使用已批准的标准化数据质量框架、网络搜索和受控网络抓取来构建并定期更新。当选择数据集时，智能体会分析表和列元数据，并从可信来源检索相关的数据质量标准、参考值和校验最佳实践。例如，对于 NPI（国家提供者标识符）列，它可以识别适用的质量标准、推荐格式（必需的 10 位数字格式）并执行参考值校验检查。
工作原理
图 3：数据质量智能体流程
数据质量智能体在单一工作流中引导用户从数据剖析走向规则创建和治理：
- 选择源： 连接到受支持的源，例如 Amazon Redshift 或 Snowflake。
- 选择数据库和架构： 浏览可用的表，并查看每个表的规则数量和活动规则状态。
- 剖析数据： 该解决方案计算表的质量指标和列模式，供用户审查。
- 检测异常： 该解决方案对照历史基线标记异常，用户可审查总数、严重和警告问题以及受影响的记录。
- 管理规则： 审查表的现有规则或开始创建新规则。
- 选择规则模式： 选择列级别、表级别或自定义查询。
- 生成规则建议： 智能体使用元数据、剖析结果、异常、现有规则和知识库上下文来推荐技术和业务规则，每条规则都带有严重性级别。
- 审查、完善并应用： 用户编辑或批准每条建议。
- 生成并校验代码： 智能体为已批准的规则生成 SQL 和 Python，并通过校验步骤进行检查。
- 存储到中央规则存储库： 已批准的规则可用于执行、监控和审计。
AWS 上由生成式 AI 驱动的数据质量智能体的解决方案架构
下图展示了 NEXT UDP 平台上数据质量智能体的端到端架构，从数据管理员请求到规则执行。
图 4：NEXT UDP 上数据质量智能体的解决方案架构
数据管理员和数据质量分析师从 Indegene 应用程序调用该解决方案。下表提供了解决方案管道的逐步说明，并列出了每一层使用的 AWS 服务。它还列出了该解决方案支持的其他选项，以便你根据数据量、现有工具和运营偏好进行调整。
| 层 | AWS / 平台服务 | 也支持 | 作用 |
| API 和访问 | AWS WAF, Amazon API Gateway, Amazon Cognito | – | 数据管理员和数据质量分析师通过 Amazon API Gateway 调用该解决方案。AWS WAF 在请求到达 API 之前进行过滤，Amazon Cognito 使用 OAuth 2.0 对用户进行身份验证，并在每次请求时验证 JWT。 |
| 数据源层 | Amazon Redshift | Snowflake 连接器、 Amazon Simple Storage Service（Amazon S3）, JDBC/ODBC 源 | 为数据质量剖析和规则执行提供结构化和半结构化数据。 |
| 元数据目录层 | AWS Glue Data Catalog | 用于自动架构发现的 AWS Glue 爬网程序 | 捕获数据库、架构、表、列、数据类型和规则覆盖情况。 |
| 剖析和异常检测层 | AWS Lambda （Python），结果存储在 Amazon DynamoDB | AWS Glue 作业, Amazon Athena, Amazon Redshift SQL |
列统计信息（如空值率、不同值计数、数据类型一致性、模式、值范围和表级信号）由 AWS Lambda 上基于 Python 的剖析流程计算 同一个 Lambda 通过将数据与历史基线进行统计对比来执行异常检测，以标记意外变化，例如空值率激增或基数变化。 |
| 知识/RAG 层 | Amazon Bedrock Knowledge Base ，搭配 Amazon Aurora PostgreSQL（pgvector） 和 S3 用于存储知识文档，并通过 AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力） | Amazon OpenSearch Serverless 作为向量存储， Amazon S3 Vectors（Amazon S3 的一项能力） | 从 Amazon Bedrock Knowledge Bases 检索（外部参考标准和内部企业知识）。AgentCore Gateway 将智能体与其知识库作为工具连接起来。 |
| LLM 智能层 | Strands Agents ，运行于 AgentCore runtime（Amazon Bedrock AgentCore 的一项能力）, Claude Sonnet 4.5 运行于 Amazon Bedrock, Amazon Bedrock Guardrails, AgentCore memory | Amazon Bedrock 中可用的其他基础模型 | 生成数据质量规则，并利用组装好的上下文和少样本提示来推荐技术检查（完整性、格式、唯一性）和制药行业特有的业务规则。Amazon Bedrock 提供多种 FM 供选择以生成规则。AgentCore runtime 提供托管的、会话隔离的环境，AgentCore memory 保留审核者反馈以改进未来的推荐。 |
| 编排与人工审核层 | AWS Step Functions, AWS Lambda, Amazon Simple Queue Service（Amazon SQS）, Amazon Simple Notification Service（Amazon SNS）, Amazon EventBridge | – | 协调剖析、LLM 调用、规则生成、规则执行、状态更新和人工审核。 |
| 规则元数据存储库 | Amazon DynamoDB | Amazon Aurora / Amazon Relational Database Service（Amazon RDS） | 存储规则 ID、名称、类型、列、状态、作者、创建日期、严重性和版本详情。 |
| 代码生成、验证与存储 | Amazon Bedrock – Claude Sonnet 4.5 和 AgentCore Code Interpreter（Amazon Bedrock AgentCore 的一项能力）, 并将已批准的脚本存储在 Amazon S3 中 | – | 生成 Python / SQL 代码并在存储前进行检查 |
| 执行层 | AWS Lambda | AWS Glue 作业, Amazon Athena, Amazon Redshift SQL | 运行数据质量检查并写入违规计数和详细异常。 |
| 监控与仪表板层 | Amazon CloudWatch, AgentCore Observability（Amazon Bedrock AgentCore 的一项能力） 或应用程序 UI | Amazon Quick, Amazon OpenSearch 仪表板 | 数据质量仪表板显示所应用的规则及其状态，以及总异常数、严重异常数、已运行的检查和问题详情。 |
| 安全与治理 | AWS Identity and Access Management（AWS IAM）, AWS Key Management Service（AWS KMS）, AWS Secrets Manager, AWS CloudTrail, AWS Config, Amazon GuardDuty, AWS Security Hub, Amazon Inspector, 虚拟私有云（VPC）端点 | – | 身份验证、加密、密钥、审计和威胁检测 |
数据质量智能体如何构建上下文
在推荐任何验证规则之前，数据质量智能体会从六个不同的来源组装上下文，每个来源回答关于数据的不同问题：
| 上下文来源 | 它提供什么 | 它回答的问题 |
| 表/列元数据（目录） | 来自 Data Catalog 的架构、数据类型 | 这是什么数据？ |
| 数据剖析 | 从实际数据计算出的列级统计信息，例如空值率、不同值计数、值范围、频繁值和检测到的模式 | 数据现在看起来是什么样的？ |
| 异常检测结果 | 通过将最新剖析与历史基线对比而标记出的意外变化，例如空值突然增加、不同值变化或超出范围的值 | 什么发生了变化或看起来有问题？ |
| 现有活动数据质量规则 | 已在表或列级别应用的规则，从规则存储库中检索 | 已存在哪些规则，以免我们重复或冲突？ |
| 外部参考知识库 | 通用的、公开确立的数据质量标准和验证最佳实践（例如，针对国家提供者标识符等标识符的格式和结构规则） | 该字段的行业标准是什么？ |
| 内部企业知识库 | 组织特定的数据质量规则模式、以往的审核者反馈以及精选的业务/技术规则库 | 本组织如何定义质量？ |
这些来源共同让智能体像经验丰富的数据管理员一样推理。将每项推荐建立在数据 是什么、 标准 要求什么、 企业 如何定义质量以及 已经 实施了什么之上。
解决方案的功能
数据质量智能体会生成多个类别的检查，并让数据管理员掌控结果。
异常检查生成
该解决方案生成异常检查，以捕获技术上有效但不符合制药市场行为方式的值。这些包括负的转换百分比、在某个市场内市场份额合计不等于 100%、不一致的药品排名（例如，排名第一的药品份额低于排名第二的药品）、超出定义量表的评级值，以及过小或与受访者数量不匹配的小组规模。
基于 RAG 的上下文感知规则生成
数据质量智能体以三种模式生成规则推荐：
| 规则类型 | 描述 |
| 列级别 | 为用户选定的特定单列生成数据质量规则。智能体读取该列的元数据和剖析信号，以建议数据类型验证、空值和必填字段检查、长度和范围验证、模式/格式验证以及唯一性等检查。 |
| 表级别 | 为整张表生成数据质量规则，由表的元数据及其各列之间的关系驱动。这涵盖记录一致性、重复检测、跨列验证、引用完整性检查以及表级业务一致性。 |
| 自定义查询 | 根据自然语言输入生成基于 SQL 的规则。用户用通俗英语描述业务验证，智能体生成相应的 SQL，随后可通过对话方式细化或直接编辑，以支持超出标准列级和表级检查范围的复杂验证。 |
“创建新质量规则”界面提供专用的列级别、表级别和自定义查询模式。
该平台同时支持技术验证和业务特定的质量检查。
对于技术规则，智能体生成确认数据在结构上健全的检查。这些包括必填字段的空值检查、数据类型验证、数值和日期值的范围验证、标识符和代码等格式化字段的模式验证、重复检测以及相关表之间的引用完整性检查。
对于业务规则，智能体生成生命科学检查，以确认数据与业务运营方式保持一致。这些包括账户归属一致性（例如，医疗服务提供者关联到正确的组织）、细分逻辑、资格标准以及市场份额和产品份额验证（例如，某区域内的份额不超过 100%）。
真实用例示例
考虑一张 HCP 产品绩效表，其列包括 HCP_ID、Specialty、Territory_ID、Product_ID、Prescription_Volume、Market_Share_Pct、Switch_Pct、Rating_Scale 和 Reporting_Month。利用表剖析和两个知识库，数据质量智能体生成并执行以下检查的方式如下：
- 已执行的异常检查。
- 负的转换百分比。
- 市场份额总计不匹配。
- 处方量突然增加或减少。
- 产品排名不一致。
- 评级量表值无效。
- 已生成的技术规则。
- HCP_ID 不得为空或重复。
- Prescription_Volume 必须为数值且非负。
- Market_Share_Pct 和 Switch_Pct 必须介于 0 和 100 之间。
- Reporting_Month 必须遵循所需的日期格式。
- Territory_ID 和 Product_ID 必须与其参考表匹配。
- 已生成的业务规则。
- 对于每个区域和报告月份，所有产品的市场份额总计必须为 100%。
- HCP 的产品资格必须与其专业相符。
- 只有符合条件的 HCP 才能纳入目标细分。
AI 辅助的严重性建议
该解决方案根据数据集上下文、规则类型和业务影响推荐严重性。严重性类别有助于区分：
- 严重 问题，例如无效的商业指标、错误的标识符或业务规则违规。
- 基本 验证，包括架构一致性、空值检查和长度验证。
- 复杂 验证，涉及高级 SQL 逻辑、多列规则或领域特定的业务检查。
- 信息： 仅为知晓和透明目的而进行的验证。除非发现问题，否则无需采取行动。
SQL/Python 代码生成与 ETL 集成
规则获批后，LLM 生成等效的 SQL、Python 和 PySpark 代码。在存储之前，代码会自动经过语法检查、针对目标架构的检查以及在语言支持的情况下对样本数据进行试运行来验证。这意味着现有的提取、转换和加载（ETL）及编排工具可以将其作为当前数据管道的一部分来运行。
AI 辅助验证
使用 LLM 作为验证智能体来审查另一个 LLM 生成的数据质量（DQ）规则/脚本，以减少幻觉并改进治理。此外， Amazon Bedrock 提供 安全性、隐私和负责任 AI 控制. 提示和输出不会用于训练模型，也不会与模型提供商共享。Amazon Bedrock 符合 HIPAA 资格，并纳入 SOC、ISO 和 GDPR 等合规计划的范围，这有助于 Indegene 满足其生命科学客户的要求。 Amazon Bedrock Guardrails 为模型输入和输出添加可配置的防护措施。它检测并掩蔽个人可识别信息（PII），阻止有害内容和提示注入攻击，并使用上下文接地检查来标记检索知识不支持的响应。
人工监督仍是核心
数据质量智能体旨在增强现有的数据质量流程。每条生成的规则都会获得一个置信度分数。只有高置信度、低风险的规则才会自动批准，而关键规则和业务规则始终交由主题专家（SME）审查。每个决策都记录在规则存储库中，因此规则管理保持受治理、可追溯并与企业标准保持一致。
交付运营影响和业务价值
在生产环境中，在 Indegene 为生命科学客户部署 NEXT UDP 的过程中，数据质量智能体将定义和实施数据质量规则的工作量从每个数据集约 30 小时减少到约 4 小时。这大约减少了 85% 的工作量，或约 7 倍的生产力提升。现在，新表接入需要 2–4 小时，而不是 2–5 个工作日。数据工程师和数据管理员现在将时间花在审查和批准规则上，而不是从头编写规则。
主要成果包括：
- 通过 AI 生成的规则、SQL 和 Python 减少人工工作量。
- 更快地接入新表、架构和业务领域。
- 基于已批准的标准、企业知识和现有规则，规则更加一致。
- 通过审查、完善和批准工作流，促进业务团队与技术团队之间更好地协作。
- 通过自动化剖析和异常检测，更早发现数据质量问题。
表1：性能与规模
| 指标 | 影响* |
| 企业级剖析 | 25–50个schema；500–2,000张表；10,000–50,000列 |
| 表剖析 | 45–90秒（约100万行）；2–5分钟（约1000万行） |
| AI规则生成 | 每张表20–45秒 |
| SQL生成 | 每条规则3–8秒；10–15条规则20–60秒 |
| 规则执行 | 20–30秒（标准）；1–3分钟（复杂SQL） |
| 中央规则存储库 | 1,000–10,000条规则 |
| 每次执行的DQ检查 | 每个域100–500项。可扩展至1,000项以上 |
*根据Indegene生产部署估算
表2：规则质量与验证
| 指标 | 影响* | 含义 |
| 规则建议准确率 | 80–90% | 技术上有效且能正确应用于相应列或表的建议 |
| 规则接受率 | 60–75% | 未经任何修改即获批准的建议 |
| 规则完善率/人工覆盖（Override）率 | 20–35% | 审查者编辑逻辑或阈值后获批的建议 |
| SQL有效性 | 90–97%（基于schema）；80–90%（自定义SQL） | 首次尝试即通过验证的生成SQL |
| 严重性建议准确率 | 75–85% | 建议的严重性与审查者最终确定的严重性一致 |
| 业务相关性（SME评分） | 4.0–4.5 / 5 | SME对推荐规则对业务有用程度的评分 |
| 幻觉率 | <5–8% | 引用不存在的列或错误业务逻辑的建议 |
*根据Indegene生产部署估算
表3：运营效率
| 指标 | 影响* |
| 手动编写SQL规则 | 端到端工作量（包括审查和完善）减少60–80% |
| 新表接入 | 2–5个工作日 → 2–4小时 |
| 规则复用 | 40–60%的新规则改编自已批准的现有规则 |
| LLM成本优化 | 借助Amazon Bedrock提示缓存，缓存上下文的输入token成本最高降低90% |
| 计算优化 | 采用元数据优先的剖析方式，降低约45–51% |
*根据Indegene生产部署估算
表4：手动与智能体辅助的数据质量对比
| 活动 | 传统DQ方法 | 生成式AI驱动的DQ方法 | 影响* |
| 规则发现 | 人工审查schema、剖析报告、样本数据和文档。现有工具可生成基础剖析检查，但往往遗漏领域特定的业务逻辑 | 智能体利用元数据、剖析结果、表上下文、现有规则模式以及可选的业务描述，推荐技术和生命科学特定的数据质量规则 | 快80–85% |
| 技术规则生成 | 手动创建空值、数据类型、范围、唯一性和完整性规则 | 自动生成规则并由人工审查 | 快80–85% |
| 业务规则定义 | 验证通常基于技术元数据，对产品、细分、客户或资格逻辑的理解有限。业务上下文严重依赖SME讨论和人工转化为验证逻辑 | 使用RAG检索业务词汇表、数据字典、现有规则和历史异常模式，以生成上下文感知的建议。 | 快70–75% |
| 规则编写与SQL/Python开发 | 工程师针对每个数据集或业务需求手动定义验证规则，并进行编码、调试和测试。 | 在列级、表级和自定义查询级自动生成规则，并为选定的DQ检查生成SQL/Python。用户可以审查、完善并应用这些建议。 | 首个可运行代码快80–85% |
| 规则验证 | 规则需人工验证，涉及多次执行查询和修改的迭代 | 智能体自动评分、完善并优化规则 | 快80–85% |
| 规则复用 | 手动复制、修改和复用 | 已批准的规则和反馈被加入智能体的知识库 | 现有领域中新数据集的接入快50% |
| 异常检测 | 人工分析剖析输出和记录 | 自动异常检测并提供业务上下文解释 | 快80–85% |
| 严重性分类 | 规则严重性和业务影响由人工确定，可能导致优先级不一致。 | 根据规则类型、数据集上下文和业务影响推荐严重性。 | 一致且基于上下文的严重性 |
| 治理与可追溯性 | 规则往往分散在工具、脚本、电子表格或目录中，使治理和可追溯性变得困难。审批和审查工作流因团队而异。 | 集中式、带版本的规则存储库，并明确归属 | 维护工作量减少85% |
| 人力投入 | SME和工程师推动每个步骤 | SME专注于审查和批准。智能体负责发现和生成 | 更高的生产力和可扩展性，约7倍生产力 |
*根据Indegene生产部署估算
展望未来
随着企业数据生态系统持续增长，使用手动规则创建和碎片化治理流程来维持一致且可扩展的数据质量变得越来越困难。生成式AI提供了一个机会，通过加速规则生成、融入业务上下文并支持受治理的决策，来增强这些工作流。
NEXT统一数据平台中由生成式AI驱动的数据质量Agent展示了大型语言模型、RAG和集中式规则治理如何协同工作，在简化数据质量管理的同时让人类掌控审查和审批。未来的增强功能将继续在此基础上构建，包括：
- AI辅助的修复建议，帮助用户解决未通过的数据质量检查。
- 根因分析，用于识别反复出现的异常模式，并支持更快地调查重复出现的数据质量问题。
随着这些能力不断演进，重点始终不变：通过AI辅助的自动化帮助组织提升数据质量，同时保持治理、透明度和业务监督。
如需了解更多信息，请参阅以下资源：
- Indegene在生命科学领域
- 医疗与生命科学中的生成式AI
- AWS Skill Builder课程：使用Amazon Bedrock构建生成式AI应用
- GitHub仓库：AWS上的医疗与生命科学Agent示例