Aplicaciones de IA con capacidad de agencia

Lo que aprendimos al evaluar la memoria de los agentes: los resultados (Parte 2)

Lectura de 9 minutos

Esta es la segunda parte de una evaluación de dos partes sobre la Memoria de Agentes de Couchbase. Si no ha leído la Parte 1, los puntos de referencia, las métricas y la arquitectura del canal están explicados allí. Esta parte describe lo que sucedió cuando realmente realizamos los experimentos. Nota: No todo salió como esperábamos.

Lo que intentamos y lo que sucedió

Formato de memoria: mensajes sin procesar frente a resúmenes

La primera variable que probamos fue si almacenar los turnos de conversación sin procesar o los resúmenes generados por LLM.

La intuición detrás de los resúmenes es razonable: las conversaciones son ruidosas, y un resumen limpio podría darle al recuperador una mejor señal. Los resúmenes también reducen significativamente el costo de tokens, pasando de aproximadamente 13,000 tokens a 6,200 para el mismo k en LME-S.

El resultado: los mensajes sin procesar superan en general a los resúmenes en los tres conjuntos de datos. En LME-S, los mensajes sin procesar obtienen una puntuación de 0.637 frente a 0.614 de los resúmenes. En LME-M, la brecha es mayor: 0.724 frente a 0.574. En LoCoMo, 0.826 frente a 0.675.

La explicación es la categoría SSA. Las preguntas del Asistente de Sesión Única (SSA) preguntan sobre algo que el asistente dijo en una sesión anterior y, a menudo, requieren una redacción exacta. La sumarización descarta los nombres propios, las recomendaciones específicas y las frases precisas. El SSA cae de 0,982 a 0,768 en LME-S al cambiar de mensajes sin procesar a resúmenes. En LME-M, cae de 0,946 a 0,714. En LoCoMo, algo específico como “una convención de tecnología para el bien” se convierte en “una convención” después de la sumarización, lo que rompe cualquier cadena de razonamiento que dependa de hacer coincidir esa entidad.

Los resúmenes no carecen de mérito. Mejoran las puntuaciones de SSP y MS porque comprimir información entre turnos reduce el ruido y facilita las conexiones entre sesiones. En cuanto a las preguntas de preferencia, la compresión tiende a revelar las señales de preferencia con mayor claridad. Y la reducción de tokens es real. Para implementaciones donde las preguntas de SSA están fuera del alcance, los resúmenes son una configuración viable. Para implementaciones donde los usuarios pueden preguntar sobre cosas que el asistente dijo anteriormente, o donde la coincidencia exacta de entidades importa, los mensajes sin procesar son necesarios.

Profundidad de recuperación (k) y tokens de contexto

En LME-S con la mejor configuración (Experimento 25), k=10 es óptimo; la puntuación J alcanza un máximo de 0,701 con una ventana de contexto promedio de 3 352 tokens. Con k=5, el modelo multisesión cae 31% porque es posible que la memoria relevante no se encuentre entre los cinco primeros resultados. Con k = 15, el recuento de tokens aumenta en 481 TP3T, mientras que la puntuación J disminuye en 31 TP3T; los recuerdos adicionales añaden ruido sin aportar señal. Con k = 30, la puntuación J cae a 0,653 y la latencia aumenta en aproximadamente dos segundos.

En LME-M, se necesita k=20. En LoCoMo, la recuperación de mensajes sin procesar se estanca alrededor de k=15 sin ninguna ganancia significativa a partir de k=20 o más.

Vale la pena examinar directamente los números de tokens de contexto. En k=5, el contexto promedio es de 1,688 tokens. En k=10, es de 3,352. En k=30, alcanza los 9,726. El salto de k=10 a k=30 triplica el costo del contexto y degrada el rendimiento. En el Experimento 7, k=10 con 6,782 tokens obtuvo una puntuación más alta que k=20 de la línea base con 13,087 tokens utilizando el mismo aviso. Más contexto no produce mejores respuestas. Más allá del punto óptimo, introduce ruido que al modelo le cuesta filtrar.

Anclaje temporal

El razonamiento temporal es la categoría más débil en todas las líneas base. En LoCoMo sin ninguna información de marca de tiempo, las puntuaciones temporales son de 0.103 en la línea base. El modo de falla es consistente: las conversaciones contienen expresiones de tiempo relativo (“ayer”, “la semana pasada”, “hace unos tres meses”), que se almacenan en la base de datos en algún momento y se recuperan semanas o meses después. Cuando el modelo lee “Fui al museo ayer”, resuelve “ayer” con respecto al reloj de inferencia (la fecha actual) en lugar de la fecha de la conversación original. El recuerdo se almacenó en febrero de 2026. La visita al museo fue “ayer”. El modelo concluye que la visita al museo fue en febrero de 2026.

Tres intervenciones produjeron tres resultados muy diferentes:

  1. Anteponga la fecha de la sesión original a cada recuerdo almacenado. Cuando se almacena un bloque de memoria, adjunte la fecha de la conversación de la que proviene. Al recuperarlo, el modelo puede leer “Sesión del 7 de mayo de 2023: Ayer fui al grupo de apoyo LGBTQ” e interpretar correctamente “ayer” como el 6 de mayo de 2023. En LoCoMo, este único cambio eleva el razonamiento temporal de 0.103 a 0.738, lo que representa aproximadamente una mejora de 7 veces en un experimento.
  2. Agrega “Hoy es {question_date}” al aviso de respuesta. Proporcionar al modelo un anclaje explícito de cuándo se está haciendo la pregunta es el cambio de mayor impacto en LME-S: la puntuación J general aumenta de 0.571 a 0.637 sin ninguna otra modificación. Las puntuaciones temporales saltan de aproximadamente 0.18 a 0.263, la mayor ganancia en una sola categoría de cualquier intervención en ese punto de referencia.
  3. Filtrar rígidamente los recuerdos futuros. Este enfoque parece lógico: si una pregunta se hizo en octubre, los recuerdos de noviembre deberían ser irrelevantes. En la práctica, degrada el rendimiento. La caída temporal de LME-S es de 0.538 a 0.398. Los recuerdos futuros frecuentemente contienen resúmenes de sesiones y señales contextuales que ayudan al modelo a comprender el arco de los eventos que condujeron a la fecha de la pregunta. Eliminarlos elimina el fundamento en lugar del ruido.

Reemplazar la clasificación por relevancia con un ordenamiento basado en la actualidad produce una degradación similar. En general, la J cae a 0.554, el TR a 0.346 y el MS a 0.361. Las puntuaciones de relevancia ya codifican información temporal; un recuerdo de la semana pasada que es topicalmente relevante para la consulta se posiciona más alto que un recuerdo de ayer que no lo es. Anular la relevancia con la actualidad pura descarta el componente semántico.

reordenamiento BM25

Realizamos tres experimentos de reordenamiento *post-hoc* con BM25 utilizando diferentes tamaños de conjunto inicial: recuperar 10 y luego reordenar a 10, recuperar 50 y luego reordenar a 10, y recuperar 100 y luego reordenar a 10. Los resultados fueron inequívocos: conjunto=10 obtuvo 0,635, conjunto=50 obtuvo 0,615 y conjunto=100 obtuvo 0,589.

Cuando el grupo inicial es pequeño, la búsqueda vectorial ya ha realizado el filtrado semántico y BM25 agudiza la precisión de las palabras clave dentro de ese conjunto filtrado. Cuando el grupo se expande a 100, la relevancia promedio de los resultados vectoriales iniciales disminuye, y BM25 termina sustituyendo buenos recuerdos recuperados semánticamente por otros que coinciden con las palabras clave de la pregunta pero que en realidad no son relevantes. El grupo de 100 tiene un rendimiento peor que no usar reordenamiento en absoluto.

La búsqueda híbrida en el momento de la consulta, que combina similitud de vectores, BM25 y extracción de entidades en una sola llamada de búsqueda de texto completo (FTS) de Couchbase, es un enfoque diferente con contraprestaciones distintas. La ganancia más clara se dio en el razonamiento temporal: la búsqueda puramente vectorial fallaba frecuentemente en nombres de eventos específicos o fechas cuando la redacción de la pregunta difería del texto de la memoria almacenada. “¿Hace cuántas semanas asistí a la venta de amigos y familiares de Nordstrom?” puede hacer surgir un recuerdo sobre “Recientemente compré botas en el Viernes Negro de Macy's” porque son temáticamente adyacentes y el embebido vectorial promedia todo el turno de la conversación. La búsqueda híbrida con extracción de entidades hace coincidir “venta de amigos y familiares de Nordstrom” como una entidad nombrada directamente, sin importar la redacción circundante. La contraprestación es la precisión multisesión: la coincidencia de palabras clave hace surgir recuerdos del tema correcto pero potencialmente de la sesión equivocada, y al modelo le puede costar determinar la versión de qué sesión es la autorizada.

La matriz de interacción

Ninguna de estas decisiones es independiente.

Los resúmenes mejoran el SSP y el MS, a la vez que degradan el SSA. La ordenación por recencia ayuda al SSP y al mismo tiempo colapsa el TR y el MS. La reordenación BM25 con grupos grandes ayuda al SSP y perjudica al MS. La búsqueda híbrida mejora el SSU y el TR a la vez que aumenta la confusión entre sesiones del MS. Agregar una marca de tiempo al prompt mejora significativamente el TR con un efecto mínimo en el resto.

Cada decisión de diseño tiene efectos asimétricos entre los tipos de preguntas, y no existe una configuración universalmente óptima. Una puntuación general única oscurece esta estructura por completo. La matriz de interacción es el resultado más útil para tomar decisiones de diseño informadas. La configuración correcta depende de qué tipos de preguntas importan más para una aplicación determinada.

Resultados

En LoCoMo, Couchbase Agent Memory alcanza una puntuación LLM de 82,31 TP3T. La mayor mejora se observa en la categoría Temporal (72,31 TP3T frente a 48,31 TP3T), lo que refleja directamente el trabajo de anclaje de marcas de tiempo. La categoría «Multi Hop» es la más sólida en términos absolutos, con 90,21 TP3T.

En LME-S con gpt-4o-mini, Logramos un 69,41 TP3T en total. Las diferencias entre las distintas categorías concuerdan con la matriz de interacción; existen configuraciones que mejorarían el SSP y el TR, pero a costa de sacrificar las ventajas en SSA y MS. En LME-S con gpt-4o, alcanzamos un total de 75,91 TP3T. 

En LME-M, alcanzamos un total de 65,31 TP3T con 1,5 millones de tokens por problema. No existe ninguna comparación publicada conocida a esta escala; estos son los primeros resultados reportados en LME-M. La recuperación en una sola sesión es casi perfecta (SSA con 94,61 TP3T, SSU con 92,91 TP3T), lo que confirma que la recuperación funciona bien cuando la respuesta se encuentra dentro de una sola sesión. Las categorías más difíciles (MS con 48,91 TP3T, TR con 45,11 TP3T, SSP con 40,01 TP3T) reflejan el costo de la expansión del espacio de búsqueda por 20.

Lo que aprendimos

El hallazgo principal es que la recuperación de memoria de los agentes tiene un espacio de diseño distinto al RAG de documentos, y la configuración adecuada depende de la distribución de los tipos de preguntas y la escala del pajar. Vale la pena señalar esto claramente porque el campo tiende a evaluar bajo los supuestos del RAG.

Del proceso experimental surgieron varias observaciones más amplias.

La metodología de evaluación da forma a los resultados tanto como lo hace el diseño del sistema. El prompt del juez no es un instrumento de medición neutral. Tiene sesgos hacia respuestas más largas, la verbosidad sobre la precisión y la cercanía de temas sobre la exactitud factual. Cambiar de juez altera las puntuaciones entre 5 y 10 puntos. Usar el mismo juez en todos los experimentos dentro de un estudio es un requisito mínimo para obtener resultados interpretables. Comparar puntuaciones entre estudios que utilizaron diferentes jueces no es válido.

La optimización para pequeños pajares no se transfiere a escala de producción. El valor óptimo de k a escala LME-S es 10. A escala LME-M, es 20. Las variantes de instrucciones que encabezan la evaluación comparativa pequeña rinden por debajo de lo esperado en la grande. Los sistemas ajustados exclusivamente en evaluaciones de pajar pequeño pueden estar mal configurados para la escala en la que se despliegan realmente.

El anclaje temporal es un problema concreto y solucionable. La mejora de aproximadamente 7 veces en la recuperación temporal de LoCoMo a partir de un solo cambio en el momento de la ingesta, al anteponer las fechas de las sesiones a los recuerdos almacenados, es el hallazgo más procesable del estudio. Este modo de fallo es invisible en pruebas comparativas sin preguntas temporales y consecuente en producción cuando los usuarios hacen preguntas relativas al tiempo. La solución tiene un costo insignificante y debe aplicarse por defecto.

La suficiencia del contexto separa los problemas de recuperación de los problemas de razonamiento. Sin ella, una puntuación J deficiente podría indicar que se recuperaron los recuerdos incorrectos, que no se recuperó ningún recuerdo o que se recuperaron los recuerdos correctos pero el modelo no los usó. Estas situaciones requieren diferentes intervenciones. La suficiencia del contexto hace que esta distinción sea explícita.

El modo de falla temporal dominante es estructural. En el caso de los fallos temporales 55%, el problema radica en la recuperación: la formulación de la pregunta difiere de la forma en que se almacenó el evento, la representación promedia demasiado ruido en un turno de conversación extenso y el recuerdo correcto queda oculto en los resultados de la clasificación. La vinculación a marcas de tiempo y la búsqueda híbrida reducen la frecuencia de este fallo, pero no lo eliminan. Los enfoques que extraen representaciones estructuradas de los eventos en el momento de su ingesta abordan la causa raíz de manera más directa. Vale la pena explorar esto más a fondo.

La mayoría de los equipos que construyen sistemas de memoria para agentes realizan evaluaciones en pajares pequeños, confían en una única puntuación general y tratan el problema como una versión más difícil de RAG. Esta evaluación argumenta que las tres suposiciones son incorrectas. Los modos de fallo son específicos. El espacio de diseño es real. Y la configuración correcta solo se revela a la escala donde las cosas realmente se rompen. La pregunta que vale la pena hacer es: si nunca probaste tu sistema a escala de producción, ¿sabes realmente si funciona?

Compartir este artículo

Autor

Deja un comentario

¿Listo para comenzar con Couchbase Capella?

Comenzar a construir

Visita nuestro portal para desarrolladores para explorar NoSQL, consultar recursos y comenzar con los tutoriales.

Usa Capella gratis

Empieza a usar Couchbase en tan solo unos clics. Capella DBaaS es la forma más fácil y rápida de comenzar.

Ponte en contacto

¿Quieres saber más sobre las ofertas de Couchbase? Permítenos ayudarte.