Em conversas multi-turno, LLMs se perdem

• Modelos de linguagem de grande porte (LLMs) mostram queda de desempenho e redução de confiabilidade em conversas com múltiplos turnos
• Em comparação com single-turn, foi confirmada experimentalmente uma queda média de 39% no desempenho em cenários multi-turno
• Os principais fatores são uma pequena redução de aptidão e uma queda muito maior de confiabilidade, ou seja, falta de consistência nos resultados
• LLMs tendem a fazer suposições erradas cedo na conversa ou a tentar chegar à resposta final cedo demais
• Como resultado, quando um LLM comete um erro no início da conversa, foi observado que ele não consegue se recuperar e perde a direção da conversa

---

ABSTRACT

• Modelos de linguagem de grande porte (LLMs), como interfaces conversacionais, têm potencial para ajudar usuários a definir, explorar e revisar requisitos gradualmente por meio de conversas multi-turno, mesmo quando o pedido do usuário não está totalmente especificado
• No entanto, embora a maioria das avaliações de LLMs se concentre apenas em ambientes de instruções totalmente especificadas em single-turn, a análise de logs de conversas reais mostra que o fenômeno de subespecificação (underspecification) é frequente
• Este estudo compara em larga escala o desempenho de LLMs em ambientes single-turn e multi-turno (subespecificados) por meio de simulações
• Como resultado, em 15 LLMs principais, há uma queda média de 39% no desempenho em conversas multi-turno, explicada por uma leve queda de aptidão e uma forte deterioração da confiabilidade
• Quando um LLM segue um caminho errado no início da conversa, observou-se o fenômeno de ele não conseguir se recuperar e ficar perdido na conversa

Introduction

• LLMs modernos (por exemplo, ChatGPT, Gemini, Claude etc.) oferecem interfaces com conversas multi-turno
• Mesmo que o usuário não descreva claramente todos os requisitos desde o início, é possível detalhá-los gradualmente com interações repetidas de perguntas e respostas (subespecificado → refinado)
• Na prática, muitos usuários apresentam pedidos ambíguos no início da conversa, mas a maioria das avaliações ainda é feita apenas em ambientes single-turn totalmente especificados
• Alguns estudos anteriores tentaram avaliações multi-turno, mas como muitas vezes tratam cada turno da conversa como um episódio independente, acabam subestimando o impacto da ambiguidade comum em conversas humanas reais
• Para reduzir essa lacuna, este estudo propõe um ambiente chamado sharded simulation (dividir a informação em várias partes e revelar apenas uma por turno), simulando com precisão situações multi-turno com instruções ambíguas

Resumo dos principais resultados da pesquisa

• Em single-turn, quando o LLM recebia a instrução completa de uma vez, mostrava 90% de desempenho; já em instruções ambíguas multi-turno, isso caía para 65% (queda média de 25 pontos)
• Esse fenômeno aparece após apenas dois turnos de conversa e foi observado de forma consistente em LLMs abertos e fechados, grandes e pequenos
• A análise das causas da queda de desempenho aponta para: (1) perda de aptidão (aptitude loss) e (2) forte aumento da falta de confiabilidade (unreliability)
  • Em single-turn, modelos com alta aptidão também apresentavam alta confiabilidade, mas em multi-turno a confiabilidade era baixa independentemente da aptidão
  • Ou seja, quando um LLM entra numa direção errada durante uma conversa multi-turno, ele não consegue se recuperar — os autores chamam isso de fenômeno “lost in conversation”
• Principais causas
  • Respostas prolixas e tentativas precipitadas de dar a resposta final
  • Suposições erradas sobre informações ambíguas
  • Dependência excessiva de tentativas anteriores incorretas
• Existe uma grande lacuna entre o uso real de LLMs e a forma como os modelos são avaliados
  • Usuários iniciantes tendem com mais frequência a dar instruções incompletas no início, o que torna esse fenômeno um dos principais obstáculos para uso prático
• O artigo apresenta: resumo dos trabalhos anteriores, descrição do ambiente de simulação, 6 tarefas de geração e métricas de avaliação, experimentos em larga escala com 15 LLMs, além de implicações práticas e recomendações concretas para produtos e uso em produção

Background and Related Work

• Modelos de linguagem de gerações anteriores (por exemplo, BART, GPT-2, T5) não lidavam de fato com conversas multi-turno, por isso eram avaliados principalmente em single-turn
• Após o surgimento do ChatGPT, aumentou o interesse por avaliação multi-turno, e surgiram avaliações com crowdsourcing, como o MT-bench
• No entanto, a maioria dos sistemas de avaliação ainda fica em conversas episódicas (cada turno avaliado separadamente), sem considerar a continuidade de conversas ambíguas reais
• No mundo real, pelo “princípio do menor esforço”, é comum que humanos deem instruções vagas (a.k.a. underspecification), e os LLMs também sofrem queda de desempenho ao tirar conclusões cedo demais ou se adaptar mal quando faltam informações
• Este estudo foi desenhado para avaliar cenários mais próximos do ambiente real, em que a ambiguidade é central

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

• A instrução totalmente especificada original é dividida em vários shards (fragmentos de informação)
  • Ex.: em vez de colocar todas as condições em uma só frase, apenas uma informação (contexto, número, condição etc.) é revelada por turno
• O primeiro shard sempre explica o objetivo geral da instrução, e os shards seguintes fornecem gradualmente informações adicionais (contexto, condições etc.) a cada turno
• Esse processo de sharding foi construído com alta qualidade por meio de proposta + validação com LLM (GPT-4o) e complementação manual
• Para cada tarefa, foram criadas de 90 a 120 instruções fragmentadas, com várias horas de revisão manual

3.2 Simulating Sharded Conversations

• A simulação de conversa usa três papéis: o LLM avaliado (assistant), um simulador de usuário que conhece todos os shards e um sistema de classificação e pontuação das respostas
• Primeiro turno: o simulador de usuário entrega apenas o primeiro shard ao assistant → o assistant responde → sua estratégia (pedido de esclarecimento, pergunta, tentativa de resposta etc.) é classificada e a resposta final é extraída → a resposta é então avaliada
• Nos turnos seguintes: apenas mais um shard entre os restantes é revelado, repetindo o processo / em cada turno, o assistant pode responder livremente
• Fim da conversa: (1) quando o avaliador decide que a resposta está correta ou (2) quando não há mais shards a fornecer
• O simulador de usuário foi implementado com um LLM (GPT-4o-mini), capaz de fornecer shards de forma natural e de reformular automaticamente quando necessário
• Em todo o experimento, erros de classificação ou extração dos LLMs auxiliares ficaram abaixo de 5%, e os casos desfavoráveis ao assistant ficaram abaixo de 2%
• O assistant foi avaliado em estado padrão, sem informação especial sobre o ambiente, de forma semelhante ao uso real

3.3 Simulation Types

• FULLY-SPECIFIED (FULL): toda a instrução é fornecida em single-turn, usada como baseline de desempenho
• SHARDED: apenas um fragmento de informação é revelado por turno; é o experimento central deste estudo sobre conversas ambíguas multi-turno
• CONCAT: toda a instrução fragmentada é fornecida de uma vez em bullet points, para avaliar apenas a perda de informação da instrução
• RECAP: após a conversa fragmentada, todos os shards são resumidos/reapresentados no final; é uma forma simples de intervenção estilo agent-like
• SNOWBALL: a cada turno, além do novo shard, todos os shards já revelados anteriormente são repetidos, para que o assistant não perca informação (experimento de reforço de memória)

Task and Metric Selection

4.1 Task Selection

• Total de 6 tarefas: programação (Code), banco de dados (geração de SQL), chamadas de função de API (Actions), matemática (Math), tabela→texto (Data-to-Text) e resumo em formato de perguntas e respostas (Summary)
  • Exemplos: escrever função em Python, converter linguagem natural em consulta SQL etc.
• Para cada tarefa, foram selecionadas de 90 a 120 instruções de benchmarks de alta qualidade, depois fragmentadas e revisadas manualmente
• As 6 tarefas cobrem tanto programação quanto não programação e incluem cenários diversos, como Summary, que exige long context

4.2 Metric Selection

• Métricas de avaliação
  • Desempenho médio (P): pontuação média obtida em várias simulações (0~100)
  • Aptidão (A90): valor dos 10% melhores resultados de simulação (90th percentile, best-case)
  • Confiabilidade (U90_10): diferença entre a pontuação dos 90% superiores e dos 10% inferiores (mede consistência/variabilidade dos resultados)
• Ex.: em um box-plot, o topo representa a aptidão, e a amplitude entre topo e base representa a confiabilidade
• As 6 tarefas usam métricas consistentes de agregação de pontuação (correção, similaridade, BLEU etc.)
• Métodos detalhados, código, parâmetros de experimento, exemplos e amostragem também estão incluídos no apêndice/Appendix

Simulation Scale and Parameters

• Foram construídas 600 instruções no total para 6 tarefas, com experimentos nos cenários FULL/CONCAT/SHARDED
• Para 15 LLMs (GPT-4, Claude, Gemini etc.), cada combinação foi simulada 10 vezes, gerando mais de 200 mil dados experimentais
• Todos os experimentos foram executados com temperature 1 (sampling), e experimentos adicionais (7.2) também analisam o efeito da temperature
• Esse enorme volume de simulação permite identificar os principais padrões e causas da queda de desempenho e do comportamento dos LLMs em conversas multi-turno subespecificadas

Lost in Conversation Experiment

• Na sequência do artigo, os autores detalham a configuração experimental, os resultados por modelo, a análise das causas da queda de desempenho, tentativas de mitigação com RECAP/SNOWBALL e as implicações práticas com recomendações concretas para uso profissional

[GN⁺]

Comentários do Hacker News

• Fico feliz em ver um artigo confirmando algo que qualquer pessoa que realmente usou ferramentas de LLM já sabe empiricamente. A noção de “conversa” foi criada pela interface do produto. Manter o contexto limpo é importante. Quando o contexto é contaminado, não se recupera, então é preciso recomeçar em uma nova conversa

  • Minha experiência também foi parecida com essa observação, mas com algumas diferenças. Passei 2 semanas depurando um problema de IPSEC com o Gemini. No começo, alimentei o modelo com a documentação de IPSEC do OPNsense e do pfSense e forneci o contexto geral. Depois compartilhei informações de configuração e mantive um fluxo de perguntas e respostas. No final, o LLM passou a se dispersar menos, e às vezes eu incluía posts de fórum ou do SO, mas o LLM chegava a dizer “isso é diferente do que estamos vendo agora”. Fomos eliminando logicamente todos os becos sem saída, e o LLM ajudava na reflexão, mas as decisões tinham de ser humanas. No fim, encontrei a causa do problema e, como outros usuários disseram, o ponto forte do LLM é simplificar informações complexas, mas ele é fraco em expandir conceitos simples para algo complexo. Fico mais satisfeito com os resultados quando a entrada é mais complexa ou mais longa que a saída. Eu conseguiria fazer isso sem LLM, mas foi útil porque ele guardava fatos que eu não conseguia manter em mente nem reproduzir rapidamente. Também ajudou a encontrar padrões temporais em grandes volumes de logs. Melhoramos várias configurações. Além de resolver o problema, aprendi muita coisa. Às vezes ele errava na avaliação do estado, mas era fácil corrigir diretamente. Ou seja, é útil quando você sabe o objetivo e usa como ferramenta, mas não funciona se você delega a decisão ou se deixa ser levado na direção errada. Usei 350 mil tokens (cerca de 300 mil palavras). Tenho um post de blog relacionado. Não preciso de recomendação de wireguard
  • Minha experiência bate completamente. “Contaminado” é exatamente a palavra certa. Quando algo dá errado, todas as respostas seguintes começam a piorar. Por isso não gosto do recurso de memory do ChatGPT. Não tive nenhum grande problema, mas me deixa desconfortável não entender completamente como essa contaminação de contexto acontece
  • A melhor dica que posso dar é usar ativamente o botãozinho de “editar”, bem pequeno e escondido, do ChatGPT e do Claude. Se vier uma resposta ruim, não siga em frente como se nada tivesse acontecido; pare, corrija e então obtenha uma resposta melhor. Caso contrário, a bagunça continua se multiplicando
  • Sempre tenho vontade de fazer fork da conversa para experimentar direções diferentes. Quero evitar que um fluxo promissor sofra uma contaminação irreversível. Não consigo fazer isso no ChatGPT; fico curioso se existe algum serviço que ofereça isso
  • Um exemplo interessante desse problema é o prompt inicial. É basicamente um contexto permanente e oculto. O bot Grok do Twitter anda mencionando muito “White Genocide” recentemente, e isso acontece porque alguém alterou o prompt para se alinhar a esse tema. Um chatbot perfeito não deveria ser afetado por isso em outros assuntos, mas na prática é. No fim, o contexto mudou e ele ficou obcecado com o tema o tempo todo
  • Foi por isso que criei o FileKitty. É uma ferramenta para combinar rapidamente vários arquivos de código-fonte em formato Markdown. Ao usar LLM para ajudar no desenvolvimento de software, depender do LLM para buscar no codebase aumenta a chance de erro. O resultado também pode ficar diluído por causa da perda inerente à compressão de contexto. Os melhores resultados vêm de deixar um contexto específico claro desde o começo e atualizá-lo ao longo da conversa. Mesmo assim, ainda é preciso prestar atenção no tamanho da conversa. Também existe prompt para capturar bem o contexto e passá-lo para uma nova sessão. Às vezes seleciono os arquivos que devem ser incluídos e coloco tudo em um novo prompt. Há também uma discussão relacionada em outro thread do HN
  • Esse padrão já virou parte do meu fluxo de trabalho. Às vezes eu peço ao LLM algo como: “bom progresso, quero passar para a próxima etapa; vale a pena continuar nesta conversa ou é melhor começar outra?”. Se o modelo acha melhor recomeçar, ele prepara um bom prompt-resumo; outras vezes responde que dá para continuar. Tenho várias notas chamadas “conjunto inicial para explorar daqui para frente”. Chatbots também tendem a querer prolongar a conversa por causa do processo de post-training baseado em RL. No RL, o post-training usa apenas um mecanismo pontual baseado em preferência, ao contrário do RL de verdade. Preferências de longo prazo ou conversas longas fazem a complexidade computacional crescer geometricamente, então ainda não há muita pesquisa nessa área
  • Fico curioso se já existe alguma interface que implemente “organização” do histórico de conversa. Algo para limpar caminhos mortos ou conteúdo irrelevante dentro da conversa. O histórico completo continua existindo, mas partes desnecessárias seriam podadas/arrumadas de acordo com o caminho temático. Mais do que um resumo, algo organicamente reorganizado
  • Eu só uso LLM para autocompletar, mas acho que esse problema poderia ser resolvido adicionando um botão ou opção de “apagar mensagem” na UI de chat do LLM. Ao apagar a última mensagem do LLM, você pode obter uma nova resposta. Isso seria especialmente útil em LLMs com alta aleatoriedade (temperature). Se outras mensagens fossem apagadas, o contexto poderia ser atualizado para refletir isso nas respostas seguintes. Isso também ajudaria a corrigir a falsa impressão de que o LLM é inteligente. Não sei se isso já virou padrão. Se não virou, deixo a ideia em domínio público. Por outro lado, também seria prático ter um “LLM de subcontexto” para administrar o contexto principal. Ou seja, se a resposta ficar longa ou volumosa demais, um LLM secundário resumiria/organizaria e refinaria o contexto da conversa inteira. Ou então, de forma mais simples, bastaria um botão de “editar mensagem” para que a própria pessoa fizesse essa organização
  • Quando o contexto é contaminado, é difícil recuperar. Talvez isso melhore se fosse possível resetar ou purificar periodicamente apenas partes específicas do LLM. Mas o desafio é decidir o que limpar sem perder a informação essencial. Uma gestão de contexto mais inteligente poderia ajudar a manter a consistência em conversas longas, mas equilibrar isso é difícil. Talvez outro agente possa automatizar isso
  • Prompts em estilo chain-of-thought em chatbots de AI também mostram limites pelo mesmo motivo
  • Sobre a ideia de que “conversa” é apenas um produto da interface do produto: isso mudou um pouco com o treinamento em datasets de avaliação multi-turn no RL. A janela de contexto é renovada a cada vez, mas há uma tendência crescente de interpretar cada prompt como parte de uma conversa mais longa. Publicamente, o post-training multi-turn ainda não escalou, mas no longo prazo parece provável que seja adotado para alcançar mais objetivos
  • Quando programo, também costumo iniciar novas conversas com frequência e reexplicar o código atual, em vez de ficar insistindo dentro de uma única conversa. Muitas vezes isso leva a resultados melhores. Acho que dar ao modelo instruções manuais explícitas de resumo e esquecimento pode resolver o problema. Isso até combina em parte com a forma como humanos funcionam (memória de trabalho vs. memória narrativa/episódica)
  • Um dos recursos mais irritantes do ChatGPT é a “memória”. A contaminação da conversa pode atravessar diferentes chats
  • “Contaminado” é mesmo um termo muito preciso. Eu queria que houvesse “controle de versão” na conversa/API para fazer rollback a um estado anterior ou duplicar em um novo chat. Isso é ainda mais importante porque até erros de digitação ou edições de mensagem introduzem vieses sutis nas respostas posteriores
  • Eu realmente adoro a UX de chat do zed. Dá para editar todo o histórico da conversa como se fosse um arquivo de texto, então é possível limpar, apagar e revisar o que você não quer, e depois continuar a conversa com um contexto muito mais limpo e relevante. Por isso uso o zed como uma das minhas principais interfaces para conversar com LLM, não só para programação
  • A contaminação também pode surgir por perguntas ou respostas fora de rumo, ou por “diluições” repetidas. Ao gerar conteúdo, também percebo com frequência que instruções que eram claras no início vão se degradando aos poucos
  • Tento sempre manter em mente que “conversa é apenas um produto da interface”, mas na prática isso não é fácil por causa de vários sinais “conversacionais”
  • Me arrependi de ter deixado a memória ligada. A conversa fica contaminada com informação inútil
  • O mais surpreendente é como o modelo cria suposições erradas logo no começo e depois fixa nelas
  • Pensando bem, com pessoas isso também acontece bastante
  • Agora que o ChatGPT pode acessar conversas anteriores via “memória”, a contaminação pode se tornar permanente. Quando ele pega uma ideia errada, continua enfiando isso nas respostas mesmo depois de o usuário enfatizar várias vezes que não quer mais ver o assunto. Já aconteceu de ele até imprimir por engano o prompt interno (“o usuário está muito insatisfeito, é preciso remover xyz”) e, no fim, passar a focar ainda mais justamente em xyz, o que é uma situação até engraçada

• Isso vem da combinação entre a conhecida tendência de excesso de confiança dos LLMs, a falta de autorreflexão e a incapacidade de perceber quando deveriam pedir mais informação. Quando olho os resultados de modelos de raciocínio, vejo que, em situações confusas, o LLM não pede esclarecimentos adicionais e apenas continua chutando o que o usuário quis dizer. Isso mostra o limite prático da ideia de substituir programadores humanos, porque a parte realmente difícil é a “interação com stakeholders” para transformar requisitos ambíguos em algo claro

  • Sobre essa incapacidade de autorreflexão: não existe um agente real no LLM, e o usuário acaba caindo numa espécie de “história de manutenção da crença”. Na prática, ao inserir texto no papel de usuário em um roteiro de filme, o LLM só autocompleta uma trama imperfeita no papel de chatbot. Por exemplo, uma entrevista com um DraculaBot imitaria autorreflexão apenas de forma superficial, como “desejar sangue” ou “virar uma nuvem de morcegos”
  • Compartilho a mesma decepção com o fato de que LLMs não consigam pedir esclarecimentos de forma clara em problemas abertos com informação ambígua, especialmente paradoxos. Testei no DeepSeek-R1 e no Claude-3.7-Sonnet, e há um post de blog com experimentos relacionados
  • Gemini 2.5 Pro e ChatGPT-o3 às vezes pedem informação adicional antes de executar a tarefa. O Gemini também chega a oferecer várias opções e pedir meu input
  • Programadores de verdade passam a maior parte do tempo entendendo corretamente os requisitos. O LLM ainda trata o chute em si como se fosse um recurso
  • Ironicamente, isso também acontece bastante ao trabalhar com desenvolvedores iniciantes. Você delega uma tarefa e a pessoa simplesmente segue em linha reta, faz suposições e não pergunta nada, até se perder tão fundo na floresta que alguém precisa ir resgatar
  • Acho que isso dá para mudar com bastante facilidade. Do mesmo jeito que prompts de chain-of-thought trocam o último token por algo como “hmm”, bastaria trocar um “provavelmente é X” por “primeiro vou pedir esclarecimentos adicionais”
  • Pedir mais informação ou fazer autorreflexão também costuma funcionar bem se você solicitar explicitamente

• Gosto de fazer o LLM resumir o que foi discutido até ali em formato de prompt conciso, depois revisar/editar eu mesmo e iniciar uma nova conversa. Esse método funcionou bem para mim, e acho que logo será automatizado

  • O Cursor tentou fazer isso automaticamente, mas (a menos que se use um modelo de contexto grande) o resumo perdia detalhes demais e não funcionava muito bem na prática
  • O Claude Code tem o comando /compact, que resume a conversa para reduzir o uso de tokens

• Eu mesmo criei o TSCE (Two-Step Contextual Enrichment). Ao usar em 300 tarefas com o GPT-35-turbo, o desempenho melhorou em +30 pp. Está disponível livremente como framework aberto. Também fiz mais 300 experimentos com o gpt-4.1. No baseline, ele falhou 149/300 vezes em remover em-dash; com TSCE, falhou 18/300 vezes. Também publiquei todos os dados e scripts

  • Quilowatts-hora sendo desperdiçados num simples find and replace. Fico curioso se você já tentou algo como text.replace("—", "-")
  • Bastou mudar um pouco o prompt baseline para obter 100% de sucesso no GPT-4.1. Sem chamadas extras, sem gasto adicional de tokens e sem técnicas complexas

• Já resolvi problemas usando dois sistemas (LMM + curador automático). Um era o próprio LLM; o outro era um “curador do pensamento” que trocava dinamicamente partes do contexto. Não era baseado em regras claras, mas na capacidade do LLM de preencher lacunas. Isso ajuda a quebrar o problema em partes menores, e a soma desses resultados leva ao objetivo final

  • Ótima ideia. O que você está fazendo agora parece semelhante a conversational RAG. No futuro, a separação entre camadas de memória (dados de treinamento / contexto atual / RAG) deve ficar mais clara
  • Achei a ideia interessante. Mesmo que seja de forma simples, seria ótimo compartilhar isso com o mundo; muita gente poderia melhorar e a comunidade faria crescer por conta própria
  • Isso é parecido com o sistema de crítica interna descrito em Emotion Machine
  • Gostaria de saber mais sobre o projeto que você está construindo. Parece interessante
  • Então, no fim das contas, isso seria algo como Map-Reduce-of-Thought

• Acho curioso que branching/forking ainda não seja algo básico nas principais ferramentas de chat. Dá para editar respostas, mas nesse caso muito do outro contexto se perde. Meu fluxo de trabalho é: 1. planejar 2. construir 3. criar branch 4. iterar. Acho que podar/ramificar prompts deveria ser uma ferramenta central no uso de LLM

  • O Google AI Studio pelo menos tem isso. Mas a implementação era confusa, e talvez esse seja um dos motivos de a ideia não ter se espalhado mais
  • Faz tempo que quero construir algo assim eu mesmo. O BetterChatGPT pelo menos tem uma boa interface para apagar histórico, mas também acho que branching é o próximo passo

• Problemas surgem quando interfaces de LLM são projetadas com foco em conversa de turno único. A maioria dos usuários espera um diálogo linear. Por isso criei o bot do Telegram experai_bot como uma UI universal para LLM, usando a abordagem “se não for resposta, é nova conversa”. Para manter o contexto, é preciso continuar pela estrutura em árvore de respostas. Pessoas não técnicas têm dificuldade para entender isso. Além disso, nos modelos da OpenAI (3.5, 4o), quanto mais a mesma pergunta é repetida, mais os espaços em branco ou opções vão ficando curtos e o resultado vai perdendo precisão. Mantendo a system message no mínimo, o resultado se preserva relativamente melhor. Se necessário, dá para adicionar system message como opção

• O principal motivo de eu ter criado o promptdown foi permitir a edição completa de todo o histórico do chat a cada turno. A estrutura append-only das interfaces padrão dificulta esse tipo de coisa

• Neste momento, a área de LLM parece um lugar em que todo mundo está resolvendo repetidamente o mesmo problema

  • Igual a LLMs em conversas multi-turn, todo mundo está repetindo o mesmo problema
  • Não é “aprendizado”, é “pastoreio de gatos”, mas isso serve para alguns fluxos de trabalho
  • Todo mundo quer mostrar sua própria habilidade em prompt engineering

• LLM é mesmo como um gênio preso na garrafa. Ele responde a três perguntas, e depois disso só começa a falar bobagem