Los LLM se pierden en conversaciones de varios turnos

• Los modelos de lenguaje grandes (LLM) muestran una caída de rendimiento y una menor confiabilidad en conversaciones de múltiples turnos
• En comparación con un solo turno, se confirmó experimentalmente una caída promedio del 39% en escenarios multiturno
• Los factores principales son una pequeña disminución de aptitud y una fuerte caída de confiabilidad, es decir, falta de consistencia en los resultados
• Los LLM tienden a hacer suposiciones incorrectas desde etapas tempranas o a intentar llegar a la respuesta final demasiado pronto
• Como resultado, si un LLM se equivoca al inicio de la conversación, se observó que no logra recuperarse y pierde el rumbo

---

ABSTRACT

• Los modelos de lenguaje grandes (LLM), como interfaces conversacionales, tienen el potencial de ayudar a definir, explorar y corregir gradualmente los requisitos mediante conversaciones de múltiples turnos, incluso cuando el usuario no puede expresar completamente lo que necesita
• Sin embargo, aunque la mayoría de las evaluaciones de LLM se concentran solo en entornos de instrucción completamente especificada en un solo turno, el análisis de registros reales de conversación muestra con frecuencia el fenómeno de subespecificación (underspecification)
• En este estudio se comparó a gran escala el rendimiento de los LLM mediante simulaciones en entornos de un solo turno y multiturno (subespecificado)
• Como resultado, en los 15 LLM principales se observó una caída promedio del 39% en conversaciones multiturno, explicada por una ligera reducción de aptitud y una drástica caída de confiabilidad
• Se detectó que, si un LLM toma una ruta equivocada al principio de la conversación, después no logra recuperarse, pierde la dirección y vaga sin rumbo

Introduction

• Los LLM más recientes (por ejemplo, ChatGPT, Gemini, Claude, etc.) ofrecen interfaces capaces de mantener conversaciones de múltiples turnos
• Aunque el usuario no describa claramente todos los requisitos desde el principio, estos pueden concretarse gradualmente mediante un intercambio iterativo de preguntas y respuestas (subespecificado → refinado)
• En la práctica, muchos usuarios presentan requisitos ambiguos al inicio de la conversación, pero la mayoría de las evaluaciones se realiza solo en entornos de especificación completa en un solo turno
• Algunos trabajos previos intentan evaluar interacciones multiturno, pero a menudo tratan cada turno como un episodio independiente, por lo que subestiman el impacto de la ambigüedad frecuente en conversaciones humanas reales
• Para cerrar esta brecha, este estudio propone un entorno de sharded simulation (dividir la información en varias piezas y revelar solo una por turno) para simular con precisión situaciones de instrucciones ambiguas y conversaciones multiturno

Resumen de los principales hallazgos

• Cuando el LLM recibe toda la instrucción de una sola vez en un solo turno, mostró un 90% de rendimiento, pero en instrucciones ambiguas multiturno cayó a 65% (una disminución promedio de 25 puntos)
• Este fenómeno aparece después de apenas dos turnos de conversación y se observó de forma consistente en todos los LLM: abiertos, cerrados, grandes y pequeños
• El análisis de las causas de la caída de rendimiento apunta a (1) pérdida de aptitud (aptitude loss) y (2) un fuerte aumento de la falta de confiabilidad (unreliability)
  • En un solo turno, los modelos con mayor aptitud también mostraban mayor confiabilidad, pero en multiturno la confiabilidad es baja independientemente de la aptitud
  • Es decir, si un LLM toma una dirección equivocada durante una conversación multiturno, no puede recuperarse; a esto lo denominan fenómeno de “lost in conversation”
• Causas principales
  • Respuestas demasiado largas e intentos prematuros de dar la respuesta final
  • Suposiciones incorrectas ante información ambigua
  • Dependencia excesiva de intentos previos equivocados
• Existe una gran brecha entre el uso real de los LLM y la forma en que se evalúan los modelos
  • Cuanto más principiante es el usuario, más probable es que dé instrucciones incompletas al inicio, por lo que este fenómeno se vuelve uno de los principales obstáculos para la aplicación práctica
• El artículo presenta: resumen de investigaciones previas, descripción del entorno de simulación, 6 tareas generativas y sus métricas de evaluación, experimentos a gran escala con 15 LLM, y además implicaciones prácticas y recomendaciones concretas para productos y uso profesional

Background and Related Work

• Los modelos de lenguaje de generaciones anteriores (por ejemplo, BART, GPT-2, T5) en la práctica no podían responder a conversaciones multiturno, por lo que se evaluaban principalmente en un solo turno
• Tras la aparición de ChatGPT, creció el interés por la evaluación multiturno, y se realizaron evaluaciones crowdsourced como MT-bench
• Sin embargo, la mayoría de los marcos de evaluación sigue limitada a conversaciones episódicas (evaluación individual de cada turno), sin considerar la continuidad de las conversaciones ambiguas reales
• En el mundo real, siguiendo el “principio del mínimo esfuerzo”, es común que las personas den instrucciones ambiguas (a.k.a. subespecificación), y los LLM también sufren una caída de rendimiento por conclusiones prematuras ante falta de información y escasa adaptación
• Este estudio se plantea con el objetivo de evaluar escenarios más cercanos al entorno real, donde la ambigüedad es un factor central

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

• La instrucción originalmente completamente especificada se divide en varios shards (fragmentos de información)
  • Ejemplo: en lugar de incluir todas las condiciones en una sola oración, se revela solo una pieza de información por turno (contexto, cifras, condiciones, etc.)
• El primer shard siempre explica el objetivo general de la instrucción, y los shards posteriores van entregando gradualmente información adicional (contexto, condiciones, etc.) en cada turno
• Este proceso de sharding se construyó con alta calidad mediante propuesta+verificación con un LLM (GPT-4o) y complementación manual
• Para cada tarea se elaboraron entre 90 y 120 instrucciones fragmentadas (sharded instructions), revisadas manualmente durante varias horas

3.2 Simulating Sharded Conversations

• La simulación de conversación usa tres roles: el LLM evaluado (assistant), un simulador de usuario que conoce todos los shards, y un sistema de clasificación y puntuación de respuestas
• Primer turno: el simulador de usuario entrega solo el primer shard al assistant → el assistant responde → se clasifica su estrategia (aclaración, pregunta, intento de respuesta, etc.) y se extrae la respuesta → se evalúa esa respuesta
• Siguientes turnos: se revela solo uno de los shards restantes y se repite el proceso / en cada turno el assistant puede responder libremente
• Fin de la conversación: (1) cuando el evaluador determina que la respuesta es correcta, o (2) cuando ya no quedan shards por revelar
• El simulador de usuario se implementó con un LLM (GPT-4o-mini), con capacidad de entregar shards de forma natural y hacer rephrase automático
• En todo el experimento, los errores de clasificación o extracción de los LLM auxiliares fueron menores al 5%, y los casos desfavorables para el assistant fueron menos del 2%
• El assistant fue evaluado en estado predeterminado, sin información especial sobre el entorno (de forma similar a un escenario real, donde no se le da contexto adicional sobre la simulación)

3.3 Simulation Types

• FULLY-SPECIFIED (FULL): se entrega la instrucción completa en un solo turno; se usa como línea base de rendimiento
• SHARDED: se revela solo un fragmento de información por turno; es el experimento central del estudio sobre conversaciones multiturno ambiguas
• CONCAT: se entrega de una sola vez toda la instrucción fragmentada en formato de viñetas; sirve para evaluar solo la pérdida de información de la instrucción
• RECAP: después de la conversación fragmentada, al final se resumen o se vuelven a entregar todos los shards; una forma simple de intervención tipo agente
• SNOWBALL: en cada turno se agrega un nuevo shard y además se repiten todos los shards ya revelados, para que el assistant no pierda información; es un experimento de refuerzo de memoria

Task and Metric Selection

4.1 Task Selection

• Total de 6 tareas: programación (Code), bases de datos (generación de SQL), llamadas a funciones de API (Actions), matemáticas (Math), tabla→texto (Data-to-Text), y resumen tipo preguntas y respuestas (Summary)
  • Ejemplos: escribir una función en Python, convertir una consulta en lenguaje natural a SQL, etc.
• Para cada tarea se seleccionaron entre 90 y 120 instrucciones de benchmarks de alta calidad, y después del sharding se validaron manualmente
• Las seis tareas representan tanto escenarios de programación como de no programación, e incluyen distintos casos como Summary, que requiere contexto largo

4.2 Metric Selection

• Métricas de evaluación
  • Rendimiento promedio (P): puntuación media obtenida en varias simulaciones (0~100)
  • Aptitud (A90): valor del 10% superior de los resultados de simulación (percentil 90, mejor caso)
  • Confiabilidad (U90_10): diferencia entre el 90% superior y el 10% inferior de las puntuaciones (mide consistencia/variabilidad de resultados)
• Ejemplo: en un box-plot, la parte superior representa la aptitud y el rango entre arriba y abajo representa la confiabilidad
• Las seis tareas agregan puntajes con métricas consistentes (correctitud, similitud, BLEU, etc.)
• Los métodos detallados, el código, los ejemplos, el muestreo y todos los parámetros experimentales también se incluyen en el apéndice/Appendix

Simulation Scale and Parameters

• Se construyeron un total de 600 instrucciones para 6 tareas, y se realizaron experimentos en los escenarios FULL/CONCAT/SHARDED
• Para 15 LLM (GPT-4, Claude, Gemini, etc.), se corrieron 10 simulaciones por cada combinación, generando más de 200 mil datos experimentales
• Todos los experimentos se realizaron con temperature 1 (muestreo), y en experimentos adicionales (7.2) también se analizó el efecto de temperature
• Con este enorme conjunto de datos de simulación fue posible identificar las principales causas y patrones de la caída de rendimiento y del comportamiento de los LLM en conversaciones multiturno subespecificadas

Lost in Conversation Experiment

• A continuación, el texto explica en detalle la configuración experimental, los resultados por modelo, el análisis de las causas de la caída de rendimiento, los intentos de mitigación (RECAP/SNOWBALL), y las implicaciones prácticas junto con recomendaciones concretas

[GN⁺]

Opiniones en Hacker News

• Me alegra ver un paper que confirma algo que cualquiera que haya usado herramientas LLM de verdad ya sabe por experiencia. El concepto de “conversación” fue creado por la interfaz del producto. Mantener limpio el contexto es importante. Cuando el contexto se contamina, no se recupera, así que hay que reiniciar con una conversación nueva

  • Mi experiencia también se parece a esta observación, aunque con algunas diferencias. Pasé dos semanas depurando un problema de IPSEC con Gemini. Al principio le hice leer la documentación de IPSEC de OPNsense y pfSense y le di el contexto general. Después compartí información de configuración y seguimos con preguntas y respuestas. Hacia el final, el LLM empezó a distraerse menos, y a veces metía posts de foros o publicaciones de SO, pero el LLM incluso decía “esto no coincide con lo que estamos viendo ahora”. Fuimos descartando lógicamente todos los callejones sin salida, y el LLM ayudaba con la reflexión, pero las decisiones las tenía que tomar una persona. Al final encontré la causa del problema y, como han dicho otros usuarios, el punto fuerte del LLM es simplificar información compleja, pero es débil para expandir conceptos simples hasta volverlos complejos. Quedo más satisfecho con el resultado cuando la entrada es más compleja o más larga que la salida. Podría haberlo hecho sin LLM, pero fue útil porque guardaba cosas que no habría recordado o reproducido rápido. También ayudó a encontrar patrones temporales en grandes volúmenes de logs. Mejoré varias configuraciones también. No solo resolví el problema, sino que aprendí mucho. A veces entendía mal el estado de la situación, pero era fácil corregirlo yo mismo. O sea, si conoces el objetivo y lo usas como herramienta, es útil; pero si le delegas las decisiones o dejas que te lleve por mal camino, no sirve. Usé 350 mil tokens (unas 300 mil palabras). Hay un blog post relacionado. No hace falta recomendar wireguard
  • Mi experiencia coincide por completo. “Contaminado” es justo la palabra correcta. Cuando algo sale mal, todas las respuestas posteriores empiezan a empeorar. Por eso no me gusta la función de memory de ChatGPT. No he tenido un problema grande, pero me inquieta no entender del todo cómo ocurre esa contaminación del contexto
  • El mejor tip que puedo dar es usar de forma agresiva el botón de “editar”, tan pequeño y escondido, en ChatGPT y Claude. Si sale una mala respuesta, no la dejes pasar; detente, corrígela y busca una mejor respuesta. Si no, el desastre sigue multiplicándose
  • Siempre me dan ganas de hacer fork de la conversación para probar distintas direcciones. Quiero evitar que un flujo prometedor sufra una contaminación irreversible. No puedo usar esa función en ChatGPT, y me pregunto si habrá algún servicio que sí la ofrezca
  • Un ejemplo interesante de este problema es el prompt inicial. Es un contexto oculto y prácticamente permanente. El bot Grok de Twitter últimamente menciona mucho “White Genocide”, y eso se debe a que alguien cambió el prompt para alinearlo con ese tema. Un chatbot perfecto no debería verse afectado en otros temas, pero en la práctica sí se ve afectado. Al final, el contexto cambió y quedó obsesionado con ese tema de forma constante
  • Por eso hice FileKitty. Es una herramienta para combinar rápidamente varios archivos de código fuente en formato Markdown. Cuando recibes apoyo de un LLM para desarrollo de software, depender del LLM para buscar dentro del codebase aumenta la posibilidad de errores. Los resultados también se diluyen por la pérdida implícita en la compresión de contexto. Los mejores resultados llegan cuando defines claramente cierto contexto desde el principio y lo vas actualizando durante la conversación. Aun así, hay que estar pendiente de la longitud de la conversación. También hay prompts que capturan bien el contexto y lo transfieren a una sesión nueva. A veces selecciono los archivos que hay que incluir y los pongo en un nuevo prompt. También se puede ver discusión relacionada en otros hilos de HN
  • Este patrón ya se volvió parte de mi flujo de trabajo. A veces le pido al LLM algo como “vamos bien, quiero pasar al siguiente paso; ¿vale la pena seguir en esta conversación o conviene empezar otra?”. Si el modelo dice que es mejor reiniciar, me prepara un buen prompt de resumen; otras veces responde que sí se puede continuar. Tengo varias notas llamadas “conjunto de valores iniciales para explorar después”. Hay una tendencia de los chatbots a querer seguir la conversación, por el proceso de post-training basado en RL y demás. En RL, el post-training usa solo mecanismos de preferencia de una sola pasada, no RL real. Las preferencias de largo plazo o las conversaciones largas aumentan exponencialmente la complejidad computacional, así que no se investiga tanto
  • Me pregunto si existe algún caso de una interfaz que implemente la “limpieza” del historial de conversación. Una función para ordenar las rutas muertas o el contenido irrelevante dentro del chat. Mantener el historial completo, pero podar u ordenar solo lo innecesario según la ruta temática. Más que un resumen, algo orgánicamente ordenado
  • Solo uso los LLM para autocompletado, pero creo que este problema se podría resolver si la UI de chat del LLM agregara un botón u opción de “borrar mensaje”. Si eliminas el último mensaje del LLM, puedes obtener una respuesta nueva. Es especialmente útil en LLM con alta aleatoriedad (temperature). Si borras otros mensajes, se debería actualizar el contexto para que se refleje en las respuestas posteriores. Eso también podría corregir la ilusión de que el LLM es inteligente. No sé si esto ya es estándar o simplemente no me he acostumbrado. Si no lo es, dejo la idea en dominio público. Por otro lado, también sería práctico tener un “subcontexto LLM” que gestione el contexto principal. O sea, cuando la respuesta es demasiado larga o extensa, un LLM secundario la resume/ordena y así afina el contexto de toda la conversación. O más simple todavía, un botón de “editar mensaje” para que una persona lo organice directamente
  • Cuando el contexto se contamina, es difícil recuperarlo. Tal vez mejoraría si se pudiera resetear o limpiar periódicamente solo ciertas partes del LLM. Pero el reto es decidir qué partes ordenar sin perder información clave. Una gestión de contexto más inteligente podría ayudar a mantener la coherencia en conversaciones largas, aunque es difícil equilibrarlo. Quizá otro agente podría automatizarlo
  • En los chatbots de IA, los prompts tipo chain-of-thought también muestran límites por la misma razón
  • Sobre la idea de que la “conversación” es solo un producto de la interfaz del producto: el entrenamiento con datasets de evaluación multi-turn en RL ha cambiado un poco la dirección de esto. La ventana de contexto es nueva cada vez, pero cada prompt tiende más a interpretarse como parte de una conversación más larga. Públicamente, el post-training multi-turn todavía no se ha escalado, pero a largo plazo parece probable que se adopte para lograr más objetivos
  • Incluso al programar, suelo empezar conversaciones nuevas con frecuencia y volver a explicar el código actual. Muchas veces eso da mejores resultados que seguir golpeando dentro de una sola conversación. Parece que el problema podría resolverse si se le explicita al modelo el resumen y el olvido mediante comandos manuales. Eso también coincide en parte con cómo funciona la mente humana (memoria de trabajo vs. memoria narrativa/episódica)
  • Una de las funciones más frustrantes de ChatGPT es “memory”. La contaminación de la conversación puede seguirte incluso entre chats
  • “Contaminado” es en serio un término perfecto. Ojalá hubiera “control de versiones” en la conversación/API para poder hacer rollback a un estado anterior o clonar en una conversación nueva. Más aún porque hasta un typo o la edición de un mensaje puede introducir un sesgo sutil en las respuestas posteriores
  • Me encanta el UX de chat de zed. Puedes editar todo el historial de conversación como si fuera un archivo de texto, así que puedes ordenar, borrar, modificar y complementar las partes no deseadas, y luego seguir con un contexto mucho más limpio y relevante. Por eso uso zed como una de mis interfaces principales para hablar con LLM incluso fuera de programación
  • La contaminación también puede venir de preguntas o respuestas fuera de lugar, o de una “dilución” repetida. Al generar contenido, también me pasa seguido que instrucciones que al inicio eran claras se van desdibujando poco a poco
  • Siempre trato de tener presente que “la conversación es solo un producto de la interfaz”, pero en la práctica no es fácil por las distintas pistas de estilo conversacional
  • Me arrepentí de haber dejado activada la memoria. La conversación se contamina con información inútil
  • Lo sorprendente es qué tan pronto el modelo se fija en una suposición equivocada
  • Si lo piensas, a las personas también les pasa mucho esto
  • Ahora que ChatGPT puede acceder a conversaciones anteriores mediante “memory”, la contaminación puede volverse permanente. Una vez que se engancha con una idea equivocada, aunque como usuario le recalques varias veces que no la vuelva a mencionar, sigue metiéndola en las respuestas. Incluso ha llegado a imprimir por error el prompt interno (“el usuario está muy molesto, hay que excluir xyz”), y eso termina provocando la situación absurda de que hable todavía más de xyz

• Esto viene de tendencias bien conocidas en los LLM: exceso de confianza, falta de autorreflexión e incapacidad de reconocer cuándo deberían pedir más información. Al ver los resultados de modelos de razonamiento, en situaciones confusas el LLM no pide aclaraciones adicionales y solo sigue adivinando qué quiso decir el usuario. Esto muestra los límites prácticos de la idea de reemplazar a los programadores humanos. La parte realmente difícil es la “interacción con stakeholders” para convertir requisitos ambiguos en algo claro

  • Sobre la incapacidad de autorreflexión: en un LLM no hay un agente real, y el usuario cae en una especie de “historia para sostener la creencia”. En esencia, si dejas texto de entrada con el rol de usuario en una especie de guion de película, el LLM solo autocompleta una trama incompleta en el rol de chatbot. Por ejemplo, una entrevista con Draculabot imita la autorreflexión solo superficialmente, como “ansiar sangre” o “convertirse en una nube de murciélagos”
  • Comparto la misma decepción con la incapacidad del LLM para pedir aclaraciones de forma explícita en problemas abiertos donde la información es ambigua (sobre todo paradojas). Lo probé con DeepSeek-R1 y Claude-3.7-Sonnet, y también hay un blog experimental relacionado
  • Gemini 2.5 Pro y ChatGPT-o3 a menudo piden información adicional antes de ejecutar una tarea. Gemini incluso presenta varias opciones y me pide elegir
  • Los programadores de verdad en realidad pasan la mayor parte del tiempo aclarando requisitos. El LLM todavía trata el acto mismo de adivinar como si fuera una funcionalidad
  • Irónicamente, con desarrolladores junior también pasa algo parecido. Les asignas una tarea y avanzan en línea recta, haciendo suposiciones sin preguntar nada, hasta que terminan perdidos tan hondo en el bosque que hay que ir a rescatarlos
  • Creo que esto se puede cambiar con bastante facilidad. Igual que en prompts de chain of thought se cambia el último token por algo como “hmm”, cuando el LLM está por decir “probablemente sea ~”, se podría cambiar el token por “primero pediré más aclaraciones”
  • Pedir más información o hacer autorreflexión también lo puede hacer bastante bien, si se lo pides

• Me gusta mucho la técnica de hacer que el LLM resuma lo discutido hasta el momento en formato de prompt conciso, luego corregirlo/editarlo yo mismo y empezar una conversación nueva. Me ha funcionado bastante bien, y creo que pronto se automatizará

  • Cursor intentó hacer esto automáticamente, pero (a menos que uses un modelo de contexto grande) el resumen perdía demasiados detalles y no servía mucho en la práctica
  • Claude Code tiene el comando /compact, que resume la conversación para reducir el uso de tokens

• Yo mismo ideé TSCE (Two-Step Contextual Enrichment). Al usarlo en 300 tareas con GPT-35-turbo, el rendimiento mejoró +30pp. Está disponible libremente como framework abierto. También hice 300 experimentos adicionales con gpt-4.1. El baseline falló 149/300 veces al eliminar em-dash, mientras que TSCE falló 18/300 veces. También publiqué todos los datos y scripts

  • Se están desperdiciando kilovatios-hora en una simple tarea de find and replace. Me pregunto si probaste algo como text.replace("—", "-")
  • Con solo cambiar un poco el prompt baseline, logré 100% de éxito en GPT-4.1. Sin llamadas adicionales, sin gasto extra de tokens ni técnicas complicadas

• He resuelto problemas usando dos sistemas (LMM + curator automático). Uno es el propio LLM, el otro es un “curador del pensamiento” que reemplaza y administra dinámicamente partes del contexto. No se basa en reglas claras, sino en la capacidad del LLM para completar huecos. Ayuda a dividir el problema en partes pequeñas para resolverlo, y luego esos resultados se juntan para alcanzar el objetivo final

  • Buena idea. Lo que haces ahora se parece a RAG conversacional. En el futuro probablemente estará más clara la separación entre capas de memoria (datos de entrenamiento / contexto actual / RAG)
  • Me parece una idea interesante. Aunque sea de forma simple, si la compartes con el mundo mucha gente podrá mejorarla y la comunidad la hará crecer por sí sola
  • Eso se parece al sistema de crítica interna que se menciona en Emotion Machine
  • Me gustaría saber más sobre el proyecto que estás haciendo. Se ve interesante
  • Así que al final sería algo como Map-Reduce-of-Thought

• Me sorprende que el branching/forking no sea algo básico en las herramientas principales de chat. Sí se pueden editar respuestas, pero en ese caso se pierde mucho del otro contexto. Mi flujo de trabajo es 1. planear 2. construir 3. ramificar 4. iterar. Creo que podar/ramificar prompts debería ser una herramienta clave para usar LLM

  • Google AI Studio al menos sí tiene esa función. Pero su implementación era confusa, y creo que eso puede ser una de las razones por las que no se ha difundido más
  • Desde hace tiempo he querido construir algo así yo mismo. BetterChatGPT al menos tiene una buena interfaz para borrar historial, pero yo también creo que el branching es el siguiente paso

• Cuando las interfaces de LLM se diseñan alrededor de conversaciones de un solo hilo, aparecen problemas. La mayoría de los usuarios espera conversaciones lineales. Por eso hice el bot de Telegram experai_bot como UI universal para LLM y usé el enfoque de “si no es respuesta, es conversación nueva”. Para conservar el contexto, necesariamente hay que continuar con una estructura en árbol de respuestas. A los no expertos les cuesta entender este enfoque. Además, en los modelos de OpenAI (según 3.5 y 4o), mientras más se repite la misma pregunta, más se acortan los espacios o las opciones y más inexactos se vuelven los resultados. Si se minimiza el mensaje de sistema, los resultados se mantienen relativamente mejor. Si hace falta, se puede agregar un mensaje de sistema mediante una opción

• La razón principal por la que hice promptdown fue permitir editar por completo todo el historial del chat en cada turno. La estructura estándar de “append-only” dificulta este tipo de cosas

• Da la sensación de que, en el estado actual del mundo LLM, todo el mundo está resolviendo los mismos problemas una y otra vez

  • Como los LLM en conversaciones multi-turn, todo el mundo repite el mismo problema
  • No es “aprendizaje”, es “arrear gatos”, pero para algunos flujos de trabajo eso encaja bien
  • Todo el mundo quiere presumir sus propias habilidades de prompt engineering

• Los LLM de verdad se sienten como un genio en una botella. Te responden tres preguntas, pero después de eso empiezan a decir puras tonterías