Escolhendo o LLM certo: prompt engineering e trade-offs

Passei bom tempo experimentando diferentes LLMs nas mesmas tarefas — geração de código, revisão, escrita técnica, raciocínio sobre arquitetura. A conclusão mais útil não foi um ranking fixo, e sim um conjunto de critérios para escolher o modelo certo por contexto.

Prompt engineering é sobre contexto, não sobre "frases mágicas"

O maior ganho de qualidade quase nunca vem de uma frase específica no prompt — vem de dar ao modelo o contexto certo, no formato certo: exemplos concretos, limites explícitos, critérios de sucesso testáveis. Um prompt bem estruturado se parece mais com uma spec curta do que com uma instrução solta.

Os trade-offs que mais pesam na escolha

• Raciocínio profundo vs. latência — modelos mais "pensantes" resolvem problemas arquiteturais melhor, mas custam mais tempo e tokens; para tarefas mecânicas, isso é desperdício.
• Janela de contexto vs. custo — janelas grandes ajudam em tarefas que exigem entender um repositório inteiro, mas nem toda tarefa precisa disso.
• Especialização vs. generalidade — alguns modelos são melhores em código, outros em escrita ou síntese; testar na tarefa real vale mais que confiar em benchmarks genéricos.

Como decido, na prática

Separo as tarefas em categorias (geração de código, revisão/crítica, escrita, decisões de arquitetura) e mantenho um modelo de referência por categoria — revisando essa escolha periodicamente, porque o cenário muda rápido. O erro mais comum que vejo é usar sempre o mesmo modelo para tudo, só porque foi o primeiro que funcionou bem uma vez.

O que fica

Prompt engineering maduro não é uma coleção de truques — é aplicar boas práticas de especificação e entender o trade-off de cada modelo para o problema que você tem na mão, não para o problema que o benchmark mediu.