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, 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, 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 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. 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 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.