1 of 12

Formação Professional ML Engineer 1 / 12

ML&IA na Google Cloud

Engenharia Pragmática e a Arte de Não Complicar

SESSÃO 1 DE 5

Pensem num projeto de frontend (UI/UX) em que a equipa passa semanas a desenhar componentes customizados do zero, quando uma biblioteca standard ou um framework resolvia o problema em pouco dias. Em ML/IA, pode acontecer o mesmo, com a diferença que a fatura sai mais alta. Corre-se o risco de se passar dois meses a debater pipelines, no fim, percebermos com que um serviço gerido ou API faria 90% do trabalho.

A complexidade prematura é, um problema transversal a todos os projetos de dado.

Por isso, nesta primeira de 5 sessões sobre ML com Google Cloud, não vos vou maçar com matemática ou com detalhes de ciência de dados, ainda que fosse essa a minha vontade.

Vou antes lançar fundações de como abordar desafios de ML/IA de forma pragmática, alhinhando e escolhendo os serviços Google Cloud. Nos próximos 15 minutos, vamos mapear a nossa 'Escada ou Espetro de Complexidade'. Vão sair daqui com uma ideia de quando faz sentifo usar uma API pronta, quando optar o treino aos dados no BigQuery, e quando se justifica realmente abrir o Vertex AI e construir MLOps a sério. O objetivo é só um: pararmos de construir laboriosamente aquilo que podemos simplesmente consumir."

"O que é Machine Learning, em termos práticos para um dev?"

Em vez de escreveres regras explícitas (if x then y), dás muitos exemplos a um algoritmo e ele descobre a regra sozinho. O resultado é um modelo — um ficheiro que, recebido um input, devolve uma previsão. Para um dev: pensa numa função que foi fitted a partir de dados, em vez de ser escrita à mão.

"O que é a Google Cloud Platform (GCP)?"

Uma das três grandes clouds públicas (com AWS e Azure). Para esta sessão interessam-nos os serviços de dados (BigQuery, Cloud Storage) e os serviços de ML (Vertex AI e APIs pré-treinadas).

"O que é uma stack de ML?"

O conjunto de peças que torna ML útil em produção: armazenamento de dados → preparação → treino → registo de versões → serving (servir previsões via API) → monitorização. Cada peça pode ser custom ou gerida.

2 of 12

O Espectro de Decisão

Estratégia de Decisão 2 / 12

Bússola arquitetural: quanto mais à direita, maior a flexibilidade, mas também o fardo operacional.

ESFORÇOMínimo

PRAGMATISMOPadrão

FLEXIBILIDADEMáxima

APIs/Serviços Prontos

BigQuery ML e AutoML

Vertex AI Custom Training

3 of 12

Degrau 1: Consumir Primeiro

Degrau 1: Consumir 3 / 12

APIs Pré-treinadas

O Google já treinou modelos em datasets globais. Use o que é universal e foque no que é único do seu negócio.

•

Vision AI: OCR e análise de imagem.

•

Natural Language: Sentimento e sintaxe.

•

Speech-to-Text: Transcrição multilingue.

Antes de inciarem a escolha, perguntem-se: este problema é meu, ou é um problema de muita gente? 1) Detetar caras numa foto, 2) extrair texto de um recibo, 3) traduzir uma frase, 3) perceber se um cliente está zangado — isto não é um problema específico da nossa empresa.

São problemas universais que a Google já resolveu com modelos treinados em datasets que nós nunca teríamos. Uma chamada HTTP, JSON de resposta, custo por chamada. Zero infraestrutura. Reservem o vosso engenho para o que é único do nosso negócio."

"Cloud Vision API faz o quê exatamente?"

Recebe uma imagem (URL ou bytes) e devolve: objetos detetados, texto via OCR, rostos e emoções, categorias, logótipos, landmarks. Cobre o catálogo típico de visão computacional.

"Natural Language API faz o quê?"

Análise de sentimento (score de positivo/neutro/negativo), extração de entidades (pessoas, locais, organizações), classificação por tópico, sintaxe. Suporta dezenas de línguas.

"Document AI distingue-se da Vision API porquê?"

Vision faz OCR genérico. Document AI tem processors especializados em tipos de documento (faturas, contratos, recibos, formulários W-2) que extraem campos estruturados — não só texto, mas "este texto é o NIF, este é o total".

"Quanto custa? É barato?"

Pagamento por chamada/unidade. Vision ronda 1.50 USD por 1000 imagens. Natural Language ~1 USD por 1000 documentos curtos. Para volumes baixos a médios, é ridiculamente mais barato do que treinar e manter um modelo próprio.

4 of 12

Degrau 1.5: AutoML (Low-Code)

Degrau 1.5: AutoML 4 / 12

O Atalho para o Específico

Quando as APIs genéricas falham em domínios de nicho, mas você ainda quer evitar a gestão de código ML.

•

Treino Gerido: Google escolhe a arquitetura.

•

Dados Próprios: Especialização garantida.

•

Time-to-market: Rapidez de implementação.

Há um momento muito comum e frustrante nos projetos: a Cloud Vision API olha para a fotografia do vosso produto e diz 'isto é uma peça de metal', mas vocês precisavam que ela dissesse 'isto é o parafuso hexagonal modelo 4B com defeito'. O vosso domínio de negócio é demasiado específico para um modelo global e genérico.

O instinto trágico da equipa técnica? 'Pronto, as APIs não servem, vamos ter de abrir o Vertex AI, escrever código PyTorch e construir uma rede neural do zero'. Falso! Conheçam o Degrau 1.5: AutoML. Este é o vosso atalho pragmático.

A lógica aqui é: vocês trazem os dados anotados — as fotografias dos vossos parafusos específicos —, e a Google entra com a matemática. Carregam as imagens, clicam em 'Treinar', e debaixo do capô a Google procura a melhor arquitetura, afina os hiperparâmetros e faz o deploy do modelo.

Zero código de Machine Learning mantido por vocês. No final, recebem um endpoint REST exatamente igual ao do Degrau 1, mas que agora é um especialista no vosso negócio. O vosso foco passa de 'escrever código de ML' para 'garantir que os dados de treino têm qualidade'. É a ponte perfeita para não saltarem logo para a complexidade máxima.

"O que é o AutoML na prática?"

É uma feature dentro do Vertex AI. Tu dás-lhe um dataset (imagens, texto, vídeo ou tabelas tabulares), defines o que queres prever, e a plataforma automatiza o processo de treinar e testar múltiplos modelos concorrentes para te entregar o que tiver melhor performance.

"Se não escrevo código, como é que eu controlo a qualidade do modelo?"

O teu código passam a ser os teus dados. O paradigma muda para Data-centric AI. Se o modelo do AutoML falhar, a solução não é mudar o algoritmo, é limpar os dados, adicionar exemplos representativos dos casos em que ele falha (edge cases) e remover anotações ambíguas.

"Qual a diferença exata entre o AutoML Vision e a Cloud Vision API (Degrau 1)?"

A Cloud Vision API é um modelo estático gerido pela Google; já sabe o que é um gato, um carro ou texto, mas não a podes ensinar. O AutoML Vision é uma "folha em branco" estruturada: não sabe nada sobre o teu negócio até tu lhe dares imagens classificadas para ele aprender a vossa taxonomia específica.

"O AutoML também funciona para dados tabulares?"

Sim (Vertex AI AutoML Tabular), mas lembrem-se da nossa regra do Degrau 2: se os vossos dados já estão no BigQuery, o BigQuery ML (BQML) é geralmente a opção mais rápida e barata antes de extrair os dados para o AutoML do Vertex AI.

"Quanto custa? Fica muito mais caro que a API genérica?"

Sim, há um salto no custo. Pagas pelas horas de computação necessárias para treinar o modelo (o que pode custar dezenas a centenas de dólares dependendo do volume de dados) e, depois, pagas pelo hosting contínuo do endpoint para que ele esteja disponível para receber chamadas REST. Contudo, é uma fração ínfima do custo de alocar um Engenheiro de ML sénior durante um mês para fazer o mesmo trabalho à mão.

5 of 12

Degrau 2: BigQuery ML

Degrau 2: BigQuery ML 5 / 12

Inteligência no Warehouse

Para dados tabulares, o SQL resolve. Traga o modelo até aos dados, não o contrário.

Ideal para: Previsão de procura, stocks, vendas ou segmentação.

Quando o problema é específico do nosso negócio mas os dados já estão arrumados em tabelas — clientes, transações, eventos — pode haver a tendencia para: exportar para CSV, treinar em Python num notebook qualquer. O BigQuery ML inverte isto. Treina-se o modelo dentro do warehouse, com SQL. CREATE MODEL. As previsões saem com SELECT ml.PREDICT(...). Os dados nunca saíram do BigQuery, o modelo vive ao lado deles, e qualquer pessoa da equipa que saiba SQL consegue ler o pipeline.

Para problemas tabulares, como previsão de vendas, classificação de clientes, analise de dados (analytics) chega quase sempre."

"O que é o BigQuery?"

Pensa nele como uma base de dados SQL massivamente paralela, otimizada para queries analíticas em terabytes/petabytes. Não tem servidores para gerir, paga-se por dados processados. (Data warehouse serverless da Google. )

"O que é o BigQuery ML (BQML)?"

Extensão do BigQuery que permite criar e usar modelos de ML com SQL. Suporta regressão logística/linear, árvores boosted, K-means, deep neural nets, ARIMA para time series, matrix factorization, e até importar modelos TensorFlow.

"Que tipos de problemas faz sentido resolver com BQML?"

Tabulares: previsão de receita, scoring de leads, deteção de fraude, recomendação básica, segmentação. Não faz sentido para visão, áudio ou texto livre — para isso, ou APIs pré-treinadas (degrau 1) ou Vertex AI custom (degrau 3).

"Como serve previsões em produção?"

Duas formas: (a) batch — SELECT ml.PREDICT(...) numa tabela, escreve resultado noutra; (b) online — exporta o modelo como Vertex AI Endpoint para chamadas em tempo real.

"E o controlo de versões do modelo?"

BQML guarda metadados, mas para MLOps a sério (registry, lineage, aprovações de promoção) o caminho é exportar para Vertex AI Model Registry.

6 of 12

Degrau 3: Construir 6 / 12

Degrau 3: O Mal Necessário

Vertex AI Custom

Controlo total sobre redes neurais e pipelines de MLOps complexos.

Apenas com justificativa técnica sólida.

•

Treino customizado (Python, TF, PyTorch).

•

Orquestração com Vertex Pipelines.

•

Serving de alta performance (TPUs/GPUs).

Há casos em que os dois primeiros degraus não chegam! Precisamos de uma arquitetura específica — uma rede neuronal customizada, um modelo de visão treinado em especies de fungos locais, um sistema de recomendação com lógica nossa. POde dar-se o cado da latência tem de ser sub-100ms. As métricas de aceitação serem particulares. Os auditores vão perguntar pela linhagem de cada decisão, etc.

Aí entra o Vertex AI: a plataforma unificada da Google para o ciclo de vida completo. É o framework de ML/IA avançada da Google. (Feature Store guarda features versionadas.) Pipelines orquestra treino reproduzível. Model Registry versiona modelos. Endpoints serve em tempo real ou batch. Monitoring deteta drift. Tudo integrado, tudo governado. É poderoso mas caro de operar. Por isso só chegamos aqui como ultimo recurso.

"O que é o Vertex AI?"

A plataforma de ML unificada da Google Cloud. Cobre desde notebooks de exploração (Workbench) até serving em produção. Substitui e consolida várias ferramentas anteriores (AI Platform, AutoML standalone).

"O que é uma Feature Store?"

Um repositório centralizado de features (variáveis de entrada para modelos) versionadas e partilhadas entre equipas. Resolve um problema clássico: a feature usada em treino ser ligeiramente diferente da usada em serving (o famoso training-serving skew).

"O que é um Model Registry?"

Catálogo versionado de modelos. Cada modelo tem versões, metadados, métricas de avaliação, lineage (que dataset, que pipeline o produziu) e estado (staging, production). Análogo a um Docker registry, mas para modelos.

"O que são Endpoints?"

Serviços HTTP geridos que servem previsões. Podes ter múltiplos modelos por endpoint com traffic split (10% para v2, 90% para v1) para canary deploys e A/B tests.

"Pipelines são o quê?"

Workflows de ML como DAGs (à la Airflow), mas especializados: cada nó é um passo (ingestão, validação, treino, avaliação, deploy). Reprodutíveis, parametrizáveis, com lineage automático.

"Quanto custa?"

Combina custo de compute para treino (GPUs/TPUs por hora), storage, e endpoints (paga-se por nó/hora mesmo sem tráfego). Facilmente milhares de USD/mês para um sistema modesto. Daí o "mal necessário".

7 of 12

Desafio 1: Churn de Clientes

Estudo de Caso 1 7 / 12

Cenário

Identificar clientes que podem cancelar o serviço nos próximos 30 dias.

Dados: Transações e logs em Base de Dados Relacional.

Pausa. Olhem para o problema. Dados tabulares, num warehouse, problema de classificação binária clássico. Quem diz consumir? Não há API pré-treinada para o nosso churn (taxa a que clientes deixam de ser clientes.). Quem diz construir? Talvez se os requisitos de latência fossem extremos. Mas olhem para o problema honestamente: regressão logística em SQL resolve isto em duas horas, com CREATE MODEL no BigQuery. Aproveitar. É a resposta certa em 80% dos problemas de previsão tabular. A vaidade é que nos faz querer construir um transformer para isto."

"O que é churn?"

A taxa a que clientes deixam de ser clientes. Modelar churn = prever quais clientes têm alta probabilidade de cancelar nos próximos N dias, para se intervir antes.

"Porque não treinar uma rede neural?"

Para dados tabulares, modelos baseados em árvores (boosted trees, random forests) e regressão logística costumam empatar ou bater redes neurais — com fração do custo, do tempo e da complexidade. Há literatura abundante sobre isto.

8 of 12

Desafio 2: Sentimento de Tickets

Estudo de Caso 2 8 / 12

Cenário

Classificar tickets de suporte (Positivo/Negativo) para priorização imediata.

Dados: Texto livre do portal de suporte.

Pausa. Sentimento é o exemplo canónico de problema universal. A Google treinou a Natural Language API em volumes que nós nunca veríamos. Resposta: consumir. Uma chamada HTTP por ticket, devolve um score. Custo: cêntimos por mil tickets. Se quiséssemos categorias mais finas — 'frustrado', 'confuso', 'furioso' — aí já não há API pré-treinada com essas etiquetas. Aí sobe-se um degrau: um prompt estruturado para Gemini via Vertex AI. Continua a não ser construir nada do zero. A pergunta a fazer é sempre: até onde tenho mesmo de subir?"

Backup

"O que é sentiment analysis?"

Atribuir um valor (geralmente entre -1 e +1, ou categórico) que reflete a polaridade emocional de um texto. É um problema bem estabelecido, com modelos públicos competentes desde 2018+.

"O que é Gemini?"

A família de Large Language Models da Google. Acessível via Vertex AI. Substitui PaLM em produção. Quando a tarefa precisa de raciocínio sobre texto livre com instruções complexas (não cobertas por uma API simples), Gemini com prompt estruturado é a opção pragmática.

9 of 12

Desafio 3: Defeitos em Chips

Estudo de Caso 3 9 / 12

Cenário

Deteção de micro-defeitos em wafers microscópicos com latência <50ms.

Dados: Imagens proprietárias de alta resolução.

Pausa.. Olhem para os requisitos: imagens microscópicas de alta resolução de um domínio proprietário e uma latência de menos de 50 milissegundos.

Podíamos tentar o Degrau 1? Não. A Cloud Vision API é brilhante a detetar cães, gatos ou logótipos, mas não sabe o que é um micro-defeito num wafer de silício específico da nossa fábrica. Podíamos tentar o Degrau 2? Também não. O BigQuery não foi feito para processar binários de imagem pesados com lógica de visão computacional customizada.

Para bater os 50ms de latência, precisamos de controlo total: desde o código de pré-processamento num contentor Docker, ao ajuste fino de hiperparâmetros com o Vertex AI Vizier, até ao deployment do modelo otimizado na edge (perto da linha de montagem). É o cenário clássico do Vertex AI Custom: dados únicos, arquitetura específica e performance crítica. É o Degrau 3. É caro, é complexo, exige MLOps rigoroso, mas é aqui que o vosso valor como Engenheiros de ML se torna insubstituível."

Backup — Q&A

"Porque é que a Cloud Vision API não resolve isto?"

Porque modelos pré-treinados são generalistas. Para defeitos em semicondutores, os padrões são demasiado subtis e específicos. Além disso, a latência de rede de enviar imagens 4K para uma API pública quebraria o requisito de <50ms.

"O que é que o 'Custom' no Vertex AI nos dá a mais?"

Permite usar qualquer framework (PyTorch, TensorFlow, JAX) através de Custom Containers. Dá-nos acesso a aceleradores (GPUs/TPUs) para treino rápido e permite orquestrar o pipeline via Vertex AI Pipelines para que o processo seja repetível sempre que o hardware da fábrica mude.

"Como garantimos <50ms de latência?"

Através de técnicas de otimização do modelo (quantização, poda) e, crucialmente, servindo o modelo localmente (Edge Computing) ou usando Vertex AI Endpoints com máquinas otimizadas para inferência, evitando os round-trips longos da internet pública.

"O que é o Hyperparameter Tuning (Vizier)?"

É um serviço de 'caixa-negra' que testa automaticamente centenas de combinações de configurações do modelo (taxa de aprendizagem, profundidade da rede) para encontrar a que dá maior precisão, sem que o engenheiro tenha de o fazer à mão.

"Este nível de complexidade compensa sempre?"

Só se o impacto financeiro de detetar o defeito superar o custo de manter a infraestrutura de MLOps. Se o erro humano na fábrica custar milhões, o Degrau 3 paga-se a si próprio. Se for um problema trivial, estamos a 'sobre-engenheirar'

10 of 12

Matriz de Decisão

Síntese de Decisão 10 / 12

A Regra de Ouro: Proibido subir o degrau se o anterior resolver o problema.

APIS

Problema Genérico

Texto, voz, tradução, visão comum.

Esforço: Quase zero

AUTOML

Visão/Vídeo Específicos

Dados próprios mas sem equipa de ML.

Esforço: Baixo

BIGQUERY ML

Dados Tabulares

Dados já estruturados num Warehouse.

Esforço: Médio (SQL)

VERTEX CUSTOM

Requisitos Críticos

Latência, governança ou redes neuronais custom, orquestração de agentes.

Esforço: Elevado

Eis o nosso mapa da sensatez. Nada de slide a perguntar 'dúvidas?', nada a mendigar 'obrigado'. Este fica no ecrã. Fotografem-no. Na próxima segunda-feira, antes de inventarem um pretexto maravilhoso para arrancar com um pipeline gigante, façam o favor de colocar o vosso projeto nesta matriz. Se a linha de cima resolve, parem aí. Sessão 1 fechada. Da próxima vez: dados, qualidade, e os dramas que acontecem antes do modelo sequer existir."

"E se o problema for híbrido — tabular e texto?"

Combina degraus. Usa Natural Language API para extrair features do texto, junta às features tabulares no BigQuery, treina com BQML. Não há regra que obrigue a um único degrau.

"E generative AI / RAG / agentes — onde encaixam?"

Tipicamente Degrau 1 (Agent Builder, foundation models do Model Garden). Sobe-se a Degrau 3 só se precisares de fine-tuning sério ou orquestração custom de tools. Tema da Sessão 5.

"Como decido o nível de governance necessário?"

Pergunta-te três coisas: (a) os dados são pessoais/regulados? (b) há auditoria externa? (c) uma decisão errada do modelo causa dano real? Se sim a qualquer uma, governance entra desde o Slide 6, mesmo num Degrau 1.

11 of 12

Glossário Rápido

Termos Técnicos11 / 12

Inferência

Fazer previsões em produção.

Feature

Variável de entrada do modelo.

Drift

Degradação do modelo com o tempo.

RAG

Grounding de LLMs com seus dados.

Pipeline

Orquestração do fluxo de ML.

Endpoint

URL gerido que serve a previsão.

1 of 12

2 of 12

3 of 12

4 of 12

5 of 12

6 of 12

7 of 12

8 of 12

9 of 12

10 of 12

11 of 12

12 of 12