72,9 %, y las tres preguntas que fallamos
Nota, septiembre de 2026. Este artículo es la campaña de julio, puntuada por el juez flexible. El 28/09/2026, una fe de erratas corrigió las cifras de agosto a 35/48 (72,9 %) con el juez estricto. El resultado actual es una nueva ejecución cuyo protocolo se publicó antes de correrla: 77,1 % (37/48) en preguntas que el motor nunca había visto, con el juez oficial de LongMemEval (la página del benchmark). El lector, el motor y los jueces cambiaron desde julio, así que estas cifras no forman una progresión. Este artículo sigue publicado, con su protocolo y su composición admitida.
Hay dos formas de correr LongMemEval. La variante cómoda pone poca paja alrededor de la respuesta correcta. El full-haystack pone unas 480 sesiones distractoras alrededor de cada pregunta, unos 2 330 fragmentos de texto. Un solo dato importa entre todos ellos.
La cómoda es la que aparece en las comunicaciones.
Nosotros corrimos la otra. El resultado es 72,9 %. Lo publicamos como un suelo.
La cifra, y lo que cubre
| Medición | Antes | Después | Δ |
|---|---|---|---|
| Full-haystack, 48 preguntas, todos los motores | 64,6 % | 72,9 % | +8,3 |
| Multi-sesión (la categoría más dura) | 1/8 | 5/8 | +4 |
Ruta real executeQuery, 61 preguntas | 78,7 % | 83,6 % | +4,9 |
| Temporal, A/B en línea, reproducido dos veces | 7/10 | 10/10 | +3 |
Por qué «suelo»: las categorías conocimiento-de-usuario y sesión-simple nunca se volvieron a correr con el motor de consolidación completo. Nos faltó tiempo de cómputo. La campaña completa costó unas veinte horas de cómputo en dos días. Volver a correr esas dos categorías costaría otro tanto. La cifra publicada es, por tanto, una subestimación.
Para situar sin comparar productos: el paper de referencia mide GPT-4o con el contexto completo en torno al 60 %, en la variante más fácil.
El protocolo, porque la cifra no vale nada sin él
Sostuvimos tres reglas durante toda la campaña.
Los escritores están ciegos. Cada instrucción de consolidación dice «consolida este tema». Nunca «responde a esta pregunta». Las preguntas del benchmark jamás se ven en el momento en que se escribe la memoria. Sin esta regla mediríamos su capacidad de hacer trampa en lugar de su memoria.
Un acierto solo cuenta si se reproduce. Cada acierto se repitió dos veces antes de contarlo. En una pasada con seis éxitos brutos, dos resultaron ser ruido del juez. Se retiraron. El 6/8 exhibible se convirtió en el 5/8 que contamos.
Una sola configuración para todas. No elegimos ninguna pregunta a posteriori ni ajustamos nada por categoría. La configuración que da 72,9 % es la misma en las 48 preguntas.
Lo que funcionó, y por qué
La ganancia viene de un solo sitio: el momento de la escritura.
Con la máquina en reposo, el motor relee su propia memoria tema por tema y escribe un registro. El registro lista cada aparición, cada valor, cada fecha y el total acumulado. Se coloca al lado del texto bruto. El texto bruto se queda.
Dos detalles lo demuestran:
La misma pasada con un modelo más débil como escritor pierde el acierto. El lector no cambió. La ganancia venía, por tanto, de la escritura.
Y un tope de 40 temas en los registros lo mataba todo. Conservaba los temas distractores grandes y tiraba el fragmento que contenía la respuesta, ocho líneas perdidas en el ruido. Ningún filtro del lado de la respuesta podía recuperar eso. El dato había desaparecido.
Lo que refutamos
Estas mediciones no suelen aparecer en las comunicaciones. Deberían.
- Los registros de relaciones parecían plausibles. Probados, dan peor.
- La pasada maestra parecía plausible. Probada, da peor.
- La preclasificación k-means antes de consolidar da temas borrosos y no recupera ningún fallo.
- El barrido de reserva produce ruido y ninguna ganancia.
- Los números primos, medidos seis veces, no dan ninguna señal de memoria. Enterrados.
De ahí sale una regularidad, y vale más que los puntos ganados. Las dos palancas reales de la campaña salieron de un dato faltante rastreado hasta su posición exacta dentro de su fragmento. Las dos palancas refutadas salieron de un razonamiento plausible sin rastro. Desde entonces rastreamos primero y construimos después.
Las tres que fallamos
Tres preguntas fallan. Sabemos por qué en cada caso.
Dos son estructurales del benchmark. LongMemEval amontona a varios usuarios en una sola memoria. El proyecto de un desconocido se vuelve indistinguible del tuyo en el texto servido. Lo verificamos. La pasada de verificación los conserva, porque están en las fuentes. Ningún filtro del lado de la respuesta puede distinguirlos.
Pero Mnemosyne OS es soberano y de un solo humano. En una bóveda real solo hay una persona. Ese modo de fallo no existe. No perseguimos esos dos puntos. Ganarlos significaría optimizar para un artefacto del benchmark.
La tercera es nuestra deuda. Un tope de corpus trunca un tema demasiado denso, así que escribimos más de lo que releemos. Es un límite de ingeniería, no una decisión de diseño. Tiene ticket. Se corregirá.
Lo que no pretendemos
El documento que contiene estas cifras lista también lo que no está probado. Mantenemos esa lista al día:
Los puentes oníricos se crean, pero nadie ha medido si son relevantes o ruido. Así que no los vendemos.
La calidad de la clasificación por temas no está medida. La memoria se organiza. No pretendemos que se organice bien.
Y 359 pruebas unitarias en verde demuestran que unas funciones funcionan. No demuestran que valgan algo.
El atajo comercial sería decir «llegaremos al 100 %, el resto es por diseño». Ese atajo es falso en un tercio. Ese tercio es trabajo nuestro por hacer.
Lo que sí podemos decir: 72,9 % en el terreno más duro, publicado como un suelo, con el protocolo y los fracasos al lado.