🔍 Seleção de modelo por capacidade e custo
A escolha do modelo é a primeira decisão arquitetural de qualquer agente. Não existe modelo universalmente melhor — existe o modelo certo para cada caso de uso, considerando capacidade de raciocínio, velocidade, custo e suporte a function calling.
🗺️ Mapa de modelos em 2026
Modelos Frontier (planejamento)
- •Claude Opus 4.6 — melhor raciocínio, ideal para planner
- •GPT-4o — excelente function calling, ecossistema maduro
- •Gemini Pro — contexto longo nativo (1M tokens)
Modelos Small (execução)
- •Claude Haiku — mais rápido e barato da família Anthropic
- •GPT-4o-mini — custo 15x menor que GPT-4o
- •Mistral / Llama — open-source, self-hosted, custo zero de API
💡 Regra de ouro da seleção
Use o modelo mais barato que ainda acerta para cada etapa. Comece testando com o menor modelo; só escale para frontier quando o pequeno demonstrar falha específica e documentada.
📊 Comparação de custo por 1M tokens (aproximado 2026)
📐 Context window na prática
O context window é a memória de trabalho do LLM. Tudo que o LLM pode considerar ao gerar uma resposta cabe ali: o system prompt, o histórico da conversa, os schemas das tools, os resultados das tools e os documentos injetados via RAG. Esgotar o contexto quebra o agente.
O que ocupa o contexto
- •System prompt: 500–2.000 tokens tipicamente
- •Histórico de conversa: cresce com cada turno
- •Tool schemas: ~200–500 tokens por tool
- •Tool results: variável, pode ser enorme
- •Documentos RAG: 500–3.000 tokens por chunk
Estimativa de tokens por conteúdo
- ≈1 token ~ 4 caracteres em inglês
- ≈1 token ~ 3 caracteres em português
- ≈1 página A4 de texto ~ 500 tokens
- ≈1 arquivo Python médio ~ 1.000 tokens
- ≈1 imagem (GPT-4V) ~ 200–1.500 tokens
📊 Context windows por modelo
- Claude 3.5 Sonnet: 200.000 tokens — cabe ~300 páginas de texto
- GPT-4o: 128.000 tokens — cabe ~190 páginas
- Gemini Pro 1.5: 1.000.000 tokens — cabe ~1.500 páginas
- Llama 3.1 (70B): 128.000 tokens — mas self-hosted sem custo de API
⚠️ Context overflow: o bug silencioso
Quando o contexto estoura, a API retorna erro 400 e o agente cai. O problema: muitos frameworks truncam silenciosamente o contexto em vez de lançar erro. O LLM responde mas sem ver parte do histórico — produzindo respostas inconsistentes sem aviso.
🌡️ Temperatura e criatividade
A temperatura é o parâmetro que controla o grau de aleatoriedade nas respostas do LLM. Em 0.0, o modelo sempre escolhe o token mais provável — produzindo respostas determinísticas. Em 1.0 ou mais, escolhas menos prováveis ganham peso, gerando respostas mais variadas e criativas.
0.0
Determinístico
Ideal para: código, SQL, JSON, análise estruturada, extração de dados. O mesmo input sempre gera o mesmo output.
0.3–0.5
Balanceado
Ideal para: respostas de suporte, classificação, resumos, maioria dos casos de uso de agente em produção.
0.7–1.0
Criativo
Ideal para: geração de texto criativo, brainstorming, variações de copy marketing, diálogo natural.
✓ O que FAZER
- ✓Usar temp=0 para tools que geram código ou SQL
- ✓Documentar a temperatura usada em cada agente
- ✓Testar com temp diferentes antes de ir para produção
- ✓Usar seed junto com temperatura baixa para reprodutibilidade
✗ O que NÃO fazer
- ✗Temperatura alta para agente que processa dados financeiros
- ✗Esquecer de definir temperatura e usar o default do provider
- ✗Assumir que temperatura 0 é sempre o melhor
- ✗Mudar temperatura em produção sem testar regressão
💡 top_p: o outro parâmetro de aleatoriedade
top_p (nucleus sampling) é uma alternativa à temperatura. Em vez de escalar todas as probabilidades, limita as escolhas aos tokens que somam probabilidade p. Regra prática: altere apenas um por vez. Mudar temperatura E top_p ao mesmo tempo torna imprevisível qual efeito domina.
💰 Custo por token na prática
Cada chamada ao LLM tem um custo mensurável: tokens de input + tokens de output. Em um agente com loop, esses custos se multiplicam a cada iteração. Um agente que parece barato em teste pode se tornar proibitivo em produção com volume real.
📊 Exemplo de custo real por tarefa
Agente de análise de email com GPT-4o, 5 iterações por email:
Estratégias para reduzir custo
- 1.Cache de prompt: repete o mesmo system prompt → desconto de 50-90%
- 2.Modelo pequeno para steps simples (classificar, formatar)
- 3.Reduzir iterações com Plan-and-Execute
- 4.Compressão de histórico antes de contexto crescer demais
Budget limits obrigatórios
- •Defina max_tokens por chamada para limitar output
- •Defina max_iterations no loop do agente
- •Use contador de tokens acumulado e pare antes de estourar
- •Monitore custo por task e alerte desvios de 2×
⚖️ Modelos pequenos vs grandes
A estratégia mais poderosa de otimização de custo em agentes é usar modelos diferentes para etapas diferentes. O modelo grande faz o raciocínio difícil; o modelo pequeno executa os passos repetitivos. A diferença de custo pode ser de 50-100×.
Modelo Grande — Para o Planner
Claude Opus, GPT-4o, Gemini Pro
Responsável por entender o objetivo, decompor em passos, escolher quais tools usar e avaliar se o resultado atingiu o objetivo. Chamado poucas vezes por tarefa (1-3 vezes).
Modelo Pequeno — Para o Executor
Claude Haiku, GPT-4o-mini, Mistral 7B
Executa cada passo do plano: formatar dados, chamar tools, parsear resultados, classificar entidades. Chamado muitas vezes (N vezes por passo do plano). É onde você economiza.
💡 Quando modelo pequeno falha
Modelos pequenos podem falhar em: raciocínio multi-passo complexo, seguir instruções longas no system prompt, JSON com estrutura aninhada profunda, e tool selection quando as descrições são ambíguas. Nesses casos, escale pontualmente para o modelo maior — não o tempo todo.
🧭 Como o LLM decide a próxima ação
O processo de decisão do LLM é fundamentalmente uma tarefa de next-token prediction sofisticada. Mas da perspectiva do agente, o LLM olha para o estado atual do contexto e decide: devo responder ao usuário, chamar uma tool específica, ou pedir mais informações?
O processo de decisão em 4 etapas
Lê o contexto completo
System prompt (papel e instruções), histórico (o que aconteceu), tool schemas (o que pode fazer) e resultado da última tool (o que sabe agora).
Avalia o estado do objetivo
Tem informação suficiente para responder? O objetivo foi atingido? Há ambiguidade que precisa ser resolvida?
Escolhe entre 3 opções
A) Responder ao usuário (objetivo atingido) · B) Chamar uma tool (precisa de mais informação ou ação) · C) Pedir clarificação (objetivo ambíguo).
Gera a resposta estruturada
Se tool call: gera JSON com nome da tool e parâmetros. Se resposta: gera texto. O runtime lê essa saída e executa a ação correspondente.
🔑 O que torna a decisão melhor
A qualidade da decisão do LLM depende diretamente de 3 elementos que você controla:
- 1.System prompt claro: define explicitamente o papel, o objetivo e quando usar cada tool
- 2.Tool descriptions precisas: o LLM usa o campo description para decidir quando chamar cada tool
- 3.Stop sequences: tokens específicos que forçam o LLM a parar e deixar o runtime agir
✅ Resumo do Módulo 2.1
Próximo Módulo:
2.2 — Memória Curto Prazo: buffer de conversa, sliding window, resumo automático e o problema do contexto longo que derruba agentes em produção.