En The Blue Box venimos investigando un problema que aparece cada vez más en atención médica: cómo registrar consultas, transcribirlas, resumirlas en formato SOAP y analizar el historial longitudinal de un paciente sin perder información clínica relevante.
La motivación es clara. Muchos médicos atienden pacientes cada pocos minutos, y a veces un mismo paciente ve distintos profesionales. Si el sistema no ayuda a recuperar contexto, cada consulta queda aislada.
La capa de transcripción fue donde el problema se volvió más interesante.
Cómo funciona el reconocimiento de voz
Un sistema ASR no "escucha" como una persona. Primero captura audio, lo convierte a señal digital, lo divide en ventanas pequeñas y extrae características acústicas. Luego un encoder procesa esas señales y un decoder predice texto.
El punto importante es que todo lo que ocurre después depende de esas primeras etapas. Si una palabra breve como "no" queda tapada por ruido, cae en un borde de chunk o tiene poca energía, el modelo puede producir una transcripción fluida que simplemente la omite.
En medicina, esa omisión puede cambiar el significado clínico.
El problema de testear ASR en condiciones ideales
Muchos benchmarks miden word error rate sobre audio limpio. Las consultas reales tienen ruido, interrupciones, voces superpuestas, silencios, muletillas y respuestas cortas.
Probamos modelos sobre un audio médico real de diez minutos. Tenía ruido ambiente, pausas y conversación natural. Era un buen proxy para entender qué podría pasar en un flujo clínico real.
Whisper
Whisper, de OpenAI, funcionó muy bien en modelos medianos y grandes. Capturó puntuación, fillers y flujo conversacional con alta calidad. Pero también tuvo un problema serio: omitió silenciosamente una interacción clínica completa sobre historial familiar de cáncer.
Ese tipo de error es peligroso porque no se anuncia. El transcript parece correcto, pero falta un dato que puede afectar el resumen y decisiones posteriores.
En nuestros tests, Whisper Turbo tardó más de un minuto para procesar diez minutos de audio en el hardware usado. La calidad fue buena, pero la latencia no era ideal para una experiencia en vivo.
La conclusión no fue "usar el modelo más grande". Fue buscar un equilibrio entre velocidad, precisión y posibilidad de fine-tuning con datos médicos reales.
MedASR
MedASR, de Google, es más pequeño y especializado en habla médica. La velocidad fue muy superior: procesó el audio en segundos. Pero la calidad quedó por debajo de Whisper.
Con chunking básico omitía respuestas cortas y mostraba tokens crudos. Al usar una estrategia con stride mejoró, pero seguía lejos de Whisper en fidelidad.
Aun así, MedASR mostró algo importante: los modelos pequeños especializados pueden ser una buena dirección si se ajustan bien y se diseñan con una estrategia de procesamiento adecuada.
Qué significa para ASR en healthcare
La pregunta no es solo qué modelo es mejor. La pregunta es qué tipo de errores puede tolerar el producto.
En muchas aplicaciones, perder una palabra es una molestia. En medicina, puede significar un síntoma omitido, un factor de riesgo mal interpretado o un resumen clínico incorrecto.
Conclusión
"Suficientemente rápido" no alcanza si el sistema omite datos clínicos en silencio. La velocidad importa, pero solo después de lograr confiabilidad.
Nuestro camino apunta a modelos más pequeños, especializados, posiblemente entrenados con audio médico en español, capaces de correr localmente y proteger la privacidad del paciente.
Referencias
El artículo original cita recursos sobre ASR, Whisper, Conformer, chunking y arquitectura encoder-decoder. La lección práctica para producto es directa: en healthcare, el error silencioso es más peligroso que una respuesta lenta.
Escrito porFacundo Ferrari
Equipo chico. Sistemas inteligentes. Impacto real.
Suscripción al newsletter