Série PMLE - 3 de 5
Publicado a 16 de abril de 2026
É fácil produzir um modelo que funciona num notebook. O problema começa quando perguntas se esse treino é reproduzível, se a avaliação mede a coisa certa e se alguém além de ti consegue perceber que versão do modelo foi realmente aprovada.
Neste artigo
- Do notebook ao processo reproduzível
- Linha de base, reprodutibilidade e artefactos
- Low-code, AutoML ou treino personalizado?
- Escolher métricas e validação
- Validação temporal
- Afinação, escalabilidade e custo
- Escolha de hardware para treino
- Registo, linhagem e promoção
- Prontidão para inferência
- Explicabilidade e confiança operacional
- Robustez e IA responsável no treino
- Heurísticas de exame
- O que precisas de saber para o exame
O notebook não é o produto
A PMLE assume que sabes trabalhar num notebook, mas também assume que percebes as limitações desse ambiente. Notebooks são excelentes para exploração, iteração rápida, validação de hipóteses e análise de erros. São péssimos como fonte única de verdade para um sistema que precisa de ser repetível. O exame tende a distinguir bem estas duas fases.
Em Vertex AI Workbench ou em qualquer ambiente semelhante, a pergunta certa é: quando é que esta exploração deixa de ser uma investigação e passa a ser um processo de treino que outra pessoa pode correr outra vez, com as mesmas entradas, os mesmos artefactos e critérios claros de avaliação?
Explorar
Entender os dados, formular hipóteses, inspecionar erros e perceber se o problema é tratável.
Formalizar
Fixar conjuntos de dados, pipelines, métricas, sementes aleatórias, parâmetros e critérios de avaliação.
Comparar
Executar experiências comparáveis, registar resultados e evitar conclusões oportunistas.
Promover
Versionar, aprovar e ligar o modelo aos mecanismos de inferência e monitorização.
Linha de base, reprodutibilidade e artefactos
O primeiro modelo sério não deve ser o mais sofisticado. Deve ser a linha de base que permite perceber se qualquer melhoria posterior é real. Na PMLE, esta é uma heurística poderosa: se o enunciado fala em equipa sem ponto de comparação, métricas soltas ou afinação antes de uma referência simples, a resposta mais madura costuma ser criar uma linha de base reproduzível antes de complicar.
Linha de base não significa modelo fraco. Significa modelo controlado: dados fixados, divisão justificada, métrica escolhida, parâmetros registados e resultado comparável. Pode ser uma regra simples, BigQuery ML, AutoML ou um modelo personalizado com valores predefinidos. O importante é que exista uma linha de base contra a qual o candidato, o modelo campeão atual ou a próxima versão possam ser avaliados.
Reproduzibilidade
Sementes aleatórias, versões de bibliotecas, divisão dos dados, imagem/contentor, dados de treino e código das variáveis não podem ficar implícitos.
Artefactos
O treino deve exportar o modelo, checkpoints, registos e métricas para localizações persistentes, normalmente em Cloud Storage.
Promoção
Um modelo só deve avançar se superar a linha de base em métricas relevantes e se puder ser servido no ambiente de produção.
Em treino personalizado no Vertex AI, a disciplina operacional aparece em detalhes concretos. O código não deve inferir o projeto por acaso; deve usar configuração explícita ou variáveis como CLOUD_ML_PROJECT_ID. Se definires baseOutputDirectory, Vertex AI disponibiliza diretórios especiais como AIP_MODEL_DIR para artefactos do modelo, AIP_CHECKPOINT_DIR para checkpoints e AIP_TENSORBOARD_LOG_DIR para registos do TensorBoard. Para tarefas longas, a documentação recomenda guardar progresso periodicamente, porque as VMs podem reiniciar.
Low-code, AutoML ou treino personalizado?
Tal como nos dados, aqui importa o nível de abstração. Nem todo o problema exige treino personalizado. Às vezes, BigQuery ML ou serviços low-code do Vertex AI chegam. Noutras situações, precisas de controlo fino sobre arquitetura, hiperparâmetros, distribuição do treino, artefactos ou integração com o resto do pipeline. O exame gosta desta decisão porque ela mistura engenharia com pragmatismo.
A regra é subir de complexidade apenas quando o requisito dominante o exige: dependências especiais, arquitetura própria, código de treino não suportado por contentores geridos, controlo de exportação, treino distribuído, ou integração explícita com pipelines e registo de modelos.
| Caminho | Quando faz sentido | Principal compromisso |
|---|---|---|
| BigQuery ML | Dados já estão no BigQuery, problema tabular, equipa quer SQL, linha de base rápida e baixa sobrecarga técnica. | Menos controlo sobre arquitetura, ambiente de execução e inferência avançada. |
| AutoML / caminhos geridos | Quando queres acelerar a linha de base e reduzir a sobrecarga técnica em tabular, imagem, texto ou previsão suportada. | Podes perder transparência, controlo fino e liberdade de personalização. |
| Aprendizagem por transferência | Quando tens um modelo pré-treinado relevante e dados insuficientes para treinar do zero. Comum em visão, processamento de linguagem natural e, agora, em cenários com modelos fundacionais. | O modelo base pode introduzir viés ou limitações de domínio que não controlas totalmente. |
| Treino personalizado com contentor gerido | TensorFlow, PyTorch, scikit-learn ou XGBoost com dependências compatíveis com contentores pré-configurados. | Mais responsabilidade sobre código, artefactos, métricas e testes. |
| Contentor personalizado | Framework, ambiente de execução, bibliotecas, sistema operativo ou binários que não cabem num contentor gerido. | Maior controlo, mas também mais manutenção, segurança e depuração. |
| Pipeline de treino | Quando o treino deve produzir e importar automaticamente um modelo para Vertex AI como parte de um fluxo repetível. | Exige desenho MLOps mais explícito, mas reduz passos manuais. |
Avaliação: medir a coisa certa, não a mais confortável
Muitas perguntas da PMLE vivem aqui. A certificação espera que saibas ler métricas e, mais importante, que saibas quando uma métrica está a mascarar o objetivo real. A taxa de acerto pode ser irrelevante em classes desequilibradas. Uma boa perda de treino pode ser inútil se a métrica de negócio ou a robustez de produção contam outra história. Em IA generativa, isto torna-se ainda mais evidente, mas já nos modelos clássicos a regra vale: avaliação é desenho de critério, não só cálculo.
Além disso, avaliação séria implica separar conjuntos corretamente, evitar fuga de informação, fazer análise de erro e manter rastreabilidade sobre as experiências. Não basta saber qual foi a melhor métrica final; tens de saber em que dados foi medida, com que transformações e que versão do pipeline/modelo a produziu.
Também tens de saber comparar. Um modelo candidato deve ser avaliado contra uma linha de base ou um modelo campeão real, não contra uma sensação de melhoria. Em Vertex AI Model Evaluation, o fluxo típico é: treinar ou registar o modelo, gerar previsões por lote, comparar essas previsões com a verdade de referência, executar a avaliação e analisar métricas entre versões. Esta ideia aparece no exame como governança: a promoção para produção deve ter evidência, não entusiasmo.
| Tipo de problema | Métricas que tendem a importar | Armadilha comum |
|---|---|---|
| Classificação equilibrada | Taxa de acerto, F1, AUC, matriz de confusão | Assumir que a taxa de acerto basta quando os custos de erro não são simétricos. |
| Classificação desequilibrada | Precisão, revocação, PR-AUC, afinação do limiar, matriz de confusão por classe | Celebrar uma taxa de acerto elevada num conjunto de dados onde a classe dominante explica quase tudo. |
| Regressão | MAE, RMSE, MAPE, erro por segmento | Usar uma métrica média que esconde falhas em segmentos críticos. |
| Ranking / recomendação | NDCG, MAP, revocação@k, cobertura | Avaliar como classificação simples e perder a noção da ordenação. |
Quando a precisão domina
Falsos positivos são caros ou perigosos: deteção de fraude com bloqueio automático, revisão humana limitada, ações corretivas dispendiosas.
Quando a revocação domina
Falhar um caso real é mais grave do que rever alguns falsos positivos: alertas médicos, incidentes críticos, triagem de risco.
Quando o limiar é a verdadeira decisão
O modelo está bom, mas a política de decisão ainda não. O exame gosta de respostas que ajustam o limiar em vez de pedir logo novo modelo.
Quando a divisão é o problema
Se há dependência temporal ou por entidade, a validação errada pode fabricar confiança onde não existe generalização.
Quando a calibração importa
Se a decisão usa probabilidades como risco, preço ou prioridade, não basta ordenar bem. A confiança prevista tem de corresponder à frequência real.
Quando a equidade muda a resposta
Se o enunciado menciona grupos sensíveis, populações pequenas ou impacto desigual, avalia por segmento antes de promover.
Validação cruzada, sobreajuste e promoções prematuras
Nem todos os problemas aceitam o mesmo desenho de validação. A validação cruzada padrão pode ser boa em dados i.i.d.; séries temporais pedem separação cronológica; grupos exigem divisões por identidade. Ao mesmo tempo, tens de reconhecer sinais de sobreajuste: diferença treino-validação demasiado grande, degradação fora do conjunto de desenvolvimento, sensibilidade excessiva a pequenas mudanças na divisão dos dados.
Na lógica da certificação, avaliar bem é também saber quando não promover um modelo que parece melhor só porque ganhou por uma margem frágil ou por uma configuração de validação demasiado favorável.
Quando detetar sobreajuste, a resposta nem sempre é “mais dados”. Técnicas de regularização — L1 (esparsidade), L2 (pesos pequenos), dropout (redes neuronais) ou paragem antecipada (parar o treino quando a validação para de melhorar) — são respostas frequentes em cenários de exame onde o modelo memoriza em vez de generalizar.
Em dados por entidade, como cliente, paciente, dispositivo ou conta, o erro clássico é deixar a mesma entidade aparecer em treino e validação. Isto dá uma métrica bonita, mas mede memorização de identidade. Em classes desequilibradas, o erro clássico é tentar resolver tudo com taxa de acerto: muitas vezes precisas de pesos de classe, reamostragem, afinação do limiar, PR-AUC e análise de erros por classe.
Validação temporal: a armadilha silenciosa
Se os teus dados têm componente temporal (séries temporais, eventos de utilizador, transações), aplicar validação cruzada k-fold padrão é uma das armadilhas mais consistentes do exame. O k-fold padrão baralha os dados e mistura futuro com passado, criando fuga de informação temporal que infla métricas artificialmente.
A solução correta é validação cronológica: treinar com dados mais antigos, validar com dados mais recentes, nunca o contrário. Isto simula o que realmente acontece em produção, onde o modelo só vê dados futuros.
Afinação de hiperparâmetros e treino distribuído
O currículo oficial também aponta para cenários em que o treino precisa de escalar. Isso inclui afinação de hiperparâmetros e, em certos casos, treino distribuído. Não é obrigatório decorar todas as estratégias possíveis ao nível mais baixo, mas tens de perceber o racional: quando vale a pena distribuir, quando o estrangulamento está nos dados, quando a afinação ajuda de facto, e quando estás a gastar recursos para extrair ganhos marginais.
Ou seja, a PMLE tende a premiar respostas que equilibram desempenho, custo, tempo e complexidade. Um pipeline elegante mas impraticável em produção não costuma ser a resposta certa.
No caso do treino distribuído, convém distinguir duas abordagens: paralelismo de dados, em que cada nó de treino trabalha com um subconjunto dos dados e os gradientes são agregados, e paralelismo de modelo, em que diferentes partes do modelo são distribuídas por vários dispositivos. O paralelismo de dados é a abordagem mais comum no Vertex AI para escalar treino padrão. O paralelismo de modelo costuma ser relevante quando o modelo é demasiado grande para caber em memória num único acelerador, cenário que aparece sobretudo com modelos fundacionais.
Em Vertex AI HyperparameterTuningJob, cada ensaio executa o teu código com argumentos diferentes. O código deve interpretar esses argumentos e comunicar a métrica a otimizar, tipicamente com a biblioteca cloudml-hypertune. Se o código não comunica a métrica certa, o serviço consegue gastar dinheiro a otimizar o número errado.
| Intervenção | Quando tentar primeiro | Sinal de que é distração |
|---|---|---|
| Melhorar dados/variáveis | Fuga de informação, valores em falta, desvio treino-inferência, deriva, baixa cobertura ou rótulos ruidosos. | A equipa quer afinação sem corrigir o conjunto de dados. |
| Linha de base mais simples | Não há referência comparável ou o modelo atual é difícil de explicar. | Já existe um modelo campeão sólido e a limitação é capacidade do modelo. |
| Afinação de hiperparâmetros | Pipeline e validação estão estáveis, mas há parâmetros com impacto provável. | Conjunto de dados pequeno, divisão errada ou métrica desalinhada com o objetivo. |
| Treino distribuído | Conjunto de dados/modelo grande, treino lento, código preparado para distribuição. | O estrangulamento é I/O, pré-processamento ou código que não paraleliza. |
| Estratégia | Quando ajuda | Onde pode falhar |
|---|---|---|
| Pesquisa em grelha | Espaço pequeno e controlado, poucos parâmetros. | Explode rapidamente em custo combinatório. |
| Pesquisa aleatória | Boa cobertura prática quando poucos parâmetros dominam o resultado. | Pode desperdiçar execuções se o espaço estiver mal definido. |
| Abordagens mais inteligentes / bayesianas | Quando cada treino é caro e queres usar melhor o orçamento. | Não compensa se o problema nem sequer estiver bem formulado ou a linha de base ainda for fraca. |
Reduction Server no Vertex AI
Para treino distribuído em escala, Vertex AI oferece o Reduction Server — um serviço que coordena a agregação de gradientes entre múltiplos nós de trabalho em paralelismo de dados. O detalhe operacional que o exame testa: Vertex AI permite configurar vários conjuntos de nós de trabalho (worker pools): Pool 0 = nó principal, Pool 1 = nós de trabalho, Pool 2 = servidores de parâmetros/redutores. O Pool 2 tipicamente não precisa de GPU, apenas de boa largura de banda de rede, porque só agrega gradientes.
Falhas clássicas em treino distribuído
| Sintoma | Causa provável | Resposta mais forte |
|---|---|---|
| Mais nós de trabalho, pouco ganho | Comunicação de gradientes domina o treino. | Rever tamanho do lote, estratégia de distribuição, Reduction Server e largura de banda. |
| Nós de trabalho parados à espera | Partições desequilibradas ou nós atrasados. | Equilibrar o pipeline de entrada e o particionamento dos dados. |
| Falhas caras em tarefas longas | Sem checkpointing ou retoma de estado. | Guardar progresso em Cloud Storage e retomar a partir de checkpoints. |
| Tarefa não usa GPUs | Código/framework/contentor não preparado para aceleradores. | Verificar estratégia distribuída, drivers, CUDA/cuDNN e contentor adequado. |
| Configuração indisponível | Quota, acelerador ou região não suportados. | Escolher região/forma de computação disponível ou pedir quota antes do desenho final. |
Escolha de hardware para treino
O exame espera que saibas escolher hardware com base no tipo de modelo e no orçamento, não por hábito.
| Hardware | Ideal para | Custo/Disponibilidade |
|---|---|---|
| CPU | Modelos simples, tabulares, scikit-learn. Sem operações matriciais pesadas. | Baixo. Alta disponibilidade. |
| GPU | Aprendizagem profunda (TF, PyTorch). Alta largura de banda de memória para multiplicações matriciais. | Médio/Alto. Boa disponibilidade. |
| TPU | Cargas de trabalho TensorFlow de larga escala. Desempenho superior a GPUs em cenários específicos. | Alto. Disponibilidade mais limitada. |
| Spot / Preemptible VMs | Qualquer treino que tolere interrupção e suporte checkpoints. Redução de custo até 80%. | Muito baixo, mas a VM pode ser revogada a qualquer momento. |
A escolha também depende de disponibilidade regional, quotas e suporte do framework. CPUs podem ser a melhor resposta em modelos tabulares simples; GPUs podem ser inúteis se o código não as usa; TPUs podem ser excelentes em cargas de trabalho TensorFlow específicas e exageradas noutros casos. O exame costuma dar pistas de custo, prazo, dependências e maturidade do código.
Experimentação, linhagem e Model Registry
Se o protótipo vai tornar-se modelo real, tens de saber o que foi treinado, com que dados, com que parâmetros e porque foi promovido. É aqui que entram acompanhamento de experiências, linhagem e Model Registry. O registo de modelos é importante não só como catálogo, mas como mecanismo de versionamento, aprovação, comparação e ligação entre treino, avaliação e inferência.
Na lógica do exame, isto cruza colaboração entre equipas, governança e operacionalização. Quando alguém pergunta “que modelo está em produção e com que artefactos foi gerado?”, a resposta não pode ser “acho que foi esta pasta”.
Na prática, Vertex AI Experiments é a ferramenta que regista automaticamente métricas, parâmetros e artefactos de cada execução, permitindo comparação direta entre experiências. Integrado com TensorBoard (disponível diretamente no Vertex AI Workbench), oferece visualização de curvas de perda, distribuições de pesos e métricas de avaliação ao longo do tempo. Se o cenário de exame menciona “comparar experiências de treino” ou “registar hiperparâmetros automaticamente”, Vertex AI Experiments é quase sempre a resposta.
O Vertex AI Model Registry centraliza versões, rótulos, nomes alternativos e ações de publicação, inferência em lote e avaliação. Nomes alternativos como staging e production ajudam a separar candidato, modelo aprovado e modelo em tráfego. Também é relevante saber que modelos BigQuery ML podem ser integrados no Model Registry, o que reforça uma ideia recorrente da PMLE: low-code não significa fora do ciclo MLOps.
Vertex AI Pipelines acrescenta a camada de orquestração: um DAG de tarefas em contentores, com entradas, saídas, artefactos e metadados. As execuções guardam linhagem no Vertex ML Metadata, o que permite responder a perguntas como: que dados, parâmetros, código e modelo deram origem a esta versão?
Prontidão para inferência
Um modelo treinado ainda não é um modelo pronto para produção. O formato de serialização, o contentor de inferência, a latência, o tamanho do artefacto, as dependências e a compatibilidade com inferência em lote ou previsão online também decidem a resposta certa.
| Pergunta de prontidão | Porque importa | Sinal típico no exame |
|---|---|---|
| O artefacto é servível? | TensorFlow SavedModel encaixa bem em inferência TensorFlow; outros frameworks podem exigir contentores próprios. | Modelo treinado localmente, mas sem plano de publicação. |
| O pré-processamento é igual em treino e inferência? | Transformações divergentes criam desvio entre treino e inferência. | Notebook calcula variáveis de uma forma e endpoint de outra. |
| O candidato bate a linha de base? | Promoção precisa de critério, não de intuição. | Nova versão melhora só uma métrica global frágil. |
| Consegue fazer reversão? | Model Registry, nomes alternativos e versões reduzem risco operacional. | Equipa precisa alternar entre versões ou voltar ao modelo campeão. |
Uma referência importante aqui é o TFX (TensorFlow Extended): os componentes Transform, Trainer, Evaluator, InfraValidator e Pusher são a base conceptual por trás de muitas pipelines. Mesmo que uses KFP (Kubeflow Pipelines SDK) ou Vertex AI Pipelines diretamente, perceber esta decomposição em etapas distintas e auditáveis ajuda a raciocinar sobre qualquer pipeline no exame.
Componentes TFX que o exame espera que conheças
| Componente | Função |
|---|---|
| ExampleGen | Ingere dados brutos e converte em formato interno (tf.Example). Faz a divisão treino/avaliação. |
| StatisticsGen / SchemaGen | Calculam estatísticas e inferem schema para validar expectativas sobre os dados. |
| ExampleValidator | Deteta anomalias, valores em falta, tipos inesperados e desvios face ao schema. |
| Transform | Engenharia de variáveis reproduzível: garante a mesma lógica de transformação em treino e inferência. |
| Trainer | Executa o treino do modelo usando os dados transformados. |
| Tuner | Executa afinação de hiperparâmetros dentro do pipeline quando a linha de base e a validação já são sólidas. |
| Evaluator | Avalia o modelo contra métricas e linhas de base definidas. Bloqueia promoção se não cumprir critérios. |
| InfraValidator | Valida se o modelo consegue ser servido numa infraestrutura real ou sandbox antes de promover. |
| Pusher | Publica o modelo aprovado para um endpoint ou diretamente para um alvo de inferência. |
Conjunto de dados fixado
Que versão de dados alimentou o treino e com que divisão?
Experiência rastreável
Parâmetros, métricas, artefactos e notas de decisão estão registados?
Critério de promoção
O modelo superou a linha de base, é reproduzível e está alinhado com a inferência esperada?
Explicabilidade e confiança operacional
Mesmo antes de chegares à parte explícita de IA responsável, a explicabilidade já importa nesta fase. Há contextos em que precisas de perceber por que razão o modelo prefere certas variáveis, como se comporta em segmentos diferentes e se a sua lógica aparente faz sentido face ao domínio. Em termos de exame, isto aparece muitas vezes como um critério de confiança e promoção: um modelo ligeiramente melhor mas opaco e instável pode ser pior escolha do que outro mais explicável e robusto.
Para o exame, interessa distinguir três métodos historicamente/documentalmente associados ao Vertex Explainable AI. Mas há uma cautela importante: a documentação atual marca Vertex Explainable AI como obsoleto desde 16 de março de 2026 e indisponível a partir de 16 de março de 2027. Portanto, usa isto como linguagem conceptual e de diagnóstico, não como recomendação cega para novos sistemas de longo prazo.
Sampled Shapley
Modelos tabulares e árvores (XGBoost, Random Forest). Calcula a contribuição de cada variável. Computacionalmente caro.
Integrated Gradients
Redes neuronais profundas. Usa gradientes ao longo de um caminho. Mais rápido que Shapley para grandes espaços de variáveis.
XRAI
Modelos de imagem. Mostra regiões (não pixels individuais) que determinaram a previsão.
Também há limites conceptuais. Atribuições locais não provam causalidade, podem variar com linhas de base e podem ser caras em escala. Se o requisito principal é auditabilidade, por vezes um modelo mais simples e intrinsecamente interpretável é melhor do que um modelo opaco com explicações a posteriori.
Robustez e IA responsável no treino
Um modelo robusto não é apenas o que tem melhor métrica média. É o que mantém comportamento aceitável sob dados ruidosos, segmentos minoritários, entradas fora de distribuição, mudanças temporais e requisitos de segurança. Esta ponte entre treino e IA responsável é cada vez mais importante em perguntas de certificação, sobretudo quando há impacto humano ou risco de automação indevida.
Avaliação por segmento
Mede desempenho por grupo, região, idioma, dispositivo, faixa de valor ou qualquer segmento que possa esconder falhas sob a média global.
Robustez a valores atípicos
Testa exemplos difíceis, valores extremos, dados incompletos e entradas fora de distribuição antes de promover.
Incerteza e alternativa de recurso
Quando a confiança é baixa, a resposta pode ser revisão humana, abstenção, regra de negócio ou modelo mais conservador.
Explicabilidade proporcional
Quanto maior o impacto da decisão, maior a necessidade de justificabilidade, auditoria e documentação.
Heurísticas de exame para esta parte
- Se ainda não há linha de base, cria uma linha de base antes de fazer afinação sofisticada.
- Se os dados estão no BigQuery e o problema é tabular simples, BigQuery ML pode bater treino personalizado por simplicidade.
- Se o problema pede arquitetura, dependências ou inferência específica, pensa em treino personalizado ou contentor personalizado.
- Se a métrica melhorou mas a divisão dos dados está errada, a melhoria não conta.
- Se o treino é longo ou usa Spot VMs, guardar checkpoints é parte da solução.
- Se o modelo precisa de promoção controlada, compara versões no Model Registry e usa nomes alternativos/rótulos.
- Se há risco de desvio entre treino e inferência, procura Feature Store, TFX Transform ou pipeline único de pré-processamento.
- Se há impacto em grupos diferentes, avalia por segmento antes de celebrar a média global.
O que precisas de saber para o exame
- Distinguir exploração em notebook de treino operacionalizável.
- Criar e defender uma linha de base antes de afinação ou treino caro.
- Garantir reprodutibilidade: sementes aleatórias, divisões dos dados, dependências, dados, código das variáveis e contentores.
- Exportar artefactos, checkpoints e registos com
AIP_MODEL_DIR,AIP_CHECKPOINT_DIRe TensorBoard quando aplicável. - Escolher entre BigQuery ML, AutoML, treino personalizado, contentor personalizado e pipeline de treino com base em requisitos reais.
- Escolher métricas de acordo com o tipo de problema, o desequilíbrio das classes e o custo real do erro.
- Comparar candidatos contra a linha de base/modelo campeão e avaliar por segmentos críticos.
- Perceber calibração, incerteza e afinação do limiar quando a decisão usa probabilidades.
- Aplicar validação cronológica (não k-fold) em séries temporais e dados com dependência temporal.
- Raciocinar sobre divisões por grupo, desequilíbrio de classes, fuga de informação, análise de erro e critérios de promoção.
- Saber quando a afinação de hiperparâmetros, o treino distribuído e o hardware acelerado resolvem um problema real.
- Saber quando a afinação e a escalabilidade só aumentam custo e complexidade.
- Configurar conjuntos de nós de trabalho (worker pools) corretamente: GPUs no Pool 0/1, largura de banda no Pool 2 (Reduction Server).
- Escolher hardware adequado (CPU, GPU, TPU, Spot VMs) com base no tipo de modelo e orçamento.
- Entender Model Registry, nomes alternativos, rótulos, versionamento, avaliação e linhagem como parte do ciclo de vida do modelo.
- Validar prontidão para inferência: formato de artefacto, pré-processamento, contentor, latência e reversão.
- Conhecer os componentes TFX e saber quando Vertex AI Pipelines/KFP é a opção mais adequada.
- Saber que método de explicabilidade usar para cada tipo de modelo, mas lembrar a depreciação do Vertex Explainable AI.
- Incluir robustez, equidade, avaliação por segmento e alternativa de recurso em decisões de promoção.
Praticar na documentação e nos laboratórios oficiais
- Percurso oficial da PMLE
- Vertex AI Workbench
- Treino em Vertex AI
- Preparar código de treino no Vertex AI
- Afinação de hiperparâmetros
- Treino distribuído no Vertex AI
- Avaliação de modelos no Vertex AI
- Vertex AI Pipelines
- Model Registry
- Vertex Explainable AI
- Guia TensorFlow Extended (TFX)
Na parte seguinte, saímos do treino e entramos no terreno onde os modelos têm de responder a tráfego, SLAs, custos, pipelines automáticos e monitorização real.