AWS实战：AI自动纠正与统一数据集元数据

随着数据收集和数据生成的加速，我们产生原始数据的能力与将其标准化能力之间的差距持续扩大。若没有自动化，这个差距就会成为一个关键瓶颈，延迟分析工作、复杂化解读，并限制共享数据集的全球价值。

元数据 harmonization（统一不同来源的数据集标签、标识符和格式使其能够协同工作）在很大程度上仍依赖人工完成。AI 驱动的元数据修正与 harmonization 提供了一条出路，将元数据管理从一项耗时的职责转变为随数据量扩展、支持开放科学而非阻碍它的流程。

在本文中，我们演示了 AI 驱动的元数据修正如何在实践中发挥作用，探索了两种实现方案（从人在回路验证到完全自主的 AI 智能体驱动工作流），并提供了在你组织中部署这些解决方案的治理注意事项。

元数据修正与 harmonization 工作流

为应对这一挑战，我们开发了一套基于 AWS 的集中式元数据修正与 harmonization 工作流，旨在支持不同元数据源之间的一致性、互操作性和准确性。该系统使用 Amazon Bedrock 提供大语言模型（LLM）驱动的 schema 对齐和修正建议，Amazon Simple Storage Service（Amazon S3）存储 schema 和结果，Amazon DynamoDB 进行作业跟踪，Amazon Cognito 进行身份验证，Amazon Elastic Container Service（Amazon ECS）提供计算资源。工作流包含一个 harmonization 包，用于对齐元数据 schema、验证数据完整性并生成修正建议。

元数据修正与 harmonization 系统作为一个循环工作运行，引导数据经过验证、生成建议，并将控制权交回用户进行最终审批。下图展示了这个高层流程：

图 1：元数据修正与 harmonization 工作流

如图所示，流程始于用户上传其元数据文件。系统随后执行两个并行验证流：schema 对齐验证列结构是否符合预期格式，而元数据字段验证则检查各个字段值是否符合规范。当检测到问题时，系统会生成有针对性的修正建议并呈现给用户，用户保留对更改的最终决策权。这种人在回路的方法让自动化加速了流程，同时保留了研究人员的控制和领域专业知识。

元数据修正的第一步是比较源数据和目标数据的 schema：验证正确的列是否存在并正确对齐。常见问题包括命名约定不一致（同义词、拼写错误、缩写）、列缺失或多余，以及需要拆分或合并列的情况。模糊字符串匹配可以处理基本的命名差异，但更复杂的对齐挑战需要不同的方法。Amazon Bedrock 上提供的 LLM 为这个问题带来了语义理解能力。LLM 驱动的方法不依赖单纯的字符串相似度，而是能够识别特定行业的同义词、从周围列推断含义，并检测源列何时应拆分为多个目标列或反之。这种语义匹配处理了基于规则的系统会遗漏的情况。

元数据字段验证

元数据字段验证组件检查各个字段值是否符合 schema 要求。系统根据预定义规则评估每个字段，并将失败分类为三种类型。

必填字段验证识别缺失、为空或仅含空白的必填字段。例如，缺失必填样本标识符的行会在进一步处理之前被标记。

枚举值验证将字段内容与 schema 中定义的受控词表进行比较。如果一个字段仅接受特定的仪器类型（如测序系统），则该列表之外的值会触发验证错误。这有助于防止自由格式文本在标准化字段中引入不一致。

模式验证应用正则表达式匹配来验证格式约定。日期字段可能要求 YYYY-MM-DD 格式，而标识符字段可能需要特定的字母数字模式。偏离预期格式的值会被标记。

每条验证失败都被分类并记录了足够的上下文，供建议系统生成适当的修正。结构化错误报告指定了每个问题的位置、类型和性质。

元数据字段建议

在元数据字段验证期间检测到验证错误时，系统会使用自然语言处理（NLP）和基于 AI 技术的分层组合来生成建议，这些技术旨在平衡成本效率、性能和可解释性。通过在调用 LLM 之前优先考虑经典 NLP 和基于嵌入的相似度，工作流实现了准确、可扩展的建议，同时保持推理成本可预测。

这些技术可以单独运行，也可以在 bagging 或 boosting 架构中按顺序运行，根据置信度阈值动态选择。这种自适应分层让更简单的方法高效处理常规修正，而让高级模型仅解决需要上下文推理的模糊或新颖案例。

向量嵌入让系统能够语义地比较元数据值，基于相似度阈值识别近似匹配。这支持对同义词、缩写或首字母缩写等常见变体进行精确修正。例如，系统可以将 "Human" 映射到 "Homo sapiens"，或将 "NYC" 映射到 "New York City"。

这种方法依赖更小、更高效的嵌入模型（可在 Amazon Bedrock 上获取），其输出可以被缓存，在保持准确性的同时提供了一种经济高效的 LLM 驱动推理替代方案。

我们评估了多个嵌入模型，包括特定领域的生物医学模型和 Amazon Titan，以识别最适合此工作负载的模型。我们选择 Amazon Titan 是因为它在通用和生物医学元数据任务上表现出色、商业可用性以及与 Amazon Bedrock 模型推理的兼容性。这使其适合需要可支持的、可扩展嵌入解决方案而不需要自管理特定领域模型的组织。

上下文推理让系统能够通过识别元数据本身内部的关系和共享模式来建议修正。许多数据集表现出内部一致性，即相似的行在列之间共享结构特征或重复值。通过分析这些局部相似性，模型可以使用当前上传中仅存在的信息来推断缺失或不一致的元数据值，从而避免了对大型外部训练数据集的需求。

在此实现中，上下文推理通过结合距离加权的 k 近邻、词频-逆文档频率（TF-IDF）特征表示和共现统计的混合方法运作。数据集中的每一行都被转换为一个复合向量，由其文本、分类和数值字段构建。文本字段被转换为 TF-IDF 表示，分类值通过独热编码或紧凑的学习表示进行编码，数值字段被缩放到可比范围。然后系统使用余弦或欧几里得距离测量行之间的相似度，并通过最相似示例的加权投票来预测缺失值，其中较近的邻居贡献更大的影响力。

通过使用点互信息（PMI）的共现分析进一步实现了细化，PMI 识别在数据集中自然一起出现的值组合。PMI 衡量超出原始频率的统计关联性，捕捉诸如"当 A 列包含 X 时，B 列通常包含 Y"这样的模式。最终建议将相似度和共现信号与可配置权重相结合。这产生了稳定且可解释的建议，这些建议植根于内部数据结构而非外部训练，即使在小型或专业化数据集中也能实现效率和可靠性。

模糊搜索算法（如 Levenshtein 距离）检测并修正打字或格式不一致错误。它们对于解决手动输入元数据中的错误特别有效，如拼写错误、间距或标点差异。模糊匹配通常应用在修正工作流的早期阶段，以在语义或上下文推理层之前捕获低级不一致。

当早期验证方法（包括基于规则的 NLP 和嵌入相似度模型）无法达到足够的置信度时，通过 Amazon Bedrock 进行的 LLM 方案解决作为备用层。这些模型能够跨复杂元数据结构进行推理，以解释模糊或先前未见的模式。LLM 推理是有选择性地调用的，这意味着计算密集型推理仅在简单算法无法高置信度解析某个字段时才会使用。结果随后会呈现给人工审核，以保持下游数据协调的准确性和可追溯性。

元数据校正与协调工作流将三个阶段相结合：通过 LLM 驱动的语义分析进行模式对齐、使用分层基于规则方法进行字段验证，以及通过嵌入、模糊匹配和上下文推理驱动的推荐。简单方法处理常规校正，而 LLM 方案解决则作为传统方法无法解决的边缘情况的备用层。

在部署应用前，确认已安装以下工具：

Node.js 18+（用于 AWS Cloud Development Kit (AWS CDK) 和前端开发）。

Python 3.11+（用于 API 和处理器）。

AWS Command Line Interface (AWS CLI)，已配置具有以下服务权限的凭证：Amazon ECS (AWS Fargate)、Amazon DynamoDB、Amazon S3、Amazon Cognito、Amazon Virtual Private Cloud (Amazon VPC)、AWS Identity and Access Management (IAM)、AWS CloudFormation、Amazon Elastic Container Registry (Amazon ECR) 和 Amazon CloudWatch

AWS CDK Toolkit（npm install -g aws-cdk）

Docker（用于构建容器镜像）。

Make（用于运行提供的 Makefile 命令）。

uv Python 包管理器（用于依赖管理）。

node -v          # 18 or higher
python --version # 3.11 or higher
aws --version    # AWS CLI configured with credentials

第一步：克隆并安装依赖

克隆仓库并安装所有 Python 和 TypeScript 依赖：

git clone https://github.com/aws-samples/sample-intelligent-metadata-harmonization.git
cd metadata-harmonization

# Create and activate Python virtual environment
make createPythonEnvironment
source .venv/bin/activate

# Install all dependencies (Python packages, TypeScript packages, CDK, frontend)
make install

make install 命令使用 uv 将 processor、API、agent 和 evaluation 包安装为可编辑的 Python 包，并为 infrastructure 和 frontend 项目运行 npm install。

第二步：配置部署

复制配置模板并使用你的 AWS 账户详细信息进行编辑：

cp config.yaml.example config.yaml

appName: "metadata-harmonization-app"
env: "dev"

dev:
  profile: "your-aws-profile"
  deploymentName: "metadata-harmonization-dev"
  accountNumber: "123456789012"     # Your 12-digit AWS account number
  region: "us-east-1"
  deploymentStage: "dev"
  removalPolicy: "destroy"
  logLevel: "INFO"
  targetPlatform: "linux/amd64"

验证配置：

make validateConfig

第三步：部署基础设施

（仅首次）引导 AWS CDK，然后部署：

# First-time setup: prepare your AWS account for CDK
make bootstrap

# Deploy all AWS resources
make deploy

make deploy 构建 API 容器镜像，将其推送到 Amazon ECR，并部署 AWS CDK 堆栈。这会创建 Amazon DynamoDB 表、Amazon S3 存储桶、Amazon Cognito 用户池和 Amazon ECS Fargate 服务。

部署后，使用已部署的资源标识符生成本地 .env 文件：

make createLocalDotEnvFile

第四步：创建 Amazon Cognito 用户

部署后，在 Amazon Cognito 用户池中创建用户，以便他们可以登录应用：

打开 Amazon Cognito 控制台。

选择部署创建的用户池（例如 metadata-harmonization-users）。

进入 Users 并选择 Create user。

输入用户的电子邮件地址和临时密码。

用户首次登录时将提示设置永久密码。

第五步：本地运行 Web 应用

启动 API 服务器和 Next.js 前端：

# Run both API and frontend together (recommended)
make runLocal

或在单独的终端中运行：

# Terminal 1: API server
make runApiLocal

# Terminal 2: Frontend
make runUiLocal

访问系统：

Web 界面：http://localhost:3000

API 文档：http://localhost:8080/api/docs

第六步：运行元数据智能体

API 服务器运行后，打开第二个终端并运行智能体：

uv run metadata-agent validate data/synthetic_dataset/simple_test.csv --interactive

智能体通过 Model Context Protocol (MCP) 连接到 API，验证数据集，检索失败报告，并自主应用校正。

人工监督仍然是维护元数据质量和信任的核心。元数据校正与协调系统被设计为协作工作流，使数据贡献者能够控制其提交内容。界面提供即时反馈、推荐和可操作的校正建议，以便贡献者能够在保持数据完整性的同时高效验证和批准元数据。

UI 流程与交互

人在回路流程始于数据贡献者通过浏览器界面上传元数据文件。贡献者可以在本地检查和修改元数据，然后使用轻量级客户端工具进行提交前调整。准备就绪后，他们触发元数据处理，将数据集发送到云端进行自动验证和协调。工作流执行时，会出现两种结果之一：

验证通过，元数据与模式完全对齐并向下游发送以进行集成。

验证失败，生成缺失或不一致字段的详细推荐。

这些推荐直接在界面中呈现以供审查和校正。贡献者可以检查被标记的条目，审查 AI 生成的建议，并接受、编辑或拒绝它们。满意后，重新提交校正后的元数据以进行重新验证。成功的提交会自动确认并向下游传播，完成协调循环。

图 2：人在回路元数据校正工作流

每个循环都会减少人工工作，同时保留贡献者对最终输出的所有权。

以下视频演示了自动化和人工审查如何在一个精简的流程中共存。系统作为协作助手，而不是依赖研究人员花费数天进行手动元数据对齐，加速校正过程，同时帮助验证记录是否反映了贡献者的意图和领域专业知识。

标题："Metadata Upload and Validation Workflow" 一个 90 秒的演示，展示了通过浏览器界面进行元数据上传、验证和校正的完整端到端流程。

人在回路方法让研究人员获得了自动化的速度，同时又不放弃控制权。AI 生成的推荐通过界面呈现，但研究人员决定应用什么。这种协作模式建立对系统的信任，同时使领域特定知识在校正过程中保持核心地位。

智能体驱动的工作流

虽然人在回路系统大大加速了元数据协调，但它仍然需要贡献者积极参与审查推荐、接受校正和重新提交更新。对于涉及数百或数千条记录的数据集，这种人工工作量仍然很大。为了减少这种负担并让贡献者专注于研究而不是重复的元数据校正，工作流可以通过智能体驱动的自动化进行扩展。

从人工到智能体调解

在这个模型中，元数据智能体作为一个自主或半自主系统运行，能够分析、校正和验证元数据记录。它使用确定性和非确定性推理系统，从基于规则的逻辑到 Amazon Bedrock LLM 推理，以识别、解决和重新提交校正后的元数据。通过 MCP，智能体可以访问一组专用工具，包括远程元数据处理服务、模式验证器和基于嵌入的相似度模块。当被调用时，智能体可以触发验证、检索失败报告和 AI 生成的推荐，并根据上下文线索决定如何应用校正。

以下过程说明了智能体驱动的循环，它反映了人工工作流的相同结构，但用自主推理取代了直接的用户操作。

图 3：智能体驱动的操作流程

此配置允许系统以最少的人工干预跨大型数据集扩展元数据管理，同时保持可审计的更正日志。

上下文感知与组织智能体

对于高价值或特定领域的数据，单一通用智能体可能缺乏必要的上下文。为提高准确率，可以部署组织特定的智能体，每个智能体都能访问该团队的私有数据存储、实验日志和研究出版物。通过将全局上下文（如本体使用情况、实验方法和内部命名规范）嵌入到智能体的推理提示词中，元数据修正变得更加精确，也更符合本地数据标准。

该架构支持两个层次的适应：

本地推理：智能体利用当前数据集和历史提交记录推断缺失或模糊的字段。

上下文丰富：智能体从更广泛的组织知识（如论文、协议和受控词表）中获取信息，自动验证和填充元数据字段。

以下演示展示了智能体在终端界面中执行此工作流程。智能体通过 MCP 工具对元数据验证系统进行编程式交互，验证数据集、解释错误，并在重新提交前自主应用修正。

终端 1：启动 API 服务器

# From the project root
make runApiLocal

终端 2：运行智能体

# Validation demo (runs a predefined workflow)
uv run metadata-agent validate data/synthetic_dataset/simple_test.csv --interactive

标题："通过智能体实现自主元数据验证" 一段 1 分 38 秒的演示，展示了一个基于 ReAct 的智能体通过命令行交互执行端到端的元数据修正。

智能体驱动的工作流程将元数据修正从人工审核周期转向可扩展的、上下文感知的自动化。通过将确定性模式验证与基于 LLM 的推理以及受控的工具访问相结合，这些智能体在保持透明度和问责制的同时，减少了贡献者的重复性工作。结果是系统能够随着数据标准的变化而适应，并支持大规模、多组织的数据共享。

治理与合规注意事项

从概念验证走向生产环境，需要在整个开发生命周期中集成治理。以下四个方面值得特别关注。

数据完整性与变更追踪：组织应建立清晰的控制框架，说明元数据变更如何被记录和保留。科学可重复性取决于数据溯源的维护。如人工参与工作流程演示所示，系统提供按类型和来源分类的变更摘要，支持元数据提交期间的审核和批准。各机构应根据其监管环境定义保留策略、审计追踪要求和完整性控制措施。

架构治理：组织需要确定 AI 建议如何整合到其数据工作流程中，具体而言是修正需要在应用前获得批准，还是可以在事后审核后自动应用。这一决策影响数据完整性、回滚能力以及与机构数据政策的对齐。架构选择应记录清晰的依据，并设计为能够适应不断发展的标准和不断增长的数据量。

负责任的 AI 与内容安全：使用 LLM 推理的生产部署应集成 Amazon Bedrock Guardrails，以建立模型行为的边界，并防止提示词注入攻击——尤其是当来自外部源的元数据值直接传入模型提示词时。Guardrails 可配置为过滤有害内容、执行话题边界，以及应用接地验证。这使得 LLM 生成的修正建议锚定于工作流程定义的模式定义和受控词表。对于智能体驱动的部署，Guardrails 还可以根据每个智能体的自主操作边界进行验证，以帮助防止未经适当监督的意外修正被应用。

安全性：处理敏感基因组数据的 AI 系统必须满足与传统研究数据系统相同的安全标准。基于角色的访问控制、验证管道中的数据保护，以及（对于智能体驱动的工作流程）自主操作的边界，都应根据组织的风险概况进行评估。

为避免产生持续费用，请在完成后销毁所有已部署的 AWS 资源：

make destroy

这将拆除 AWS CDK 堆栈，包括 Amazon ECS 服务、Amazon DynamoDB 表、Amazon S3 存储桶和 Amazon Cognito 用户池。该命令在继续执行前会提示确认。

如果在 config.yaml 中将 removalPolicy 设置为 "retain"（生产环境推荐），某些资源将在堆栈删除后保留。请通过 AWS Management Console 或 AWS CLI 手动删除保留的 Amazon S3 存储桶和 Amazon DynamoDB 表。

要清除本地构建产物：

make clean

这里介绍的 AI 驱动元数据修正与协调系统解决了生物医学研究中的一个持久挑战：将时间花在数据标准化而不是科学工作上。两种实现方法——人工参与验证和智能体驱动的工作流程——为处于不同 AI 采用阶段的组织提供了灵活性。团队可以从监督修正开始，建立对系统的信任，然后随着信任的增长逐步过渡到更自动化的方法。

该系统有助于减少阻碍跨组织协作的摩擦。云原生架构随组织规模扩展，模块化设计允许定制以满足特定的机构需求。随着数据量持续增长，自动化元数据协调在组织扩展过程中变得越来越重要。请访问我们的 GitHub 仓库开始使用该解决方案。