Algoritmos de ML e Avaliação de Modelos na AWS

Um algoritmo é fácil de nomear e difícil de justificar. O exame AIF-C01 quase nunca pergunta "qual algoritmo existe": ele pergunta "o negócio precisa de X, os rótulos se parecem com Y, e a AWS dá a você Z; justifique o par e defenda a métrica." A Tarefa 2.1 pede que você selecione técnicas de ML apropriadas para casos de uso específicos (regressão, classificação, clustering), a Tarefa 2.2 pede que você descreva aprendizado supervisionado, não supervisionado e por recompensa, e a Tarefa 1.4 pede que você descreva métricas de desempenho do modelo (acurácia, AUC, F1) e métricas de negócio (custo por usuário, custo de desenvolvimento, retorno do cliente, ROI). Esta lição transforma essas três frases em um sistema de decisão operável.

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

• escolher entre aprendizado supervisionado, não supervisionado e por recompensa apenas a partir do formato dos dados;
• mapear dezesseis famílias de algoritmos para seu caso de uso, sua rota AWS e seu hiperparâmetro-chave;
• afirmar quais algoritmos são embutidos no SageMaker, e qual deles famosamente não é;
• computar acurácia, precisão, revocação, F1, MAE, MSE, RMSE e R² a partir de uma matriz de confusão ou um conjunto de resíduos sem usar calculadora;
• escolher a divisão certa (70/30, 60/20/20, holdout 20 to 30%, k-fold 5 to 10) e defendê-la;
• diagnosticar underfitting vs. overfitting e aplicar o remédio prescrito pela AWS na direção correta;
• atacar desbalanceamento de classes com as três alavancas documentadas pela AWS (reposicionamento de pesos, reamostragem, troca de métrica);
• responder dez perguntas no estilo do exame escritas na voz oficial.

---

1. Os três paradigmas de aprendizado e como a AWS os implementa

1.1 Guia de seleção: leia os dados, não o jargão

O exame decide o paradigma para você com uma pista: o que os dados de treinamento contêm? Pares rotulados de entrada/saída apontam para aprendizado supervisionado; features sem respostas apontam para não supervisionado; um sinal de recompensa voltando de um ambiente aponta para aprendizado por recompensa.

A distinção em que os itens do exame mais se apoiam: o aprendizado nunca supervisionado não vê um conjunto de validação com rótulos. A própria documentação do k-means do SageMaker diz que ele "não usa um conjunto de dados de validação" porque não há nada contra o que validar: ele aceita um canal de teste e reporta apenas métricas baseadas em distância. Uma questão que oferece validation:f1 para um trabalho de clustering está testando se você percebeu.

1.2 Como cada paradigma se parece como um fluxo de trabalho

1.3 Aprendizado por recompensa no SageMaker: os fatos específicos

O aprendizado por recompensa (RL) é o paradigma que o exame testa por reconhecimento de nome em vez de por computação. As afirmações verificadas da AWS são:

• o SageMaker AI suporta RL em TensorFlow e Apache MXNet;
• ele suporta os toolkits Intel Coach e Ray RLlib;
• o FAQ do SageMaker lista algoritmos como DQN, PPO, A3C e muitos outros;
• o repositório de contêineres de RL aberto distribui imagens do Vowpal Wabbit (VW);
• os trabalhos eram lançados com o RLEstimator.

Se uma questão descreve um agente aprendendo uma política para maximizar a recompensa acumulada em uma simulação, a resposta é SageMaker RL com Coach ou Ray RLlib: nunca k-means, nunca Autopilot, nunca PCA.

• 📚 Você sabia? O suporte a RL do SageMaker é deliberadamente estreito: apenas TensorFlow e MXNet para frameworks. Se uma opção oferece "SageMaker RL com PyTorch", é um distrator: a lista de frameworks documentada não inclui PyTorch, mesmo sendo o PyTorch totalmente suportado para deep learning supervisionado através dos contêineres de deep learning pré-construídos.

Verifique sua seleção de paradigma:

---

2. A matriz algoritmo → caso de uso → rota AWS

Esta é a tabela mais examinável do Domínio 2. Leia-a como três perguntas respondidas de uma vez: qual família, qual caso de negócio, onde roda na AWS.

2.1 A matriz completa

2.2 Do tipo de tarefa à família de algoritmos

2.3 As listas de embutidos que você deve ser capaz de reproduzir

A AWS organiza seus algoritmos embutidos em grupos supervisionados, não supervisionados e de recompensa. O conjunto tabular supervisionado é o que o exame mais reutiliza:

Embutidos tabulares (classificação ou regressão): AutoGluon-Tabular, CatBoost, Factorization Machines, k-NN, LightGBM, Linear Learner, TabTransformer, XGBoost.

A documentação do Linear Learner é explícita sobre o que ele é: ele "aprende uma função linear para regressão ou uma função de limiar linear para classificação", o que o torna a resposta embutida sempre que uma questão diz regressão logística ou regressão linear.

Embutidos não supervisionados: PCA (redução de dimensionalidade), K-Means (clustering), Random Cut Forest (detecção de anomalia), IP Insights (anomalia de endereço IP), LDA e Neural Topic Model (modelagem de tópicos).

• 📚 Você sabia? A AWS publica listas de algoritmos, nunca uma contagem. Qualquer opção que começa com "O SageMaker tem exatamente N algoritmos embutidos" é um número inventado: as listas mudam conforme algoritmos são adicionados (AutoGluon-Tabular e TabTransformer são adições recentes ao conjunto tabular) e removidos. Aprenda a pertinência das listas, não um total.

---

3. As famílias supervisionadas: lineares, árvores, boosting e redes neurais

3.1 Linear Learner, o cavalo de batalha de regressão e classificação

O Linear Learner é a resposta para "qual embutido faz regressão linear ou logística?" e carrega três propriedades examináveis:

Essa regra de ajuste é uma resposta gratuita sempre que uma opção diz "ajustar contra a métrica de treinamento". O remédio documentado é o oposto: ajuste na métrica de validação.

3.2 Gradient boosting: três embutidos mais um wrapper AutoML

O gradient boosting é representado no SageMaker por três algoritmos embutidos mais uma opção de ensemble em pilha:

Detalhes do XGBoost que o exame reutiliza:

• o contêiner cobre XGBoost 1.0, 1.2, 1.3, 1.5, 1.7 e 3.0;
• num_round é obrigatório (mais num_class para multi:softmax e multi:softprob);
• o objetivo padrão é reg:squarederror, então um trabalho do XGBoost não configurado é um trabalho de regressão;
• o treinamento em GPU é habilitado com tree_method=gpu_hist;
• os hiperparâmetros de maior impacto para ajuste são alpha, min_child_weight, subsample, eta e num_round.

3.3 O menu de métricas do XGBoost: doze objetivos com direções

O ajuste automático de modelo precisa de um objetivo e uma direção. O XGBoost expõe doze métricas de validação, e a direção é parte da resposta:

Duas armadilhas vivem nesta tabela. Primeiro, as métricas de ranking (map, ndcg) são Maximizar enquanto toda métrica de erro é Minimizar: selecionar validation:rmse com direção Maximizar ajustaria o modelo para o pior resultado. Segundo, merror e mlogloss são os irmãos multiclass de error e logloss; confundi-los em uma opção é um padrão de distrator comum.

3.4 Árvores, florestas e redes neurais: as rotas que exigem código

O Object2Vec merece um gancho de memória específico: ele usa entropia cruzada para classificação e erro quadrático médio (MSE) para regressão, o mesmo algoritmo troca sua função de loss com a tarefa, que é exatamente o tipo de detalhe que uma opção pode inverter para produzir uma resposta errada.

---

4. As famílias não supervisionadas: clustering, redução, anomalia e tópicos

4.1 K-Means: não existe conjunto de validação

O K-Means é o favorito do exame para testar se você entende que o aprendizado não supervisionado não tem conjunto de validação com rótulos. Os pontos da documentação verificada:

• "Como é não supervisionado, ele não usa um conjunto de dados de validação… Mas ele aceita um conjunto de dados de teste."
• Métricas de objetivo: test:msd (distâncias quadradas médias) e test:ssd: ambas Minimizar;
• a inferência retorna closest_cluster e distance_to_cluster;
• hiperparâmetros: k, init_method (random ou k-means++), mini_batch_size.

Note a direção: métricas de distância são minimizadas, porque uma menor distância quadrada significa clusters mais compactos. Todo objetivo de clustering baseado em distância no SageMaker aponta na mesma direção.

4.2 Silhueta: uma métrica real que não é uma métrica do SageMaker

O coeficiente de silhueta varia de −1 a 1; um valor próximo de 1 significa que os pontos estão apertados dentro do próprio cluster e longe dos outros clusters. A orientação da AWS é parear silhueta com inércia, e deixar claro que o SageMaker não a emite: você a computa você mesmo fora do trabalho de treinamento. Uma questão que oferece "selecionar validation:silhouette como objetivo de ajuste" está testando precisamente esse limite.

4.3 PCA: três hiperparâmetros obrigatórios

O PCA é embutido, e sua configuração é examinável porque é curta:

O PCA produz a mean, a matriz de autovetores v e os valores singulares s: que é como você depois reconstrói ou projeta dados com os componentes que manteve.

4.4 Detecção de anomalia e modelagem de tópicos

• 📚 Você sabia? test:msd e test:ssd não são sinônimos intercambiáveis: msd é a distância quadrada média e ssd é a soma das distâncias quadradas ao centróide. Em um conjunto de teste de n linhas, ssd = msd × n, então ssd cresce com o tamanho do conjunto de dados enquanto msd não cresce. Ambas são minimizadas, e ambas são objetivos de clustering válidos, mas apenas msd é comparável entre conjuntos de teste de tamanhos diferentes.

---

5. Quatro rotas para um algoritmo

A AWS documenta exatamente quatro maneiras de colocar um algoritmo em execução, e o exame testa se você consegue nomeá-las em ordem crescente de esforço.

5.1 O fluxo de decisão

5.2 BYOC: as três regras de contêiner não negociáveis

Se uma questão empurra você para a Rota 4, três fatos documentados decidem a resposta:

1. o pacote de toolkit sagemaker-training é obrigatório;
2. ENV SAGEMAKER_PROGRAM train.py é a única variável de ambiente obrigatória: ela nomeia o ponto de entrada que o SageMaker invoca;
3. /opt/ml e todos os seus subdiretórios são reservados pelo treinamento do SageMaker, então entradas, artefatos de modelo e saída devem seguir esse layout.

Duas mais regras de contêiner aparecem como distratores:

• o SageMaker sobrescreve o CMD padrão da sua imagem anexando o argumento train;
• imagens GPU devem ser compatíveis com nvidia-docker: embale o CUDA toolkit, mas não embale os drivers NVIDIA, o host os fornece.

5.3 Janelas de suporte de contêiner são datas examináveis

A AWS publica um cronograma explícito de GA → fim-de-patch para seus contêineres de algoritmos. O padrão que vale a pena memorizar é o formato: cerca de um ano de suporte de patch após a disponibilidade geral, e é por isso que um item de exame datado em 2026 pode legitimamente referenciar uma versão de 2025 atingindo o fim de patch no mesmo ano.

---

6. Métricas de avaliação: fórmulas, direções e quando usá-las

6.1 A folha de fórmulas

O resumo da própria AWS sobre a relação precisão/revocação vale a pena memorizar textualmente: precisão corta falsos positivos, revocação corta falsos negativos, e F1 é a média harmônica dos dois.

6.2 Escolhendo uma métrica a partir da matriz de confusão

6.3 Matriz de confusão trabalhada nº 1: dados de churn equilibrados

Um modelo de churn é avaliado em 200 clientes: VP = 80, FP = 20, FN = 10, VN = 90.

$$\text{Acurácia} = \frac{VP+VN}{N} = \frac{80+90}{200} = \frac{170}{200} = 0.85$$ $$\text{Precisão} = \frac{VP}{VP+FP} = \frac{80}{100} = 0.80$$ $$\text{Revocação} = \frac{VP}{VP+FN} = \frac{80}{90} = 0.889$$ $$F1 = \frac{2VP}{2VP+FP+FN} = \frac{160}{190} = 0.842$$

Leitura: o modelo captura cerca de 89% dos churners, mas 20 dos seus 100 alertas estão errados. Uma acurácia de 0.85 é respeitável aqui porque as classes estão razoavelmente equilibradas (90 positivas, 110 negativas).

6.4 Matriz de confusão trabalhada nº 2: a armadilha do 1% de fraude

Um modelo de fraude é avaliado em 10.000 transações das quais apenas 100 são fraudulentas: VP = 85, FP = 40, FN = 15, VN = 9.860.

$$\text{Acurácia} = \frac{85+9860}{10000} = \frac{9945}{10000} = 99.45\%$$

Ainda assim, um modelo que sempre prevê "não fraude" já pontua:

$$\frac{9900}{10000} = 99.0\%$$

Então 99,45% de acurácia compra 0,45 pontos percentuais sobre uma linha de base inútil. As métricas que importam:

$$\text{Precisão} = \frac{85}{85+40} = \frac{85}{125} = 0.68$$ $$\text{Revocação} = \frac{85}{85+15} = \frac{85}{100} = 0.85$$ $$F1 = \frac{2 \times 85}{170+40+15} = \frac{170}{225} = 0.756$$

Leitura: 32% dos alertas de fraude são falsos alarmes, o modelo perde 15 de 100 fraudes, e a acurácia manchete é quase sem significado. Este é o padrão de avaliação mais repetido no material próprio de detecção de fraude da AWS.

---

7. Divisões de dados, validação cruzada e testes A/B

7.1 Os padrões de divisão publicados

O motivo declarado da AWS para reter dados é uma frase que vale a pena reproduzir em uma resposta de exame: avaliar nos dados de treinamento "recompensa modelos que podem 'lembrar' dos dados de treinamento, em vez de generalizar a partir deles."

7.2 Aritmética de divisão e validação cruzada em 100.000 linhas

7.3 Validação cruzada do Autopilot: o limiar de 50.000 instâncias

Com 40.000 instâncias de treinamento (≤ 50.000, então o modo HPO aplica k-fold automático com k = 5):

1. a divisão automática 80/20 dá 32.000 treino / 8.000 validação;
2. cada um dos 5 folds treina em 4/5 × 32.000 = 25.600 instâncias;
3. cada fold valida em 6.400 instâncias;
4. as cinco pontuações de validação são mediadas no objetivo reportado.

Um conjunto de dados de 60.000 instâncias excede o limiar ≤ 50.000, então o k-fold automático no modo HPO não é acionado: enquanto o modo ensemble roda validação cruzada independentemente do tamanho ao lado de sua divisão automática 80/20.

7.4 Como o loop se encaixa

Verificação interativa: as fórmulas que você não deve precisar procurar:

---

8. Underfitting, overfitting e os controles de ajuste que os corrigem

8.1 O diagnóstico

A assinatura oficial de overfitting da AWS é curta: alta acurácia de treinamento mais baixa acurácia de teste. A direção do remédio importa tanto quanto o remédio: overfitting recebe mais regularização, underfitting recebe menos. Invertê-los é um distrator clássico.

8.2 Os controles de ajuste que previnem overfitting mecanicamente

Quatro controles documentados fazem o trabalho que um humano faria a olho:

1. Ajuste em uma métrica de validação, não em uma métrica de treinamento. A documentação do Linear Learner afirma isso como recomendação, não como preferência.
2. Early stopping. A cada época, a métrica de objetivo é comparada com a mediana das médias móveis de trabalhos anteriores; trabalhos com desempenho pior param cedo: a AWS diz que isso "ajuda você a evitar overfitting do seu modelo". A configuração é early_stopping_type='Auto'.
3. Hyperband também termina cedo trabalhos com desempenho fraco, alocando o orçamento para configurações promissoras.
4. Direção da regularização: aumente-a para overfitting, diminua-a para underfitting.

8.3 Ordene a sequência de diagnóstico

• 📚 Você sabia? O early stopping no Ajuste Automático de Modelo do SageMaker não compara seu trabalho com um alvo fixo: ele compara o valor de objetivo de cada época com a mediana das médias móveis de todos os trabalhos anteriores. Isso torna o limiar adaptativo: um trabalho inicial incomumente forte eleva a barra para tudo que segue, e um trabalho inicial fraco a baixa. A lista de suporte do early stopping traz um carimbo de "atual em 13 de dezembro de 2018", então trate qualquer afirmação sobre quais algoritmos o suportam como histórica.

---

9. Dados desbalanceados: três alavancas e os números por trás delas

A AWS documenta três alavancas independentes para desbalanceamento. Uma resposta forte usa pelo menos duas delas juntas.

9.1 As três alavancas

9.2 Aritmética de pesos de classe

Caso A: uma divisão binária de 98% / 2%. Para fazer a classe minoritária contar tanto quanto a majoritária:

$$0.02 \times w = 0.98 \implies w = \frac{0.98}{0.02} = 49$$

Então o positive_example_weight_mult='balanced' do Linear Learner em um conjunto 98/2 produz um peso positivo de 49.

Caso B, o próprio conjunto de dados de fraude da AWS. Com 284.807 exemplos dos quais 492 são fraudulentos (0,173%), a variante XGBoost da AWS usa a regra da raiz quadrada em vez da razão bruta:

$$\text{scale\_pos\_weight} = \sqrt{\frac{284{,}315}{492}} = \sqrt{577.9} \approx 24$$

A razão bruta seria 577,9; o amortecimento da raiz quadrada mantém o treinamento estável enquanto ainda diz ao modelo que a fraude importa. A AWS reporta adicionalmente que elevar o Kappa de Cohen acima de 0,8 seria "geralmente muito favorável" naquele problema.

9.3 O que a ponderação custa, o trade-off documentado

Ponderar não é de graça. O próprio exemplo multiclass da AWS mostra os dois lados:

A lição que o exame quer: você trocou 13 pontos de acurácia por um modelo que realmente reconhece a classe rara. Em um problema desbalanceado, essa troca geralmente está correta, mas deve ser uma decisão, não um efeito colateral.

9.4 A troca de métrica, lado a lado

---

10. Avaliação por tipo de tarefa: a tabela de consulta

10.1 Métricas de foundation models: o que o Clarify realmente computa

Dois números de amostragem são examináveis: o Clarify avalia 100 registros por padrão para a maioria das tarefas e 300 para conhecimento factual. E um nome de métrica de viés é único do Clarify: CI (Class Imbalance).

• 📚 Você sabia? A acurácia de classificação balanceada tem um glossário oficial da AWS: "a soma da revocação e da taxa de verdadeiro negativo dividida por 2." Para um problema multiclass ela degrada graciosamente na média da revocação por classe: que é exatamente por que ela sobrevive ao desbalanceamento de classes enquanto a acurácia simples não sobrevive: cada classe contribui igualmente independentemente de quantas linhas ela possui.

---

11. Juntando os três eixos

O exame quase sempre força uma escolha sobre três eixos de uma vez: a família de algoritmos, o tipo de tarefa, e a ferramenta da AWS que implementa o par. Acertar dois dos três não é suficiente.

---

12. Exemplos trabalhados com números

Exemplo trabalhado 1: métricas de regressão do zero. Valores reais $y = [100, 120, 140, 160, 180]$, previsões $\hat{y} = [110, 115, 150, 155, 190]$, então os erros são $[10, -5, 10, -5, 10]$.

• $\text{MAE} = (10+5+10+5+10)/5 = 40/5 = \mathbf{8.0}$
• $\text{MSE} = (100+25+100+25+100)/5 = 350/5 = \mathbf{70}$
• $\text{RMSE} = \sqrt{70} \approx \mathbf{8.37}$: de volta às próprias unidades do alvo
• $\bar{y} = 140$, então $SS_{tot} = 1600+400+0+400+1600 = 4000$, e $R^2 = 1 - 350/4000 = \mathbf{0.9125}$

O padrão: o MSE pune os dois erros de 10 pontos quatro vezes mais duramente que os erros de 5 pontos (100 vs. 25), e o RMSE desfaz essa elevação ao quadrado para que o número possa ser citado em dólares ou dias.

Exemplo trabalhado 2: aritmética de divisão em 100.000 linhas. O padrão 70/30 dá 70.000 / 30.000; o recomendado 60/20/20 dá 60.000 / 20.000 / 20.000; o holdout de 20 to 30% do SageMaker reserva 20.000 to 30.000 linhas para teste; k = 10 dá 90.000 treino / 10.000 validação por fold em 10 modelos cujas métricas você media.

Exemplo trabalhado 3: matemática de validação cruzada do Autopilot. Conjunto de dados de 40.000 instâncias (≤ 50.000 → k-fold automático, k = 5, no modo HPO): 80/20 dá 32.000 treino / 8.000 validação; cada um dos 5 folds treina em 4/5 × 32.000 = 25.600 e valida em 6.400; as cinco pontuações são mediadas. A mesma receita em 60.000 instâncias excederia o limiar e perderia o k-fold automático no modo HPO.

Exemplo trabalhado 4: matemática de pesos de classe, ambas as variantes. 98% negativo / 2% positivo ⇒ $0.02 \times w = 0.98 \Rightarrow w = \mathbf{49}$. A variante de fraude da AWS usa $\text{scale\_pos\_weight} = \sqrt{284{,}315/492} = \sqrt{577.9} \approx \mathbf{24}$. Ambas são legítimas; a razão bruta é mais severa, a raiz quadrada é o amortecimento documentado para enviesamento extremo.

Exemplo trabalhado 5: a matriz de confusão desbalanceada completa. 10.000 transações, 100 fraudes, VP = 85, FP = 40, FN = 15, VN = 9.860 ⇒ acurácia 99,45%, linha de base majoritária 99,0%, precisão 0,68, revocação 0,85, F1 0,756. A decisão que segue: reporte F1 ou AUC, não acurácia, e afirme que 40 de 125 alertas (32%) são falsos alarmes.

Exemplo trabalhado 6, equilibrando um conjunto de avaliação de 600 previsões. Um modelo produz VP = 480, FP = 60, FN = 20, VN = 40 em 1.000 linhas. Acurácia = $880/1000 = \mathbf{0.88}$; precisão = $480/540 = \mathbf{0.889}$; revocação = $480/500 = \mathbf{0.96}$; F1 = $2(0.889)(0.96)/(0.889+0.96) = 1.707/1.849 = \mathbf{0.923}$. Taxa de verdadeiro negativo = $40/100 = 0.40$, então acurácia balanceada = $(0.96 + 0.40)/2 = \mathbf{0.68}$, muito abaixo da acurácia de 0.88, porque a classe negativa é onde o modelo falha. Aquela lacuna entre 0,88 e 0,68 é exatamente o que a acurácia balanceada existe para expor.

---

13. Armadilhas, conflitos e afirmações não verificadas

13.1 Afirmações conflitantes, não verificadas e não examináveis

Fontes primárias para esta lição: o Exam Guide do AIF-C01; as páginas do guia do desenvolvedor do SageMaker algorithms, algorithms-tabular, xgboost, xgboost-tuning, linear-learner-tuning, k-means, PCA-reference, object2vec, how-it-works-model-validation, autopilot-metrics-validation, automatic-model-tuning-early-stopping, your-algorithms-training-algo-dockerfile, train-model, pre-built-containers-frameworks-deep-learning, pre-built-containers-support-policy, clarify-foundation-model-evaluate-overview e reinforcement-learning; as páginas do guia do desenvolvedor de machine learning model-fit-underfitting-vs-overfitting e evaluating_models; e os posts do AWS Machine Learning blog sobre detecção de fraude, balanceamento do Data Wrangler, Autopilot para serviços financeiros e classificação multiclass do Linear Learner.

---

Casos Reais

Cada regra das seções 1 a 13 tem uma versão de cliente. Os quatro casos abaixo são extraídos do digest de estudos de caso do curso (fontes restritas a aws.amazon.com/solutions/case-studies/* e aws.amazon.com/blogs/machine-learning/*), e cada um foi escolhido porque é uma história de seleção de algoritmo ou avaliação e não uma anedota de marketing: alguém escolheu uma rota da seção 5, escolheu uma métrica da seção 6, e então mediu o resultado em dados nos quais o modelo não foi treinado.

Estudo de caso 1, Chronomics: o limiar é uma decisão, não um detalhe

Depois de quatro meses de modelagem de visão computacional interno que nunca atingiu a meta, a Chronomics moveu a mesma tarefa de leitura de testes de COVID para o Amazon Rekognition Custom Labels (AutoML) e entregou em 3 to 4 semanas com 96,5% de acurácia e 97,9% de F1, pontuado com DetectCustomLabels. A parte examinável é o que aconteceu depois: elevar o limiar de confiança comprou precisão e pagou por isso em cobertura.

Fonte: AWS Machine Learning Blog, blogs/machine-learning/chronomics-detects-covid-19-test-results-with-amazon-rekognition-custom-labels (13 de dezembro de 2022).

A lição espelha a seção 6: um único número de acurácia nunca conta quanto uma mudança de limiar custa. A Chronomics não retreinou entre as duas linhas: ela mudou apenas quais previsões estava disposta a assinar, e é por isso que "o que acontece com as linhas descartadas?" deve ser respondido antes da implantação.

Estudo de caso 2, Sun Finance: avalie cada tentativa e nunca deixe um modelo fazer dois trabalhos

A Sun Finance automatizou a extração de documentos KYC em nove países. A escada de tentativas documentada é a narrativa de avaliação mais limpa do digest:

Fonte: AWS Machine Learning Blog, blogs/machine-learning/sun-finance-automates-id-extraction-and-fraud-detection-with-generative-ai-on-aws (30 de abril de 2026); avaliado em 585 imagens.

Dois hábitos de exame vivem aqui. Primeiro, a tentativa 1 foi medida e rejeitada, o time não entregou por vibes, entregou em um conjunto de avaliação de retenção. Segundo, OCR e raciocínio são trabalhos separados: o serviço de extração pré-construído (Rota 1) fez a leitura, o foundation model apenas estruturou o que já tinha sido lido, e regras de validação pegaram o resto.

Estudo de caso 3, HAYAT HOLDING: o ajuste automático substitui a varredura manual

A HAYAT HOLDING transmite 194 sensores via OPC-UA para um SiteWise Edge Gateway AWS IoT Greengrass, depois treina no SageMaker Model Training com SageMaker Automatic Model Tuning, implanta com SageMaker Model Deployment, e roda os modelos no dispositivo através do SageMaker Edge Manager. O resultado documentado é US$ 300.000 por ano economizados mais qualidade de painel mais alta.

Fonte: AWS Machine Learning Blog, blogs/machine-learning/hayat-holding-uses-amazon-sagemaker-to-increase-product-quality-and-optimize-manufacturing-output-saving-300000-annually (2023).

Isto é a seção 8.2 rodando sem supervisão: em vez de um humano varrendo hiperparâmetros a olho, o tuner busca o espaço de configuração contra uma métrica de validação e para cedo trabalhos fracos. Quando uma questão pergunta como um time escala o ajuste em muitos modelos ou entradas, a resposta documentada é Automatic Model Tuning: não uma planilha maior.

Estudo de caso 4, Adobe: chunking e embeddings também são hiperparâmetros

A Adobe melhorou a busca na documentação para desenvolvedores com Amazon Bedrock Knowledge Bases, testando quatro estratégias de chunking (400 tokens com 20% de sobreposição, 1.000 tokens, hierárquica, semântica) pareadas com Amazon Titan Text Embeddings V2 no OpenSearch Service, recuperadas através da Retrieve API. O resultado no próprio conjunto de testes da Adobe foi +20% de acurácia de recuperação, e a estratégia mais simples, chunks de 400 tokens com 20% de sobreposição, também foi a mais precisa.

Fonte: AWS Machine Learning Blog, blogs/machine-learning/adobe-enhances-developer-productivity-using-amazon-bedrock-knowledge-bases (11 de junho de 2025).

A disciplina de avaliação é idêntica à da seção 7: candidatos foram comparados em um conjunto de teste fixo de retenção, não nas consultas usadas para construí-los. A qualidade da recuperação é um problema de seleção de modelo: tamanho do chunk, sobreposição e escolha do embedding são os hiperparâmetros, e a métrica decide.

• 📚 Você sabia? A AWS publica exatamente uma taxa de resultado de projeto: 65% dos projetos do Generative AI Innovation Center chegaram à produção em 2025, extraídos de mais de 1.000 implementações, com alguns entregues em apenas 45 dias. O método por trás disso é o framework dos Cinco V's, Value → Visualize → Validate → Verify → Venture, que começa com métricas de linha de base (acurácia e resultado de negócio) antes que um único modelo seja treinado. Fonte: AWS Machine Learning Blog, blogs/machine-learning/beyond-pilots-a-proven-framework-for-scaling-ai-to-production (2025). O corolário que os examinadores gostam: 35% não chegaram à produção, então avaliação é uma fase, não uma cerimônia.

• 📚 Você sabia? O caminho humano para os 5% descartados da Chronomics já tem nome de produto: Amazon Augmented AI (A2I), disponível desde 2020 com mais de 60 fluxos de trabalho, existe porque "clientes ainda dizem que há casos de uso críticos onde julgamento humano é necessário." O A2I é como um pipeline de visão ou documentos de limiar alto converte abstenções em resultados revisados em vez de linhas descartadas, o mesmo princípio de design do caminho de exceção humana da Anthem para os claims que o Textract não automatizou.

---

14. Perguntas de Prática (Practice Questions)