Por qué los puntos de referencia de la memoria del agente engañan, y cómo evaluar con sus propios datos

Los benchmarks públicos para la memoria de los agentes no pueden indicar qué sistema es adecuado para un problema determinado, y varios ni siquiera pueden determinar con fiabilidad cuál sistema es mejor. La evidencia no es sutil: en el benchmark que todos citan, un método básico que incluye toda la conversación en el prompt supera a los productos especializados en memoria, según el propio artículo de un proveedor de memoria. Una auditoría independiente descubrió que alrededor del seis por ciento de las respuestas correctas de ese benchmark están equivocadas, y que su sistema de calificación automática acepta aproximadamente dos de cada tres respuestas incorrectas intencionadas. La respuesta sensata es dejar de elegir basándose en las clasificaciones y desarrollar una evaluación con datos propios.

Considere cómo suele elegir un equipo un sistema de memoria. Revisa la tabla de clasificación, toma lo que está en la cima y lo implementa. Tres semanas después de su puesta en producción, el agente comete un error grave respecto a una cifra que el usuario corrigió el martes pasado. Ha comenzado a contradecir una decisión tomada la semana anterior. La única información que necesitaba una consulta aparece clasificada por debajo de otras cuatro irrelevantes. El estudio de referencia lo había calificado como el mejor sistema del mercado, pero no mencionaba en absoluto el problema del propio equipo.

Debajo de esto surge una pregunta que surge tras cualquier implementación de sistema de memoria: ¿cómo se sabe si funciona? La respuesta poco satisfactoria es que las cifras a las que suelen recurrir los equipos no pueden responderla, y algunas ni siquiera sirven de mucho para nadie.

Un puesto en la tabla de clasificación indica que un sistema obtuvo buenos resultados en una prueba de otra persona, evaluada por otro juez, según la concepción que esa persona tiene de la respuesta correcta. No indica si su agente recordará lo que un usuario mencionó hace tres semanas. Esas son preguntas separadas, y solo una es la suya.

El punto de referencia que está considerando mide algo distinto

El resultado principal merece una reflexión. Tomemos la prueba de referencia más citada sobre memoria de conversación: un método que no utiliza sistema de memoria, que simplemente pega toda la conversación en el prompt y responde a partir de ella, terminó primero, ligeramente por delante de los productos especializados en memoria en la comparación. Ningún crítico señaló esto. Dicho método se presenta en el artículo detrás de una biblioteca de memoria bien conocida, Mem0, publicado en una revista revisada por pares, donde los autores indican que el contexto completo superó a su propio sistema en precisión bruta, con una latencia aproximadamente diez veces mayor por respuesta. Otro proveedor competidor cita el mismo hecho sobre ese artículo, por lo que no se trata de una interpretación unilateral.

Es menos vergonzoso de lo que parece, y es importante leerlo correctamente. Pegar todo resulta preciso porque no se omitió nada. Simplemente no es escalable debido al desbordamiento y al costo cuadrático. Por lo tanto, el benchmark, tal como se califica, recompensa sobre todo al sistema que mejor aproxima la precisión en contexto completo gastando menos tokens. Eso es útil para medir. Pero eso no es lo mismo que probar si un sistema puede recordar un detalle que el usuario proporcionó un mes antes; cualquiera que interprete la clasificación como lo segundo se ha dejado engañar por su propia suposición.

La verdad objetiva es aún más incierta. Una auditoría separada, pública y reproducible aunque no revisada por pares, analizó detenidamente las respuestas correctas del benchmark y encontró que alrededor del seis por ciento estaban erróneas: hechos inventados, razonamiento temporal defectuoso y respuestas atribuidas al hablante incorrecto. Cuando los auditores proporcionaron al sistema de calificación automática respuestas erróneas pero plausibles, este las aceptó en aproximadamente dos tercios de los casos. Existe una salvedad importante: los autores de la auditoría, Penfield, también desarrollan sistemas de memoria, por lo que no son neutrales. Sin embargo, el trabajo es reproducible, y los problemas pendientes en el propio repositorio del benchmark apuntan en la misma dirección, de modo que el problema es real incluso si se desestima a quienes lo informaron. La implicación es contundente. Un punto de referencia con una tasa de error del seis por ciento en sus pruebas no puede distinguir entre dos sistemas que difieren en menos del seis por ciento, y un evaluador que aprueba dos tercios de las pruebas basadas en suposiciones erróneas mide la confianza, no la corrección.

Tampoco coinciden las cifras de los fabricantes. Los dos fabricantes de memoria más conocidos publican resultados para el mismo punto de referencia que se contradicen entre sí, ya que cada uno volvió a ejecutar el sistema del otro y obtuvo un resultado que el otro cuestiona, dado que el resultado depende en gran medida de quién configuró la integración del otro. Una cifra principal que varía significativamente según la configuración es algo de marketing, no una medida real. Nada de esto significa que los sistemas sean malos; simplemente significa que una lista de clasificación no puede ordenarlos por usted, y ciertamente no para su área de aplicación específica.

Un contexto extenso no es memoria, y los puntos de referencia confunden ambas cosas

Una confusión silenciosa corrompe las comparaciones antes incluso de que comiencen. El contexto extenso y la memoria son cosas diferentes, pero muchas evaluaciones las tratan como un mismo eje. La búsqueda de una aguja en un pajar, en la que una oración está oculta en un documento largo y el modelo debe encontrarla, pone a prueba la atención ante una única entrada fija. Se trata de una prueba práctica sin respaldo teórico, solo un script ampliamente copiado. Un benchmark más riguroso, RULER, demostró que muchos modelos promocionados con ventanas de contexto enormes tienen un rango efectivo mucho más corto del que indican sus especificaciones. Ambos miden la capacidad, es decir, cuánto de una instrucción puede utilizar realmente el modelo.

La memoria significa continuidad entre sesiones. El lunes el agente recoge algo, la conversación termina y la ventana se limpia, y para el viernes debería seguir sabiéndolo. LoCoMo y LongMemEval, las pruebas de rendimiento relacionadas con la memoria conversacional, ejercitan ese ciclo de almacenamiento y posterior recuperación a lo largo de muchas sesiones, por lo que pertenecen a la misma categoría independientemente de sus defectos.

Dos capas para probar

Cuando las pruebas de rendimiento públicas no son suficientes, la alternativa es crear una propia, y la primera decisión en el diseño es decidir dónde dividirla. Hay que dividirla en dos. Una capa se encarga de la recuperación: ¿el sistema de memoria trajo de vuelta los datos correctos? La otra se ocupa de la respuesta: ¿el agente finalmente respondió o actuó correctamente? Ambas fallan de forma independiente, y una cifra de precisión integral promedia ambos resultados de manera que oculta qué fue lo que falló.

La división no es algo nuevo. El marco de código abierto RAGAS, mencionado en un artículo de 2024, se basa en ella, separando la capacidad del recuperador para encontrar contexto relevante de la capacidad del modelo para utilizar ese contexto de manera fidedigna. TruLens describe la misma idea como una tríada: relevancia del contexto para la recuperación, fundamentación para determinar si la respuesta deriva de lo recuperado, y relevancia de la respuesta para saber si se abordó la pregunta. Los nombres difieren, pero la división es la misma.

Son necesarias ambas capas, y esta es la parte que suelen omitir los equipos. Un buen recuperador de información aún puede dar una respuesta incorrecta, porque los datos correctos aparecen en el contexto y el modelo los ignora, razona mal o los mezcla con lo que ya creía. Por eso la solidez de las respuestas es una métrica por sí misma. Un mal recuperador de información también puede dar una respuesta correcta, ya que el modelo llena el vacío con su conocimiento paramétrico, y ese es el caso más peligroso. La puntuación de extremo a extremo muestra “correcto” mientras oculta que la capa de memoria no obtuvo nada útil, un fallo que se manifestará más tarde ante un hecho del dominio que el modelo simplemente no conocía. Medir solo la respuesta final no permite distinguir entre una memoria funcional y una simple suposición afortunada.

La recuperación de información merece métricas de clasificación, no la opinión de un LLM

La recuperación es la capa donde la aritmética puede realizar la puntuación, y la aritmética no tiene opiniones. Las métricas provienen de la recuperación de información clásica y tienen décadas de antigüedad:

• Recall@k es la proporción de hechos que deberían haber sido recuperados y que sí aparecieron entre los k primeros. Es útil cuando el modelo posterior tolera elementos distractores y la principal preocupación es que el hecho necesario esté presente.
• Precision@k es la proporción de elementos recuperados que resultaron relevantes. Es importante cuando el espacio de contexto es escaso y cada posición desperdiciada cuesta tokens o desvía al modelo de su objetivo.
• Mean reciprocal rank premia colocar el único hecho correcto en primer lugar, en casos de factoid donde solo cuenta el primer resultado.
• Beneficio acumulado descontado normalizado es adecuado para la relevancia graduada, donde el orden es importante porque el modelo da más peso al contexto anterior.
• Tasa de aciertos, que indica si apareció algo relevante o no, es un filtro básico y directo.

Elige el que mejor se adapte a la forma en que tu agente accede a su memoria.

Casi ningún equipo se da cuenta del siguiente punto, que podría ser el más útil aquí. Los marcos de evaluación populares como RAGAS, TruLens y DeepEval incluyen métricas denominadas recuperación de contexto y precisión de contexto, y es natural suponer que se trata de las métricas de clasificación mencionadas anteriormente. Pero no lo son. En la mayoría de estas herramientas, un evaluador basado en modelos de lenguaje lee los fragmentos recuperados y los califica, en lugar de compararlos con un conjunto etiquetado que indique qué hechos son realmente relevantes. Por lo tanto, un equipo que cree que está midiendo la calidad de la recuperación está, en realidad, pidiendo a un modelo de lenguaje que opine sobre la recuperación de otro modelo, heredando así todos los sesgos que tenga ese evaluador. Para obtener cifras reales se necesita un conjunto etiquetado que liste qué hechos almacenados son relevantes para cada consulta; una vez disponible, la recuperación@k y las demás métricas son simplemente cálculos numéricos. El verdadero esfuerzo radica en crear ese conjunto, y los marcos de evaluación permiten eludirlo. Eso explica por qué los números de recuperación honestos son escasos, mientras que los paneles que parecen rigurosos pero no lo son son comunes.

Cuatro verificaciones que la evaluación genérica de RAG omite

Si trata la memoria del agente como si fuera un pipeline RAG normal, solo evaluará la calidad de la recuperación y de la respuesta, y se detendrá allí. Eso deja de lado cuatro fallos propios de la memoria, que solo surgen porque esta persiste y cambia con el tiempo.

Coherencia. ¿Ha dicho el agente algo que choca con lo que le dijo al usuario anteriormente, o con su propia declaración anterior? La evaluación estándar de RAG no puede detectar esto, ya que cada consulta se evalúa por separado, pero una memoria que almacene dos hechos opuestos los presentará en días diferentes y parecerá incoherente. Es posible utilizar números. Un modelo NLI puede marcar una declaración posterior como contradictoria con una anterior, aplicándolo a toda la conversación y a lo que devuelve la tienda, lo que convierte la contradicción en una métrica a seguir en lugar de en una queja del usuario. Los conjuntos de datos creados para identificar un turno de diálogo que contradice a otro formalizan precisamente esta idea.

Recencia. Una vez que un hecho cambia, ¿la memoria devuelve el nuevo valor o el antiguo? LongMemEval (ICLR 2025) incluye el razonamiento temporal y las actualizaciones de conocimiento entre sus cinco capacidades probadas, por lo que se trata de una dimensión reconocida y no de un lujo. El diseño que funciona es bitemporal: un hecho registra cuándo se produjo en el mundo real y cuándo lo descubrió el sistema, y una actualización invalida la versión antigua mediante una marca de tiempo en lugar de sobrescribirla. Los sistemas de gráficos temporales como Graphiti y Zep funcionan de esta manera. La prueba es sencilla: después de una actualización, la consulta devuelve el nuevo valor, y el sistema aún puede indicar que el valor antiguo era verdadero anteriormente.

Abstención. Si un hecho nunca llegó a ser almacenado, ¿lo indica el agente o inventa algo? LongMemEval trata la abstención como una capacidad por sí misma, y con razón: una memoria que inventa es peor que una que admite una laguna, ya que lo que el cliente termina leyendo es la fabricación segura de información. Esta idea es anterior a la noción de memoria, y se remonta a una prueba de comprensión lectora de 2018 con preguntas deliberadamente sin respuesta. En este caso, la prueba es sencilla: se pregunta por algo que nunca fue almacenado; un sistema correcto no encuentra nada y rechaza la respuesta, mientras que uno defectuoso llena el silencio con información inventada.

Olvidar. En el caso de los datos que se supone deben desvanecerse o eliminarse, ¿realmente han desaparecido? El trabajo de “desaprendizaje” en máquinas proporciona el patrón para ello. TOFU, uno de estos puntos de referencia, divide los datos en un conjunto de olvido y uno de retención, y verifica no solo que el material olvidado no pueda ser accedido, sino también que sus vecinos permanezcan intactos. Las pruebas de memoria siguen la misma lógica: tras una eliminación, ese dato ya no puede ser recuperado ni inferido, mientras que los datos relacionados siguen existiendo. Esto no es lo mismo que la recencia. Sustituir un valor mantiene intencionadamente el antiguo en los archivos, mientras que una eliminación real, la tipo que exige una solicitud de privacidad, debe dejar sin rastro. Un sistema que solo invalida los datos pasa la prueba de recencia pero falla silenciosamente en una auditoría relacionada con el derecho a ser olvidado; solo una evaluación que distinga entre ambos casos podrá detectarlo.

Evalúa las respuestas con un juez, pero no dejes que defina la verdad

Las puntuaciones de recuperación se calculan mediante conteo. Por lo general, las respuestas no son viables para este método, ya que una respuesta correcta puede expresarse de muchas maneras, por lo que la mayoría de los equipos utilizan un LLM como juez. Esto funciona dentro de límites bien documentados que son fáciles de olvidar. El artículo de 2023 que estableció el uso del LLM como juez indicó que un juez eficaz coincidía con los evaluadores humanos en más del ochenta por ciento de los casos, lo que explica la popularidad de esta técnica. También detalló los modos de fallo: el sesgo de posición, en el que el juez favorece la respuesta que ve primero; el sesgo de verbosidad, en el que se premia la longitud en lugar del contenido; y el sesgo de auto-mejora, en el que el juez prefiere respuestas escritas en su propio estilo. Un estudio de seguimiento de 2024 aclaró este último punto de manera preocupante: un modelo puede reconocer su propia escritura, y cuanto mejor lo hace, más la prefiere. Otro artículo de 2023, G-Eval, demostró que la calificación de GPT-4 coincide razonablemente con la de los humanos, pero señaló el fallo más importante en este contexto: los evaluadores tienden a favorecer textos fluidos, seguros y bien estructurados. Esa es precisamente la forma de una respuesta errónea presentada con confianza, lo que permite que una memoria que suena correcta pero da un resultado equivocado pase desapercibida.

Utiliza al evaluador, pero restrínelo:

• Evalúa según una rúbrica basada en una respuesta correcta conocida en lugar de una pregunta abierta tipo “¿cuál es mejor?”, de modo que el evaluador verifique un hecho y no vote según su percepción subjetiva.
• Verifica con qué frecuencia coincide con muestras etiquetadas por humanos de tus propios datos, ya que un evaluador que discrepa de ti en tu área de conocimiento es un instrumento fuera de calibración.
• Neutraliza el sesgo de posición, como se hizo en el artículo original: intercambia el orden de los candidatos y calcula el promedio de los resultados.
• Considere la actualización a un modelo de evaluación como una migración del conjunto de herramientas de evaluación y no como una mejora automática. Las puntuaciones obtenidas con un modelo nuevo no son comparables con las del anterior, y un cambio silencioso modifica las cifras por razones que no tienen nada que ver con el sistema que se está probando.

Un modelo de evaluación es un instrumento para calibrar, no un oráculo al que hay que obedecer.

Construir el conjunto de pruebas con sus propios datos

Todo funciona a partir de un conjunto base: una colección congelada y etiquetada de casos de su propio dominio, donde cada entrada relaciona una consulta con los hechos que deben recuperarse y la respuesta que debe obtenerse. Funciona como un conjunto de pruebas de regresión, algo que debe seguir funcionando correctamente, adaptado a resultados no deterministas. Muchos equipos comienzan con unos pocos cientos de casos seleccionados manualmente. Ese rango es una regla práctica y no una ley, así que trátelo como un punto de partida que puede ampliarse.

Construir el conjunto no es la parte difícil; lo complicado es mantenerlo fiel a la realidad. Un conjunto dorado congelado deja de coincidir gradualmente con el tráfico real a medida que el producto, el corpus y los usuarios evolucionan, y un conjunto completamente verde basado en datos obsoletos genera una confianza falsa, la más costosa de todas. La solución es un ciclo: tomar los fallos del entorno de producción y incorporarlos al conjunto dorado como casos etiquetados recientemente, retirar aquellos que ya no reflejan la realidad, y así el conjunto seguirá al producto en lugar de ser una instantánea de su pasado. Los casos sintéticos pueden servir para iniciar la cobertura, y varios frameworks los generan, pero los casos creados automáticamente tienen las limitaciones del modelo que los desarrolló, por lo que sigue siendo necesario contar con un conjunto de referencia revisado por humanos.

La suite se ejecuta entonces en dos entornos, ya que el modo sin conexión y el en línea detectan errores diferentes. En modo sin conexión, comparando con el conjunto de referencia, controla los lanzamientos: de forma repetible y determinista, confirma que nada de lo ya conocido como funcional ha fallado. En línea, analizando datos reales muestreados, detecta cosas que un conjunto fijo nunca podría identificar, como cambios en la distribución, consultas inusuales de cola larga que nadie previó, y la lentitud acumulada que solo aparece tras semanas de estado acumulado. Un resultado verde en modo sin conexión indica que lo conocido está intacto; la monitorización en línea revela lo desconocido. Considere el primer caso como una señal para lanzar el producto, nunca como prueba de que funciona correctamente.

El costo y la latencia deben evaluarse en la misma métrica

El costo y la latencia son los aspectos que la mayoría de las evaluaciones omiten, pero son indispensables en el caso de la memoria. La memoria se encuentra en el camino crítico de cada turno, por lo que su latencia de recuperación, medida en p95 y no oculta en un promedio, determina la rapidez con la que el agente puede responder. Los tokens por turno constituyen todo el argumento económico: la memoria existe para utilizar menos tokens que al pegar toda la historia, así que una capa que consume más de lo que ahorra ha fallado en su propósito principal, incluso cuando la precisión es similar. El crecimiento del almacenamiento representa una regresión lenta que añade latencia y distracciones poco a poco cada semana, hasta que la recuperación se vuelve claramente peor, sin que ninguna prueba de precisión en un momento determinado haya señalado el problema. El costo del camino de escritura, es decir, el trabajo de extracción y conciliación, representa un cálculo real que las cifras de precisión no reflejan.

Una memoria debe construirse para lograr eficiencia y consistencia, y la evaluación es donde eso se demuestra. Una mayor precisión obtenida con medio segundo adicional en cada turno, a un costo superior al ahorro, no convierte a la memoria en mejor, pero un cuadro de puntuación con solo una columna de precisión sí lo indicará. Al incluir la latencia y el costo junto a la calidad, los compromisos se vuelven visibles en lugar de ser algo accidental.

Así es el equipo en la práctica

En términos abstractos, el equipo consta de dos capas, cuatro verificaciones de memoria, un juez calibrado, un conjunto de referencia actualizado a partir de la producción, y el costo indicado junto a la precisión. Dos bocetos muestran qué significa esto en la práctica.

Supongamos que una plataforma de gestión de patrimonios almacena su información como un grafo de conocimiento con unos pocos tipos de entidades y relaciones, alimentado por un proceso de extracción en varias etapas que asigna una puntuación de confianza del cero al uno a cada hecho. El equipo no lo evaluaría preguntando al modelo si las respuestas parecen buenas; en su lugar, probaría directamente la capa de recuperación contra un conjunto de documentos etiquetados en los que las entidades y relaciones correctas ya se conocen, de modo que la tasa de recuperación y la precisión son cifras concretas y no meras impresiones. La actualidad también sería objeto de una prueba deliberada: si un documento más reciente modifica algo que indicaba uno anterior, la consulta debe devolver el valor actualizado. La misma disciplina de puntuación para evaluar el grafo antes de que los agentes dependan de él se aplica también a la memoria de los agentes.

Supongamos ahora un sistema de análisis legal con un par de docenas de agentes, algunos que actúan como calificadores y otros como analistas, que comparten una tabla estructurada de puntuaciones en lugar de intercambiar transcripciones. La consistencia se convierte en una métrica fundamental, ya que un agente que contradice una puntuación establecida en el estado compartido representa un defecto medible y no simplemente una impresión subjetiva. El costo por turno se muestra en el mismo panel de control que la calidad, porque una capa de enrutamiento que determina qué agentes necesita realmente un documento y reduce significativamente las llamadas al modelo solo merece mantenerse si la evaluación muestra que la calidad se mantiene mientras el costo disminuye. Ninguno de los sistemas gana confianza al superar un punto de referencia; ambos lo logran mediante mediciones en sus propios datos, a través de las capas y verificaciones adecuadas para el trabajo que realizan.

Señales de que la evaluación es el cuello de botella

Algunos síntomas apuntan a la evaluación en sí y no al modelo, a la tienda de datos ni al sistema de recuperación:

• El sistema de memoria fue seleccionado de una lista de mejores resultados, y la producción sigue discrepando de su puntuación.
• La precisión de las respuestas de extremo a extremo es la única métrica, por lo que un fallo no puede atribuirse a un error en la recuperación de datos ni a que el modelo maneje mal los hechos recibidos.
• Las cifras de recuperación provienen de la métrica de recordatorio de contexto de un framework y no existe un conjunto etiquetado, lo que significa que un LLM ha estado evaluando la recuperación de datos y la considera una medida válida.
• El agente se contradice o proporciona datos obsoletos, y el conjunto de pruebas nunca lo habría detectado, ya que solo prueba consultas individuales e ignora la consistencia, la actualidad, la abstinencia y el olvido.
• Nadie sabe qué efecto ha tenido el último cambio en la memoria en la latencia o en el uso de tokens, ya que la precisión es la única columna que se registra.

Dado ese patrón, un modelo más potente o un recuperador más inteligente no resolverán la situación, porque lo que no se puede observar no se puede mejorar. La solución es el procedimiento riguroso: separar la recuperación de la respuesta, evaluar la recuperación con métricas de clasificación en un conjunto etiquetado, añadir las cuatro verificaciones de memoria, calibrar al evaluador en lugar de confiar ciegamente en él, actualizar el conjunto de referencia con datos reales de producción, e informar sobre el costo y la latencia además de la precisión.

Eso también cierra el argumento principal. Una ventana de contexto no es memoria. El almacenamiento creado en su lugar debe leerse mediante clasificación y no mediante búsquedas. El conjunto de trabajo frente al modelo debe gestionarse, no simplemente ampliarse, y la ruta de escritura debe consolidar en lugar de acumular. Todo esto necesita ser evaluado con los propios datos, abarcando la recuperación, la respuesta y las cuatro verificaciones que los benchmarks públicos omiten, teniendo en cuenta el costo y la latencia además de la precisión, porque una tabla de clasificación realmente no puede proporcionar lo que necesitas saber. Construye la memoria y su evaluación juntas, y sabrás, con cifras, si el agente recuerda. Omites la evaluación y te basas en las puntuaciones de un tercero para un problema que nunca fue suyo.

Leer más

• Optimizando un agente Terraform con DSPy: Construir el verificador antes que el optimizador — Los agentes Terraform inventan esquemas. Construya un verificador determinista, establezca una línea de referencia para el agente y luego utilice DSPy y GEPA para optimizar su archivo de habilidades, obteniendo resultados precisos.
• Forma de la ontología vs tamaño del modelo: Cuánto cuesta el diseño de un grafo a un agente de IA — Cómo tres formas sin pérdidas de un grafo de conocimiento de seguros cambiaron la precisión, las llamadas a herramientas, los tokens y el costo en modelos pequeños y grandes en Azure Cosmos DB.

Por qué la memoria de un agente de codificación debe contener solo el delta, y cómo almacenarlo — La memoria del agente debe registrar únicamente aquello que el modelo no pudo adivinar. Cuatro pruebas para cada entrada, tres requisitos para el almacenamiento, y por qué el markdown en git es adecuado.