Por que os Modelos de Linguagem Perdem-se em Conversas

Um novo artigo de pesquisa da Microsoft Research e Salesforce (CRM ) descobriu que mesmo os modelos de linguagem mais capazes (LLMs) perdem o rumo quando as instruções são dadas em etapas, em vez de todas de uma vez. Os autores encontraram que o desempenho cai em média 39% em seis tarefas quando um prompt é dividido em várias partes:

Uma conversa de uma única volta (à esquerda) obtém os melhores resultados, mas é antinatural para o usuário final. Uma conversa de múltiplas voltas (à direita) encontra mesmo os modelos LLM mais performáticos perdendo o impulso eficaz em uma conversa. Fonte: https://arxiv.org/pdf/2505.06120

Mais notavelmente, a confiabilidade das respostas sofre um declínio acentuado, com modelos prestigiados como ChatGPT-4.1 e Gemini 2.5 Pro oscilando entre respostas quase perfeitas e falhas manifestas, dependendo de como a mesma tarefa é formulada; além disso, a consistência da saída pode cair mais da metade no processo.

Para explorar esse comportamento, o artigo apresenta um método chamado sharding*, que divide prompts completamente especificados em fragmentos menores e os libera um a um em uma conversa.

Em termos básicos, isso é equivalente a dar um pedido coeso e abrangente em um restaurante, deixando o garçom com nada a fazer além de confirmar o pedido; ou decidir abordar a questão de forma colaborativa:

Duas versões extremas de uma conversa em um restaurante (não do novo artigo, apenas para ilustração).

Para enfatizar, o exemplo acima coloca o cliente em uma luz negativa. Mas a ideia central representada na segunda coluna é a de uma troca transacional que esclarece um conjunto de problemas antes de abordá-los – aparentemente uma maneira racional e razoável de abordar uma tarefa.

Essa configuração é refletida na nova abordagem de sharding para interação com LLM. Os autores observam que os LLMs frequentemente geram respostas excessivamente longas e continuam a confiar em suas próprias percepções mesmo após essas percepções terem sido comprovadas como incorretas ou irrelevantes. Essa tendência, combinada com outros fatores, pode causar o sistema a perder o controle da troca inteira.

De fato, os pesquisadores observam o que muitos de nós encontramos de forma anedótica – que a melhor maneira de colocar a conversa de volta nos trilhos é iniciar uma nova conversa com o LLM.

‘Se uma conversa com um LLM não levou a resultados esperados, iniciar uma nova conversa que repita as mesmas informações pode produzir resultados significativamente melhores do que continuar uma conversa em andamento.

‘Isso ocorre porque os LLMs atuais podem se perder na conversa, e nossos experimentos mostram que persistir em uma conversa com o modelo é ineficaz. Além disso, como os LLMs geram texto com aleatoriedade, uma nova conversa pode levar a resultados melhorados.’

Os autores reconhecem que sistemas agênticos, como Autogen ou LangChain, podem potencialmente melhorar os resultados, agindo como camadas interpretativas entre o usuário final e o LLM, comunicando-se com o LLM apenas quando tiverem coletado respostas sharded suficientes para se coagular em uma única consulta coesa (que o usuário final não será exposto).

No entanto, os autores argumentam que uma camada de abstração separada não deve ser necessária, ou seja, deve ser construída diretamente no LLM de origem:

‘Um argumento pode ser feito de que as capacidades de múltiplas voltas não são uma característica necessária dos LLMs, pois podem ser repassadas para o quadro do agente. Em outras palavras, precisamos de suporte nativo para interação de múltiplas voltas nos LLMs quando um quadro de agente pode orquestrar interações com usuários e aproveitar os LLMs apenas como operadores de uma única volta?…’

Mas, após testar a proposição em sua variedade de exemplos, eles concluem:

‘[Depender] de um quadro de agente para processar informações pode ser limitante, e argumentamos que os LLMs devem suportar nativamente a interação de múltiplas voltas’

Esse interessante novo artigo é intitulado LLMs Perdem-se em Conversas de Múltiplas Voltas, e vem de quatro pesquisadores da Microsoft Research e Salesforce,

Conversas Fragmentadas

O novo método primeiro divide as instruções convencionais de uma única volta em fragmentos menores, projetados para serem introduzidos em momentos-chave durante uma interação com um LLM, uma estrutura que reflete o estilo exploratório e de ida e volta de sistemas como ChatGPT ou Google Gemini.

Cada instrução original é um único prompt autocontido que entrega a tarefa inteira de uma vez, combinando uma pergunta de alto nível, contexto de apoio e quaisquer condições relevantes. A versão sharded divide isso em várias partes menores, com cada fragmento adicionando apenas uma peça de informação:

Instruções em pares mostrando (a) um prompt completo entregue em uma única volta e (b) sua versão sharded usada para simular uma interação de múltiplas voltas subespecificada. Semanticamente, cada versão entrega a mesma carga de informação.

O primeiro fragmento sempre introduz o objetivo principal da tarefa, enquanto o resto fornece detalhes esclarecedores. Juntos, eles entregam o mesmo conteúdo que o prompt original, mas distribuído naturalmente ao longo de várias voltas na conversa.

Cada conversa simulada se desenrola entre três componentes: o assistente, o modelo sob avaliação; o usuário, um agente simulado com acesso ao prompt completo em forma sharded; e o sistema, que supervisiona e pontua a troca.

A conversa começa com o usuário revelando o primeiro fragmento e o assistente respondendo livremente. O sistema então classifica essa resposta em uma das várias categorias, como um pedido de esclarecimento ou uma tentativa de resposta completa.

Se o modelo faz uma tentativa de resposta, um componente separado extrai apenas o span relevante para avaliação, ignorando qualquer texto circundante. Em cada nova volta, o usuário revela um fragmento adicional, provocando outra resposta. A troca continua até que o modelo obtenha a resposta certa ou não haja mais fragmentos para revelar:

Diagrama de uma simulação de conversa sharded, com o modelo avaliado destacado em vermelho.

Testes iniciais mostraram que os modelos frequentemente perguntavam sobre informações que ainda não haviam sido compartilhadas, então os autores abandonaram a ideia de revelar fragmentos em uma ordem fixa. Em vez disso, um simulador foi usado para decidir qual fragmento revelar em seguida, com base em como a conversa estava se desenrolando.

O simulador de usuário, implementado usando GPT-4o-mini, foi dado acesso completo à instrução completa e à história da conversa, encarregado de decidir, a cada volta, qual fragmento revelar em seguida, com base em como a troca estava se desenrolando.

O simulador de usuário também reformulou cada fragmento para manter o fluxo conversacional, sem alterar o significado. Isso permitiu que a simulação refletisse o ‘dar e receber’ do diálogo real, enquanto preservava o controle sobre a estrutura da tarefa.

Antes de a conversa começar, o assistente é dado apenas as informações básicas necessárias para completar a tarefa, como um esquema de banco de dados ou uma referência de API. Ele não é informado de que as instruções serão quebradas, e não é orientado sobre como lidar com a conversa. Isso é feito propositadamente: em uso real, os modelos raramente são informados de que um prompt será incompleto ou atualizado ao longo do tempo, e deixar de fora esse contexto ajuda a simulação a refletir como o modelo se comporta em um contexto mais realista.

GPT-4o-mini também foi usado para decidir como as respostas do modelo deveriam ser classificadas e para extrair quaisquer respostas finais dessas respostas. Isso ajudou a simulação a permanecer flexível, mas introduziu ocasionalmente erros: no entanto, após verificar várias centenas de conversas manualmente, os autores encontraram que menos de cinco por cento tinham problemas, e menos de dois por cento mostraram uma mudança no resultado devido a eles, e consideraram essa uma taxa de erro baixa o suficiente dentro dos parâmetros do projeto.

Cenários de Simulação

Os autores usaram cinco tipos de simulação para testar o comportamento do modelo sob diferentes condições, cada um uma variação de como e quando partes da instrução são reveladas.

No cenário Completo, o modelo recebe a instrução completa em uma única volta. Isso representa o formato de benchmark padrão e serve como a linha de base de desempenho.

O cenário Sharded divide a instrução em várias partes e as entrega uma a uma, simulando uma conversa mais realista e subespecificada. Este é o cenário principal usado para testar como os modelos lidam com entrada de múltiplas voltas.

No cenário Concat, os fragmentos são costurados de volta como uma lista única, preservando a redação, mas removendo a estrutura de volta a volta. Isso ajuda a isolar os efeitos da fragmentação conversacional da reescrita ou perda de conteúdo.

O cenário Resumo funciona como Sharded, mas adiciona uma volta final onde todos os fragmentos anteriores são reafirmados antes de o modelo dar uma resposta final. Isso testa se um prompt de resumo pode ajudar a recuperar o contexto perdido.

Finalmente, Neve vai mais longe, repetindo todos os fragmentos anteriores em cada volta, mantendo a instrução completa visível à medida que a conversa se desenrola – e oferecendo um teste mais indulgente da capacidade de múltiplas voltas.

Tipos de simulação baseados em instruções sharded. Um prompt completamente especificado é dividido em partes menores, que podem ser usadas para simular conversas de uma única volta (Completo, Concat) ou de múltiplas voltas (Sharded, Resumo, Neve), dependendo de quão rapidamente a informação é revelada.

Tarefas e Métricas

Seis tarefas de geração foram escolhidas para cobrir tanto programação quanto domínios de linguagem natural: prompts de geração de código foram tirados de HumanEval e LiveCodeBench; consultas Text-to-SQL foram obtidas de Spider; chamadas de API foram construídas usando dados do Berkeley Function Calling Leaderboard; problemas de matemática elementar foram fornecidos por GSM8K; tarefas de legendagem de tabela foram baseadas em ToTTo; e resumos de múltiplos documentos foram tirados do conjunto de dados Summary of a Haystack.

O desempenho do modelo foi medido usando três métricas principais: desempenho médio, habilidade e inconfiabilidade.

Desempenho médio capturou como o modelo se saiu em geral em várias tentativas; habilidade refletiu os melhores resultados que um modelo podia alcançar, com base em suas saídas de pontuação mais alta; e inconfiabilidade mediu quão variados esses resultados eram, com lacunas maiores entre os melhores e os piores resultados indicando comportamento menos estável.

Todas as pontuações foram colocadas em uma escala de 0 a 100 para garantir consistência em todas as tarefas, e as métricas foram calculadas para cada instrução – e então médias para fornecer uma visão geral do desempenho do modelo.

Seis tarefas sharded usadas nos experimentos, cobrindo tanto programação quanto geração de linguagem natural. Cada tarefa é mostrada com uma instrução completamente especificada e sua versão sharded. Entre 90 e 120 instruções foram adaptadas de benchmarks estabelecidos para cada tarefa.

Concorrentes e Testes

Nas simulações iniciais (com um custo estimado de $5000), 600 instruções abrangendo seis tarefas foram sharded e usadas para simular três tipos de conversa: completo, concat e sharded. Para cada combinação de modelo, instrução e tipo de simulação, dez conversas foram executadas, produzindo mais de 200.000 simulações no total – um esquema que tornou possível capturar tanto o desempenho geral quanto medidas mais profundas de habilidade e confiabilidade.

Quinze modelos foram testados, abrangendo uma ampla gama de provedores e arquiteturas: os modelos OpenAI GPT-4o (versão 2024-11-20), GPT-4o-mini (2024-07-18), GPT-4.1 (2025-04-14), e o modelo de pensamento o3 (2025-04-16).

Os modelos Anthropic foram Claude 3 Haiku (2024-03-07) e Claude 3.7 Sonnet (2025-02-19), acessados via Amazon Bedrock.

O Google contribuiu com Gemini 2.5 Flash (preview-04-17) e Gemini 2.5 Pro (preview-03-25). Os modelos Meta foram Llama 3.1-8B-Instruct e Llama 3.3-70B-Instruct, bem como Llama 4 Scout-17B-16E, via Together AI.

As outras entradas foram OLMo 2 13B, Phi-4, e Command-A, todos acessados localmente via Ollama ou Cohere API; e Deepseek-R1, acessado por meio da Amazon Bedrock.

Para os dois modelos de pensamento (o3 e R1), ‘limites de token foram aumentados para 10.000 para acomodar cadeias de raciocínio mais longas:

Pontuações de desempenho médio para cada modelo em seis tarefas: código, banco de dados, ações, dados para texto, matemática e resumo. Os resultados são mostrados para três tipos de simulação: completo, concat e sharded. Os modelos são ordenados por sua pontuação média no cenário completo. A sombreamento reflete o grau de declínio no desempenho a partir do cenário completo, com as duas colunas finais relatando declínios médios para concat e sharded em relação ao completo.

Com relação a esses resultados, os autores afirmam^†:

‘Em alto nível, todo modelo vê seu desempenho degradar-se em cada tarefa quando comparando o desempenho Completo e Sharded, com uma degradação média de -39%. Nós nomeamos esse fenômeno Perdido em Conversa: modelos que alcançam desempenho estelar (90%+) em um ambiente de laboratório de conversa de uma única volta, com prompts completamente especificados, lutam nas mesmas tarefas em um ambiente mais realista quando a conversa é subespecificada e de múltiplas voltas.’

Concat pontuações médias foram 95% das pontuações completas, indicando que a queda no desempenho no cenário sharded não pode ser explicada pela perda de informação. Modelos menores, como Llama3.1-8B-Instruct, OLMo-2-13B e Claude 3 Haiku, mostraram uma degradação mais acentuada no cenário concat, sugerindo que modelos menores são geralmente menos robustos à reescrita do que os maiores.

Os autores observam^†:

‘Surpreendentemente, modelos mais performáticos (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) se perdem igualmente em conversas em comparação com modelos menores (Llama3.1-8B-Instruct, Phi-4), com degradações médias de 30-40%. Isso ocorre em parte devido às definições de métricas. Como os modelos menores alcançam pontuações absolutas mais baixas no cenário Completo, eles têm menos espaço para degradação do que os melhores modelos.

‘Em resumo, não importa quão forte seja o desempenho de uma única volta de um LLM, observamos grandes degradações de desempenho no cenário de múltiplas voltas.’

O teste inicial indica que alguns modelos se saíram melhor em tarefas específicas: Command-A em Ações, Claude 3.7 Sonnet e GPT-4.1 em código; e Gemini 2.5 Pro em Dados para Texto, indicando que a capacidade de múltiplas voltas varia por domínio. Modelos de raciocínio, como o3 e Deepseek-R1, não se saíram melhor no geral, talvez porque suas respostas mais longas introduziram mais suposições, que tendiam a confundir a conversa.

Confiabilidade

A relação entre habilidade e confiabilidade, clara em simulações de uma única volta, pareceu se desintegrar em condições de múltiplas voltas. Embora a habilidade declinasse apenas modestamente, a inconfiabilidade dobrou em média. Modelos que eram estáveis em prompts de formato completo, como GPT-4.1 e Gemini 2.5 Pro, tornaram-se igualmente erráticos quanto modelos mais fracos, como Llama3.1-8B-Instruct ou OLMo-2-13B, uma vez que a instrução foi fragmentada.

Visão geral da habilidade e inconfiabilidade, como mostrado em um gráfico de caixa (a), seguido por resultados de confiabilidade de experimentos com 15 modelos (b), e resultados do teste de sharding gradual, onde as instruções foram divididas em um a oito fragmentos (c).

As respostas do modelo frequentemente variavam tanto quanto 50 pontos na mesma tarefa, mesmo quando nada de novo foi adicionado, sugerindo que a queda no desempenho não foi devido à falta de habilidade, mas à instabilidade crescente do modelo ao longo das voltas.

O artigo afirma^†:

‘[Embora] modelos melhores tendam a ter habilidades de múltiplas voltas ligeiramente mais altas, todos os modelos que testamos exibem níveis de inconfiabilidade muito altos, com desempenho degradando-se 50 pontos em média entre a melhor e a pior execução simulada para uma instrução fixa.’

Para testar se a degradação do desempenho estava ligada ao número de voltas, os autores realizaram um experimento de sharding gradual, dividindo cada instrução em um a oito fragmentos (veja a coluna mais à direita na imagem acima).

À medida que o número de fragmentos aumentava, a inconfiabilidade subia consistentemente, confirmando que até mesmo aumentos menores no número de voltas tornavam os modelos mais instáveis. A habilidade permaneceu basicamente inalterada, reforçando que o problema reside na consistência, não na capacidade.

Controle de Temperatura

Um conjunto separado de experimentos testou se a inconfiabilidade era apenas um subproduto da aleatoriedade. Para fazer isso, os autores variaram a configuração de temperatura tanto do assistente quanto do simulador de usuário em três valores: 1,0, 0,5 e 0,0.

Em formatos de uma única volta, como completo e concat, reduzir a temperatura do assistente melhorou significativamente a confiabilidade, cortando a variação em até 80%; mas no cenário sharded, a mesma intervenção teve pouco efeito:

Pontuações de inconfiabilidade para diferentes combinações de temperatura do assistente e do usuário em cenários completo, concat e sharded, com valores mais baixos indicando consistência de resposta maior.

Mesmo quando tanto o assistente quanto o usuário foram definidos para zero de temperatura, a inconfiabilidade permaneceu alta, com GPT-4o mostrando variação em torno de 30%, sugerindo que a instabilidade observada em conversas de múltiplas voltas não é apenas ruído estocástico, mas uma fraqueza estrutural na forma como os modelos lidam com entrada fragmentada.

Implicações

Os autores escrevem sobre as implicações de suas descobertas com uma extensão incomum na conclusão do artigo, argumentando que um desempenho de uma única volta forte não garante confiabilidade de múltiplas voltas e advertindo contra a confiança excessiva em benchmarks completamente especificados ao avaliar a prontidão para o mundo real (já que esses benchmarks mascaram a instabilidade em interações mais naturais e fragmentadas).

Eles também sugerem que a inconfiabilidade não é apenas um artefato de amostragem, mas uma limitação fundamental na forma como os modelos atuais processam entrada em evolução, e sugerem que isso levanta preocupações para quadros de agente, que dependem de raciocínio sustentado ao longo das voltas.

Finalmente, eles argumentam que a capacidade de múltiplas voltas deve ser tratada como uma capacidade central dos LLMs, não algo repassado para sistemas externos.

Os autores notam que seus resultados provavelmente subestimam a verdadeira escala do problema e chamam a atenção para as condições ideais do teste: o simulador de usuário em seu setup teve acesso completo à instrução e pôde revelar fragmentos em uma ordem ótima, o que deu ao assistente um contexto favorável (em uso real, os usuários frequentemente fornecem prompts fragmentados ou ambíguos sem saber o que o modelo precisa ouvir em seguida).

Além disso, o assistente foi avaliado imediatamente após cada volta, antes que a conversa completa se desenrolasse, impedindo que confusão ou autocontradição posteriores fossem penalizadas, o que pioraria o desempenho. Essas escolhas, embora necessárias para o controle experimental, significam que as lacunas de confiabilidade observadas na prática são provavelmente ainda maiores do que as relatadas.

Eles concluem:

‘[Nós] acreditamos que as simulações realizadas representam um terreno de teste benigno para as capacidades de múltiplas voltas dos LLMs. Devido às condições de simulação excessivamente simplificadas, acreditamos que a degradação observada nos experimentos é provavelmente uma subestimação da inconfiabilidade dos LLMs e de quão frequentemente os LLMs se perdem em conversas em configurações do mundo real.‘

Conclusão

Qualquer pessoa que tenha passado um tempo significativo com um LLM provavelmente reconhecerá os problemas formulados aqui, a partir da experiência prática; e a maioria de nós, imagino, abandonou conversas ‘perdidas’ com LLMs por novas, na esperança de que o LLM possa ‘recomeçar’ e parar de se obcecar com material que surgiu em uma troca longa e cada vez mais irritante.

É interessante notar que jogar mais contexto no problema pode não necessariamente resolvê-lo; e de fato, observar que o artigo levanta mais questões do que fornece respostas (exceto em termos de maneiras de contornar o problema).

* Confusamente, isso não está relacionado ao significado convencional de ‘sharding’ em IA.

† Ênfases em negrito dos autores.

Publicado pela primeira vez na segunda-feira, 12 de maio de 2025