Contexto é tudo

Se eu tivesse que escolher uma única ideia para alguém levar deste guia, seria esta: o modelo não te conhece, não lembra de ontem e não sabe nada do seu projeto. Ele só sabe o que está escrito na janela, agora.

Tudo o que parece memória, personalidade ou “ele já me entende” é alguém — você ou o produto — colocando texto de volta nessa janela.

O que o modelo enxerga quando você pergunta?

A melhor imagem que conheço para isso é do Andrej Karpathy, que descreve os modelos de linguagem como um novo tipo de computador: o modelo faz o papel da CPU, e a janela de contexto é a memória — a RAM. (Vale ver a palestra inteira.)

A CPU de um computador só processa o que foi carregado na RAM. O modelo só raciocina sobre o que foi carregado no contexto: suas instruções, os documentos anexados, o histórico da conversa, a descrição das ferramentas que ele pode usar, os resultados dessas ferramentas. Tudo isso é medido em tokens (pedaços de palavra) e compete pelo mesmo espaço.

Engenharia de contexto é o nome que pegou para o trabalho de decidir o que entra nessa RAM. É a evolução natural da engenharia de prompt: antes a gente caprichava em uma instrução; agora a gente administra tudo o que o modelo vê ao longo de uma tarefa longa. Quando o termo apareceu eu fiquei em dúvida se precisávamos de mais um conceito — mas a ideia por trás eu defendo desde sempre: a habilidade humana mais importante agora é saber comunicar e entregar a informação e as ferramentas certas.

Mais contexto é melhor contexto?

A intuição diz: “na dúvida, joga tudo lá dentro”. É o erro mais comum que eu vejo.

Modelos de linguagem funcionam relacionando cada token com todos os outros. Quanto mais coisa na janela, mais essa atenção se espalha. Há quem chame isso de orçamento de atenção: é finito, e cada token novo gasta um pouco dele. Quando o orçamento estoura, aparece o que se convencionou chamar de context rot, a queda de desempenho que já foi medida conforme a entrada cresce. O modelo esquece uma instrução do começo, confunde documentos, repete o que já fez. Não é que ele “trava” — ele vai ficando gradualmente pior.

Daí sai o princípio prático: procurar o menor conjunto de tokens de alto sinal que resolve a tarefa.

Qual é a altitude certa de uma instrução?

Um texto sobre engenharia de contexto para agentes tem uma ideia que mudou meu jeito de escrever instruções: existe uma altitude certa, uma zona “Cachinhos Dourados” entre dois erros.

SE a pergunta contiver "táxi" E valor < 80 ENTÃO responda "Aprovado".
SE a pergunta contiver "táxi" E valor >= 80 ENTÃO responda "Precisa de aprovação".
SE a pergunta contiver "carro com motorista" ENTÃO trate como "táxi".
SE a pergunta contiver "almoço" E for dia útil ENTÃO ...
(mais 36 regras)

Você é um assistente prestativo. Ajude as pessoas da equipe com reembolsos.
Seja educado e preciso.

<contexto>
Você atende pessoas da empresa com dúvidas sobre reembolso de
despesas. A política vigente está em <politica>. Quem pergunta em geral
está com pressa e quer saber: posso ou não posso, e qual o próximo passo.
</contexto>

<instrucoes>
1. Responda com base apenas na política. Cite o item que usou.
2. Se a política não cobrir o caso, diga isso claramente e indique
   quem aprova exceções. Não estime valores nem prazos.
3. Comece pela resposta; explique depois, em até três frases.
</instrucoes>

<politica>
(somente os trechos relevantes da política)
</politica>

E no dia a dia?

• Explico o porquê, não só o quê. “Responda curto porque a pessoa lê no celular entre duas reuniões” funciona melhor que “responda curto”.
• Separo as partes. Títulos em Markdown ou marcações como <contexto> ajudam o modelo a não misturar instrução com documento.
• Trago só o trecho. Em vez do manual de 300 páginas, as três páginas que importam. Se eu não sei quais são, esse é o primeiro pedido: “ache os trechos sobre X”.
• Começo conversa nova quando muda o assunto. Histórico velho é ruído. Se preciso levar algo adiante, peço um resumo e colo no começo da nova.
• Ligo poucas ferramentas. Cada conector ocupa espaço na janela só por existir. E eu fico de olho no medidor que a ferramenta mostra: quando uma sessão passa de dois terços da janela ocupada, já estou pensando em fechar e começar outra.
• Guardo o contexto fora da conversa. Tudo o que eu não quero explicar de novo vira arquivo no repositório do projeto — assunto do capítulo 11.