LLMs se perdem em conversas de múltiplos turnos
(arxiv.org)- Quando o usuário não consegue escrever todos os requisitos de uma vez, o desempenho de instruções incompletas em múltiplos turnos de 15 LLMs cai muito em relação a instruções completas em turno único: a média em 6 tarefas generativas desce de 90% para 65%
- O experimento foi montado com uma abordagem de sharding, que divide instruções tradicionais de benchmarks de turno único em vários pedaços, revelando gradualmente condições e contexto ao longo da conversa
- A queda de desempenho foi causada mais pelo aumento da instabilidade do que por simples falta de capacidade; em mais de 200.000 conversas, os modelos dependeram demais de suposições iniciais e de tentativas precoces de resposta final
- Os testes incluíram desde o Llama3.1-8B-Instruct até o Gemini 2.5 Pro, usando tanto tarefas de programação quanto de geração em linguagem natural, como Code, Database, Actions, Math, Data-to-Text e Summary
- Embora seja uma simulação simplificada de conversas reais entre humanos e IA, todas as conversas foram projetadas para terminar com informação suficiente para resolver a tarefa; por isso, a queda observada pode ser menor do que em diálogos reais incompletos de múltiplos turnos
A lacuna entre avaliação de turno único e uso real em conversa
- LLMs são usados por meio de interfaces conversacionais como ChatGPT, Gemini e Claude, e os usuários podem definir, explorar e revisar o que querem ao longo de vários turnos, mesmo sem especificar tudo logo no começo
- As avaliações tradicionais de LLMs se concentram principalmente em cenários de turno único com instruções completas, mas logs de conversas com LLM mostram que a incompletude das instruções do usuário é algo comum
- Muitas avaliações anteriores de múltiplos turnos são mais próximas de uma abordagem episódica, tratando a conversa como uma sequência de subtarefas que podem ser avaliadas independentemente
- Isso exige alguma compreensão de contexto entre turnos, mas é diferente de situações em que o modelo precisa combinar ativamente informações vindas de instruções incompletas do usuário
- Esse tipo de tarefa pode fazer o desempenho do LLM em conversas de múltiplos turnos parecer melhor do que realmente é
Conversas incompletas de múltiplos turnos criadas com sharding
- O experimento transforma instruções completas de benchmarks de turno único de alta qualidade em sharded instructions
- O primeiro shard apresenta a intenção de alto nível da tarefa
- Os shards seguintes fornecem, um a um, condições adicionais ou contexto da instrução original
- Juntos, todos os shards contêm a mesma informação da instrução completa original
- Como exemplo, no problema da bola de neve do GSM8K, o enunciado em turno único fornece de uma vez condições como “20 produzidas por hora”, “2 derretem a cada 15 minutos” e “são necessárias 60 no total”, enquanto a versão sharded revela isso ao longo de vários turnos
- O processo de sharding foi semiautomático: o GPT-4o gerou e validou candidatos, e depois pesquisadores revisaram e ajustaram o resultado
Estrutura da simulação de conversa
- A simulação de múltiplos turnos envolve três agentes
- assistant avaliado: o LLM cujo desempenho será medido
- user simulator: um LLM que conhece toda a sharded instruction e revela o próximo shard a cada turno
- system: componente que classifica as respostas do assistant e avalia tentativas de resposta
- No primeiro turno, o user simulator revela apenas o primeiro shard, e o assistant responde em texto livre
- A resposta do assistant é classificada em uma de 7 estratégias
- clarification
- refusal
- hedging
- interrogation
- discussion
- missing
- answer attempt
- Quando a resposta é classificada como answer attempt, um answer extractor extrai o trecho necessário para avaliação, como código, número ou SQL, e um avaliador específico da tarefa atribui a pontuação
- A conversa termina em uma de duas condições
- a tentativa de resposta do assistant é avaliada como correta
- ao iniciar um novo turno, não resta mais shard a revelar
- O user simulator, o strategy classifier e o answer extractor foram implementados com GPT-4o-mini baseado em prompts
- A anotação manual de centenas de conversas mostrou que erros do user simulator, do classifier e do extractor ocorreram em menos de 5% das conversas inspecionadas, e erros que prejudicaram o modelo assistant ficaram abaixo de 2%
Cinco tipos de simulação comparados
- FULL é a simulação de turno único em que a instrução completa original é fornecida no primeiro turno, usada como linha de base de desempenho
- SHARDED é a conversa incompleta de múltiplos turnos em que os shards são revelados ao longo de vários turnos, sendo o ambiente central de avaliação
- CONCAT junta os shards em instruções com bullet points dentro de um único turno
- Como em FULL, a incompletude é removida
- Como em SHARDED, mantém-se a reformulação criada pelo processo de sharding
- Se o modelo acerta em FULL e CONCAT, mas falha em SHARDED, a causa pode ser a própria natureza do cenário incompleto de múltiplos turnos, e não perda de informação
- RECAP reapresenta todos os shards de uma vez no final da conversa SHARDED, dando ao LLM uma chance final de responder
- SNOWBALL reapresenta em cada turno o novo shard junto com todos os shards já revelados, fornecendo um resumo acumulado a cada etapa
Tarefas e benchmarks usados
- O experimento é composto por 6 tarefas generativas cobrindo casos de uso tanto de programação quanto de geração em linguagem natural
- Para cada tarefa, foram preparados de 90 a 120 sharded instructions, totalizando 600 instructions
- Composição das tarefas:
- Code: escrita de funções em Python com base em HumanEval e LiveCodeBench
- Database: geração de text-to-SQL com base no Spider
- Actions: geração de chamadas de função de API com base no Berkeley Function Calling Leaderboard
- Math: resolução de problemas matemáticos elementares em linguagem natural com base no GSM8K
- Data-to-Text: geração de descrições textuais de dados tabulares com base no ToTTo
- Summary: resumo de conjuntos de documentos e geração de citações com base no Summary of a Haystack
- As métricas de avaliação reutilizam as métricas originais dos benchmarks
- Code e Database usam acurácia baseada em execução
- Actions e Math usam equivalência semântica com a resposta de referência ou acerto numérico
- Data-to-Text usa BLEU
- Summary usa o “Joint Score”, um método de LLM-as-a-judge que mede cobertura de informação e precisão da atribuição de fontes
- Acurácia binária também foi mapeada para uma escala de 0 a 100, para agregar todas as tarefas na mesma escala
Medindo desempenho, capacidade e instabilidade
- Como as saídas dos LLMs são probabilísticas, cada instruction e tipo de simulação foi executado N=10 vezes
- Cada execução foi avaliada em uma escala de 0 a 100
- Foram usadas três métricas
- desempenho médio P: média das pontuações nas execuções repetidas
- aptitude A90: percentil 90 das pontuações, como estimativa do melhor caso entre os 10% melhores resultados
- unreliability U90-10: diferença entre os percentis 90 e 10, medindo a distância entre o melhor e o pior caso
- Em turno único, modelos com maior aptitude tendiam também a ser mais confiáveis, mas em múltiplos turnos apareceu alta unreliability em todos os LLMs, independentemente da aptitude
Resultados do experimento em larga escala
- O experimento principal foi conduzido com 600 instructions, 3 tipos de simulação (FULL, CONCAT, SHARDED) e 15 LLMs
- Cada combinação foi repetida 10 vezes, simulando mais de 200.000 conversas
- Todas as simulações foram executadas com temperature padrão T=1, e o efeito da temperature sobre aptitude e reliability foi tratado em experimentos auxiliares separados
- No geral, o desempenho médio em conversas incompletas de múltiplos turnos foi de 65%, 25 pontos abaixo do desempenho de 90% em turno único com a instrução completa desde o início
- A queda de desempenho em múltiplos turnos apareceu de forma consistente, de modelos pequenos open-weight até modelos mais recentes
- Entre os modelos testados estavam desde o pequeno modelo open-weight Llama3.1-8B-Instruct até o Gemini 2.5 Pro
- A Figure 1 destaca como exemplos Claude 3.7 Sonnet, Deepseek-R1, o3, GPT-4.1 e Gemini 2.5 Pro
- A queda média de desempenho nas 6 tarefas generativas foi de 39%, e a Figure 1 mostra cerca de -35% de perda de desempenho no cenário de múltiplos turnos
Por que eles se perdem
- A queda de desempenho se divide em dois fatores
- queda de aptitude: o melhor caso de desempenho em si diminui um pouco
- aumento de unreliability: a diferença de qualidade entre execuções cresce bastante
- Segundo a Figure 1, no cenário de múltiplos turnos a aptitude cai -15% e a unreliability sobe +112%
- Os modelos tendem a formar suposições erradas com base apenas nas informações incompletas do início e a tentar dar uma resposta final cedo demais na conversa
- Mesmo quando novas informações são fornecidas depois, eles se apoiam excessivamente nas tentativas anteriores de resposta errada e falham em corrigir o rumo
- Esse fenômeno, em que o modelo entra numa direção errada em uma conversa incompleta de múltiplos turnos e não consegue se recuperar, é definido como lost in conversation
Limitações e implicações práticas
- A simulação totalmente automática não representa exatamente conversas reais entre humanos e IA
- O ambiente experimental é simplificado e idealizado
- As conversas são garantidas a terminar com informação suficiente para resolver a tarefa
- Comportamentos inesperados, como desvios de conversa que podem ocorrer no mundo real, são limitados
- Por causa desse desenho, a queda de desempenho observada pode estar subestimando a degradação que ocorreria em conversas reais incompletas de múltiplos turnos entre humanos e IA
- Organizações que criam produtos conversacionais com LLM e usuários finais precisam avaliar a confiabilidade em múltiplos turnos junto com a capacidade em turno único
- Para usuários iniciantes, que têm dificuldade de escrever requisitos completos desde o começo, a queda de desempenho em múltiplos turnos pode ser um fator que limita a adoção mais ampla de sistemas de IA
1 comentários
Opiniões no Hacker News
Para quem já usou ferramentas de LLM, é bom ver um artigo confirmar heuristicamente algo que já se sabe. Manter um contexto limpo é importante, e a “conversa” é apenas uma construção criada pela interface do produto; para a qualidade das respostas do próprio LLM, ela é prejudicial. Uma vez que o contexto é contaminado, ele não se recupera, então é preciso recomeçar em um novo chat
Perto do fim das duas semanas, o LLM ficou muito menos disperso e, mesmo quando eu colava uma thread de fórum ou um post inteiro do Stack Overflow, ele conseguia distinguir: “não é esse o fenômeno que estamos vendo aqui, por causa de [contexto ou descoberta anterior]”. Eu ainda precisava eliminar logicamente os becos sem saída e informar isso a ele, mas no fim encontramos a causa
Isso também parece estar de acordo com a ideia de que LLMs são fortes em comprimir informações complexas em algo simples, e fracos em expandir ideias simples em algo complexo. Quando a entrada era maior ou mais complexa que a saída, o resultado foi satisfatório
Eu poderia ter feito sem LLM, mas ele ajudou como um repositório quando eu esquecia fatos inseridos desde o começo ou não conseguia lembrá-los rapidamente em um novo contexto, e também foi útil para encontrar padrões temporais em arquivos de log grandes. Não apenas corrigi um problema, como também otimizei várias configurações e aprendi bastante. Ele às vezes errava o estado atual dos parâmetros, mas isso era fácil de corrigir. Se você sabe para onde está indo e o trata como uma ferramenta, ajuda; mas não se deve delegar a tomada de decisão nem deixá-lo puxar você para a direção errada
O uso total foi de cerca de 350k tokens. Há um post relacionado no blog em https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/, embora ele não corresponda diretamente a esse problema específico. Dispenso recomendações de WireGuard
É muito provável que alguém tenha ajustado recentemente o prompt para especificar uma posição sobre genocídio branco; para um chatbot perfeito, isso não importaria ao perguntar sobre outro assunto, mas na prática importa. Como isso faz parte do contexto, agora ele passa a falar disso
Parece um aspecto do conhecido excesso de confiança e da incapacidade de autorreflexão. Quando a probabilidade a priori é baixa demais, ele não percebe que deveria pedir informações mais detalhadas. Ao olhar a saída de modelos de raciocínio, quase nunca surge a ideia de fazer perguntas de esclarecimento; quando estão confusos, eles apenas especulam sem parar sobre o que o usuário poderia ter querido dizer
Isso também tem implicações para a sensatez da ideia de “substituir programadores humanos”. Uma das partes difíceis desse trabalho é interagir com stakeholders e transformar ideias ambíguas, e muitas vezes confusas, em especificações precisas
Na maioria das vezes, o usuário está escrevendo as falas do personagem User em um documento de roteiro de filme, e o algoritmo do LLM apenas autocompleta periodicamente as falas inacabadas do personagem Chatbot
Você pode entrevistar um vampiro chamado DraculaBot, mas esse personagem só consegue “fazer autorreflexão” de uma forma rasa e fictícia, como “anseia por sangue” ou “se transforma em um enxame de morcegos”
Por isso, quando o autocomplete começa a piorar, é preciso começar de novo. Não há nenhum conceito, só enormes blocos de palavras e de possíveis textos subsequentes que os textos de treinamento mostraram
Frequentemente peço ao LLM que transforme a discussão até então em um resumo conciso em formato de prompt. Edito isso conforme necessário e uso para iniciar uma nova conversa sem bagagem, e tem funcionado muito bem. Imagino que isso logo será automatizado
Foi assim que criamos o TSCE (Two-Step Contextual Enrichment). Ao testar 300 tarefas misturadas com o GPT-35-turbo, houve uma melhora de +30 pontos percentuais
É um framework aberto e gratuito, e dá para testá-lo diretamente no repositório: https://github.com/AutomationOptimization/tsce_demo
Testamos novamente 300 vezes no gpt-4.1 com a tarefa de remover o chamativo “em-dash” que as pessoas detestam. Comparamos a linha de base de passagem única e o TSCE com a mesma instrução e o prompt “Remove the em-dashes from my linkedin post. . .”
Em 300 execuções, a linha de base falhou em remover o em-dash 149/300 vezes, enquanto o TSCE falhou 18/300 vezes. Funciona, e todos os dados e scripts de teste completos estão no repositório
text.replace("—", "-")Prompt do sistema:
"Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."Prompt do usuário:
Temperature: 0.0
Venho trabalhando com bastante sucesso para resolver esse problema e em breve pretendo compartilhar mais. Tenho 2 sistemas: o primeiro é o próprio LLM, e o outro funciona como uma espécie de curador de pensamentos
Ele insere e remove partes do contexto dinamicamente, sem se basear em definições explícitas, dependendo da capacidade do LLM de “preencher as lacunas”. Esse sistema ajuda o LLM a decompor o problema em tarefas menores, que no fim são agregadas na tarefa completa
Acho que, daqui para a frente, essa distinção entre camadas de memória ficará mais clara. Pode se dividir em memória primária dos dados de treinamento, memória secundária do contexto e memória terciária do RAG
É surpreendente que ramificação/fork não seja um recurso central nas principais ferramentas de chat. Dá para editar respostas, mas aí muito do outro contexto desaparece
Meu fluxo é mais ou menos: 1) planejar 2) implementar 3) ramificar (por causa de um recurso ou de algum problema estranho de dependência) 4) voltar para o passo 2. Poda de prompts e ramificação deveriam ser ferramentas de primeira classe em qualquer uso de LLM
Há um problema evidente quando se criam interfaces de LLM centradas em conversas de turno único. A maioria das pessoas espera uma conversa linear
Criei um bot do Telegram http://t.me/experai_bot como UI de uso geral para LLMs; ele tem um pouco menos de recursos e foi projetado em torno da ideia de que “mensagens que não são respostas iniciam uma nova conversa”. Se você quiser manter o contexto, basta continuar respondendo às respostas do bot. Pessoas que não são usuárias avançadas têm dificuldade com essa ideia
Também vi que, quando modelos da OpenAI respondem à mesma pergunta, até uma mensagem de sistema muito pequena piora o desempenho. Por exemplo, a lista de opções na resposta ficava mais curta. Isso acontecia no 3.5 e no 4o; não sei quanto aos modelos mais recentes. Por isso decidi não colocar uma mensagem de sistema por padrão. Ainda assim, se necessário, dá para adicionar uma, ligá-la e desligá-la e combiná-la com outras
Tenho a impressão de que a área de LLMs hoje está cheia de gente resolvendo os mesmos problemas de novo e de novo
Esse foi o principal motivo de eu ter criado o promptdown. Eu queria poder editar todo o histórico do chat a cada turno, e isso não é fácil nas interfaces padrão de chat, que só permitem acrescentar conteúdo
https://github.com/t-kalinowski/promptdown
Sempre senti que o deboche com o termo “engenharia de prompt” também vem do fato de as pessoas superestimarem a importância do prompt inicial e subestimarem a importância de gerenciar o contexto ao longo da conversa
Com a experiência, você aprende a sentir como conduzir o modelo e quando começar uma nova conversa. O prompt de sistema ou o prompt inicial também são importantes, mas, se você ingenuamente prolonga demais a conversa, nada disso vai salvar você