Por que os modelos de linguagem se "perdem" na conversa

Um novo artigo da Microsoft Research e da Salesforce conclui que mesmo os mais capazes Modelos de linguagem grandes (LLMs) desmoronam quando instruções são dadas em estágios em vez de tudo de uma vez. Os autores descobriram que o desempenho cai em média 39 por cento em seis tarefas quando um prompt é dividido em várias voltas:

Uma conversa de turno único (esquerda) obtém os melhores resultados, mas não é natural para o usuário final. Uma conversa de turnos múltiplos (direita) faz com que até mesmo os LLMs mais bem classificados e com melhor desempenho percam o ímpeto efetivo em uma conversa. Fonte: https://arxiv.org/pdf/2505.06120

Mais impressionante ainda, o confiabilidade de respostas sofre uma queda acentuada, com modelos prestigiados como Bate-papoGPT-4.1 e Gêmeos 2.5 Pró 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 em mais da metade no processo.

Para explorar esse comportamento, o artigo apresenta um método chamado raspando*, que divide prompts totalmente especificados em fragmentos menores e os libera um de cada vez em uma conversa.

Em termos mais básicos, isso equivale a fazer um pedido único, coeso e abrangente, em um restaurante, deixando o garçom sem outra opção a não ser reconhecer o pedido; ou então decidir atacar o assunto de forma colaborativa:

Duas versões extremas de uma conversa em um restaurante (não do novo jornal, apenas para fins ilustrativos).

Para enfatizar, o exemplo acima talvez coloque o cliente sob uma luz negativa. Mas a ideia central retratada 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 se reflete no gotejamento do novo trabalho, fragmentado abordagem para a interação com o LLM. Os autores observam que os LLMs frequentemente geram respostas excessivamente longas e, então, continuam a confiar em seus próprios insights mesmo depois de essas percepções terem sido demonstradas como incorretas ou irrelevantes. Essa tendência, combinada com outros fatores, pode fazer com que o sistema perca completamente o controle da troca.

Na verdade, os pesquisadores observam o que muitos de nós descobriram anedoticamente – que a melhor maneira de retomar o rumo da conversa é iniciar uma nova conversa com o LLM.

'Se uma conversa com um LLM não levou aos resultados esperados, iniciar uma nova conversa que repita as mesmas informações pode gerar 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 aleatoriamente, uma nova conversa pode levar a melhores resultados.

Os autores reconhecem que sistemas de agentes como autógeno or LangChain podem potencialmente melhorar os resultados agindo como camadas interpretativas entre o usuário final e o LLM, comunicando-se com o LLM somente quando tiverem reunido respostas 'fragmentadas' suficientes para coagular em uma única consulta coesa (à qual o usuário final não será exposto).

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

Pode-se argumentar que os recursos multi-turno não são um recurso necessário dos LLMs, pois podem ser transferidos para a estrutura do agente. Em outras palavras, precisamos de suporte nativo multi-turno em LLMs quando uma estrutura de agente pode orquestrar interações com usuários e utilizar LLMs apenas como operadores de turno único?…

Mas depois de testar a proposição em sua série de exemplos, eles concluem:

'[Depender] de uma estrutura semelhante a um agente para processar informações pode ser limitante, e argumentamos que os LLMs devem oferecer suporte nativo à interação multi-turno'

Este interessante novo papel é intitulado LLMs se perdem em conversas multifacetadas, e vem de quatro pesquisadores da MS Research e da 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 LLM, uma estrutura que reflete o estilo de engajamento exploratório e de vaivém visto em sistemas como ChatGPT ou Google Gemini.

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

Instruções pareadas mostrando (a) um prompt completo entregue em uma única volta e (b) sua versão fragmentada usada para simular uma interação subespecificada e multivolta. Semanticamente, cada versão entrega a mesma carga informacional.

O primeiro fragmento sempre apresenta o objetivo principal da tarefa, enquanto os demais fornecem detalhes esclarecedores. Juntos, eles apresentam o mesmo conteúdo do prompt original, mas se distribuem naturalmente ao longo de vários turnos da conversa.

Cada conversa simulada se desenrola entre três componentes: o assistente, o modelo em avaliação; o do utilizador, um agente simulado com acesso à instrução completa em formato fragmentado; e o sistema., que fiscaliza 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 de várias categorias, como pedido de esclarecimento ou o tentativa de resposta completa.

Se o modelo parece Ao tentar responder, um componente separado extrai apenas o intervalo relevante para avaliação, ignorando qualquer texto ao redor. A cada nova rodada, o usuário revela um fragmento adicional, solicitando outra resposta. A troca continua até que o modelo acerte a resposta ou não haja mais fragmentos para revelar:

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

Os primeiros testes 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 os fragmentos em uma ordem fixa. Em vez disso, um simulador foi usado para decidir qual fragmento revelar em seguida, com base no andamento da conversa.

O simulador de usuário, implementado usando GPT-4o-mini, recebeu, portanto, acesso total tanto à instrução completa quanto ao histórico da conversa, tendo a tarefa de decidir, a cada passo, qual fragmento revelar em seguida, com base em como a troca estava se desenrolando.

O simulador de usuário também reformulado cada fragmento para manter o fluxo da conversa, sem alterar o significado. Isso permitiu que a simulação refletisse o "toma lá, dá cá" do diálogo real, preservando o controle sobre a estrutura da tarefa.

Antes do início da conversa, o assistente recebe apenas as informações básicas necessárias para concluir a tarefa, como um esquema de banco de dados ou uma referência de API. Não é informado que as instruções serão divididas e não é orientado sobre nenhuma maneira específica de lidar com a conversa. Isso é feito de propósito: no uso real, os modelos quase nunca são informados de que um prompt estará incompleto ou será atualizado ao longo do tempo, e omitir esse contexto ajuda a simulação a refletir como o modelo se comporta em um contexto mais realista.

O GPT-4o-mini também foi usado para decidir como as respostas do modelo deveriam ser classificadas e para extrair as respostas finais dessas respostas. Isso ajudou a manter a flexibilidade da simulação, mas introduziu erros ocasionais: após verificar centenas de conversas manualmente, os autores descobriram que menos de XNUMX% apresentaram problemas e menos de XNUMX% apresentaram alteração no resultado devido a eles, o que eles consideraram uma taxa de erro suficientemente baixa 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 uma uma variação de como e quando partes da instrução são reveladas.

De acordo com o relatório completo Nesta configuração, o modelo recebe toda a instrução em uma única volta. Isso representa o formato de benchmark padrão e serve como base de desempenho.

O método da Sharded A configuração divide a instrução em várias partes e as entrega uma de cada vez, simulando uma conversa mais realista e subespecificada. Esta é a configuração principal usada para testar o quão bem os modelos lidam com entradas multi-turn.

De acordo com o relatório Concatenar Nessa configuração, os fragmentos são costurados novamente como uma única lista, preservando sua formulação, mas removendo a estrutura passo a passo. Isso ajuda a isolar os efeitos da fragmentação conversacional da reformulação ou da perda de conteúdo.

O método da Recapitular configuração funciona como Sharded, mas adiciona uma volta final onde todos os fragmentos anteriores são reapresentados antes que o modelo dê uma resposta final. Isso testa se um prompt de resumo pode ajudar a recuperar o contexto perdido.

Finalmente, Bola de neve vai mais longe, repetindo todos os fragmentos anteriores em cada turno, mantendo a instrução completa visível à medida que a conversa se desenrola – e oferecendo um teste mais tolerante de capacidade de resposta múltipla.

Tipos de simulação baseados em instruções fragmentadas. Um prompt totalmente especificado é dividido em partes menores, que podem ser usadas para simular conversas de uma única volta (Completa, Concatenada) ou de várias voltas (Fragmentada, Recapitulada, Bola de Neve), dependendo da rapidez com que as informações são reveladas.

Tarefas e Métricas

Foram escolhidas seis tarefas de geração para cobrir os domínios de programação e de linguagem natural: os prompts de geração de código foram retirados de Avaliação Humana e Banco de Códigos ao Vivo; As consultas de texto para SQL foram originadas de Spiders; As chamadas de API foram construídas usando dados do Classificação de chamadas de função de Berkeley; problemas matemáticos elementares foram fornecidos por GSM8K; as tarefas de legendagem tabular foram baseadas em ParaTTo; e resumos multidocumentais foram extraídos do Resumo de um palheiro conjunto de dados.

O desempenho do modelo foi medido usando três métricas principais: desempenho médio, aptidão e falta de confiabilidade.

Desempenho médio capturou o desempenho geral de um modelo em várias tentativas; aptidão refletiu os melhores resultados que um modelo poderia alcançar, com base em suas saídas de maior pontuação; e falta de confiabilidade mediu o quanto esses resultados variaram, com lacunas maiores entre os melhores e os piores resultados indicando um comportamento menos estável.

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

Seis tarefas fragmentadas foram utilizadas nos experimentos, abrangendo programação e geração de linguagem natural. Cada tarefa é apresentada com uma instrução totalmente especificada e sua versão fragmentada. 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 US$ 5000), 600 instruções abrangendo seis tarefas foram fragmentadas e usadas para simular três tipos de conversação: completa, concat e fragmentado. 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 aptidão e confiabilidade.

Foram testados quinze modelos, 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 antrópicos eram Claude 3 Haiku (2024-03-07) e Soneto de Cláudio 3.7 (2025-02-19), acessado via Amazon Bedrock.

O Google contribuiu Gêmeos 2.5 Flash (prévia-04-17) e Gêmeos 2.5 Pró (preview-03-25). Os metamodelos foram Lhama 3.1-8B-Instruct e Lhama 3.3-70B-Instruct, assim como Llama 4 Scout-17B-16E, via Together AI.

As outras entradas foram OLMo 2 13B, Phi-4 e Comando-A, todos acessados ​​localmente via Ollama ou Cohere API; e Busca Profunda-R1, acessado através do Amazon Bedrock.

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

Pontuações médias de desempenho para cada modelo em seis tarefas: código, banco de dados, ações, conversão de dados em texto, matemática e resumo. Os resultados são exibidos para três tipos de simulação: completa, concatenada e fragmentada. Os modelos são ordenados por sua pontuação média na configuração completa. O sombreamento reflete o grau de queda de desempenho em relação à configuração completa, com as duas colunas finais relatando declínios médios para concatenada e fragmentada em relação à completa.

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

'Em alto nível, cada modelo vê seu desempenho degradar em cada tarefa ao comparar o desempenho COMPLETO e COMPARTILHADO, com uma degradação média de -39%. Chamamos a este fenómeno Perdido na conversa: modelos que alcançam desempenho estelar (90%+) em ambiente de laboratório de luta de conversação de turno único totalmente especificado nas mesmas tarefas exatas em um cenário mais realista, quando a conversa é subespecificada e multifacetada.'

Concatenar as pontuações médias foram de 95 por cento completa, indicando que a queda de desempenho na configuração fragmentada não pode ser explicada pela perda de informações. Modelos menores, como Llama3.1-8B-Instruct, OLMo-2-13B e Claude 3 Haiku, apresentaram degradação mais pronunciada sob concat, sugerindo que modelos menores são geralmente menos resistentes à reformulação 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 na conversa em comparação com modelos menores (Llama3.1-8B-Instruct, Phi-4), com degradações médias de 30-40%. Isso se deve, em parte, às definições métricas. Como modelos menores alcançam pontuações absolutas mais baixas em FULL, eles têm menos espaço para degradação do que os melhores modelos.

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

O teste inicial indica que alguns modelos apresentaram melhor desempenho 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 conversão em múltiplas voltas varia de acordo com o domínio. Modelos de raciocínio como o3 e Deepseek-R1 não apresentaram melhor desempenho geral, talvez porque suas respostas mais longas introduzissem mais suposições, o que tendia a confundir a conversa.

Confiabilidade

A relação entre aptidão e confiabilidade, evidente em simulações de volta única, pareceu se desfazer em condições de voltas múltiplas. Embora a aptidão tenha diminuído apenas modestamente, a falta de confiabilidade duplicou Em média. Modelos estáveis ​​em prompts de formato completo, como GPT-4.1 e Gemini 2.5 Pro, tornaram-se tão erráticos quanto modelos mais fracos, como Llama3.1-8B-Instruct ou OLMo-2-13B, quando a instrução foi fragmentada.

Visão geral da aptidão e da falta de confiabilidade, conforme mostrado em um gráfico de caixa (a), seguido pelos resultados de confiabilidade de experimentos com quinze modelos (b) e resultados do teste de fragmentação gradual, onde as instruções foram divididas em um a oito fragmentos (c).

As respostas do modelo frequentemente variavam em até 50 pontos na mesma tarefa, mesmo quando nada de novo era adicionado, sugerindo que a queda no desempenho não era devido à falta de habilidade, mas ao modelo se tornar cada vez mais instável ao longo dos turnos.

O artigo afirma^†:

[Embora] modelos melhores tendam a ter uma aptidão multivolta ligeiramente maior, todos os modelos tendem a apresentar níveis semelhantes de falta de confiabilidade. Em outras palavras, em configurações subespecificadas e de múltiplas voltas, todos os modelos que testamos apresentam uma altíssima falta de confiabilidade, com desempenho degradando 50 pontos percentuais 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 relacionada ao número de voltas, os autores realizaram um experimento de fragmentação 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 falta de confiabilidade aumentava de forma constante, confirmando que mesmo pequenos aumentos na contagem de turnos tornaram os modelos mais instáveis. A aptidão permaneceu praticamente inalterada, reforçando que o problema reside em consistência, não capacidade.

Controle de Temperatura

Um conjunto separado de experimentos testou se a falta de confiabilidade era simplesmente um subproduto da aleatoriedade. Para isso, os autores variaram a configuração de temperatura do assistente e do simulador de usuário em três valores: 1.0, 0.5 e 0.0.

Em formatos de volta única como completa e concat, a redução da temperatura do assistente melhorou significativamente a confiabilidade, reduzindo a variação em até 80 por cento; mas no fragmentado configuração, a mesma intervenção teve pouco efeito:

Pontuações de falta de confiabilidade para diferentes combinações de temperatura do assistente e do usuário em configurações completas, concatenadas e fragmentadas, com valores mais baixos indicando maior consistência de resposta.

Mesmo quando tanto o assistente como o utilizador foram ajustados para temperatura zero, a falta de fiabilidade permaneceu elevada, com o GPT-4o a apresentar uma variação em torno dos 30 por cento, sugerindo que a instabilidade observada em conversas multi-turno não é apenas ruído estocástico, mas uma fraqueza estrutural na forma como os modelos lidam com entradas fragmentadas.

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 forte em uma única volta não garante confiabilidade em várias voltas e alertando contra a dependência excessiva de benchmarks totalmente especificados ao avaliar a prontidão no mundo real (já que tais benchmarks mascaram a instabilidade em interações mais naturais e fragmentadas).

Eles também sugerem que a falta de confiabilidade não é apenas um artefato de amostragem, mas uma limitação fundamental na forma como os modelos atuais processam a entrada em evolução, e sugerem que isso levanta preocupações para estruturas de agentes, que dependem de raciocínio sustentado em turnos.

Por fim, eles argumentam que a capacidade de multi-turno deve ser tratada como uma capacidade essencial dos LLMs, não algo transferido para sistemas externos.

Os autores observam que os seus resultados provavelmente subestimar a verdadeira escala do problema e chamar a atenção para as condições ideais do teste: o simulador de usuário em sua configuração tinha acesso total às instruções e podia revelar fragmentos em uma ordem ideal, o que dava ao assistente um contexto irrealisticamente favorável (no uso no mundo real, os usuários geralmente 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 turno, antes que a conversa completa se desenrolasse, evitando que confusões ou autocontradições posteriores fossem penalizadas, o que, de outra forma, pioraria o desempenho. Essas escolhas, embora necessárias para o controle experimental, significam que as lacunas de confiabilidade observadas na prática provavelmente serão ainda maiores do que as relatadas.

Eles concluem:

'[Acreditamos] que as simulações conduzidas representam um campo de testes benigno para as capacidades multivoltas do LLM. Devido às condições excessivamente simplificadas da simulação, acreditamos que a degradação observada nos experimentos é provavelmente uma subestimação da falta de confiabilidade do LLM e da frequência com que os LLMs se perdem na conversa em cenários do mundo real.'

Conclusão

Qualquer pessoa que tenha passado um tempo significativo com um LLM provavelmente reconhecerá as questões formuladas aqui, a partir da experiência prática; e a maioria de nós, imagino, abandonou intuitivamente conversas "perdidas" do LLM por novas, na esperança de que o LLM possa "recomeçar" e parar de ficar obcecado com material que surgiu em uma troca longa, tortuosa e cada vez mais irritante.

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

* Confusamente, isso não tem relação com o significado convencional de 'fragmentação' em IA.

† Ênfases em negrito dos próprios autores.

Primeira publicação na segunda-feira, 12 de maio de 2025