El 15 de septiembre, en plena reunión, una sesión de voz se cortó y volvió sola tres segundos después. Volvió con la conversación en blanco. Llevaba 600 segundos abierta, ni uno más, y 58 mensajes.
Una semana después, el 22, encontré otro fallo que no había hecho ningún ruido. En unas quince horas de registro, el respaldo había bajado 96 veces al modelo pequeño turnos que debía contestar el grande. Lo vi revisando el gasto, no porque nada avisara.
01«Murió y volvió»
Una sesión que se corta y vuelve sola, con la conversación en blanco, se parece a una caída de red. Así lo leí al principio: la red, el ordenador o el motor de voz.
Lo que no encajaba era la cuenta. Una red que falla no suele hacerlo a los diez minutos clavados. Y la reconexión automática, que tardó tres segundos, lo dejaba todo como nuevo menos lo hablado.
02Un número redondo es un tope
Antes de tocar nada pregunté al motor de voz, el proveedor externo del que hablo en qué sale de tu ordenador, cómo había terminado esa conversación. Guarda el motivo de cierre de cada una, y el de esta decía que había superado la duración máxima. Las dos configuraciones de voz que tenía en producción, la del Mac y la de iPhone, iPad y reloj, llevaban un tope de 600 segundos.
No hizo falta más. Otra sesión, abierta cuatro minutos y medio después, tenía la hora de cierre calculada de antemano: la de apertura más 600 segundos. Un fallo que se predice con una suma es una configuración.
Lo que lo hacía parecer aleatorio era la reconexión automática. Hacía bien su trabajo, devolver la voz en tres segundos, y de paso borraba la pista: a la vista solo quedaba un «se cayó y volvió».
Ese mismo día lo subí a dos horas en las dos configuraciones, que es lo máximo que me dejó poner el motor. El 25 de septiembre volví a leerlas del servicio y seguían en dos horas.
03El respaldo que no hacía ruido
El 18 de septiembre migré a una versión nueva del modelo grande. Ese día un acta salió con un error visible: el modelo nuevo rechazaba un parámetro de muestreo (de los que regulan cuánto se arriesga al elegir cada palabra) que enviaba la ruta de las actas. Arreglé esa ruta, ese día.
La ruta de la voz arma su propia petición y tenía el mismo defecto, pero esa no hizo ruido. Con una tarea en curso y sin razonamiento extendido mandaba el mismo parámetro, el modelo nuevo lo rechazaba y el respaldo hacía lo que se le había pedido, bajar ese turno al modelo pequeño y seguir. Ningún error a la vista. En el registro, entre el 21 y el 22 de septiembre, hay 96 de esas bajadas en unas quince horas.
El registro de cada turno tiene un campo con el modelo que contestó y otro con el motivo por el que se eligió. El respaldo cambiaba el primero y no tocaba el segundo: el motivo seguía diciendo «tarea en curso», que es la razón para usar el modelo grande. El evento del respaldo sí quedaba escrito, pero ninguna métrica ni alarma lo miraba.
El arreglo fue una lista de los modelos que rechazan esos parámetros, y a esos ya no se los mando. Antes lo medí con una llamada real de un token al servicio: el modelo grande rechazaba dos de los parámetros y el pequeño aceptaba los dos. El test que lo protege falla contra el código de antes, que es lo único que le da valor: un test que pasa a la primera y nunca se ha visto fallar no demuestra nada.
No bastó. En poco más de una hora, otros 18 turnos cayeron al modelo pequeño por un tercer parámetro: la petición lleva tres de estos, repartidos en dos campos distintos, y mi primer arreglo había cubierto dos. Segundo arreglo, ese mismo día.
De aquí salen dos reglas. Un cambio de modelo se prueba con una llamada real en cada sitio que arma la petición, con sus parámetros reales: arreglar solo la ruta que había fallado a la vista fue el error, porque dejó intacta la de la voz. Y un respaldo que cambia lo que habías decidido tiene que dejarlo escrito donde se lea, y tener una alarma.
No quité el respaldo para que los errores se vieran: prefiero una voz que contesta con otro modelo a una que se queda callada. Lo que falta es que se vea cuándo actúa.
04Lo que sigue pendiente
A 6 de octubre de 2026 me quedan tres cosas sin cerrar.
- El techo existe: está a dos horas, y una reunión más larga llegaría a él igual que la de septiembre llegó al de diez minutos. Lo que lo resolvería es renovar la sesión antes de que caduque, llevándose lo hablado. Lo tengo anotado como pendiente desde el 15 de septiembre y sigue sin cerrarse.
- El respaldo sigue sin alarma. El evento queda en el registro y solo se ve si alguien lo busca; a mí me llegó por el gasto. La regla la tengo escrita desde el 22 de septiembre; la alarma, todavía no.
- Dos casos no hacen una estadística: de las 96 respuestas sé qué modelo contestó, no si contestó peor.
05Preguntas frecuentes
¿Por qué se cortaba justo a los diez minutos?
Porque las dos configuraciones de voz llevaban un tope de 600 segundos por sesión. Era un valor configurado en el motor de voz, no un fallo de la red.
¿Sigue pasando?
Lo de los diez minutos no. Desde el 15 de septiembre las dos configuraciones están en dos horas, y el 25 de septiembre volví a leerlas del servicio y seguían así. El techo de dos horas sí existe.
¿Qué pasa si una reunión pasa de dos horas?
Llega al techo de dos horas, que es lo máximo que me dejó poner el motor de voz. Renovar la sesión antes de que caduque, llevándose lo hablado, lo resolvería y sigue pendiente.
¿Cómo se detectó que el respaldo bajaba de modelo?
Revisando el gasto, no por una alarma: aparecieron turnos de tarea en curso respondidos por el modelo pequeño.
¿Hay ya una alarma sobre ese respaldo?
Todavía no. El evento queda en el registro, pero ninguna métrica ni alarma lo vigila. La regla está escrita; la alarma, pendiente.
— Adianny
Sr. DevOps. Llevo unos cuatro años trabajando con machine learning y MLOps, hoy como tech lead; Saelyx es mi proyecto de casa.