Seis Proveedores de Transcripción, Una API

Elegir un proveedor de voz a texto no es una decisión que se toma una sola vez. La precisión en su dominio, el precio por hora, los idiomas que necesita, si el proveedor firmará un DPA con los datos almacenados en la UE, y qué tan bien funciona la separación de interlocutores cuando tres personas hablan al mismo tiempo: todo esto cambia, y la respuesta no es la misma para cada cliente.

Así que dejamos de elegir. Usted elige el proveedor por bot y puede cambiar de opinión en una grabación que ya tiene.

Qué puede elegir

ElevenLabs es solo streaming. Los otros cinco hacen ambos.

Batch es lo que la mayoría de las personas necesitan: la reunión termina, el audio se envía, un webhook devuelve la transcripción con etiquetas de interlocutor y tiempos a nivel de palabra. Live significa segmentos de transcripción que llegan por un WebSocket mientras la reunión aún está en curso, para cualquier cosa que deba reaccionar en tiempo real.

Se configuran de forma independiente, y puede ejecutar ambos en el mismo bot con diferentes proveedores si desea un feed en vivo rápido y una transcripción final más precisa.

Batch

{
  "meeting_url": "https://meet.google.com/abc-defg-hij",
  "bot_name": "Recording Bot",
  "transcription_enabled": true,
  "transcription_config": {
    "provider": "speechmatics",
    "region": "eu2",
    "api_key": null,
    "custom_params": null
  }
}

Cuatro campos. provider tiene como valor predeterminado "gladia" si lo omite. region, api_key y custom_params tienen como valor predeterminado null y se describen a continuación.

transcription_config es obligatorio cuando transcription_enabled es true, y se ignora cuando es false.

Una vez que el bot termina, transcription_provider y transcription_ids se devuelven en el registro del bot y en el payload del webhook, y GET /v2/bots/:bot_id/status reporta transcription_status en vivo consultado directamente del proveedor: not-applicable, not-started, queued, processing, done o error.

Fijación de región

La mayoría de estos proveedores operan en más de una región, y para muchos de nuestros clientes ese es el factor determinante.

Si envía una región que el proveedor no tiene, recibirá un error 400 al crear el bot con los valores permitidos listados, en lugar de una sorpresa más adelante. La API batch de Gladia es solo global, y pasar region con provider: "gladia" en la configuración batch se rechaza por ese motivo. Su API live sí tiene regiones.

Si deja region en null, elegimos un valor predeterminado razonable: eu para Deepgram y AssemblyAI, eu1 para Speechmatics, us para Soniox.

Si necesita que el audio nunca salga de una jurisdicción, combine esto con traiga su propio almacenamiento. Los proveedores obtienen el audio desde una URL firmada en el bucket, por lo que la ubicación del bucket y la región del proveedor juntos determinan a dónde va realmente el audio.

Traiga su propia key

Pase api_key y usaremos su cuenta con ese proveedor en lugar de la nuestra.

{
  "transcription_config": {
    "provider": "deepgram",
    "region": "eu",
    "api_key": "your-deepgram-key"
  }
}

Las keys se cifran con AES-256-GCM antes de almacenarse y permanecen cifradas en tránsito hacia el bot, que las descifra en el punto de uso. Cuando elimina los datos de un bot, la key almacenada se sobreescribe.

Hay dos razones para usarlo. La primera es el costo: la transcripción con nuestra key cobra 0,25 tokens por hora; con la suya, 0,05. La segunda es que algunas cosas solo son posibles en su propia cuenta, como un vocabulario personalizado que haya entrenado o un contrato con términos que nosotros no tenemos.

BYOK está disponible en todos los planes, incluido Pay as You Go. Pase su API key del proveedor en transcription_config; no se requiere actualización de plan.

Opciones del proveedor, pasadas directamente

Deliberadamente no construimos una capa de opciones normalizadas. Cada proveedor tiene funcionalidades que los demás no tienen, y reducirlas a un denominador común significaría descartar la razón por la que eligió ese proveedor.

custom_params se envía al proveedor más o menos tal como lo escribió:

{
  "transcription_config": {
    "provider": "speechmatics",
    "region": "eu2",
    "custom_params": {
      "transcription_config": {
        "language": "en",
        "diarization": "speaker",
        "operating_point": "enhanced"
      }
    }
  }
}

La notación de puntos también funciona, si es más fácil de construir:

{ "custom_params": { "diarization_config.min_speakers": 2 } }

En la configuración live, se desanida antes de la validación, de modo que se valida la forma que el proveedor recibirá realmente. En la configuración batch, la clave plana se valida tal como se escribió y se desanida más tarde, en el momento del envío.

En la configuración live, cuatro campos son establecidos por el pipeline y se rechazan si los envía: encoding, sample_rate, bit_depth, channels. La frecuencia de muestreo en particular se negocia por proveedor a partir del audio de la reunión, por lo que sobreescribirla rompería el stream. Use streaming_config.audio_frequency en su lugar.

La separación de interlocutores está activada por defecto, porque sin ella obtendrá un bloque de texto sin etiquetas de interlocutor, y al menos un proveedor silenciosamente no devuelve ningún enunciado a menos que se lo solicite. Un valor explícito en custom_params tiene prioridad.

El problema: batch y live aceptan formas diferentes

Esto es lo que le cuesta a la gente una tarde entera, así que vale la pena decirlo claramente. Para el mismo proveedor, la API live y la API batch no aceptan la misma forma de parámetros.

Gladia es el ejemplo más claro. Batch acepta la configuración de traducción en el nivel superior. Live la quiere anidada bajo realtime_processing:

{
  "streaming_config": {
    "mode": "transcription",
    "output_url": "wss://your-app.example.com/transcripts",
    "audio_frequency": 24000,
    "transcription": {
      "provider": "gladia",
      "region": "eu-west",
      "api_key": "your-gladia-key",
      "custom_params": {
        "language_config": { "languages": ["ru"] },
        "realtime_processing": {
          "translation": true,
          "translation_config": { "target_languages": ["en"] }
        }
      }
    }
  }
}

Los parámetros live se validan en modo estricto, porque las API de sesión live rechazan claves desconocidas directamente y preferimos fallar en la creación del bot que fallar en su reunión. Cuando envía una clave que pertenece un nivel más abajo, el error le indica dónde va:

'translation' is not a top-level field of the gladia live API —
did you mean 'realtime_processing.translation'?
(the live API shape differs from batch)

Tanto los parámetros batch como los live se verifican contra el schema propio de cada proveedor al crear el bot, de modo que un error tipográfico devuelve un 400 en un segundo en lugar de una transcripción fallida una hora después. Dos advertencias sobre qué tan estricto es esto. El análisis batch es permisivo, por lo que una clave batch desconocida pasa la validación y se reenvía al proveedor; solo live rechaza claves desconocidas. Y los parámetros live de ElevenLabs se pasan sin validación, porque no hay un schema publicado contra el cual verificarlos.

Salida live

Con mode: "transcription", abrimos la sesión del proveedor, le enviamos el audio de la reunión y reenviamos los eventos a su output_url como JSON:

{
  "event": "transcript.segment",
  "bot_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "data": {
    "text": "so the migration lands Thursday",
    "isFinal": true,
    "utteranceStart": 12.44,
    "utteranceEnd": 14.91,
    "confidence": 0.97,
    "speaker": { "name": "Alice", "id": 1 },
    "words": []
  }
}

También session.started con el proveedor que se utilizó, translation cuando lo haya solicitado, y error. Enviamos un ping cada 30 segundos para evitar que los intermediarios cierren un socket inactivo.

Una restricción: las sesiones live con nuestra platform key están limitadas a un conjunto gestionado de proveedores, actualmente Gladia. Cualquier otro proveedor para transcripción live necesita una BYOK key, y lo rechazamos en la creación del bot con FST_ERR_STREAMING_TRANSCRIPTION_KEY_UNAVAILABLE en lugar de descubrirlo cuando la reunión comienza.

Cambiar de opinión

POST /v2/bots/:bot_id/retranscribe

{
  "transcription": {
    "provider": "assemblyai",
    "region": "eu",
    "api_key": "your-assemblyai-key"
  }
}

El audio almacenado se reenvía a un proveedor diferente y la configuración del bot se actualiza. Así es como se comparan dos proveedores en sus propias reuniones en lugar de en su audio de demostración, y así es como se recupera una transcripción que falló.

Al eliminar los datos de un bot, la transcripción también se elimina del proveedor, con ?delete_from_provider=true (el valor predeterminado), usando su propia key donde la haya proporcionado.

Qué ocurre cuando un proveedor tiene un mal día

Un envío fallido se reintenta dos veces, a los 5 y 15 segundos, para un total de tres intentos. Solo los errores en los que un reintento podría funcionar son elegibles: rate limits, errores 5xx, tiempos de espera de conexión y polling, fallas a nivel de red, y el caso en que el proveedor devolvió un 2xx con un body que no contiene ningún job id. Los errores de autenticación, la entrada no válida y las operaciones no admitidas nunca se reintentan, porque fallarán de forma idéntica la segunda vez.

Cada reintento rota el callback secret antes de volver a enviar. Esto cierra una condición de carrera real: si el proveedor aceptó realmente un trabajo cuya respuesta expiró en nuestro extremo, su callback llega contra un secret que ya no existe y es rechazado, en lugar de competir con el trabajo reintentado y producir dos transcripciones para un mismo fragmento.

No hay conmutación automática a un segundo proveedor, y prefiero decirlo claramente en lugar de que lo descubra durante un incidente. Si el proveedor que eligió falla después de los reintentos, el bot termina en failed con TRANSCRIPTION_FAILED, y la grabación y los artefactos de audio siguen ahí. La recuperación es una llamada retranscribe, opcionalmente nombrando un proveedor diferente. Cambiar de proveedor silenciosamente significaría una transcripción en una jurisdicción con la que no acordó, a un precio con el que no acordó, por lo que es una decisión que dejamos en sus manos.

Relacionado

• Traiga Su Propio Almacenamiento — controle dónde vive realmente el audio que lee el proveedor
• Referencia de la API de Meeting BaaS