Publicado: · Versión para IA (markdown)
El motor de reconocimiento de voz (STT) para llamadas se elige no por una «precisión general» declarada, sino por cómo maneja específicamente sus conversaciones: en su idioma, con audio telefónico a 8 kHz, dentro de su presupuesto por minuto y bajo sus requisitos sobre a dónde van los datos. No existe un motor universalmente «mejor»: existe el que se ajusta a la tarea. A continuación, los seis criterios sobre los que decidir, y por qué conviene probarlos con su propio archivo y no con benchmarks ajenos.
Paso 1. Empiece por el idioma y los acentos
El primer criterio eliminatorio es el idioma. Un motor excelente en inglés puede rendir claramente peor en español, y viceversa. Si sus llamadas abarcan varios idiomas o tienen acentos regionales marcados, busque un motor multilingüe en lugar de un conjunto de modelos monolingües. Para la telefonía en un idioma específico suelen destacar los motores locales; para decenas de idiomas, los modelos multilingües en la nube encajan mejor.
No confunda el idioma de la interfaz con el idioma de reconocimiento: son cosas distintas. Determine en qué idiomas ocurren realmente sus llamadas y en qué proporciones. Si el 95 % de las conversaciones son en un idioma, optimice para ese; si el flujo es mixto, lo importante es la capacidad del motor de cambiar de idioma dentro de una misma conversación sin «caer» en un idioma por defecto.
Paso 2. Verifique la precisión con audio telefónico a 8 kHz
Esta es la trampa principal. La mayoría de las cifras de precisión atractivas provienen de audio de estudio limpio a 16 kHz o más, mientras que la telefonía es sonido de banda estrecha a 8 kHz, con códecs, ruido de línea, eco y solapes de voz. Un motor que brilla con podcasts puede rendir notablemente peor en llamadas reales. Por eso hay que verificar la precisión con grabaciones lo más parecidas posible a las suyas: misma telefonía, mismas condiciones, misma jerga.
Un método práctico: tome una decena de llamadas típicas donde sepa con certeza qué se dijo, páselas por varios motores y compare las transcripciones a simple vista. Fíjese no en el porcentaje general, sino en lo que es crítico para usted: ¿se reconocen bien los nombres, números, montos, nombres de productos y términos específicos? Un error en la cifra de un contrato pesa más que un «eh» omitido. No confíe en benchmarks ajenos: su acústica es única.
Paso 3. Calcule el costo por minuto
Los motores difieren en costo por varias veces, y en volumen eso es el factor decisivo. Hay que calcular no un precio abstracto, sino el costo del minuto de su escenario concreto: depende de la duración de las llamadas, del número de canales (una grabación estéreo operador/cliente duplica el costo en motores que tarifican por canal) y del volumen mensual de flujo.
El costo de los motores varía mucho — de fracciones de centavo a varios centavos por minuto. En la plataforma, las operaciones se descuentan del saldo al costo del motor, sin margen adicional, así que su precio por minuto es exactamente el precio del motor; es fácil comparar tarifas en la página de precios. Un motor multilingüe caro se justifica donde se necesita máxima precisión y hay muchos idiomas; para grandes volúmenes homogéneos, suele ganar un motor local económico afinado para un idioma concreto.
Paso 4. Resuelva la diarización y los canales
Para analizar llamadas, el texto solo no basta: hay que saber quién dijo qué — qué líneas son del operador y cuáles del cliente. Hay dos caminos. Si la grabación es estéreo y los roles están separados por canal (operador en uno, cliente en otro), la separación resulta precisa casi automáticamente — esta es la mejor opción, y conviene definirla desde la etapa de configuración de la telefonía. Si la grabación es mono, los roles los separa la diarización, que divide una pista única en interlocutores.
Tenga en cuenta que la diarización es una operación aparte y una línea de costo aparte, y su calidad con audio telefónico es menor que con audio limpio. Por eso, siempre que sea posible, grabe las llamadas en estéreo con separación por canal: es más preciso y más económico que depender de la diarización sobre una pista mono. Cómo funciona la capa de reconocimiento y etiquetado de roles se explica en la página análisis automático de llamadas.
Paso 5. Elija el modo: tiempo real o procesamiento por lotes
No toda tarea necesita reconocerse al instante. Si analiza un archivo o procesa llamadas después de ocurridas para métricas y control de calidad, no necesita tiempo real — y el procesamiento diferido por lotes suele ser notablemente más económico. En algunos motores, el modo diferido cuesta varias veces menos que el síncrono con la misma calidad, y en volumen eso representa un ahorro considerable.
El tiempo real (reconocimiento en streaming) es necesario donde el texto se requiere durante la propia conversación: un apuntador para el operador, una transcripción en vivo, un agente de voz. Para todo lo demás — posprocesamiento, analítica, etiquetado retroactivo del archivo — elija el modo por lotes. Reducir aún más la factura se logra recortando el silencio antes del reconocimiento (archivo más corto, menos costo) y con una caché de transcripciones: el mismo audio con los mismos parámetros no se reconoce dos veces.
Paso 6. Defina sus requisitos de datos (nube o self-hosted)
El último criterio no es técnico, sino de confianza y regulación. Si por política de la empresa o por requisito legal el audio de las llamadas no puede salir de su perímetro, un motor en la nube no sirve, sin importar su precisión o precio. En ese caso, se opta por reconocimiento self-hosted: el modelo corre en su propia infraestructura y los datos no salen de ella.
Para este escenario encajan motores como Whisper o Vosk, ejecutados en su propia infraestructura: se pueden desplegar localmente y reconocer voz sin pagos por minuto a un proveedor externo y sin enviar audio a la nube. En la plataforma, este modo se implementa mediante un worker local: usted lo descarga y lo ejecuta en su propio entorno, lo empareja con un código, y la transcripción con diarización se ejecutan dentro de su perímetro — el audio no sale de él. Más sobre los modelos de aislamiento de datos y las opciones on-prem en la página de seguridad.
Cómo combinar los criterios
No existe un único motor «mejor», pero sí una forma sencilla de llegar a una decisión. Primero, filtre por restricciones duras: idioma (el motor debe entender bien sus idiomas) y datos (si necesita self-hosted, la nube queda descartada de inmediato). Después, entre los candidatos restantes, verifique la precisión con el audio a 8 kHz de su propio archivo y calcule el costo por minuto de su flujo real. Por último, considere los canales/la diarización y el modo de procesamiento — generan ahorros fáciles de pasar por alto.
Es práctico no atarse a un solo motor para siempre. Distintos escenarios pueden requerir distintos motores: uno caro y preciso para idiomas importantes o llamadas complejas, uno económico por lotes para el flujo masivo, uno self-hosted para datos sensibles. La plataforma permite conectar motores del sistema, aportar su propia clave a un proveedor externo o ejecutar un worker local, así que la elección no es definitiva: puede cambiarla a medida que crece y afinarla con sus propios datos.
Qué sigue
Elegir el motor es la base, no el objetivo final: el texto reconocido vale por lo que se obtiene a partir de él. El siguiente paso es convertir las transcripciones en métricas, temas y control de calidad sobre todas las llamadas a la vez. Si está comparando el enfoque en sí — una plataforma de análisis frente a «solo transcripción» — vea en qué se diferencia el análisis de llamadas de la transcripción.