Echtzeit-Spracherkennung unter 200 ms: Ein Architekturleitfaden

Echtzeit-Spracherkennung (STT) transkribiert Audio aktiv, während eine Person spricht, und gibt ihre Worte innerhalb weniger hundert Millisekunden als Text zurück. Eine niedrige STT-Latenz ist jedoch ebenso ein Architektur- wie ein Modellproblem. Entwickler müssen Transport, Chunking, End-Pointing und Erfassungspfad planen, da jeder davon Latenz hinzufügt. Ineffizienz in nur einem dieser Bereiche kann Ihr 200-ms-Budget sprengen.

Dieser Leitfaden bietet ein praxistaugliches System zum Aufbau von Echtzeit-Spracherkennungs-Pipelines – von der Transportschicht aufwärts. Als Grundlage dient Scribe v2 Realtime, das Teiltranskriptionen bei etwa 150 ms Modelllatenz liefert, über 90 Sprachen unterstützt, PCM-Audio (8 kHz–48 kHz) und Mu-Law akzeptiert und Voice Activity Detection sowie eine manuelle Commit-Steuerung zum Finalisieren von Segmenten bietet.

Wir zeigen, wie Audio den Server erreicht, wie Hypothesen zu festgeschriebenem Text werden, welche Kosten In-Stream-Funktionen verursachen und wie Sie Audio korrekt erfassen und weiterleiten.

Zusammenfassung

• Echtzeit-Spracherkennungssysteme erfordern architektonische Feinabstimmung, damit die Latenz in der gesamten Pipeline niedrig bleibt.
• WebSocket ist für die meisten Pipelines die richtige Standardwahl. WebRTC bietet zwar Vorteile, ist aber komplexer.
• Voice Activity Detection übernimmt die freihändige Segmentierung. Mit manuellem Commit können Ihre Anwendungen eingreifen, wenn sie wissen, dass ein Sprecherzug beendet ist.
• Partials sind vorläufig, Finals sind festgeschrieben. Sie sollten daher unterschiedlich dargestellt werden. 
• Kleine PCM-Chunks von etwa 100 ms minimieren die Latenz bis zum ersten Partial.

WebSocket vs. WebRTC für Echtzeit-Spracherkennung

Bevor eine Transkription stattfinden kann, muss das Audio von der Quelle zum Erkenner gelangen. Der gewählte Kanal bestimmt die minimale Latenz für alles Folgende. Es gibt zwei praktikable Optionen, um Audio zur Transkriptionsebene zu übertragen.

WebSocket ist ein langlebiger, geordneter, zuverlässiger bidirektionaler Kanal über TCP. Sie öffnen eine Verbindung, senden binäre Audio-Frames und lesen Transkriptionsereignisse. Er ist auf Client und Server unkompliziert, passiert Unternehmens-Proxys und Firewalls, die HTTPS bereits zulassen, und wird von jeder Browser- und Server-Laufzeit unterstützt. 

Die Einschränkung von WebSocket liegt darin, dass es TCP nutzt. Geht ein Paket verloren, überträgt TCP es erneut und hält spätere Daten zurück, bis die Lücke geschlossen ist. Bei guten Netzwerkbedingungen fällt das nicht auf. Bei Paketverlust entsteht jedoch Head-of-Line-Blocking: Audio staut sich kurz und trifft dann schubweise ein.

WebRTC wurde für Echtzeitmedien entwickelt. Es überträgt Medien über UDP (via SRTP), daher hält ein verlorenes Paket den Stream nicht an; die Pipeline läuft weiter. Es enthält einen Jitter-Buffer, der Schwankungen bei Paketankunftszeiten ausgleicht, handelt NAT-Traversal über ICE/STUN/TURN aus, damit Peers hinter Routern sich verbinden können, und bringt eigene Funktionen für Audioerfassung und -kodierung mit. 

Für Clients, die keine direkte Verbindung herstellen können, benötigen Sie in der Regel TURN-Server. Serverseitig muss ein Medienstrom terminiert werden, statt einen Byte-Stream zu lesen.

Die Unterschiede im Überblick:

Für die meisten Anwendungsfälle ist WebSocket die richtige Wahl. Nutzen Sie es, wenn Ihre Clients eine gute Verbindung haben und Sie den Erfassungspfad kontrollieren: Server-zu-Server-Pipelines, Desktop-Apps, Browser-Apps über Breitband sowie die meisten Contact-Center-Backends, bei denen Audio bereits auf anderem Weg Ihren Server erreicht. 

Wählen Sie WebRTC, wenn Sie direkt von Endgeräten in unzuverlässigen Mobilfunknetzen erfassen, bereits einen WebRTC-Stack für Zwei-Wege-Audio betreiben – etwa für einen Voice Agent, der auch antwortet – oder wenn verlusttolerantes Echtzeitverhalten wichtiger ist als eine einfache Implementierung.

Im weiteren Verlauf dieses Leitfadens verwenden wir WebSocket für die Verbindung zum Erkenner, weil dadurch die Komponenten sichtbar bleiben und es für die meisten Teams der richtige Einstieg ist. Nichts davon ist WebSocket-spezifisch: Sie können später davor eine WebRTC-Medienstrecke ergänzen, das Audio auf dem Server in PCM dekodieren und dieselben Chunks an die Pipeline weiterleiten.

Partials und finale Transkripte: vorläufige Ergebnisse erklärt

Ein Echtzeit-Erkenner wartet nicht auf einen vollständigen Satz, bevor er Text ausgibt. Stattdessen liefert er einen fortlaufenden Strom von Vermutungen, die mit weiterem Audio präziser werden und dann festgeschrieben werden. Wer den Unterschied zwischen diesen beiden Zuständen versteht, erstellt Transkripte, die lebendig statt fehlerhaft wirken. 

Eine partielle (vorläufige) Hypothese ist die beste Schätzung des Modells auf Grundlage des bisher empfangenen Audios. Partials sind absichtlich instabil. Mit weiterem Audio überarbeitet das Modell frühere Wörter: „Ich möchte“ kann zu „Ich möchte zwei Tickets“ werden, sobald späterer Kontext die Mehrdeutigkeit auflöst. Sie treffen schnell ein – darauf bezieht sich die Latenz von etwa 150 ms – und sollen überschrieben werden.

Eine finale Hypothese ist ein festgeschriebenes Segment, das sich nicht mehr ändert. Sobald ein Segment finalisiert ist, fährt der Erkenner fort und nachfolgende Hypothesen beschreiben späteres Audio. Finals speichern Sie, senden sie an ein LLM oder legen sie als Transkript ab.

Die Unterscheidung zwischen Partials und Finals beeinflusst drei Dinge, die Sie falsch machen werden, wenn Sie sie vermischen:

• Nutzererlebnis: Die Anzeige von Partials lässt ein Transkript live wirken: Nutzer sehen Wörter erscheinen, während sie sprechen. Das bestätigt, dass das Mikrofon funktioniert und das System zuhört.
• End-Pointing: Partials liefern ein kontinuierliches Signal für Sprachaktivität. In Verbindung mit VAD können Sie damit entscheiden, wann ein Sprecher tatsächlich aufgehört hat.
• Timing nachgelagerter Schritte: In einer Voice-Agent-Pipeline folgen auf eingehendes Audio Speech to Text, ein LLM und Text to Speech, anschließend wird Audio ausgegeben. Sie können auf Basis von Partials spekulative Arbeit beginnen und sie mit Finals bestätigen. Das verkürzt die wahrgenommene Antwortzeit, kann aber dazu führen, dass spekulative Arbeit verworfen wird.

Stellen Sie Partials und Finals unterschiedlich dar. Ein einfaches, effektives Muster besteht darin, eine einzelne veränderbare „aktuelle Zeile“ an das neueste Partial zu binden und sie bei Eintreffen eines Finals in ein Transkript nur zum Anhängen zu übernehmen:

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

Stellen Sie festgeschriebenen Text visuell stabil dar und den aktuellen Text heller oder kursiv, damit Nutzer erkennen, dass er sich noch ändern kann.

End-Pointing und Voice Activity Detection (VAD)

Zu wissen, was gesagt wurde, ist nur die halbe Aufgabe. Ein Erkenner muss auch wissen, wann ein Gedanke beendet ist. Diese Entscheidung bestimmt, wann Sie ein Segment finalisieren und wann das System bei einem Agenten zu antworten beginnt. 

End-Pointing ist die Entscheidung, dass eine Äußerung beendet ist. Zu frühes Finalisieren unterbricht Nutzer mitten im Satz. Zu spätes Finalisieren lässt einen Agenten schweigen, obwohl der Nutzer eindeutig fertig ist.

Scribe v2 Realtime bietet zwei sich ergänzende Mechanismen:

• Voice Activity Detection segmentiert Audio anhand von Stille: Der Erkenner erkennt, wann Sprache in anhaltende Stille übergeht, und nutzt diese Grenze, um ein Segment automatisch zu finalisieren. VAD ist die richtige Standardwahl für dialogorientierte Oberflächen, weil sie sich an den natürlichen Sprechrhythmus anpasst, ohne dass Sie Zeiten manuell verfolgen müssen.
• Manuelle Commit-Steuerung: Die manuelle Commit-Steuerung ermöglicht Ihrer Anwendung, unabhängig von Stille zu bestimmen, wann das aktuelle Segment finalisiert wird. Sie senden ein Commit-Signal, der Erkenner schließt das aktuelle Segment und gibt ein Final aus. Das richtige Werkzeug, wenn Ihre Anwendung bereits weiß, dass der Sprecherzug beendet ist: beim Loslassen einer Push-to-Talk-Taste, bei einer „Senden“-Aktion oder durch eine externe Sprecherwechselrichtlinie.

Beide lassen sich gut kombinieren. Ein typischer Voice Agent nutzt VAD für den freihändigen Betrieb und bietet manuellen Commit als Override. So wird ein Nutzer, der zum Nachdenken pausiert, nicht unterbrochen, während ein Nutzer, der eine Taste antippt, sofort eine Segmentgrenze erhält.

Der Stille-Schwellenwert ist ein echter Zielkonflikt ohne universell richtigen Wert:

• Ein kurzes Timeout nach Sprachende – etwa Finalisierung nach ~200–400 ms Stille – lässt das System reaktionsschnell wirken. Es unterbricht jedoch auch Nutzer, die zwischen Teilsätzen natürlich pausieren, teilt einen Gedanken in mehrere Segmente und kann bei einem Agenten eine verfrühte Antwort auslösen.
• Ein langes Timeout – etwa ~800–1200 ms – toleriert natürliche Pausen und erhält Äußerungen vollständig, verursacht aber eine merkliche Verzögerung, bevor das System reagiert.

Hier gibt es keine globale Konstante. Stimmen Sie den Schwellenwert auf die Interaktion ab:

• Diktate und Notizen tolerieren längere Pausen, weil Nutzer mitten im Satz nachdenken. Bevorzugen Sie längere Timeouts und setzen Sie auf VAD.
• Befehlssysteme und transaktionale Agenten profitieren von kürzeren Timeouts plus manuellem Commit, weil Sprecherzüge kurz und eindeutig sind.
• Mehrsprachige Sprecher oder Nichtmuttersprachler pausieren häufiger. Planen Sie daher mehr Stille ein, bevor Sie finalisieren.

Mit diesen Hinweisen können Sie ein wirksames End-Pointing-System aufbauen und sich der Echtzeit-Spracherkennung annähern.

In-Stream-Funktionen: Spracherkennung und Sprecherdiarisierung

Streaming-Erkennung kann mehr als Wörter erzeugen. Jedes zusätzliche angeforderte Signal beeinflusst jedoch Latenz und Stabilität. Als Faustregel gilt: Aktivieren Sie nur, was das Live-Erlebnis benötigt, und verschieben Sie den Rest in einen Batch-Durchlauf.

Die automatische Spracherkennung ermöglicht Scribe v2 Realtime, die gesprochene Sprache unter den mehr als 90 unterstützten Sprachen zu erkennen, statt sie vorab anzugeben. Das Modell benötigt dafür kurze Audioabschnitte, um sicher zu entscheiden. Die ersten Partials eines Streams können daher weniger stabil sein, während sich die Sprache festlegt. Wenn Sie die Sprache bereits kennen, beseitigt ihre Angabe diese Mehrdeutigkeit und führt meist zu stabileren frühen Partials.

Sprecherdiarisierung ordnet Sprache einzelnen Sprechern zu und erkennt, wer was gesagt hat. Bei der Batch-Transkription ist das vergleichsweise einfach, weil das Modell die gesamte Datei sieht. Beim Streaming ist es schwieriger: Der Erkenner muss anhand des bisherigen Audios ein Sprecherlabel vergeben. Ein Label für frühes Audio muss möglicherweise korrigiert werden, sobald mehr von der Stimme dieses Sprechers zu hören ist. Behandeln Sie Streaming-Sprecherlabels wie partiellen Text: als vorläufig, bis das Segment finalisiert ist.

Zeitangaben auf Wortebene und Entitätskontext folgen derselben Logik. Je mehr Metadaten pro Token Sie anfordern, desto mehr müssen Modell und Übertragungsweg transportieren. Für die meisten Echtzeit-UIs benötigen Sie live nur Text und Segmentgrenzen. Detaillierte Metadaten können Sie in einen Batch-Durchlauf nach dem Gespräch mit Scribe v2 verschieben.

Audioformate für Streaming: PCM und Mu-Law

Transport- und Erkennungslogik erhalten die meiste Aufmerksamkeit, doch ein überraschend großer Anteil realer Fehler entsteht eine Ebene tiefer: bei Kodierung und Chunking des Audios. Das richtige Format und die richtige Chunk-Größe sind der günstigste Hebel für geringere Speech-to-Text-Latenz.

PCM (linear, 16-Bit mit Vorzeichen, Little-Endian) ist das richtige Format, wenn Sie die Erfassung kontrollieren. Höhere Abtastraten enthalten mehr akustische Details: 16 kHz sind der Standard-Mindestwert für Spracherkennung und meist ausreichend; 8 kHz entsprechen Telefonqualität und verlieren hochfrequente Inhalte. Nutzen Sie die Rate, die zu Ihrer Quelle passt. Das Hochskalieren von 8-kHz-Telefonieaudio auf 48 kHz bringt keinen Nutzen, da die Informationen nicht wiederhergestellt werden können.

Mu-Law bei 8 kHz ist das Telefonieformat. Wenn Sie Anrufe eines Anbieters wie Twilio aufnehmen, trifft Audio als 8-kHz-Mu-Law ein. Leiten Sie es in diesem Format weiter, statt es zweimal zu transkodieren. Das Quellformat beizubehalten vermeidet Resampling-Artefakte und einen unnötigen Konvertierungsschritt.

Die Chunk-Größe beeinflusst die wahrgenommene Latenz am direktesten. Sie senden Audio in Chunks, und der Erkenner erzeugt Partials, sobald sie eintreffen. Kleinere Chunks bedeuten häufigere Updates und geringere Latenz bis zum ersten Partial; größere Chunks bedeuten weniger Nachrichten und etwas mehr Kontext pro Inferenz. Ein praxisnaher Bereich liegt bei 20–250 ms Audio pro Chunk. Bei 16-kHz-Mono-PCM mit 16 Bit umfasst eine Sekunde Audio 32.000 Bytes, ein 100-ms-Chunk also etwa 3.200 Bytes.

Mikrofoneingaben im Browser erfassen

Im Browser verwenden Sie die Web-Audio API mit einem AudioWorklet. Das Worklet läuft im Audio-Rendering-Thread, empfängt Audio in kleinen Frames und ist nicht wie der ältere ScriptProcessorNode von Rucklern im Main Thread betroffen. Seine Aufgabe ist es, die nativen Float-Samples des Browsers in 16-Bit-PCM umzuwandeln und an den Main Thread zu übergeben, der sie über den WebSocket weiterleitet.

Der Kern des Worklet-Prozessors ist die Float-zu-PCM-Konvertierung:

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

Die Pipeline im Code

Die Pipeline besteht aus drei Komponenten: einem Browser-Client, der das Mikrofon erfasst und PCM zu Ihrem Server streamt, einem Node-Server, der Audio an Scribe v2 Realtime weiterleitet und Transkripte zurücksendet, sowie einem skriptfähigen Client, der PCM aus einer Datei oder Telefonie-Bridge streamt.

Der Server leitet weiter, statt den Erkenner direkt im Browser bereitzustellen, und zwar aus einem wichtigen Grund: Ihr ElevenLabs-API-Key ist geheim und darf niemals in clientseitigem Code erscheinen. Der Server verwahrt den Key. Falls der Browser dennoch direkt mit dem Erkenner kommunizieren muss, erstellen Sie serverseitig ein kurzlebiges Einmal-Token und geben dieses dem Client statt des API-Keys.

Browser-Client

Der Client öffnet einen WebSocket zu Ihrem Server, erfasst das Mikrofon über das oben beschriebene Worklet und leitet jeden PCM-Frame sofort weiter. Eingehende Ereignisse, die der Server bereits in { type, text } normalisiert hat, steuern den zuvor beschriebenen Partial-/Final-Zustand:

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

Server-Relay

Der Server öffnet pro Client eine Erkennerverbindung, behält den API-Key auf dem Server, leitet binäres PCM direkt durch und normalisiert Erkennerereignisse in das stabile Format { type, text }, das der Client verarbeitet:

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

Alles Endpunkt-spezifische ist auf die beiden folgenden Adapter-Funktionen beschränkt. Ersetzen Sie die Feldnamen durch die exakten Namen aus der Speech-to-Text-Referenz; der Rest der Pipeline bleibt unverändert:

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

Skriptfähiger Backend-Client

Für Backend-Pipelines und den folgenden Benchmark funktioniert dieselbe Erkennerverbindung ohne Browser: Lesen Sie PCM aus einer beliebigen Quelle, takten Sie es mit der Echtzeit-Chunk-Frequenz und lesen Sie Ereignisse zurück. API-Key und URL stammen wie beim Server aus der Umgebung.

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

Speech-to-Text-Latenz und Wortfehlerrate benchmarken

Latenz und Wortfehlerrate variieren je nach Sprecher, Sprache, akustischen Bedingungen, Audiolänge, Netzwerkpfad zur nächstgelegenen Region eines Anbieters und aktueller Auslastung des jeweiligen Dienstes. 

Ein Ergebnis, das auf einem Laptop in einer Stadt gemessen wurde, lässt sich nicht auf Ihre Produktionsinfrastruktur in einer anderen übertragen. Führen Sie den Benchmark auf Infrastruktur aus, die der Produktion ähnelt, mit Audio, das Ihren tatsächlichen Eingaben entspricht, und berichten Sie Bereiche und Verteilungen statt einzelner Werte.

Die einzigen Latenz- und Genauigkeitswerte, die zählen, sind jene, die Sie mit Ihrem eigenen Audio auf produktionsnaher Infrastruktur messen. Hier ist ein Leitfaden zum Benchmarking von Speech-to-Text-Latenz.

Was Sie für Speech-to-Text-Latenz messen sollten

Dies sind die wichtigsten Metriken für das Benchmarking der Echtzeit-Spracherkennungslatenz:

• Zeit bis zum ersten Partial: Vom Senden des ersten Audio-Chunks bis zum Empfang des ersten nicht leeren Partials.
• Verzögerung von Partial zu Final: Vom letzten Audio-Chunk einer Äußerung bis zur finalen Hypothese.
• Wortfehlerrate (WER): WER des finalisierten Transkripts im Vergleich zu einer menschlichen Referenz, für alle Systeme identisch berechnet.
• Stabilitätsänderungen: Wie viele Partials vor dem Finalisieren umgeschrieben werden. Diese Metrik zeigt, wie stark sich die Live-UI voraussichtlich verändert.

Kontrollen

Um unzuverlässige Daten zu vermeiden, sollten Sie mehrere Kontrollen in Ihr Experiment einbauen und für Konsistenz sorgen.

Dies sind die wichtigsten Kontrollen für das Benchmarking der Speech-to-Text-Latenz:

• Identisches Audio: Verwenden Sie für jedes System dieselben Dateien, dieselbe Abtastrate und dieselbe Kodierung.
• Identisches Timing: Streamen Sie jedes System mit derselben Echtzeit-Chunk-Frequenz, beispielsweise 100-ms-Chunks.
• Wiederholen und Verteilungen berichten: Führen Sie jede Datei über den Tag hinweg mehrfach aus; berichten Sie Median und Ausreißerbereich (p50/p95).
• Identische Referenzen und Bewertung: Normalisieren Sie Text vor der WER-Berechnung auf dieselbe Weise – Groß-/Kleinschreibung, Satzzeichen und Zahlen.
• Region und Netzwerk offenlegen: Geben Sie an, wo der Benchmark lief und welchen Pfad er zu jedem Anbieter nahm.

Wenn Sie alle diese Elemente gleich halten, erhalten Sie präzisere Metriken.

Grundgerüst für den Benchmark

Der Messkern übernimmt einen Anbieteradapter und erfasst Zeit bis zum ersten Partial, Finalisierungsverzögerung und Partial-Änderungen:

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

Die Wortfehlerrate ist eine standardmäßige Levenshtein-Distanz auf Tokenebene über normalisierten Text. Schreiben Sie Referenz und Hypothese identisch klein und entfernen Sie Satzzeichen, bevor Sie sie berechnen. Andernfalls messen Sie Ihren Normalisierer statt des Modells. Führen Sie diese Messung in einer Schleife aus, die jede Datei pro Anbieter etwa zehnmal verarbeitet und die mediane Zeit bis zum ersten Partial sowie die mediane WER (p50/p95) ausgibt, da einzelne Stichproben stark von Netzwerkschwankungen beeinflusst werden.

Damit es läuft, benötigen Sie zwei Dinge. Schreiben Sie zuerst einen StreamFn-Adapter pro System. Der obige skriptfähige Client ist bereits einer; die Adapter für andere Systeme folgen demselben Vertrag (audioPath, onEvent, result) und setzen result.lastChunkSentAt beim Senden des finalen Audio-Chunks. Laden Sie anschließend Ihre Audiodateien und Referenzen und rufen Sie die Messungen dafür auf. Führen Sie alles auf einer Maschine aus, die Ihre Bereitstellung repräsentiert, mit Audio, das Ihren Nutzern entspricht. So erhalten Sie einen reproduzierbaren Vergleich.

Zusammenfassung: So erreichen Sie Echtzeit-Spracherkennung 

In diesem Artikel haben wir viele Architekturänderungen behandelt, mit denen Sie Ihr System iterativ verbessern und sich der Echtzeit-Spracherkennung annähern können.

Ein produktives Echtzeit-STT-System beruht auf einigen zentralen Entscheidungen:

• Transport: Wählen Sie WebSocket für Einfachheit und kontrollierte Netzwerke und WebRTC, wenn Sie Verlusttoleranz benötigen und von Endgeräten erfassen.
• Partials und Finals: Behandeln Sie Partials als vorläufig und Finals als festgeschrieben. Stellen Sie sie unterschiedlich dar, damit Nutzer dem Live-Text vertrauen.
• End-Pointing: Nutzen Sie VAD für freihändige Segmentierung, manuellen Commit als Override und stimmen Sie den Stille-Schwellenwert auf die Interaktion statt auf eine Konstante ab.
• In-Stream-Funktionen: Aktivieren Sie In-Stream-Funktionen nur dort, wo das Live-Erlebnis sie benötigt, und verschieben Sie den Rest in einen Batch-Durchlauf mit Scribe v2.
• Audioformat: Erfassen Sie in kleinen PCM-Frames, senden Sie Chunks von etwa 100 ms und verwenden Sie für Telefonie das Quellformat.
• Benchmarking: Stellen Sie die Regler für Genauigkeit und Latenz empirisch auf Basis Ihres eigenen Audios und Ihrer Zielmetrik ein.
• API-Sicherheit: Bewahren Sie Ihren API-Key auf dem Server auf oder erstellen Sie Einmal-Tokens für direkte Client-Verbindungen.

Wenn Sie erfahren möchten, wie Sie die Latenz eines Voice Agents optimieren, finden Sie dazu ebenfalls einen Leitfaden.

Echtzeit-Spracherkennungssysteme mit Scribe v2 Realtime entwickeln

Scribe v2 Realtime liefert Partials bei etwa 150 ms Modelllatenz. Ob Ihre Nutzer diesen Wert oder eine höhere Latenz erleben, hängt von der umgebenden Architektur ab – und diesen Teil kontrollieren Sie. Mit den Strategien aus diesem Artikel bauen Sie eine bessere Pipeline-Architektur, die Latenz reduziert und das Kundenerlebnis verbessert. 

Weitere Informationen finden Sie in der Übersicht zu Speech-to-Text-Funktionen, in unserer Modellreferenz mit der vollständigen Funktions- und Sprachenliste sowie auf den Echtzeit-Produktseiten: Echtzeit-Speech-to-Text-API und Echtzeit-Speech-to-Text.

Wenn Sie bereit sind, loszulegen, erstellen Sie ein kostenloses ElevenLabs-Konto und streamen Sie noch heute Ihr erstes Transkript.

FAQ zur Latenz von Echtzeit-Spracherkennung