本文由Indegene Limited的Shravan K S共同撰写。
企业AI正在为生命科学组织创造新的机会,以改进商业、医学、市场准入及其他业务职能的决策。但每个AI模型、仪表板和业务洞察的质量都取决于一件事:可信的数据。随着企业数据在多个平台、管道和业务领域中不断增长,保持一致的数据质量变得越来越困难。手动创建数据质量规则、碎片化的治理以及不断演变的业务定义,使得在整个企业范围内扩展数据质量充满挑战。
本文探讨了Indegene如何在AWS上的NEXT统一数据平台(NEXT UDP)内构建一个生产级、由大语言模型(LLM)驱动的数据质量Agent。该Agent可生成具备上下文感知能力的数据质量规则、对其进行验证,并在集中式的人机协同治理下生成可直接运行的SQL和Python代码。这些能力共同帮助组织在企业规模上提升数据质量,同时减少构建和维护数据质量计划所需的工作量。
关于Indegene
Indegene Limited (BSE: 544172,NSE: INDGN)是生命科学行业的战略运营合作伙伴,在整个产品生命周期中统筹商业、医学、研发(R&D)和安全运营。Indegene深受全球前20大生物制药公司的信赖,帮助其在全球范围内运行复杂且受严格监管的工作流程。Indegene将深厚的生命科学专业知识与嵌入AI的平台和受治理的运营模式相结合,以提升关键任务运营的速度、一致性和合规性。通过将技术融入工作的执行和扩展方式,Indegene帮助生命科学组织在受监管的环境中交付可衡量的成果。
为什么传统的数据质量计划会失效
大多数组织都已建立数据质量流程,但随着企业数据生态系统的演变,保持这些流程的有效性正变得越来越困难。
最大的挑战之一是技术规则与业务规则所有权的分裂。数据工程师通常定义技术规则,用于确认数据在结构上是否正确。例如,验证HCP ID(医疗专业人员ID)不为空、符合要求的格式、具有唯一性,并映射到有效的参考记录。业务团队则定义规则,用以确定数据在其运营场景中是否有意义。例如,确认产品市场份额在某区域内总计为100%,或某HCP的处方活动与其专业领域和资格标准相符。由于技术规则通常以代码形式维护,而业务规则则存在于词汇表、SOP和领域专家知识中,因此在不同数据集和平台之间保持两者一致并进行统一治理变得十分困难。
传统验证技术也存在固有的局限性。对空值、数据类型、唯一性或引用完整性的检查仍然必不可少,但它们无法捕捉特定业务的上下文。验证产品层级、客户细分、区域对齐或商业业务规则需要领域知识,而静态验证逻辑难以表达这些知识。
创建和维护数据质量规则同样要求很高。每个新数据集都需要数据剖析、规则定义、SQL开发、验证和持续维护。这些规则往往分散在SQL脚本、管道代码、电子表格、数据目录和特定工具的配置中。随着架构、业务定义或验证阈值的变更,更新和治理这些规则所需的工作量会显著增加。
此外,运营影响也很显著。由于许多活动需要重复手动执行,新数据集的接入变得更慢。在数百个数据集中维护质量规则消耗了宝贵的工程资源。当验证规则难以理解、难以追踪或难以与业务上下文关联时,业务用户的信心就会下降。
其结果是,数据质量往往沦为周期性的治理活动,而非一种持续、可扩展的能力。
用生成式AI重新思考数据质量
传统的数据质量工具通常作为独立的能力运行,与更广泛的企业数据生态系统脱节。随着组织扩展AI和分析能力,数据质量需要嵌入数据平台本身,使治理、元数据、血缘和分析协同工作。
Indegene通过 NEXT统一数据平台(NEXT UDP)来解决这一问题,这是一个专为生命科学构建的现代化、AI驱动的数据平台。NEXT UDP将碎片化的商业、医学、临床和企业数据汇聚到一个统一的受治理环境中,使组织能够管理从摄取到分析的完整数据生命周期。NEXT UDP提供了多个独立的AI Agent,例如数据摄取Agent、数据质量Agent、编排Agent、数据目录Agent和SQL Bot生成器Agent。您可以在数据管道中独立使用它们,或为Agent间的通信进一步定制。
通过在统一平台内集成数据摄取、转换、数据质量、治理、元数据管理和分析,NEXT UDP帮助组织:
- 将分散的企业数据整合为可信的单一事实来源。
- 在业务领域之间标准化数据质量和治理。
- 提升元数据可见性、血缘和可追溯性。
- 减少数据工程工作流中的人工工作。
- 为企业分析和决策提供可信的、AI 就绪的数据。
图 1:NEXT 统一数据平台仪表板,展示用例和 AI 智能体
图 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(National Provider Identifier,国家提供商标识符)列,它可以识别适用的质量标准,推荐格式(要求的 10 位数字格式)并执行参考验证检查。
工作原理
图 3:数据质量智能体流程
数据质量智能体在单一工作流中引导用户完成从数据剖析到规则创建和治理的全过程:
- 选择来源: 连接到受支持的来源,例如 Amazon Redshift 或 Snowflake。
- 选择数据库和模式: 浏览可用的表,并查看每个表的规则数量和活动规则状态。
- 画像数据: 该解决方案为表计算质量指标和列模式,供用户审阅。
- 检测异常: 该解决方案根据历史基线标记异常,用户可以审阅总计、严重和警告问题以及受影响的记录。
- 管理规则: 查看表现有的规则,或开始创建新规则。
- 选择规则模式: 选择列级别(Column Level)、表级别(Table Level)或自定义查询(Custom Query)。
- 生成规则建议: 该代理利用元数据、画像结果、异常、现有规则和知识库上下文来推荐技术和业务规则,每条规则都带有严重级别。
- 审阅、优化并应用: 用户可以编辑或批准每条建议。
- 生成并验证代码: 该代理为已批准的规则生成 SQL 和 Python 代码,并通过验证步骤进行检查。
- 存储到中央规则仓库: 已批准的规则可用于执行、监控和审计。
基于生成式 AI 的数据质量代理(Data Quality Agent)在 AWS 上的解决方案架构
下图展示了 NEXT UDP 平台上 Data Quality Agent 的端到端架构,从数据管理员请求到规则执行。
图 4:NEXT UDP 上 Data Quality Agent 的解决方案架构
数据管理员和数据质量分析师从 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 知识库 与 Amazon Aurora PostgreSQL (pgvector) 以及S3,用于存储以工具形式通过以下方式暴露的知识文档 AgentCore Gateway,是 Amazon Bedrock AgentCore 的一项功能 | Amazon OpenSearch 面向向量存储的无服务器架构, 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 中提供的其他基础模型 | 生成数据质量规则,并使用组装好的上下文和少样本提示(few-shot prompting)来推荐技术检查(完整性、格式、唯一性)以及制药行业特有的业务规则。Amazon Bedrock 提供多种基础模型(FM)供选择以生成规则。AgentCore runtime 提供托管且会话隔离的环境,AgentCore memory 保留审阅者的反馈以改进未来的推荐。 |
| 编排与人工审阅层 | AWS Step Functions(AWS 步骤函数), AWS Lambda(AWS Lambda 无服务器计算服务), Amazon Simple Queue Service(Amazon SQS,亚马逊简单队列服务), Amazon Simple Notification Service(Amazon SNS,亚马逊简单通知服务), Amazon EventBridge(亚马逊 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 Dashboards | 数据质量仪表板显示已应用的数据质量规则及其状态,以及异常总数、严重异常、已运行检查次数和问题详细信息。 |
| 安全与治理 | 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 Quality Agent 如何构建上下文
在推荐任何验证规则之前,Data Quality Agent 会从六个不同的来源汇集上下文,每个来源针对数据回答一个不同的问题:
| 上下文来源 | 它提供什么 | 它回答什么问题 |
| 表/列元数据(Catalog) | 来自 Data Catalog 的模式和数据类型 | 这是什么数据? |
| 数据画像 | 根据实际数据计算出的列级统计信息,例如空值率、不同值计数、值范围、高频值和检测到的模式 | 数据现在看起来是什么样子? |
| 异常检测结果 | 通过将最新画像与历史基线进行比较而标记出的意外变化,例如空值突然增加、不同值发生变化或出现超出范围的值 | 什么发生了变化或看起来不对劲? |
| 现有的活动数据质量规则 | 已在表级或列级应用的规则,从规则存储库中检索 | 已存在哪些规则,以避免重复或冲突? |
| 外部参考知识库 | 通用的、公开确立的数据质量标准和验证最佳实践(例如,像 National Provider Identifier 这类标识符的格式和结构规则) | 该字段的行业标准是什么? |
| 内部企业知识库 | 组织特定的数据质量规则模式、以往的评审反馈,以及经过整理的业务/技术规则库 | 这个组织如何定义质量? |
这些来源结合在一起,让代理像一位经验丰富的数据管理员那样进行推理。每条建议都立足于数据 是什么, 标准 有什么要求, 企业 如何定义质量,以及已经 已经 实施了什么。
该解决方案的功能
Data Quality Agent 生成多个类别的检查,并让数据管理员保持对结果的控制。
异常检查生成
该解决方案生成异常检查,捕获那些在技术上有效但与医药市场实际行为不符的值。这些包括负的转换百分比、在某个市场中加起来不等于100百分比的市场份额、不一致的药品排名(例如,排名第一的药品份额低于排名第二的药品)、超出定义范围的评级值,以及过小或与受访者数量不符的样本组规模。
基于 RAG 的上下文感知规则生成
Data Quality Agent 以三种模式生成规则建议:
| 规则类型 | 描述 |
| 列级别 | 为用户选择的特定单个列生成数据质量规则。该代理读取该列的元数据和剖析信号,以建议检查,例如数据类型验证、空值和必填字段检查、长度和范围验证、模式/格式验证以及唯一性检查。 |
| 表级别 | 基于表的元数据及其各列之间的关系,为整个表生成数据质量规则。这涵盖记录一致性、重复检测、跨列验证、引用完整性检查以及表级业务一致性。 |
| 自定义查询 | 从自然语言输入生成基于 SQL 的规则。用户用通俗英语描述业务验证,代理生成相应的 SQL,然后可以通过对话进行细化或直接编辑,以支持超出标准列和表检查范围的复杂验证。 |
Create New Quality Rule 界面提供专门的列级别、表级别和自定义查询模式。
该平台同时支持技术验证和特定业务的质量检查。
对于技术规则,代理生成确认数据在结构上健全的检查。这些检查包括必填字段的空值检查、数据类型验证、数值和日期值的范围验证、标识符和代码等格式化字段模式验证、重复检测以及相关表之间的引用完整性检查。
对于业务规则,代理生成生命科学领域的检查,确认数据与业务的实际运作方式一致。这些检查包括账户隶属一致性(例如,医疗提供者链接到正确的组织)、细分逻辑、资格标准以及市场份额和产品份额验证(例如,某区域内的份额不超过100%)。
实际用例示例
设想一个 HCP Product Performance 表,包含 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 percent的工作量,即约7倍的更高生产力。接入一个新表现在只需2–4小时,而不是2–5个工作日。数据工程师和数据管理员现在将时间用于审查和批准规则,而不是从头编写规则。
关键成果包括:
- 通过AI生成的规则、SQL和Python减少人工工作量。
- 更快地接入新表、模式和业务领域。
- 规则更加一致,以已批准的标准、企业知识和现有规则为基础。
- 通过审查、完善和批准的工作流,促进业务团队和技术团队之间更好的协作。
- 通过自动化画像和异常检测更早发现数据质量问题。
表1:性能和规模
| 指标 | 影响* |
| 企业画像 | 25–50 个模式;500–2,000 张表;10,000–50,000 列 |
| 表剖析 | 45–90 秒(约1M 行);2–5 分钟(约10M 行) |
| 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% | 未经任何修改即被批准的建议 |
| 规则优化率 / 人工覆盖率 | 20–35% | 审核人修改逻辑或阈值后才被批准的建议 |
| SQL 有效性 | 90–97%(基于模式);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 提示词缓存,缓存上下文的输入令牌成本最高可降低 90% |
| 计算优化 | 通过元数据优先的分析实现约 45–51% 的降幅 |
*基于 Indegene 的生产部署估算
表 4:人工方式与代理辅助数据质量对比
| 活动 | 传统 DQ 方法 | 生成式 AI 驱动的 DQ 方法 | 影响* |
| 规则发现 | 人工审查模式、分析报告、样本数据和文档。现有工具可以生成基础的分析检查,但往往遗漏特定领域的业务逻辑 | 代理利用元数据、分析结果、表上下文、现有规则模式以及可选的业务描述,推荐技术类和生命科学领域特定的数据质量规则 | 速度提升 80-85% |
| 技术规则生成 | 人工创建空值、数据类型、范围、唯一性和完整性规则 | 自动化规则生成并进行人工审核 | 速度提升 80-85% |
| 业务规则定义 | 验证通常基于技术元数据,对产品、细分市场、客户或资格逻辑的理解有限。业务上下文高度依赖与 SME 的讨论以及人工转化为验证逻辑 | 使用 RAG 检索业务术语表、数据字典、现有规则和历史异常模式,以生成具备上下文感知能力的建议。 | 速度提升 70-75% |
| 规则编写与 SQL/Python 开发 | 工程师针对每个数据集或业务需求手动定义验证规则,并进行编码、调试和测试。 | 在列级别、表级别和自定义查询级别自动生成规则,并为所选的 DQ 检查生成 SQL/Python。用户可以审查、细化并应用这些建议。 | 首个可运行代码的产出速度提升 80-85% |
| 规则验证 | 规则需要人工验证,涉及多轮执行查询和反复打磨 | 代理自动评分、细化和优化规则 | 速度提升 80-85% |
| 规则复用 | 手动复制、修改并复用 | 经批准的规则和反馈被添加到智能体的知识库中 | 在现有领域中,新数据集的上线速度提升50% |
| 异常检测 | 人工分析画像输出和记录 | 结合业务上下文解释的自动化异常检测 | 速度提升80-85% |
| 严重性分级 | 规则的严重性和业务影响由人工确定,这可能导致优先级排序不一致。 | 基于规则类型、数据集上下文和业务影响推荐严重性。 | 一致且基于上下文的严重性 |
| 治理与可追溯性 | 规则通常分散在工具、脚本、电子表格或目录中,使治理和可追溯性变得困难。审批和审查流程因团队而异。 | 集中的、带版本管理和所有权归属的规则存储库 | 维护工作量减少85% |
| 人工投入 | 领域专家(SME)和工程师驱动每一步 | 领域专家专注于审查和批准。智能体负责发现和生成。 | 更高的生产力和可扩展性,生产力提升约7倍 |
*估算自Indegene的生产环境部署
展望未来
随着企业数据生态系统持续增长,使用手动规则创建和碎片化的治理流程来保持一致且可扩展的数据质量变得越来越困难。生成式AI为增强这些工作流提供了机会,通过加速规则生成、融入业务上下文并支持受治理的决策制定。
NEXT统一数据平台中基于生成式AI的数据质量智能体展示了大语言模型、RAG和集中式规则治理如何协同工作,以简化数据质量管理,同时让人类掌控审查和批准。未来的增强功能将继续在此基础上构建,包括:
- AI辅助的修复建议,帮助用户解决未通过的数据质量检查。
- 根因分析,用于识别反复出现的异常模式,并支持更快速地调查重复出现的数据质量问题。
随着这些能力的演进,重点始终保持不变:帮助组织通过AI辅助的自动化提升数据质量,同时保持治理、透明度和业务监督。
欲了解更多信息,请参阅以下资源:
- Indegene在生命科学领域
- 医疗与生命科学中的生成式AI
- AWS Skill Builder课程:使用Amazon Bedrock构建生成式AI应用
- GitHub仓库:AWS上的医疗与生命科学智能体示例