O que é a janela de contexto de um modelo de IA
A janela de contexto é a quantidade de texto que um modelo de linguagem «vê» em uma única requisição: seu prompt, o histórico do chat, documentos enviados e a resposta do modelo. Caber ou não uma base de código inteira, um contrato longo ou só um chat curto em uma chamada de API depende do tamanho da janela. A seguir: o que é a janela de contexto, como se mede em tokens e por que é um dos principais parâmetros na escolha do modelo.
Definição em termos simples
A janela de contexto (context window) é o número máximo de tokens que o modelo pode processar em uma requisição. Token não é palavra nem caractere: é um fragmento de texto após a tokenização. Em russo e inglês, um token corresponde a cerca de 3-4 caracteres ou parte de uma palavra; «programação» pode ocupar 2-3 tokens.
O modelo não «lembra» sessões anteriores por conta própria. Tudo o que ele sabe no momento da resposta é o que você passou na requisição atual dentro da janela. Se o diálogo ou o documento ultrapassar o limite, trechos antigos são cortados ou precisam ser comprimidos com técnicas separadas (RAG, sumarização, chunking).
Como a janela funciona na prática
Em uma requisição típica de API, o contexto inclui:
- System prompt - instruções ao modelo (papel, formato de resposta, restrições).
- Histórico de mensagens - turnos anteriores de user e assistant no chat.
- Anexos - texto de PDF, código do repositório, trechos da base de conhecimento.
- Saída do modelo - em muitos modelos, a resposta também conta para o limite total de uma chamada.
O esquema é simples: input + output ≤ tamanho da janela de contexto (alguns modelos limitam input e output separadamente, mas a lógica é a mesma - há um teto por chamada).
Exemplo para janela de 128K:
| Componente | Tamanho aproximado |
|---|---|
| System prompt | 500-2.000 tokens |
| Histórico (20 mensagens) | 5.000-15.000 |
| Documento enviado | 80.000 |
| Resposta do modelo | até 8.000-16.000 |
Se a soma exceder o limite, a API retorna erro ou a plataforma corta automaticamente o início do histórico - conforme o cliente.
Contexto de entrada e de saída
Desenvolvedores costumam confundir dois conceitos:
- Input context - quantos tokens o modelo aceita (prompt + histórico + arquivos).
- Max output tokens - limite superior do tamanho da resposta por chamada (parâmetro separado na API, ex.
max_tokens).
Um modelo com janela de 1M pode aceitar quase um milhão de tokens de entrada, mas a resposta ainda pode ser limitada a, por exemplo, 8K-64K tokens por chamada. Relatórios longos às vezes exigem várias requisições sequenciais ou streaming com continuação.
Em alguns planos, requisições long-context (acima de um limiar, ex. 200K de input) custam mais - refletem maior carga de inferência.
Por que uma janela de contexto grande importa
Contexto grande ajuda quando uma requisição precisa manter muita informação relacionada:
- Análise de documentos - contratos, relatórios, pesquisas com dezenas de páginas sem compressão prévia.
- Trabalho com código - vários arquivos do projeto, stack trace e histórico de alterações em um prompt.
- Diálogos longos - suporte e consultoria onde toda a conversa importa, não só as últimas 10 mensagens.
- Cenários agentic - um agente acumula observações, chamadas de ferramentas e resultados intermediários em uma sessão.
Janela pequena (4K-32K) basta para tarefas curtas: classificação, extração de campos de formulário, tradução de parágrafo, chatbot simples. Cenários enterprise com documentos e código costumam mirar 128K ou mais.
Tamanhos típicos em 2026
Em meados de 2026 o mercado se divide em vários níveis:
| Nível | Tamanho da janela | Modelos de exemplo | Tarefas típicas |
|---|---|---|---|
| Compactos | 8K-32K | Modelos locais leves, APIs antigas | Chat, classificação |
| Padrão | 128K-200K | GPT-5.5, Claude Sonnet 5, Gemini 3.1 Pro | Código, documentos, agentes |
| Estendidos | 1M-2M | GPT-5.6, Claude Fable 5, Gemini 3.5 Flash | Repositórios grandes, corpora |
O contexto cresce mais rápido que o comprimento «útil»: o modelo pode aceitar tecnicamente um milhão de tokens, mas a qualidade na cauda mais longa pode cair (efeito «lost in the middle» - o modelo usa pior a informação do meio de contextos longos). Janela grande não substitui arquitetura bem pensada, mas amplia capacidades.
Limitações e alternativas
Mesmo com janela de 2M, nem tudo deve ir em um único prompt:
- Custo - input é cobrado por tokens; um milhão de tokens por requisição encarece rápido a produção.
- Latência - contexto longo demora mais na GPU.
- Qualidade - fatos relevantes é melhor fornecer explicitamente do que «enterrar» no meio de 500 páginas.
Padrões úteis quando a janela é apertada ou para economizar:
- RAG (Retrieval-Augmented Generation) - buscar trechos relevantes em base vetorial e injetar só esses no prompt.
- Sumarização - comprimir mensagens antigas ou seções do documento com chamada separada ao modelo.
- Chunking - dividir texto em partes e agregar resultados.
- Janela deslizante - só as últimas N mensagens mais breve resumo do passado no histórico.
Em produção, combina-se frequentemente: RAG para fatos da base de conhecimento + histórico moderado + modelo 128K-1M para requisições «pesadas».
Como escolher o tamanho da janela para a tarefa
| Tarefa | Mínimo recomendado | Comentário |
|---|---|---|
| Bot FAQ, classificação de intenção | 8K-16K | Histórico curto, documentos via RAG |
| Copilot para um repositório | 128K-1M | Depende do tamanho do codebase |
| Revisão legal / compliance | 200K+ | PDFs longos, referências cruzadas |
| Documentos multimodais | 1M+ | Texto + imagens consomem mais tokens |
Antes de escolher o modelo, estime o volume real de input: conte tokens de uma requisição típica (tiktoken, tokenizer da API ou count_tokens do provedor) e reserve 20-30% de margem para resposta e crescimento do histórico.
Conclusão
A janela de contexto é a «memória de trabalho» do modelo de linguagem para uma requisição. Mede-se em tokens e inclui prompt, histórico, anexos e muitas vezes espaço para a resposta. Janelas grandes (128K-2M) permitem analisar documentos e bases de código longas sem cortar constantemente, mas não substituem RAG, sumarização e controle de custo. Na escolha do modelo, olhe não só o número na ficha técnica, mas também qualidade em contexto longo, tarifas long-context e o tamanho real das requisições típicas.
Perguntas frequentes
Em que um token difere de uma palavra?
Token é unidade de texto após a tokenização do modelo. Uma palavra pode ser um ou vários tokens; pontuação e espaços também contam. Em média para russo e inglês, 1000 tokens ≈ 750-900 palavras ou 3000-4000 caracteres, mas depende do idioma e do modelo. Para estimar, use o tokenizer do provedor específico, não a contagem de palavras do Word.
O que acontece se o texto for maior que a janela de contexto?
Depende da plataforma: a API pode retornar «context length exceeded», cortar o início do histórico (mensagens mais antigas saem primeiro) ou oferecer compressão. O modelo não «continua lendo» além da janela - informação fora do limite não existe para ele. Soluções: RAG, sumarização, chunking ou modelo com janela maior.
Mais contexto sempre significa respostas melhores?
Não. Janela grande dá a possibilidade de passar mais dados, mas não garante uso igualmente bom de tudo. Em entradas muito longas, a precisão sobre fatos do meio costuma cair, e custo e latência sobem. Melhor passar contexto relevante (busca ou prompt estruturado) do que o corpus inteiro «por precaução».
Como calcular quantos tokens meu documento ocupará?
Use ferramentas oficiais: tiktoken para modelos compatíveis com OpenAI, Anthropic tokenizer, Google AI Studio para Gemini ou count_tokens no SDK do provedor. Regra grosseira: 1 página de texto (≈500 palavras) - da ordem de 650-800 tokens; código e tabelas podem gerar mais tokens por caractere por símbolos especiais.
Preciso de modelo com 1M tokens para um chatbot comum?
Para chatbot típico com respostas curtas e FAQ - não, bastam 32K-128K mais RAG sobre base de conhecimento. Janela 1M+ faz sentido para análise de PDFs grandes, repositórios inteiros, sessões agentic longas ou quando não dá para dividir dados sem perder coerência. Primeiro meça tamanhos reais de requisição em produção - muitas vezes 128K basta com a arquitetura certa.