Wie KI mehrere Sprecher verarbeitet: Grenzen und Einstellungen

Wie Engines Sprecher trennen

Wenn Sie eine Aufnahme mit mehreren Sprechern hochladen, erledigt die KI zwei getrennte Aufgaben: Sie transkribiert die Worte und findet heraus, wer was gesagt hat. Die meisten Menschen nehmen an, dass beides gleichzeitig passiert. Dem ist nicht so. Das Transkriptionsmodell und das Diarisierungsmodell laufen parallel, und ihre Ausgaben werden erst am Ende zusammengefügt. Wer diese Trennung versteht, versteht auch, warum Transkription mit mehreren Sprechern so häufig schiefgeht.

Der Fachbegriff für die Aufgabe „Wer hat was gesagt?" lautet Sprecher-Diarisierung. Einen tieferen Blick darauf, wie die zugrundeliegenden Modelle funktionieren, bietet Sprecher-Diarisierung erklärt. Dieser Beitrag konzentriert sich auf die praktische Seite: wie Engines Audio mit mehreren Sprechern verarbeiten, welche dokumentierten Sprecher-Grenzen es gibt und wo die Genauigkeit nachlässt.

Die Zwei-Modell-Architektur

Eine typische Transkriptions-Engine führt zwei Modelle auf jedem Audiomaterial aus.

Das Transkriptionsmodell wandelt die Audio-Wellenform in Text mit Wortzeitstempeln um. Es erzeugt etwa Folgendes: „0,4 s: die, 0,6 s: Besprechung, 0,9 s: beginnt, 1,2 s: jetzt." Es hat keine Ahnung, wie viele Personen sprechen.

Das Diarisierungsmodell liefert eine andere Art von Ausgabe: eine Sprecher-Zeitleiste. Es sagt: „Von 0,0 s bis 14,2 s ist dies Sprecher A; von 14,2 s bis 16,0 s ist dies Sprecher B." Es hat keine Ahnung, was die Sprecher gesagt haben.

Sind beide Modelle fertig, gleicht die Engine ihre Ausgaben ab. Jedes Wort erhält das Sprecher-Label, das die Diarisierungs-Zeitleiste seinem Zeitstempel zugeordnet hat. Das Ergebnis ist ein Transkript mit Sprecher-Labels.

Das Diarisierungsmodell selbst arbeitet typischerweise in drei Schritten: Sprachaktivitätserkennung (Auffinden der Audiobereiche, die Sprache enthalten), Speaker Embedding (Umwandlung kurzer Audiosegmente in Vektoren, die die Stimmidentität codieren) und Clustering (Gruppierung ähnlicher Vektoren zu Sprecher-Labels). Unter der Haube verwenden die meisten kommerziellen APIs Varianten dieser Pipeline, oft aufbauend auf oder inspiriert von pyannote, dem dominierenden Open-Source-Framework für Diarisierung.

Ein wichtiger Hinweis: Das Diarisierungsmodell identifiziert Sprecher nicht beim Namen. Es vergibt Cluster-Labels. „Sprecher 1" und „Sprecher 2" sind Cluster-IDs, keine echten Identitäten. Die Zuordnung echter Namen erfolgt – falls überhaupt – separat über Sprecher-Enrollment, Kalender-Metadaten oder manuelles Umbenennen.

Was „Max-Sprecher"-Einstellungen tatsächlich bedeuten

Die meisten Transkriptions-APIs bieten einen Parameter für die Sprecherzahl an. Hier ist, was die großen Engines Stand Mitte 2026 dokumentieren.

Ein paar Dinge, die Ihnen die Tabelle nicht verrät: Eine hohe Parameter-Obergrenze bedeutet keine genaue Ausgabe an dieser Grenze. MaxSpeakerLabels=30 in AWS Transcribe zu setzen heißt nicht, dass AWS zuverlässig 30 verschiedene Sprecher identifiziert. Es bedeutet nur, dass das System es versucht. Die Genauigkeit am oberen Ende des Bereichs einer jeden Engine ist deutlich niedriger als bei 2 bis 4 Sprechern.

Wie die Genauigkeit mit der Sprecherzahl nachlässt

Je mehr Sprecher dazukommen, desto weniger Audio trägt jeder Sprecher pro Minute bei – und desto schwieriger wird das Clustering-Problem. Ein Gespräch mit zwei Sprechern gibt dem Modell mehrere Minuten Sprachsignal pro Person, um ein zuverlässiges Stimmprofil aufzubauen. Eine Konferenzschaltung mit 10 Sprechern gibt jeder Person vielleicht 90 Sekunden fragmentierter Beiträge.

Benchmark-Datensätze liefern einige Referenzpunkte, wobei es sich um Werte unter kontrollierten Bedingungen handelt. Auf dem AMI-Meeting-Korpus (Mikrofonaufnahmen, 3–4 Sprecher, kontrollierte Bedingungen) erreichen State-of-the-Art-Systeme eine Diarisierungsfehlerrate (DER) von rund 7 %. Auf DIHARD, einem deutlich schwierigeren Datensatz mit verrauschterem, vielfältigerem Audio, steigt die DER selbst für starke Systeme auf etwa 18 %. Reale Aufnahmen mit schlecht eingerichteten Mikrofonen, überlappender Sprache und vielen Sprechern landen typischerweise näher am DIHARD-Bereich oder darunter.

Die DER misst den Anteil der Sprachzeit, der dem falschen Sprecher-Cluster zugeordnet wird, zusammen mit verpasster Sprache und Fehlalarmen. Eine DER von 7 % bei einer einstündigen Aufnahme bedeutet, dass rund 4 Minuten Audio falsch zugeordnet sind. Für eine Meeting-Zusammenfassung ist das verkraftbar; für ein wörtliches Protokoll juristischer Art ist es nicht akzeptabel.

Die Bedingungen, die die DER zuverlässig in die Höhe treiben:

Viele Sprecher. Sechs oder mehr sind der Punkt, an dem die meisten Engines ins Straucheln geraten. Die Cluster beginnen sich zu überlappen; kurze Beiträge werden falsch zugeordnet; ähnlich klingende Sprecher werden zusammengelegt.

Kurze Beiträge. „Ja", „genau", „stimmt." Diese Ein-Wort-Beiträge geben dem Embedding-Modell kaum etwas zum Arbeiten. Sie werden häufig falsch gelabelt, selbst wenn längere Beiträge desselben Sprechers korrekt sind.

Ähnliche Stimmen. Zwei Personen gleichen Geschlechts, ähnlichen Alters und mit ähnlichem Akzent können im Embedding-Raum eng beieinanderliegen. Der Clustering-Algorithmus legt sie manchmal zusammen oder vertauscht ihre Labels mitten im Gespräch.

Ein einzelnes Mikrofon, Raumakustik. Ein Deckenmikrofon in einem Konferenzraum mischt alle Stimmen, bevor irgendeine Signalverarbeitung stattfindet. Pro Kanal getrennte Signale von einzelnen Mikrofonen lassen sich dramatisch einfacher diarisieren. Speziell zu überlappender Sprache siehe überlappende Sprache behandeln und überlappende Sprecher korrigieren.

Die Whisper-Lücke

Whisper verdient eine eigene Erwähnung, weil es die Grundlage vieler Transkriptions-Tools ist. Das Whisper-Modell von OpenAI hat keinerlei native Diarisierung. Es erzeugt ein Transkript ohne Sprecher-Labels.

Produkte, die auf rohem Whisper aufbauen, verzichten entweder komplett auf Diarisierung, setzen WhisperX auf (das die Whisper-Ausgabe durch pyannote leitet) oder führen ein separates Diarisierungsmodell auf demselben Audio aus. Wenn sich ein Tool als „Whisper-basiert" beschreibt und Sprecher-Labels anbietet, fragen Sie, welches Diarisierungsmodell es verwendet und wo der Abgleich stattfindet. Die Antwort ist entscheidend für die Genauigkeit bei schwierigem Audio.

Einen Vergleich, wie Whisper gegen spezialisierte APIs abschneidet, finden Sie unter Whisper vs. Google Cloud Speech 2026 und beste Speech-to-Text-APIs 2026.

Meeting-Bot vs. Diarisierung beim Datei-Upload

Zwei verschiedene Architekturen, zwei verschiedene Genauigkeitsprofile.

Meeting-Bots (Otter, Fireflies und ähnliche Tools) nehmen am Call als Teilnehmer teil. Sie können Audio-Streams pro Teilnehmer von der Plattform erfassen, auf Kalender-Metadaten mit Teilnehmernamen zugreifen und Sprecher-Labels in Echtzeit echten Namen zuordnen. Das ist ein struktureller Vorteil für meeting-zentrierte Anwendungsfälle. Fireflies dokumentiert Unterstützung für bis zu 50 Sprecher pro Gespräch – mehr als die meisten Datei-Upload-APIs, teilweise weil die Trennung der Streams pro Teilnehmer das Diarisierungsproblem deutlich leichter macht.

Datei-Upload-APIs arbeiten mit einem Mono- oder Stereo-Mix. Sie haben keinen der Vorteile der Teilnehmer-Streams. Bei Meeting-Aufnahmen bedeutet das, dass die Genauigkeit typischerweise niedriger ist als die eines Bots, der dasselbe Meeting live besucht hat. Bei anderen Audioarten (Podcasts, Interviews, Gerichtsanhörungen) ist der Datei-Upload-Ansatz die einzige Option.

Meine Einschätzung: Für Genauigkeit bei mehreren Sprechern in aufgezeichneten Meetings hat ein nativer Meeting-Bot einen strukturellen Vorsprung. Für alles andere sind Deepgram Nova-3 und AssemblyAI die stärksten Datei-Upload-Optionen, basierend auf aktuellen Benchmarks und dem dokumentierten Sprecherbereich. Testen Sie aber an Ihrem eigenen Audio, bevor Sie sich auf eine Pipeline festlegen. DER-Benchmarks werden auf kontrollierten Datensätzen gemessen; Ihre Aufnahmen sind nicht kontrolliert.

Wann Sie die Diarisierung deaktivieren sollten

Nicht jede Aufnahme mit mehreren Sprechern braucht Diarisierung. Ein paar Fälle, in denen sie eher Rauschen als Wert hinzufügt:

Solo-Aufnahmen mit gelegentlichen Hintergrundstimmen. Ein einzelner Erzähler mit einem Co-Moderator, der selten spricht. Die Diarisierung erzeugt jedes Mal Scheinwechsel der Sprecher, wenn die Hintergrundstimme sich meldet.

Closed Captions und Video-Untertitel. Der Zuschauer sieht das Video; die Sprecherstruktur ist erkennbar. Labels bringen nur Unruhe.

Sehr kurze Clips. Unter zwei Minuten ist die Sprecherstruktur meist aus dem Kontext ersichtlich, und das Modell hat zu wenig Audio, um ein zuverlässiges Cluster aufzubauen.

Bei Dateien mit nur einem Sprecher lassen die meisten Engines die Diarisierung explizit deaktivieren. Tun Sie das. Sie erhalten ein sauberes Transkript und schnellere Verarbeitung.

Wenn Sie falsche Sprecher-Labels in einem bestehenden Transkript korrigieren müssen, behandelt der Beitrag falsche Sprecher-Labels korrigieren den Korrektur-Workflow.

Worauf Sie bei der Transkription mehrerer Sprecher achten sollten

Eine kurze Checkliste zur Bewertung einer Engine für den Einsatz mit mehreren Sprechern:

1. Erkennt die Engine die Sprecherzahl automatisch, oder legen Sie sie fest? Automatische Erkennung ist flexibler, kann sich aber verzählen. Wenn Sie die erwartete Sprecherzahl kennen, verbessert deren Angabe in der Regel die Genauigkeit.
2. Dokumentiert sie eine Max-Sprecher-Obergrenze? AWS Transcribe sagt 30. AssemblyAI asynchron sagt 20. Die harte Obergrenze von Google Cloud ist weniger klar dokumentiert. Deepgram veröffentlicht keine. Wissen Sie, womit Sie arbeiten.
3. Bietet sie Wortzeitstempel neben den Sprecher-Labels an? Die Qualität des Abgleichs hängt von der Präzision der Zeitstempel ab. Ohne Wortzeitstempel können die Grenzen der Sprecher-Labels der tatsächlichen Sprecheränderung hinterherhinken oder vorausgehen.
4. Können Sie Labels nachträglich korrigieren? Fehlzuschreibungen sind unvermeidlich. Eine Editor-Oberfläche oder ein strukturierter Export, in dem Sie Cluster umbenennen und zusammenführen können, spart Zeit bei jedem wichtigen Transkript.

Wenn Sie schnelle, genaue Transkription brauchen, ohne einen Meeting-Bot einzurichten, verarbeitet ConvertAudioToText Uploads mit mehreren Sprechern mit nummerierten Sprecher-Labels und strukturierter Ausgabe, die Sie direkt herunterladen oder kopieren können. Zum Testen ist kein Konto erforderlich.

FAQ

Was ist Sprecher-Diarisierung und warum läuft sie getrennt von der Transkription?

Sprecher-Diarisierung ist der Prozess, Audio in Segmente aufzuteilen und jedes Segment einem Sprecher-Cluster zuzuordnen. Sie läuft getrennt von der Transkription, weil die beiden Modelle unterschiedliche Probleme lösen: Das eine dekodiert Sprache in Text, das andere kodiert Stimmidentität in Vektoren und clustert diese. Die meisten Engines führen beide parallel aus und gleichen die Ausgaben über Zeitstempel ab. Die Trennung bedeutet auch, dass Sie Diarisierungs-Backends austauschen können, ohne das Transkriptionsmodell neu zu trainieren.

Wie viele Sprecher können KI-Transkriptions-Engines tatsächlich genau verarbeiten?

Die veröffentlichten Parameter-Obergrenzen sind hoch (AWS Transcribe bis zu 30, AssemblyAI asynchron bis zu 20), aber die Genauigkeit lässt deutlich früher nach, bevor Sie diese Zahlen erreichen. In der Praxis liefern 2 bis 4 Sprecher mit klaren Pausen zwischen den Beiträgen zuverlässige Ergebnisse. Ab 6 oder mehr Sprechern sinkt die Genauigkeit spürbar, besonders bei Aufnahmen mit nur einem Mikrofon. Kurze Beiträge und ähnliche Stimmprofile verschärfen das Problem unabhängig von der Sprecherzahl.

Unterstützt OpenAI Whisper die Sprecher-Diarisierung?

Nein. Whisper erzeugt ein Transkript ohne Sprecher-Labels. Produkte, die auf Whisper eine Diarisierung aufsetzen, integrieren entweder WhisperX (das pyannote an die Whisper-Pipeline anhängt) oder führen ein separates Diarisierungsmodell aus und gleichen die Ausgaben ab. Wenn Ihnen Sprecher-Labels wichtig sind, prüfen Sie, welches Diarisierungsmodell im Hintergrund läuft – nicht nur welches Spracherkennungsmodell.

Wann sollte ich die Diarisierung deaktivieren?

Bei Audio mit nur einem Sprecher, kurzen Clips unter zwei Minuten und Anwendungsfällen wie Untertiteln oder Closed Captions, bei denen die Sprecherstruktur visuell offensichtlich ist. Diarisierung bei Einzelsprecher-Audio erzeugt oft Scheinwechsel der Sprecher, die das Transkript unübersichtlich machen. Die meisten Engines lassen sie explizit deaktivieren, was auch die Verarbeitung beschleunigt.

Quellen

• AWS Transcribe API Reference, Settings.MaxSpeakerLabels: https://docs.aws.amazon.com/transcribe/latest/APIReference/API_Settings.html (geprüft Juli 2026)
• AssemblyAI, Top Speaker Diarization Libraries and APIs 2026: https://www.assemblyai.com/blog/top-speaker-diarization-libraries-and-apis (geprüft Juli 2026)
• Deepgram, Speaker Diarization documentation: https://developers.deepgram.com/docs/diarization (geprüft Juli 2026)
• Google Cloud Speech-to-Text, Detect different speakers: https://docs.cloud.google.com/speech-to-text/docs/multiple-voices (geprüft Juli 2026)
• Picovoice, State of Speaker Diarization 2026 (pyannote vs Falcon benchmark): https://picovoice.ai/blog/state-of-speaker-diarization/ (geprüft Juli 2026)
• pyannote.ai, What is Speaker Diarization: https://www.pyannote.ai/blog/what-is-speaker-diarization (geprüft Juli 2026)