Nota de laboratorio · Agosto 2026
Nuestro benchmark nos mintió. Esta es la prueba de 40 líneas que lo descubrió.
Instrumentos, ruido, y por qué ahora verificamos el prompt en vez de los contadores. Cifras retenidas; tendrán su propio artículo cuando las cifras estén congeladas.
Pasamos un día y una noche construyendo algo que queríamos desde hacía meses: Octave Engine, la capa de compresión de memoria multi-resolución de Mnemosyne OS. La idea cabe en una frase: la misma memoria, disponible en varios tamaños, elegida en el momento de inyectarla en el contexto de un modelo. Su regla fundacional cabe en cuatro palabras. Proyección, nunca paráfrasis. Cada forma comprimida que Octave sirve está hecha de extractos literales de la fuente, cada uno con sus offsets de caracteres exactos. Se puede probar, mecánicamente, por substring, que nada fue inventado. Para un producto que vende memoria auditable, un resumidor que podría redondear una fecha o mejorar una frase no es un motor de compresión. Es un mentiroso con buenas intenciones.
Así que lo construimos y lo probamos (más de dos mil tests unitarios se mantuvieron verdes todo el tiempo), y luego hicimos lo que hay que hacer: lo pusimos en el banco. Un arnés A/B sobre un corpus de preguntas de memoria a largo plazo, brazo de control contra brazo de proyección, un juez LLM puntuando respuestas, todo registrado. Llegaron los runs. Llegaron los deltas. Empezamos a ver una forma en ellos. Escribimos una regla sobre cuándo debía activarse el motor directamente en el documento de diseño, con la seguridad de quien ha 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 que se ganó el pan
Entregamos el diff completo a revisores adversariales con un único mandato: no comprobéis que funciona; intentad demostrar que no funciona. Los tests los había escrito la misma mente que el código, así que comparten sus puntos ciegos. Ojos frescos y hostiles son la única cura conocida.
Uno de los hallazgos acabó con la fiesta.
Nuestro arnés alimentaba el pipeline con filas de memoria «congeladas»: pre-recuperadas, y en el brazo de proyección, reescritas en memoria para llevar el cuerpo comprimido. Lo que se nos había escapado: en el fondo del pipeline, el constructor del prompt no se fía de las filas en memoria. Resuelve el contenido de cada fila por su hash, directamente desde la base de datos, un patrón de caché perfectamente razonable. Al hacerlo descartaba en silencio nuestra copia modificada y releía el original.
Los dos brazos llevaban todo el tiempo emitiendo prompts idénticos byte a byte.
Cada delta que habíamos visto (los que nos preocupaban, los que nos entusiasmaban, la regla tan cuidadosamente derivada) no era más que la varianza del juez y del modelo, disfrazada de nuestra hipótesis.
Por qué nunca lo vimos
Esta es la parte que debería preocupar a cualquiera que haga evaluaciones de LLM, porque le va a resultar familiar.
Los registros del arnés estaban llenos de actividad real. Entradas proyectadas. Caracteres ahorrados. Contadores de repliegue avanzando exactamente por las razones correctas. Nada de eso era fabricado. La proyección corría de verdad, comprimía de verdad, producía de verdad todas esas cifras. Simplemente, nada llegaba nunca al prompt. El instrumento medía fielmente su propio esfuerzo en lugar de su efecto.
Ese es el modo de fallo. Un registro que parece un brazo trabajando no es prueba de que el trabajo llegara al artefacto que estás puntuando. Y había un segundo cómplice: la plausibilidad. Cuando el ruido dibujaba por azar un patrón, sabíamos explicarlo. La explicación era mecánicamente razonable. Encajaba con las intuiciones de la literatura. Era satisfactoria. La plausibilidad no es evidencia. Es el aspecto que toma el ruido cuando quieres que signifique algo.
La temperatura cero tampoco te salva. Un modelo de respuesta más un modelo juez es una pila de componentes casi deterministas, y el «casi» se compone. Con muestras modestas, esa pila te entregará diferencias lo bastante grandes como para parecer 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 es lo bastante pequeño como para robarlo:
Antes de cualquier run de evaluación pagado, un script de control toma ahora una fila de memoria, sustituye su contenido por una cadena-marcador, y la empuja por el camino exacto de ensamblaje del prompt que usa el benchmark. Luego verifica ambas direcciones:
- con el arreglo en su sitio, el marcador debe aparecer en el prompt final, demostrando que el brazo llega de verdad al artefacto;
- por el camino antiguo, el marcador no debe aparecer, demostrando que el bug era lo que pensábamos y no algo más extraño.
Unas cuarenta líneas. Corre antes de gastar un solo token de juez. Si falla, la campaña no empieza.
La regla que salió de ahí: un experimento A/B solo existe cuando se ha demostrado que los brazos difieren en el artefacto final. No en la config. No en los logs. No en los contadores de tu instrumento. En lo que el modelo ve realmente.
Qué hicimos con los cadáveres
No borramos las campañas invalidadas. Están en el documento de diseño, tachadas, con sus tablas intactas, junto a las corregidas, porque un cuaderno de investigación que solo contiene supervivientes no es un cuaderno, es un folleto. Los resultados negativos también se quedaron, cada uno con su mecanismo de fallo explicado. Un equipo que te enseña en qué se equivocó te dice cuánta confianza merece lo que acertó.
Después volvimos a medirlo todo sobre el instrumento probado. Esas cifras son reales, son interesantes, y no están en este artículo. Se publicarán aparte, congeladas, con sus tamaños de muestra y sus reservas, cuando hayan sobrevivido al escrutinio que merecen. El día antes de las cifras es donde el trabajo de evaluación se gana o se pierde.
Tres voces, una memoria
Una cosa más sobre cómo se construyó este motor. Octave se diseñó en una conversación continua a tres voces: un humano con la intuición inicial y la última palabra, un ingeniero-compañero de IA en el código, y la asistente que vive dentro de Mnemosyne OS, revisando los diseños a la luz de su propia memoria del proyecto. En un momento dado, un resumen de la sesión de trabajo fue ingerido en la memoria del OS, y minutos después la asistente razonaba sobre esa misma crónica para proponer los siguientes experimentos. Cuando las cifras del benchmark fueron invalidadas, también lo fue un trozo de esa memoria ingerida, y la corrección se escribió como su propia crónica, que reemplaza sin borrar.
Una memoria que puede auditarse, corregirse a la vista de todos, y nunca reescribirse en silencio. Construimos el producto así porque trabajamos así. Esta semana, lo primero que se puso a prueba fue nuestra forma de trabajar.