Echtzeit-Spracherkennung unter 200 ms: Ein Architekturleitfaden

Echtzeit-Spracherkennung (STT) transkribiert Audio während des Sprechens und liefert Text innerhalb weniger hundert Millisekunden. Die Latenz niedrig zu halten, ist jedoch ebenso eine Frage der Architektur wie des Modells. Ingenieure müssen Transport, Chunking, Endpunkt-Erkennung und Audioaufnahme planen – jeder dieser Schritte erhöht die Latenz. Ineffizienz in einem Bereich kann das 200-ms-Ziel sprengen.

Dieser Leitfaden bietet ein praxisnahes System, mit dem Sie Echtzeit-Spracherkennungspipelines von der Transportschicht an aufbauen können. Wir konzentrieren uns auf Scribe v2 Echtzeit, das Teiltranskripte mit etwa 150 ms Modell-Latenz liefert, über 90 Sprachen unterstützt, PCM (8kHz-48kHz) und mu-law Audio akzeptiert und Voice Activity Detection sowie manuelle Commit-Kontrolle für die Segmentfinalisierung bietet.

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

Kurzfassung

• Echtzeit-Spracherkennungssysteme erfordern architektonische Feinabstimmung, damit die Latenz über die gesamte Pipeline niedrig bleibt.
• WebSocket ist für die meisten Pipelines die richtige Wahl, auch wenn WebRTC zusätzliche Vorteile bietet, aber komplexer ist.
• Voice Activity Detection ermöglicht freihändige Segmentierung, während die manuelle Commit-Funktion Ihrer Anwendung eine gezielte Steuerung gibt, wenn das Gesprächsende erkannt wird.
• Teiltranskripte sind vorläufig, finale Transkripte sind fest – Sie sollten sie unterschiedlich darstellen.
• Kleine PCM-Chunks von etwa 100 ms minimieren die Latenz bis zum ersten Teiltranskript.

WebSocket vs. WebRTC für Echtzeit-Spracherkennung

Bevor eine Transkription erfolgt, muss das Audio vom Ursprung zum Erkenner gelangen. Der gewählte Übertragungskanal legt die Latenzuntergrenze für alles Weitere fest. Es gibt zwei praktikable Optionen, um Audio zur Transkriptionsschicht zu bringen.

WebSocket ist ein langlebiger, geordneter, zuverlässiger, bidirektionaler Kanal über TCP. Sie öffnen eine Verbindung, senden binäre Audioframes und empfangen Transkriptereignisse. Es ist sowohl auf Client- als auch auf Serverseite unkompliziert, funktioniert durch Unternehmensproxies und Firewalls, die HTTPS erlauben, und wird von allen Browsern und Serverumgebungen unterstützt.

Die Einschränkung bei WebSocket ist, dass es auf TCP basiert. Geht ein Paket verloren, sendet TCP es erneut und hält nachfolgende Daten zurück, bis die Lücke geschlossen ist. Bei guten Netzwerkbedingungen fällt das nicht auf. Bei Paketverlust kommt es zu Head-of-Line-Blocking, also kurzen Verzögerungen, bei denen Audio gestaut wird und dann gebündelt ankommt.

WebRTC ist für Echtzeit-Medien entwickelt. Es überträgt Medien über UDP (via SRTP), sodass ein verlorenes Paket den Stream nicht anhält; die Pipeline läuft weiter. Ein Jitter-Buffer gleicht Schwankungen in der Paketankunft aus, NAT-Traversal wird mit ICE/STUN/TURN verhandelt, sodass auch Geräte hinter Routern verbunden werden können, und es bringt eigene Audioaufnahme- und Kodierungsfunktionen mit.

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

Hier der Vergleich auf einen Blick:

Für die meisten Anwendungsfälle ist WebSocket die richtige Wahl. Nutzen Sie es, wenn Ihre Clients stabile Verbindungen haben und Sie den Aufnahmeweg kontrollieren: Server-zu-Server-Pipelines, Desktop-Apps, Browser-Apps mit Breitband und die meisten Contact-Center-Backends, bei denen Audio bereits auf Ihrem Server ankommt.

Wählen Sie WebRTC, wenn Sie direkt von Endgeräten auf instabilen Mobilfunknetzen aufnehmen, bereits einen WebRTC-Stack für bidirektionales Audio nutzen (z. B. ein Sprachagent, der auch antwortet), oder wenn niedriger Paketverlust wichtiger ist als einfache Implementierung.

Im weiteren Verlauf dieses Leitfadens wird WebSocket als Transport für die Verbindung zum Erkenner verwendet, da so die Abläufe transparent bleiben und dies für die meisten Teams der beste Ausgangspunkt ist. Nichts davon ist WebSocket-spezifisch – Sie können später einen WebRTC-Medienpfad davor schalten, das Audio auf dem Server zu PCM dekodieren und die gleichen Chunks in die Pipeline geben.

Teil- und Finaltranskripte: Zwischenstände erklärt

Ein Echtzeit-Erkenner wartet nicht auf einen vollständigen Satz, bevor er Text ausgibt. Stattdessen sendet er fortlaufend Hypothesen, die mit weiterem Audio präziser werden und dann festgeschrieben werden. Den Unterschied zwischen diesen Zuständen zu verstehen, ist entscheidend für ein lebendiges Transkripterlebnis.

Ein Teiltranskript (interim) ist die aktuelle beste Schätzung des Modells basierend auf dem bisher empfangenen Audio. Teiltranskripte sind absichtlich instabil. Mit weiterem Audio kann das Modell frühere Wörter anpassen: „Ich möchte“ kann zu „Ich möchte zwei Tickets“ werden, sobald der Kontext klar ist. Sie kommen schnell (das beschreibt die ~150 ms Latenz) und sind zum Überschreiben gedacht.

Ein finales Transkript ist ein festgeschriebenes Segment, das sich nicht mehr ändert. Nach der Finalisierung geht der Erkenner zum nächsten Segment über. Finale Transkripte werden gespeichert, an ein LLM gesendet oder als Transkript archiviert.

Der Unterschied zwischen Teil- und Finaltranskripten beeinflusst drei Dinge, die Sie falsch machen, wenn Sie ihn ignorieren:

• Nutzererlebnis: Das Anzeigen von Teiltranskripten vermittelt ein Live-Gefühl: Nutzer sehen Wörter beim Sprechen erscheinen, was bestätigt, dass das Mikrofon funktioniert und das System zuhört.
• Endpunkt-Erkennung: Teiltranskripte liefern ein kontinuierliches Signal für Sprachaktivität. Zusammen mit VAD können Sie erkennen, wann der Sprecher tatsächlich aufgehört hat.
• Zeitsteuerung nachgelagerter Prozesse: In einer Voice-Agent-Pipeline die Schritte sind: Audioeingabe, dann Speech to Text, dann ein LLM, dann

Stellen Sie Teil- und Finaltranskripte unterschiedlich dar. Ein einfaches, effektives Muster ist, eine veränderbare „aktuelle Zeile“ an das letzte Teiltranskript zu binden und sie bei Finalisierung an das Transkript anzuhängen:

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

Visualisieren Sie Finaltranskripte als festen Text und Teiltranskripte in heller oder kursiver Schrift, damit Nutzer erkennen, dass sich der Text noch ändern kann.

Endpunkt-Erkennung und Voice Activity Detection (VAD)

Zu wissen, was gesagt wurde, ist nur die halbe Miete. Ein Erkenner muss auch wissen, wann ein Gedanke abgeschlossen ist. Diese Entscheidung bestimmt, wann ein Segment finalisiert wird und – bei einem Agenten – wann das System antwortet.

Endpunkt-Erkennung ist die Entscheidung, dass eine Äußerung beendet ist. Zu frühe Finalisierung schneidet Nutzer mitten im Satz ab. Zu späte Finalisierung lässt einen Agenten nach dem Ende der Äußerung zu lange schweigen.

Scribe v2 Realtime bietet zwei ergänzende Mechanismen:

• Voice Activity Detection segmentiert Audio anhand von Stille: Der Erkenner erkennt, wenn Sprache in längere Stille übergeht, und nutzt diese Grenze zur automatischen Finalisierung eines Segments. VAD ist der Standard für Konversationsschnittstellen, da es sich dem natürlichen Sprechrhythmus anpasst, ohne dass Sie die Zeit manuell verfolgen müssen.
• Manuelle Commit-Kontrolle: Mit der manuellen Commit-Kontrolle kann Ihre Anwendung unabhängig von Stille entscheiden, wann das aktuelle Segment finalisiert wird. Sie senden ein Commit-Signal, der Erkenner schließt das Segment ab und gibt ein finales Transkript aus. Das ist sinnvoll, wenn Ihre Anwendung bereits weiß, dass der Gesprächswechsel erfolgt ist: etwa beim Loslassen einer Push-to-Talk-Taste, einer „Senden“-Aktion oder einer externen Turn-Taking-Logik.

Beide Mechanismen lassen sich gut kombinieren. Ein typischer Voice Agent nutzt VAD für freihändigen Betrieb und bietet die manuelle Commit-Funktion als Override, sodass ein Nutzer, der nachdenkt, nicht unterbrochen wird, aber ein Nutzer, der eine Taste drückt, sofort eine Segmentgrenze erhält.

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

• Ein kurzer Timeout (z. B. Finalisierung nach ~200-400 ms Stille) sorgt für ein reaktionsschnelles System, kann aber Nutzer bei natürlichen Pausen mitten im Satz abschneiden und einen Gedanken in mehrere Segmente aufteilen.
• Ein langer Timeout (z. B. ~800-1200 ms) toleriert natürliche Pausen und hält Äußerungen zusammen, führt aber zu spürbarer Verzögerung, bevor das System reagiert.

Es gibt hier keine globale Konstante – passen Sie den Schwellenwert an die Interaktion an:

• Diktat und Notizen vertragen längere Pausen, da Nutzer beim Sprechen nachdenken. Bevorzugen Sie längere Timeouts und setzen Sie auf VAD.
• Command-and-Control- und Transaktionsagenten profitieren von kürzeren Timeouts plus manueller Commit-Funktion, da die Gesprächswechsel kurz und klar sind.
• Mehrsprachige oder nicht-muttersprachliche Sprecher machen mehr Pausen – planen Sie mehr Stille ein, bevor Sie finalisieren.

Mit diesen Tipps bauen Sie ein effektives Endpunkt-Erkennungssystem und kommen der Echtzeit-Spracherkennung näher.

In-Stream-Features: Spracherkennung und Sprechertrennung

Streaming-Erkennung kann mehr als nur Wörter liefern. Allerdings beeinflusst jedes zusätzliche Signal die Latenz und Stabilität. Die Faustregel: Aktivieren Sie nur, was das Live-Erlebnis benötigt, und verschieben Sie den Rest in einen Batch-Durchlauf.

Automatische Spracherkennung ermöglicht es Scribe v2 Realtime, die gesprochene Sprache aus über 90 unterstützten Sprachen zu erkennen, ohne dass Sie sie vorher angeben müssen. Das Modell benötigt dafür einen kurzen Audioabschnitt, sodass die ersten Teiltranskripte eines Streams weniger stabil sein können, bis die Sprache erkannt ist. Wenn Sie die Sprache bereits kennen, geben Sie sie an – das sorgt für stabilere Teiltranskripte zu Beginn.

Sprechertrennung ordnet Sprache verschiedenen Sprechern zu und erkennt, wer was gesagt hat. Im Batch-Modus ist das vergleichsweise einfach, da das Modell die gesamte Datei sieht. Im Streaming ist es schwieriger: Der Erkenner muss anhand des bisherigen Audios ein Sprecherlabel vergeben, das sich mit mehr Kontext noch ändern kann. Behandeln Sie Streaming-Sprecherlabels wie Teiltranskripte: Sie sind vorläufig, bis das Segment finalisiert ist.

Wortgenaue Zeitstempel und Entitäten folgen derselben Logik. Je mehr Metadaten Sie pro Token anfordern, desto mehr müssen Modell und Übertragung leisten. Für die meisten Echtzeit-UIs benötigen Sie nur Text und Segmentgrenzen live – feingranulare Metadaten können Sie im Nachgang mit Scribe v2 im Batch-Modus verarbeiten.

Audioformate für Streaming: PCM und mu-law

Transport und Erkennung stehen oft im Fokus, aber viele Fehler entstehen eine Ebene tiefer – bei der Kodierung und Chunk-Größe des Audios. Das richtige Format und die passende Chunk-Größe sind der einfachste Weg, Latenz zu reduzieren.

PCM (linear, 16 Bit, little-endian) ist das Format der Wahl, wenn Sie die Aufnahme kontrollieren. Höhere Abtastraten liefern mehr akustische Details: 16 kHz ist Standard für Spracherkennung und meist ausreichend; 8 kHz ist Telefonqualität und verliert hohe Frequenzen. Nutzen Sie die Rate, die Ihrer Quelle entspricht. Ein Upsampling von 8 kHz auf 48 kHz bringt keinen Vorteil, da keine zusätzlichen Informationen gewonnen werden.

Mu-law mit 8 kHz ist das Telefonieformat. Wenn Sie Anrufe von einem Anbieter wie Twilio empfangen, kommt das Audio als 8 kHz mu-law an – leiten Sie es in diesem Format weiter, statt es mehrfach zu transkodieren. Das Quellformat zu übernehmen, vermeidet Resampling-Artefakte und unnötige Konvertierungen.

Die Chunk-Größe beeinflusst die wahrgenommene Latenz am stärksten. Sie senden Audio in Chunks, der Erkenner liefert Teiltranskripte, sobald Chunks ankommen. Kleinere Chunks bedeuten häufigere Updates und geringere Latenz bis zum ersten Teiltranskript; größere Chunks bedeuten weniger Nachrichten und etwas mehr Kontext pro Inferenz. Ein praxisnaher Bereich sind 20–250 ms Audio pro Chunk. Als Anhaltspunkt: Bei 16 kHz Mono 16 Bit PCM sind 1 Sekunde Audio 32.000 Bytes, ein 100-ms-Chunk etwa 3.200 Bytes.

Mikrofoneingabe im Browser erfassen

Im Browser ist die Web Audio API mit einem AudioWorklet das richtige Werkzeug. Das Worklet läuft im Audio-Thread, erhält Audio in kleinen Frames und ist nicht von Main-Thread-Lags betroffen wie das ältere ScriptProcessorNode. Es wandelt die nativen Float-Samples des Browsers in 16-Bit-PCM um und übergibt sie an den Main-Thread, der sie über WebSocket weiterleitet.

Der Kern des Worklet-Prozessors ist die Umwandlung von Float zu 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);

Die Pipeline im Code

Die Pipeline besteht aus drei Teilen: Einem Browser-Client, der das Mikrofon erfasst und PCM an Ihren Server streamt, einem Node-Server, der Audio an Scribe v2 Realtime weiterleitet und Transkripte zurückgibt, und einem skriptgesteuerten Client, der PCM aus einer Datei oder Telefonie-Bridge streamt.

Der Server leitet weiter, statt den Erkenner direkt im Browser verfügbar zu machen – aus einem Grund: Ihr ElevenLabs API-Schlüssel ist geheim und darf nie im Client-Code erscheinen. Der Server hält den Schlüssel. Falls der Browser direkt mit dem Erkenner sprechen muss, generieren Sie serverseitig ein kurzlebiges Einmal-Token und geben Sie dieses an den Client weiter.

Browser-Client

Der Client öffnet einen WebSocket zu Ihrem Server, erfasst das Mikrofon über das oben beschriebene Worklet und leitet jedes PCM-Frame weiter, sobald es erzeugt wird. Eingehende Ereignisse (vom Server bereits normalisiert zu { type, text }) steuern den Teil-/Finalstatus wie zuvor beschrieben:

// 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 Verbindung zum Erkenner, hält den API-Schlüssel serverseitig, leitet binäres PCM direkt durch und normalisiert Erkenner-Ereignisse in das stabile { type, text }-Format, 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 Endpoint-spezifische ist auf die beiden Adapterfunktionen unten beschränkt. Ersetzen Sie die Feldnamen durch die 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;
}

Skriptgesteuerter Backend-Client

Für Backend-Pipelines und den untenstehenden Benchmark funktioniert die gleiche Erkenner-Verbindung ohne Browser: Lesen Sie PCM aus beliebiger Quelle, takten Sie es im Echtzeit-Chunk-Rhythmus und lesen Sie die Ereignisse zurück. API-Schlüssel und URL kommen 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`);
});

Benchmarking von Spracherkennungslatenz und Wortfehlerrate

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

Ein Ergebnis, das auf einem Laptop in einer Stadt gemessen wurde, lässt sich nicht auf Ihre Produktionsumgebung in einer anderen übertragen. Führen Sie den Test auf Infrastruktur aus, die der Produktion ähnelt, mit Audio, das Ihren echten Daten entspricht, und berichten Sie Bereiche und Verteilungen statt Einzelwerten.

Die einzigen relevanten Latenz- und Genauigkeitswerte sind die, die Sie mit Ihrem eigenen Audio und produktionsnaher Infrastruktur messen. Hier ein Leitfaden zum Benchmarking der Spracherkennungslatenz.

Was Sie bei der Spracherkennungslatenz messen sollten

Folgende Hauptmetriken sollten Sie beim Benchmarking der Echtzeit-Spracherkennungslatenz erfassen:

• Zeit bis zum ersten Teiltranskript: Vom Senden des ersten Audio-Chunks bis zum Empfang des ersten nicht-leeren Teiltranskripts.
• Verzögerung von Teil- zu Finaltranskript: Vom letzten Audio-Chunk einer Äußerung bis zur finalen Hypothese.
• Wortfehlerrate (WER): WER auf dem finalen Transkript im Vergleich zu einer menschlichen Referenz, identisch über alle Systeme berechnet.
• Stabilitätsänderungen: Wie oft Teiltranskripte vor der Finalisierung überschrieben werden. Dies ist ein Indikator dafür, wie stark sich die Live-UI verändert.

Kontrollen

Um verlässliche Daten zu erhalten, sollten Sie mehrere Kontrollen in Ihr Experiment einbauen, um Konsistenz zu gewährleisten.

Hier die wichtigsten Kontrollen für das Benchmarking der Spracherkennungslatenz:

• Identisches Audio: Verwenden Sie die gleichen Dateien, dieselbe Abtastrate und Kodierung für jedes System.
• Identisches Timing: Streamen Sie jedes System mit dem gleichen Echtzeit-Chunk-Rhythmus (z. B. 100-ms-Chunks).
• Wiederholen und Verteilungen berichten: Führen Sie jede Datei mehrfach über den Tag verteilt aus; berichten Sie Median und Randwerte (p50/p95).
• Identische Referenzen und Auswertung: Normalisieren Sie Text (Groß-/Kleinschreibung, Interpunktion, Zahlen) vor der WER-Berechnung identisch.
• Region und Netzwerk offenlegen: Geben Sie an, wo der Test lief und wie der Netzwerkpfad zu jedem Anbieter war.

Wenn Sie all diese Elemente konstant halten, erhalten Sie präzisere Metriken.

Test-Harness-Grundstruktur

Der Messkern nimmt einen Anbieter-Adapter und zeichnet Zeit bis zum ersten Teiltranskript, Finalisierungsverzögerung und Teiltranskript-Änderungen auf:

// 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 ein standardisierter Token-Levenshtein-Abstand über normalisiertem Text. Wandeln Sie Referenz und Hypothese identisch in Kleinbuchstaben um und entfernen Sie Interpunktion, bevor Sie messen – sonst messen Sie Ihren Normalizer statt des Modells. Führen Sie die Messung in einer Schleife aus, die jede Datei etwa 10-mal pro Anbieter laufen lässt, und berichten Sie Medianwerte für Zeit bis zum ersten Teiltranskript und WER (p50/p95), da einzelne Messungen stark von Netzwerkvariabilität beeinflusst werden.

Zum Ausführen benötigen Sie zwei Dinge: Schreiben Sie für jedes System einen StreamFn-Adapter. Der oben beschriebene skriptgesteuerte Client ist bereits einer, weitere Adapter folgen dem gleichen (audioPath, onEvent, result)-Schema und setzen result.lastChunkSentAt, wenn der letzte Audio-Chunk gesendet wird. Laden Sie dann Ihre Audiodateien und Referenzen und rufen Sie die Messungen darauf auf. Führen Sie den Test auf einer Maschine aus, die Ihrer Produktionsumgebung entspricht, mit Audio, das Ihren Nutzern entspricht – so erhalten Sie reproduzierbare Vergleiche.

Zusammenfassung: So erreichen Sie Echtzeit-Spracherkennung

In diesem Artikel haben wir zahlreiche architektonische Anpassungen behandelt, mit denen Sie Ihr System schrittweise verbessern und Echtzeit-Spracherkennung erreichen.

Ein produktives Echtzeit-STT-System hängt von wenigen Entscheidungen ab:

• Übertragung: Wählen Sie WebSocket für einfache, kontrollierte Netzwerke und WebRTC, wenn Sie Verlusttoleranz benötigen und von Endgeräten aufnehmen.
• Teil- und Finaltranskripte: Behandeln Sie Teiltranskripte als vorläufig und Finaltranskripte als festgeschrieben und stellen Sie sie unterschiedlich dar, damit Nutzer dem Live-Text vertrauen.
• Endpunkt-Erkennung: Nutzen Sie VAD für freihändige Segmentierung, manuelle Commit-Funktion als Override und passen Sie den Stille-Schwellenwert an die Interaktion an, nicht an einen festen Wert.
• In-Stream-Features: Aktivieren Sie In-Stream-Features nur, wenn sie für das Live-Erlebnis nötig sind, und verschieben Sie den Rest in einen Batch-Durchlauf mit Scribe v2.
• Audioformat: Erfassen Sie kleine PCM-Frames, senden Sie ~100-ms-Chunks und übernehmen Sie das Quellformat bei Telefonie.
• Benchmarking: Stellen Sie die Genauigkeits- und Latenzparameter empirisch anhand Ihres eigenen Audios und Zielwerts ein.
• API-Sicherheit: Bewahren Sie Ihren API-Schlüssel auf dem Server auf oder generieren Sie Einmal-Tokens für direkte Client-Verbindungen.

Wenn Sie sehen möchten, wie Sie die Latenz in einem Voice Agent optimieren können, haben wir ebenfalls einen Leitfaden für Sie.

Echtzeit-Spracherkennungssysteme mit Scribe v2 Realtime aufbauen

Scribe v2 Realtime liefert Teiltranskripte mit etwa 150 ms Modell-Latenz. Ob Ihre Nutzer diesen Wert oder einen höheren erleben, hängt von der umgebenden Architektur ab – und die liegt in Ihrer Hand. Mit den in diesem Artikel beschriebenen Strategien bauen Sie eine optimierte Pipeline-Architektur, die Latenz reduziert und das Nutzererlebnis verbessert.

Für mehr Details entdecken Sie die Funktionen von Speech to Text im Überblick, lesen Sie unsere Modellreferenz für die vollständige Funktions- und Sprachenliste und besuchen Sie die Produktseiten für Echtzeitlösungen: Echtzeit Speech to Text API und Echtzeit Speech to Text.

Wenn Sie bereit sind zu starten, erstellen Sie ein kostenloses ElevenLabs-Konto und streamen Sie Ihr erstes Transkript.

FAQ zur Echtzeit-Spracherkennungslatenz