🪟 Janela de contexto, atenção e "lost in the middle"

A janela é uma string serializada que vive na memória do servidor do provedor durante a chamada. Quando você faz client.messages.create(...), o SDK monta essa string em um formato específico do modelo (ChatML, Anthropic XML, etc.) e envia. O modelo processa tudo de uma vez no prefill, depois gera tokens um a um. Essa visão muda decisões: ordenar para maximizar cache, recuperar menos para reduzir input, ou comprimir histórico antigo deixam de ser 'truques' e passam a ser engenharia.

<system>
  Você é um assistente conciso. Use formato JSON.
</system>
<few_shot>
  <example><in>...</in><out>...</out></example>
</few_shot>
<context>
  <doc id=42>...trecho recuperado por RAG...</doc>
</context>
<user>Qual a janela do modelo?</user>

Atenção causal significa que cada token, ao ser processado, só pode 'olhar' para tokens anteriores — não para o futuro. Isso permite paralelização do prefill (todos os tokens de input são processados juntos) e geração autoregressiva no decode. O KV cache guarda os estados key e value de cada camada para cada token já processado; se o prefixo não muda entre chamadas, o provedor reutiliza esses estados. Daí o ganho de prompt caching: ~10% do preço para tokens cacheados.

Posição não é só 'tokens 1, 2, 3...'. Modelos modernos usam RoPE (Rotary Position Embedding, Su et al. 2021), que codifica posição via rotação de pares de dimensões em cada cabeça de atenção. Resultado prático: o modelo dá peso estrutural diferente para tokens em posições diferentes — o início (prefix bias) e o fim (recency bias) recebem mais 'sinal' que o meio. Esse é o mecanismo concreto por trás do 'lost in the middle'.

Liu et al. (2023) construíram experimento controlado: pegaram um documento com a resposta correta e o inseriram em posições variáveis dentro de janelas de 10-32k tokens preenchidas com documentos distratores. Mediram a acurácia do modelo em encontrar a resposta. O resultado é uma curva em U consistente — acurácia ~75% quando a info está no topo, cai para ~50% no meio, sobe de novo para ~70% no fim. O efeito persiste em GPT-3.5, GPT-4, Claude 2, Llama-2. Não é bug de modelo único; é arquitetural.

A ordem certa não é estética — é alinhada a três forças: prompt cache (estável fica no início), atenção (instrução fica no fim), e ancoragem (pergunta repetida antes/depois do contexto recuperado). O padrão mais robusto é: system → few-shot → âncora-pergunta → contexto recuperado → âncora-pergunta → user-turn. Isso maximiza cache hit rate (~70-95% típico em chats), reduz lost-in-middle e dá ao modelo um sinal claro de 'a pergunta de fato é esta'.

msgs = [
    Message(role=SYSTEM, content=system_prompt),       # estável (cacheável)
    Message(role=USER, content=few_shot_canonico),     # estável (cacheável)
    Message(role=USER, content=(
        f'Pergunta: {pergunta}\n\n'                  # âncora 1
        f'<contexto>\n{contexto_recuperado}\n</contexto>\n\n'
        f'Pergunta (repete): {pergunta}'                # âncora 2
    )),
]

Janela nominal é o que o marketing fala (200k tokens, 1M tokens). Janela efetiva é onde a qualidade não degrada. O benchmark RULER (Hsieh et al. 2024) mede isso: muitos modelos com 128k nominal degradam significativamente acima de 32-64k em tarefas que exigem múltipla recuperação. Antes de assumir que cabe E funciona, faça um needle-in-a-haystack próprio com seus dados.