Playbook: IA, ML, Deep Learning, LLM e Agentes — o Mapa para Decidir a Ferramenta Certa
Ouvir estudo
gerado ao ouvirGerado apenas no primeiro play
Com tecnologia Amazon Polly + OmniVoice
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?'.
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
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.
- Regras Explícitas · if/else, regex, heurísticas
- Busca & Otimização · A*, LP, constraint solvers
- 🤖 ML — Machine Learning · Aprende de dados
- ML Clássico · Regressão, SVM, GBM, KNN
- 🧠 Deep Learning · Redes neurais profundas
- Visão Computacional · CNN, YOLO, ResNet
- Áudio & Fala · Whisper, WaveNet
- ✨ GenAI · Geração de conteúdo
- Geração de Imagem · Diffusion, DALL-E
- 💬 LLM · Modelos de Linguagem
- LLM Base · Claude, GPT-4, Titan, Llama
- Embeddings · Busca semântica, RAG
- 🤝 Agentes · LLM + Ferramentas + Memória
- Motor de Raciocínio · LLM como orquestrador
- Ferramentas · APIs, código, buscas
- Memória · Contexto, vetor store
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 | 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.
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.
Post-mortems, ADRs e deep dives de arquitetura no seu email — do jeito que um arquiteto lê.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Receba uma resposta focada sobre este estudo do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar — você também recebe a newsletter. Sem senha.