La ofrenda del laboratorio: lo que no sobrevivió a octubre

En México, entre el 31 de octubre y el 2 de noviembre, se pone la ofrenda: un altar con la foto de quien se fue, flores de cempasúchil, pan de muerto, velas y lo que le gustaba en vida. Y se escriben calaveritas, versos burlones en los que la Catrina viene por alguien.

Un laboratorio también tiene sus muertos. Mi laboratorio, en octubre de 2026, eran dos equipos en una oficina: una mini PC Intel N100 y una Raspberry Pi 5. No todos los experimentos estaban destinados a sobrevivir. Algunos murieron porque encontramos algo mejor; otros, porque las mediciones contradijeron lo que esperábamos; y algunos simplemente cumplieron su ciclo. Pero si se documenta bien lo que pasó, ninguno desaparece por completo.

Ésta es la ofrenda. Cada difunto lleva su acta: fecha, causa de muerte técnica y lo que nos deja. Y su calaverita, porque sin calaverita no hay ofrenda. El humor no tapa el resultado: cada cifra sale de una medición publicada o de su bitácora.

Antes de empezar, una aclaración. No tengo registrado que en octubre muriera ningún componente: ni una SD, ni una fuente, ni un sensor. No pusimos un cadáver electrónico para llenar el altar.

El usuario pi

Falleció el 3 de octubre, en la Raspberry Pi 5.

Causa de muerte: retiro. Ese día los dos equipos pasaron a ser exclusivos del laboratorio, con un usuario propio, edgelab, y una llave propia. Antes de cerrar la cuenta de fábrica, todo el laboratorio que vivía en ella se copió a edgelab y se comprobó por hash. Después se borró la copia vieja, y a pi se le bloqueó la contraseña y se le quitaron las llaves.

Epitafio: Aquí descansa una cuenta que cumplió su ciclo. Sus experimentos siguen vivos en edgelab.

Lo que nos deja: no murió por una falla; el laboratorio cambió. También hay que retirar las configuraciones que ya no corresponden a la arquitectura. Y en ese orden: primero se copia y se comprueba, luego se borra.

La Catrina entró a la Pi muy formal
y al usuario pi lo mandó a descansar:
“Tus datos los hereda edgelab, tal cual;
la llave la dejas, ya no hay que entrar”.

La promesa de OpenVINO en la CPU del N100

Falleció el 3 de octubre, en el N100. Se confirmó el 7.

Causa de muerte: medición. OpenVINO es el runtime de Intel para su propio hardware, y en una mini PC Intel parecía la elección obvia. Con la precisión fijada en f32, fue entre 11 % y 22 % más lento que ONNX Runtime en los tres modelos que medí: MobileNetV2, ResNet18 y YOLO26n. Contra su modo para muchas peticiones a la vez, ONNX Runtime con cuatro procesos siguió adelante entre 14 y 20 %.

No murió entera. En la gráfica integrada del N100, OpenVINO sí gana: con YOLO26n, 39 % más inferencias por segundo que ONNX Runtime en la CPU. Pero gana en FP16, una precisión que elige por su cuenta. Con ella, las detecciones bajan de confianza: en una imagen, una persona pasó de 0.829 a 0.696. Lo que murió fue la promesa de que en la CPU de este equipo bastaba con elegirlo.

Epitafio: El rendimiento se demuestra con mediciones, no con las promesas de una herramienta.

Lo que nos deja: fijar la precisión y leer después la que de verdad quedó. La medición completa está en la nota de OpenVINO, y los datos crudos, en crtdrops.mx/datos.

A OpenVINO, que prometía volar,
la Catrina en el N100 lo cronometró:
con f32 fijo no pudo acelerar,
y ONNX Runtime en la meta lo esperó.

Las tareas programadas del asistente

Fallecieron el 9 de octubre.

Causa de muerte: permisos. Eran cuatro tareas automáticas. Dos sólo leían: una revisaba cada mañana entre semana las conversaciones de dev.to, y otra medía las cifras cada lunes. Las otras dos, de una sola corrida, agregaban la pregunta de cierre a dos notas ya publicadas. Se atoraban pidiendo permisos, y no había un lugar a la mano donde aprobarlos. Además, casi todo lo que hacían necesitaba de todos modos mi “sí”.

Las reemplazó una rutina que yo disparo cada mañana. Lo único que quedó automático es lo que no necesita mis permisos: las publicaciones programadas de dev.to.

Epitafio: Una automatización que necesita supervisión constante deja de ser realmente autónoma.

Lo que nos deja: antes de automatizar algo, preguntar quién lo destraba cuando se atora. Si la respuesta es “yo, a cada rato”, todavía no es automático.

Cuatro tareas, puntuales y obedientes,
temprano salían a trabajar;
pedían permiso, quietas y pacientes,
y la Catrina se cansó de esperar.

La estrategia original del TradingAgent

Falleció el 10 de octubre.

Causa de muerte: no pasó la prueba. TradingAgent es un agente propio para operar criptomonedas al contado; no es un producto ni una recomendación. Su validación se hizo con un protocolo escrito antes de ver los datos: se ajusta con 2018 a 2022, se prueba con 2023 a septiembre de 2026, y tiene que cumplir cinco criterios. La estrategia original, tal como corría, dio esto (las cifras salen de su bitácora, que no está publicada):

	Ajuste 2018–2022	Prueba 2023–sep 2026
Rendimiento anual	+3.0 %	+0.4 %
Caída máxima	2.1 %	3.6 %
MAR (rendimiento anual entre caída máxima)	1.48	0.10
Pares con resultado positivo	10 de 10	6 de 10
Reality Check	97, robusto	63, marginal
Criterios del protocolo	cumple los 5	no cumple 3: MAR, Reality Check y al menos 7 de 10 pares positivos

La ventaja de 2018 a 2022 no se sostuvo fuera de esa ventana. Con el doble de costos, la prueba queda en +0.1 % al año. En la prueba de suerte de Reality Check, 29 % de los remuestreos pierden. Y con mi tolerancia de 15 % de caída máxima, ninguna de las 18 configuraciones de la segunda fase dio un agente.

No basta con que una estrategia dé un resultado positivo: tiene que justificar el riesgo que asume. Con +0.4 % al año, no lo justifica.

Su sucesora anda como alma en pena. Una de las familias de la segunda fase, escalada para no caer más de 15 %, pasó la prueba, aunque con evidencia más débil, porque ese periodo ya se había usado. Pero bastó ejecutarla un día tarde, o rebalancear otro día de la semana, para que su caída pasara de 15 %: de las cinco formas de ejecutarla que probé, sólo la elegida se quedó por debajo. Así no sirve para dinero real. Opera en papel desde el 12 de octubre, y nadie la entierra ni le reza hasta el 11 de enero de 2027, cuando se decide si pasa a una red de prueba, todavía sin dinero real.

Epitafio: Descartar una hipótesis también es un resultado de investigación.

Lo que nos deja: escribir los criterios antes de ver la prueba, y no moverlos después.

Al agente de trading, prudente y cabal,
la Catrina le dio datos que nunca vio:
cuatro décimas al año, y ni un real más;
“Con eso, mi rey, ni la cera alcanzó”.

El Laplaciano y la distancia mínima

Fallecieron el 26 de octubre, en el N100. Van en un solo retrato.

Causa de muerte: el ruido. En el experimento de los fantasmas, un disco brillante se mueve sobre un fondo uniforme y hay que decir dónde está. Éstos eran dos de los filtros del ojo de 2001 que reescribí en C: el Laplaciano y una prueba de borde de mínima distancia, cada uno con un umbral fijo. En la escena limpia funcionaban: 1.1 px y 0.3 px de error mediano. Con una pizca de ruido —gaussiano σ 10 o 1 % impulsivo— perdieron el disco en los 20 cuadros de cada caso, con y sin el cancelador de eco. Se quedó la mediana con el cancelador, que elegí después de ver los resultados por tener el peor caso más bajo: en los 72 cuadros de la comparación, 0.1 px de error mediano y 7.8 px en el fantasma más difícil, ruido gaussiano σ 50.

Epitafio: Un algoritmo no se evalúa por su mejor resultado, sino por cómo resiste las condiciones reales.

Lo que nos deja: publicar también las variantes que fallan. Las diez están en el repositorio, las malas incluidas.

El Laplaciano y su compadre, el de la distancia,
veían los bordes finitos en la escena ideal;
bastó una pizca de ruido, sigma diez, sin importancia,
para que el umbral los mandara al panteón municipal.

Gemma como ojo

Falleció el 27 de octubre, en el N100.

Causa de muerte: siempre dio la misma respuesta. En el mismo experimento, Gemma 3 4B, corriendo en local, contestó (320, 240) en las 72 imágenes, también en las limpias: el centro exacto de la imagen. Su error mediano fue de 177.8 px. En el mismo equipo y con las mismas imágenes, Qwen2.5-VL 3B encontró el disco a 1.3 px en los 37 cuadros donde dio la caja completa.

Murió para ese prompt: lo probé con uno solo, y otro podría irle mejor. Y no murió entera. Gemma sigue escribiendo cada mañana el informe del turno de noche, que es el trabajo en el que sí medimos dónde se equivoca.

Epitafio: Una respuesta consistente no necesariamente es una respuesta correcta.

Lo que nos deja: antes de creerle a un modelo, ver si su respuesta cambia cuando cambia la imagen. Si no cambia, no está mirando.

Gemma, la que escribe el informe temprano,
quiso también ser ojo y el disco encontrar;
señaló el centro setenta y dos veces, en vano:
el disco, en otra parte, se echó a carcajear.

La invitada que regresó: la Raspberry Pi 5

No va como difunta, sino como invitada que regresó del más allá.

El 27 de octubre a las 20:06 se fue la luz en la oficina. La Pi perdió la alimentación y se reinició. Nadie la tocó: el latido volvió solo, y el turno de noche, que arranca a las 22:00, salió completo esa misma noche: el 100 % de los latidos esperados.

Lo que nos deja: la resiliencia no consiste en evitar todas las interrupciones, sino en poder recuperarse de ellas.

Se fue la luz, y en la oficina oscura
la Catrina a la Pi se la quiso llevar;
volvió la corriente, arrancó sin ayuda,
y esa noche a la Catrina le tocó velar.

El acta completa

Difunto	Fecha	Causa	Lo que deja
El usuario pi	3 oct	Retiro	Retirar lo que ya no corresponde, copiando y comprobando antes
OpenVINO en la CPU del N100	3 oct	11 a 22 % más lento en f32	Medir en vez de suponer; fijar y leer la precisión
Las tareas programadas	9 oct	Se atoraban pidiendo permisos	Si necesita supervisión constante, no es autónoma
La estrategia original del TradingAgent	10 oct	+0.4 % al año en la prueba	Descartar una hipótesis también es un resultado
El Laplaciano y la distancia mínima	26 oct	Perdían el disco con poco ruido	Se evalúa por la resistencia, no por el mejor caso
Gemma como ojo	27 oct	El centro, en las 72 imágenes	Consistente no es correcto
La Raspberry Pi 5 (invitada)	27 oct	Apagón; regresó sola	Recuperarse, no evitar toda interrupción

En esta ofrenda no celebramos los errores: celebramos lo que aprendimos al reconocerlos.

Israel Negrete Lepe es ingeniero en electrónica. Veinticinco años haciendo que sistemas distintos funcionen juntos en condiciones reales: del sensor, el vehículo o la transacción al backend, los datos, la seguridad y la operación. Hoy, cada vez más, IA en el borde. Acepto proyectos por hora o por entrega: israel0negrete@gmail.com.