Fundamentos de IA Generativa: Tokens, Transformers, Prompting e Modelos de Fundação

Esta é a lição de maior alavancagem do curso. O Domínio 2 (Fundamentos de IA Generativa) carrega 24% e o Domínio 3 (Aplicações de Modelos de Fundação) carrega 28% do conteúdo avaliado, 52% no total, e quase toda questão dentro desses dois domínios é construída a partir do mesmo conjunto pequeno de objetos: um token, uma janela de contexto, um prompt, um parâmetro de inferência, um embedding e um modelo de fundação (FM). Aprenda os objetos e os números a eles ligados, e metade do exame vira aritmética mais vocabulário em vez de palpite.

Ao final desta lição você será capaz de:

• explicar o self-attention em termos de query/key/value e dizer por que transformers vencem RNNs em sequências longas;
• estimar tokens com ambas as regras publicadas pela AWS (6 caracteres por token, e 4,7 caracteres por token para embeddings em inglês) e saber qual delas a questão está usando;
• orçar uma janela de contexto como system prompt + entrada do cliente + contexto RAG + saída, e prever o que um Context Window Overflow faz ao comportamento;
• escolher entre zero-shot, few-shot, chain-of-thought, self-consistency e encadeamento de prompts e afirmar o custo de cada um;
• definir temperature, top-p, top-k, max tokens, stop sequences e penalidades para uma carga de trabalho e defender a resposta sobre determinismo;
• ler uma tabela de modalidade e escolher a família de FM certa para texto, embeddings, imagem, vídeo ou entradas imagem+texto;
• percorrer o espectro de customização da engenharia de prompt até um modelo personalizado e nomear os números que a AWS liga à destilação e ao fine-tuning por reforço;
• avaliar um FM com ROUGE, BLEU, BERTScore, LLM-as-a-judge e avaliação humana;
• aplicar as seis políticas dos Guardrails e a escada de três passos de mitigação de alucinação;
• defender o veredito comparativo entre IA generativa, ML tradicional e sistemas baseados em regras.

---

1. O que a IA generativa é, e o que ela não é

1.1 A definição que o exame realmente usa

IA generativa é a classe de sistemas que cria conteúdo novo: texto, código, imagens, vídeo, áudio e embeddings. Aquela única palavra, novo, é a distinção inteira. Um modelo de ML tradicional responde "a qual balde esta linha pertence?"; um modelo generativo responde "escreva algo que pertença a este balde". Modelos de fundação são os motores por baixo: grandes modelos treinados em corpora amplos que você adapta através de prompting, geração aumentada por recuperação (RAG) ou fine-tuning em vez de retreinar.

A AWS é explícita sobre a troca. Modelos de fundação são não-determinísticos: "entradas idênticas podem produzir respostas diferentes". Essa propriedade é o que os torna úteis para rascunho e brainstorming e o que os torna perigosos para extração, pontuação e qualquer coisa que um auditor leia duas vezes.

1.2 As vantagens e os riscos que a AWS nomeia

O guia de exame lista quatro vantagens e quatro desvantagens. Eles não são decoração: cada vantagem pareia com um controle, e cada risco pareia com uma mitigação que você será pedido a nomear.

1.3 O ciclo de vida do modelo de fundação

A Tarefa 2.1 exige o ciclo de vida em ordem. Também é a forma da maioria das questões de sequenciamento do exame.

• 🔢 📚 Você sabia? A própria formulação do guia de exame para o ciclo de vida é um ciclo, não uma linha: o feedback retorna à seleção de dados. É por isso que "monitore o modelo implantado e devolva dados de produção ao corpus" lê-se como correto no exame, enquanto "implantação é o passo final" lê-se como um distrator: e é o mesmo loop que faz do desvio um problema de IA generativa e não apenas de ML clássico.

---

2. Tokens: a unidade em que tudo é medido

2.1 O que é um token

Um token é o pedaço de texto que um modelo realmente lê e escreve. Um tokenizador divide o texto bruto em tokens antes que o modelo o veja, e a geração acontece um token de cada vez. A propriedade crítica é que a tokenização é específica do modelo: a mesma frase pode ser 12 tokens em um modelo e 17 em outro, e é por isso que uma fórmula fixa "palavras ÷ X = tokens" é não-confiável, e por isso que o Amazon Bedrock expõe uma API CountTokens que conta com o tokenizador do modelo selecionado sobre a entrada exata que você está prestes a invocar.

Chunking é o conceito companheiro: quando um documento é mais longo que o limite de entrada do modelo, você o divide em segmentos (parágrafos, seções, páginas) para que cada segmento caiba. A qualidade do chunking é a maior alavancagem em um sistema RAG: a AWS publicou um caso em que apenas um chunking melhor elevou a relevância de contexto de 67% para 93% e removeu alucinações sem mudar o prompt.

2.2 As duas regras de estimativa publicadas pela AWS

2.3 Exemplo resolvido 1: cota de fine-tuning em caracteres

Uma equipe quer fazer fine-tune do Amazon Titan Text G1 Express e tem um prompt de exemplo de 30.000 caracteres. A cota de fine-tuning com batch size 1 para aquele modelo é 4.096 tokens de entrada+saída.

1. Converta a cota para caracteres: $4{,}096 \times 6 = 24{,}576$ caracteres permitidos.
2. Converta o exemplo para tokens: $30{,}000 \div 6 = 5{,}000$ tokens: 904 tokens acima da cota de 4.096.
3. Converta o excesso de volta para caracteres: $30{,}000 - 24{,}576 = 5{,}424$ caracteres a mais.

Resposta: o exemplo excede a cota em 5.424 caracteres; divida-o em dois registros ou trunque. O distrator "50.000 caracteres" é o teto do Embeddings V2 do Titan, um modelo diferente e um limite diferente.

2.4 Exemplo resolvido 2: qual limite de embedding prende primeiro?

O Titan Text Embeddings V2 aceita 8.192 tokens ou 50.000 caracteres. Qual dos dois pára um documento longo em inglês primeiro?

1. Inglês tem em média 4,7 caracteres por token, então o limite de tokens prende em $8{,}192 \times 4,7 \approx 38{,}502$ caracteres.
2. Um artigo de 50.000 caracteres converte portanto em $50{,}000 \div 4,7 \approx 10{,}638$ tokens.
3. Excesso: $10{,}638 - 8{,}192 = 2{,}446$ tokens.

Resposta: o limite de tokens prende primeiro, em cerca de 38.502 caracteres para inglês: 11.498 caracteres antes do teto de 50.000 caracteres. O remédio documentado pela AWS é segmentar o documento em parágrafos ou seções e embutir cada um.

• 🔢 📚 Você sabia? O endpoint CountTokens do Bedrock responde uma pergunta que nenhuma fórmula consegue: ele roda o tokenizador do próprio modelo invocado sobre a sua string exata. O mesmo artigo de 47.000 caracteres pode estar acima do orçamento em um modelo e confortavelmente abaixo em outro, e é por isso que a AWS documenta o CountTokens como a etapa de planejamento antes de qualquer chamada sensível a cota, e não como uma conveniência opcional.

---

3. Transformers e self-attention: como um modelo lê uma sequência

3.1 Query, key e value

O self-attention deixa cada token de uma sequência olhar para cada outro token e decidir o que importa. Cada embedding de token é projetado em três vetores, e as descrições da AWS deles são a formulação exata que o exame usa:

As pontuações de atenção são computadas a partir de Q comparado contra K, e então usadas para ponderar os vetores V. O resultado é uma representação de cada token que já contém o seu contexto: é por isso que "bank" em river bank e "bank" em bank account terminam como vetores diferentes mesmo tendo sido a mesma string de entrada.

3.2 O bloco transformer e a codificação posicional

Um bloco transformer é, na definição da AWS, self-attention multi-head mais uma rede feed-forward position-wise. Múltiplos heads atendem em paralelo para que heads diferentes possam se especializar: um rastreando sintaxe, outro rastreando co-referência, outro rastreando distância. Como a atenção em si é cega à ordem, a codificação posicional injeta a ordem da sequência para que o modelo saiba qual token veio primeiro.

3.3 Por que transformers vencem RNNs, e por que modelos estilo GPT são pilhas de decoders

Transformers processam a sequência inteira em paralelo, onde um RNN deve percorrê-la uma posição de cada vez. As consequências são as duas coisas que valem a pena memorizar: treinamento mais rápido e a capacidade de lidar com sequências muito mais longas. Modelos estilo GPT são pilhas de blocos de decoder e são autoregressivos: eles produzem um token, o anexam à entrada, e rodam de novo.

---

4. Embeddings, vetores e bancos de dados vetoriais

4.1 De tabelas one-hot ao espaço de embeddings

Antes dos embeddings, dados categóricos viviam em tabelas one-hot: um vetor alto e esparso onde cada palavra era uma coluna independente e nenhuma noção de significado existia entre elas. Embeddings substituem isso por um vetor denso no qual palavras semanticamente similares ficam perto umas das outras. O retorno é aritmética que a codificação one-hot nunca conseguiu fazer, o exemplo documentado pela AWS é Paris − France + Germany ≈ Berlin, onde a direção entre dois embeddings codifica um relacionamento.

4.2 Quem calcula a similaridade: o modelo ou o banco de dados?

Um detalhe que decide muitas pontuações: o modelo produz o vetor; o banco de dados vetorial calcula a similaridade, usando similaridade de cosseno ou k-nearest neighbours (k-NN). A recuperação em um pipeline RAG é portanto uma operação de banco de dados, e o guia de exame nomeia os armazenamentos de embedding que ele espera que você reconheça.

4.3 Os modelos de embedding e seus limites verificados

4.4 Exemplo resolvido 3: quanto um armazenamento vetorial realmente custa em bytes

O Titan Text Embeddings V2 retorna 1.024 dimensões. Assumindo floats de 32 bits (4 bytes por valor: uma suposição, não um número publicado pela AWS), um vetor é:

$$1{,}024 \times 4\ \text{bytes} = 4{,}096\ \text{bytes} \approx 4\ \text{KB}$$

Para uma base de conhecimento de 100.000 passagens:

$$100{,}000 \times 4\ \text{KB} = 400{,}000\ \text{KB} \approx 400\ \text{MB}$$

Resposta: cerca de 400 MB de payload bruto de vetores antes de sobrecarga de índice, metadados e sharding. Esse é o número que você carrega para a escolha entre OpenSearch, Aurora (pgvector), Neptune, DocumentDB e RDS for PostgreSQL: e é por isso que a redução de dimensionalidade para 512 ou 256 (ambos suportados pelo V2) é uma alavancagem legítima de custo: reduzir as dimensões pela metade reduz o payload bruto pela metade para cerca de 200 MB.

• 🔢 📚 Você sabia? Aritmética de embedding não é truque de festa: é evidência de que o espaço vetorial codifica relacionamentos como direções. Paris − France + Germany ≈ Berlin funciona porque o deslocamento "capital de" é consistente entre países. No exame isso aparece indiretamente: quando uma questão diz que vetores colocam itens semanticamente similares perto um dos outros, a resposta pretendida é quase sempre sobre similaridade de cosseno em um banco de dados vetorial, não sobre o modelo reler o texto.

---

5. Engenharia de prompt: a primeira alavancagem que você deve sempre puxar

5.1 O vocabulário de shots

5.2 A tabela de técnicas

5.3 Chain-of-thought: o que ela compra e o que ela custa

O Amazon Bedrock documenta que chain-of-thought, com a marca model reasoning no console, "pode muitas vezes melhorar a precisão do modelo dando ao modelo a chance de pensar antes de responder". O custo é igualmente explícito: latência aumentada e tokens de saída aumentados. E a exclusão importa tanto quanto o benefício: a AWS afirma que tarefas simples não são bons candidatos para chain-of-thought. Pedir a um modelo que raciocine longamente para classificar um chamado de suporte em uma de quatro filas é pagar tokens de saída sem precisão.

5.4 A árvore de decisão de engenharia de prompt

5.5 Exemplo resolvido 4: quanto few-shot prompting realmente custa

Uma instrução custa 80 tokens; um exemplo rotulado custa 60 tokens.

Resposta: um prompt de 5-shot custa 4,75× os tokens de entrada do zero-shot pela mesma única resposta. Como a AWS diz que 3 a 5 exemplos bastam para classificação simples de texto, 3 shots é o ponto ideal: você obtém controle de formato a 3,25× em vez de 4,75×. E se você então acrescentar chain-of-thought, o custo se move para o lado da saída, onde o maxTokenCount padrão do Titan Text de 512 começa a apertar; eleve-o antes de habilitar raciocínio.

• 🔢 📚 Você sabia? A orientação de engenharia de prompt da AWS esconde dois hábitos que separam um prompt que funciona de uma demo: coloque a pergunta ou instrução no fim do prompt (para que os tokens mais relevantes fiquem mais perto de onde a geração começa), e mantenha um conjunto de prompts mantido separado que você nunca mostra à equipe enquanto itera. Sem o conjunto separado, "o prompt melhorou" é uma anedota: a mesma disciplina de um conjunto de teste separado no ML clássico, aplicada a texto.

---

6. Parâmetros de inferência: pilotando o próximo token

6.1 A tabela completa de parâmetros

Cada número aqui é verificado contra as páginas Inference response generation e Titan Text do Bedrock.

6.2 Os padrões que você deve saber de cor

6.3 Exemplo resolvido 5: três cargas de trabalho, três conjuntos de parâmetros

Uma equipe roda três trabalhos no mesmo modelo Titan Text Express. Assuma o mesmo prompt e o mesmo teto de saída padrão de 512 tokens.

1. Extração de cláusulas contratuais (deve ser auditável): temperature 0,0, top-p reduzido de 0,9 para 0,1 to 0,3. Efeito: a distribuição fica mais íngreme, o pool de candidatos encolhe, e re-execuções convergem na mesma extração.
2. Brainstorm de manchetes de campanha: temperature 1,0, top-p deixado em 0,9. Efeito: a distribuição achata, mais da cauda fica acessível, e a diversidade sobe: ao custo da reprodutibilidade.
3. Raciocínio chain-of-thought sobre uma resposta de 400 tokens: temperature 0,2, mas maxTokenCount elevado de 512 para pelo menos 1.024, porque tokens de raciocínio são tokens de saída. Deixar o padrão em vigor trunca a cadeia no meio da derivação.

Resposta: determinismo é comprado com temperature e top-p; criatividade com temperature; e capacidade de raciocínio com max tokens, o parâmetro que mais frequentemente é esquecido, porque a falha parece um bug em vez de uma configuração.

---

7. Janelas de contexto: o orçamento que falha silenciosamente

7.1 O que realmente cabe

A janela de contexto é o número máximo de tokens que um modelo considera de uma vez, e ela é um orçamento para tudo na chamada:

$$\text{context window} \ge \text{system prompt} + \text{client input} + \text{RAG context} + \text{output}$$

Defina maxTokenCount por subtração: janela − tokens de entrada − margem de segurança. Nunca por intuição.

7.2 O ring buffer FIFO e o Context Window Overflow

O blog de segurança da AWS descreve a janela de contexto como um ring buffer FIFO. Uma vez cheio, cada novo token silenciosamente expulsa o token mais antigo, nenhum erro, nenhum aviso, apenas comportamento derivando. O fenômeno tem um nome na AWS: Context Window Overflow (CWO). O horror prático é que o system prompt geralmente é o conteúdo mais antigo, então sob CWO as instruções que definem o comportamento do seu agente são a primeira coisa a desaparecer, e a aplicação continua retornando 200 OK enquanto ignora suas próprias regras.

7.3 Exemplo resolvido 6: um orçamento de janela de contexto

System prompt 400 + passagens RAG 1.600 + histórico de conversa 900 + pergunta 100:

$$400 + 1{,}600 + 900 + 100 = 3{,}000\ \text{input tokens}$$

Com maxTokenCount no máximo do Titan Text Premier de 3.072, o total vira $3{,}000 + 3{,}072 = 6{,}072$ tokens de demanda. Se a janela do modelo for menor que isso, o overflow não levanta exceção: os ~3.000 tokens mais antigos (começando pelo system prompt) são expulsos conforme a geração procede, e o comportamento deriva em vez de falhar.

Correção, em ordem: rode CountTokens no prompt exato → defina maxTokenCount = janela − entrada − margem → encurte ou re-ordene passagens RAG → resuma voltas mais antigas do histórico.

7.4 O fluxo de geração ponta a ponta

• 🔢 📚 Você sabia? A janela de contexto não é publicada como um número fixo por família de modelo nas páginas que a AWS verificou para este digest, então itens "qual modelo tem a maior janela?" são dirigidos por anúncios e devem ser re-checados perto do dia do exame. O que é verificado e estável: máximos de maxTokenCount do Titan Text (4.096 / 8.192 / 3.072), Titan Embeddings 8K tokens, Embeddings V2 8.192 tokens, fine-tuning do Llama soma de entrada + saída 16.000 (10.000 para o 90B), e fine-tuning do Claude 3 Haiku 32.000 tokens. Orcue a partir desses números, não de uma manchete de blog.

---

8. Modelos de fundação por modalidade, e como imagens são feitas

8.1 A tabela de modalidades

8.2 Como um modelo de difusão produz uma imagem

O treinamento de difusão ensina a um modelo a remover ruído que foi adicionado a imagens reais. A geração roda esse processo ao contrário: começa a partir de ruído aleatório e denoisa iterativamente, cada passo condicionado ao embedding do prompt de texto. Difusão latente faz o trabalho em um espaço latente comprimido (uma U-Net, ou um transformer denoiser) e só então decodifica para pixels.

Amazon Nova Canvas e Nova Reel são modelos de difusão latente com backbones de transformer, frequentemente chamados de diffusion transformers, construídos a partir de três partes: um VAE que converte entre pixels e tokens visuais, um text encoder para o prompt, e um transformer denoiser. O Amazon Titan Image Generator é um FM de difusão condicionado por texto: ele codifica o prompt, casa vetores em um espaço compartilhado de embedding texto/imagem, e transforma uma codificação aleatória de baixa resolução na imagem final.

8.3 Exemplo resolvido 7: entradas de visão também são aritmética de tokens

A fórmula publicada pela AWS para tokens de imagem no fine-tuning de visão do Llama é:

$$\text{tokens} = \min(2, \max(H // 560,\ 1)) \times \min(2, \max(W // 560,\ 1)) \times 1601$$

Contra a cota de fine-tuning de soma de entrada-mais-saída de 16.000 do Meta Llama 3.2: uma imagem de 1.120 × 1.120 = 6.404 ✓, duas = 12.808 ✓, três = 19.212 ✗: acima da cota.

Resposta: duas imagens grandes cabem, três não cabem, e o comportamento de clamp significa que uma imagem pequena ainda custa pelo menos 1.601 tokens.

• 🔢 📚 Você sabia? O Amazon Titan Image Generator sai com uma marca d'água invisível ativada por padrão e aceita no máximo 5 imagens de referência: ambos são fatos com forma de exame porque respondem a duas perguntas diferentes: "como a AWS torna conteúdo gerado identificável?" (marca d'água, um controle de transparência) e "quanta personalização a API aceita?" (5 imagens, não 50). Pareie qualquer um com a Responsible AI Lens da Seção 11 quando uma questão pedir um artefato de transparência.

8.4 Atualizações de 2026 (em outubro de 2026)

A tabela de modalidades em 8.1 é a linha de base do guia de exame; o elenco por trás dela mudou duas vezes dentro da janela que a AWS verificou para esta lição. Tudo abaixo vem do AWS What's New, do guia do usuário do Amazon Bedrock e da própria cobertura do re:Invent 2025 da AWS: apenas funcionalidades e datas que a AWS publicou ela mesma.

Os Guardrails cresceram ao lado do elenco de modelos: a AWS agora documenta code safeguards, uma ApplyGuardrail API independente, filtra um prompt para qualquer modelo sem invocar um FM, e cross-account safeguards que impõem um guardrail em uma AWS Organization. O conjunto de seis políticas e as alegações publicadas (88% de bloqueio de conteúdo prejudicial, 99% de precisão de Automated Reasoning) estão inalterados, então a Seção 11 ainda responde a toda questão de política; o que mudou é onde essas políticas podem ser aplicadas.

• 🔢 📚 Você sabia? O guia de exame v1.1 tornou a precificação baseada em tokens um objetivo explícito (2.1.4), o exame agora espera que você raciocine sobre como contagens de tokens e formatos de precificação moldam custo e desempenho, o que é precisamente a aritmética já praticada nas Seções 2, 5 e 7. A AWS afirma que mudanças no guia aparecem no exame cerca de um mês após a publicação, então tudo que o v1.1 acrescentou está ao vivo: o formato está inalterado em 65 questões (50 avaliadas + 15 não avaliadas), 90 minutos, 700/1000 para passar.

---

9. O espectro de customização: prompt primeiro, modelo personalizado por último

9.1 A escada que a AWS publica

O próprio resumo da AWS: a maioria das cargas de trabalho nunca passa do Passo 3. Essa frase vale mais no exame que qualquer técnica individual, porque ela converte "qual customização devo usar?" em "qual é a degrau mais barato que corrige o problema?": e cada degrau mais barato que você pula é custo e latência que você paga por nada.

9.2 O vocabulário de fine-tuning da Tarefa 3.3

9.3 Fine-tuning por reforço e destilação: os números

Reinforcement fine-tuning (RFT) usa funções de recompensa, uma função AWS Lambda implementando verificação baseada em regras (RLVR), ou um model-as-judge (RLAIF), com o método de otimização GRPO. A AWS alega ganho de precisão de até 66%. Guardrails na própria funcionalidade: mínimo de 100 registros, máximo de 20.000 prompts para modelos Nova, e o próprio conselho da AWS de pular o RFT quando a recompensa da linha de base já exceder 95%.

Model Distillation (GA maio de 2025) treina um aluno menor nas saídas do professor. A AWS alega que o aluno pode ser até 500% mais rápido, 75% mais barato, com menos de 2% de perda de precisão.

9.4 Exemplo resolvido 8; esta equipe deve fazer fine-tune?

Uma equipe de suporte quer que seu assistente adote o estilo da casa. Recompensa de avaliação da linha de base em seu conjunto de prompts mantido separado: 91%.

1. Linha de base 91% < 95%, então o RFT está tecnicamente disponível: mas ele precisa de ≥ 100 registros rotulados e adiciona treinamento e manutenção da função de recompensa.
2. A escada da AWS diz tentar os passos 1 to 3 primeiro: engenharia de prompt (regras de estilo da casa no system prompt) e RAG (a base de conhecimento de respostas passadas).
3. Se o estilo ainda falhar após os passos 1 to 3, fine-tuning (passo 6) é o degrau correto: e a equipe precisa de um dataset rotulado, não de mais ajuste de temperature.

Resposta: não comece no passo 6. Se a recompensa da linha de base algum dia chegar acima de 95%, a AWS diz explicitamente para pular o RFT inteiramente.

• 🔢 📚 Você sabia? O espectro de customização é a resposta direta à forma recorrente do exame "a equipe quer fazer fine-tune, o que eles devem fazer primeiro?": e o ganho de 66% de precisão do RFT da AWS, o 500% mais rápido / 75% mais barato / <2% de perda de precisão na destilação e o "a maioria das cargas de trabalho nunca passa do passo 3" são todos alegações da AWS reproduzidas como publicadas. Use-os como direções (destilação é mais barata, RFT pode ajudar tarefas difíceis, prompting e RAG vêm primeiro) e não como promessas que a sua arquitetura deve entregar.

---

10. Avaliando IA generativa

10.1 Três famílias de avaliação no Amazon Bedrock Model Evaluation

Datasets embutidos incluem Real Toxicity, BOLD, TREX, WikiText-2, Gigaword, BoolQ, Natural Questions e TriviaQA.

10.2 As regras do juiz que aparecem verbatim como respostas

• A AWS alega que LLM-as-a-judge entrega economia de custo de até 98% versus revisão humana.
• Melhor prática: usar um modelo avaliador de uma família diferente da do gerador: um juiz da mesma família herda as mesmas pontos cegos.
• Faithfulness é a métrica de alucinação: a resposta permanece dentro do contexto recuperado?
• Revisão humana não é substituída; ela é camada: métricas de juiz para escala, workflows humanos para aprovação.

10.3 As métricas clássicas de geração de texto da Tarefa 3.4

10.4 Métricas específicas de RAG

A tríade RAG é relevância de contexto, faithfulness e relevância de resposta; a AWS acrescentou citation precision e citation coverage em 2025, ambas pontuadas de 0 to 1 (coverage é N/A quando a resposta é inteiramente infiel). O caso publicado da AWS: chunking melhor elevou a relevância de contexto de 67% para 93% e removeu alucinações sem mudar o prompt: a evidência mais clara disponível de que em RAG, a qualidade da recuperação geralmente é o bug, e o prompt não é.

10.5 Exemplo resolvido 9: juiz mais humano, precificado

Uma equipe deve avaliar 2.000 gerações:

1. LLM-as-a-judge pontua as 2.000 em correção, completude, faithfulness e segurança: a AWS alega economia de custo de até 98% versus fazer à mão.
2. Revisão humana em uma amostra de 10% de 200 tarefas ao $0.21 documentado por tarefa concluída: $200 \times 0.21 = $42.00$.
3. O modelo juiz vem de uma família diferente da do gerador, então modos de falha compartilhados não se cancelam.

Resposta: juiz em escala para cobertura, humanos a $42.00 para uma amostra de 200 tarefas para autoridade, o padrão que a AWS documenta em vez de avaliação só com juiz ou só com humanos.

---

11. Guardrails, mitigação de alucinação e IA responsável

11.1 As seis políticas dos Guardrails

A AWS alega: 88% de bloqueio de conteúdo prejudicial, 99% de precisão de validação de Automated Reasoning, e mais de 75% de respostas alucinadas filtradas pelas checagens de fundamentação.

11.2 Automated Reasoning checks: os limites que valem a pena memorizar

11.3 A escada de mitigação de alucinação: na ordem da AWS

A AWS documenta exatamente três rotas, nesta sequência:

1. Refinar ou otimizar o prompt: mais barata, sem infraestrutura.
2. Usar RAG para fornecer dados relevantes: fundamenta a resposta nos seus documentos.
3. Tentar um modelo diferente: alguns modelos alucinam menos na sua carga de trabalho.

Então, no topo da escada, contextual grounding checks nos Guardrails detectam respostas não suportadas pela fonte (a AWS alega >75% filtradas).

11.4 Exemplo resolvido 10: quanto 75% de filtragem realmente te deixa?

Um chatbot de produção emite 1.000 respostas por dia, e a equipe habilita apenas contextual grounding checks:

$$1{,}000 \times (1 - 0.75) = 250$$

Resposta: cerca de 250 respostas não fundamentadas ainda passam a cada 1.000 quando as checagens de fundamentação são o único controle: e é por isso que a AWS camada controles: content filters a 88%, Automated Reasoning a 99% em violações de política, trabalhos de avaliação antes da liberação, e revisão humana para os casos que restam. Nenhum percentual isolado nesta seção substitui a pilha.

11.5 As dimensões de IA responsável e seus artefatos

A AWS avalia sistemas de IA generativa em oito dimensões, fairness, explainability, veracity/robustness, governance, transparency, privacy & security, safety e controllability, que são codificadas na AWS Well-Architected Responsible AI Lens. O artefato de transparência que a AWS publica para seus próprios serviços é o AI Service Card, e o mesmo vocabulário da lens é o que uma questão "qual dimensão isso preocupa?" está citando.

• 🔢 📚 Você sabia? Os percentuais publicados de guardrails da AWS (88% / 99% / >75%), o ganho de 66% do RFT, a economia de 98% do LLM-as-a-judge, a alegação de destilação 500% mais rápido / 75% mais barato e o caso de chunking 67% → 93% são todos alegações da AWS com suas próprias metodologias: eles são reproduzidos aqui como a AWS os publica. No exame, eles funcionam como pistas de ordenação (qual controle é mais forte, qual passo vem primeiro), não como garantias; trate qualquer opção que transforma uma alegação em absoluto como suspeita.

---

12. Veredito comparativo

---

13. Armadilhas do exame para esta lição

---

14. Casos Reais

Tudo até aqui é mecanismo, como tokens, recuperação, parâmetros de inferência e Guardrails se comportam. Esta seção é evidência: implantações de IA generativa publicadas pela AWS, cada uma com os serviços usados, os números que a AWS e o cliente imprimiram, e a fonte. Leia-as como exemplos de padrão para o Domínio 3 (Aplicações de Modelos de Fundação, 28%): o exame raramente pede o nome de uma empresa, mas ele constantemente pergunta qual forma de arquitetura entrega qual resultado, e estas são as formas que a própria AWS publica.

14.1 Seis implantações de IA generativa, com serviços e números

14.2 Os três casos dos quais o exame vai emprestar

Sun Finance: OCR e raciocínio são trabalhos separados. O primeiro protótipo enviou fotografias de ID direto a um LLM e foi rejeitado a 61,8% no geral (43% em números de ID); a AWS atribui a falha a proteções de privacidade que bloqueiam extração direta de PII. Separar as preocupações: Textract lê, Claude estrutura, regras validam: produziu 85% na segunda tentativa e 90,80% no pipeline publicado, com −91% de custo por documento e 20 horas → menos de 5 segundos por caso. Essa é a escada de mitigação da Seção 11 aplicada antes que os parâmetros sejam tocados: corrija o pipeline, não a temperature.

Nippon India: recuperação vence ajuste de parâmetro. RAG ingênuo degradou conforme o volume de documentos cresceu e produziu alucinações, então a equipe engenheirou a recuperação: FM-como-parser, reformulação de consulta, multi-query RAG, modelos reranker, GraphRAG, filtragem por metadados: e camadou Bedrock Guardrails e citações por cima: precisão de +>95%, alucinação de −90 to 95%, relatórios caindo de 2 dias para cerca de 10 minutos. A AWS sinaliza todos estes como funcionalidades de produto GA, não código exclusivo do cliente. A leitura com forma de exame: quando um assistente fundamentado alucina, a escada ainda é prompt → RAG → modelo diferente, e a qualidade da recuperação geralmente é o bug (Seção 10.4).

Adobe: chunking é um hiperparâmetro mensurável. Quatro estratégias de chunking foram benchmarkadas no próprio conjunto de teste da Adobe; chunks de 400 tokens com 20% de sobreposição foram tanto os mais simples quanto os mais precisos, dando +20% de precisão de recuperação sobre a busca incumbente quando embutidos com Titan Text Embeddings V2 no Amazon OpenSearch Service. É a confirmação ao vivo da Seção 2.1: a qualidade do chunking, não a redação do prompt, é a maior alavancagem em um sistema RAG.

14.3 Antes e depois: os números que valem a pena carregar para o exame

• 🔢 📚 Você sabia? As falhas documentadas são a parte com mais forma de exame destes casos: a extração só com LLM da Sun Finance (61,8%), a primeira tentativa do Prime Focus Technologies com APIs externas de LLM cuja latência era alta demais para tagging ao vivo, e os 4 meses de visão computacional interno da Chronomics que nunca atingiram a meta antes de o Rekognition Custom Labels ser entregue em 3 to 4 semanas a 96,5% de precisão / F1 de 97,9%. Todos os três re-enunciam a Seção 12 em forma de produção: escolha o nível deliberadamente (pré-construído → personalizado gerenciado → generativo), e avalie antes de lançar: o Epilot escolheu seu modelo com Bedrock Evaluations em vez de em um notebook.

---

Perguntas de Prática (Practice Questions)

---