ByteDance explica falha de recuperação em contexto longo nos modelos DeepSeek

Uma equipe do time Seed da ByteDance identificou a causa técnica por trás de resultados inconsistentes na recuperação de informações em contextos longos nos modelos DeepSeek. A diferença de acurácia pode chegar a 40 pontos percentuais dependendo de onde o dado cai dentro da janela de compressão do cache.

O que a pesquisa encontrou

Pesquisadores do time Seed, braço de pesquisa em IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → da ByteDance, identificaram um mecanismo técnico por trás de um problema conhecido em modelos DeepSeek: a recuperação de informação em contextos longos é inconsistente, mesmo quando o modelo vai bem em benchmarks agregados. Segundo o estudo, reportado pelo TechNode, a causa está na compressão de cache key-value (KV-cache) em blocos (chunks), técnica usada para reduzir custo de memória e de atenção em janelas de contexto grandes.

O achado central: a mesma informação pode ser fácil de recuperar em uma posição do texto e difícil em outra, dependendo de onde ela cai dentro da janela de compressão. Os pesquisadores batizaram o padrão de "sensibilidade de fase" (phase sensitivity) e mediram diferenças de até 40 pontos percentuais na acurácia de recuperação entre posições diferentes.

Como a compressão de cache gera o problema

KV-cache é a memória que um modelo de linguagem mantém durante a geração de texto para não recalcular a atenção sobre tokens já processados. Em contextos longos, esse cache cresce rápido e vira o principal gargalo de memória e latência em produção. Para lidar com isso, famílias de modelos como o DeepSeek comprimem grupos de tokens consecutivos em um número menor de entradas de cache, trocando granularidade por economia de memória.

O problema é que essa compressão não é neutra em relação à posição. Diferentes componentes de atenção (heads) acabam se especializando em recuperar informação de posições específicas dentro do bloco comprimido. Quando um dado relevante cai numa posição que nenhum head cobre bem, a recuperação falha, mesmo que a mesma informação, um pouco deslocada, fosse recuperada sem problema.

Em resumo: não é um bug pontual de um checkpoint do DeepSeek, mas um padrão ligado a como a compressão em blocos interage com a especialização dos heads de atenção. Os pesquisadores reproduziram o comportamento em modelos treinados do zero para testar a hipótese, o que reforça que a causa está no desenho da técnica de compressão, não em um efeito isolado de treinamento de um modelo específico.

Por que isso some nos benchmarks

Boa parte dos testes de "agulha no palheiro" (needle-in-a-haystack) mede recuperação em várias posições do texto e depois reporta uma média. Um modelo pode ter média respeitável e, ainda assim, ter zonas cegas sistemáticas: posições em que a recuperação é consistentemente ruim. A pesquisa da ByteDance mostra esse mecanismo na prática, com variação de até 40 pontos percentuais entre posições dentro da janela de compressão.

Isso muda a forma de ler relatórios de benchmark de contexto longo. Um score agregado de recuperação não garante o mesmo desempenho em qualquer documento real: se a estrutura do seu caso de uso tende a colocar informação crítica sempre na mesma posição relativa dentro de um bloco de contexto, o resultado prático pode ficar bem longe da média anunciada pelo fornecedor do modelo.

O que muda para quem usa DeepSeek em produção

DeepSeek é uma das famílias de modelos open-weight usada em cenários de RAG, análise de documentos longos e agentes que mantêm histórico extenso de conversa, situações em que o contexto longo é parte central do caso de uso. Na prática, muitas dessas implantações passam por motores de inferência que aplicam técnicas próprias de paginação e compressão de cache para controlar memória em produção.

Para quem está nesse cenário, a pesquisa traz três pontos práticos:

• Testar com a estrutura real dos próprios documentos, não só com benchmarks públicos, já que a posição da informação relevante no seu caso de uso pode coincidir com uma zona de recuperação fraca do modelo.
• Avaliar se o motor de inferência usado permite ajustar a agressividade da compressão de KV-cache em tarefas em que a confiabilidade da recuperação importa mais do que a economia de memória.
• Desconfiar de comparações de modelos baseadas só em médias de benchmark de contexto longo, e buscar relatórios que detalhem variação por posição, não apenas o número agregado.

Nenhuma dessas medidas resolve o problema na raiz: são formas de reduzir o risco até que apareça uma solução estrutural, algo que o estudo da ByteDance ainda não anuncia.

O que ainda está em aberto

O material divulgado até agora identifica a causa do problema, mas não traz uma correção publicada para os modelos DeepSeek já em produção. Também não fica claro, pelo que o TechNode reportou, se o mecanismo de sensibilidade de fase afeta igualmente todas as variantes da família DeepSeek ou se está concentrado em configurações específicas de compressão.

Fica em aberto também se outras famílias de modelos que usam compressão de KV-cache em blocos, prática cada vez mais comum para baratear contexto longo, sofrem do mesmo padrão. Se a causa é estrutural à técnica de compressão, como sugere a reprodução em modelos treinados do zero, é razoável esperar que o problema não seja exclusividade do DeepSeek.

Fonte: TechNode (China)