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 como texto en unos cientos de milisegundos. Pero mantener baja la latencia de STT es tanto un problema de arquitectura como de modelo. Ingenieros deben planificar el transporte, la fragmentación, la detección de fin de intervención y la ruta de captura, ya que cada elemento añade latencia a la ecuación. La ineficiencia en cualquiera de ellos puede agotar tu presupuesto 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 de modelo, admite más de 90 idiomas, acepta audio PCM (8 kHz-48 kHz) y mu-law, e incluye 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 durante la transmisión y cómo capturar y reenviar correctamente el audio.

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 el turno ha terminado.
• Los parciales son provisionales y los finales están confirmados, por lo que debes mostrarlos de forma distinta. 
• Los fragmentos pequeños de PCM, de unos 100 ms, minimizan la latencia hasta el primer resultado parcial.

WebSocket frente a WebRTC para Voz a Texto en Tiempo Real

Antes de transcribir nada, 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 y ordenado sobre TCP que permanece abierto. Abres una conexión, envías tramas binarias de audio y recibes eventos de transcripción. Es sencillo tanto en el cliente como en el servidor, atraviesa los proxies corporativos y cortafuegos 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 rellenar el hueco. En buenas condiciones de red no se aprecia. Cuando hay pérdida de paquetes, se produce bloqueo de cabecera de línea: una breve pausa en la que el audio se acumula y después llega de golpe.

WebRTC está diseñado para medios en tiempo real. Transmite los medios 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 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 vez de leer un flujo de bytes.

Estas son las diferencias principales:

Para la mayoría de casos de uso, WebSocket es la opción adecuada. Úsalo cuando tus clientes tengan buena conectividad 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 al servidor por otro medio. 

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

El resto de esta guía utiliza transporte WebSocket para la conexión al reconocedor, porque mantiene visibles las partes implicadas y es el punto de partida adecuado para la mayoría de equipos. Nada de esto es específico de WebSocket, así que después puedes añadir delante una conexión multimedia WebRTC, descodificar 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 resultados. En su lugar, emite un flujo continuo de estimaciones que se precisan a medida que llega más audio y después las confirma. Comprender la diferencia entre estos dos estados es lo que distingue una transcripción que parece viva de otra que parece fallar. 

Una hipótesis parcial (provisional) es la mejor estimación del modelo con el 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 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 el audio siguiente. Los finales son los que guardas, 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 que el sistema escucha.
• Detección de fin de intervención: Los parciales ofrecen una señal continua de actividad de voz. Junto con VAD, te permiten decidir cuándo ha terminado realmente de hablar la persona.
• 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 los parciales y confirmarlo con los finales, reduciendo el tiempo de respuesta percibido a costa de tener que descartar ocasionalmente ese trabajo.

Muestra los parciales y finales de forma distinta. Un patrón sencillo y eficaz consiste en mantener una única «línea actual» mutable asociada al último parcial y confirmarla en una transcripción de solo anexado cuando llega un resultado 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 empieza a responder el sistema. 

La detección de fin de intervención determina que una intervención ha terminado. Finalizar demasiado pronto corta a usuarios a mitad de frase. Finalizar demasiado tarde deja a un agente en silencio después de que usuario haya acabado claramente.

Scribe v2 Realtime ofrece dos mecanismos complementarios:

• La Detección de Actividad de Voz segmenta el audio según el silencio: El reconocedor detecta cuándo la voz 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 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 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, mediante una acción de «enviar» o según una política externa de toma de turnos.

Ambos mecanismos se combinan bien. Un agente de voz típico usa VAD para funcionar sin manos y ofrece la confirmación manual como alternativa, de modo que 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 un compromiso real sin un valor universalmente correcto:

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

No hay una constante global que puedas usar; 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 sistemas de control por comandos y los agentes transaccionales se benefician de tiempos de espera más cortos junto con la confirmación manual, porque los turnos son breves y claros.
• Quienes hablan varios idiomas o no son nativos hacen más pausas, así que deja más silencio antes de finalizar.

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

Funciones durante la transmisión: 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 los más de 90 que admite, sin que tengas que indicarlo de antemano. El coste es que el modelo necesita un breve fragmento de audio para determinarlo con confianza, por lo que los primeros parciales de una transmisión pueden ser menos estables mientras se identifica el idioma. Si ya conoces el idioma, especificarlo elimina esa ambigüedad y suele producir parciales iniciales más estables.

Diarización de hablantes atribuye el habla a diferentes hablantes e identifica quién dijo qué. En la transcripción por lotes, esto es relativamente fácil 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 entonces, y quizá tenga que revisar una etiqueta asignada al audio inicial cuando escuche más de la voz de ese hablante. 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 tendrán que transportar tanto el modelo como la conexión. Para 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 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 correctamente el formato y el tamaño de fragmento es la mejora más económica disponible para 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 incluyen más detalle acústico: 16 kHz es el mínimo estándar para el reconocimiento de voz y suele bastar; 8 kHz tiene calidad telefónica y pierde contenido de alta frecuencia. Usa la frecuencia que corresponda a tu fuente. No sirve de nada remuestrear audio de telefonía de 8 kHz a 48 kHz, porque esa información no se puede recuperar.

Mu-law a 8 kHz es el formato de telefonía. Si ingieres llamadas de un proveedor como Twilio, el audio llega como mu-law de 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 elemento 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 permiten 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 a 250 ms de audio por fragmento. Como referencia concreta, en 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.

Capturar la entrada del micrófono en el navegador

En el navegador, la herramienta adecuada es la API de Audio web 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 como ocurría con el antiguo ScriptProcessorNode. Su función es convertir las muestras flotantes nativas del navegador a PCM de 16 bits y entregarlas al hilo principal, que las reenvía por WebSocket.

El núcleo del procesador worklet es la conversión de flotante 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: 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 telefónica.

El servidor retransmite el audio 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 hable 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 genera. Los eventos entrantes —ya normalizados por el servidor como { type, text }— controlan el estado de 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 al reconocedor por cliente, mantiene la clave de API en el servidor, reenvía directamente el 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 queda limitado a 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 posterior, la misma conexión al reconocedor funciona sin navegador: lee PCM de cualquier fuente, envíalo al ritmo 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`);
});

Evaluación comparativa 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 hablante, idioma, condiciones acústicas, 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 flota de producción en otra. Ejecuta el arnés de pruebas desde una infraestructura similar a producción, con audio parecido a tu entrada real, e informa de intervalos 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 parecida a producción. Esta es una guía para evaluar comparativamente 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 comparativamente 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 palabras (WER): WER de la transcripción finalizada 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 implementar varios controles en tu experimento para mantener la coherencia.

Estos son los principales controles que debes usar para evaluar 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 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 durante el día; informa de la mediana y de 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 arnés de pruebas y la ruta hasta cada proveedor.

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

Esqueleto del arnés 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 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 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 la misma forma tanto en la referencia como en la hipótesis antes de calcularla, o medirás tu normalizador en lugar del 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 medio (p50/p95), ya que una única muestra está dominada por la variación de red.

Para ponerlo en marcha, necesitas aportar dos cosas. 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 ejecuta las mediciones con ellos. Hazlo desde una máquina representativa de tu despliegue y con audio representativo de tus usuarios, y tendrás una comparación reproducible.

Resumen para lograr Voz a Texto en Tiempo Real 

En este artículo hemos cubierto muchos cambios arquitectónicos que te permiten mejorar tu sistema de forma iterativa y avanzar hacia la Voz a Texto en Tiempo Real.

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

• Transporte: Elige WebSocket por su simplicidad y para redes controladas, y WebRTC cuando necesites tolerancia a pérdidas y captures desde dispositivos de consumidores.
• 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 alternativa y ajusta el umbral de silencio a la interacción en vez de a una constante.
• Funciones durante la transmisión: Activa funciones durante la transmisión 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 usa el formato de origen para telefonía.
• Evaluación comparativa: Ajusta empíricamente los parámetros de precisión frente a latencia con tu propio audio y tu 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 escrito 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 de modelo. Que usuarios perciban esa cifra u otra mayor depende de la arquitectura que lo rodea, que es la parte que controlas. Con 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 consultar la lista completa de funciones e idiomas, y visita las páginas de productos 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 hoy tu primera transcripción.

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