---
title: "Engenharia de Contexto 3.0: Como o 'Prompt para Devs' precisa mudar para modelos recorrentes"
author: "Ricardo Pupo Larguesa"
date: "2026-05-04 16:06:00-03"
category: "Opinião"
url: "http://scale.press/portal/aintuicao/post/2026/05/04/engenharia-de-contexto-30-como-o-prompt-para-devs-precisa-mudar-para-modelos-recorrentes/md"
---

Certa vez, um aluno me fez uma pergunta que me obrigou a olhar para o meu próprio livro de um jeito diferente: "Professor, as técnicas de prompt funcionam do mesmo jeito em modelos baseados em RetNet ou Mamba?". E a resposta é: não exatamente.

A gente passa tanto tempo discutindo otimização de pesos e eficiência de treinamento, como o recente [paper do LoRA-FA](https://arxiv.org/abs/2308.03303), que propõe congelar a matriz de projeção *down* para poupar memória e tentar igualar a performance de um fine-tuning completo, que às vezes ignoramos uma mudança estrutural acontecendo na base da inferência. Estamos flertando novamente com a recorrência e os modelos de estado linear (State Space Models). E quando você troca a Atenção Global típica dos Transformers por mecanismos recorrentes, as regras de como conversamos com a máquina mudam.

## A ordem dos fatores altera o produto (e o estado)

Em um Transformer tradicional como o GPT, a injeção de prompt é quase um exercício de colagem estática. A arquitetura de Atenção olha para a janela de contexto inteira simultaneamente. A ordem das palavras importa pela semântica da linguagem, mas o modelo teoricamente tem acesso direto a qualquer token do passado. Já em modelos de arquitetura linear ou RetNet, lidamos com compressão contínua. O modelo "lembra" do começo do prompt através de um estado oculto que vai sendo atualizado passo a passo.

Na prática, colocar uma instrução principal, como uma *system message* dura, no início ou no fim do prompt gera matrizes de estado completamente diferentes na hora da geração da resposta. A ordem cronológica dos fatos ganha um peso mecânico que não existia de forma tão severa antes. Se você vomitar dados no começo do prompt e colocar a restrição de comportamento no final, um modelo recorrente pode já ter saturado seu vetor de estado com informações inúteis, degradando a capacidade de seguir a regra final.

## Do gerenciamento de tokens ao gerenciamento de estado

Se eu fosse escrever uma revisão estrutural do meu livro focada exclusivamente nessas novas arquiteturas, o capítulo sobre otimização precisaria ser rebatizado de "Economia de Tokens" para "Gerenciamento de Estado". Nós nos acostumamos a jogar blocos de texto gigantes no prompt baseados em busca vetorial. Como já apontei quando discutimos [o problema dos prompts gigantes em agentes](https://scale.press/portal/aintuicao/post/2026/02/21/o-fim-dos-prompts-gigantes-como-a-recuperacao-dinamica-de-instrucoes-itr-pode-reduzir-custos-em-70), saturar a janela de contexto custa caro.

Mas em arquiteturas recorrentes, saturar o início da interação com lixo significa sujar a memória de curto prazo da máquina de forma irreversível para aquela geração. O problema deixa de ser apenas financeiro e passa a ser qualitativo. Você precisa projetar o contexto como um funil de relevância estrita. [Essa evolução da Engenharia de Prompt para a Engenharia de Estrutura](https://scale.press/portal/aintuicao/post/2026/03/09/do-prompt-engineering-ao-structure-engineering-o-fim-dos-agentes-web-gananciosos) obriga o desenvolvedor a pensar no fluxo de dados, não apenas no texto gerado.

## Onde isso quebra em produção

Vejo isso acontecer com frequência na [T2S](http://t2s.com.br). Um time de desenvolvimento pega um template de prompt que funcionava lindamente na API da OpenAI e tenta rodar *zero-shot* em um modelo open-source menor baseado em arquiteturas alternativas, rodando localmente na infraestrutura. O resultado sai completamente esquizofrênico. A equipe imediatamente culpa o tamanho do modelo, argumentando que faltam parâmetros. Na grande maioria das vezes, o erro primário está na engenharia de contexto incompatível com a forma como aquela arquitetura processa a informação.

Isso significa que os Transformers vão morrer amanhã? Dificilmente. Mas a pressão por menor latência em inferência e janelas de contexto virtualmente infinitas está empurrando a indústria para adoção de abordagens híbridas. Quem desenvolve software precisa entender que o prompt deixou de ser um documento estático para se tornar um pipeline sequencial de eventos.

Talvez a pergunta certa para o desenvolvedor hoje não seja qual modelo é mais inteligente, mas sim como a arquitetura escolhida digere a informação que você está enviando. Se você quiser dominar os fundamentos de como construir essa interação em nível de código, antes que as abstrações escondam os problemas reais, meu livro [Engenharia de Prompt para Devs](https://www.casadocodigo.com.br/products/livro-engenharia-de-prompt) continua mapeando a base técnica necessária para não depender de tentativa e erro. Convido você a debater essas mudanças arquitetônicas diretamente comigo nas minhas redes sociais: [https://linktr.ee/ricardo.pupo](https://linktr.ee/ricardo.pupo).