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
- Prompt design patterns no Vertex AI
- Context caching para otimização de custos
- Agent Search vs Vector Search
- Model Garden e escolha de foundation models
- RAG, grounding e arquitetura de contexto
- Agent Builder e agentes
- Avaliação de GenAI
- Responsible AI em decisões concretas
- Ferramentas de explainability e fairness
- O que precisas de saber para o exame
Prompt design patterns no Vertex AI
No Vertex AI, o design do prompt é parte da arquitetura do sistema, não uma otimização isolada. O exame cobre técnicas como few-shot prompting (exemplos no prompt), chain-of-thought (raciocínio passo-a-passo) e system prompts (instruções de comportamento) como decisões que afetam qualidade, custo e segurança.
Quando o cenário menciona "melhorar a qualidade sem retraining", a resposta pode passar por engenharia de prompts. Quando menciona "reduzir custos", pode passar por simplificação de prompts ou context caching.
| Padrão | Quando usar | Trade-off no exame |
|---|---|---|
| Few-shot prompting | Quando precisas de guiar o comportamento sem tuning. | Aumenta tokens e custo; pode ser inconsistente entre chamadas. |
| Chain-of-thought | Quando o problema exige raciocínio multi-etapa. | Maior latência e tokens; melhora factualidade em cenários complexos. |
| System prompts | Para definir tom, limites e comportamento de segurança. | Controla output mas requer testes para garantir consistência. |
Context caching para otimização de custos
Quando o mesmo contexto (documentos longos, instruções de sistema) é reutilizado em múltiplas chamadas, o Vertex AI oferece context caching para reduzir o número de tokens processados. Esta otimização aparece no exame em cenários onde o orçamento é mencionado ou onde prompts grandes afetam a latência.
O caching é especialmente relevante em sistemas RAG onde os documentos de referência são recorrentes, ou em agentes que mantêm instruções extensas.
Agent Search vs Vector Search: escolha arquitetural
Agent Search (anteriormente Vertex AI Search) é uma solução gerida para pesquisa e RAG que inclui indexação, recuperação, sumarização generativa, pesquisa conversacional, sinónimos, correção ortográfica e auto-suggest prontos a usar, com menos configuração. Vector Search oferece controlo total sobre embeddings, chunking e indexação, mas requer mais engenharia.
No exame, a distinção aparece como: qual a solução mais apropriada para uma equipa com pouca experiência em embeddings (Agent Search) vs uma que precisa de controlo fino (Vector Search)?
| Necessidade | Agent Search | Vector Search |
|---|---|---|
| Setup rápido | Configuração mínima, UI guiada, widget de pesquisa pronto a embeber. | Requer pipeline de embeddings e chunking. |
| Controlo de embeddings | Embeddings geridos, menos flexibilidade. | Escolhe modelo, dimensão, chunking. |
| Funcionalidades de RAG | Sumarização generativa, pesquisa conversacional e ranking self-learning incluídos. | Constrói-se o RAG por cima; mais controlo, mais trabalho. |
| Escalabilidade | Gerida automaticamente. | Configuração manual de índices e endpoints. |
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. A Google Cloud organiza os modelos Gemini numa hierarquia de capacidade/custo: Pro para raciocínio complexo, Flash para equilíbrio entre inteligência e latência, e Flash-Lite para alto volume e custo mínimo.
| Modelo | Contexto | Posicionamento | Caso de uso ideal |
|---|---|---|---|
| Gemini 2.5 Pro | 1M tokens | Alta capacidade, raciocínio adaptativo | Raciocínio complexo, desafios agentic e multimodais, análise de documentos longos. |
| Gemini 2.5 Flash | 1M tokens | Equilíbrio inteligência/latência, com thinking budgets controláveis | Aplicações versáteis onde velocidade e custo importam tanto quanto qualidade. |
| Gemini 2.5 Flash-Lite | 1M tokens | Custo mínimo, alto débito | Tráfego de alto volume e sensível a custo; tarefas mais simples em escala. |
| Gemini 3.5 Flash | 1M tokens | Near-Pro a custo Flash (GA) | Capacidades agentic e coding ao nível Pro, sem o custo de um modelo Pro. |
Prompting / grounding
Primeiro degrau quando queres reduzir complexidade e validar utilidade antes de tuning. Sem custo de treino.
Parameter-efficient tuning (adapter)
Atualiza um subconjunto pequeno de parâmetros com dados próprios. Mais leve que full fine-tuning, mantém a base do modelo. Abordagem recomendada pela Agent Platform para a maioria dos casos.
Full fine-tuning
Atualiza todos os parâmetros do modelo. Maior qualidade potencial em tarefas complexas, mas exige muito mais compute para treino e serving.
Supervised fine-tuning
Ensina uma nova skill ao modelo com centenas de exemplos etiquetados. Recomendado para classificação, extração de entidades, sumarização e queries de domínio.
Preference tuning
Afinação com dados de feedback humano (preferências). Substitui o que se chamava RLHF. Alinha o modelo com preferências subjetivas difíceis de capturar com labels.
Distillation (conceito geral)
Treinar um modelo menor para aproximar o comportamento de um maior. Reduz custo de serving. Conceito relevante no ecossistema de modelos abertos, não listado como método de tuning de Gemini.
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.
A Agent Platform disponibiliza o RAG Engine, um framework de dados para aplicações LLM com contexto aumentado. O pipeline formal do RAG Engine tem seis etapas que o exame pode referenciar:
| Etapa | O que acontece |
|---|---|
| 1. Data ingestion | Ingestão de fontes: ficheiros locais, Cloud Storage, Google Drive. |
| 2. Data transformation | Conversão e preparação para indexação — tipicamente, divisão em chunks. |
| 3. Embedding | Representações numéricas do texto que capturam significado semântico. Textos semelhantes ficam próximos no espaço vetorial. |
| 4. Data indexing | Criação de um corpus — índice otimizado para pesquisa, como um índice detalhado de um livro de referência. |
| 5. Retrieval | Perante uma pergunta, o sistema pesquisa no corpus os passagens relevantes. |
| 6. Generation | O contexto recuperado é adicionado à query original para o modelo gerar uma resposta grounded e factual. |
No centro de muitas arquiteturas RAG estão embeddings e vector search. O Vertex AI disponibiliza 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 é o 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. |
Agent Builder e sistemas com agentes
Agent Builder (anteriormente Vertex AI Agent Builder, agora parte da Gemini Enterprise Agent Platform) é 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, ROUGE/BLEU/BERTScore, groundedness scores, 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.
Arquitetura de safety em camadas para Gemini
A documentação atual da Agent Platform descreve a safety como uma arquitetura multi-camada. O exame pode testar a capacidade de escolher a camada certa para cada risco. As camadas, da mais básica à mais avançada, são:
| Camada | O que faz | Quando usar |
|---|---|---|
| Filtros por defeito (não configuráveis) | Proteção contra CSAM e conteúdo copyright (recitação). Independente do modelo. | Baseline mínimo em qualquer workflow. |
| Filtros configuráveis | Filtros predefinidos para categorias de dano (sexual, hate, harassment, dangerous) com thresholds ajustáveis (BLOCK_LOW_AND_ABOVE, BLOCK_MEDIUM_AND_ABOVE, BLOCK_ONLY_HIGH). Robustez contra jailbreaks. | Aplicações user-facing e agentes que precisam de base de content safety. |
| System instructions | Instruções diretas ao modelo sobre tom, marca e tópicos a evitar. | Brand safety e políticas de conteúdo nuanceadas. Combinar com filtros configuráveis. |
| DLP (Sensitive Data Protection) | Inspeciona texto para identificar e mascarar PII, com infoTypes predefinidos ou custom. Permite block lists customizadas. Aplicável no input e no output. | Cenários com risco de fuga de dados sensíveis em prompts, logs ou respostas. |
| Gemini as a Filter | Segunda chamada a um modelo rápido e barato (Flash/Flash-Lite) para avaliar se input ou output é seguro segundo políticas customizadas. Multimodal. | Proteção avançada e customizável contra drift, hallucination e violações de brand safety. |
| C2PA Content Credentials | Metadados criptograficamente assinados em imagens geradas, indicando origem AI. | Geração de media onde a transparência de origem é importante para confiança. |
| 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. | DLP para mascarar/redaction, minimização de dados, políticas de retenção, desenho seguro. |
| Safety | Conteúdo inadequado, instruções perigosas, hallucination em contexto sensível. | Filtros configuráveis, system instructions, grounding, Gemini as a Filter, 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 Engine, Agent Builder, avaliação generativa e Responsible AI?
- Sei distinguir entre variantes Gemini (Pro, Flash, Flash-Lite) e escolher com base em custo, latência e capacidade?
- Percebo as seis etapas do pipeline RAG (ingestion, transformation, embedding, indexing, retrieval, generation)?
- Percebo como chunking e vector search afetam a qualidade de um sistema RAG?
- Sei escolher entre Agent Search e Vector Search para RAG?
- Sei distinguir parameter-efficient tuning, full fine-tuning, supervised e preference tuning?
- 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?
- Sei aplicar prompt design patterns (few-shot, chain-of-thought) como parte da arquitetura?
- Sei usar context caching para reduzir custos em cenários de prompts repetidos?
- Sei aplicar métricas GenAI (ROUGE, BLEU, groundedness) na avaliação?
- Sei identificar as camadas de safety (filtros por defeito, configuráveis, system instructions, DLP, Gemini as a Filter, C2PA) e quando usar cada uma?
- Sei implementar DLP para proteção de PII em input e output de modelos generativos?
Praticar na documentação e nos labs oficiais
- Página oficial da certificação
- Path oficial da PMLE
- Model Garden
- Agent Builder e agentes
- RAG Engine
- Agent Search
- Safety (Responsible AI)
- Tuning de modelos Gemini
- 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.