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

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.

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.

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.