Série PMLE - 5 de 5
Publicado a 14 de Abril de 2026
A versão atual da PMLE já não trata generative AI como nota de rodapé. Model Garden, Agent Builder, avaliação de soluções generativas e Responsible AI passaram a fazer parte explícita do território que tens de conhecer.
Neste post
Generative AI entrou no exame. Isso muda o quê?
Muda duas coisas. Primeiro, já não basta estudar a PMLE como se fosse apenas uma certificação de pipelines clássicos para modelos tabulares ou de visão/NLP tradicional. Segundo, o tipo de avaliação que o exame exige ficou mais contextual: escolher foundation models, pensar em grounding, avaliar outputs menos determinísticos, considerar segurança e desenhar experiências com agentes.
Isto não significa que a certificação virou um exame de prompt engineering. Significa que generative AI passou a ser mais um ramo do mesmo problema central: como desenhar, operacionalizar e monitorizar soluções AI credíveis na Google Cloud.
Model Garden: escolher em vez de reinventar
Model Garden aparece no currículo porque incorpora a lógica low-code/managed do mundo generativo. Em vez de começares com o reflexo de treinar ou afinar tudo de raiz, partes de um catálogo de foundation models e perguntas: que capacidades já existem, que modelos servem o meu caso, quanto controlo preciso, e que trade-offs de custo, latência e segurança são aceitáveis?
Tal como em BigQuery ML no mundo clássico, a competência avaliada não é só saber que a ferramenta existe. É saber quando ela é a resposta certa.
| Questão | Porque importa no exame | Direção de raciocínio |
|---|---|---|
| Que foundation model escolher? | Nem todos os casos exigem o mesmo custo, modalidade ou nível de tuning. | Alinhar capacidade, contexto, latência e risco. |
| Preciso de tuning ou basta prompting/grounding? | Evita complexidade prematura. | Preferir a intervenção mínima que resolva o problema. |
| Como avalio a solução? | Outputs generativos são menos binários e exigem critérios mais ricos. | Combinar qualidade, segurança, factualidade e utilidade. |
Variantes Gemini: trade-offs de custo, latência e capacidade
O exame espera que saibas distinguir entre variantes de foundation models disponíveis no Model Garden. Nem todos os problemas exigem o modelo mais capaz — e escolher o errado pode inflacionar custos ou introduzir latência desnecessária.
| Modelo | Contexto | Modalidades | Caso de uso ideal |
|---|---|---|---|
| Gemini Pro | Contexto longo (até 1M tokens) | Texto, imagem, áudio, vídeo, código | Análise de documentos longos, raciocínio complexo, multimodalidade. |
| Gemini Flash | Contexto longo (até 1M tokens) | Texto, imagem, áudio, vídeo, código | Latência baixa e custo otimizado. Quando a velocidade é mais importante que a capacidade máxima. |
Prompting / grounding
Primeiro degrau quando queres reduzir complexidade e validar utilidade antes de tuning.
Adapter tuning (LoRA)
Ajusta um subconjunto pequeno de parâmetros com dados próprios. Mais leve que full fine-tuning, mantém a base do modelo.
Distillation
Treina um modelo menor para aproximar o comportamento de um modelo maior. Reduz custo de serving sem perder demasiada qualidade.
RLHF / alinhamento
Afinação com feedback humano para melhorar alinhamento, segurança e estilo de resposta. Relevante em cenários de produto.
Troca de modelo
Às vezes o problema não é o prompt; é o foundation model errado para a latência, modalidade ou custo.
RAG, grounding e arquitetura de contexto
No contexto atual da certificação, falar de grounding sem falar de Retrieval-Augmented Generation é ficar a meio da conversa. Sempre que o sistema precisa de responder com base em documentação interna, fontes dinâmicas ou conhecimento que não cabe só no modelo, tens de pensar em recuperação de contexto, chunking, ranking, contexto injetado e controlo sobre a origem da resposta.
No centro de muitas arquiteturas RAG estão embeddings e vector search. O Vertex AI disponibiliza Vertex AI Vector Search (anteriormente Matching Engine) para indexar e pesquisar embeddings a grande escala, com latência baixa. Perceber quando usar embeddings pré-gerados vs re-encoding, como gerir índices e como integrar vector search com pipelines de grounding é cada vez mais relevante no exame.
Outra feature explícita do Vertex AI é Grounding with Google Search, que permite ao modelo ancorar respostas em resultados de pesquisa públicos para melhorar factualidade. Em cenários de exame onde a pergunta menciona redução de hallucination ou verificação factual, esta feature pode ser a peça que falta.
Chunking: a decisão que define a qualidade da recuperação
A forma como divides os documentos em chunks antes de os indexar determina a qualidade do contexto que o modelo recebe. Chunks demasiado grandes diluem relevância; chunks demasiado pequenos perdem contexto. Para o exame, interessa perceber que chunking não é um detalhe menor — é uma decisão de engenharia com impacto direto na qualidade das respostas.
| Estratégia de chunking | Quando funciona | Quando falha |
|---|---|---|
| Chunks de tamanho fixo | Documentos homogéneos, prototipagem rápida. | Corta frases e ideias ao meio; perde semântica. |
| Chunks por secção/parágrafo | Documentos bem estruturados com headers claros. | Secções muito longas ou muito curtas criam chunks desequilibrados. |
| Chunks com overlap | Quando o contexto na fronteira entre chunks é importante para a resposta. | Aumenta o custo de armazenamento e indexação; pode introduzir redundância nos resultados. |
| Padrão | Quando costuma bastar | Quando fica curto |
|---|---|---|
| RAG simples | Base documental relativamente estável, perguntas diretas, pipeline curto de recuperação. | Quando a qualidade depende de re-ranking, multi-hop ou filtros de segurança mais fortes. |
| RAG com re-ranking | Quando a recuperação bruta devolve demasiado ruído ou contexto mal ordenado. | Se o problema exigir também ações, ferramentas ou planeamento multi-etapa. |
| Agente com grounding e tools | Quando o sistema precisa de pesquisar, sintetizar e agir sobre outros sistemas. | Se não houver governança, observabilidade e limites de ação adequados. |
Vertex AI Agent Builder e sistemas com agentes
Agent Builder é uma das menções explícitas da versão atual da certificação. O que te interessa estudar aqui não é só a interface do produto, mas o padrão arquitetural: pesquisa/grounding, recuperação de contexto, orquestração de ações, governança e avaliação. Um agente é interessante precisamente porque expõe de forma muito visível problemas antigos de ML engineering: observabilidade, segurança, controlo de qualidade e integração com sistemas reais.
Se o modelo clássico obrigava a pensar no que entra e no que sai, os agentes obrigam-te a pensar também em ferramentas, contexto, autonomia e risco. Isso torna Responsible AI ainda menos opcional.
Observabilidade e guardrails em agentes
Num sistema com agentes, a monitorização não se limita a métricas de modelo. Precisas de observar o que o agente faz: que ferramentas chamou, que contexto recuperou, que ações executou, que respostas deu e onde falhou. A ausência de observabilidade num agente é equivalente a pôr um modelo em produção sem logging.
Logging de ações
Registar cada tool call, contexto recuperado e resposta gerada para auditoria e debugging.
Guardrails de input/output
Filtros de safety no prompt e na resposta. Limites de autonomia: que ações o agente pode executar sem aprovação humana.
Escalonamento humano
Definir critérios para quando o agente deve devolver controlo a um humano em vez de continuar a agir.
Avaliação em GenAI: qualidade não é uma única métrica
Na Parte 3, vimos que avaliação é desenhar critérios, não só calcular números. Em modelos generativos, esse princípio mantém-se mas os critérios mudam: avaliação deixa de ser facilmente reduzível a uma métrica única. A certificação atual deixa isso implícito ao falar em avaliação de soluções generativas. Tens de saber raciocinar sobre relevância, factualidade, robustez, segurança, aderência à tarefa e, dependendo do caso, experiência do utilizador. Em muitos cenários, isso implica mistura de avaliação automática e humana.
Mais uma vez, a pergunta certa é: o que significa “bom” neste sistema? Respostas factualmente corretas? Respostas seguras? Capacidade de citar contexto? Menos alucinação? Melhor grounding? A PMLE não te pede apenas tecnologia; pede critérios.
| Camada de avaliação | O que tenta responder | Exemplos de sinais |
|---|---|---|
| Avaliação automática | O output se aproxima do comportamento esperado em escala? | Relevância, cobertura, métricas textuais, matching com respostas de referência. |
| Avaliação humana | A resposta é útil, clara, segura e credível para quem a usa? | Rubricas de factualidade, clareza, utilidade, tom, riscos. |
| Avaliação operacional | O sistema aguenta custo, latência, segurança e contexto real? | Tokens, latência, falhas de grounding, incidentes de safety. |
Responsible AI: fairness, interpretability, privacy, safety
O learning path oficial dedica blocos próprios a fairness & bias, interpretability & transparency, privacy & safety. Isso é um sinal curricular claro. Responsible AI não deve ser estudada como apêndice moral, mas como parte do desenho de um sistema utilizável e defensável. Mesmo em GenAI, onde parte da conversa se foca em safety, os pilares continuam a incluir viés, explicabilidade, privacidade e governação.
- Fairness & bias: perceber como dados, labels, sampling e feedback loops podem enviesar o sistema.
- Interpretability & transparency: saber quando e porquê é preciso tornar o comportamento do modelo mais legível para equipas e utilizadores.
- Privacy: proteger dados sensíveis no treino, serving e observação do sistema.
- Safety: reduzir outputs perigosos, inadequados ou operacionalmente arriscados, especialmente em GenAI.
Um artefacto que o exame referencia para transparência é o Model Card — documento estruturado que descreve o que o modelo faz, como foi treinado, com que dados, que limitações tem e para que cenários foi validado. Model Cards são especialmente relevantes em ambientes regulados e em equipas grandes onde quem faz deploy não é quem treinou o modelo.
| Risco | Como aparece | Resposta esperada |
|---|---|---|
| Bias / unfairness | Outputs piores para certos grupos, dados enviesados, feedback loops. | Rever dados, avaliar por segmento, ajustar pipeline e critérios de promoção. |
| Baixa interpretabilidade | Equipa não consegue justificar decisões ou investigar erros. | Adicionar explicabilidade, documentação e revisão humana em pontos críticos. |
| Privacidade | PII em prompts, logs, treino ou contexto recuperado. | Minimização de dados, políticas de retenção, filtros e desenho seguro do sistema. |
| Safety | Conteúdo inadequado, instruções perigosas, hallucination em contexto sensível. | Guardrails, avaliação contínua, filtros, grounding e escalonamento humano. |
Ferramentas de explainability e fairness
Na Parte 3, vimos Shapley, Integrated Gradients e XRAI no contexto de promoção de modelos — “devo confiar neste modelo antes de o publicar?”. Aqui, aplicam-se a um problema diferente: detetar viés e garantir fairness antes e depois do deploy. A escolha do método continua a depender da estrutura matemática do modelo.
| Método | Tipo de modelo | O que faz |
|---|---|---|
| Sampled Shapley Values | Modelos tabulares, árvores de decisão, XGBoost | Calcula a contribuição de cada feature para a previsão. Padrão ouro para dados tabulares, mas computacionalmente caro. |
| Integrated Gradients (IG) | Redes neuronais profundas, modelos diferenciáveis | Calcula o gradiente da saída em relação à entrada ao longo de um caminho. Mais rápido que Shapley para grandes espaços de features. |
| XRAI | Modelos de imagem | Combina Integrated Gradients com segmentação para mostrar que regiões da imagem (não pixels) foram determinantes. |
Para deteção de viés, o What-If Tool (WIT) permite análises contrafatuais: "O que aconteceria com a previsão se eu mudasse a idade de 20 para 30 anos, mantendo tudo o resto constante?". É essencial para identificar se o modelo usa atributos protegidos (género, etnia) de forma discriminatória, mesmo indiretamente. O exame valoriza ajustes de fairness feitos na fase de pré-processamento e seleção de dados, não tentando corrigir previsões após o modelo estar treinado.
Checklist final da série
Se leste as cinco partes como preparação de exame, a revisão final devia deixar-te confortável com este conjunto de perguntas:
- Consigo escolher entre low-code AI e abordagens mais customizadas?
- Sei desenhar dados, features e pipelines sem leakage nem skew?
- Sei passar de protótipo a treino reprodutível, com avaliação defensável?
- Sei servir, automatizar, monitorizar e atualizar o sistema em produção?
- Sei raciocinar sobre Model Garden, RAG, Agent Builder, avaliação generativa e Responsible AI?
- Sei distinguir entre variantes Gemini (Flash vs Pro) e escolher com base em custo, latência e capacidade?
- Percebo como chunking e vector search afetam a qualidade de um sistema RAG?
- Sei que método de explainability usar para cada tipo de modelo (Shapley, IG, XRAI)?
- Sei usar ferramentas como What-If Tool para detetar viés antes de o modelo ir para produção?
- Sei o que é um Model Card e quando usá-lo para documentar limitações, dados e cenários validados?
Praticar na documentação e nos labs oficiais
- Página oficial da certificação
- Path oficial da PMLE
- Model Garden
- Vertex AI Agent Builder
- RAG na Vertex AI
- Responsible AI na Google Cloud
Com isto, a série cobre o mapa atual do currículo oficial da PMLE. A próxima etapa de estudo já não é adicionar temas novos; é rever cenários e praticar decisões arquiteturais com documentação e labs oficiais.