- Los chatbots conversacionales de largo plazo tienen dificultades para reflejar de forma estable los puntos clave de interacciones pasadas en sus respuestas, incluso con ventanas de contexto largas, y este estudio aborda cómo reducir los problemas de consistencia con una memoria de resumen recursivo
- El procedimiento central consiste en crear una memoria inicial a partir de una conversación corta y luego, cada vez que se agrega una sesión, actualizarla resumiendo juntos la memoria previa y la nueva conversación para generar una memoria más reciente
- Los métodos basados en recuperación dependen de un recuperador capaz de encontrar con precisión los enunciados pasados necesarios, y los métodos tradicionales basados en memoria pueden ver afectada la calidad de respuesta por información desactualizada que no se ha actualizado
- En experimentos con LLM públicos y privados como Llama, ChatGLM y OpenAI GPT-3.5-Turbo, tanto la evaluación automática como la humana mostraron una consistencia superior en conversaciones largas frente a enfoques previos
- Este método también puede usarse junto con ventanas de contexto largas o LLM reforzados con recuperación, por lo que puede ser una opción práctica para manejar contextos conversacionales muy extensos sin simplemente aumentar sin control la longitud total de la conversación
La memoria de conversaciones largas requiere algo más que contexto largo
- LLM como GPT-4 y ChatGPT pueden mantener conversaciones dinámicas y adecuadas al contexto sobre diversos temas, pero en conversaciones largas pueden perder información pasada y generar respuestas inconsistentes
- Aunque una ventana de contexto larga permita procesar como entrada todo el historial de conversación, la capacidad de comprender interacciones pasadas e integrar la información clave en la respuesta sigue siendo limitada
- Casos representativos donde se necesita recordar conversaciones pasadas incluyen acompañantes personales de IA y servicios de asistencia en salud
- Un acompañante personal de IA necesita recordar conversaciones previas para construir una relación
- Un servicio de asistencia en salud debe considerar todo el historial de consultas del paciente para ofrecer resultados de diagnóstico
- En un ejemplo del Multi-Session Chat Dataset, cuando el usuario volvió a mencionar el tema pasado de “composición musical” unas 20 intervenciones después, la versión ChatGPT gpt-turbo-3.5-0301 respondió que era “un modelo de lenguaje de IA sin una profesión en el sentido tradicional”, generando una respuesta inconsistente con su persona anterior
Límites de los enfoques basados en recuperación y en memoria
- Los enfoques representativos para fortalecer la capacidad de conversación de largo plazo se dividen en métodos basados en recuperación y métodos basados en memoria
- Los métodos basados en recuperación guardan enunciados pasados en un repositorio y usan un recuperador para encontrar el historial más relevante para la conversación actual y aprovecharlo en la generación de la respuesta
- Tienen la limitación de que es difícil obtener un recuperador ideal que capture por completo el significado necesario para la conversación actual
- Los métodos basados en memoria almacenan información clave resumiendo conversaciones pasadas con un modelo entrenado aparte o con un LLM potente
- Si falta un mecanismo de actualización iterativa, la información desactualizada preservada puede perjudicar directamente la calidad de la respuesta
- MemoChat reconstruye el historial de conversación pasado por tema del hablante y usa prompts para que el LLM recupere desde una memoria estructurada durante la generación
- MemoryBank propone un mecanismo de memoria que primero crea un resumen de cada sesión de conversación y luego lo comprime en un resumen global
- Si la memoria almacenada queda completamente fija, es difícil garantizar consistencia con la conversación en curso
Generación de memoria actualizada de forma recursiva
- El método propuesto es un enfoque simple tipo plugin en el que el propio LLM crea resúmenes y sigue actualizando y revisando el contexto pasado para almacenar información en tiempo real del hablante
- El procedimiento se compone de tres pasos
- Un LLM generativo recibe como entrada un contexto corto de conversación y genera un resumen inicial
- Después combina la memoria previa con conversaciones posteriores para ir actualizando continuamente un nuevo resumen o memoria
- El chatbot usa la memoria más reciente como referencia principal para responder a la conversación actual
- Como los resúmenes generados son mucho más cortos que toda la conversación, es posible manejar contextos muy largos a lo largo de varias sesiones sin aumentar de forma costosa la longitud máxima de entrada
- La conversación de largo plazo se define como un Multi-Session Dialogue compuesto por varias sesiones
- Se usan el conjunto de sesiones pasadas
S = {S1, S2, ..., SN}, el contexto conversacional de la sesión actualCty la respuesta objetivort - El objetivo es generar una respuesta relevante y altamente consistente a partir de las sesiones pasadas y el contexto actual
- Se usan el conjunto de sesiones pasadas
- La memoria
Mies la memoria disponible al final de la i-ésima sesión, y todo el proceso se define como un proceso secuencial en el que cada memoria depende solo de la sesión actual y de la memoria anterior
Iteración de memoria y generación de respuestas
- El método propuesto asigna dos tareas a cualquier LLM
- Iteración de memoria: resumir recursivamente la información clave siguiendo el flujo de una conversación larga
- Generación de respuestas basada en memoria: combinar la memoria más reciente con la conversación actual para generar una respuesta adecuada y consistente
- La iteración de memoria es el proceso mediante el cual el chatbot obtiene un resumen consistente y actualizado para usarlo
- Algunos trabajos previos actualizan la memoria aplicando a los resúmenes “operaciones duras” como replace, append y delete
- Este enfoque depende de conversaciones de alta calidad etiquetadas con operaciones, interfiere con la consistencia semántica del resumen y no es adecuado para la gestión a largo plazo
- El método propuesto introduce juntos el contexto de conversación y la memoria previa para que el LLM genere recursivamente la memoria o el resumen
- Aprovechar el resumen anterior permite que el modelo procese mejor el contexto conversacional actual y produzca una memoria de alta calidad
- En el ejemplo, después de la primera sesión se crea una memoria inicial y, tras la segunda, se integra en la memoria previa una nueva información de personalidad: “el bot se unió recientemente a un nuevo gimnasio abierto las 24 horas”
Resultados experimentales y posibilidades de aplicación
- Los experimentos se implementaron con LLM públicos y privados de última generación como Llama, ChatGLM y OpenAI GPT-3.5-Turbo
- El desempeño en conversaciones largas fue superior al de enfoques populares previos tanto en evaluación automática como en evaluación humana
- Se verificó la efectividad de usar memoria explícita en conversaciones largas, así como que la memoria generada con este método es más fácil de procesar para los LLM
- Al combinarlo con aprendizaje en contexto (ICL), la calidad de respuesta puede mejorar aún más
- Se presentan al LLM varios ejemplos con formato
(conversación, memoria, respuesta correcta) - Esto permite que el LLM use la memoria generada con mayor flexibilidad
- Se presentan al LLM varios ejemplos con formato
- En text-davinci-003, la puntuación BLEU mejoró alrededor de +3%
- El método propuesto complementa LLM con ventanas de contexto largas como GPT-3.5-Turbo-16k y LongLoRA-8k, y LLM reforzados con recuperación como LLM-BM25 y LLM-DPR
- El código público está disponible en qingyue2014/Rsum
1 comentarios
Opiniones de Hacker News
Todas las formas de acumular memoria en el “espacio de texto” se sienten bastante hacky
Para preservar por completo el significado del modelo, parece más natural guardarlo en un espacio de embeddings denso que usar un procedimiento añadido que regenera resúmenes continuamente
Además, el modelo debería entrenarse para reconocer y usar la memoria y, de ser posible, creo que convendría que aprendiera en esa configuración desde el principio
Al final se le pide que agregue una palabra más a una conversación dada y, cuando en algún momento emite un token de finalización, la aplicación vuelve a ceder el control al usuario
Creo que el espacio latente y el espacio de texto no están tan lejos como parece. Los LLM son bastante torpes, pero muy buenos para hablar; con escribir código pasa algo similar: lo hacen bien, pero se derrumban en áreas que requieren pensamiento abstracto real, como las matemáticas
Estos hacks en el espacio de texto en la práctica suelen funcionar bastante bien, y por eso se volvieron comunes prompts como “piensa paso a paso”
LoRA está más cerca de la dirección mencionada, y es excelente para comprimir mucha comprensión en muy pocos datos. Pero ajustar pesos para una sola conversación todavía no es realista, así que para ese uso se está explorando el espacio de texto
Resumir algo en tu cabeza puede sentirse “hacky”, pero creo que una gran parte de cómo funciona realmente la memoria se parece a eso
https://news.northwestern.edu/stories/2012/09/your-memory-is...
Según entiendo, los embeddings son esencialmente algo cercano a una compresión con pérdida. Con un resumen de texto, al menos el agente puede verificar si ese resumen representa con precisión la información original
En CodeRabbit ya usamos este método para revisiones incrementales de PR y conversaciones en el contexto de cambios de código
Hace que el bot parezca tener mucho más contexto del que realmente tiene, y es uno de varios trucos que usamos para escalar la revisión de código con IA incluso a PR grandes (más de 100 archivos)
Para cada commit resumimos el diff por archivo, luego creamos un resumen de los resúmenes, y lo actualizamos incrementalmente cada vez que se agregan commits al PR. Este resumen de resúmenes se guarda oculto dentro de los comentarios del PR y se usa al revisar cada archivo o responder preguntas de usuarios
Parte del código es open source, y el prompt relacionado que usamos para el resumen recursivo está aquí: https://github.com/coderabbitai/ai-pr-reviewer/blob/main/src...
[0]: coderabbit.ai
Si es así, también me pregunto si han probado usar function calling en lugar de parsear una salida de texto libre
Si están en la etapa de “el código y los scripts se publicarán más adelante”, ya es difícil creer cualquier afirmación
Puede ser verdad o puede ser una tontería, pero si no hay una forma barata de reproducir el experimento, veo estos papers como algo que los autores escribieron para poner en su currículum
Llevo más de 6 meses esperando papers del campo de los LLM que dicen “el código se publicará más adelante”, pero no hay señales de que realmente vaya a publicarse. Incluso algunos papers tienen el descaro de incluir enlaces rotos que llevan a dominios estacionados
Ya es hora de que la comunidad reconozca adecuadamente esta práctica de no publicar el código
Hace un tiempo experimenté con una idea parecida tocando prompts directamente desde el dashboard de la API; tenía potencial, pero no parecía valer lo que costaba la API. Probablemente el enfoque de embeddings vectoriales sea mucho mejor
Como caso personal, en mi empresa tenemos miles de “Briefings”, que son paneles presenciales de una hora o a veces de todo el día
Logramos resumir cada briefing con éxito, y transcripciones desordenadas quedaron bien organizadas como un resumen de cinco párrafos
La parte más relevante es que clasificamos cada briefing en temas y subtemas con una relación 1:N. Decenas de briefings quedaron agrupados por tema y una docena por subtema; luego volvimos a resumir subconjuntos de resúmenes relacionados y lo probamos ampliamente, con resultados muy buenos usando LLM
Al principio era escéptico sobre si esto funcionaría, pero funcionó muy bien. Si hubiéramos tenido una ventana de contexto lo bastante grande no lo habríamos hecho así, pero por suerte no fue un problema
Creo que dividir el problema como MapReduce funciona mucho mejor que meter todo en una enorme ventana de contexto de 32k y hacer que lo resuelva de una sola vez
Hace unos meses probé crear una memoria de resumen recursivo con un modelo open source, y al implementarla de forma ingenua, a menudo se quedaba atrapada para siempre en ciertos temas.
Porque algunos fragmentos sobrevivían a todas las rondas de resumen.
Es imposible reducir cualquier bloque de texto a un bloque de texto más pequeño sin perder nada de información.
Si eso fuera posible, implicaría compresión infinita, y cualquier dataset debería poder reducirse a 1 bit y luego reconstruirse perfectamente. Pero no se puede.
Al comprimir una conversación en un resumen, necesariamente se pierde parte de la información. Por más tuning, plegado o métodos ingeniosos que se usen, fundamentalmente habrá pérdida de información.
Además, como el proceso es recursivo, en algún momento se vuelve a resumir un conjunto de resúmenes, y ahí también se pierde cierta cantidad de información.
Así que puede ayudar en casos triviales, pero meter resúmenes recursivos en el prompt parece bastante tonto, y si se le pide hacer algo realmente útil, casi seguro que no va a funcionar bien. Cuando no se usa mucho el resumen recursivo, parece funcionar porque se pierde poca información, pero al usarlo de verdad es muy probable que sus límites aparezcan rápido.
Si pensamos en lo fácil que es que la mente humana se salga de curso solo por traumas o procesos de desarrollo, se nota lo cargada de esperanza que está la idea de una IA parecida a los humanos.
El paper me decepciona un poco. Prácticamente no hay detalles sobre la técnica; solo hay tablas que dicen que con la metodología que usaron obtienen buenos resultados.
Sé que esto es común en la ciencia actual, pero para un desarrollador que trabaja con LLMs el paper tiene muy poco valor. Claro, la reputación académica de los autores subirá un poco, y parece bastante probable que ese haya sido el objetivo.
Me dan ganas de escribir un par de papers así. Me pregunto cuántos tendría que escribir para poder poner el título “ML researcher” arriba de todo en mi CV.
Deberían haber dedicado mucho más tiempo a los ejemplos y al prompt.
Ya escribí algo parecido hace unas semanas, pero la gente está simplificando demasiado la parte de resumen: https://news.ycombinator.com/item?id=37117515
El valor de la memoria de largo plazo tiene matices distintos según el caso de uso.
Si estás creando un asistente para el hogar, necesitas identificar nombres con NER, entender qué tono prefiere esa persona cuando le envías mensajes, y comprender lugares y formas de traslado.
Si estás creando un bot de soporte al cliente, necesitas identificar consultas que derivaron en conversaciones largas o consultas que terminaron en un abandono repentino del carrito.
Con un nivel de resumen general alcanza para hacer demos vistosas, pero para construir un producto realmente útil hoy hay que ir un paso más allá.
No tengo claro qué hay de nuevo aquí.
El resumen de memoria de historial de chat basado en LLMs es una técnica conocida que ya está implementada en muchos frameworks de LLM. Si se resume en cada mensaje como en el paper, se convierte en un gran cuello de botella de rendimiento y agrega una latencia considerable al loop de chat.
Muchas implementaciones usan un buffer de tamaño fijo y van resumiendo progresivamente los grupos de memoria antiguos que salen del buffer. Idealmente, ese trabajo también se procesa fuera del loop de chat.
Soy uno de los autores de Zep, un repositorio open source de memoria de largo plazo, y nosotros implementamos los resúmenes de esta manera.
0: https://github.com/getzep/zep
https://github.com/paul-gauthier/aider/blob/main/aider/histo...
https://www.deeplearning.ai/short-courses/langchain-for-llm-...
Aunque se desvía un poco del artículo y la discusión, la memoria corta sí es una limitación real.
Dicho eso, creo que la mayoría de las críticas a las capacidades de GPT-4 se aplican igual, o incluso con más fuerza, a los humanos.
En una situación de test de Turing inverso, no creo que una persona viva pudiera convencerme de que es GPT-4. Solo por sus respuestas rápidas y ordenadas, GPT-4 supera ampliamente la capacidad humana.
Incluso si un equipo de humanos pudiera tomarse 60 minutos para responder cada pregunta, quizá le costaría seguir el ritmo de las respuestas de GPT-4 a consultas interesantes. Sería una competencia divertida.
La implementación del paper básicamente agrega el texto de memoria como parte del prompt.
Me pregunto por qué no usan un sistema de almacenamiento y búsqueda que no consuma tokens de la ventana de contexto. Por ejemplo, al guardar, es decir, cuando entra el prompt del usuario, se podrían clasificar automáticamente los datos con tags, y al buscar, hacer una consulta filtrada por los tags que el LLM estime antes de responder.
Tengo la intuición de que con solo unas pocas reglas iniciales, como nombres o estilos de tags hardcodeados, se podrían obtener resultados bastante buenos.