Voz a Texto en Tiempo Real en menos de 200 ms: Guía de arquitectura

La Voz a Texto en Tiempo Real (STT) transcribe activamente el audio mientras una persona habla y devuelve sus palabras en texto en unos pocos cientos de milisegundos. Sin embargo, mantener baja la latencia de STT es un problema tanto de arquitectura como de modelo. Desarrolladores deben planificar el transporte, la fragmentación, la detección de fin de intervención y la ruta de captura, ya que cada uno añade latencia. La ineficiencia en cualquiera de ellos puede agotar tu margen de 200 ms.

Esta guía ofrece un sistema práctico para crear pipelines de Voz a Texto en Tiempo Real desde la capa de transporte. Nos basaremos en Scribe v2 Realtime, que genera transcripciones parciales con una latencia de modelo de unos 150 ms, admite más de 90 idiomas, acepta audio PCM (8 kHz-48 kHz) y mu-law, e incorpora detección de actividad de voz y control de confirmación manual para finalizar segmentos.

Veremos cómo llega el audio al servidor, cómo las hipótesis se convierten en texto confirmado, qué coste tienen las funciones en streaming y cómo capturar y reenviar el audio correctamente.

Resumen

• Crear sistemas de Voz a Texto en Tiempo Real requiere ajustar la arquitectura para mantener baja la latencia en todo el pipeline.
• WebSocket es la opción predeterminada adecuada para la mayoría de pipelines, aunque WebRTC ofrece varias ventajas a cambio de una mayor complejidad.
• La detección de actividad de voz gestiona la segmentación manos libres, mientras que la confirmación manual permite a tus aplicaciones intervenir cuando saben que la intervención ha terminado.
• Los parciales son provisionales y los finales están confirmados, por lo que debes mostrarlos de forma distinta. 
• Los fragmentos PCM pequeños, de unos 100 ms, reducen al mínimo la latencia hasta el primer resultado parcial.

WebSocket frente a WebRTC para Voz a Texto en Tiempo Real

Antes de que se produzca cualquier transcripción, el audio debe viajar desde la fuente hasta el reconocedor. El canal que elijas establece la latencia mínima de todo lo que viene después. Hay dos opciones viables para que el audio llegue a la capa de transcripción.

WebSocket es un canal bidireccional de larga duración, ordenado y fiable sobre TCP. Abres una conexión, envías fotogramas de audio binarios y recibes eventos de transcripción. Es sencillo tanto en el cliente como en el servidor, atraviesa los proxies y cortafuegos corporativos que ya permiten HTTPS, y todos los navegadores y entornos de servidor lo admiten. 

La limitación de WebSocket es que funciona sobre TCP. Si se pierde un paquete, TCP lo retransmite y retiene los datos posteriores hasta que se completa el hueco. En buenas condiciones de red, esto no se nota. Cuando hay pérdida de paquetes, provoca bloqueo de cabecera de línea: una breve pausa en la que el audio se acumula y luego llega de golpe.

WebRTC está diseñado para contenido multimedia en tiempo real. Transmite contenido multimedia a través de UDP (mediante SRTP), por lo que un paquete perdido no detiene el flujo; el pipeline continúa. Incluye un búfer de fluctuación que absorbe las variaciones en el momento de llegada de los paquetes, negocia el cruce de NAT con ICE/STUN/TURN para que puedan conectarse pares detrás de routers e incorpora sus propios mecanismos de captura y codificación de audio. 

Normalmente necesitas servidores TURN para clientes que no pueden conectarse directamente, y el servidor debe terminar un flujo multimedia en lugar de leer un flujo de bytes.

Esta es la comparación de un vistazo:

Para la mayoría de casos de uso, WebSocket es la opción adecuada. Úsalo cuando tus clientes tengan una conectividad aceptable y controles la ruta de captura: pipelines de servidor a servidor, aplicaciones de escritorio, aplicaciones de navegador con banda ancha y la mayoría de backends de centros de contacto donde el audio ya llega a tu servidor por otro medio. 

Elige WebRTC si capturas directamente desde dispositivos de consumo en redes móviles poco fiables, si ya utilizas una pila de WebRTC para audio bidireccional —por ejemplo, un agente de voz que también responde hablando— o si el comportamiento en tiempo real con baja pérdida importa más que la simplicidad de implementación.

El resto de esta guía utiliza transporte WebSocket para la conexión con el reconocedor, porque mantiene visibles las piezas en movimiento y es el punto de partida adecuado para la mayoría de equipos. Nada de esto es específico de WebSocket, así que más adelante puedes añadir delante un tramo multimedia con WebRTC, descodificar el audio a PCM en el servidor y reenviar los mismos fragmentos al pipeline.

Resultados parciales y transcripciones finales: explicación de los resultados provisionales

Un reconocedor en tiempo real no espera a tener una frase completa antes de mostrar resultados. En su lugar, emite un flujo continuo de hipótesis que se afinan a medida que llega más audio y después las confirma. Entender la diferencia entre estos dos estados distingue una transcripción que parece viva de una que parece defectuosa. 

Una hipótesis parcial (provisional) es la mejor estimación del modelo a partir del audio recibido hasta ese momento. Los parciales son inestables por diseño. A medida que llega más audio, el modelo revisa palabras anteriores: «Quiero» puede convertirse en «Quiero dos entradas» cuando el contexto posterior resuelve la ambigüedad. Llegan rápido —a esto se refiere la cifra de latencia de unos 150 ms— y están pensados para sobrescribirse.

Una hipótesis final es un segmento confirmado que no cambiará. Cuando se finaliza un segmento, el reconocedor sigue adelante y las hipótesis posteriores describen audio posterior. Los resultados finales son los que conservas, envías a un LLM o almacenas como transcripción.

La distinción entre parciales y finales determina tres aspectos que harás mal si los confundes:

• Experiencia de usuario: Mostrar parciales hace que una transcripción parezca en directo: usuario ve aparecer las palabras mientras habla, lo que confirma que el micrófono funciona y el sistema está escuchando.
• Detección de fin de intervención: Los parciales te proporcionan una señal continua de actividad de voz. Combinados con VAD, te permiten decidir cuándo la persona que habla se ha detenido realmente.
• Temporización posterior: En un pipeline de agente de voz los pasos son: entrada de audio, Voz a Texto, un LLM, Texto a Voz y salida de audio. Puedes iniciar trabajo especulativo con parciales y confirmarlo con los finales, reduciendo el tiempo de respuesta percibido a costa de tener que descartar ocasionalmente trabajo especulativo.

Muestra los parciales y los finales de forma distinta. Un patrón sencillo y eficaz consiste en mantener una única «línea actual» mutable vinculada al último parcial y confirmarla en una transcripción a la que solo se añaden elementos cuando llega un final:

type TranscriptState = {
  committed: string[]; // finalized segments, never rewritten
  current: string;     // latest partial, overwritten on each update
};

const onPartial = (s: TranscriptState, text: string): TranscriptState =>
  ({ ...s, current: text });

const onFinal = (s: TranscriptState, text: string): TranscriptState =>
  ({ committed: [...s.committed, text], current: "" });

Visualmente, muestra el texto confirmado como texto estable y el actual con un estilo más tenue o en cursiva, para que usuario entienda que aún puede cambiar.

Detección de fin de intervención y detección de actividad de voz (VAD)

Saber qué se ha dicho es solo la mitad del trabajo. Un reconocedor también debe saber cuándo ha terminado una idea. Esa decisión determina cuándo finalizas un segmento y, en un agente, cuándo el sistema empieza a responder. 

La detección de fin de intervención determina que una intervención ha terminado. Finalizar demasiado pronto interrumpe a usuarios a mitad de frase. Finalizar demasiado tarde deja a un agente en silencio cuando usuario ya ha acabado claramente.

Scribe v2 Realtime te ofrece dos mecanismos complementarios:

• La detección de actividad de voz segmenta el audio según los silencios: El reconocedor detecta cuándo el habla da paso a un silencio prolongado y utiliza ese límite para finalizar automáticamente un segmento. VAD es la opción predeterminada adecuada para interfaces conversacionales porque se adapta al ritmo natural del habla sin que tengas que controlar los tiempos manualmente.
• Control de confirmación manual: El control de confirmación manual permite a tu aplicación decidir cuándo finalizar el segmento actual, independientemente del silencio. Envías una señal de confirmación, el reconocedor cierra el segmento actual y genera un resultado final. Es la herramienta adecuada cuando tu aplicación ya sabe que la intervención ha terminado: al soltar un botón de pulsar para hablar, mediante una acción de «enviar» o con una política externa de gestión de turnos.

Los dos mecanismos se complementan bien. Un agente de voz típico utiliza VAD para funcionar manos libres y ofrece la confirmación manual como opción de anulación. Así, no se interrumpe a usuario que hace una pausa para pensar, pero quien pulsa un botón obtiene un límite inmediato.

El umbral de silencio implica una decisión real, sin un valor universalmente correcto:

• Un tiempo de espera de final de habla corto —por ejemplo, finalizar tras unos 200-400 ms de silencio— hace que el sistema parezca ágil. Sin embargo, también interrumpe a usuarios que hacen pausas naturales entre cláusulas, dividiendo una idea en varios segmentos y, en un agente, provocando una respuesta prematura.
• Un tiempo de espera largo —por ejemplo, de unos 800-1200 ms— admite pausas naturales y mantiene las intervenciones intactas, a costa de un retraso perceptible antes de que el sistema reaccione.

No existe una constante global que usar; ajusta el umbral a la interacción:

• El dictado y la toma de notas admiten pausas más largas, porque usuarios piensan a mitad de frase. Prioriza tiempos de espera más largos y apóyate en VAD.
• Los agentes de comando y control y los transaccionales se benefician de tiempos de espera más cortos junto con la confirmación manual, porque los turnos son breves y precisos.
• Quienes hablan varios idiomas o no son nativos hacen más pausas, así que deja más tiempo de silencio antes de finalizar.

Estos consejos te ayudarán a crear un sistema eficaz de detección de fin de intervención y a avanzar hacia la Voz a Texto en Tiempo Real.

Funciones en streaming: detección de idioma y diarización de hablantes

El reconocimiento en streaming puede hacer más que generar palabras. Sin embargo, cada señal adicional que solicitas afecta a la latencia y la estabilidad. La regla general es activar solo lo que necesita la experiencia en directo y dejar el resto para un procesamiento por lotes.

El reconocimiento automático de idioma permite a Scribe v2 Realtime identificar el idioma hablado entre sus más de 90 idiomas compatibles, sin que tengas que indicarlo de antemano. A cambio, el modelo necesita un breve fragmento de audio para determinarlo con seguridad, por lo que los primeros parciales de un flujo pueden ser menos estables mientras se determina el idioma. Si ya conoces el idioma, especificarlo elimina esa ambigüedad y suele generar parciales iniciales más estables.

La diarización de hablantes atribuye el habla a personas distintas e identifica quién ha dicho qué. En la transcripción por lotes, esto es relativamente sencillo porque el modelo ve el archivo completo. En streaming es más difícil: el reconocedor debe asignar una etiqueta de hablante basándose solo en el audio recibido hasta el momento, y puede tener que revisar una etiqueta asignada al audio inicial cuando escucha más voz de esa persona. Trata las etiquetas de hablante en streaming igual que el texto parcial: como provisionales hasta que finalice el segmento.

La temporización a nivel de palabra y el contexto de entidades siguen la misma lógica. Cuantos más metadatos por token solicites, más información tendrán que transportar tanto el modelo como la red. En la mayoría de interfaces en tiempo real, solo necesitas en directo el texto y los límites de segmento; puedes dejar los metadatos detallados para un procesamiento por lotes posterior a la llamada con Scribe v2.

Formatos de audio para streaming: PCM y mu-law

La lógica de transporte y reconocimiento recibe la mayor parte de la atención, pero una proporción sorprendente de errores reales se origina un nivel más abajo: en cómo codificas y fragmentas el audio. Elegir bien el formato y el tamaño de los fragmentos es la forma más económica de reducir la latencia de Voz a Texto.

PCM (lineal, con signo de 16 bits y little-endian) es el formato que debes usar cuando controlas la captura. Las frecuencias de muestreo más altas contienen más detalle acústico: 16 kHz es el mínimo estándar para el reconocimiento de voz y suele ser suficiente; 8 kHz tiene calidad telefónica y pierde contenido de alta frecuencia. Usa la frecuencia que corresponda a tu fuente. No tiene sentido aumentar el muestreo de audio telefónico de 8 kHz a 48 kHz, porque no hay información que recuperar.

Mu-law a 8 kHz es el formato de telefonía. Si recibes llamadas de un proveedor como Twilio, el audio llega como mu-law a 8 kHz y debes reenviarlo en ese formato en lugar de transcodificarlo dos veces. Ajustar el formato al de la fuente evita artefactos de remuestreo y un paso de conversión innecesario.

El tamaño de los fragmentos es el factor que más directamente determina la latencia percibida. Envías el audio en fragmentos y el reconocedor genera parciales a medida que llegan. Los fragmentos más pequeños implican actualizaciones más frecuentes y menor latencia hasta el primer parcial; los más grandes implican menos mensajes y algo más de contexto por inferencia. Un rango práctico es de 20 a 250 ms de audio por fragmento. Como referencia concreta, con PCM mono de 16 bits a 16 kHz, un segundo de audio ocupa 32.000 bytes, así que un fragmento de 100 ms ocupa unos 3.200 bytes.

Captura de la entrada de micrófono en el navegador

En el navegador, la herramienta adecuada es la API web Audio API con un AudioWorklet. El worklet se ejecuta en el hilo de renderizado de audio, recibe audio en fotogramas pequeños y no está sujeto a los bloqueos del hilo principal como ocurría con el antiguo ScriptProcessorNode. Su función es convertir las muestras float nativas del navegador a PCM de 16 bits y entregarlas al hilo principal, que las reenvía mediante WebSocket.

El núcleo del procesador worklet es la conversión de float a PCM:

// pcm-worklet.ts - registered via audioContext.audioWorklet.addModule()
class PCMWorklet extends AudioWorkletProcessor {
  process(inputs: Float32Array[][]) {
    const channel = inputs[0]?.[0]; // mono; Float32, range [-1, 1]
    if (!channel) return true;
    const pcm = new Int16Array(channel.length);
    for (let i = 0; i < channel.length; i++) {
      const s = Math.max(-1, Math.min(1, channel[i]));
      pcm[i] = s < 0 ? s * 0x8000 : s * 0x7fff;
    }
    // Transfer the buffer to the main thread without copying.
    this.port.postMessage(pcm.buffer, [pcm.buffer]);
    return true;
  }
}
registerProcessor("pcm-worklet", PCMWorklet);

El pipeline en código

El pipeline tiene tres componentes: un cliente de navegador que captura el micrófono y transmite PCM a tu servidor; un servidor Node que retransmite el audio a Scribe v2 Realtime y devuelve las transcripciones; y un cliente programable que transmite PCM desde un archivo o una pasarela de telefonía.

El servidor retransmite en vez de exponer directamente el reconocedor al navegador por una razón importante: tu clave de API de ElevenLabs es secreta y nunca debe aparecer en código del lado del cliente. La clave se guarda en el servidor. Si necesitas que el navegador se comunique directamente con el reconocedor, genera en el servidor un token de un solo uso y de corta duración, y entrégaselo al cliente en lugar de la clave de API.

Cliente de navegador

El cliente abre un WebSocket con tu servidor, captura el micrófono mediante el worklet anterior y reenvía cada fotograma PCM en cuanto se genera. Los eventos entrantes —ya normalizados por el servidor como { type, text }— controlan el estado parcial/final descrito antes:

// client.ts - runs in the browser. ws is an open WebSocket to your server.
const audioContext = new AudioContext({ sampleRate: 16000 });
await audioContext.audioWorklet.addModule("pcm-worklet.js");

const mediaStream = await navigator.mediaDevices.getUserMedia({
  audio: { channelCount: 1, echoCancellation: true, noiseSuppression: true },
});

const source = audioContext.createMediaStreamSource(mediaStream);
const worklet = new AudioWorkletNode(audioContext, "pcm-worklet");

// Forward each PCM frame to the server the moment it is produced.
worklet.port.onmessage = (e: MessageEvent<ArrayBuffer>) => {
  if (ws.readyState === WebSocket.OPEN) ws.send(e.data);
};
source.connect(worklet);

// Manual commit: tell the server to finalize the current segment.
const commit = () => ws.send(JSON.stringify({ type: "commit" }));

Retransmisión del servidor

El servidor abre una conexión con el reconocedor por cada cliente, mantiene la clave de API en el servidor, reenvía directamente PCM binario y normaliza los eventos del reconocedor al formato estable { type, text } que consume el cliente:

// server.ts - Node, using the `ws` library. ELEVENLABS_API_KEY and the
// recognizer URL come from the environment; see the Speech to Text reference
// for the exact path and query parameters.
import { WebSocketServer, WebSocket } from "ws";

new WebSocketServer({ port: 8080 }).on("connection", (client) => {
  // The API key stays on the server, never on the wire to the browser.
  const recognizer = new WebSocket(process.env.RECOGNIZER_WSS_URL!, {
    headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY! },
  });

  // Browser -> recognizer: forward binary PCM, translate control messages.
  client.on("message", (data, isBinary) => {
    if (recognizer.readyState !== WebSocket.OPEN) return;
    if (isBinary) recognizer.send(data); // raw PCM bytes
    else if (JSON.parse(data.toString()).type === "commit")
      recognizer.send(sendCommit());
  });

  // Recognizer -> browser: normalize events into a stable shape.
  recognizer.on("message", (raw) => {
    const event = parseRecognizerEvent(raw.toString());
    if (event && client.readyState === WebSocket.OPEN)
      client.send(JSON.stringify(event));
  });

  // ... open handshake, queueing pre-open audio, and teardown on close/error
});

Todo lo específico de la ruta de API se concentra en las dos funciones adaptadoras siguientes. Sustituye los nombres de campo por los exactos de la referencia de Voz a Texto; el resto del pipeline no cambia:

// The single place that knows the recognizer's wire format.
const sendCommit = (): string => JSON.stringify({ type: "commit" });

type NormalizedEvent =
  | { type: "partial"; text: string }
  | { type: "final"; text: string }
  | { type: "vad"; speaking: boolean };

function parseRecognizerEvent(raw: string): NormalizedEvent | null {
  const msg = JSON.parse(raw);
  if (msg.is_final === true || msg.type === "final")
    return { type: "final", text: msg.text ?? "" };
  if (msg.type === "vad") return { type: "vad", speaking: !!msg.speaking };
  if (typeof msg.text === "string")
    return { type: "partial", text: msg.text };
  return null;
}

Cliente de backend programable

Para pipelines de backend y para la prueba comparativa de abajo, la misma conexión con el reconocedor funciona sin navegador: lee PCM desde cualquier fuente, ajusta su ritmo a la cadencia de fragmentos en tiempo real y recibe los eventos. La clave de API y la URL proceden del entorno, igual que en el servidor.

// stream-stt.ts - pace ~100ms chunks at real time, then commit the tail.
const SAMPLE_RATE = 16000, CHUNK_MS = 100;
const CHUNK_BYTES = (SAMPLE_RATE * 2 * CHUNK_MS) / 1000; // 3200 bytes
const ws = new WebSocket(process.env.RECOGNIZER_WSS_URL!, {
  headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY! },
});

// Send: walk the PCM buffer in 100ms chunks, sleeping between to mimic a
// live source. For audio that already arrives in real time, drop the sleep.
async function sendAudio(pcm: Buffer) {
  for (let off = 0; off < pcm.length; off += CHUNK_BYTES) {
    ws.send(pcm.subarray(off, off + CHUNK_BYTES));
    await new Promise((r) => setTimeout(r, CHUNK_MS));
  }
  ws.send(JSON.stringify({ type: "commit" })); // finalize the trailing segment
}

// Receive: print partials in place, append finals.
ws.on("message", (raw) => {
  const e = parseRecognizerEvent(raw.toString());
  if (e?.type === "final") console.log(`[final]   ${e.text}`);
  else if (e?.type === "partial") process.stdout.write(`[partial] ${e.text}\r`);
});

Medición de la latencia de Voz a Texto y la tasa de error de palabra

Tanto la latencia como la tasa de error de palabra varían según quien habla, el idioma, las condiciones acústicas, la duración del audio, la ruta de red hasta la región más cercana de cada proveedor y la carga actual de cada servicio. 

Un resultado medido desde un portátil en una ciudad no se puede generalizar a tu infraestructura de producción en otra. Ejecuta el harness desde una infraestructura similar a la de producción, con audio parecido a tu entrada real, e informa de rangos y distribuciones en lugar de cifras únicas.

Las únicas cifras de latencia y precisión que importan son las que mides con tu propio audio desde una infraestructura similar a la de producción. Aquí tienes una guía para medir la latencia de Voz a Texto.

Qué medir para la latencia de Voz a Texto

Estas son las principales métricas que debes medir al evaluar la latencia de Voz a Texto en Tiempo Real:

• Tiempo hasta el primer parcial: Desde el envío del primer fragmento de audio hasta la recepción del primer parcial no vacío.
• Retraso de parcial a final: Desde el último fragmento de audio de una intervención hasta la hipótesis final.
• Tasa de error de palabra (WER): WER de la transcripción final frente a una referencia humana, calculada de forma idéntica en todos los sistemas.
• Cambios de estabilidad: Cuántos parciales se reescriben antes de finalizar. Esta medida indica cuánto parecerá cambiar la interfaz en directo.

Controles

Para evitar datos poco fiables, debes incorporar varios controles a tu experimento para mantener la coherencia.

Estos son los principales controles que debes utilizar para medir la latencia de Voz a Texto:

• Audio idéntico: Usa los mismos archivos, la misma frecuencia de muestreo y la misma codificación en todos los sistemas.
• Ritmo idéntico: Transmite todos los sistemas con la misma cadencia de fragmentos en tiempo real —por ejemplo, fragmentos de 100 ms—.
• Repite e informa de las distribuciones: Ejecuta cada archivo muchas veces a lo largo del día; informa de la mediana y la cola (p50/p95).
• Referencias y puntuación idénticas: Normaliza el texto de la misma forma —mayúsculas, puntuación y números— antes de calcular el WER.
• Indica la región y la red: Especifica dónde se ejecutó el harness y la ruta hasta cada proveedor.

Al mantener iguales todos estos elementos, obtendrás métricas más precisas.

Estructura del harness

El núcleo de medición acepta un adaptador de proveedor y registra el tiempo hasta el primer parcial, el retraso de finalización y los cambios en los parciales:

// benchmark.ts - measurement core; one StreamFn adapter per provider.
type StreamFn = (
  audioPath: string,
  onEvent: (kind: "partial" | "final", text: string) => void,
  result: RunResult
) => Promise<void>; // adapter sets result.lastChunkSentAt on the final chunk

interface RunResult {
  firstPartialMs?: number;
  finalLagMs?: number;
  hypothesis: string;
  partialEdits: number;
  lastChunkSentAt: number;
  startedAt: number;
}

async function measure(streamFn: StreamFn, audioPath: string): Promise<RunResult> {
  const result: RunResult = {
    hypothesis: "", partialEdits: 0, lastChunkSentAt: 0,
    startedAt: performance.now(),
  };
  let prevPartial = "";

  await streamFn(audioPath, (kind, text) => {
    const now = performance.now();
    if (kind === "partial") {
      if (text && result.firstPartialMs === undefined)
        result.firstPartialMs = now - result.startedAt;
      if (text !== prevPartial) { result.partialEdits++; prevPartial = text; }
    } else { // final
      result.hypothesis = result.hypothesis ? `${result.hypothesis} ${text}` : text;
      if (result.lastChunkSentAt)
        result.finalLagMs = now - result.lastChunkSentAt;
    }
  }, result);

  return result;
}

La tasa de error de palabra es una distancia de Levenshtein estándar a nivel de token sobre texto normalizado. Convierte a minúsculas y elimina la puntuación de la misma forma tanto en la referencia como en la hipótesis antes de calcularla; de lo contrario, medirás tu normalizador y no el modelo. Ejecuta esta medida en un bucle que procese cada archivo unas 10 veces por proveedor e informe de la mediana del tiempo hasta el primer parcial y del WER mediano (p50/p95), ya que una sola muestra está dominada por la variación de red.

Para ejecutarlo, debes proporcionar dos elementos. Primero, escribe un adaptador StreamFn para cada sistema. El cliente programable anterior ya es uno; los adaptadores para los demás siguen el mismo contrato (audioPath, onEvent, result) y establecen result.lastChunkSentAt cuando se envía el fragmento de audio final. Segundo, carga tus archivos de audio y referencias y llama a measure con ellos. Ejecútalo desde una máquina que represente tu despliegue, con audio que represente a tus usuarios, y tendrás una comparación reproducible.

Resumen: cómo conseguir Voz a Texto en Tiempo Real 

En este artículo hemos cubierto muchos cambios de arquitectura que te permiten mejorar iterativamente tu sistema y avanzar hacia la Voz a Texto en Tiempo Real.

Un sistema de STT en tiempo real listo para producción se reduce a unas pocas decisiones:

• Transporte: Elige WebSocket por su simplicidad y para redes controladas, y WebRTC cuando necesites tolerancia a pérdidas y captures desde dispositivos de consumo.
• Parciales y finales: Trata los parciales como provisionales y los finales como confirmados, y muéstralos de forma distinta para que usuarios confíen en el texto en directo.
• Detección de fin de intervención: Usa VAD para la segmentación manos libres, la confirmación manual como opción de anulación y ajusta el umbral de silencio a la interacción, en lugar de utilizar una constante.
• Funciones en streaming: Activa las funciones en streaming solo cuando la experiencia en directo las necesite y deja el resto para un procesamiento por lotes con Scribe v2.
• Formato de audio: Captura en fotogramas PCM pequeños, envía fragmentos de unos 100 ms y ajusta el formato al de la fuente para telefonía.
• Pruebas comparativas: Ajusta empíricamente el equilibrio entre precisión y latencia con tu propio audio y tu métrica objetivo.
• Seguridad de la API: Guarda tu clave de API en el servidor o genera tokens de un solo uso para conexiones directas de clientes.

Si quieres ver cómo optimizar la latencia de un agente de voz, también hemos preparado una guía para ti.

Crea sistemas de Voz a Texto en Tiempo Real con Scribe v2 Realtime

Scribe v2 Realtime genera parciales con una latencia de modelo de unos 150 ms. Que usuarios perciban esa cifra u otra mayor depende de la arquitectura que la rodea, que es la parte que controlas. Al aplicar las estrategias de este artículo, crearás una arquitectura de pipeline mejorada que reduce la latencia y mejora la experiencia de cliente. 

Para profundizar, consulta la descripción general de las capacidades de Voz a Texto, revisa nuestra referencia de modelos para ver la lista completa de funciones e idiomas y visita las páginas de producto en tiempo real: API de Voz a Texto en Tiempo Real y Voz a Texto en Tiempo Real.

Cuando estés listo para empezar, crea una cuenta gratuita de ElevenLabs y transmite hoy tu primera transcripción.

Preguntas frecuentes sobre la latencia de Voz a Texto en Tiempo Real