El 5 de octubre, en una reunión real, tecleé una pregunta en el panel flotante de Saelyx. Era de las que piden un dato y nada más. La respuesta empezó a llegar 102 segundos después. Dieciséis segundos más tarde acabó la sesión, con ella a medias.
01El modelo iba bien
Cuando algo tarda, se mira el modelo. Lo miré primero: entre 1,7 y 2,3 segundos hasta el primer fragmento de respuesta, en todos los turnos de esa reunión. Lo mide el propio motor de voz, turno a turno, y ninguno se sale de ese rango. Un modelo que arranca en unos dos segundos no explica los otros cien.
02Tres relojes
Entre la tecla y la respuesta corren tres relojes, cada uno en un sitio distinto y con su propio instrumento. La cronología de esa pregunta:
t+0 s tecleo la pregunta
t+7 s sale hacia el motor de voz
t+102 s empieza la respuesta
t+118 s acaba la sesión, a medias- El modelo: de 1,7 a 2,3 s hasta el primer fragmento, como en la sección anterior.
- Mi cola: 7 s. Mientras el agente está ocupado, la cola retiene lo que se teclea, porque un mensaje nuevo hace que el motor tire la respuesta que llevaba a medias. Tiene un tope, y aquí se gastaron 7 segundos: lo veo en mi registro.
- El turno de voz: 95 s. Desde que la pregunta entra al motor hasta que empieza a contestar, según la transcripción del propio motor. Es casi todo.
En una conversación normal el motor sabe cuándo te toca a ti y cuándo a él: hablas, callas, contesta. En una reunión el micrófono recoge la sala entera, y además le paso lo que dicen los demás para que el agente tenga contexto. Para el motor, todo eso es un usuario que no para de hablar, en bloques de varios miles de caracteres. En una reunión casi siempre habla alguien; para eso están.
Mientras ese turno siga abierto, el agente no contesta. Y cada línea nueva que le llega como turno tira la respuesta que estuviera preparando. La pregunta no encontró hueco en 95 segundos. Lo encontró cuando acabó la reunión.
03Dos caminos, y quién decide
El turno de voz lo dejé como estaba. Lo que cambié fue el camino: lo que no necesita la voz ya no pasa por ella.
Lo que no pide actuar (una pregunta, un resumen, unas ideas) va ahora al modelo por escrito, con las últimas líneas de la reunión como contexto, y la respuesta se pinta en el panel. No se manda además por la voz, para que no se conteste dos veces. Las tres preguntas que tecleé esa misma tarde, en otra reunión, quedaron contestadas, enteras, en 2,4, 1,3 y 2,5 segundos.
Lo que pide actuar sigue por la voz, que es la que tiene las herramientas: cerrar la reunión, apuntar algo, buscar en la web. También van por ella el «sí» o el «no» a algo que ha dicho el agente, rehacer la última línea («acórtalo») y lo que necesita herramientas que solo tiene ese camino. Si el escrito falla (por ejemplo, sin conexión o sin sesión), la misma pregunta sale por la voz, una sola vez. En el peor caso, lo de antes.
Ante la duda, gana la voz, porque los dos errores no cuestan lo mismo. Una pregunta que cae en la voz por error tarda, como tardaba antes. Una orden que cae en el escrito por error no se ejecuta, porque ese camino no tiene herramientas. Por eso la lista de lo que cuenta como orden la hice generosa a propósito.
04Lo que descarté, y por qué
Lo más simple era mandarlo todo por escrito, y contestaba en dos segundos. Pero eso deja a las órdenes sin herramientas, y prefiero una respuesta lenta a una orden que no se hace.
La primera versión, la de esa mañana, mandaba por escrito solo lo que parecía una pregunta: signo de interrogación o palabra interrogativa. «Resume lo último» o «dame tres ideas» no lo parecían y se quedaban esperando hueco de voz. En la reunión de la tarde, sin hueco, la voz tardó 26 segundos o no contestó, y en un tramo de unos trece minutos seis tecleadas se quedaron sin respuesta. Quien las tecleaba no veía nada, ni siquiera que estuvieran esperando. Esa misma tarde le di la vuelta al criterio: por escrito va todo lo que no sea una orden, un sí o un no, o rehacer la última línea. Y lo que sigue por la voz ya no calla: si en unos segundos no llega ninguna señal del agente, el panel dice que la voz espera un hueco.
El motor más impaciente ya lo probé: partía una frase en tres peticiones y lo quité el 25 de septiembre. En una reunión, con la sala hablando sin parar, lo esperable es que contestara a la sala. Esto último es razonamiento: no lo he medido.
05No era la primera vez
El 18 de septiembre, en Modo Reunión, una pregunta sencilla tardaba entre 30 y 45 segundos. El modelo contestaba en 2,5 a 3,4 s por llamada, y el motor esperaba 19,7 y 26,6 s antes de tomar la palabra en las dos esperas que medí. Aquella vez la causa que encontré era mía: una señal de «sigo aquí», enviada cada pocos segundos para que la llamada no caducara, le decía al motor que el usuario seguía activo. La hice callar mientras se espera una respuesta, ese mismo día.
Las dos veces empecé por lo mismo: separar los relojes antes de tocar el modelo. Ya es una regla mía: si una latencia en reunión no se puede partir en modelo, cola y turno, todavía no estoy midiendo nada.
06Lo que sigue sin arreglar
Lo primero, la voz: sin hueco tardó 26 segundos o no contestó, y eso no lo he arreglado. He sacado de ese camino una clase de preguntas; las órdenes siguen pasando por él.
Es un caso de 102 segundos, medido al segundo con dos fuentes (mi registro y la transcripción del motor), así que el reparto entre 7 y 95 puede variar en uno. Del camino escrito hay tres respuestas medidas, y de la voz sin hueco, seis tecleadas; una reunión por la mañana y otra por la tarde. No tengo percentiles. Y los dos tiempos no vienen del mismo instrumento: los 1,7 a 2,3 s son hasta el primer fragmento del modelo de la voz y los 1,3 a 2,5 s son la respuesta entera del camino escrito, que es otro camino.
El camino escrito contesta en una o dos frases, con las últimas líneas de la reunión y sin herramientas, que es lo que le pido. Y todo esto es lo que pasa en el Mac: en el iPhone no lo he medido.
07Preguntas frecuentes
¿Por qué no haces que el motor de voz tome antes la palabra?
Ya probé un ajuste más impaciente y partía una frase en tres peticiones; lo quité el 25 de septiembre. En una reunión, con la sala hablando, lo esperable es que contestara a la sala, aunque eso no lo he medido. Prefiero sacar de ese camino lo que no lo necesita.
¿Qué sigue yendo por la voz?
Las órdenes (cerrar la reunión, apuntar algo, buscar en la web), el «sí» o el «no» a algo que ha dicho el agente, rehacer la última línea y lo que necesita herramientas que solo tiene ese camino. Ante la duda, va por la voz.
¿Qué pasa si el camino escrito falla?
La misma pregunta sale por la voz, una sola vez. Si la voz tampoco encuentra hueco en unos segundos, el panel lo dice en lugar de quedarse callado.
¿Se lee mi pantalla cada vez que pregunto?
No. Solo si la pregunta la nombra («qué pone en la pantalla», «lee esto»). Entonces se lee en tu propio Mac el texto de la ventana que tienes delante o, si la de delante es la propia Saelyx, el de la pantalla donde está el cursor, sin las ventanas de Saelyx. Ese texto viaja con la pregunta, recortado, con las claves y contraseñas que reconoce tapadas y marcado como dato y no como instrucción. Si compartes una sola ventana o no has concedido el permiso de grabación de pantalla, no se lee nada. El detalle completo está en qué sale de tu ordenador.
¿Funciona igual en el iPhone?
Lo que cuento es lo que hace hoy el Mac, que es donde lo he medido. En el iPhone no lo he medido y no lo doy por hecho.
— Adianny
Sr. DevOps. Llevo unos cuatro años trabajando con machine learning y MLOps, hoy como tech lead; Saelyx es mi proyecto de casa.