
Ich habe eine englische Interview-Transkription mit KI getestet – Ergebnisse vom 26. Februar 2026 (Whisper BASE, ca. 11 Minuten Audio)
2026-02-26Test
Eric King
Author
1. Warum dieses Interview‑Benchmark relevant ist
Bei echten Interviews ist Transkriptionsgenauigkeit keine Option, sondern eine Voraussetzung. Sie entscheidet darüber, ob Zitate belastbar sind, ob sich wichtige Themen zuverlässig finden lassen und ob nachgelagerte Analysen den Inhalt korrekt wiedergeben. Ein verlorenes Adjektiv, eine falsch verstandene Zahl oder ein verunstalteter Eigenname können die Bedeutung einer Antwort ändern.
In diesem Benchmark habe ich einen englischen „Bill‑Interview“‑Ausschnitt durch eine Whisper‑basierte Transkriptionspipeline geschickt und mit Standard‑ASR‑Metriken ausgewertet. Das Ziel ist keine Werbung, sondern eine konkrete, reproduzierbare Momentaufnahme, wie sich das System auf einem realen, mittellangen Interview verhält.
Das Ausgangsinterview stammt aus einem YouTube‑Video, das hier als Kontext referenziert werden kann:
Originales Interviewvideo auf YouTube.
Originales Interviewvideo auf YouTube.
Source Materials
Alle Eingaben für dieses Benchmark liegen im Repository bzw. als statische Ressourcen und können direkt inspiziert werden:
- Originalaudio: Audio source
- Referenztranskript (VTT): Base text
- Modell‑Transkript (VTT): Result text
Diese Dateien sind die einzigen Quellen für alle Kennzahlen und Schlussfolgerungen in diesem Beitrag.
Screenshots from this run


2. Testaufbau (Testing Setup)
Für diesen Lauf wurden die folgenden Einstellungen verwendet (alle Werte stammen aus den vorberechneten Metadaten und aus
result.json):- Datum des Laufs: 2026‑02‑26 (aus Verarbeitungstimestamps abgeleitet)
- Szenario: englisches Interview (
test-transcripts/bill-interview) - Sprache: Englisch
- Audiodauer:
audioDurationSeconds = 653.2934375- ≈ 10,89 Minuten Material
- Verarbeitungszeit:
sttProcessingTimeSeconds = 85.476- ≈ 1,42 Minuten End‑to‑End‑Decoding
- Modell / Modus:
whisper-model: BASEsaytowords-mode: base
Aufnahmebedingungen, Mikrofontyp und Sprechdichte sind in den Metadaten nicht dokumentiert und werden daher nicht spekulativ ergänzt. Alignment und Scoring wurden vor der Berichtserstellung durchgeführt; die folgenden Zahlen werden direkt aus
test-transcripts/bill-interview/result.json gelesen.3. Evaluierungsmethodik (Evaluation Methodology)
Sowohl das menschliche Referenztranskript (
ref.vtt) als auch die Modellausgabe (model.vtt) liegen im WebVTT‑Format vor. Die Auswertekette extrahiert zunächst Klartext aus den Dateien, richtet Referenz und Hypothese gegeneinander aus und berechnet anschließend Fehlerkennzahlen.Word Error Rate (WER)
Nach der Tokenisierung in Wortsequenzen zählen wir:
- (S): Substitutionen
- (D): Deletionen
- (I): Insertionen
- (N): Anzahl der Referenzwörter
Die Wortfehlerrate ist definiert als:
[
\text{WER} = \frac{S + D + I}{N}
]
Die Wortgenauigkeit ergibt sich daraus als:
[
\text{Accuracy} = 1 - \text{WER}
]
Character Error Rate (CER)
Auf Zeichenebene werden Leerzeichen entfernt und eine Levenshtein‑Edit‑Distanz berechnet:
- Edit‑Distanz auf Zeichenebene: Summe aus Insertionen, Deletionen und Substitutionen
- Gesamtzahl der Zeichen: Anzahl Referenzzeichen (ohne Leerzeichen)
[
\text{CER} = \frac{\text{Character edit distance}}{\text{Total characters}}
]
Real‑Time Factor (RTF)
Der Durchsatz wird mit dem Real‑Time Factor gemessen:
[
\text{RTF} = \frac{\text{Processing Time}}{\text{Audio Duration}}
]
Die Verarbeitungszeit stammt aus der Differenz von
processtime-at und completed-at in other.yaml; die Audiodauer aus audio-duration in derselben Datei.Implementierungsdetails
- Alle Kennzahlen basieren auf einer Alignment‑Prozedur zwischen Referenz und Hypothese.
- Wort‑ und Zeicheneditdistanzen werden mit einer leistungsfähigen Levenshtein‑Implementierung berechnet.
- Die Alignments laufen auf einem C++‑optimierten Backend.
- Die Zeitkomplexität liegt bei Sequenzlängen (n) und (m) ungefähr bei O(nm).
- Alle Werte in
result.jsonsind deterministisch und reproduzierbar: gleiche Eingaben erzeugen dieselben Ergebnisse.
4. Modellüberblick (Model Overview)
In diesem Benchmark wurde genau eine Modellkonfiguration evaluiert:
- Whisper BASE (saytowords-mode: base)
Ein allgemein einsetzbares Speech‑to‑Text‑Modell mit mittlerer Kapazität, ausgelegt auf englische Mehrakzent‑Szenarien und längere Audiosequenzen. In diesem Benchmark wird es unverändert (ohne Fine‑Tuning, ohne manuelle Korrektur) verwendet, um das Rohverhalten in einem realen Interview zu beobachten.
Künftige Vergleiche könnten kleinere oder größere Whisper‑Varianten sowie Nicht‑Whisper‑Systeme ergänzen; dieser Beitrag konzentriert sich jedoch bewusst auf diese einzelne Baseline.
5. Ergebnisse (aus result.json)
Die folgenden Werte stammen direkt aus
test-transcripts/bill-interview/result.json:- Audiodauer (s):
653.2934375 - Verarbeitungszeit (s):
85.476 - Referenzwörter (N):
1846 - Substitutionen (S):
67 - Deletionen (D):
178 - Insertionen (I):
23 - WER:
0.14517876489707476 - Accuracy:
0.8548212351029252 - Referenzzeichen:
7335 - Zeichen‑Edit‑Distanz:
825 - CER:
0.11247443762781185 - RTF:
0.13083860191079907
Zur besseren Lesbarkeit:
- WER ≈ 14,52 %
- Accuracy ≈ 85,48 %
- CER ≈ 11,25 %
- RTF ≈ 0,13, also etwa 7,6‑mal schneller als Echtzeit.
6. Fehlerbildanalyse (Error Pattern Analysis)
Es liegen keine segmentweisen Markierungen oder Visualisierungen vor; die Analyse basiert daher vollständig auf den aggregierten Zählwerten.
-
Dominanter Fehlertyp: Deletionen
- Deletionen:
D = 178 - Substitutionen:
S = 67 - Insertionen:
I = 23
Deletionen machen den Großteil der Wortfehler aus. Das deutet darauf hin, dass das Modell eher Wörter auslässt, als Inhalte zu halluzinieren. Im Interviewkontext äußert sich das häufig als verlorene Funktionswörter, verschluckte Satzenden bei schneller Sprache oder ausgeblendete Teile bei Überschneidungen mehrerer Sprecher.
- Deletionen:
-
Substitutionen sind vorhanden, aber zweitrangig
MitS = 67machen Substitutionen grob ein Viertel aller Fehler aus. Typischerweise geht es um lexikalische Verwechslungen: ähnlich klingende Wörter, falsch erkannte Namen oder Domänenbegriffe, die das Modell seltener gesehen hat. -
Insertionen sind relativ selten
NurI = 23Insertionen wurden beobachtet. Das passt zu einem Modell, das eher konservativ in Bezug auf Halluzinationen ist: Es irrt sich häufiger durch Weglassen als durch Hinzufügen.
Auf Zeichenebene:
- Zeichen‑Edit‑Distanz = 825 bei 7335 Zeichen, entsprechend CER ≈ 11,25 %.
Im Vergleich zur WER von ~14,5 % zeigt die niedrigere CER, dass viele falsche Wörter auf Zeichenebene noch recht nah an der Referenz liegen – etwa durch kleine Flexions‑ oder Rechtschreibunterschiede oder zerlegte/vereinigt geschriebene Komposita – statt völlig unrelated zu sein.
Ohne zeitstempelgenaue Fehlermarkierung lassen sich keine „Problemstellen bei Minute X“ benennen. Das S/D/I‑Profil zeigt aber bereits deutlich: Dieses System neigt eher zum Unter‑Transkribieren als zum Erfinden zusätzlicher Passagen.
7. Zentrale Erkenntnisse (Key Insights)
Rein aus den Zahlen lassen sich einige Kernaussagen ableiten:
-
Guter Kompromiss zwischen Geschwindigkeit und Genauigkeit für Interviews
Mit RTF ≈ 0,13 verarbeitet das System rund 10,9 Minuten Audio in etwa 1,4 Minuten, bei WER ≈ 14,5 % und CER ≈ 11,3 %. Für die Stapelverarbeitung vieler Interviews ist das ein praxistauglicher Punkt. -
Fehler sind klar deletions‑lastig
Deletionen (178) dominieren gegenüber Substitutionen (67) und Insertionen (23). Praktisch bedeutet das: Eher gehen kleine Content‑Stücke verloren, als dass das Modell ganze Sätze hinzufantasiert. -
Zeichenebene stabiler als Wortebene
Die niedrigere CER im Vergleich zur WER zeigt, dass viele falsche Wörter auf Zeichenebene dennoch nahe an der Referenz liegen. Für Aufgaben wie Suche oder Themenclustering, die leichte lexikalische Abweichungen tolerieren, ist das positiv. -
Nicht‑triviale Datenmenge
Mit 1846 Referenzwörtern und 7335 Zeichen nähert sich das Szenario einem echten Interview an und ist weit entfernt von einem Spielzeugbeispiel. Die Metriken beschreiben das Verhalten über mehrere Minuten spontaner Sprache.
8. Bestes Modell für dieses Szenario (Best Model for This Scenario)
In diesem Benchmark wurde ausschließlich Whisper BASE (base mode) getestet – es ist damit zugleich:
- das stärkste Modell auf dieser „Liste“, und
- der einzige Referenzpunkt.
Unter diesem Vorzeichen liefert es:
- WER ≈ 14,5 %, Accuracy ≈ 85,5 % auf ~11 Minuten Interviewaudio.
- RTF ≈ 0,13, also 7–8‑mal schneller als Echtzeit.
Für Workflows, in denen schnelle, hinreichend genaue Interviewtranskripte benötigt werden – etwa zum Browsen, Suchen oder groben Zitieren –, ist diese Konfiguration numerisch ausreichend. Für Anwendungsfälle, in denen jedes Wort sitzen muss, machen die Metriken aber auch klar, dass manuelle Prüfung oder ein stärkeres Modell weiterhin nötig sind.
9. Neutrales Fazit (Neutral Final Verdict)
Auf diesem spezifischen englischen Interview vom 26. Februar 2026 zeigt Whisper BASE im „base“‑Modus:
- ein deletions‑dominiertes Fehlerprofil mit wenigen Insertionen,
- eine WER im mittleren Zehnerbereich und eine CER im niedrigen Zehnerbereich auf Basis eines nicht‑trivialen Referenztranskripts,
- einen Real‑Time Factor von rund 0,13, passend für großskalige Batch‑Verarbeitung.
Das Verhalten ist numerisch konsistent, reproduzierbar und schnell genug für tägliche Benchmarks. Für unabhängige Evaluatoren lautet das Fazit: Diese Konfiguration ist eine solide Basislinie für Interviewtranskription, ersetzt menschliche Kontrolle in hochsensiblen Domänen aber noch nicht.
Referenzartefakte (Reference Artifacts)
Unten sind einklappbare Platzhalter für Referenz‑ und Modelltranskript vorgesehen. Hier können bei Bedarf die vollständigen VTT‑Inhalte eingebettet werden.
ref.vtt (Referenztranskript)
<!-- Hier die vollständigen Inhalte von test-transcripts/bill-interview/ref.vtt einfügen -->
model.vtt (Modelltranskript)
<!-- Hier die vollständigen Inhalte von test-transcripts/bill-interview/model.vtt einfügen -->