O problema de rastreabilidade em ML de produção
Equipes de machine learning (ML) em produção frequentemente se deparam com uma pergunta simples que se transforma em uma investigação de dias: “quais dados treinaram o modelo que está em produção agora?” Sem uma cadeia de rastreabilidade bem definida, a resposta exige vasculhar logs espalhados, notebooks e buckets do Amazon Simple Storage Service (Amazon S3) — um processo lento e propenso a erros.
Esse problema é ainda mais crítico em setores regulados, como saúde, serviços financeiros e veículos autônomos. Nesses contextos, auditorias exigem que modelos em produção estejam vinculados aos dados exatos que os treinaram, e registros individuais podem precisar ser excluídos de treinamentos futuros mediante solicitação.
Para endereçar esse desafio, a AWS publicou um guia técnico mostrando como combinar três ferramentas em um único fluxo de trabalho rastreável:
Como a arquitetura funciona
A solução integra as três ferramentas de forma que cada modelo possa ser rastreado até seus dados de treinamento exatos. Cada ferramenta tem um papel distinto:
- DVC: armazena metafiles
.dvc leves no Git, enquanto os dados reais ficam no Amazon S3
- Amazon SageMaker AI: orquestra jobs de processamento, treinamento e hospedagem do modelo
- SageMaker AI MLflow App: registra parâmetros, métricas, artefatos e modelos versionados
O fluxo de dados percorre quatro estágios principais. Primeiro, um job de processamento do SageMaker AI pré-processa os dados brutos e versiona o dataset resultante com o DVC, enviando os dados para o S3 e os metadados para um repositório Git. Em seguida, um job de treinamento clona o repositório DVC em uma tag Git específica, executa dvc pull para recuperar o dataset versionado exato e treina o modelo. Cada execução de treinamento registra o data_git_commit_id — o hash do commit DVC que aponta para o dataset exato no S3. Por fim, o modelo treinado é registrado no MLflow Model Registry e pode ser implantado em um endpoint do SageMaker AI.
O resultado é uma cadeia de rastreabilidade completa: Modelo em Produção → Execução MLflow → Commit DVC → Dataset exato no Amazon S3.
Como DVC e MLflow se complementam
O ponto central dessa arquitetura é que o DVC e o MLflow resolvem metades diferentes do problema de linhagem — e juntos fecham o ciclo.
O DVC (Controle de Versão de Dados) é uma ferramenta gratuita e de código aberto que estende o Git para lidar com grandes datasets e artefatos de ML. O Git sozinho não consegue gerenciar arquivos binários grandes sem tornar os repositórios lentos e pesados. O DVC resolve isso rastreando metafiles .dvc leves no Git (ponteiros endereçáveis por conteúdo), enquanto os dados reais ficam em armazenamento remoto como o Amazon S3. Isso oferece semântica de versionamento similar ao Git — branches, tags, diffs — para datasets de gigabytes ou terabytes.
Em termos de eficiência de armazenamento, o DVC usa armazenamento endereçável por conteúdo com hashes MD5. Isso significa que apenas arquivos novos ou modificados são armazenados — se você adicionar mil imagens a um dataset existente, somente essas novas imagens são enviadas ao S3. Arquivos com conteúdo idêntico são armazenados uma única vez, mesmo que apareçam com nomes diferentes ou em versões distintas do dataset.
Além do versionamento de dados, o DVC também suporta pipelines de dados reproduzíveis, gerenciamento de experimentos e pode funcionar como um registro de dados para compartilhamento entre equipes. Nessa arquitetura, porém, o foco é exclusivamente no versionamento de dados.
O SageMaker AI MLflow App é um serviço totalmente gerenciado da AWS, disponível dentro do SageMaker AI Studio, para gerenciar o ciclo de vida completo de ML e IA generativa. Suas capacidades incluem rastreamento de experimentos, registro de modelos com versionamento e gerenciamento de ciclo de vida, avaliação de modelos e integrações de implantação.
A separação de responsabilidades é clara: o DVC cuida da linhagem dados→treinamento, o MLflow cuida da linhagem treinamento→implantação, e o hash do commit Git é o elo que os conecta.
Padrão 1: Linhagem em nível de dataset
O primeiro padrão demonstra o fluxo central usando o dataset de classificação de imagens CIFAR-10, simulando um cenário comum de expansão progressiva de dados rotulados:
- v1.0: processamento e treinamento com 5% dos dados (~2.250 imagens de treino)
- v2.0: processamento e treinamento com 10% dos dados (~4.500 imagens de treino)
Para cada versão, o pipeline executa dois passos. No Passo 1, um job de processamento do SageMaker AI baixa o CIFAR-10, faz a amostragem configurada, divide em conjuntos de treino/validação/teste e versiona o resultado com DVC. O job recebe a URL do repositório DVC e o URI de rastreamento do MLflow como variáveis de ambiente:
processor_v1 = FrameworkProcessor(
image_uri=processing_image,
role=role,
instance_type="ml.m5.xlarge",
instance_count=1,
env={
"DVC_REPO_URL": dvc_repo_url,
"DVC_REPO_NAME": dvc_repo_name,
"MLFLOW_TRACKING_URI": mlflow_app_arn,
"MLFLOW_EXPERIMENT_NAME": experiment_name,
"PIPELINE_RUN_ID": pipeline_run_id_v1,
}
)
processor_v1.run(
code="preprocessing_foundational.py",
source_dir="../source_dir",
arguments=[
"--data-fraction", str(data_fraction_v1),
"--data-version", data_version_v1,
"--val-split", "0.1"
],
wait=True
)
Dentro do script de processamento, o dataset é versionado com DVC e o hash do commit é registrado no MLflow:
def version_with_dvc(repo_path, version_tag, pipeline_run_id):
"""Add data to DVC and push to remote."""
subprocess.check_call(["dvc", "add", "dataset"], cwd=repo_path)
subprocess.check_call(["git", "add", "dataset.dvc", ".gitignore"], cwd=repo_path)
subprocess.check_call(
["git", "commit", "-m", f"Add dataset version {version_tag}"],
cwd=repo_path
)
subprocess.check_call(["git", "tag", pipeline_run_id], cwd=repo_path)
subprocess.check_call(["dvc", "push"], cwd=repo_path)
subprocess.check_call(["git", "push", "origin", "main"], cwd=repo_path)
subprocess.check_call(["git", "push", "origin", pipeline_run_id], cwd=repo_path)
commit_id = subprocess.check_output(
["git", "rev-parse", "HEAD"], cwd=repo_path
).decode().strip()
return commit_id
No Passo 2, um job de treinamento clona o repositório DVC na tag exata do Passo 1, executa dvc pull para baixar o dataset versionado e faz o fine-tuning de um modelo MobileNetV3-Small pré-treinado. A ponte de linhagem — o registro do hash do commit DVC no MLflow — acontece no script de treinamento:
# Fetch data: clone DVC repo at the exact tag, then dvc pull
data_git_commit_id = fetch_data_from_dvc()
with mlflow.start_run(run_name=run_name) as run:
mlflow.log_params({
"data_version": data_version,
"data_git_commit_id": data_git_commit_id, # <-- the lineage bridge
"dvc_repo_url": dvc_repo_url,
"model_architecture": "mobilenet_v3_small",
"epochs": args.epochs,
"learning_rate": args.learning_rate,
# ...
})
Com esse padrão, é possível responder perguntas como: “qual versão do dataset treinou este modelo?”, “consigo reproduzir os dados de treinamento?” e “por que a performance do modelo mudou entre versões?”. Os modelos treinados são automaticamente registrados no MLflow Model Registry com histórico de versões e links para a execução de treinamento que os gerou. Com a integração entre o SageMaker AI MLflow App e o SageMaker AI Model Registry, o MLflow também registra automaticamente o modelo no Model Registry do SageMaker AI.
O notebook também demonstra a implantação do modelo recomendado (v2.0, treinado com mais dados) do MLflow Model Registry para um endpoint de inferência em tempo real do SageMaker AI usando o ModelBuilder. Após a implantação, é possível invocar o endpoint com bytes de imagem bruta e obter predições de classe.
Padrão 2: Linhagem em nível de registro (conformidade em saúde)
O segundo padrão estende o padrão fundacional para ambientes regulados, adicionando rastreabilidade em nível de registro individual por meio de manifestos e registros de consentimento.
A adição do manifesto
A diferença central é um manifesto: um arquivo CSV estruturado que lista cada registro individual em cada versão do dataset:
patient_id,scan_id,file_path,split,label
PAT-00001,PAT-00001-SCAN-0001,train/normal/00042.png,train,normal
PAT-00023,PAT-00023-SCAN-0015,train/tubercolosis/00015.png,train,tubercolosis
...
Esse manifesto é salvo dentro do diretório do dataset versionado pelo DVC e registrado como artefato do MLflow em cada execução de treinamento. Isso torna os registros individuais consultáveis diretamente no MLflow, sem precisar baixar o dataset completo do DVC.
O registro de consentimento e o fluxo de opt-out
O fluxo é orientado por um registro de consentimento — um arquivo CSV listando cada paciente e seu status de consentimento. Em produção, isso seria um banco de dados com commits transacionais e trilha de auditoria própria. O job de processamento lê esse registro e inclui apenas registros com consent_status == "active". O código de processamento é idempotente: um opt-out é simplesmente uma mudança de entrada que produz um dataset novo e limpo quando o mesmo pipeline é executado novamente.
O notebook demonstra um ciclo completo de opt-out:
- v1.0 — Baseline: processamento e treinamento com todos os pacientes com consentimento ativo. O manifesto lista todos os exames. O modelo é registrado no MLflow com o manifesto como artefato.
- Evento de opt-out: o paciente PAT-00023 solicita exclusão. O status de consentimento é atualizado para
revoked no registro, e o registro atualizado é enviado ao S3.
- v2.0 — Dataset limpo: o mesmo job de processamento roda com o registro atualizado. As imagens de PAT-00023 são automaticamente excluídas. O DVC versiona o novo dataset. O modelo é retreinado e registrado como nova versão no MLflow.
- Verificação de auditoria: consultas ao MLflow confirmam que PAT-00023 aparece apenas no modelo v1.0 e está ausente dos modelos treinados após a data de opt-out.
Consultas de auditoria
O módulo utils/audit_queries.py do repositório fornece três funções de consulta que operam baixando artefatos de manifesto do MLflow:
find_models_with_patient("PAT-00023") — busca execuções de treinamento que incluem um paciente. Retorna apenas a execução v1.0.verify_patient_excluded_after_date("PAT-00023", "2025-06-01") — verifica modelos treinados após uma data e confirma a ausência do paciente. Retorna PASSED ou FAILED com detalhes.get_patients_in_model(run_id) — lista os IDs de pacientes nos dados de treinamento de um modelo específico.
from utils.audit_queries import find_models_with_patient
# "Which models were trained on this patient's data?"
find_models_with_patient("PAT-00023", experiment_name="demo-cxr-mlflow-dvc")
Essas consultas não exigem um checkout do DVC — elas operam inteiramente sobre artefatos do MLflow, sendo rápidas o suficiente para respostas interativas de auditoria. Para produção em escala, a recomendação é escrever tuplas (record_id, run_id, data_version) no Amazon DynamoDB no momento do treinamento, apontar o Amazon Athena para o prefixo de artefatos do MLflow no S3, ou usar um AWS Lambda pós-treinamento para popular um índice.
Embora o exemplo use terminologia de saúde, o padrão se aplica a outros domínios que exigem rastreabilidade em nível de registro: serviços financeiros, moderação de conteúdo com conteúdo enviado por usuários, ou qualquer sistema de ML sujeito a solicitações de exclusão de dados.
Boas práticas e considerações de segurança
O fluxo integrado cria rastreabilidade em três camadas:
- Camada Git + DVC: cada versão do dataset é uma tag Git apontando para um commit DVC. Executar
git checkout <tag> && dvc pull restaura os dados processados exatos.
- Camada MLflow: cada execução de treinamento registra o
data_git_commit_id, vinculando o modelo à versão de dados DVC. O manifesto de nível de registro (quando usado) torna registros individuais consultáveis.
- Camada Model Registry: cada versão de modelo registrada está vinculada à sua execução de treinamento, que está vinculada à sua versão de dados.
Para implantações em ambientes regulados (HIPAA, FDA 21 CFR Part 11, GDPR), a AWS recomenda adicionar controles em nível de infraestrutura:
- S3 Object Lock (modo de conformidade) nos remotes DVC e nos armazenamentos de artefatos do MLflow
- AWS CloudTrail para registro independente e append-only de acessos
- Políticas de Gerenciamento de Identidade e Acesso (IAM) com privilégio mínimo para buckets de produção, servidores de rastreamento MLflow e repositórios Git
- Criptografia em repouso usando o AWS Key Management Service (AWS KMS)
Otimizando a iteração
Para acelerar experimentos repetidos, dois recursos do SageMaker AI são recomendados:
- SageMaker Managed Warm Pools — mantém instâncias de treinamento aquecidas entre jobs, reutilizando infraestrutura já provisionada. Basta adicionar
keep_alive_period_in_seconds à configuração de Compute. Esse recurso se aplica apenas a jobs de treinamento, não de processamento.
- SageMaker AI Pipelines — orquestra o fluxo processamento → treinamento → registro como um pipeline único e repetível. Os pipelines gerenciam dependências entre etapas, passam artefatos automaticamente e podem ser disparados programaticamente — por exemplo, quando um paciente faz opt-out e o manifesto é atualizado.
Pré-requisitos e limpeza
Para seguir o guia, são necessários: uma conta AWS com permissões para Amazon SageMaker (Processing, Training, MLflow Apps, Endpoints), Amazon S3, AWS CodeCommit e Gerenciamento de Identidade e Acesso (IAM); Python 3.11 ou 3.12; e o SageMaker Python SDK v3.4.0 ou posterior. O repositório de acompanhamento inclui um requirements.txt com todas as dependências.
Os notebooks usam o AWS CodeCommit como backend Git para metadados do DVC, mas o DVC funciona com outros provedores Git (GitHub, GitLab, Bitbucket). Basta substituir a URL do git remote add origin e configurar as credenciais adequadas — por exemplo, armazenando tokens no AWS Secrets Manager e buscando-os em tempo de execução, ou usando o AWS CodeConnections.
Para evitar cobranças contínuas, é importante excluir os recursos criados ao final dos testes: o endpoint do SageMaker AI, o MLflow App (opcional), o repositório do AWS CodeCommit e os dados no S3. O principal gerador de custos é o endpoint de inferência em tempo real do SageMaker AI — ele deve ser excluído imediatamente após os testes.
Conclusão
A abordagem demonstrada pela AWS combina DVC para versionamento de dados, Amazon SageMaker AI para treinamento e orquestração escaláveis, e SageMaker AI MLflow Apps para rastreamento de experimentos e registro de modelos. Os resultados principais são:
- Reprodutibilidade completa: modelos podem ser rastreados até seus dados de treinamento exatos via hashes de commit DVC armazenados no MLflow.
- Linhagem em nível de registro: o padrão de manifesto permite consultar quais registros individuais treinaram um determinado modelo — essencial para conformidade com opt-out e respostas a auditorias.
- Alinhamento de conformidade sem estado: o padrão de registro de consentimento trata exclusões de registros como mudanças de entrada, sem alterar o código de processamento.
- Comparação de experimentos: o MLflow oferece comparação lado a lado de modelos treinados em versões diferentes de dados, com rastreamento completo de parâmetros e métricas.
Os dois notebooks disponíveis no repositório GitHub de acompanhamento são implantáveis diretamente. O padrão fundacional atende equipes que precisam de rastreabilidade em nível de dataset. O padrão de conformidade em saúde o estende para ambientes regulados que exigem trilhas de auditoria em nível de registro. Ambos compartilham o mesmo código de treinamento e arquitetura do SageMaker AI. Para aprofundar no versionamento com DVC, o guia Versionando Dados e Modelos é o ponto de partida recomendado.
Fonte
End-to-end lineage with DVC and Amazon SageMaker AI MLflow apps (https://aws.amazon.com/blogs/machine-learning/end-to-end-lineage-with-dvc-and-amazon-sagemaker-ai-mlflow-apps/)
