La transcripción Speech-to-Text Client-Side que no puntúa correctamente por no usar un LLM-MM
No soy mucho de enviar audios por las aplicaciones de mensajería. Lo hago sólo con amigos, y gente muy cercana, pero no me gusta mucho usar la voz. Va demasiado de mí en los audios. Sin embargo, es mucho más rápido que escribir. Pero... ¿por qué no usar el Speech-To-Text del smartphone? Pues porque no suelo tener buena experiencia con la puntuación. Eso es lo que estaba pensando ayer domingo, trabajando viendo el puente del 25 de Abril de Lisboa , así que quise probar si, con la llegada de los LLMs Multi Modales, había mejorado. Figura 1: La transcripción Speech-to-Text Client-Side que no puntúa correctamente por no usar un LLM-MM Primera prueba, usando Twitter/X en iOS , y el botón de Speech-To-Text del teclado del iPhone 17 Pro Max que tengo, con un mensaje muy sencillo. Aquí tenéis el resultado, muy al estilo de los primeros Cognitive Services del año 2016 (si no anteriores) . Han pasado 10 años ya para seguir con esta calidad. Figura 2: Speech-to-Text del teclado de iPhone. No pone el punto ni las interrogaciones. Ni una coma. Six-Seven nada más. Lo siguiente que hice fue probarlo en Gemini , pero ahora pidiéndole que me lo hiciera bien con un Prompt y subiéndole un audio, para que hiciera todo el proceso en backend (Server-Side) . El resultado es muy bueno, que es lo que yo estoy esperando de un Speech-to-Text en el terminal móvil. Figura 3: Gemini lo borda. Correcto. Así que, como lo hizo muy bien Gemini , que es un LLM-MM , le pregunté por qué la soluciones Speech-To-Text en Smartphone tienen tantas carencias a la hora de poner las puntuaciones correctas, y aquí está la explicación que me dio. Figura 4: Problemas del Speech-to-Text para puntuar correctamente. Por supuesto, la primera es que no se dictan los puntos y las comas, ni las interrogaciones o exclamaciones. Evidente, pero en el mundo que estamos hoy en día, l os modelos de IA reconocen las entonaciones con facilidad, así como se hace el análisis de sentimiento, que de eso hemos hablado mucho . Basta con un clasificador de Machine-Learning para hacer eso. Figura 5: Libro de Machine Learning aplicado a Ciberseguridad de Carmen Torrano , Fran Ramírez , Paloma Recuero, José Torres y Santiago Hernández Lo siguiente que dice es que las pausas pueden ser ambigüas, bueno, pero se puede hacer mejor que lo que se hace ahora. También dice que puede afectar la diferente forma de entonar que se tiene o que el contexto puede ser indeterminado. Además del uso de fórmulas habladas, como las muletillas. Nada, no se lo compro, debería ser mucho mejor que esta prueba que he hecho con Notas de iPhone . Figura 6: Ni una puntuación. Visto esto, le pregunté a Gemini , si estos problemas existen, cómo es posible qué él lo hubiera hecho tan bien con el audio que le había subido, y la respuesta se resume en... Yo soy un LLM-MM de primer nivel, para mí es trivial. Figura 7: La respuesta de por qué lo hace él tan bien Por supuesto, hay una diferencia fundamental entre hacer un análisis en tiempo real del flujo de audio en " stream " a hacerlo con el fichero completo en " bloque ", pero aún así es muy mejorable. De hecho, este Prompt se lo he subido usando el Speeh-To-Text en Google Chrome en la webapp de Gemini - ejecutándose el Client-Side - , y la verdad que lo hace muy bien. Figura 8: Usando el Speech-To-Text de Gemini en Google Chrome Client-Side Lo dicho, creo que si estos sistemas de Speech-To-Text en Client-Side funcionara mejor - que estamos en la era ElevenLabs y traducción en tiempo real de conversaciones, la gente haría menos uso de los envíos de audios, y sería un avance para los usuarios, porque a veces hay que escribir textos muy largos por no enviar el audio a una persona que no se quiere enviar. ¡Saludos Malignos! Autor: Chema Alonso ( Contactar con Chema Alonso ) Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com…