# Playbook: IA, ML, Deep Learning, LLM e Agentes — o Mapa para Decidir a Ferramenta Certa

Um guia prático em camadas para engenheiros e arquitetos que precisam parar de usar 'vamos de LLM' como resposta padrão. O mapa correto é IA → ML → Deep Learning → GenAI/LLM → Agentes, cada camada um subconjunto da anterior — não sinônimos. A pergunta certa nunca é 'qual modelo?', é 'qual a ferramenta mais simples que resolve bem?'.

- URL: https://fernando.moretes.com/studies/playbook-ia-ml-deep-learning-llm-agentes-o-mapa

- Markdown: https://fernando.moretes.com/studies/playbook-ia-ml-deep-learning-llm-agentes-o-mapa/study.md?lang=pt

- Type: Playbook

- Domain: IA / Fundamentos

- Date: 2025-05-15

- Tags: ai, machine-learning, llm, agents, deep-learning, genai, aws, fundamentals

- Reading time: 10 min

---

Toda semana alguém propõe um LLM para um problema que um classificador de regressão logística resolvia com 99% de acurácia por US$ 0,001 por mil chamadas. O custo não é só financeiro — é latência, imprevisibilidade, surface de alucinação e complexidade operacional que você não precisava. Este playbook é o mapa que faltava: as camadas reais do campo de IA, o que cada uma resolve, e o processo de decisão para chegar à ferramenta mais simples que funciona.

## O que você vai conseguir decidir depois deste playbook

- Distinguir IA, ML, Deep Learning, GenAI, LLM e Agentes como camadas aninhadas — não como sinônimos ou modismos intercambiáveis.
- Aplicar o critério de 'ferramenta mais simples que resolve bem' antes de propor qualquer solução baseada em modelo.
- Comparar regras explícitas vs. modelo treinado vs. LLM em termos de custo, previsibilidade e risco operacional.
- Identificar quando um classificador clássico ganha de um LLM — e quando o LLM é genuinamente a ferramenta certa.
- Reconhecer os anti-padrões que geram arquiteturas erradas por confusão conceitual.
- Decidir quando agentes são necessários — e quando são over-engineering disfarçado de inovação.

## Glossário de Referência Rápida

- **Inteligência Artificial (IA):** O campo completo: qualquer técnica que permite a máquinas simular capacidades cognitivas humanas — percepção, raciocínio, decisão. Inclui sistemas de regras, busca, otimização, ML e tudo mais.
- **Machine Learning (ML):** Subconjunto de IA onde o sistema aprende padrões a partir de dados, sem ser explicitamente programado para cada regra. Inclui supervisionado, não-supervisionado e por reforço.
- **Deep Learning (DL):** Subconjunto de ML que usa redes neurais com múltiplas camadas (profundas) para aprender representações hierárquicas. Dominante em visão computacional, NLP e áudio.
- **IA Generativa (GenAI):** Subconjunto de Deep Learning focado em gerar conteúdo novo — texto, imagem, código, áudio — a partir de padrões aprendidos. LLMs são o caso mais visível.
- **Large Language Model (LLM):** Modelo de linguagem de grande escala treinado em enormes corpora de texto via self-supervised learning. Especializado em compreensão e geração de linguagem natural. Ex: GPT-4, Claude, Titan.
- **Embeddings:** Representações vetoriais densas de texto, imagem ou outro dado em espaço de alta dimensão. Permitem busca semântica, clustering e RAG sem precisar de um LLM gerativo no caminho crítico.
- **Agente de IA:** LLM equipado com ferramentas (APIs, buscas, execução de código) e memória (contexto de sessão, vetor store), capaz de planejar e executar sequências de ações para atingir um objetivo.

## O modelo mental que desbloqueia tudo: camadas aninhadas, não sinônimos

O erro mais caro que vejo em design reviews não é técnico — é semântico. Quando alguém diz 'vamos usar IA para isso', pode estar propondo desde um sistema de regras if/else até um agente autônomo com acesso a APIs externas. Essa ambiguidade gera arquiteturas erradas porque o time não está falando da mesma coisa.

O mapa correto é de **camadas aninhadas**, onde cada camada é um subconjunto estrito da anterior:

- **IA** é o campo inteiro. Tudo que segue é IA.
- **ML** é a abordagem dominante dentro de IA: sistemas que aprendem de dados. Mas IA inclui sistemas de regras, planejamento simbólico e otimização clássica que não são ML.
- **Deep Learning** é ML com redes neurais profundas. Poderoso para dados não estruturados (texto, imagem, áudio), mas não é a única forma de fazer ML. Um gradient boosting em dados tabulares é ML, não DL.
- **GenAI** é Deep Learning com objetivo generativo — produzir conteúdo novo. Inclui LLMs, mas também difusão de imagens, síntese de áudio e geração de código.
- **LLM** é GenAI especializada em linguagem. É o subconjunto mais visível hoje, mas continua sendo um subconjunto.
- **Agentes** são LLMs com ferramentas e memória. Não são um tipo diferente de modelo — são uma arquitetura de sistema que usa um LLM como motor de raciocínio.

Por que isso importa na prática? Porque a escolha da ferramenta deve começar da camada mais externa (mais simples) e só descer para camadas mais internas quando há evidência de que a camada anterior não é suficiente. Ir direto para LLM ou agente sem essa avaliação é como usar um bisturi quando uma tesoura resolve — e pagar o preço em custo, latência e risco.

## Mapa em Camadas: IA → ML → DL → GenAI → LLM → Agentes

Cada camada é um subconjunto estrito da anterior. A decisão de qual usar começa de fora para dentro — da mais simples para a mais complexa. Agentes não são 'mais IA' do que regras; são mais complexos e mais caros.

### 🌐 IA — Inteligência Artificial / Artificial Intelligence

- Regras Explícitas if/else, regex, heurísticas (compute)
- Busca & Otimização A*, LP, constraint solvers (compute)
- 🤖 ML — Machine Learning Aprende de dados (ai)

### 🤖 ML — Machine Learning

- ML Clássico Regressão, SVM, GBM, KNN (ai)
- 🧠 Deep Learning Redes neurais profundas (ai)

### 🧠 Deep Learning

- Visão Computacional CNN, YOLO, ResNet (ai)
- Áudio & Fala Whisper, WaveNet (ai)
- ✨ GenAI Geração de conteúdo (ai)

### ✨ GenAI — IA Generativa / Generative AI

- Geração de Imagem Diffusion, DALL-E (ai)
- 💬 LLM Modelos de Linguagem (ai)

### 💬 LLM — Large Language Models

- LLM Base Claude, GPT-4, Titan, Llama (ai)
- Embeddings Busca semântica, RAG (ai)
- 🤝 Agentes LLM + Ferramentas + Memória (ai)

### 🤝 Agentes / Agents

- Motor de Raciocínio LLM como orquestrador (ai)
- Ferramentas APIs, código, buscas (external)
- Memória Contexto, vetor store (storage)

### Fluxos

- rules -> ml_group: quando regras não escalam
- classical_ml -> dl_group: quando dados são não-estruturados
- dl_group -> genai_group: quando precisa gerar
- genai_group -> llm_group: quando domínio é linguagem
- llm_base -> agent_group: quando precisa agir no mundo
- agent_core -> tools: invoca
- agent_core -> memory: lê/escreve

## Quando cada camada é a resposta certa

A pergunta que estrutura a decisão não é 'qual modelo de IA devo usar?' — é **'qual é a ferramenta mais simples que resolve este problema com qualidade aceitável?'**. Simples aqui não é pejorativo: significa menor custo de operação, maior previsibilidade, menor surface de falha e mais fácil de auditar.

**Regras explícitas** ganham quando o domínio é pequeno e estável, as condições são enumeráveis, e você precisa de 100% de explicabilidade. Validação de CPF, formatação de campos, roteamento por tipo de documento — essas são vitórias de regras. Custo: praticamente zero. Latência: microssegundos. Auditoria: trivial.

**ML clássico** (regressão, árvores, gradient boosting) ganha quando você tem dados rotulados suficientes, o problema é de classificação ou regressão sobre dados estruturados, e precisa de previsibilidade de custo. Um classificador de fraude em dados tabulares com XGBoost frequentemente supera um LLM em acurácia, custa uma fração do preço, e produz feature importances que o time de compliance consegue auditar. O Amazon SageMaker tem infraestrutura madura para esse padrão.

**Deep Learning** (sem ser generativo) entra quando os dados são não-estruturados — imagens, áudio, texto para classificação — e o volume justifica o custo de treinamento. Detecção de objetos em imagens de câmera, transcrição de áudio, classificação de sentimento em escala: esses são casos de DL, não de LLM.

**Embeddings** merecem menção especial porque são frequentemente a resposta certa para problemas que parecem precisar de LLM. Busca semântica, deduplicação, clustering de documentos, recomendação — tudo isso pode ser resolvido com embeddings + busca vetorial (Amazon OpenSearch, pgvector) sem um LLM gerativo no caminho crítico. Custo de embedding é uma ordem de magnitude menor que geração.

**LLM** é a ferramenta certa quando o problema exige compreensão ou geração de linguagem natural em domínio aberto: sumarização, extração de entidades de texto livre, geração de rascunhos, Q&A sobre documentos com RAG. Mas mesmo aqui, a primeira pergunta deve ser: 'um modelo menor, fine-tuned, resolve?' Um modelo de 7B parâmetros fine-tuned no seu domínio frequentemente supera GPT-4 zero-shot no seu caso específico, a um custo 10-50x menor.

**Agentes** são a resposta certa quando o problema exige múltiplos passos de raciocínio, uso de ferramentas externas, e o fluxo não é determinístico o suficiente para ser codificado como workflow. Pesquisa autônoma, assistentes que executam ações em sistemas externos, pipelines de análise que precisam decidir quais dados coletar. O custo de agentes é alto — latência de múltiplos round-trips de LLM, custo de tokens acumulado, complexidade de observabilidade. Use quando o valor justifica.

## Regras vs. ML Clássico vs. LLM: quando usar cada um
| Critério | Critério | Regras Explícitas | ML Clássico (ex: XGBoost) | LLM (ex: Claude, GPT-4) |
| --- | --- | --- | --- | --- |
| Custo por chamada | ~$0 (compute local) | ~$0,0001–$0,001 | ~$0,002–$0,06 (varia por modelo) | — |
| Latência típica | < 1ms | 1–50ms | 500ms–10s (geração) | — |
| Previsibilidade de output | Determinístico | Estocástico, mas calibrável | Estocástico, difícil de garantir | — |
| Risco de alucinação | Zero | Zero (classifica, não gera) | Presente — requer mitigação | — |
| Explicabilidade / Auditoria | Trivial — código é a doc | Boa — feature importance, SHAP | Difícil — caixa preta por natureza | — |
| Dados de treino necessários | Nenhum | Centenas a milhares de exemplos rotulados | Nenhum (zero-shot) ou poucos (few-shot) | — |
| Domínio aberto / linguagem livre | Não suporta | Limitado a features engenheiradas | Ponto forte | — |
| Manutenção ao longo do tempo | Alta se domínio muda | Re-treino periódico necessário | Prompt engineering + monitoramento contínuo | — |
| Quando usar | Domínio pequeno, estável, auditável | Dados estruturados, volume alto, compliance | Linguagem livre, geração, domínio aberto | — |

## O processo de decisão: de fora para dentro

A sequência de perguntas abaixo é o que eu faço mentalmente em qualquer design review que envolva 'IA'. Não é burocracia — é o atalho para evitar over-engineering.

**1. O problema é enumerável?**
Se você consegue escrever todas as condições em código sem perder cobertura relevante, use regras. Validação de campos, roteamento por tipo, formatação — regras. Fim.

**2. Os dados são estruturados e você tem labels?**
Se sim, avalie ML clássico primeiro. Gradient boosting (XGBoost, LightGBM) em dados tabulares é frequentemente o melhor classificador disponível, com custo de inferência irrisório e explicabilidade razoável. Amazon SageMaker suporta esse padrão com autopilot, endpoints gerenciados e monitoramento de drift.

**3. Os dados são não-estruturados (imagem, áudio) mas o output é estruturado (classificação, detecção)?**
DL especializado — não LLM. Um modelo de visão computacional para detecção de defeitos em linha de produção custa uma fração de um LLM multimodal e é mais preciso no domínio específico.

**4. O problema envolve linguagem natural mas o output é estruturado (classificação, extração)?**
Considere embeddings + classificador ou um modelo de linguagem menor fine-tuned antes de ir para LLM gerativo. Amazon Bedrock oferece modelos de embedding (Titan Embeddings) que resolvem busca semântica sem geração.

**5. O problema exige geração ou compreensão em domínio aberto?**
Agora LLM faz sentido. Mas ainda pergunte: zero-shot resolve? Few-shot resolve? Fine-tuning no domínio seria melhor? RAG é suficiente? Quanto menor e mais especializado o modelo, menor o custo e maior a previsibilidade.

**6. O problema exige múltiplos passos, ferramentas externas e raciocínio não-determinístico?**
Agora agentes fazem sentido. Mas implemente com observabilidade desde o início — logs de cada step, rastreamento de tool calls, limites de iteração. Amazon Bedrock Agents oferece esse padrão com integração nativa a Lambda, Knowledge Bases e Action Groups.

Essa sequência não é dogma — é um filtro. Você pode pular etapas se tiver evidência clara. Mas o ônus da prova é de quem propõe a camada mais complexa.

## Processo de Decisão: do Problema à Ferramenta

1. **Passo 1 — Defina o problema com precisão** — Escreva em uma frase: qual é o input, qual é o output esperado, qual é a métrica de sucesso. 'Usar IA para melhorar a experiência' não é um problema — é uma intenção. 'Classificar tickets de suporte em 8 categorias com F1 > 0,90' é um problema.

2. **Passo 2 — Teste a hipótese de regras** — Pergunte: 'consigo cobrir 95%+ dos casos com regras explícitas?' Se sim, implemente regras e monitore os casos não cobertos. Adicione ML só quando os edge cases forem suficientemente custosos para justificar.

3. **Passo 3 — Avalie o perfil dos dados** — Dados estruturados com labels → ML clássico. Dados não-estruturados com output estruturado → DL especializado. Texto com output estruturado → embeddings + classificador. Texto com output livre → LLM. Sem dados históricos e domínio aberto → LLM zero/few-shot.

4. **Passo 4 — Estime custo e volume** — Calcule: volume mensal de chamadas × custo por chamada para cada opção. Um classificador a $0,001/1k vs LLM a $0,05/1k = 50x de diferença. Em 10M chamadas/mês: $10 vs $500. Documente esse número antes de qualquer decisão.

5. **Passo 5 — Avalie requisitos de explicabilidade e compliance** — Sistemas financeiros, de saúde ou com impacto em decisões sobre pessoas frequentemente exigem explicabilidade auditável. LLMs são caixas-pretas por natureza. Se o requisito de explicabilidade for forte, ML clássico com SHAP ou regras são a resposta — não LLM.

6. **Passo 6 — Prototype e meça antes de arquitetar** — Antes de desenhar a arquitetura completa, valide a hipótese com um protótipo mínimo. Um classificador sklearn em 200 exemplos rotulados leva 2 horas para testar. Um LLM zero-shot com 20 exemplos de avaliação leva 1 hora. Meça F1, custo e latência antes de comprometer a arquitetura.

7. **Passo 7 — Defina a estratégia de fallback e monitoramento** — Qualquer modelo em produção precisa de: (1) métricas de qualidade monitoradas continuamente, (2) threshold de confiança com fallback para humano ou regra, (3) processo de re-treino ou atualização de prompt quando a qualidade degradar. Isso é verdade para ML clássico, LLM e agentes.

> **Anti-padrões que geram arquiteturas erradas:** **1. LLM como default.** Tratar LLM como a resposta óbvia para qualquer problema que envolva texto é o anti-padrão mais caro do momento. Um classificador de sentimento com BERT fine-tuned custa 20x menos, tem latência 10x menor e não alucina. Use LLM quando geração ou compreensão em domínio aberto for genuinamente necessária.

**2. Confundir os conceitos = arquitetura errada.** Chamar um classificador de 'agente', ou propor um 'modelo de deep learning' quando você quer dizer 'LLM', não é só imprecisão semântica — leva a decisões de infraestrutura erradas, estimativas de custo erradas e escolha de serviços errados.

**3. Agentes para fluxos determinísticos.** Se o fluxo pode ser mapeado como um DAG de steps com condições conhecidas, use Step Functions ou um workflow engine — não um agente. Agentes introduzem não-determinismo onde você não quer. Reserve agentes para problemas onde o espaço de ações não é enumerável antecipadamente.

**4. Ignorar o custo de tokens em agentes.** Um agente com 5 round-trips de LLM, cada um com 2k tokens de contexto, custa 10k tokens por tarefa. Em volume, isso é significativo. Meça o custo médio por tarefa completada antes de ir para produção.

**5. Fine-tuning prematuro.** Fine-tuning é caro (compute de treinamento + dados rotulados de qualidade) e cria um modelo que precisa ser mantido. Antes de fine-tunar, esgote zero-shot, few-shot e RAG. Fine-tuning faz sentido quando você tem centenas de exemplos de alta qualidade e o modelo base consistentemente falha no domínio.

> **Regra de Bolso:** **Escolha sempre a ferramenta mais simples que resolve bem.** Um classificador de $0,001 que acerta 98% ganha de um LLM de $0,05 que alucina 2% com confiança — especialmente em produção, onde o 2% de alucinação aparece exatamente nos casos mais sensíveis. A complexidade tem que ser justificada pelo problema, não pelo entusiasmo com a tecnologia.

> **Minha perspectiva como arquiteto:** Nos últimos dois anos, revisei dezenas de propostas de arquitetura onde LLM era a primeira linha da solução. Em pelo menos metade dos casos, a conversa de 30 minutos sobre o problema real revelava que um classificador, uma busca vetorial ou até regras explícitas resolvia melhor — com custo e risco menores.

O que me preocupa não é o entusiasmo com LLMs — é a falta do processo de eliminação. A pergunta 'por que não uma solução mais simples?' deveria ser obrigatória em qualquer design review de IA.

Na prática, o que eu faço: começo sempre pela definição precisa do problema e pela estimativa de custo comparativa. Se o LLM for 10x mais caro que a alternativa, o ônus da prova é de quem propõe o LLM — e 'é mais moderno' não é prova. Também mantenho uma distinção clara entre o que é um problema de linguagem (onde LLM tem vantagem real) e o que é um problema de classificação ou busca disfarçado de linguagem (onde embeddings ou ML clássico ganham).

Para agentes especificamente: só recomendo quando o fluxo genuinamente não pode ser mapeado como workflow determinístico. A maioria dos 'agentes' que vejo em produção são, na verdade, pipelines de RAG com alguns steps de lógica — que seriam mais confiáveis, baratos e observáveis como Step Functions + Lambda + Bedrock do que como um agente autônomo.

O campo está evoluindo rápido, e modelos menores estão ficando cada vez mais capazes. Mas o princípio de escolher a ferramenta mais simples que resolve bem é atemporal — e é o que separa engenharia de cargo cult.

## Veredicto

IA não é um produto — é um campo. ML não é sinônimo de Deep Learning. LLM não é sinônimo de IA. Agente não é sinônimo de LLM. Confundir esses termos não é só imprecisão acadêmica: leva a arquiteturas superdimensionadas, custos desnecessários e sistemas que falham de formas que você não antecipou. O mapa correto é de camadas aninhadas, e a direção de decisão é sempre de fora para dentro — da ferramenta mais simples para a mais complexa, com o ônus da prova em quem propõe a camada seguinte. Um classificador bem treinado que acerta 98% e custa $0,001 por mil chamadas não é 'menos IA' do que um LLM. É engenharia melhor.

## Referências

- [AWS — What is Artificial Intelligence?](https://aws.amazon.com/what-is/artificial-intelligence/)
- [AWS — What is Machine Learning?](https://aws.amazon.com/what-is/machine-learning/)
- [AWS — What is a Large Language Model?](https://aws.amazon.com/what-is/large-language-model/)
- [AWS — What are AI Agents?](https://aws.amazon.com/what-is/ai-agents/)

## Fontes do caso

- [AWS — What is Artificial Intelligence?](https://aws.amazon.com/what-is/artificial-intelligence/)
- [AWS — What is Machine Learning?](https://aws.amazon.com/what-is/machine-learning/)
- [AWS — What is a Large Language Model?](https://aws.amazon.com/what-is/large-language-model/)
- [AWS — What are AI Agents?](https://aws.amazon.com/what-is/ai-agents/)