Eu vi uma conta de $200 aparecer na AWS da noite para o dia.
Não porque o sistema quebrou.
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 saudável.
Ninguém percebeu até a fatura chegar de manhã.
É isso que acontece quando você constrói sistemas de IA sem entender como eles realmente funcionam.
A maioria das pessoas aprende engenharia de IA ao contrário.
Instalar uma biblioteca. Seguir um tutorial. Chamar uma API. Fazer algo funcionar. Sentir que está progredindo.
Então 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.
Isso é o campo inteiro.
Tudo abaixo é apenas desdobrar 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
"incrível" → 2 tokens Espaços e pontuação também contam.
Cada modelo tem uma janela de contexto — um limite rígido 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 abrir espaço.
O modelo não perde a capacidade de pensar.
Ele perde acesso às informações anteriores.
Por que isso quebra sistemas em produção:
→ Tokens custam dinheiro — cada chamada de API cobra por token de entrada e saída
→ Históricos longos de conversa enchem a janela rapidamente
→ Quando o contexto enche, instruções anteriores são silenciosamente descartadas
→ O que vai para o 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 12 meses completos de histórico de chat como contexto em cada 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 solução não foi um modelo melhor.
Foi resumir o histórico mais antigo para manter a janela focada.
A verdade incômoda:
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 problema real é 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 "similar" possa ser calculado 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 corresponderam.
Embeddings resolvem isso de forma diferente.
Um modelo de embedding converte texto em um vetor — uma lista de números representando significado no espaço matemático.
Texto semanticamente similar → vetores numericamente similares.
"carro" e "automóvel" → próximos
"carro" e "fotossíntese" → distantes
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 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 (Retrieval-Augmented Generation - Geração Aumentada por Recuperação)
Em vez de treinar um modelo com seus dados, você recupera os dados relevantes no momento da consulta e os alimenta para o modelo como contexto.
O problema que o RAG resolve:
LLMs sabem muito. Eles não sabem seus dados.
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 com seus dados (caro, lento, fica desatualizado instantaneamente) ou dar os dados ao modelo exatamente quando ele precisa.
RAG é a segunda opção, feita de forma sistemática.
O pipeline de 3 etapas:
→ RECUPERAR:
pergunta se torna um vetor → banco de dados vetorial encontra os documentos armazenados mais similares → top 3-5 chunks recuperados
→ AUMENTAR:
documentos recuperados são adicionados ao contexto do modelo → prompt se torna "usando este contexto, responda esta pergunta"
→ GERAR:
modelo responde fundamentado em seus dados reais — não alucinado
Onde o RAG quebra:
→ Recuperação ruim = resposta ruim. O modelo só pode trabalhar com o que recebeu
→ Chunking inadequado 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 chunk.
Eles dividiram o manual em chunks de 1.000 tokens por contagem bruta de caracteres.
Tabelas divididas no meio da linha. Instruções passo a passo divididas no meio do passo.
A recuperação estava encontrando a área geral certa — mas perdendo a resposta real.
Reduzir o tamanho do chunk pela metade e adicionar sobreposição resolveu 80% dos problemas da noite para o dia.
A opinião firme:
RAG é superestimado quando sua recuperação é ruim.
O LLM não pode consertar uma recuperação ruim. Ele só pode alucinar ao redor 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é que a tarefa esteja concluída.
Uma chamada de LLM comum é sem estado. Você pergunta, ele responde, pronto.
Um agente tem estado. 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é que o objetivo seja concluído
- Retornar a resposta final
Ferramentas são o que dá poder aos agentes.
Sem ferramentas, um LLM apenas 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, em detalhes:
O agente não tinha um número 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 acionando outra busca.
Seis horas depois: 847 chamadas de LLM. 2,1 milhões de tokens consumidos. Um resumo de aparência coerente, mas completamente circular. Uma fatura de $200.
A correção foram três linhas: um contador máximo de passos, um tratador explícito para resultados vazios, um caminho de escalonamento quando a confiança estava baixa.
O mesmo agente agora completa em média em menos de 12 chamadas.
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 fosse autogerenciável.
Não é.
Salvaguardas, condições de parada, tratadores 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 melhorou ou piorou.
Este é o conceito que a maioria dos tutoriais pula porque não é glamoroso.
É 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.
Melhorou?
Você não sabe. Você poderia verificar manualmente alguns exemplos — mas isso é um palpite, não evidência.
Como os evals realmente são:
→ Um conjunto de dados dourado: 25-50 entradas reais com saídas corretas conhecidas, cobrindo casos de uso principais 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 completou sem erro? Sim/Não
— A resposta continha a informação necessária? Sim/Não
→ Pontuações agregadas rastreadas 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 te diz nada acionável.
"Recuperou o documento correto: 84% das vezes" te diz exatamente onde está o problema e 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 vão para a 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 em ruído — todas as vezes.
A maioria das equipes gasta 80% do esforço de otimização no prompt e quase nenhum 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 falha por uma razão consistente: o modelo fica confuso sobre o que é mais importante.
Há um efeito documentado chamado "perdido no meio" — informações enterradas profundamente em 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
→ Poda: 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 com o histórico preenchendo 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 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 tudo 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 Memória relevante (RAG)
→ Tokens determinam quanto cabe na janela
→ LLM raciocina sobre o contexto montado
→ Loop Agêntico decide se mais informação é necessária
→ 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ê constrói → 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 enviar qualquer coisa para produção
→ Aplique engenharia de contexto conforme todo 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 para sempre 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, vestidos com 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 ferramenta nova.
Mais importante — você nunca mais gastará $200 vendo um agente em loop a noite inteira, se perguntando o que deu errado.
Se isso foi útil:
→ Republique para compartilhar com todos os engenheiros de IA que você conhece
→ Siga @sairahul1 para mais sistemas e análises como esta
→ 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.
