Lineage ponta a ponta com DVC e SageMaker AI MLflow Apps

Time de ML em produção sofre pra rastrear a linhagem completa de um modelo: qual código treinou, qual versão exata do dataset foi consumida, quais métricas de experimento justificaram o deploy. Sem isso, perguntas tipo "qual dado treinou o modelo que tá em prod?" ou "consegue reproduzir o modelo que subimos 6 meses atrás?" viram investigação de vários dias em logs espalhados, notebooks e buckets S3.

O problema aperta em setor regulado — saúde, financeiro, veículo autônomo — onde auditoria exige link entre modelo deployado e dado exato de treino, e registros individuais podem precisar sair de treinos futuros sob pedido.

As três peças

• DVC (Data Version Control): versiona dataset e artefato, linkando com commit Git. Guarda .dvc metafiles leves no Git e o dado real no S3.
• Amazon SageMaker AI: compute escalável pra processing, training e hosting.
• SageMaker AI MLflow App: experiment tracking, model registry, lineage. Gerenciado pela AWS dentro do SageMaker Studio.

A ideia: DVC cobre a ponta dado → treino, MLflow cobre treino → deploy, e o hash do commit Git costura tudo.

Como o fluxo roda

1. Um Processing job do SageMaker AI faz preprocessing do dado cru e versiona o dataset processado com DVC, empurrando o dado pro S3 e o metadado pro repositório Git.
2. Um Training job clona o repositório DVC numa tag Git específica, roda dvc pull pra puxar o dataset versionado exato, treina o modelo e loga tudo no MLflow.
3. Cada run de treino registra o data_git_commit_id, que é o hash do commit DVC apontando pro dataset no S3.
4. Modelo treinado entra no MLflow Model Registry e vai pra endpoint do SageMaker AI.

Cadeia completa: Production Model → MLflow Run → DVC commit → dataset exato no S3.

Por que DVC + MLflow juntos

Git sozinho não lida com binário grande — repo incha e o GitHub bloqueia arquivo acima de 100 MB. DVC resolve com storage content-addressable (hash MD5): só arquivo novo ou modificado sobe. Adicionar 1.000 imagens novas a um dataset existente só manda essas 1.000 pro S3, o resto não re-upa.

O MLflow traz o que DVC tem mais fraco: model registry maduro com versioning, aliases pra lifecycle e integração de deploy. Separação limpa de responsabilidade.

Na prática, pra quem já roda SageMaker e tá montando governança de MLOps do zero, esse stack faz sentido sem adicionar fornecedor novo — DVC é open source e os dois outros já estão na casa.

Padrão 1: lineage em nível de dataset

O notebook foundational simula cenário comum: começar com dado rotulado limitado e expandir ao longo do tempo. Usa CIFAR-10 em dois experimentos:

• v1.0: treina com 5% do dado (~2.250 imagens)
• v2.0: treina com 10% do dado (~4.500 imagens)

Pra cada versão, o pipeline roda Processing job (baixa CIFAR-10, amostra, splita train/val/test, versiona com DVC) e depois Training job (clona repo DVC na tag exata, roda dvc pull, fine-tuna MobileNetV3-Small e loga no MLflow).

A ponte de lineage tá dentro do script de treino:

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,  # <-- a ponte de lineage
        "dvc_repo_url": dvc_repo_url,
        "model_architecture": "mobilenet_v3_small",
        # ...
    })

No MLflow UI você compara curva de acurácia entre versões, hiperparâmetro e o data_git_commit_id que linka cada modelo ao seu dataset DVC. O modelo treinado entra automaticamente no MLflow Model Registry, e por integração com SageMaker AI Model Registry, também no registry nativo.

Responde: qual versão treinou esse modelo, dá pra reproduzir, por que a performance mudou. Não responde: o registro X estava nesse treino?

Padrão 2: lineage em nível de registro (compliance em saúde)

Esse padrão estende o primeiro pra ambiente regulado onde você precisa rastrear registro individual. A adição chave é o manifest: um CSV estruturado listando cada registro 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

O manifest fica dentro do dataset versionado com DVC e é logado como artefato MLflow a cada run. Resultado: registro individual consultável direto do MLflow sem puxar o dataset inteiro.

O fluxo é guiado por um consent registry — CSV listando cada paciente e seu status de consentimento. Em produção viraria banco com transacional e audit trail próprio. O processing code é idempotente: filtra consent_status == "active" e processa o que sobra. Opt-out vira mudança de input que gera dataset novo e limpo no mesmo pipeline.

O ciclo de opt-out

1. v1.0 baseline: treina com todos os pacientes consentidos.
2. Evento de opt-out: paciente PAT-00023 pede pra sair. Status vira revoked no registry.
3. v2.0 dataset limpo: mesmo processing job roda com registry atualizado. Imagens do PAT-00023 saem automaticamente. Novo modelo registrado no MLflow.
4. Verificação de auditoria: query no MLflow confirma que PAT-00023 aparece só no modelo v1.0.

O módulo utils/audit_queries.py traz três funções que rodam baixando o manifest do MLflow — sem checkout do DVC:

• find_models_with_patient("PAT-00023") — quais modelos treinaram com esse paciente
• verify_patient_excluded_after_date(...) — PASSED/FAILED automático pra auditoria
• get_patients_in_model(run_id) — lista registros num modelo específico

Nota importante de produção: essas queries baixam o manifest.csv de cada training run e escaneiam. Funciona pra poucos runs, não escala. Em produção, gravar tuplas (record_id, run_id, data_version) em DynamoDB no momento do treino, apontar Athena pro prefix de artefatos MLflow no S3, ou usar Lambda pós-treino pra popular índice.

Considerações de segurança em ambiente regulado

DVC e MLflow dão rastreabilidade mas não são tamper-evident sozinhos. Pra deploy HIPAA, FDA 21 CFR Part 11, GDPR, empilha controle de infra:

• S3 Object Lock em compliance mode nos remotes DVC e nos artifact stores MLflow, pra evitar modificação ou delete de dado versionado
• AWS CloudTrail pra log append-only independente de acesso a storage e training
• IAM com least-privilege em bucket de prod, tracking server MLflow e repo Git
• Encryption at rest com KMS nos buckets S3

Acelerando iteração

• SageMaker Managed Warm Pools: mantém instância quente entre jobs de treino consecutivos. Adiciona keep_alive_period_in_seconds no Compute config. Só vale pra training, não processing.
• SageMaker AI Pipelines: orquestra processing → training → registration como pipeline único e repetível. Dispara programaticamente (ex: quando paciente faz opt-out e manifest atualiza).

Conclusão

Os dois notebooks no repo companheiro são deployáveis como estão. O padrão foundational serve time que precisa de lineage em nível de dataset. O padrão healthcare compliance estende pra ambiente regulado com audit trail de registro. Os dois compartilham o mesmo código de treino SageMaker AI e mesma arquitetura.

Mesma lógica funciona além de saúde: serviços financeiros, moderação de conteúdo, qualquer sistema ML sujeito a pedido de deleção de dado.