Degradação de Contexto em LLMs: O Que os Artigos sobre Contexto Longo Realmente Mostram
Uma nova publicação no r/MachineLearning argumenta que longas sessões com LLMs se deterioram antes de atingir seus limites anunciados, apesar do tamanho reconfortante das janelas de contexto modernas. A publicação relaciona esse problema a longas sessões de análise e programação, nas quais decisões anteriores permanecem visíveis, mas se tornam menos influentes.
Essa afirmação é, em linhas gerais, sustentada por vários estudos, embora os detalhes importem. Os modelos não simplesmente esquecem tudo após um número fixo de tokens. Seu desempenho muda conforme o tamanho do contexto, a posição das evidências, a dificuldade da tarefa, a sobreposição lexical e o material ao redor.
O conflito real, portanto, não é entre contexto curto e contexto longo. É entre capacidade e uso confiável. Um modelo pode aceitar um documento sem utilizar todas as partes dele com a mesma eficácia.
Essa distinção pressiona desenvolvedores, pesquisadores e profissionais do conhecimento que tratam o histórico de conversas como memória de trabalho durável. Ela também desafia interfaces de produto que apresentam um único chat contínuo como uma única cadeia contínua de raciocínio.
A Publicação no Reddit Transformou uma Falha Silenciosa em uma Questão de Fluxo de Trabalho
O evento imediato é uma discussão de pesquisa que se torna um alerta prático sobre como as pessoas conduzem longas sessões de IA.
Em 2 de agosto de 2026, um usuário enviou uma publicação sobre degradação de contexto ao r/MachineLearning. Sua descrição vinculada afirma que longas sessões podem se deteriorar muito antes de um limite de tokens ser atingido.
A publicação não estabelece um novo benchmark. Ela apresenta um problema de pesquisa já existente a partir de uma experiência familiar: um assistente começa com precisão, mas gradualmente perde restrições, prioridades ou o raciocínio anterior.
Essa experiência pode surgir de muitas formas. Um assistente de programação pode reintroduzir uma arquitetura rejeitada. Um assistente de pesquisa pode citar uma premissa desatualizada depois de o usuário corrigi-la. Uma ferramenta de análise pode preservar fatos individuais, mas perder a lógica que os conecta.
Essas falhas são difíceis de diagnosticar porque o chat continua parecendo intacto. As mensagens anteriores permanecem na tela, e o assistente frequentemente consegue citá-las quando solicitado. Ainda assim, uma recuperação precisa não garante um raciocínio correto.
Uma janela de contexto é a sequência máxima de tokens que um modelo pode aceitar em uma única solicitação. Não é uma promessa de que cada token aceito receba o mesmo peso prático.
Essa diferença se parece com capacidade de armazenamento versus atenção de trabalho. Uma mesa cheia pode comportar todos os documentos relevantes, mas um documento sob uma grande pilha continua mais difícil de usar. A analogia é imperfeita, já que transformers não pensam como pessoas, mas ela captura o risco operacional.
A publicação também chega depois que as janelas de contexto se tornaram uma métrica de produto visível. Janelas maiores comportam repositórios, livros, históricos de reuniões e coleções de artigos de pesquisa. Essa capacidade é útil, mas pode incentivar usuários a manter uma única sessão ativa indefinidamente.
Uma sessão longa então acumula diversos tipos de atrito. Ela contém abordagens abandonadas, instruções repetidas, resultados intermediários, correções e fatos desatualizados. Cada item permanece potencialmente disponível, mas sua presença contínua não o torna igualmente útil.
A degradação resultante raramente é um colapso evidente. As respostas podem continuar fluentes enquanto se tornam menos fiéis às decisões que orientam o projeto. Isso torna a falha de contexto mais perigosa do que uma mensagem explícita de erro.
O histórico de pesquisa sustenta o alerta amplo. No entanto, ele não sustenta uma alegação universal de que um número específico de turnos marca o ponto de falha. Nenhum artigo estabelece que a vigésima mensagem, por exemplo, se torne efetivamente inacessível em todos os modelos e tarefas.
O que mudou foi o enquadramento. A fragilidade do contexto longo está migrando da discussão sobre benchmarks para o desenho cotidiano de fluxos de trabalho. A questão não é mais se um modelo aceita a transcrição. É se a transcrição continua sendo um ambiente confiável para o raciocínio.
Os Artigos Mostram Várias Falhas, Não um Único Penhasco de Contexto
A degradação de contexto é uma coleção de fragilidades mensuráveis, não um único limiar no qual um LLM perde subitamente sua memória.
O resultado posicional mais citado vem do artigo de 2024 Lost in the Middle. Seus autores testaram perguntas e respostas com múltiplos documentos e recuperação de chave-valor em diferentes posições das evidências.
O desempenho frequentemente foi mais forte quando as informações relevantes apareciam perto do início ou do fim. Ele caiu quando as mesmas informações apareciam no meio, inclusive em modelos projetados para contexto longo.
Esse padrão é comumente descrito como uma curva de desempenho em U. A curva mostra sensibilidade posicional, mas não significa que todos os modelos sempre ignorem o meio. Os resultados variam conforme o modelo, o tamanho da entrada, a tarefa e a construção do prompt.
A posição é apenas uma parte do problema. RULER ampliou a recuperação simples de agulha no palheiro com múltiplas agulhas, rastreamento de múltiplos saltos e tarefas de agregação.
Seus pesquisadores avaliaram 17 modelos de contexto longo em 13 tarefas. Embora todos os modelos avaliados declarassem pelo menos um contexto de 32.000 tokens, apenas metade manteve desempenho satisfatório nesse tamanho.
O benchmark RULER expôs, portanto, uma diferença entre encontrar uma string literal e utilizar informações distribuídas. Um modelo pode passar em um teste fácil de recuperação, mas ter dificuldades com agregação ou raciocínio encadeado.
NoLiMa levou essa distinção adiante. Ele reduziu a sobreposição lexical entre a pergunta e as evidências relevantes, forçando os modelos a inferir uma associação em vez de corresponder palavras semelhantes.
Os pesquisadores avaliaram 13 modelos que declaravam suporte para pelo menos 128.000 tokens. Em 32.000 tokens, 11 modelos ficaram abaixo da metade de sua forte linha de base para contexto curto.
GPT-4o permaneceu um dos sistemas mais fortes nesse teste. Ainda assim, seu resultado relatado caiu de uma linha de base de 99,3 por cento em contexto curto para 69,7 por cento em 32.000 tokens.
Esses resultados do NoLiMa importam porque análises comuns raramente oferecem alinhamento perfeito de palavras-chave. Uma decisão de projeto e uma pergunta posterior podem expressar o mesmo conceito com vocabulários diferentes.
As conversas também introduzem complicações temporais. Um usuário pode declarar uma preferência, revisá-la mais tarde e então fazer uma pergunta que exige que o sistema identifique a versão atual.
LongMemEval foi projetado em torno desse problema de memória mais amplo. Ele inclui 500 perguntas que testam extração, raciocínio entre múltiplas sessões, raciocínio temporal, conhecimento atualizado e abstenção apropriada.
Seus autores relataram que assistentes comerciais de chat e modelos de contexto longo tiveram uma queda geral de 30 por cento na precisão em interações prolongadas. O resultado diz respeito a um benchmark específico, não a todas as conversas reais.
Em conjunto, esses estudos distinguem ao menos quatro problemas. Os modelos podem ter dificuldades para localizar evidências, conectar evidências indiretamente relacionadas, priorizar a versão atual ou raciocinar corretamente após recuperar o material certo.
Essa última falha é especialmente importante. Ela significa que uma busca melhor, por si só, não resolve o problema do contexto longo.
Por Que a Recuperação Perfeita Ainda Não Protege Análises Longas
Um modelo pode recuperar a evidência correta e ainda assim raciocinar pior porque a entrada total ficou mais longa.
Um preprint de outubro de 2025 isolou essa possibilidade em cinco modelos abertos e fechados. Os pesquisadores testaram matemática, perguntas e respostas, programação e uma tarefa sintética de soma de variáveis.
Eles construíram entradas mais longas mantendo controladas as evidências e a pergunta. As perdas de desempenho relatadas variaram de 13,9 por cento a 85 por cento, apesar da recuperação perfeita de evidências relevantes.
Os autores também substituíram prosa irrelevante por espaços em branco minimamente distrativos. Alguns modelos ainda se degradaram. Em seguida, mascararam tokens irrelevantes em experimentos com modelos abertos, e a degradação permaneceu.
Seu estudo sobre recuperação perfeita é um preprint, e não um consenso científico consolidado. Seus experimentos são sintéticos, e sua amostra de modelos não representa todos os sistemas atuais.
Ainda assim, o resultado desafia uma explicação conveniente. As falhas de contexto nem sempre podem ser atribuídas ao modelo selecionar a passagem errada em meio a material ruidoso.
Os pesquisadores também posicionaram as evidências imediatamente antes da pergunta. Entradas mais longas ainda prejudicaram o desempenho em várias configurações. Essa descoberta enfraquece a alegação de que simplesmente repetir a instrução mais recente sempre repara uma conversa congestionada.
Um preprint posterior de 2026 examinou falhas posicionais sob conteúdo de preenchimento estruturado. Ele testou se a localização de um problema-alvo altera a precisão enquanto o contexto ao redor permanece controlado.
O estudo relatou grandes quedas do fim para o meio em modelos vulneráveis. Em seu conjunto inicial de cinco modelos, 76 por cento dos erros na posição intermediária correspondiam às respostas do conteúdo de preenchimento ao redor, em comparação com 22 por cento no fim.
Os pesquisadores interpretaram esse resultado como evidência de interferência do preenchimento. Lançamentos mais recentes geralmente mostraram quedas menores, o que também sugere que fornecedores estão melhorando alguns comportamentos de contexto longo.
Esses estudos não devem ser combinados em uma única taxa universal de falha. Eles usam modelos, conjuntos de dados, métodos de pontuação, tamanhos de contexto e definições de degradação diferentes.
Eles sustentam uma conclusão comum. O tamanho máximo de contexto e o tamanho efetivo de contexto são medidas diferentes.
O tamanho máximo de contexto descreve a aceitação de entrada. O tamanho efetivo de contexto descreve quanto material um modelo consegue usar de forma confiável para uma tarefa específica.
Esse tamanho efetivo pode diminuir à medida que a tarefa se torna menos literal. Ele também pode diminuir quando o modelo precisa combinar evidências, distinguir revisões, preservar restrições ou resistir a distrações plausíveis.
Isso explica por que análises longas podem parecer instáveis mesmo quando a simples recordação continua impressionante. Perguntar “O que eu disse sobre o banco de dados?” testa recuperação. Perguntar “O design atual ainda atende a todas as restrições do banco de dados?” testa recuperação, priorização e raciocínio.
Chats longos também contêm material gerado pelo modelo. Cada rascunho, interpretação e alegação especulativa se torna um possível contexto futuro. Um erro inicial do modelo pode, portanto, competir com a correção posterior do usuário.
O problema não é que o sistema possua uma memória humana que se desvanece. O modelo recebe uma entrada construída e produz uma saída a partir dessa entrada. A falha está em quão confiavelmente ele utiliza a sequência crescente.
Esse mecanismo transforma a gestão de contexto em uma preocupação de engenharia. Ele também explica por que uma linguagem refinada não pode servir como evidência de que o raciocínio subjacente permaneceu alinhado.
O Verdadeiro Oponente É a Continuidade Sem Controle
A principal troca é entre uma continuidade conversacional conveniente e um conjunto menor e governado de fatos autorizados.
Uma sessão contínua parece eficiente. O usuário evita reapresentar o projeto, enquanto o assistente parece preservar cada decisão e descoberta.
A continuidade também reduz custos visíveis de preparação. Iniciar um novo chat parece descartar trabalho, especialmente após horas de pesquisa ou depuração.
No entanto, a transcrição ininterrupta se torna um banco de dados não gerenciado. Hipóteses antigas permanecem ao lado de fatos confirmados. Planos rejeitados permanecem ao lado de decisões aprovadas. Formulações temporárias permanecem ao lado de requisitos vinculantes.
O assistente recebe esses materiais sem os mecanismos de governança encontrados em sistemas de informação maduros. Um chat não distingue automaticamente entre a política atual, notas obsoletas, evidências brutas e resultados especulativos.
A recência pode ajudar porque informações posteriores aparecem perto do fim. Ainda assim, uma correção tardia não apaga afirmações anteriores. Ambas as versões podem permanecer disponíveis, a menos que a aplicação as resuma, recupere ou filtre ativamente.
Isso cria pressão sobre as equipes de produtos de IA. Um grande número de contexto é fácil de promover, enquanto o uso confiável do contexto exige avaliação específica para cada tarefa e um projeto cuidadoso do sistema.
Também pressiona as equipes que desenvolvem agentes. Os agentes frequentemente acumulam resultados de ferramentas, planos, erros, observações e código gerado ao longo de muitas etapas. Cada novo item amplia o material que ações posteriores precisam interpretar.
Os desenvolvedores podem recorrer à geração aumentada por recuperação, ou RAG. O RAG pesquisa uma coleção externa e fornece passagens selecionadas ao modelo para uma determinada solicitação.
A recuperação reduz a quantidade de material inserida no prompt ativo. Ela também pode preservar a proveniência das fontes e tornar as atualizações mais fáceis do que reescrever uma transcrição gigantesca.
Ainda assim, o RAG não resolve automaticamente o problema. A recuperação pode selecionar passagens semanticamente semelhantes, mas incompletas. Limites inadequados entre trechos podem separar uma exceção da regra que ela modifica.
A pesquisa sobre recuperação perfeita levanta uma segunda preocupação. Mesmo quando a evidência correta está presente, um prompt desnecessariamente longo ainda pode enfraquecer o desempenho na tarefa.
Um projeto melhor trata o contexto como um conjunto de trabalho compilado. O sistema deve reunir instruções atuais, evidências verificadas, questões não resolvidas e o mínimo de histórico relevante para cada tarefa.
Essa ideia também muda o fluxo de trabalho pessoal. Em vez de pedir que um chat se torne o único registro, os usuários podem manter um pequeno conjunto de artefatos externos.
Um registro de decisões documenta o que foi escolhido, por que foi escolhido e quais alternativas foram rejeitadas. Um arquivo de evidências separa o material de origem da interpretação do modelo. Um briefing da tarefa registra o objetivo e as restrições atuais.
É aí que uma base de conhecimento pessoal estruturada pode ajudar. O recurso útil não é o armazenamento ilimitado. É a capacidade de recuperar um conjunto menor e atual de materiais.
O objetivo não é eliminar a continuidade. É deixar de tratar continuidade como controle.
Uma transcrição longa continua valiosa como arquivo. Ela se torna arriscada quando o arquivo também serve como a única especificação, sistema de memória e espaço de raciocínio.
Os Hábitos que Resistiram ao Contato com as Evidências
O fluxo de trabalho mais seguro converte periodicamente a conversa em um estado compacto e inspecionável antes de pedir ao modelo que continue raciocinando.
O primeiro hábito é separar o estado durável do histórico conversacional. O estado durável inclui decisões aprovadas, definições, restrições, evidências e questões não resolvidas.
Mantenha esse estado em um documento curto fora do chat. Peça ao modelo que proponha atualizações, mas revise essas atualizações antes de aceitá-las.
Essa etapa impede que uma resposta especulativa do assistente se torne silenciosamente a verdade do projeto. Ela também dá à próxima sessão um ponto de partida mais limpo.
O segundo hábito é usar pontos de controle após decisões relevantes. Um ponto de controle deve registrar o objetivo atual, as conclusões aceitas, as opções rejeitadas e o próximo teste.
Não solicite um resumo genérico. Resumos genéricos favorecem fluência e cobertura, enquanto um ponto de controle precisa de categorias explícitas e compromissos rastreáveis.
Um ponto de controle útil pode conter cinco campos:
Objetivo atual e definição de sucesso
Restrições vinculantes e suas fontes
Decisões tomadas e alternativas rejeitadas
Incertezas em aberto que exigem evidências
Próxima ação e seu resultado esperado
O terceiro hábito é iniciar novas sessões em torno dos limites das tarefas. Coleta de pesquisa, avaliação de evidências, elaboração de estrutura e redação final impõem exigências diferentes ao contexto.
Uma sessão de pesquisa se beneficia de detalhes das fontes. Uma sessão de redação se beneficia de afirmações verificadas e de uma estrutura consolidada. Levar cada troca de pesquisa para a elaboração do texto adiciona material sem valor equivalente.
Iniciar uma nova sessão não significa descartar o trabalho. Significa passar uma transição cuidadosamente selecionada, em vez de todo o chão da oficina.
O quarto hábito é repetir restrições críticas perto da tarefa, mantendo uma única versão autoritativa. Isso é útil ao gerar código, avaliar evidências ou escrever dentro de requisitos rigorosos.
A repetição deve referenciar a fonte da verdade. Caso contrário, instruções copiadas podem divergir entre várias versões e criar um problema de contexto diferente.
O quinto hábito é pedir ao modelo que exponha seu estado de trabalho. Antes de uma saída relevante, solicite as suposições, evidências, restrições e conflitos não resolvidos que ele identifica no momento.
Isso não garante fidelidade interna. A explicação de um modelo não revela todas as causas computacionais de sua resposta. No entanto, fornece uma verificação prática de alinhamento.
Se o modelo omitir uma restrição vinculante, pare e corrija o contexto de trabalho. Não continue apenas porque a resposta anterior pareceu competente.
O sexto hábito é separar recuperação de julgamento. Primeiro, peça a evidência exata e relevante; depois, peça uma análise baseada apenas nesse conjunto extraído.
O artigo sobre recuperação perfeita de 2025 testou uma estratégia relacionada de recuperar e depois raciocinar. Ele relatou melhorias de até quatro pontos percentuais para GPT-4o no RULER.
Esse resultado se limita à configuração avaliada. Ainda assim, apoia um padrão prático: encurtar a entrada de raciocínio depois de identificar a evidência relevante.
O sétimo hábito é preservar a proveniência. Cada afirmação importante deve apontar para uma fonte, experimento, arquivo ou decisão do usuário.
A proveniência torna os erros mais fáceis de corrigir porque o usuário pode distinguir entre evidência primária e a interpretação do assistente. Ela também ajuda a resolver contradições após várias sessões.
O oitavo hábito é tratar resumos do modelo como perdas. Resumos comprimem, priorizam e reinterpretam. Eles nunca devem substituir silenciosamente a evidência original.
Mantenha os documentos-fonte disponíveis e audite afirmações de alto impacto em relação a eles. Um resumo é uma camada de navegação, não um registro inquestionável.
O nono hábito é observar sintomas comportamentais em vez de esperar por um aviso de tokens. Os sinais de alerta incluem perguntas repetidas, retomada de ideias rejeitadas e definições inconsistentes.
Outros sintomas incluem ignorar formatos de saída solicitados, confundir evidências com hipóteses ou responder a uma versão anterior da tarefa.
Quando esses sintomas surgem, mais prompts na mesma sessão podem piorar a situação. A resposta mais segura costuma ser criar um ponto de controle, verificar e reiniciar com um contexto menor.
Essas práticas não produzem um comprimento de sessão universalmente seguro. A pesquisa não justifica um. Elas criam pontos de recuperação antes que a degradação se torne cara.
O Que as Evidências Ainda Não Comprovam
Os benchmarks de contexto longo justificam cautela, mas não comprovam que toda conversa extensa inevitavelmente se torna inutilizável.
Os estudos diferem significativamente. Lost in the Middle se concentra na posição das evidências. RULER varia a complexidade de recuperação, enquanto NoLiMa reduz a sobreposição lexical.
LongMemEval examina a memória conversacional sustentada. O preprint de recuperação perfeita tenta isolar o próprio comprimento da entrada. Esses experimentos se sobrepõem, mas não medem um fenômeno idêntico.
Benchmarks sintéticos também simplificam o trabalho real. Eles oferecem controle, o que ajuda a identificar causas, mas sessões reais contêm ferramentas, prompts de sistema, memória da aplicação e objetivos do usuário em mudança.
Aplicações comerciais podem pré-processar chats de formas não divulgadas. Elas podem resumir interações anteriores, recuperar memórias selecionadas, remover conteúdo ou aplicar instruções ocultas.
Portanto, dois produtos que usam o mesmo modelo subjacente podem se comportar de maneira diferente. Até mesmo um produto pode mudar após uma atualização do modelo ou uma revisão da gestão de contexto.
As famílias de modelos também diferem. Alguns estudos mostram fraqueza posicional substancial em um sistema e quedas menores em outro. Lançamentos mais recentes às vezes reduzem padrões anteriores de falha.
O estudo posicional de 2026, por exemplo, relatou diferenças menores entre as extremidades e o meio em vários modelos mais novos. Isso sugere que o uso de contexto está melhorando, embora as falhas restantes ainda importem.
Pesquisadores também debatem o que constitui uma tarefa significativa de contexto longo. A recuperação literal de uma agulha pode ser fácil demais, mas testes de raciocínio altamente construídos podem não se parecer com o trabalho rotineiro.
Uma avaliação útil deve corresponder à implantação. Um sistema de revisão jurídica precisa de exceções, revisões e relações entre documentos. Um agente de código precisa de dependências, arquivos atuais e restrições arquiteturais aceitas.
Nenhum dos sistemas deve ser avaliado apenas por localizar uma frase inserida. Da mesma forma, um benchmark difícil não deve apagar um desempenho útil em tarefas mais restritas.
A expressão “context rot” também pode induzir ao erro. Ela sugere que as informações se deterioram fisicamente dentro de uma conversa em andamento. Em muitos sistemas, a entrada real pode ser reconstruída para cada resposta.
O problema observável é a degradação do desempenho na tarefa à medida que o contexto utilizável se torna mais longo ou menos bem organizado. A causa interna pode envolver atenção, posição, interferência, pré-processamento, recuperação ou complexidade da tarefa.
O grande relatório comparativo da Chroma afirma explicitamente que não identifica um mecanismo definitivo. Seus pesquisadores observaram que o desempenho variava com o comprimento e a estrutura do contexto em tarefas controladas.
O relatório sobre context rot defende uma construção cuidadosa do contexto. Ele também reconhece a necessidade de separar a dificuldade intrínseca da tarefa das limitações no tratamento de extensão.
Essa cautela deve moldar as afirmações dos usuários. Uma resposta ruim no fim de um chat não comprova, por si só, a degradação do contexto.
A tarefa pode ter se tornado mais difícil. As instruções podem entrar em conflito. Uma ferramenta pode ter retornado informações ruins. O modelo pode ter sido atualizado, ou a aplicação pode ter comprimido o histórico.
A resposta prática permanece semelhante: inspecione o estado disponível, reduza a ambiguidade e reproduza a falha sob condições controladas.
Para trabalhos de alto risco, execute a mesma tarefa com um prompt limpo e compacto. Compare-o com o resultado da sessão longa. Esse teste fornece mais evidências do que a intuição por si só.
O Que Observar a Seguir nos LLMs de Contexto Longo
Os próximos avanços úteis conectarão a capacidade anunciada à confiabilidade específica de cada tarefa, a controles de memória visíveis e a testes de fluxo de trabalho repetíveis.
O primeiro sinal é uma melhor avaliação posicional nos lançamentos de modelos. Os fornecedores devem informar como o desempenho muda quando evidências idênticas passam do início para o meio e o fim.
Essas avaliações devem incluir raciocínio, agregação e tratamento de revisões. Um modelo que recupera uma frase literal no comprimento máximo não demonstrou memória de projeto confiável.
Se resultados controlados por posição se tornarem padrão, a lacuna entre capacidade e uso será mais fácil de comparar. Se continuarem ausentes, os compradores terão de seguir criando seus próprios testes.
O segundo sinal é o progresso em sistemas de recuperar e depois raciocinar. Esses sistemas identificam evidências relevantes, constroem um contexto de trabalho mais curto e então realizam a análise solicitada.
A medição crítica não é apenas a revocação da recuperação. Os desenvolvedores devem avaliar se a resposta final respeita restrições, combina as evidências corretamente e rejeita informações obsoletas.
Sistemas bem-sucedidos também preservarão a proveniência. Os usuários devem poder inspecionar quais fontes e decisões entraram no contexto de trabalho de uma resposta relevante.
O terceiro sinal é o controle do usuário sobre a memória e o estado da sessão. As interfaces dos produtos precisam de distinções mais claras entre histórico de chat, memória salva, documentos recuperados e instruções ativas.
Os usuários devem poder marcar um item como autoritativo, substituído, incerto ou excluído. Sem esses controles, uma memória mais longa pode preservar mais contradições junto com mais fatos úteis.
Para as equipes, a lição de curto prazo é simples. Não escolha um sistema de IA com base apenas no tamanho do contexto. Teste as tarefas que importam com posicionamento realista das evidências e ruído realista.
Para indivíduos, a resposta certa não é abandonar sessões longas. É mudar o que uma sessão pode assumir como responsabilidade.
Deixe a transcrição registrar a exploração. Mantenha evidências verificadas, decisões atuais e restrições vinculantes em artefatos externos menores. Atualize o conjunto de trabalho do modelo sempre que a tarefa mudar.
Antes de sua próxima análise prolongada, crie um resumo compacto do projeto e um registro de decisões. Em seguida, compare uma resposta de uma sessão nova com a resposta da sua conversa mais longa.
Se a versão nova seguir as restrições com mais precisão, o contexto não estava funcionando como memória confiável. Estava funcionando como um arquivo cada vez mais ruidoso.
