Transcrição de Voz em Tempo Real em menos de 200ms: Guia de arquitetura

A transcrição de voz em tempo real (STT) transcreve ativamente o áudio enquanto uma pessoa fala, retornando suas palavras em texto em poucas centenas de milissegundos. Mas manter baixa a latência de STT é tanto um desafio de arquitetura quanto de modelo. Os engenheiros precisam planejar o transporte, a divisão em chunks, a detecção de fim de fala e o caminho de captura, pois cada um adiciona latência à equação. A ineficiência em qualquer um deles pode estourar seu orçamento de 200 ms.

Este guia apresenta um sistema prático para criar pipelines de transcrição de voz em tempo real a partir da camada de transporte. Vamos usar como base o Scribe v2 Realtime, que produz transcrições parciais com cerca de 150 ms de latência do modelo, oferece suporte a mais de 90 idiomas, aceita áudio PCM (8 kHz a 48 kHz) e mu-law e disponibiliza Detecção de Atividade de Voz e controle manual de commit para finalizar segmentos.

Vamos acompanhar como o áudio chega ao servidor, como as hipóteses evoluem para texto confirmado, qual é o custo dos recursos durante o streaming e como capturar e encaminhar áudio corretamente.

Resumo

• Criar sistemas de transcrição de voz em tempo real exige ajustes finos na arquitetura para manter a latência baixa em todo o pipeline.
• O WebSocket é a escolha padrão certa para a maioria dos pipelines, embora o WebRTC ofereça vários benefícios com mais complexidade.
• A Detecção de Atividade de Voz gerencia a segmentação sem usar as mãos, e o commit manual dá aos seus aplicativos uma substituição quando eles sabem que a vez terminou.
• As parciais são provisórias e as finais são confirmadas, então você deve renderizá-las de formas diferentes. 
• Pequenos chunks de PCM de cerca de 100 ms minimizam a latência até a primeira parcial.

WebSocket vs. WebRTC para transcrição de voz em tempo real

Antes de qualquer transcrição, o áudio precisa viajar da fonte até o reconhecedor. O canal escolhido define a latência mínima para tudo o que vem depois. Há duas opções viáveis para o áudio chegar à camada de transcrição.

WebSocket é um canal bidirecional, confiável, ordenado e persistente sobre TCP. Você abre uma conexão, envia frames binários de áudio e recebe eventos de transcrição. Ele é simples tanto no cliente quanto no servidor, atravessa os proxies corporativos e firewalls que já permitem HTTPS, e é suportado por todos os navegadores e runtimes de servidor. 

A limitação do WebSocket é que ele usa TCP. Se um pacote se perde, o TCP o retransmite e retém dados posteriores até preencher a lacuna. Em boas condições de rede, isso não é perceptível. Com perda de pacotes, ocorre bloqueio de linha de frente: uma breve pausa em que o áudio se acumula e depois chega em uma rajada.

O WebRTC foi criado para mídia em tempo real. Ele transmite mídia por UDP (via SRTP), portanto um pacote perdido não interrompe o stream; o pipeline continua. Inclui um buffer de jitter que absorve variações no momento de chegada dos pacotes, negocia a travessia de NAT com ICE/STUN/TURN para que pares atrás de roteadores possam se conectar e traz seus próprios recursos de captura e codificação de áudio. 

Em geral, você precisa de servidores TURN para clientes que não conseguem se conectar diretamente, e o lado do servidor precisa encerrar um stream de mídia em vez de ler um stream de bytes.

Veja rapidamente essa relação de compromisso:

Para a maioria dos casos de uso, WebSocket é a opção certa. Use-o quando seus clientes tiverem boa conectividade e você controlar o caminho de captura: pipelines servidor a servidor, apps para desktop, apps no navegador em banda larga e a maioria dos backends de centrais de atendimento, nos quais o áudio já chega ao seu servidor por outro meio. 

Escolha WebRTC quando estiver capturando diretamente de dispositivos de consumidores em redes móveis instáveis, quando já operar uma stack WebRTC para áudio bidirecional (por exemplo, um agente de voz que também responde falando) ou quando o comportamento em tempo real tolerante a perdas for mais importante que a simplicidade de implementação.

O restante deste guia usa o transporte WebSocket para a conexão com o reconhecedor porque ele mantém as partes em movimento visíveis e é o ponto de partida certo para a maioria das equipes. Nada disso é específico do WebSocket, então depois você pode adicionar uma etapa de mídia WebRTC antes dele, decodificar o áudio em PCM no servidor e encaminhar os mesmos chunks para o pipeline.

Parciais e transcrições finais: resultados intermediários explicados

Um reconhecedor em tempo real não espera uma frase completa antes de se manifestar. Em vez disso, ele emite um fluxo contínuo de suposições que se refinam à medida que mais áudio chega e então as confirma. Entender a diferença entre esses dois estados é o que separa uma transcrição que parece viva de uma que parece quebrada. 

Uma hipótese parcial (intermediária) é a melhor estimativa do modelo com base no áudio recebido até o momento. As parciais são instáveis por definição. À medida que mais áudio chega, o modelo revisa palavras anteriores: "Eu quero" pode se tornar "Eu quero dois ingressos" quando o contexto posterior resolve a ambiguidade. Elas chegam rápido (é isso que descreve o valor de latência de ~150 ms) e devem ser sobrescritas.

Uma hipótese final é um segmento confirmado que não será alterado. Depois que um segmento é finalizado, o reconhecedor segue adiante, e as hipóteses subsequentes descrevem o áudio posterior. As finais são o que você persiste, envia para um LLM ou armazena como transcrição.

A distinção entre parciais e finais determina três coisas que você errará se misturá-las:

• Experiência do usuário: Mostrar parciais faz uma transcrição parecer ao vivo: o usuário vê as palavras surgirem enquanto fala, o que confirma que o microfone funciona e que o sistema está ouvindo.
• Detecção de fim de fala: As parciais fornecem um sinal contínuo de atividade de fala. Combinadas ao VAD, permitem decidir quando o falante realmente parou.
• Tempo das etapas posteriores: Em um pipeline de agente de voz, as etapas são: entrada de áudio, transcrição de voz, um LLM, texto em voz e saída de áudio. Você pode começar um trabalho especulativo com as parciais e confirmá-lo nas finais, reduzindo o tempo de resposta percebido ao custo de ocasionalmente descartar esse trabalho.

Renderize parciais e finais de modo diferente. Um padrão simples e eficaz é manter uma única "linha atual" mutável vinculada à parcial mais recente e confirmá-la em uma transcrição que só recebe acréscimos quando uma final chega:

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, renderize o texto confirmado como estável e o atual em um estilo mais claro ou itálico, para que o usuário entenda que ele ainda pode mudar.

Detecção de fim de fala e detecção de atividade de voz (VAD)

Saber o que foi dito é apenas metade do desafio. Um reconhecedor também precisa saber quando um pensamento terminou. Essa decisão define quando você finaliza um segmento e, em um agente, quando o sistema começa a responder. 

A detecção de fim de fala é a decisão de que uma enunciação terminou. Finalizar cedo demais interrompe os usuários no meio da frase. Finalizar tarde demais deixa um agente em silêncio depois que o usuário claramente terminou.

O Scribe v2 Realtime oferece dois mecanismos complementares:

• A Detecção de Atividade de Voz segmenta o áudio com base no silêncio: O reconhecedor detecta quando a fala dá lugar a um silêncio prolongado e usa esse limite para finalizar um segmento automaticamente. O VAD é o padrão ideal para interfaces conversacionais porque se adapta ao ritmo natural da fala sem que você precise monitorar o tempo manualmente.
• Controle manual de commit: O controle manual de commit permite que seu aplicativo decida quando finalizar o segmento atual, independentemente do silêncio. Você envia um sinal de commit, o reconhecedor fecha o segmento atual e emite uma final. É a ferramenta certa quando seu aplicativo já sabe que a vez acabou: ao soltar um botão de push-to-talk, em uma ação de "enviar" ou por uma política externa de alternância de turnos.

Os dois funcionam bem juntos. Um agente de voz típico usa VAD para operação sem usar as mãos e expõe o commit manual como substituição, para que um usuário que pausa para pensar não seja interrompido, mas um usuário que toca em um botão obtenha um limite imediato.

O limite de silêncio é uma relação de compromisso real, sem valor universalmente correto:

• Um tempo limite curto para o fim da fala (por exemplo, finalização após ~200 a 400 ms de silêncio) faz o sistema parecer responsivo. Mas também interrompe usuários que pausam naturalmente entre orações, dividindo um pensamento em vários segmentos e, em um agente, disparando uma resposta prematura.
• Um tempo limite longo (por exemplo, ~800 a 1.200 ms) tolera pausas naturais e mantém as enunciações intactas, ao custo de um atraso perceptível antes de o sistema reagir.

Não existe uma constante global para usar aqui; ajuste o limite à interação:

• Ditado e anotações toleram pausas mais longas porque os usuários pensam no meio da frase. Prefira tempos limite maiores e conte com o VAD.
• Agentes de comando e controle e transacionais se beneficiam de tempos limite menores com commit manual, porque os turnos são curtos e objetivos.
• Falantes multilíngues ou não nativos fazem mais pausas, então reserve mais silêncio antes de finalizar.

Usar estas dicas ajuda você a criar um sistema eficaz de detecção de fim de fala e avançar rumo à transcrição de voz em tempo real.

Recursos durante o streaming: detecção de idioma e diarização de falantes

O reconhecimento por streaming pode fazer mais do que produzir palavras. Ainda assim, cada sinal extra solicitado afeta a latência e a estabilidade. A regra prática é ativar apenas o que a experiência ao vivo precisa e deixar o restante para um processamento em lote.

O reconhecimento automático de idioma permite que o Scribe v2 Realtime identifique o idioma falado entre seus mais de 90 idiomas compatíveis, sem que você precise declará-lo antecipadamente. O custo é que o modelo precisa de um breve trecho de áudio para fazer uma identificação confiável; portanto, as primeiras parciais de um stream podem ser menos estáveis enquanto o idioma é definido. Se você já souber o idioma, especificá-lo elimina essa ambiguidade e tende a produzir parciais iniciais mais estáveis.

Diarização de falantes atribui a fala a diferentes falantes, identificando quem disse o quê. Em transcrição em lote, isso é comparativamente fácil porque o modelo vê o arquivo inteiro. No streaming, é mais difícil: o reconhecedor precisa atribuir um rótulo de falante apenas com base no áudio disponível até então, e um rótulo dado ao áudio inicial pode precisar ser revisado quando mais da voz desse falante for ouvida. Trate os rótulos de falantes no streaming da mesma forma que o texto parcial: como provisórios até a finalização do segmento.

A marcação de tempo por palavra e o contexto de entidades seguem a mesma lógica. Quanto mais metadados por token você solicitar, mais dados tanto o modelo quanto a transmissão precisarão carregar. Para a maioria das UIs em tempo real, você precisa apenas do texto e dos limites de segmento ao vivo; os metadados detalhados podem ficar para um processamento em lote pós-chamada com o Scribe v2.

Formatos de áudio para streaming: PCM e mu-law

A lógica de transporte e reconhecimento recebe a maior parte da atenção, mas uma parcela surpreendente dos bugs do mundo real surge uma camada abaixo: na forma como você codifica e divide o áudio em chunks. Acertar o formato e o tamanho do chunk é a forma mais barata de reduzir a latência da transcrição de voz.

PCM (linear, assinado em 16 bits, little-endian) é o formato a usar quando você controla a captura. Taxas de amostragem mais altas trazem mais detalhes acústicos: 16 kHz é o mínimo padrão para reconhecimento de fala e geralmente é suficiente; 8 kHz é qualidade de telefonia e perde conteúdo de alta frequência. Use a taxa que corresponde à sua fonte. Não há benefício em aumentar o áudio de telefonia de 8 kHz para 48 kHz, pois não há informação a recuperar.

Mu-law a 8 kHz é o formato de telefonia. Se você estiver recebendo chamadas de um provedor como o Twilio, o áudio chegará como mu-law de 8 kHz, e você deve encaminhá-lo nesse formato em vez de transcodificá-lo duas vezes. Corresponder ao formato da fonte evita artefatos de reamostragem e uma etapa de conversão desnecessária.

O tamanho do chunk é o fator que molda mais diretamente a latência percebida. Você envia o áudio em chunks, e o reconhecedor produz parciais conforme eles chegam. Chunks menores significam atualizações mais frequentes e menor latência até a primeira parcial; chunks maiores significam menos mensagens e um pouco mais de contexto por inferência. Uma faixa prática é de 20 a 250 ms de áudio por chunk. Como referência concreta, em PCM mono de 16 bits a 16 kHz, um segundo de áudio tem 32.000 bytes; portanto, um chunk de 100 ms tem cerca de 3.200 bytes.

Captura de entrada do microfone no navegador

No navegador, a ferramenta certa é a Web Audio API com um AudioWorklet. O worklet é executado na thread de renderização de áudio, recebe áudio em pequenos frames e não sofre com as travadas da thread principal como o antigo ScriptProcessorNode. Sua função é converter as amostras float nativas do navegador em PCM de 16 bits e entregá-las à thread principal, que as encaminha pelo WebSocket.

O núcleo do processador worklet é a conversão de float para 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);

O pipeline em código

O pipeline tem três partes: um cliente no navegador que captura o microfone e transmite PCM ao seu servidor, um servidor Node que retransmite áudio para o Scribe v2 Realtime e devolve as transcrições, e um cliente programável que transmite PCM de um arquivo ou ponte de telefonia.

O servidor retransmite em vez de expor o reconhecedor diretamente ao navegador por um motivo importante: sua chave de API da ElevenLabs é secreta e nunca deve aparecer em código do lado do cliente. O servidor guarda a chave. Se você realmente precisar que o navegador fale diretamente com o reconhecedor, gere no servidor um token de uso único e curta duração e entregue-o ao cliente em vez da chave de API.

Cliente no navegador

O cliente abre um WebSocket para seu servidor, captura o microfone por meio do worklet acima e encaminha cada frame PCM assim que ele é produzido. Os eventos recebidos (já normalizados pelo servidor no formato { type, text }) controlam o estado parcial/final descrito anteriormente:

// 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" }));

Retransmissão no servidor

O servidor abre uma conexão com o reconhecedor por cliente, mantém a chave de API no servidor, encaminha o PCM binário diretamente e normaliza os eventos do reconhecedor no formato estável { type, text } consumido pelo 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
});

Tudo o que é específico do endpoint fica restrito às duas funções adaptadoras abaixo. Substitua os nomes dos campos pelos nomes exatos da referência de Speech to Text; o restante do pipeline não muda:

// 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 programável

Para pipelines de backend e para o benchmark abaixo, a mesma conexão com o reconhecedor funciona sem um navegador: leia PCM de qualquer fonte, envie-o no ritmo de chunks em tempo real e leia os eventos de volta. A chave de API e a URL vêm do ambiente, como no 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`);
});

Avaliação comparativa da latência de transcrição de voz e da taxa de erro de palavras

A latência e a taxa de erro de palavras variam conforme o falante, o idioma, as condições acústicas, a duração do áudio, o caminho de rede até a região mais próxima de cada provedor e a carga atual de cada serviço. 

Um resultado medido em um laptop em uma cidade não se generaliza para sua infraestrutura de produção em outra. Execute o harness em uma infraestrutura semelhante à de produção, com áudio parecido com sua entrada real, e informe faixas e distribuições em vez de números isolados.

Os únicos valores de latência e precisão que importam são os medidos no seu próprio áudio, a partir de uma infraestrutura parecida com a de produção. Veja um guia para avaliar comparativamente a latência da transcrição de voz.

O que medir na latência da transcrição de voz

Abaixo estão as principais métricas que você deve medir ao avaliar a latência da transcrição de voz em tempo real:

• Tempo até a primeira parcial: Do envio do primeiro chunk de áudio até o recebimento da primeira parcial não vazia.
• Atraso da parcial até a final: Do último chunk de áudio de uma enunciação até a hipótese final.
• Taxa de erro de palavras (WER): WER na transcrição finalizada em comparação com uma referência humana, calculada de forma idêntica em todos os sistemas.
• Oscilação de estabilidade: Quantas parciais são reescritas antes da finalização. Essa medida é um indicador de quanto a UI ao vivo parecerá mudar.

Controles

Para evitar dados pouco confiáveis, implemente vários controles no experimento para manter a consistência.

Estes são os principais controles para usar na avaliação de latência de transcrição de voz:

• Áudio idêntico: Use os mesmos arquivos, a mesma taxa de amostragem e a mesma codificação para todos os sistemas.
• Ritmo idêntico: Transmita cada sistema com o mesmo ritmo de chunks em tempo real (por exemplo, chunks de 100 ms).
• Repita e informe distribuições: Execute cada arquivo muitas vezes ao longo do dia; informe a mediana e a cauda (p50/p95).
• Referências e pontuação idênticas: Normalize o texto da mesma forma (maiúsculas, pontuação, números) antes de calcular a WER.
• Informe a região e a rede: Indique onde o harness foi executado e o caminho até cada provedor.

Mantendo todos esses elementos iguais, você obterá métricas mais precisas.

Estrutura do harness

O núcleo de medição recebe um adaptador de provedor e registra o tempo até a primeira parcial, o atraso de finalização e a oscilação das parciais:

// 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;
}

A taxa de erro de palavras é uma distância de Levenshtein padrão no nível de token sobre texto normalizado. Converta para minúsculas e remova a pontuação de forma idêntica na referência e na hipótese antes de calculá-la, ou você medirá seu normalizador, e não o modelo. Execute essa medida em um loop que rode cada arquivo cerca de 10 vezes por provedor e informe a mediana do tempo até a primeira parcial e a WER mediana (p50/p95), pois uma única amostra é dominada pela variação da rede.

Para executá-lo, você precisa fornecer duas coisas. Primeiro, escreva um adaptador StreamFn por sistema. O cliente programável acima já é um deles; os adaptadores dos outros seguem o mesmo contrato (audioPath, onEvent, result) e definem result.lastChunkSentAt quando o chunk final de áudio é enviado. Segundo, carregue seus arquivos de áudio e referências e execute as medições neles. Execute-o em uma máquina que represente sua implantação, com áudio que represente seus usuários, e você terá uma comparação reproduzível.

Recapitulando como alcançar a transcrição de voz em tempo real 

Cobrimos muitas mudanças arquiteturais neste artigo, permitindo que você melhore seu sistema de forma iterativa e avance rumo à transcrição de voz em tempo real.

Um sistema de STT em tempo real em produção se resume a algumas decisões:

• Transporte: Escolha WebSocket para simplicidade e redes controladas, e WebRTC quando precisar de tolerância a perdas e estiver capturando a partir de dispositivos de consumidores.
• Parciais e finais: Trate as parciais como provisórias e as finais como confirmadas, e renderize-as de forma diferente para que os usuários confiem no texto ao vivo.
• Detecção de fim de fala: Use VAD para segmentação sem usar as mãos, o commit manual como substituição e ajuste o limite de silêncio à interação, em vez de usar uma constante.
• Recursos durante o streaming: Ative recursos durante o streaming apenas onde a experiência ao vivo precisar deles e deixe o restante para um processamento em lote com o Scribe v2.
• Formato de áudio: Capture em pequenos frames PCM, envie chunks de ~100 ms e corresponda ao formato da fonte para telefonia.
• Avaliação comparativa: Ajuste empiricamente os parâmetros de precisão versus latência usando seu próprio áudio e métrica-alvo.
• Segurança da API: Mantenha sua chave de API no servidor ou gere tokens de uso único para conexões diretas de clientes.

Se quiser saber como otimizar a latência em um agente de voz, também escrevemos um guia para você.

Crie sistemas de transcrição de voz em tempo real com o Scribe v2 Realtime

O Scribe v2 Realtime produz parciais com cerca de 150 ms de latência do modelo. Seus usuários perceberão esse valor ou algo maior dependendo da arquitetura ao redor, que é a parte que você controla. Ao usar as estratégias apresentadas neste artigo, você criará uma arquitetura de pipeline aprimorada que reduz a latência e melhora a experiência do cliente. 

Para se aprofundar, conheça a visão geral dos recursos de Speech to Text, consulte nossa referência de modelos para ver a lista completa de recursos e idiomas e acesse as páginas de produto em tempo real: API de Speech to Text em tempo real e Speech to Text em tempo real.

Quando estiver pronto para criar, crie uma conta gratuita na ElevenLabs e transmita sua primeira transcrição hoje.

Perguntas frequentes sobre latência de transcrição de voz em tempo real