Zur Navigation springen

Transkripte und Commit-Strategien

Dieser Leitfaden zeigt, wie Sie Transkripte und Commit-Strategien mit der ElevenLabs API für Echtzeit-Spracherkennung verwalten.

Anleitung · Setzt voraus, dass Sie die Anleitung für clientseitiges oder serverseitiges Streaming abgeschlossen haben.

Überblick

Beim Transkribieren von Audio erhalten Sie teilweise und abgeschlossene Transkripte.

  • Teilweise Transkripte – die Zwischenergebnisse der Transkription
  • Abgeschlossene Transkripte – die endgültigen Ergebnisse des Transkriptionssegments, die beim Empfang einer „Commit“-Nachricht gesendet werden. Eine Sitzung kann mehrere abgeschlossene Transkripte enthalten.

Das abgeschlossene Transkript kann optional Zeitstempel auf Wortebene enthalten. Diese werden nur empfangen, wenn die Option „include timestamps“ auf true gesetzt ist.

# Initialize the connection
connection = await elevenlabs.speech_to_text.realtime.connect(RealtimeUrlOptions(
model_id="scribe_v2_realtime",
include_timestamps=True, # Include this to receive the RealtimeEvents.COMMITTED_TRANSCRIPT_WITH_TIMESTAMPS event with word-level timestamps
))

Commit-Strategien

Beim Senden von Audio-Chunks über WebSocket können Transkriptsegmente auf zwei Arten abgeschlossen werden: manueller Commit oder Voice Activity Detection (VAD).

Manueller Commit

Mit der manuellen Commit-Strategie steuern Sie, wann Transkriptsegmente abgeschlossen werden. Diese Strategie wird standardmäßig verwendet. Das Abschließen eines Segments löscht das verarbeitete, angesammelte Transkript und startet ein neues Segment, ohne Kontext zu verlieren. Um die Latenz zu verbessern, empfiehlt es sich, alle 20–30 Sekunden einen Commit auszuführen. Auch ohne manuellen Commit schließt das Modell nach etwa 36 Sekunden angesammeltem Audio automatisch ab.

Für beste Ergebnisse führen Sie den Commit während Sprechpausen oder an einem anderen logischen Punkt aus, etwa bei einem Sprecherwechsel.

Die Verarbeitung des Transkripts beginnt, nachdem die ersten 2 Sekunden Audio gesendet wurden.
await connection.send({
"audio_base_64": audio_base_64,
"sample_rate": 16000,
})
# When ready to finalize the segment
await connection.commit()

Mehrere manuelle Commits in kurzer Folge können die Modellleistung beeinträchtigen.

Vorherigen Textkontext senden

Beim Senden von Audio zur Transkription können Sie zusammen mit dem ersten Audio-Chunk vorherigen Textkontext senden. So versteht das Modell den Kontext der Sprache besser. Das ist in einigen Szenarien nützlich:

  • Agententext für Anwendungsfälle mit konversationeller KI – Ermöglicht dem Modell, den Gesprächskontext leichter zu verstehen und bessere Transkriptionen zu erstellen.
  • Wiederverbindung nach einem Netzwerkfehler – Dadurch kann das Modell die Transkription mithilfe des vorherigen Texts als Orientierung fortsetzen.
  • Allgemeine Kontextinformationen – Eine kurze Beschreibung, worum es in der Transkription geht, hilft dem Modell, den Kontext zu verstehen.

Das Senden des Kontexts previous_text ist nur beim Senden des ersten Audio-Chunks über connection.send() möglich. Das Senden in nachfolgenden Chunks führt zu einem Fehler. Vorheriger Text funktioniert am besten, wenn er weniger als 50 Zeichen lang ist.

await connection.send({
"audio_base_64": audio_base_64,
"previous_text": "The previous text context",
})

Voice Activity Detection (VAD)

Mit der VAD-Strategie erkennt die Transkriptions-Engine automatisch Sprach- und Stillesegmente. Wenn ein Schwellenwert für Stille erreicht wird, schließt die Transkriptions-Engine das Transkriptsegment automatisch ab.

Beim Transkribieren von Mikrofon-Audio in der clientseitigen Integration wird die VAD-Strategie empfohlen.

import { Scribe, AudioFormat, CommitStrategy } from "@elevenlabs/client";
const connection = Scribe.connect({
token: "sutkn_1234567890",
modelId: "scribe_v2_realtime",
audioFormat: AudioFormat.PCM_16000,
commitStrategy: CommitStrategy.VAD,
vadSilenceThresholdSecs: 1.5,
vadThreshold: 0.4,
minSpeechDurationMs: 100,
minSilenceDurationMs: 100,
});

Verbindung während Stille aufrechterhalten

Die offiziellen SDKs trennen die Verbindung nicht, wenn keine Nachrichten eingehen. Daher benötigen die meisten Integrationen dies nicht. Wenn Ihr eigener WebSocket-Client, ein Proxy oder ein vorgeschalteter Load Balancer die Verbindung schließt, sobald eine Zeit lang keine Frames eingehen, übergeben Sie beim Verbinden den optionalen Abfrageparameter keepalive_interval_ms. Das ist bei längeren Stillephasen wichtig, etwa bei einem Telefongespräch mit Pausen von 10–15 Sekunden. Etwa einmal pro Intervall sendet der Server ein Keepalive-partial_transcript: leer (text: ""), wenn das aktuelle Segment keinen nicht abgeschlossenen Text enthält, oder als Wiederholung des neuesten teilweisen Texts, falls es solchen enthält.

Keepalives sind keine fortlaufenden Pings: Sie müssen weiterhin Audio streamen (Stille-Frames sind ausreichend). Wenn Sie kein Audio mehr senden, werden keine Keepalives gesendet, und der Server schließt die Verbindung nach 15 Sekunden ohne Client-Nachrichten. Dieses Serverlimit kann nicht konfiguriert werden.

  • Akzeptiert eine Ganzzahl zwischen 500 und 10000 (Millisekunden). Standardmäßig ist die Funktion deaktiviert; lassen Sie den Parameter weg, um das bisherige Verhalten beizubehalten.
  • Werte außerhalb des Bereichs oder keine Ganzzahlen führen dazu, dass der Server einen invalid_request-Fehler sendet und die Verbindung schließt.
  • Keepalives werden durch die tatsächliche Verarbeitung des gesendeten stillen Audios durch das Modell ausgelöst, nicht durch einen fortlaufenden Timer. Sie bestätigen somit auch, dass der Transkriptionspfad aktiv ist.
  • Audio wird in Chunks von etwa 1 Sekunde verarbeitet. Keepalives treffen daher etwa einmal pro Intervall ein, gerundet auf diesen Takt (zum Beispiel löst 1000 etwa einmal pro Sekunde aus, 3000 etwa alle 3 Sekunden). Das erste Keepalive einer Sitzung trifft etwa 2 Sekunden nach ihrem Start ein, da der Server die ersten etwa 2 Sekunden Audio vor der Transkription puffert. Setzen Sie Ihr Intervall auf höchstens etwa ein Drittel Ihres eigenen Lese-Timeouts, um Spielraum zu lassen.
  • Der text eines Keepalives ist nur leer, wenn das aktuelle Segment noch keinen nicht abgeschlossenen Text enthält. Tritt eine Pause nach Sprache, aber vor einem Commit auf – besonders sichtbar mit filter_background_audio=true oder im manuellen Commit-Modus ohne Commit –, wiederholt das Keepalive stattdessen den neuesten teilweisen Text. Zwischentexte werden also nie geleert. Nach einem Commit sind Keepalives wieder leer, bis neue Sprache eingeht.
  • Funktioniert mit commit_strategy=manual und commit_strategy=vad sowie mit filter_background_audio=true. Abgesehen von dem Audio, das Sie bereits streamen, entstehen keine zusätzlichen Kosten.
  • Die config der Nachricht session_started gibt keepalive_interval_ms zurück (null, wenn deaktiviert).

Ein leeres partial_transcript (text: "") bedeutet „keine Sprache im aktuellen Segment“. Ein wiederholtes, identisches partial_transcript während einer Pause ist ebenfalls ein Keepalive – Clients sollten Teilergebnisse einfach wie gewohnt darstellen, statt die Wiederholung gesondert zu behandeln.

Fügen Sie den Parameter zur WebSocket-URL hinzu:

wss://api.elevenlabs.io/v1/speech-to-text/realtime?model_id=scribe_v2_realtime&commit_strategy=vad&keepalive_interval_ms=1000

Unterstützte Audioformate

FormatAbtastrateBeschreibung
pcm_80008 kHz16-Bit-PCM, Little-Endian
pcm_1600016 kHz16-Bit-PCM, Little-Endian (empfohlen)
pcm_2205022,05 kHz16-Bit-PCM, Little-Endian
pcm_2400024 kHz16-Bit-PCM, Little-Endian
pcm_4410044,1 kHz16-Bit-PCM, Little-Endian
pcm_4800048 kHz16-Bit-PCM, Little-Endian
ulaw_80008 kHz8-Bit-μ-Law-Kodierung

Best Practices

Audioqualität

  • Verwenden Sie für ein optimales Verhältnis von Qualität und Bandbreite eine Abtastrate von 16 kHz.
  • Sorgen Sie für ein sauberes Audiosignal mit möglichst wenig Hintergrundgeräuschen.
  • Verwenden Sie eine passende Mikrofonverstärkung, um Clipping zu vermeiden.
  • Derzeit wird nur Mono-Audio unterstützt.

Chunk-Größe

  • Senden Sie Audio-Chunks mit einer Länge von 0,1–1 Sekunde für reibungsloses Streaming.
  • Kleinere Chunks führen zu geringerer Latenz, aber mehr Overhead.
  • Größere Chunks sind effizienter, können aber Latenz verursachen.

Nächste Schritte