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.
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.
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.
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.
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
500und10000(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
1000etwa einmal pro Sekunde aus,3000etwa 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
texteines 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 mitfilter_background_audio=trueoder 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=manualundcommit_strategy=vadsowie mitfilter_background_audio=true. Abgesehen von dem Audio, das Sie bereits streamen, entstehen keine zusätzlichen Kosten. - Die
configder Nachrichtsession_startedgibtkeepalive_interval_mszurü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:
Unterstützte Audioformate
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.