Cristian Araujo

3.19 - Context window

9 min read

1. ⚡ Resumo Expandido

Nesta aula, o foco foi a Janela de Contexto (Context Window), definida como o limite máximo de tokens (unidades de texto) que um Grande Modelo de Linguagem (LLM) consegue processar e “enxergar” de uma única vez para gerar uma resposta. O professor explicou que, embora a capacidade dos modelos tenha crescido exponencialmente (de 4k tokens no GPT-3.5 para 200k+ no Claude 3), o aumento da janela traz desafios técnicos e econômicos significativos.

O ponto central da aula foi desmistificar a ideia de que “maior é sempre melhor”. O professor destacou que, quanto maior a janela, maior a dificuldade do modelo em manter o foco (Mecanismo de Atenção) e a coerência, levando a fenômenos como a “Diluição de Relevância”. Além disso, o custo e o tempo de processamento crescem de forma não-linear (muitas vezes quadraticamente) em relação ao tamanho da entrada.

Para mitigar esses problemas, foram discutidas estratégias de engenharia, como:

  1. Chunking (Divisão): Fatiar documentos longos (ex: por capítulos).

  2. Resumo Hierárquico: Resumir partes do texto antes de processar o todo.

  3. RAG (Retrieval-Augmented Generation): Buscar apenas os trechos relevantes em vez de enviar todo o documento ao modelo.

Contexto de Mercado Atual (Pesquisa): Atualmente, vivemos a era dos modelos de “Contexto Infinito” (ex: Gemini 1.5 Pro com até 2 milhões de tokens). No entanto, o debate “RAG vs. Long Context” continua acalorado. Enquanto janelas longas permitem uma análise holística (“encontre padrões neste livro”), o RAG continua sendo mais eficiente e barato para consultas pontuais (“encontre esta fatura específica”).

2. 🔍 Deep Dive: Conceitos & Teoria

A. Janela de Contexto e o Mecanismo de Atenção

  • Na Aula: O professor definiu a janela como o grupo de tokens usados para prever o próximo token. Ele alertou que quanto maior a janela, mais difícil é manter a “atenção”, comparando com a dificuldade humana de processar muita informação de uma vez.

  • Deep Dive (Pesquisa): Tecnicamente, a janela de contexto é limitada pela matriz de atenção na arquitetura Transformer (apresentada em “Attention Is All You Need”, Vaswani et al., 2017 ). O cálculo da Self-Attention tem complexidade quadrática em relação ao comprimento da sequência . Isso significa que dobrar a janela de contexto quadruplica o custo computacional.

    • Nota do Pesquisador: Inovações recentes como FlashAttention (Dao et al., 2022) e Ring Attention permitiram janelas de 128k a 1M tokens otimizando operações de IO na GPU, algo que viabilizou os modelos citados na aula (GPT-4 Turbo).

B. O Fenômeno “Lost in the Middle”

  • Na Aula: Foi mencionado que modelos tendem a dar mais foco ao final do contexto (efeito de recência) ou ao início, perdendo informações no meio (“perda de detalhes importantes nas 200k tokens”).

  • Deep Dive (Pesquisa): Este fenômeno foi formalizado no paper “Lost in the Middle: How Language Models Use Long Contexts” (Liu et al., 2023). O estudo demonstra uma curva em forma de “U” na performance: a precisão na recuperação de informações é alta no início e no fim do prompt, mas degrada significativamente quando a informação crucial está no meio da janela de contexto. Isso valida a recomendação do professor de colocar instruções críticas no final ou início.

C. Diluição de Relevância

  • Na Aula: O professor explicou que muito contexto pode gerar respostas genéricas ou alucinações, pois o modelo se “perde” no ruído .

  • Deep Dive (Pesquisa): Em Teoria da Informação, isso se relaciona à Signal-to-Noise Ratio (SNR). Ao injetar 200 páginas de texto para responder uma pergunta simples, reduz-se a densidade de informação relevante, aumentando a probabilidade do modelo atender a tokens irrelevantes (distratores), o que pode levar a alucinações ou recusa em responder.

3. 🛠️ Engenharia: Arquiteturas e Agentes

Padrão: Chunking Intelligence (Estratégia de Fatiamento)

  • Funcionamento: Em vez de enviar um PDF de 200 páginas, divide-se o texto em pedaços lógicos (chunks).

  • Exemplo da Aula: O professor sugeriu dividir um documento por capítulos ou seções lógicas antes de processar .

  • Referência Externa (LangChain): Bibliotecas como LangChain oferecem RecursiveCharacterTextSplitter ou SemanticChunker, que tentam dividir o texto preservando o significado semântico (ex: não quebrar uma frase no meio), algo crucial para manter a coerência citada na aula.

Padrão: Map-Reduce para Resumo

  • Funcionamento: Processar chunks individualmente em paralelo e depois sintetizar os resultados.

  • Exemplo da Aula: O professor mencionou a estratégia de “Chunking Intelligence” e “dividir o trabalho” (fatiar o bolo) para reduzir a carga cognitiva .

  • Referência Externa: Este é o padrão Map-Reduce clássico aplicado a LLMs. O framework LangGraph permite criar um grafo onde múltiplos nós processam seções de texto simultaneamente (Map) e um nó final consolida as respostas (Reduce), evitando o estouro da janela de contexto.

Padrão: RAG (Retrieval-Augmented Generation)

  • Funcionamento: Recuperar apenas a informação necessária de um banco de dados vetorial antes de enviar ao LLM.

  • Exemplo da Aula: Usado para contornar limitações de custo e foco, especialmente em documentos longos .

  • Nota do Pesquisador: A aula menciona o RAG como solução para “conhecimento estático”. O estado da arte hoje é o Agentic RAG (mencionado no livro Agentic Design Patterns ), onde um agente não apenas busca, mas avalia a qualidade do documento recuperado (“Self-Correction”) antes de responder, mitigando a “diluição de relevância”.

4. 📚 Bibliografia Estendida e Referências (Pesquisa)

  • Paper Fundamental: Liu, N. F., et al. (2023). “Lost in the Middle: How Language Models Use Long Contexts”. (Leitura obrigatória para entender por que apenas aumentar a janela não resolve tudo).

  • Artigo de Engenharia: Anthropic Engineering Blog: “Long Context Window Recall”. (Explica o teste “Needle in a Haystack”, usado para medir se o modelo consegue achar uma informação específica em uma janela de 200k tokens).

  • Ferramenta: LlamaIndex (Framework especializado em ingestão de dados e estratégias avançadas de indexação/chunking para lidar com janelas de contexto limitadas).

  • Conceito SOTA: Ring Attention (Paper: Liu et al., 2023). Técnica que permite treinar e inferir em contextos de tamanho quase infinito distribuindo o cálculo da atenção entre múltiplas GPUs (usado pelo Gemini 1.5).

5. ⚠️ Pontos de Atenção e Trade-offs

  • Custo Quadrático vs. Linear: O professor alertou que o custo aumenta drasticamente. Nota: Em APIs (OpenAI/Anthropic), o preço é por token (linear), mas a latência (tempo de espera) e o custo computacional interno do provedor seguem a curva quadrática ou sub-quadrática, resultando em respostas mais lentas.

  • Acurácia vs. Volume: Enviar um livro inteiro para o prompt (Janela Grande) vs. Usar RAG.

    • Trade-off: Janela Grande é melhor para tarefas de “compreensão global” (ex: “Qual o tema central deste livro?”). RAG é melhor para “precisão local” (ex: “Qual o valor da multa na cláusula 3 do contrato?”).

  • Instrução Negligenciada (Instruction Neglect): Em prompts muito longos, o modelo tende a esquecer instruções dadas no início. Dica: Reforce a instrução crítica (o “goal”) no final do prompt (Recency bias), conforme sugerido na aula.

6. 📝 Quiz Prático

  1. Conceito: O que é o fenômeno “Lost in the Middle” em relação à janela de contexto e como ele afeta a confiabilidade de um agente que analisa documentos longos?

  2. Engenharia: Se você precisa analisar um contrato de 500 páginas para encontrar uma cláusula específica de rescisão, qual padrão é mais eficiente em termos de custo e precisão: jogar tudo na janela de contexto de 128k do GPT-4 ou usar uma arquitetura RAG? Justifique.

  3. Trade-off: Explique por que o tempo de processamento de um prompt não dobra, mas sim quadruplica (teoricamente), se você dobrar a quantidade de texto de entrada em uma arquitetura Transformer padrão.

🔥 Pergunta Desafio (SOTA):

O Google Gemini 1.5 Pro introduziu uma janela de contexto de até 2 milhões de tokens com alta taxa de recall (“Needle in a Haystack”). Considerando isso, a técnica de RAG (Retrieval Augmented Generation) tornou-se obsoleta? Argumente considerando latência, custo de API e atualização de conhecimento em tempo real.

📝 Gabarito do Quiz Prático

1. Conceito: “Lost in the Middle”

Resposta: O fenômeno “Lost in the Middle” refere-se à tendência dos Grandes Modelos de Linguagem (LLMs) de priorizarem informações localizadas no início (viés de primazia) e no fim (viés de recência) da janela de contexto . Quando informações críticas são posicionadas no meio de um contexto muito longo, a precisão da recuperação cai drasticamente.

  • Impacto na Confiabilidade: Isso torna agentes que analisam documentos longos menos confiáveis se processarem tudo de uma vez, pois instruções ou dados cruciais “enterrados” no meio do texto podem ser ignorados ou “esquecidos”, levando a alucinações ou respostas incompletas.

2. Engenharia: Contrato de 500 Páginas

Resposta: A arquitetura mais eficiente é o RAG (Retrieval-Augmented Generation).

  • Justificativa de Custo e Precisão: 500 páginas equivalem a aproximadamente 200.000 a 300.000 tokens. Enviar tudo isso em um único prompt (janela de contexto) é extremamente caro (cobrança por token de entrada) e lento. Além disso, devido à “diluição de relevância” citada na aula, o modelo pode se perder no ruído . O RAG é superior aqui porque recupera apenas os chunks (trechos) relevantes à cláusula de rescisão, enviando um contexto curto, focado e barato para o modelo processar .

3. Trade-off: Complexidade Quadrática

Resposta: O tempo quadruplica porque o mecanismo de Autoatenção (Self-Attention) dos Transformers calcula a relação de cada token com todos os outros tokens da sequência.

  • Explicação Técnica: A complexidade computacional é O(n2), onde n é o número de tokens. Se você dobra a entrada (2n), o custo se torna (2n)2=4n2. O professor alertou sobre isso ao mencionar que o custo computacional e o tempo de processamento crescem drasticamente em janelas grandes .

🔥 Resposta do Desafio (SOTA)

Pergunta: O RAG tornou-se obsoleto com o Gemini 1.5 Pro (Contexto de 2M)?

Gabarito: Não, o RAG não se tornou obsoleto. Embora janelas de contexto massivas (Long Context) permitam a ingestão de livros inteiros ou bases de código completas, o RAG continua essencial por três pilares de engenharia:

  1. Latência e Custo (Eficiência): Inserir 2 milhões de tokens em cada chamada de API é financeiramente inviável para a maioria das aplicações em produção e resulta em uma latência alta (segundos ou minutos de espera). O RAG reduz isso para milissegundos ao selecionar apenas o necessário.

  2. Dados em Tempo Real: Conforme visto na aula, modelos pré-treinados ou com contexto estático não sabem informações de “agora” . O RAG conecta o modelo a dados vivos (ex: preço de ações, estoque atual) que mudam sub-segundo a sub-segundo, algo que um prompt estático, por maior que seja, não resolve dinamicamente sem re-ingestão constante.

  3. Curadoria de Contexto: O RAG atua como um filtro de “Context Engineering” , garantindo que o modelo não se distraia com informações irrelevantes, mantendo a “densidade de informação” alta para raciocínios complexos.

Recent Notes

Graph View