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

La Voz a Texto (STT) en tiempo real transcribe activamente el audio mientras una persona habla y devuelve sus palabras en forma de texto en unos cientos de milisegundos. Sin embargo, mantener baja la latencia de STT es tanto un problema de arquitectura como de modelo. Desarrolladores deben planificar el transporte, la fragmentación, la detección de final de intervención y la ruta de captura, ya que cada uno añade latencia a la ecuación. 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. Tomaremos como referencia Scribe v2 Realtime, que genera transcripciones parciales con unos 150 ms de latencia del modelo, 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 evolucionan las hipótesis hasta convertirse 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, y la confirmación manual permite a tus aplicaciones intervenir cuando saben que el turno ha terminado.
• Los parciales son provisionales y los finales están confirmados, por lo que debes mostrarlos de forma diferente. 
• Los fragmentos PCM pequeños, de unos 100 ms, minimizan la latencia hasta el primer parcial.

WebSocket frente a WebRTC para Voz a Texto en tiempo real

Antes de que haya 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, fiable, ordenado y persistente sobre TCP. Abres una conexión, envías tramas de audio binarias y recibes eventos de transcripción. Es sencillo tanto en el cliente como en el servidor, atraviesa los proxies corporativos y firewalls que ya permiten HTTPS, y es compatible con todos los navegadores y entornos de servidor. 

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

WebRTC se diseñó para contenido multimedia en tiempo real. Transmite contenido multimedia sobre 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 variaciones en el momento de llegada de los paquetes, negocia el cruce de NAT con ICE/STUN/TURN para que puedan conectarse pares tras routers e incorpora sus propios mecanismos de captura y codificación de audio. 

Normalmente necesitarás servidores TURN para clientes que no puedan conectarse directamente, y el servidor tendrá que terminar un flujo multimedia en vez de leer un flujo de bytes.

Este es el equilibrio de un vistazo:

Para la mayoría de casos de uso, WebSocket es la opción adecuada. Úsalo cuando tus clientes tengan una conectividad decente y controles la ruta de captura: pipelines entre servidores, 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 otros medios. 

Elige WebRTC cuando captures directamente desde dispositivos de consumo en redes móviles poco fiables, cuando ya uses una pila WebRTC para audio bidireccional —por ejemplo, un agente de voz que también responde hablando— o cuando el comportamiento en tiempo real tolerante a pérdidas importe más que la sencillez de implementación.

El resto de esta guía usa transporte WebSocket para la conexión con el reconocedor, ya que mantiene visibles las partes móviles y es el mejor punto de partida para la mayoría de equipos. Nada de esto es específico de WebSocket: más adelante puedes añadir delante una conexión multimedia WebRTC, decodificar el audio a PCM en el servidor y reenviar los mismos fragmentos al pipeline.

Parciales y transcripciones finales: resultados provisionales explicados

Un reconocedor en tiempo real no espera a tener una frase completa antes de mostrar texto. En su lugar, emite un flujo continuo de estimaciones que se afinan a medida que llega más audio y luego las confirma. Entender la diferencia entre estos dos estados es lo que separa una transcripción que parece viva de otra que parece defectuosa. 

Una hipótesis parcial (provisional) es la mejor estimación del modelo basándose en el audio recibido hasta el 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 —esto es lo que describe la cifra de unos 150 ms de latencia— y están pensados para sobrescribirse.

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

La distinción entre parciales y finales determina tres aspectos en los que te equivocarás si la difuminas:

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

Muestra parciales y finales de manera 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 de solo anexado cuando llegue 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 lo confirmado como texto estable y lo actual con un estilo más claro o en cursiva, para que el usuario entienda que aún puede cambiar.

Detección de final 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 empieza a responder el sistema. 

La detección de final de intervención decide que una emisión ha terminado. Finalizar demasiado pronto interrumpe a usuarios a mitad de frase. Finalizar demasiado tarde deja a un agente en silencio después de que el usuario haya terminado claramente.

Scribe v2 Realtime te proporciona dos mecanismos complementarios:

• La Detección de Actividad de Voz segmenta el audio según el silencio: El reconocedor detecta cuándo el habla da paso a un silencio sostenido 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 el tiempo 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 emite un resultado final. Es la herramienta adecuada cuando tu aplicación ya sabe que el turno ha terminado: al soltar un botón de pulsar para hablar, realizar una acción de «enviar» o aplicar una política externa de turnos.

Ambos mecanismos funcionan bien juntos. Un agente de voz habitual usa VAD para funcionar manos libres y ofrece la confirmación manual como alternativa, de modo que no interrumpe a quien hace una pausa para pensar, pero proporciona un límite inmediato a quien pulsa un botón.

El umbral de silencio implica un equilibrio real, sin un valor universalmente correcto:

• Un tiempo de espera tras el final de voz corto —por ejemplo, finalizar después de unos 200-400 ms de silencio— hace que el sistema parezca ágil. También puede interrumpir a usuarios que hacen pausas naturales entre cláusulas, dividir una idea en varios segmentos y, en un agente, desencadenar una respuesta prematura.
• Un tiempo de espera largo —por ejemplo, de unos 800-1200 ms— tolera las pausas naturales y mantiene intactas las emisiones, a costa de un retraso perceptible antes de que reaccione el sistema.

No hay una constante global que puedas usar aquí; ajusta el umbral a la interacción:

• El dictado y la toma de notas toleran 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 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 margen de silencio antes de finalizar.

Estos consejos te ayudarán a crear un sistema eficaz de detección de final de intervención y 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. Como regla general, activa solo lo que necesita la experiencia en directo y deja 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. El coste es que el modelo necesita un breve tramo de audio para determinarlo con confianza, 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 proporcionar parciales iniciales más estables.

Diarización de hablantes atribuye el habla a distintos hablantes e identifica quién dijo qué. En la transcripción por lotes, esto es comparativamente sencillo porque el modelo ve el archivo completo. En streaming es más difícil: el reconocedor debe asignar una etiqueta de hablante usando solo el audio recibido hasta ese momento, y una etiqueta dada al audio inicial puede requerir revisión cuando escuche más de la voz de esa persona. Trata las etiquetas de hablantes en streaming igual que el texto parcial: como provisionales hasta que el segmento se finalice.

La sincronizació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 conexión. Para la mayoría de interfaces en tiempo real, basta con tener 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 acapara 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 controles la captura. Las frecuencias de muestreo más altas aportan 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 altas frecuencias. Usa la frecuencia que corresponda a tu fuente. No tiene sentido aumentar el muestreo de audio de telefonía a 8 kHz hasta 48 kHz, porque esa información no existe y no se puede 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 a 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 audio en fragmentos y el reconocedor produce parciales a medida que estos 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 intervalo práctico es de 20-250 ms de audio por fragmento. Como referencia, con PCM mono de 16 bits a 16 kHz, un segundo de audio son 32.000 bytes, por lo que un fragmento de 100 ms ocupa unos 3.200 bytes.

Captura de la entrada del 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 tramas pequeñas y no sufre los bloqueos del hilo principal que afectaban al 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 partes móviles: un cliente de navegador que captura el micrófono y transmite PCM a tu servidor, un servidor Node que retransmite 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 lugar de exponer el reconocedor directamente al navegador por una razón importante: tu clave de API de ElevenLabs es secreta y nunca debe aparecer en código del cliente. El servidor guarda la clave. Si necesitas que el navegador se comunique directamente con el reconocedor, genera en el servidor un token de un solo uso y 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 trama PCM en cuanto se produce. Los eventos entrantes —ya normalizados por el servidor como { type, text }— actualizan 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" }));

Relay del servidor

El servidor abre una conexión con el reconocedor por cliente, mantiene la clave de API en el servidor, reenvía PCM binario directamente y normaliza los eventos del reconocedor en el 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 limita a las dos funciones adaptadoras siguientes. Sustituye los nombres de los campos 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 siguiente, la misma conexión con el reconocedor funciona sin navegador: lee PCM de cualquier fuente, marca el ritmo según la cadencia de fragmentos en tiempo real y recibe los eventos. La clave de API y la URL proceden del entorno, como 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`);
});

Comparación de la latencia de Voz a Texto y la tasa de error de palabras

Tanto la latencia como la tasa de error de palabras varían según el hablante, el idioma, las condiciones acústicas, la duración del audio, tu 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 banco de pruebas desde una infraestructura similar a producción, con audio que se parezca a tu entrada real, e informa de intervalos y distribuciones en vez 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 producción. Esta es una guía para comparar 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 comparar 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 emisión hasta la hipótesis final.
• Tasa de error de palabras (WER): WER de la transcripción finalizada respecto 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 usar al comparar 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.
• Cadencia idéntica: Transmite a 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 del mismo modo —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 banco de pruebas y la ruta hasta cada proveedor.

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

Estructura del banco de pruebas

El núcleo de medición recibe un adaptador de proveedor y registra el tiempo hasta el primer parcial, el retraso de finalización y los cambios de 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 palabras es una distancia de Levenshtein estándar a nivel de token sobre texto normalizado. Convierte a minúsculas y elimina la puntuación de igual forma en la referencia y en la hipótesis antes de calcularla; de lo contrario, medirás tu normalizador en vez del modelo. Incluye esta medida en un bucle que ejecute cada archivo unas 10 veces por proveedor e informe de la mediana del tiempo hasta el primer parcial y del WER medio (p50/p95), ya que una sola muestra está dominada por la variación de red.

Para hacerlo funcionar, debes proporcionar dos elementos. Primero, escribe un adaptador StreamFn por 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 último fragmento de audio. Segundo, carga tus archivos de audio y referencias, y llama a las mediciones 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 lograr Voz a Texto en tiempo real 

Hemos abordado muchos cambios de arquitectura en este artículo, que te permitirán mejorar iterativamente tu sistema y acercarte a la Voz a Texto en tiempo real.

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

• Transporte: Elige WebSocket para simplificar y usar 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 diferente para que usuarios confíen en el texto en directo.
• Detección de final de intervención: Usa VAD para la segmentación manos libres, la confirmación manual como alternativa y ajusta el umbral de silencio a la interacción en lugar de a una constante.
• Funciones en streaming: Activa funciones en streaming solo cuando las necesite la experiencia en directo y deja el resto para un procesamiento por lotes con Scribe v2.
• Formato de audio: Captura en tramas PCM pequeñas, envía fragmentos de unos 100 ms y ajusta el formato a la fuente de telefonía.
• Comparación: Ajusta empíricamente los parámetros de precisión frente a latencia con tu propio audio y métrica objetivo.
• Seguridad de la API: Mantén 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 en 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 unos 150 ms de latencia del modelo. Que usuarios experimenten esa cifra o una 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 del cliente. 

Para profundizar, consulta el resumen de capacidades de Voz a Texto, revisa nuestra referencia de modelos para consultar 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 crear, crea una cuenta gratuita de ElevenLabs y transmite tu primera transcripción hoy mismo.

Preguntas frecuentes sobre la latencia de Voz a Texto en tiempo real