De 4K a 1 milhão de tokens: como a janela de contexto evoluiu e por que mais contexto não equivale a melhor memória

O número que mudou o mercado: o que é uma janela de contexto e o que ela não mede

A janela de contexto é o orçamento de tokens que um modelo pode considerar durante uma invocação. Em termos práticos, ela normalmente inclui as instruções, o histórico da conversa, os documentos anexados ou recuperados, as chamadas e os resultados de ferramentas reincorporados à interação e, conforme a interface, também a saída que será gerada. Por isso, um número de contexto não deve ser lido automaticamente como espaço disponível para documentos: parte do orçamento pode já estar ocupada antes de a tarefa começar.

Uma especificação de 128K, 200K ou 1 milhão de tokens descreve, antes de tudo, um limite de admissão ou uma configuração suportada. É uma propriedade importante: evita fragmentar desde o início um material extenso e pode permitir manter evidências, instruções e rastreabilidade em uma única solicitação. No entanto, ela não estabelece, por si só, que o sistema responderá com a mesma fidelidade para qualquer posição, resolverá contradições documentais ou transformará um trecho relevante em uma decisão correta.

Também convém distinguir contexto de memória em sentido amplo. Contexto é a informação fornecida na interação atual. Uma memória persistente exige armazenar, selecionar, atualizar e governar informações entre sessões ou tarefas. Um modelo pode receber um dossiê completo e, ainda assim, não dispor de um mecanismo confiável para decidir qual fato deve persistir, qual versão prevalece ou quando uma preferência anterior deixou de ser válida. Essa diferença é central no desenho de assistentes documentais e agentes.

A ampliação do contexto representa uma capacidade de entrada útil, não uma garantia geral de compreensão. A pergunta operacional não é qual é o maior número publicado, mas se, para uma distribuição específica de documentos e decisões, incorporar mais material melhora a precisão verificável sem ultrapassar os limites de custo e latência.

Cronologia útil: da atenção densa à extensão do contexto

O Transformer original colocou a atenção como mecanismo para relacionar posições de uma sequência e utilizou codificações posicionais para representar a ordem. Sua formulação de atenção completa é poderosa, mas comparar muitas posições entre si cria uma pressão de computação e memória que cresce rapidamente com o comprimento da sequência. Nos primeiros usos práticos de modelos de linguagem, janelas relativamente curtas não eram apenas uma decisão de produto: refletiam limites de treinamento e inferência.

A evolução posterior não seguiu uma única rota. Por um lado, surgiram melhorias de implementação que reduzem o tráfego entre memória e processador sem alterar o resultado matemático da atenção exata. FlashAttention é um marco representativo dessa via: reorganiza o cálculo levando em conta a hierarquia de memória. Ela não elimina, por si só, o crescimento associado à atenção densa, mas pode tornar viáveis comprimentos ou lotes que eram menos práticos com implementações anteriores.

Por outro lado, as representações posicionais tornaram-se uma parte decisiva da extensão. RoPE codifica a posição por meio de rotações; trabalhos posteriores propuseram interpolar posições para adaptar modelos com RoPE a janelas maiores mediante ajuste fino limitado. Esse mecanismo não equivale a demonstrar uso uniforme de todas as posições: ele modifica como distância e ordem são apresentadas ao modelo, enquanto o comportamento final também depende dos dados, do treinamento e da tarefa.

Uma terceira via trata o contexto como fluxo, e não como um bloco que deve permanecer íntegro no cache. Mecanismos de atenção em streaming com attention sinks propõem preservar um pequeno conjunto de estados de atenção junto com tokens recentes. Eles são relevantes para interações prolongadas, mas mudam o problema: uma política de retenção decide o que continua disponível e o que é descartado. Não constituem uma memória semântica infalível.

Por fim, fornecedores passaram a expor janelas de um milhão de tokens ou mais em algumas famílias de modelos. A documentação do Gemini apresenta essas capacidades junto com opções de cache e considerações de custo e latência. Isso é evidência de uma interface e de um produto disponíveis sob condições específicas; não deve ser convertido em demonstração independente de raciocínio confiável sobre qualquer milhão de tokens.

Quatro camadas que não devem ser confundidas

A primeira camada é a admissão. Um sistema admite uma entrada quando a tokeniza e a aceita dentro de seu limite. A segunda é o processamento efetivo sob um orçamento operacional: essa mesma entrada pode exigir um prefill prolongado, consumir capacidade de memória ou reduzir a concorrência disponível. Dois sistemas que admitem o mesmo volume podem comportar-se de forma diferente em tempo de resposta e custo por tarefa.

A terceira camada é a recuperação de informação. Aqui, a pergunta é se o modelo localiza um dado específico, uma cláusula, uma data ou uma relação quando ela está distribuída entre documentos e cercada por material plausível, porém irrelevante. A pesquisa sobre o fenômeno conhecido como perda na região intermediária avaliou tanto perguntas e respostas multidocumento quanto recuperação chave-valor e observou variação de desempenho conforme a posição da informação relevante. Essa evidência recomenda medir posições, e não apenas médias.

A quarta camada é o uso coerente da evidência. Um modelo pode citar ou extrair uma passagem correta e, em seguida, produzir uma síntese que mistura versões incompatíveis, viola uma regra de prioridade ou executa uma ação não justificada pela fonte. Essa camada exige tarefas de decisão e produção com critérios explícitos, e não apenas um teste de busca textual.

Essas camadas também ajudam a evitar um erro frequente em comparações: transformar o limite de entrada de uma API em uma classificação global de capacidade. Para comparar opções na rota de comparação, é preferível registrar separadamente entrada máxima, saída máxima, modalidade, desempenho medido em uma tarefa e condições da medição. O número nominal é um atributo; a confiabilidade é um resultado empírico.

O que muda na inferência: prefill, geração, cache KV e concorrência

A inferência longa tem ao menos duas fases com perfis distintos. No prefill, o sistema processa os tokens de entrada para construir os estados necessários à continuação da geração. Na fase de decodificação, ele gera novos tokens de modo incremental e reutiliza esses estados. Uma entrada extensa pode concentrar uma parte importante da espera inicial, mesmo que a resposta final seja curta; uma saída extensa acrescenta depois sua própria duração.

O cache de chaves e valores, ou cache KV, evita recalcular, para cada token gerado, as representações dos tokens anteriores. Ele é essencial para uma geração eficiente, mas ocupa memória, e seu tamanho cresce com o comprimento atendido, a arquitetura, a precisão e o número de solicitações simultâneas. O trabalho sobre quantização assimétrica de dois bits para cache KV identifica esse cache como um gargalo de memória, especialmente à medida que crescem o contexto e o tamanho do lote. A quantização pode aliviar essa pressão, mas introduz uma escolha adicional de qualidade, compatibilidade e avaliação.

O custo real também não é uma tarifa plana obtida apenas multiplicando tokens por preço. Influem o prefill, o comprimento de saída, a reutilização ou o cache de contexto quando houver, as tentativas repetidas, o número de turnos, a concorrência e a capacidade reservada. A documentação de contexto longo do Gemini alerta para considerações específicas de latência e preço; tais condições devem ser verificadas na versão vigente da documentação e na carga de trabalho própria.

Por isso, uma avaliação deve apresentar distribuição, não apenas média. A média pode ocultar que os casos longos bloqueiam recursos ou elevam de forma relevante o percentil 95 de latência. Ela também deve separar o tempo de preparação do contexto, o primeiro token e a conclusão, pois cada medida sugere uma mitigação diferente.

Por que testes simples falham

Uma demonstração em que a resposta está no início ou no fim de um documento limpo não representa a maioria dos repositórios reais. A evidência relevante pode estar em posições intermediárias, em uma tabela, em uma versão anterior que foi substituída ou distribuída entre fontes com terminologia diferente. Repetir a mesma pergunta em muitas posições permite detectar degradação posicional que um único teste não revela.

Os distratores devem ser plausíveis. Adicionar texto aleatório mede principalmente robustez a ruído fácil; adicionar políticas semelhantes, números antigos ou cláusulas quase idênticas mede a capacidade de resolver ambiguidade. Também convém introduzir contradições controladas e definir antecipadamente a regra de resolução: por exemplo, prevalece a versão aprovada mais recente ou a fonte designada como normativa. Sem uma regra de referência, não é possível atribuir uma falha ao modelo.

Os agentes acrescentam outra pressão: o contexto compete com descrições de ferramentas, resultados de buscas, estados de execução e mensagens de segurança. Uma janela maior pode reduzir a necessidade de cortar conteúdo, mas também facilita que informação obsoleta ou irrelevante continue influenciando. O desenho deve limitar quais resultados são reincorporados e preservar identificadores de procedência para revisar por que uma ação foi tomada.

Não basta pedir ao modelo que afirme ter usado uma fonte. A saída deve conter referências internas a trechos estáveis do corpus congelado, e um avaliador deve verificar se elas sustentam a resposta. A rastreabilidade não elimina alucinações nem garante que a inferência seja válida, mas transforma uma afirmação em um objeto revisável.

Contexto longo versus RAG, resumo e memória persistente

Contexto longo, recuperação aumentada por geração — RAG —, resumos e memória persistente são padrões complementares, não degraus de uma mesma escala. O contexto longo preserva mais material literal em uma chamada. RAG seleciona um subconjunto a partir de um índice ou repositório. O resumo comprime informação, ao custo de poder perder detalhes. A memória persistente mantém dados entre interações por meio de políticas de escrita, atualização, expiração e acesso.

RAG é adequado quando o repositório ultrapassa a janela, muda com frequência ou exige filtragem por permissões, data, entidade ou jurisdição. Também reduz a quantidade de texto que deve ser processada em cada turno. Seus riscos se deslocam para a indexação, o recall, o ranking e a perda de relações entre trechos. Um contexto longo pode ser preferível quando a tarefa depende de comparar muitas partes de um conjunto delimitado, desde que os testes demonstrem benefício frente a uma seleção bem configurada.

Resumos ajudam a manter continuidade, mas não devem ser tratados como fonte primária quando a tarefa exige precisão literal. Uma arquitetura prudente preserva ligações entre o resumo e os trechos de origem, permite retornar a eles e distingue fatos extraídos, interpretações e decisões. A memória persistente exige ainda mais governança: quem pode escrevê-la, o que pode ser esquecido, como ela é corrigida e quais dados não devem persistir.

A escolha deve partir de evidência própria. Na rota de descoberta, é possível identificar quais documentos, ferramentas e restrições caracterizam o fluxo; na rota de aprendizado, a equipe pode estabelecer definições e critérios; e na rota de comparação, pode contrastar resultados sob o mesmo corpus e orçamento. A arquitetura padrão não deveria ser definida pelo comprimento anunciado.

Protocolo de avaliação próprio: da demonstração à decisão

Um protocolo mínimo começa com um corpus congelado e documentado. Ele deve incluir formatos e comprimentos representativos, versões, metadados permitidos e uma separação clara entre desenvolvimento e avaliação final. Para cada tarefa, define-se uma resposta esperada, a evidência que a sustenta, a regra para resolver conflitos e o nível de risco de uma resposta incorreta. Se não houver uma resposta única, o critério deve admitir incerteza ou escalonamento humano.

Em seguida, distribua a evidência relevante em várias posições: início, região intermediária e fim. Varie a distância entre peças que precisam ser combinadas e acrescente distratores semanticamente próximos. Avalie ao menos extração literal, resposta multidocumento, resolução de contradições e uma decisão ou ação com restrições. As métricas devem separar fidelidade das citações, precisão da decisão, taxa de abstenção apropriada, custo por caso correto e percentis de latência.

Compare configurações que consumam orçamentos semelhantes: contexto completo, RAG, RAG com documentos vizinhos, resumo com retorno à fonte e, quando aplicável, contexto longo com cache. Mantenha fixos o modelo, as instruções e o avaliador quando o objetivo for isolar a arquitetura. Quando o modelo mudar, informe a mudança como uma variável adicional e evite atribuir todo o efeito ao comprimento.

Antes de adotar uma solução, estabeleça limites explícitos. Por exemplo, uma melhoria deve superar uma margem definida em decisões corretas e fidelidade da evidência, não piorar o p95 acima do limite de serviço e permanecer dentro de um custo máximo por tarefa válida. Os valores concretos dependem do caso de uso; não podem ser deduzidos de uma especificação pública de contexto.

Como ler 128K, 200K ou 1M de tokens sem prometer compreensão ilimitada

Uma especificação responsável deve ser lida junto com cinco perguntas: qual é a entrada máxima, qual é a saída máxima, quais modalidades ela aceita, quais condições de preço e latência se aplicam e qual comportamento foi medido na tarefa de interesse. Entrada e saída não são intercambiáveis: reservar uma saída ampla pode reduzir o espaço disponível para documentos, e uma tarefa com resposta curta ainda pode sofrer espera considerável durante o prefill.

A data e a versão da documentação também importam. Limites, modelos, modalidades e políticas de cache podem mudar. Em uma ficha interna, convém registrar a data de consulta, o identificador exato do modelo ou serviço e as condições relevantes, em vez de guardar apenas um número que em breve pode ficar desatualizado.

A conclusão não é que janelas longas sejam inúteis. Elas são uma ampliação técnica relevante e podem simplificar tarefas que antes exigiam fragmentação agressiva. A conclusão é mais limitada: a utilidade deve ser demonstrada na distribuição real de documentos, com evidência rastreável e dentro de um envelope operacional aceitável. Mais tokens disponíveis podem melhorar uma aplicação; mais tokens sem seleção, avaliação ou governança podem aumentar o custo e a superfície de erro.

Para equipes de produto, a decisão prática é tratar o contexto como um orçamento mensurável. Envie mais informação quando isso aumentar de forma demonstrável a recuperação e a decisão; recupere, resuma, peça esclarecimentos ou escale quando isso oferecer melhor evidência e controle. Assim, uma janela de um milhão de tokens deixa de ser uma promessa abstrata e passa a ser uma opção técnica avaliável.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.