Eu vi uma conta de $200 aparecer em uma conta da AWS da noite para o dia.
Não porque o sistema travou.
Um agente rodou em loop por seis horas sem condição de parada, chamando a API da OpenAI a cada iteração.
Todos os dashboards de monitoramento diziam que estava tudo bem.
Ninguém percebeu até a fatura chegar de manhã.
É isso que acontece quando você constroi sistemas de IA sem entender como eles realmente funcionam.
A maioria das pessoas aprende engenharia de IA ao contrário.
Instala uma biblioteca. Segue um tutorial. Chama uma API. Faz algo funcionar. Sente que está progredindo.
Aí algo quebra de uma forma que não faz sentido.
Eles mudam números aleatoriamente até parar.
Isso não é engenharia. É esperança com um teclado.
Aqui estão os 6 conceitos que resolvem isso.
A frase que explica tudo
Todo sistema de IA, por mais complexo que seja, é apenas:
Memória (RAG) + Pensamento (LLM + Tokens) + Ações (Agentes) + Medição (Evals)
…montados através da Engenharia de Contexto.
Esse é todo o campo.
Tudo abaixo é só detalhar o que cada parte realmente significa.
1. Tokens e a Janela de Contexto
LLMs não leem palavras. Eles leem pedaços chamados tokens.
"engenharia" → 1 token
"inacreditável" → 2 tokens Espaços e pontuação também contam.
Cada modelo tem uma janela de contexto — um limite fixo de tokens que pode segurar de uma vez.
→ Claude: 200.000 tokens
→ GPT-5: 400.000 tokens
Pense nisso como um quadro branco em uma sala de reunião.
O modelo só trabalha com o que está atualmente no quadro.
Quando o quadro enche, anotações antigas são apagadas para dar espaço.
O modelo não perde a capacidade de pensar.
Ele perde o acesso às informações anteriores.
Por que isso quebra sistemas em produção:
→ Tokens custam dinheiro — toda chamada de API cobra por token de entrada e saída
→ Históricos de chat longos enchem a janela rapidamente
→ Quando o contexto enche, instruções anteriores são descartadas silenciosamente
→ O que entra no contexto é uma decisão de engenharia, não um padrão
A falha que prova isso:
Uma equipe construiu um agente de suporte ao cliente com o histórico completo de 12 meses de chat como contexto em toda requisição.
Funcionou perfeitamente nos testes com 5 interações.
Em produção, após 50 interações, o agente começou a ignorar seu próprio prompt de sistema.
As instruções ainda estavam lá.
Elas estavam enterradas sob 80.000 tokens de histórico de conversa.
O modelo efetivamente parou de prestar atenção nelas.
A correção não foi um modelo melhor.
Foi resumir o histórico mais antigo para manter a janela focada.
A verdade desconfortável:
A maioria das "falhas de engenharia de prompt" são, na verdade, falhas de token e janela de contexto disfarçadas.
Engenheiros culpam o prompt quando o real problema é que a instrução crítica está na linha 3 de um contexto de 500 linhas, e o modelo parou de ponderá-la.
2. Embeddings e Busca Vetorial
Embeddings transformam significado em números para que "similaridade" possa ser calculada matematicamente.
O problema que eles resolvem:
Você tem 50.000 documentos. Um usuário faz uma pergunta. Você precisa dos 3 mais relevantes — sem ler todos os 50.000 toda vez.
A busca por palavras-chave falha aqui.
Se o documento diz "automóvel" e o usuário pergunta sobre "carros", a busca por palavras-chave não encontra.
Não porque a resposta não está lá. Porque as palavras não coincidiram.
Embeddings resolvem isso de forma diferente.
Um modelo de embedding converte texto em um vetor — uma lista de números representando o significado em um espaço matemático.
Texto semanticamente similar → vetores numericamente similares.
"carro" e "automóvel" → próximos um do outro
"carro" e "fotossíntese" → distantes um do outro
Como a busca vetorial realmente funciona:
- Cada documento é convertido em um vetor e armazenado
- A pergunta do usuário também se torna um vetor
- O sistema encontra os vetores armazenados mais próximos do vetor da pergunta
- Esses são seus documentos mais relevantes
Isso não é mágica aproximada. É geometria.
Similaridade é uma propriedade matemática real que você pode calcular.
Onde isso aparece em produção:
→ Busca semântica em qualquer sistema de documentos
→ Encontrar produtos, artigos, perfis de usuário similares
→ A etapa de recuperação no RAG (próximo conceito)
→ Memória em agentes de IA
3. RAG (Geração Aumentada por Recuperação)
Em vez de treinar um modelo nos seus dados, você recupera os dados relevantes no momento da consulta e os fornece ao modelo como contexto.
O problema que o RAG resolve:
LLMs sabem muita coisa. Eles não sabem seus dados.
Os documentos internos da sua empresa. Seu banco de dados de produtos. Seu histórico de suporte ao cliente.
Nada disso estava no conjunto de treinamento.
Duas opções: treinar um modelo nos seus dados (caro, lento, fica desatualizado instantaneamente) ou dar os dados ao modelo exatamente quando ele precisa.
RAG é a segunda opção, feita sistematicamente.
O pipeline de 3 etapas:
→ RECUPERAR:
pergunta se torna um vetor → banco de dados vetorial encontra os documentos armazenados mais similares → top 3-5 trechos recuperados
→ AUMENTAR:
documentos recuperados são adicionados ao contexto do modelo → prompt se torna "usando este contexto, responda esta pergunta"
→ GERAR:
modelo responde com base nos seus dados reais — não alucinados
Onde o RAG quebra:
→ Recuperação ruim = resposta ruim. O modelo só pode trabalhar com o que recebeu
→ Fragmentação (chunking) pobre separa a resposta do seu contexto
→ O modelo ainda pode alucinar se a recuperação não encontrar nada útil
Uma falha real de RAG:
Uma equipe construiu um assistente de conhecimento interno para um manual técnico de 500 páginas.
Funcionou perfeitamente em demonstrações. Em produção, as respostas eram vagas e às vezes erradas.
O problema: tamanho do fragmento (chunk).
Eles dividiram o manual em fragmentos de 1.000 tokens por contagem bruta de caracteres.
Tabelas foram divididas no meio da linha. Instruções passo a passo foram divididas no meio do passo.
A recuperação estava encontrando a área geral certa — mas perdendo a resposta real.
Reduzir o tamanho do fragmento pela metade e adicionar sobreposição corrigiu 80% dos problemas da noite para o dia.
A opinião firme:
RAG é superestimado quando sua recuperação é ruim.
O LLM não pode corrigir uma recuperação ruim. Ele só pode alucinar em torno dela.
Se você está vendo respostas erradas, pare de ajustar seu prompt.
Comece a medir sua precisão de recuperação.
É aí que está a resposta.
4. O Loop Agêntico
Agentes funcionam escolhendo repetidamente uma ação, executando-a, observando o resultado e decidindo o que fazer em seguida — até a tarefa ser concluída.
Uma chamada de LLM normal é sem estado (stateless). Você pergunta, ele responde, pronto.
Um agente tem estado (stateful). Ele age, observa, decide, repete.
O loop em português claro:
- Receber um objetivo
- Decidir a próxima ação
- Executá-la — pesquisar, codificar, ler um arquivo
- Observar o resultado
- Decidir a próxima ação com base no que foi aprendido
- Repetir até o objetivo ser concluído
- Retornar a resposta final
Ferramentas são o que dão poder aos agentes.
Sem ferramentas, um LLM só responde com texto.
Com ferramentas, ele pode pesquisar na web, ler arquivos, escrever código, chamar APIs, acionar qualquer ação que você definir.
Três coisas que iniciantes sempre erram:
→ Agentes sem condições de parada rodam para sempre. Você deve definir quando parar — limite de passos, limite de tempo ou condição de objetivo
→ Mais ferramentas ≠ melhor desempenho. Muitas ferramentas confundem o modelo sobre qual usar
→ Erros de ferramenta precisam de tratamento explícito. Uma falha silenciosa faz o agente produzir lixo com confiança
A falha de $200 da noite para o dia, em detalhes:
O agente não tinha um contador máximo de passos. Seu objetivo: pesquisar um tópico e produzir um resumo.
Uma de suas ferramentas de busca na web retornou um resultado vazio.
O agente não sabia como parar.
Ele continuou pesquisando, tentando novamente, gerando resumos intermediários — cada um desencadeando outra pesquisa.
Seis horas depois: 847 chamadas de LLM. 2,1 milhões de tokens consumidos. Um resumo coerente, mas completamente circular. Uma conta de $200.
A correção foi de três linhas: um contador máximo de passos, um manipulador explícito para resultados vazios, um caminho de escalonamento quando a confiança estava baixa.
O mesmo agente agora conclui em menos de 12 chamadas em média.
A opinião que você precisa ouvir:
A maioria dos agentes falha não porque o modelo é ruim — mas porque os engenheiros tratam o loop como se ele se autogerenciasse.
Não é.
Salvaguardas, condições de parada, manipuladores de erro — construídos desde o início, não adicionados após o primeiro incidente.
5. Evals (Avaliação)
Evals são como você sabe se seu sistema de IA está realmente funcionando — e se uma mudança o tornou melhor ou pior.
Este é o conceito que a maioria dos tutoriais pula porque não é glamouroso.
É também o que separa engenheiros que constroem demonstrações de engenheiros que constroem sistemas de produção.
O problema sem evals:
Você muda seu prompt. Atualiza sua lógica de recuperação. Muda para um modelo mais novo.
Ficou melhor?
Você não sabe. Você poderia verificar manualmente alguns exemplos — mas isso é um palpite, não uma evidência.
Como os evals realmente são:
→ Um conjunto de dados dourado (golden dataset): 25-50 entradas reais com saídas corretas conhecidas, cobrindo os principais casos de uso mais 5 casos extremos complicados conhecidos
→ Métricas binárias quando possível:
— O sistema RAG recuperou o documento correto? Sim/Não
— O agente concluiu sem erro? Sim/Não
— A resposta continha a informação necessária? Sim/Não
→ Pontuações agregadas monitoradas ao longo do tempo:
— Precisão de recuperação: 89% → mudança feita → 84%. Regressão encontrada.
— Taxa de conclusão de tarefa: 76% → nova versão do agente → 81%. Melhoria confirmada.
O ciclo de eval:
Implantar → Medir com evals → Encontrar falhas → Adicionar falhas ao conjunto de dados dourado → Corrigir → Executar evals novamente → Comparar pontuações → Lançar apenas se os números melhoraram
A verdade honesta:
"Utilidade: 3,7/5" não lhe diz nada acionável.
"Recuperou o documento correto: 84% das vezes" diz exatamente onde está o problema e o quanto uma correção o melhorou.
Um sistema de IA sem evals não é um produto.
É uma demonstração que você não pode alterar com confiança.
6. Engenharia de Contexto
A disciplina de decidir exatamente quais informações entram na janela de contexto do modelo, como são estruturadas e o que é deixado de fora.
Aqui está a opinião que deixa as pessoas desconfortáveis:
Engenharia de contexto importa mais do que engenharia de prompt.
Um prompt medíocre em um contexto bem curado supera um prompt brilhante enterrado no ruído — todas as vezes.
A maioria das equipes gasta 80% do esforço de otimização no prompt e quase nada no contexto.
Os resultados refletem isso.
A abordagem ingênua falha:
Incluir tudo. Todo o histórico. Todos os documentos recuperados. Toda descrição de ferramenta. O prompt de sistema. A mensagem do usuário. Tudo isso.
Isso falha por uma razão consistente: o modelo fica confuso sobre o que é mais importante.
Há um efeito documentado chamado "perdido no meio" (lost in the middle) — informações enterradas no fundo de um contexto longo têm menos probabilidade de serem usadas.
O que a engenharia de contexto realmente envolve:
→ Seleção: quais documentos, fatos ou histórico esta decisão específica precisa?
→ Compressão: partes mais antigas da conversa podem ser resumidas para economizar tokens?
→ Ordenação: instruções críticas pertencem ao início e ao fim — não ao meio
→ Podagem: o que pode ser removido sem afetar a qualidade da saída?
→ Estrutura: cabeçalhos, separadores, seções rotuladas afetam a confiabilidade com que o modelo usa as informações
Um exemplo prático:
Um agente está rodando há 45 minutos. Acumulou 80.000 tokens de histórico de conversa. Sua janela é de 128.000.
Você não quer perder o objetivo e as restrições originais, mesmo que o histórico preencha a janela.
Engenharia de contexto: comprimir saídas de ferramentas mais antigas, resumir raciocínios anteriores, manter a definição da tarefa proeminente durante toda a sessão.
Engenharia de prompt é escrever boas instruções.
Engenharia de contexto é construir o ambiente no qual essas instruções são realmente seguidas.
Como esses 6 conceitos formam um único sistema
MEMÓRIA → RAG + Embeddings (o que o sistema sabe)
PENSAMENTO → LLM + Tokens + Janela de Contexto (como ele raciocina com o que sabe)
AÇÕES → Loop Agêntico + Ferramentas (o que ele pode fazer no mundo)
MEDIÇÃO → Evals (como você sabe que está funcionando)
COLA → Engenharia de Contexto (o que decide o que flui entre todos os itens acima)
Um chatbot simples é apenas Pensamento.
Um agente de suporte ao cliente é Memória + Pensamento + Ações.
Um sistema de produção confiável adiciona Medição.
A sofisticação está em quão bem as peças se conectam.
O fluxo para qualquer requisição única:
Pergunta do usuário
→ Engenharia de Contexto decide o que incluir
→ Embeddings recuperam a Memória relevante (RAG)
→ Tokens determinam quanto cabe na janela
→ LLM raciocina sobre o contexto montado
→ Loop Agêntico decide se mais informações são necessárias
→ Evals medem se a saída estava realmente correta
Por onde começar
Você não precisa dominar todos os seis de uma vez.
→ Comece com tokens e janelas de contexto — eles afetam tudo que você constroi → Adicione embeddings quando precisar de busca semântica ou memória
→ Aprenda RAG quando precisar fundamentar um modelo em seus próprios dados
→ Aprenda o loop agêntico quando precisar de automação
→ Adicione evals antes de lançar qualquer coisa em produção
→ Aplique engenharia de contexto quando tudo o resto se tornar intuitivo
Essa sequência não é arbitrária.
Cada conceito torna o próximo aprendível.
A consideração final honesta
A maioria das equipes que luta com IA em produção não está lutando com o modelo errado ou a biblioteca errada.
Elas estão lutando porque pularam um desses seis conceitos.
O agente entra em loop infinito porque ninguém pensou em condições de parada.
As respostas do RAG estão erradas porque ninguém mediu a recuperação.
O prompt para de funcionar em sessões longas porque ninguém entendeu como a janela de contexto enche.
Esses não são problemas sofisticados.
São problemas básicos, disfarçados em vocabulário técnico.
As ferramentas mudam a cada seis meses.
Esses seis conceitos são como as ferramentas funcionam.
Aprenda os conceitos, e você nunca mais ficará confuso com uma nova ferramenta.
Mais importante — você nunca mais gastará $200 assistindo um agente em loop a noite toda, se perguntando o que deu errado.
Se isso foi útil:
→ Reposte para compartilhar com todo engenheiro de IA que você conhece
→ Siga @sairahul1 para mais sistemas e detalhamentos como este
→ Salve nos favoritos — você vai consultar isso na próxima vez que algo quebrar em produção
Eu escrevo sobre IA, construção de produtos e sistemas que funcionam enquanto você dorme.
