Speech to Text en temps réel sous 200 ms : guide d’architecture

La reconnaissance vocale en temps réel (STT) transcrit activement l'audio à mesure qu'une personne parle et restitue ses mots sous forme de texte en quelques centaines de millisecondes. Mais maintenir une faible latence STT relève autant de l'architecture que du modèle. Les ingénieurs doivent planifier le transport, le découpage en blocs, la détection de fin d'énoncé et le chemin de capture, chacun ajoutant de la latence. Une inefficacité dans l'un de ces éléments peut faire exploser votre budget de 200 ms.

Ce guide présente une approche pratique pour concevoir des pipelines de reconnaissance vocale en temps réel, en partant de la couche de transport. Nous nous appuierons sur Scribe v2 Realtime, qui génère des transcriptions partielles avec une latence de modèle d'environ 150 ms, prend en charge plus de 90 langues, accepte l'audio PCM (8 kHz à 48 kHz) et mu-law, et propose Voice Activity Detection ainsi qu'un contrôle de validation manuelle pour finaliser les segments.

Nous verrons comment l'audio atteint le serveur, comment les hypothèses deviennent du texte validé, ce que coûtent les fonctionnalités en flux et comment capturer puis transmettre correctement l'audio.

En résumé

• La création de systèmes de reconnaissance vocale en temps réel exige un réglage précis de l'architecture afin de maintenir une faible latence sur l'ensemble du pipeline.
• WebSocket constitue le choix par défaut pour la plupart des pipelines, même si WebRTC offre plusieurs avantages au prix d'une plus grande complexité.
• Voice Activity Detection gère la segmentation mains libres, tandis que la validation manuelle permet à vos applications de reprendre la main lorsqu'elles savent que le tour est terminé.
• Les transcriptions partielles sont provisoires et les transcriptions finales sont validées : vous devez donc les afficher différemment. 
• De petits blocs PCM d'environ 100 ms minimisent la latence avant la première transcription partielle.

WebSocket ou WebRTC pour la reconnaissance vocale en temps réel

Avant toute transcription, l'audio doit parvenir de sa source au moteur de reconnaissance. Le canal choisi fixe le niveau minimal de latence pour tout ce qui suit. Deux options permettent d'acheminer l'audio jusqu'à la couche de transcription.

WebSocket est un canal TCP bidirectionnel, fiable, ordonné et durable. Vous ouvrez une connexion, envoyez des trames audio binaires et recevez des événements de transcription. Il est simple à utiliser côté client comme côté serveur, traverse les proxys d'entreprise et les pare-feux qui autorisent déjà HTTPS, et est pris en charge par tous les navigateurs et environnements serveur. 

La contrainte de WebSocket est qu'il repose sur TCP. Si un paquet est perdu, TCP le retransmet et retient les données ultérieures jusqu'à ce que le manque soit comblé. Dans de bonnes conditions réseau, cela ne se remarque pas. En cas de perte de paquets, cela produit un blocage en tête de ligne : un bref arrêt durant lequel l'audio s'accumule avant d'arriver en rafale.

WebRTC est conçu pour les médias en temps réel. Il transporte les médias via UDP, grâce à SRTP, de sorte qu'un paquet perdu ne bloque pas le flux : le pipeline continue. Il intègre un tampon de gigue qui absorbe les variations de temps d'arrivée des paquets, négocie la traversée NAT avec ICE/STUN/TURN afin de connecter des pairs derrière des routeurs, et embarque ses propres mécanismes de capture et d'encodage audio. 

Vous avez généralement besoin de serveurs TURN pour les clients qui ne peuvent pas se connecter directement, et le serveur doit terminer un flux média plutôt que lire un flux d'octets.

Voici les compromis en un coup d'œil :

Pour la plupart des cas d'usage, WebSocket est la bonne option. Utilisez-le lorsque vos clients disposent d'une connectivité correcte et que vous contrôlez le chemin de capture : pipelines de serveur à serveur, applications de bureau, applications de navigateur sur haut débit et la plupart des backends de centres de contact, où l'audio arrive déjà sur votre serveur par un autre moyen. 

Choisissez WebRTC lorsque vous capturez directement l'audio depuis des appareils grand public sur des réseaux mobiles peu fiables, lorsque vous utilisez déjà une pile WebRTC pour l'audio bidirectionnel, par exemple un agent vocal qui répond à son tour, ou lorsque le comportement en temps réel tolérant aux pertes importe davantage que la simplicité d'implémentation.

La suite de ce guide utilise le transport WebSocket pour la connexion au moteur de reconnaissance, car il rend les composants visibles et constitue le bon point de départ pour la plupart des équipes. Rien n'est propre à WebSocket : vous pourrez ensuite ajouter en amont une couche média WebRTC, décoder l'audio en PCM sur le serveur et transmettre les mêmes blocs dans le pipeline.

Transcriptions partielles et finales : comprendre les résultats intermédiaires

Un moteur de reconnaissance en temps réel n'attend pas une phrase complète avant de restituer du texte. Il émet plutôt un flux continu d'hypothèses qui s'affinent à mesure que l'audio arrive, puis les valide. Comprendre la différence entre ces deux états fait la différence entre une transcription qui paraît vivante et une transcription qui semble défaillante. 

Une hypothèse partielle, ou intermédiaire, est la meilleure estimation du modèle à partir de l'audio reçu jusqu'ici. Les transcriptions partielles sont instables par nature. À mesure que l'audio arrive, le modèle révise les mots précédents : « Je voudrais » peut devenir « Je voudrais deux billets » quand le contexte ultérieur lève l'ambiguïté. Elles arrivent rapidement, c'est ce que décrit la latence d'environ 150 ms, et sont destinées à être remplacées.

Une hypothèse finale est un segment validé qui ne changera plus. Une fois le segment finalisé, le moteur de reconnaissance passe à la suite et les hypothèses suivantes décrivent l'audio ultérieur. Ce sont les résultats finaux que vous conservez, envoyez à un LLM ou stockez dans une transcription.

La distinction entre transcriptions partielles et finales détermine trois aspects que vous gérerez mal si vous les confondez :

• Expérience utilisateur : L'affichage des transcriptions partielles donne une impression de direct : l'utilisateur voit les mots apparaître pendant qu'il parle, ce qui confirme que le microphone fonctionne et que le système écoute.
• Détection de fin d'énoncé : Les transcriptions partielles vous fournissent un signal continu de l'activité vocale. Associées à la VAD, elles permettent de déterminer quand le locuteur a réellement terminé.
• Temporalité en aval : Dans un pipeline d'agent vocal, les étapes sont l'entrée audio, puis la reconnaissance vocale, puis un LLM, puis la synthèse vocale, puis la sortie audio. Vous pouvez commencer un travail spéculatif sur les transcriptions partielles et le confirmer sur les transcriptions finales, afin de réduire le temps de réponse perçu, au risque d'écarter occasionnellement ce travail spéculatif.

Affichez différemment les transcriptions partielles et finales. Un modèle simple et efficace consiste à conserver une unique « ligne courante » modifiable associée à la dernière transcription partielle, puis à l'ajouter à une transcription qui ne fait qu'ajouter du contenu lorsqu'un résultat final arrive :

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

Visuellement, affichez le texte validé dans un style normal et le texte courant dans un style plus léger ou italique, afin que l'utilisateur comprenne qu'il peut encore changer.

Détection de fin d'énoncé et détection d'activité vocale (VAD)

Savoir ce qui a été dit ne représente que la moitié du travail. Un moteur de reconnaissance doit aussi savoir quand une idée est terminée. Cette décision détermine quand finaliser un segment et, pour un agent, quand le système commence à répondre. 

La détection de fin d'énoncé consiste à décider qu'une énonciation est terminée. Une finalisation trop précoce coupe les utilisateurs en milieu de phrase. Une finalisation trop tardive laisse un agent silencieux alors que l'utilisateur a clairement fini.

Scribe v2 Realtime propose deux mécanismes complémentaires :

• Voice Activity Detection segmente l'audio selon les silences : Le moteur de reconnaissance détecte lorsque la parole laisse place à un silence prolongé et utilise cette limite pour finaliser automatiquement un segment. La VAD constitue le bon choix par défaut pour les interfaces conversationnelles, car elle s'adapte au rythme naturel de la parole sans suivi manuel de la temporalité.
• Contrôle de validation manuelle : Le contrôle de validation manuelle permet à votre application de décider quand finaliser le segment en cours, indépendamment du silence. Vous envoyez un signal de validation, le moteur de reconnaissance ferme le segment en cours et émet un résultat final. C'est l'outil approprié lorsque votre application sait déjà que le tour est terminé : relâchement d'un bouton push-to-talk, action « envoyer » ou règle externe de gestion des tours de parole.

Ces deux mécanismes se combinent efficacement. Un agent vocal typique utilise la VAD pour fonctionner sans les mains et propose la validation manuelle comme remplacement, afin qu'un utilisateur qui fait une pause pour réfléchir ne soit pas coupé, tandis qu'un utilisateur qui appuie sur un bouton obtient une limite immédiate.

Le seuil de silence implique un véritable compromis, sans valeur universellement correcte :

• Un délai court de fin de parole, par exemple une finalisation après environ 200 à 400 ms de silence, donne au système une impression de réactivité. Mais il coupe aussi les utilisateurs qui marquent naturellement des pauses entre les propositions, divisant une même idée en plusieurs segments et, dans un agent, déclenchant une réponse prématurée.
• Un délai long, par exemple environ 800 à 1 200 ms, tolère les pauses naturelles et préserve les énoncés, au prix d'un délai perceptible avant la réaction du système.

Il n'existe pas de constante universelle : adaptez le seuil à l'interaction :

• La dictée et la prise de notes tolèrent des pauses plus longues, car les utilisateurs réfléchissent au milieu d'une phrase. Privilégiez des délais plus longs et appuyez-vous sur la VAD.
• Les agents de commande et transactionnels bénéficient de délais plus courts associés à la validation manuelle, car les tours de parole sont courts et précis.
• Les locuteurs multilingues ou non natifs font davantage de pauses : prévoyez donc plus de silence avant de finaliser.

Ces conseils vous aideront à concevoir un système efficace de détection de fin d'énoncé et à vous rapprocher d'une reconnaissance vocale en temps réel.

Fonctionnalités en flux : détection de la langue et diarisation des locuteurs

La reconnaissance en flux peut faire plus que produire des mots. Cela dit, chaque signal supplémentaire demandé influe sur la latence et la stabilité. En règle générale, activez uniquement ce dont l'expérience en direct a besoin et reportez le reste à un traitement par lots.

La reconnaissance automatique de la langue permet à Scribe v2 Realtime d'identifier la langue parlée parmi les plus de 90 langues prises en charge, sans vous obliger à la déclarer au préalable. Le modèle a toutefois besoin d'un court extrait audio pour statuer avec certitude : les premières transcriptions partielles d'un flux peuvent donc être moins stables pendant que la langue est déterminée. Si vous connaissez déjà la langue, la préciser élimine cette ambiguïté et produit généralement des transcriptions partielles initiales plus stables.

La diarisation des locuteurs attribue la parole à des locuteurs distincts et identifie qui a dit quoi. Dans une transcription par lots, cette tâche est relativement simple, car le modèle voit l'intégralité du fichier. En flux, elle est plus difficile : le moteur de reconnaissance doit attribuer une étiquette de locuteur à partir du seul audio reçu jusqu'alors, et une étiquette attribuée au début peut devoir être révisée lorsqu'une plus grande partie de la voix de ce locuteur est entendue. Traitez les étiquettes de locuteurs en flux comme le texte partiel : elles restent provisoires jusqu'à la finalisation du segment.

L'horodatage au niveau des mots et le contexte des entités suivent la même logique. Plus vous demandez de métadonnées par jeton, plus le modèle et la transmission ont de données à transporter. Pour la plupart des interfaces en temps réel, vous n'avez besoin en direct que du texte et des limites de segments ; vous pouvez reporter les métadonnées détaillées à un traitement par lots après l'appel avec Scribe v2.

Formats audio pour le streaming : PCM et mu-law

La logique de transport et de reconnaissance attire le plus l'attention, mais une part étonnante des bugs réels provient de l'étape inférieure : l'encodage et le découpage de l'audio. Bien choisir le format et la taille des blocs est le moyen le plus économique de réduire la latence de reconnaissance vocale.

Le PCM, linéaire, signé sur 16 bits et petit-boutiste, est le format à utiliser lorsque vous contrôlez la capture. Des fréquences d'échantillonnage plus élevées restituent davantage de détails acoustiques : 16 kHz est le minimum standard pour la reconnaissance vocale et suffit généralement ; 8 kHz correspond à la qualité téléphonique et perd le contenu haute fréquence. Utilisez la fréquence correspondant à votre source. Il est inutile de suréchantillonner un audio téléphonique à 8 kHz vers 48 kHz, car l'information ne peut pas être récupérée.

Le mu-law à 8 kHz est le format de téléphonie. Si vous ingérez des appels provenant d'un fournisseur tel que Twilio, l'audio arrive en mu-law 8 kHz et vous devez le transmettre dans ce format plutôt que de le transcoder deux fois. Faire correspondre le format source évite les artefacts de rééchantillonnage et une étape de conversion inutile.

La taille des blocs est le levier qui façonne le plus directement la latence perçue. Vous envoyez l'audio par blocs et le moteur de reconnaissance produit des résultats partiels à leur arrivée. Des blocs plus petits permettent des mises à jour plus fréquentes et réduisent la latence avant le premier résultat partiel ; des blocs plus grands impliquent moins de messages et un peu plus de contexte par inférence. Une plage pratique va de 20 à 250 ms d'audio par bloc. À titre d'exemple, en PCM mono 16 bits à 16 kHz, une seconde d'audio représente 32 000 octets, donc un bloc de 100 ms fait environ 3 200 octets.

Capturer l'entrée microphone dans le navigateur

Dans le navigateur, l'outil approprié est l'API Web Audio API avec un AudioWorklet. Le worklet s'exécute sur le thread de rendu audio, reçoit l'audio dans de petites trames et n'est pas soumis aux à-coups du thread principal, contrairement à l'ancien ScriptProcessorNode. Il convertit les échantillons flottants natifs du navigateur en PCM 16 bits et les transmet au thread principal, qui les envoie via WebSocket.

Le cœur du processeur worklet est la conversion de flottants en 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);

Le pipeline en code

Le pipeline comporte trois composants : un client de navigateur qui capture le microphone et transmet le PCM à votre serveur, un serveur Node qui relaie l'audio vers Scribe v2 Realtime puis renvoie les transcriptions, et un client scriptable qui transmet du PCM depuis un fichier ou une passerelle téléphonique.

Le serveur agit comme relais plutôt que d'exposer directement le moteur de reconnaissance au navigateur pour une raison essentielle : votre clé API ElevenLabs est secrète et ne doit jamais apparaître dans le code côté client. Le serveur conserve la clé. Si le navigateur doit communiquer directement avec le moteur de reconnaissance, générez côté serveur un jeton à usage unique de courte durée et transmettez-le au client à la place de la clé API.

Client de navigateur

Le client ouvre un WebSocket vers votre serveur, capture le microphone avec le worklet ci-dessus et transmet chaque trame PCM dès sa production. Les événements entrants, déjà normalisés par le serveur au format { type, text }, pilotent l'état partiel/final décrit précédemment :

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

Relais serveur

Le serveur ouvre une connexion au moteur de reconnaissance par client, conserve la clé API sur le serveur, transmet directement le PCM binaire et normalise les événements du moteur au format stable { type, text } utilisé par le client :

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

Tout ce qui est spécifique au point de terminaison est isolé dans les deux fonctions d'adaptation ci-dessous. Remplacez les noms de champs par ceux indiqués dans le Guide de l'API Speech to Text ; le reste du pipeline ne change pas :

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

Client backend scriptable

Pour les pipelines backend et pour le benchmark ci-dessous, la même connexion au moteur de reconnaissance fonctionne sans navigateur : lisez le PCM depuis n'importe quelle source, cadrez-le selon la cadence des blocs en temps réel, puis lisez les événements renvoyés. Comme sur le serveur, la clé API et l'URL proviennent de l'environnement.

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

Évaluer la latence de reconnaissance vocale et le taux d'erreur sur les mots

La latence et le taux d'erreur sur les mots varient selon le locuteur, la langue, les conditions acoustiques, la durée de l'audio, le chemin réseau vers la région la plus proche de chaque fournisseur et la charge actuelle de chaque service. 

Un résultat mesuré depuis un ordinateur portable dans une ville ne se généralise pas à votre infrastructure de production dans une autre. Exécutez le banc d'essai depuis une infrastructure proche de la production, sur un audio comparable à vos entrées réelles, et présentez des plages et des distributions plutôt que des chiffres uniques.

Les seuls chiffres de latence et de précision qui comptent sont ceux que vous mesurez sur votre propre audio depuis une infrastructure proche de la production. Voici comment évaluer la latence de reconnaissance vocale.

Mesures à relever pour la latence de reconnaissance vocale

Voici les principales métriques à mesurer lorsque vous évaluez la latence de la reconnaissance vocale en temps réel :

• Délai avant le premier résultat partiel : du premier bloc audio envoyé à la réception du premier résultat partiel non vide.
• Délai entre résultat partiel et final : du dernier bloc audio d'un énoncé à l'hypothèse finale.
• Taux d'erreur sur les mots (WER) : WER de la transcription finalisée par rapport à une référence humaine, calculé de façon identique dans tous les systèmes.
• Instabilité des résultats : nombre de résultats partiels réécrits avant la finalisation. Cette mesure indique dans quelle proportion l'interface en direct semblera changer.

Contrôles

Pour éviter des données peu fiables, mettez en place plusieurs contrôles dans votre expérience afin de garantir la cohérence.

Voici les principaux contrôles à appliquer à l'évaluation de la latence de la reconnaissance vocale :

• Audio identique : utilisez les mêmes fichiers, la même fréquence d'échantillonnage et le même encodage pour chaque système.
• Cadence identique : transmettez chaque système selon la même cadence de blocs en temps réel, par exemple des blocs de 100 ms.
• Répétez et présentez les distributions : exécutez chaque fichier plusieurs fois dans la journée ; indiquez la médiane et les valeurs de queue, p50/p95.
• Références et notation identiques : normalisez le texte de la même façon, notamment la casse, la ponctuation et les nombres, avant de calculer le WER.
• Indiquez la région et le réseau : précisez où le banc d'essai a été exécuté et le chemin vers chaque fournisseur.

En maintenant tous ces éléments identiques, vous obtiendrez des métriques plus précises.

Structure du banc d'essai

Le cœur de la mesure accepte un adaptateur de fournisseur et enregistre le délai avant le premier résultat partiel, le délai de finalisation et l'instabilité des résultats partiels :

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

Le taux d'erreur sur les mots est une distance de Levenshtein standard au niveau des jetons sur du texte normalisé. Mettez en minuscules et supprimez la ponctuation de façon identique dans la référence et l'hypothèse avant de le calculer, sinon vous mesurerez votre normaliseur plutôt que le modèle. Exécutez cette mesure dans une boucle qui traite chaque fichier environ 10 fois par fournisseur et indique la médiane du délai avant le premier résultat partiel et du WER, p50/p95, car un seul échantillon est fortement dominé par la variation réseau.

Pour l'exécuter, vous devez fournir deux éléments. D'abord, écrivez un adaptateur StreamFn par système. Le client scriptable ci-dessus en est déjà un ; les adaptateurs pour les autres suivent le même contrat (audioPath, onEvent, result) et définissent result.lastChunkSentAt lorsque le dernier bloc audio est envoyé. Ensuite, chargez vos fichiers audio et vos références, puis appelez les mesures sur l'ensemble. Exécutez-le depuis une machine représentative de votre déploiement, sur un audio représentatif de vos utilisateurs, et vous disposerez d'une comparaison reproductible.

Récapitulatif : parvenir à une reconnaissance vocale en temps réel 

Cet article a présenté de nombreuses évolutions architecturales qui vous permettront d'améliorer progressivement votre système et de vous rapprocher de la reconnaissance vocale en temps réel.

Un système STT en temps réel prêt pour la production repose sur quelques décisions essentielles :

• Transport : choisissez WebSocket pour sa simplicité et les réseaux contrôlés, et WebRTC lorsque vous avez besoin d'une tolérance aux pertes et capturez depuis des appareils grand public.
• Résultats partiels et finaux : traitez les résultats partiels comme provisoires et les résultats finaux comme validés, puis affichez-les différemment afin que les utilisateurs aient confiance dans le texte en direct.
• Détection de fin d'énoncé : utilisez la VAD pour la segmentation mains libres, la validation manuelle comme remplacement et adaptez le seuil de silence à l'interaction plutôt qu'à une constante.
• Fonctionnalités en flux : activez-les uniquement lorsque l'expérience en direct les requiert et reportez le reste à un traitement par lots avec Scribe v2.
• Format audio : capturez dans de petites trames PCM, envoyez des blocs d'environ 100 ms et utilisez le format source pour la téléphonie.
• Évaluation : réglez empiriquement les paramètres de précision et de latence en fonction de votre audio et de votre métrique cible.
• Sécurité de l'API : conservez votre clé API sur le serveur, ou générez des jetons à usage unique pour les connexions directes des clients.

Si vous souhaitez découvrir comment optimiser la latence d'un agent vocal, nous avons également rédigé un guide à ce sujet.

Concevez des systèmes de reconnaissance vocale en temps réel avec Scribe v2 Realtime

Scribe v2 Realtime produit des résultats partiels avec une latence de modèle d'environ 150 ms. Que vos utilisateurs constatent cette valeur ou une valeur supérieure dépend de l'architecture qui l'entoure, celle que vous contrôlez. En appliquant les stratégies présentées dans cet article, vous construirez une architecture de pipeline améliorée qui réduit la latence et améliore l'expérience client. 

Pour aller plus loin, découvrez l'aperçu des capacités de Speech to Text, consultez notre référence des modèles pour obtenir la liste complète des fonctionnalités et des langues, et accédez aux pages produit en temps réel : API Speech to Text en temps réel et Speech to Text en temps réel.

Lorsque vous serez prêt à concevoir votre solution, créez gratuitement un compte ElevenLabs et diffusez votre première transcription dès aujourd'hui.

FAQ sur la latence de la reconnaissance vocale en temps réel