GPTunneL llevó a su asistente de voz GROM a un directo: qué falló en 3 horas de hackatón

Un asistente de voz en una mesa compartida es una idea fácil de entender, hasta que llega a un directo. El equipo de GPTunneL la probó en el hackatón «Nuevas ciudades» en el «Gran Fizteh»: durante tres horas GROM escuchó a expertos, escolares y estudiantes que diseñaban un poblado del futuro, y respondió preguntas en voz alta. El resultado no fue perfecto, pero el análisis es honesto.

Cómo funciona

No se usó una palabra de activación. El habla del micrófono se reconocía, se miraba la primera palabra de cada intervención y, si era «Grom», el texto pasaba al modelo. La respuesta la locutaba la voz sintética de Filipp, desarrollada por el mismo equipo. En el ensayo GROM se metía solo en la conversación e interrumpía ideas, así que para el directo se pasó al modo «habla solo si lo llaman».

La principal dificultad es que las personas casi siempre hablan entre sí, no con el asistente. Para que GROM supiera qué se había acordado, la emisión se procesaba con un flujo independiente. vMix guardaba un archivo de vídeo cada cinco minutos, Resilio lo transfería a un segundo ordenador, un Whisper local hacía la transcripción y Claude Sonnet actualizaba un resumen: quién propuso qué, qué se decidió, qué quedó abierto. El resumen actualizado se insertaba en la instrucción de sistema de GROM. Se eligió Sonnet porque el equipo ya había comprobado sus resúmenes muchas veces.

Dónde se torció todo

El primer fallo fueron quince minutos perdidos. Cuando llegaban varios archivos a la vez, el procesador tomaba el más reciente y no tenía cola. Tras el octavo archivo venía el duodécimo, y los fragmentos del noveno al undécimo hubo que procesarlos a mano.

El segundo, los nombres. A Whisper no se le dio una lista de nombres y GPTunneL se convirtió en GPTanal. Peor resultó el etiquetado de hablantes: en cada archivo la numeración empezaba de nuevo y el «Hablante 1» de fragmentos contiguos podía ser dos personas distintas.

El tercero, el contexto. Una larga discusión sobre si el mentor tendría barba saturó el historial del diálogo. Nueve minutos después, ante la pregunta de si una persona puede vivir menos sin comunicación, GROM volvió a hablar de la barba. Un ingeniero limpió el historial en pleno directo, y la decisión sobre el aspecto del personaje quedó en el resumen aparte, así que en lo esencial el asistente no perdió nada.

Qué conviene anotar

Para los desarrolladores la lección es esta: la memoria prolongada de un asistente no es un contexto grande, sino disciplina. Conviene separar el diálogo en bruto del extracto de decisiones: el historial se puede limpiar, el resumen permanece. Es un recurso barato y funcionó en directo.

Un flujo hecho de fragmentos necesita una cola, no la lógica de «tomar el último». Para el reconocimiento hace falta un diccionario de nombres y términos antes del inicio. Para varios hablantes se necesita identificación continua de hablantes: el equipo se propone probar embeddings de voz y comparar el resultado con el etiquetado manual.

Las limitaciones también se ven. Es un piloto en un solo evento, no hay métricas de calidad de las respuestas, parte del trabajo fue manual, y el modelo de vídeo nunca generó la inscripción del dirigible: se añadió en el montaje. Las respuestas salieron al aire sin edición, por eso el desafortunado momento de la barba quedó en la grabación en el minuto 55:03.

Los planes: en noviembre volver a eventos presenciales con cola y diccionario, conectar el asistente con el editor Workflow para poder decir «Grom, rehaz la escena de la tarde» y buscar recursos para lanzarlo en dispositivos. Para ello hacen falta tarjetas gráficas y equipo para pruebas, y el equipo lo habla con inversores. Para los product managers la conclusión es simple: el valor de una interfaz de voz en una conversación grupal no está en responder una pregunta, sino en conocer el contexto de toda la reunión. Esa es la parte que conviene construir primero.