Nota de laboratorio · Agosto 2026
Nuestro benchmark nos mintió. Un script de 40 líneas lo demostró.
Por qué ahora verificamos el prompt en vez de los contadores. Los resultados tendrán su propio artículo, cuando las cifras estén congeladas.
En un día y una noche construimos algo que queríamos desde hacía meses. Octave Engine es la capa de compresión de memoria multi-resolución de Mnemosyne OS. La misma memoria existe en varios tamaños. El motor elige el tamaño cuando inyecta la memoria en el contexto del modelo.
Su regla cabe en cuatro palabras: Proyección, nunca paráfrasis. Cada forma comprimida está hecha de extractos literales de la fuente, con sus offsets de caracteres exactos. Una búsqueda de substring demuestra que nada fue inventado. Un resumidor puede redondear una fecha o mejorar una frase. Para un producto que vende memoria auditable, ese resumidor es un mentiroso con buenas intenciones.
Más de dos mil tests unitarios siguieron en verde todo el tiempo. Luego pusimos el motor en el banco. Un arnés A/B enfrentaba un brazo de control a un brazo de proyección, sobre un corpus de preguntas de memoria a largo plazo. Un juez LLM puntuaba las respuestas, y todo quedaba registrado. Los deltas dibujaron una forma. Escribimos en el documento de diseño una regla sobre cuándo activar el motor. Creíamos haber medido.
Entonces el fundador hizo una pregunta, casi de pasada:
«Verifica el código. No solo los tests detrás de los tests.»
La revisión adversarial del código
Entregamos el diff completo a revisores adversariales. Su consigna: no compruebes que funciona; intenta demostrar que no funciona. La misma mente escribió el código y los tests. Así que los tests tenían los mismos puntos ciegos. Solo unos ojos frescos y hostiles los encuentran.
Uno de sus hallazgos lo paró todo.
Nuestro arnés daba al pipeline filas de memoria «congeladas», ya recuperadas. En el brazo de proyección, reescribíamos esas filas en memoria con el texto comprimido. Pero el constructor del prompt no lee las filas en memoria. Relee cada fila por su hash, directamente desde la base de datos. Es un patrón de caché razonable. Así descartaba en silencio nuestra copia modificada y releía el original.
Los dos brazos enviaban desde el principio prompts idénticos byte a byte.
Todos nuestros deltas venían de la varianza del juez y del modelo. Nuestra regla tan cuidada se apoyaba en ese ruido. El ruido había tomado la forma de nuestra hipótesis.
Por qué nunca lo vimos
Si haces evaluaciones de LLM, esta parte te resultará familiar.
Los registros del arnés estaban llenos de actividad real: entradas proyectadas, caracteres ahorrados, contadores de repliegue en marcha. Nada era fabricado. La proyección comprimía de verdad. Pero nada llegaba al prompt. El instrumento medía su propio esfuerzo en lugar de su efecto.
Un registro lleno de actividad no prueba que el trabajo llegue al juez. La plausibilidad también nos engañó. Cuando el ruido dibujaba un patrón, sabíamos explicarlo, con apoyo de la literatura. Una explicación plausible no prueba nada.
La temperatura cero tampoco te protege. El modelo de respuesta y el modelo juez son casi deterministas, y los dos «casi» se suman. Con muestras pequeñas, producen diferencias que parecen descubrimientos.
La prueba de 40 líneas
El arreglo del arnés fue pequeño. El arreglo de nuestro método importa más, y puedes reutilizarlo.
Antes de cada run de evaluación pagado, un script de control toma una fila de memoria. Sustituye su contenido por una cadena-marcador. La pasa por el camino exacto que monta el prompt del benchmark. Luego verifica ambas direcciones:
- Con el arreglo, el marcador debe aparecer en el prompt final. El brazo llega de verdad al artefacto.
- Por el camino antiguo, el marcador no debe aparecer. El bug era el que pensábamos.
El script tiene unas cuarenta líneas. Corre antes del primer token de juez. Si falla, la campaña no empieza.
Nuestra regla: un experimento A/B solo existe cuando se ha demostrado que los brazos difieren en el artefacto final. La config, los logs y los contadores no bastan. Lo que cuenta es lo que ve el modelo.
Qué hicimos con las campañas invalidadas
Las campañas invalidadas siguen en el documento de diseño. Están tachadas, con sus tablas intactas, junto a las corregidas. Los resultados negativos también siguen ahí, cada uno con la causa de su fallo. Un cuaderno de investigación que solo guarda los éxitos se convierte en un folleto.
Después volvimos a medirlo todo con el instrumento probado. Esas cifras son reales. Se publicarán aparte, congeladas, con sus tamaños de muestra y sus reservas.
Un motor diseñado a tres voces
Octave nació de una conversación a tres voces. Un humano tenía la intuición inicial y la última palabra. Un ingeniero-compañero de IA trabajaba en el código. La asistente integrada en Mnemosyne OS revisaba los diseños con su memoria del proyecto.
Un resumen de la sesión de trabajo entró en la memoria del OS. Minutos después, la asistente lo usaba para proponer los siguientes experimentos. Cuando las cifras quedaron invalidadas, también quedó invalidada una parte de esa memoria. La corrección es una nueva crónica, que reemplaza a la anterior sin borrarla.
Esta memoria se audita y se corrige a la vista de todos. Construimos el producto como trabajamos. Esta semana, nuestra forma de trabajar se puso a prueba primero.
Mnemosyne OS es una aplicación de escritorio para Windows, macOS y Linux. Descargar Mnemosyne OS