💭 Chain-of-Thought (CoT)
Chain-of-Thought é a técnica de fazer o LLM explicitar seu raciocínio passo a passo antes de dar a resposta final. Em vez de ir direto ao resultado, o modelo "pensa em voz alta" — e isso melhora significativamente a qualidade em problemas complexos.
Comparação: sem CoT vs. com CoT
SEM CoT
Prompt: "Se João tem 3 vezes mais maçãs que Maria, e Maria tem 8, quantas maçãs João tem?"
→ Resposta: "João tem 11 maçãs."
✗ Errado (3×8 = 24, não 11)
COM CoT ("pense passo a passo")
Mesmo prompt + "Pense passo a passo antes de responder."
→ "Maria tem 8 maçãs. João tem 3 vezes mais, então João tem 3 × 8 = 24 maçãs."
✓ Correto
Zero-shot CoT
Adicione "Pense passo a passo" ao prompt. Funciona na maioria dos modelos frontier sem exemplos.
Few-shot CoT
Inclua 2-3 exemplos de raciocínio passo a passo no prompt. Mais preciso, mais tokens de input.
CoT em Tool Selection
O LLM explica por que escolheu uma tool específica antes de chamá-la. Melhora a escolha em 30%.
💡 Onde CoT mais impacta
Matemática, lógica, código, raciocínio multi-passo e análise crítica se beneficiam mais de CoT. Para tarefas simples de recuperação de fato ou classificação direta, CoT adiciona custo sem benefício real.
⚡ ReAct: Reason + Act
ReAct é o padrão default da maioria dos agentes em produção. Ele intercala Pensamento → Ação → Observação em loop até atingir o objetivo. O LLM "pensa em voz alta", escolhe uma action (tool), vê o resultado e repete.
Trace de um agente ReAct real
Thought:
O usuário quer saber o preço atual da PETR4. Preciso buscar essa informação em tempo real. Vou usar a tool de cotação de ações.
Action: buscar_cotacao
Input: {"ticker": "PETR4", "exchange": "B3"}
Observation:
PETR4: R$ 38,42 (+1,2%) às 15:32. Volume: 12,5M ações.
Thought:
Tenho a informação necessária. Posso responder ao usuário diretamente com a cotação atual.
Final Answer:
A PETR4 está sendo negociada a R$ 38,42 hoje, com alta de 1,2%.
Vantagens do ReAct
- ✓Flexível — adapta o próximo passo com base no resultado atual
- ✓Raciocínio auditável — você vê exatamente o que o agente pensou
- ✓Simples de implementar — é o padrão de AgentExecutor
Limitações
- ✗Custo cresce com cada iteração (modelo caro a cada thought)
- ✗Pode entrar em loop infinito se mal configurado
- ✗Não ideal para tarefas com plano previsível (desnecessariamente caro)
📋 Plan-and-Execute
Plan-and-Execute separa o agente em dois: um Planner (LLM grande, chamado uma vez) que decompõe a tarefa em passos, e um Executor (LLM pequeno, chamado por passo) que executa cada item. Reduz custo em até 90% para tarefas longas.
Arquitetura Plan-and-Execute
1. Planner (Claude Opus — 1 chamada)
Input: "Pesquise os 3 maiores players de
computação em nuvem e compare preços"
Output: [
"1. Buscar info sobre AWS",
"2. Buscar info sobre Azure",
"3. Buscar info sobre GCP",
"4. Comparar preços de VM padrão",
"5. Montar tabela comparativa"
]
2. Executor (GPT-4o-mini — 5 chamadas)
📊 Comparação de custo: ReAct vs. Plan-and-Execute
ReAct puro (GPT-4o todo o tempo)
$0.85
por tarefa de 5 passos
Plan-and-Execute
$0.09
Opus (plan) + mini (execute)
Economia
89%
sem perda de qualidade no plano
🔁 Reflexion pattern
No padrão Reflexion, o agente gera uma resposta e depois usa um segundo LLM (o Critic) para criticar, identificar erros e sugerir melhorias. A resposta melhorada passa por nova rodada de crítica até atingir qualidade suficiente.
Actor — gera a resposta
Recebe o objetivo e produz uma primeira resposta completa. Não tenta ser perfeito — produz rapidamente e delega a crítica.
Critic — avalia e pontua
Recebe o objetivo + resposta do Actor. Identifica erros factuais, lógicos, de completude ou de estilo. Produz feedback específico e acionável.
Revisor — melhora com base no feedback
Actor recebe o feedback do Critic e revisa a resposta. Ciclo se repete até o Critic dar nota suficiente ou número máximo de iterações.
Quando Reflexion compensa
- ✓Geração de código onde bug tem custo alto
- ✓Escrita criativa onde qualidade é diferencial
- ✓Análise crítica onde imprecisão tem consequências
- ✓Geração de relatórios executivos
Parâmetros de controle
- max_iterations: geralmente 2-3 (custo aumenta linearmente)
- quality_threshold: nota mínima do Critic para parar
- Critic model: pode ser menor que o Actor (economiza)
- Critic prompt: seja específico sobre critérios de qualidade
🗺️ Quando usar cada padrão
Não existe padrão universalmente melhor. A escolha depende de 4 dimensões: número de passos da tarefa, previsibilidade do plano, tolerância a custo e requisito de qualidade. A tabela abaixo sintetiza a decisão.
| Padrão | Passos | Previsibilidade | Custo Relativo | Melhor para |
|---|---|---|---|---|
| CoT | 1 | Alta | 1-2× | Análise, matemática, lógica pontual |
| ReAct | 2-10 | Baixa | N×custo_modelo | Exploração com tools, pesquisa dinâmica |
| Plan+Execute | 5-20 | Alta | 10-90× menor | Pipelines longos e previsíveis |
| Reflexion | 1 (c/ revisões) | Alta | 3-5× | Qualidade crítica, código, escrita profissional |
💡 Combinando padrões
Os padrões não são mutuamente exclusivos. Exemplo poderoso: Plan-and-Execute + Reflexion — o Planner cria o plano (CoT interno), o Executor executa cada passo (ReAct local por passo), e o Reflexion avalia o resultado final antes de entregar. Custo intermediário, qualidade máxima.
💰 Custo vs. qualidade por padrão
A escolha de padrão tem impacto financeiro direto em produção. Um agente com milhares de execuções diárias pode ter diferença de 10× no custo mensal dependendo do padrão escolhido. Entender o trade-off é parte da arquitetura.
📊 Análise de custo mensal (10.000 tarefas/dia)
Regras práticas de decisão arquitetural
✅ Resumo do Módulo 2.5
Próximo Módulo:
2.6 — MCP na Prática: o padrão USB dos agentes. Como conectar banco de dados, APIs externas e criar seu primeiro servidor MCP em Python.