A engenharia de prompt virou uma linha de custo: quanto mais agentes, automações e copilots internos um time roda em produção, maior a conta de tokens de IA no fim do mês.
Mas o problema não é usar IA: é não ter estrutura para usá-la. Prompt longo demais, contexto repetido em toda chamada, histórico inteiro reenviado do zero: cada um desses hábitos vira dinheiro saindo da conta, mês após mês.
Neste artigo, você verá por que engenharia de prompt reduz custo, como a engenharia de contexto entra nessa conta, técnicas práticas para aplicar hoje e os erros mais comuns que fazem qualquer equipe gastar token à toa. Boa leitura.
Toda chamada a um modelo de linguagem cobra por token, de entrada e de saída. Um prompt maior consome mais tokens de entrada antes mesmo do modelo processar qualquer coisa; uma resposta mais longa consome mais tokens de saída, geralmente a um preço por unidade ainda maior que o de entrada. Engenharia de prompt, ou prompt engineering, como a comunidade internacional chama, é, na prática, o trabalho de desenhar essa troca com critério, para que cada token gasto tenha função clara na resposta que volta.
A diferença entre um prompt de tentativa e erro e um prompt engenheirado aparece nesse ponto. O primeiro cresce por acúmulo: alguém adiciona uma instrução aqui, um exemplo ali, sem revisar o que já existia, até o prompt virar um arquivo de regras empilhadas sem hierarquia. Já o segundo define papel, formato de saída e restrição desde o início, e cada linha adicionada precisa justificar seu próprio custo em tokens.
Isso não é otimização cosmética. Um prompt mal estruturado não só custa mais: ele também tende a degradar a qualidade da resposta, porque o modelo passa a lidar com ruído (instrução redundante, contexto desorganizado) em vez de sinal. Reduzir tokens com engenharia de prompt bem aplicada geralmente melhora a resposta, porque força clareza sobre o que realmente importa na tarefa.
O termo prompt engineering ganhou tração a partir de 2020, quando a API do GPT-3 tornou públicas as primeiras técnicas sistemáticas de moldar o comportamento de um modelo só pela forma como a entrada era escrita, sem ajustar peso nenhum do modelo em si. Virou disciplina reconhecida quando ficou claro que pequenas mudanças de estrutura, ordem e exemplo mudavam bastante a qualidade e o custo da resposta, abrindo caminho para o que depois seria chamado de context engineering, a extensão do mesmo problema para janelas de contexto maiores e agentes de múltiplas etapas.
Context engineering, em português engenharia de contexto, trata de um problema que vai além do prompt: o que entra na janela de contexto a cada chamada. Histórico de conversa, documentos recuperados por RAG, memória de sessão, instruções de sistema: tudo isso ocupa espaço na mesma janela finita, e todo token ali dentro é cobrado, relevante ou não para a resposta atual. A própria Anthropic descreve esse trabalho, em documentação técnica publicada sobre agentes, como o de "otimizar a utilidade dos tokens contra as restrições inerentes dos LLMs para alcançar o resultado desejado de forma consistente".
Context engineering, então, evoluiu como resposta a um limite físico: por mais que as janelas de contexto tenham crescido de milhares para centenas de milhares de tokens em poucos anos, cada token disponível continua sendo recurso finito e cobrado. O trade-off é sempre entre dar ao modelo informação suficiente para responder bem e não pagar por informação que ele nunca vai usar, e esse equilíbrio muda a cada caso de uso, não existe configuração universal.
Uma forma simples de pensar nisso é: a janela de contexto funciona como memória de curto prazo do modelo, ou seja, tudo que está lá dentro custa atenção e custa token, mesmo que só uma fração seja de fato usada na resposta final. Gerenciar essa memória com critério é o núcleo do trabalho de engenharia de contexto, tanto quanto engenharia de prompt é o núcleo do trabalho sobre a instrução em si.
Em produção, o erro mais comum é tratar o histórico como algo que se acumula e se reenvia por completo a cada chamada. Um agente que já trocou quarenta mensagens com o usuário carrega esse histórico inteiro na próxima chamada, mesmo que só as últimas trocas sejam relevantes para a pergunta atual. Truncar por relevância, ou resumir o que já aconteceu em vez de reenviar tudo, corta esse custo sem perder o contexto que de fato importa para a tarefa em andamento.
O mesmo raciocínio vale para RAG: jogar documentos inteiros no prompt para garantir que "a resposta está ali" é o caminho mais caro e menos preciso. Recuperar apenas os trechos mais relevantes, bem recortados e não o documento completo, reduz o consumo de tokens e tende a aumentar a precisão da resposta, porque o modelo lida com menos ruído para localizar a informação certa dentro do contexto.
Um exemplo simples ilustra o efeito prático: um agente de suporte que processa quarenta mensagens de histórico a cada chamada, sem truncamento, paga o custo do texto completo em toda nova pergunta, mesmo que só as últimas trocas sejam relevantes. Resumir o histórico anterior em poucas linhas e manter apenas as últimas mensagens literais reduz esse texto reenviado a uma fração do original, sem alterar a qualidade da resposta percebida pelo usuário final.
Leia também: Como a Lughy usa IA para desenvolvimento de software com segurança, criticidade e foco em qualidade
Algumas práticas de engenharia de prompt têm impacto direto e mensurável no consumo de tokens de IA sem exigir reescrever a arquitetura do sistema. São ajustes que qualquer time técnico consegue aplicar de forma incremental.
Pense nessas práticas como manutenção preventiva, não como retrofit emergencial: aplicadas desde o desenho do sistema, custam pouco esforço de implementação. Aplicadas só depois que a fatura assustou o time financeiro, exigem reengenharia de prompts que já estão espalhados por múltiplos serviços, integrações e times diferentes, o que é sempre mais caro e mais arriscado de mudar. As mais recorrentes na prática são:
Nenhuma dessas práticas depende de trocar de modelo ou renegociar contrato com provedor. São ajustes de disciplina de engenharia e, combinadas, reduzem o consumo de tokens sem perda de qualidade.
Do outro lado da mesma moeda, alguns hábitos são responsáveis pela maior parte do desperdício de tokens que aparece na fatura no fim do mês.
Sob prazo curto, copiar um prompt que já funcionou em outro contexto é mais rápido do que desenhar um novo do zero, e reenviar o histórico inteiro é mais simples de implementar do que uma lógica de truncamento inteligente. O problema é que "mais rápido de implementar" e "mais barato de operar" raramente são a mesma coisa quando o assunto é IA em produção. Vale revisar se algum destes está presente no fluxo do seu time:
Cada um desses erros parece pequeno isoladamente, mas soma no fim do mês. Engenharia de prompt madura trata isso como qualquer outra dívida técnica: precisa de revisão contínua.
Prompt engineering é sobre estrutura, contexto e disciplina, e essas três coisas se traduzem em economia de tokens de IA e previsibilidade de custo: o tipo de resultado que qualquer time técnico consegue defender internamente com número, não com opinião.
Revisão de prompt, gestão de contexto e monitoramento de consumo são as práticas de engenharia de prompt que a Lughy aplica no dia a dia dos projetos de IA que desenvolve, como parte do próprio trabalho de engenharia. Saiba mais como a Lughy atua na engenharia de software com IA.
