Die geteilte Pipeline: Warum Ihre VAD und Ihr STT verschiedenes Audio wollen

Aktualisiert am 14. August 2026. Als dieser Beitrag zuerst erschien, war die Evidenz für die Teilung die anderer Leute — eine schmale Studie und eine erklärte Herstellerposition. Sie ist jetzt unsere und sie ist gemessen, und die Zahlen unten sind inzwischen über achtzehn akustische Bedingungen statt dreizehn neu generiert worden. Die Absolutwerte haben sich bewegt, die Reihenfolge nicht, und alles hier ist aus der veröffentlichten benchmark.json zitiert.

Ihr Voice Agent hat einen Mikrofonstream und zwei Konsumenten mit entgegengesetzten Anforderungen. Der Turn-Detektor will das sauberstmögliche Signal, damit er nicht einem Fernseher ins Wort fällt. Der Recognizer will das Audio, auf dem er tatsächlich trainiert wurde, Artefakte inklusive. Fast jeder Stack, den wir uns angesehen haben, reicht beiden denselben Puffer — und tunt dann den einen auf Kosten des anderen.

Dieser Beitrag ist das ingenieurtechnische Argument für die Teilung dieses Streams, die Messungen, die es inzwischen stützen, und die Teile, die lästig richtig hinzubekommen sind: Verzögerungsabgleich, Pre-Roll und die Stelle, an die die Teilung in der Pipeline eines Agent-Frameworks gehört.

Die zwei Konsumenten wollen verschiedene Dinge

Turn-Taking will sauber. Sprachaktivitätserkennung (VAD) und Endpointing arbeiten auf Energie- und Spektralhinweisen über kurze Frames. Es sind Schwellenmaschinen. Senken Sie den SNR, und jede Schwelle, die Sie kalibriert haben, verschiebt sich: Die Onset-Erkennung feuert zu spät, weil das Sprach-Rausch-Verhältnis länger braucht, um die Schwelle zu kreuzen; die Offset-Erkennung feuert zu früh oder nie, weil der Rauschteppich nie unter die Hangover-Schwelle fällt. Der Fehlermodus mit dem höchsten Schadenswert in einem Voice Agent ist ein falsch ausgelöstes Barge-in — ein zweiter Sprecher im Raum, ein Fernseher, Café-Babble mit einem verständlichen Fragment darin —, und das ist exakt der Fall, in dem ein Unterdrücker, der den Primärsprecher isoliert, ein unbrauchbares Signal in ein brauchbares verwandelt.

Transkription will roh. Moderne STT-Modelle sind auf sehr großen Mengen echten, verrauschten Audios trainiert. Rauschen liegt innerhalb der Trainingsverteilung. Artefakte neuronaler Unterdrückung — spektrale Löcher, Musical Noise, verschmierte Transienten, ein Rauschteppich, der zwischen Wörtern unnatürlich tot wird — liegen es nicht. Eine unabhängige Studie (arXiv:2512.17562) fand, dass verbessertes Audio in allen 40 getesteten Konfigurationen schlechter abschnitt als rohes, mit dem Vorbehalt, dass sie nur MetricGAN+ verwendete, auf medizinischer Sprache, in semantischer Wortfehlerrate (WER). AssemblyAI, das sie zitiert, berichtete separat, dass Krisps Rauschunterdrückung die WER grob verdoppelte, wenn ihre Ausgabe an STT verfüttert wurde, während falsche VAD-Auslösungen etwa um das 3.5-Fache sanken. Das war die öffentliche Evidenz, und sie war dünn. Sie ist nicht mehr die einzige, die wir haben.

Was unser eigener Lauf über beide Hälften sagt

Wir haben zehn Engines zur Sprachverbesserung (speech enhancement) über achtzehn akustische Bedingungen gegen eine rohe Kontrolle laufen lassen und WER und VAD im selben Durchgang bewertet. Provenienz: ein einzelner Recognizer, faster-whisper base.en (CTranslate2 int8 CPU, greedy), Silero VAD bei Schwelle 0.5, 10 Sprecher / 180 Clips / rund 1406 Sekunden, etwa 190 Referenzwörter pro Bedingung, Apple M1 Max, onnxruntime 1.28.0 festgenagelt auf einen Intra-Op-Thread. Vollständige Methode und Vorbehalte in dem Beitrag zum Benchmark-Launch.

Auf dem Transkriptionszweig verlor die Verbesserung das gepoolte Mittel. Die gepoolte WER lag bei 14.77% für roh gegen 15.56% für die beste Engine (ai-coustics Quail L) und 20.26% für GTCRN. Die Einfügungen — der Recognizer erfindet Wörter, die niemand gesagt hat — gingen von 101 bei roh auf 210 bei GTCRN und 380 bei DeepFilterNet3. Keine der zehn schlug im gepoolten Mittel das Nichtstun.

Pro Bedingung ist es ein anderer Satz, und die geteilte Pipeline hängt davon ab, dass beide wahr sind. In 11 der 18 Bedingungen schlug mindestens eine Engine das rohe Signal, und wo die Siege passieren, sind sie groß: Bei Breitbandrauschen mit 0 dB schlagen acht der zehn Engines roh, die beste um 4.7 Punkte. Verbesserung zahlt sich aus, wo das Audio wirklich schlecht ist, und kostet dort, wo es das nicht ist. Die vollständige Tabelle mit ihren Vorbehalten steht in Hilft Rauschunterdrückung Speech-to-Text wirklich?.

Auf dem Turn-Taking-Zweig kehrt sich das Bild um — aber nicht in der Metrik, die üblicherweise zitiert wird. Die gepoolte VAD-F1 bewegte sich kaum: 0.950 roh gegen 0.947 für den besten verbesserten Stream. Wer Verbesserung an der VAD-F1 misst, folgert: Sie tut nichts.

Die Fehlalarmrate erzählt eine komplett andere Geschichte, und Fehlalarme sind das, was ein Barge-in tatsächlich ist.

Bedingung	VAD-Fehlalarmrate, roh	Verbessert	Engine
Babble bei 5 dB	97.7%	68.2%	FastEnhancer-L
Konkurrierender Sprecher bei 5 dB	58.1%	37.2%	ai-coustics Quail VF

Unter Babble bei 5 dB löst der rohe Stream auf praktisch jedem Nicht-Sprach-Frame falsch aus, den der Detektor sieht — 97.7% ist eine VAD, die als Gate zu funktionieren aufgehört hat. Verbesserung bringt das auf 68.2%. Das ist immer noch schlecht, und es sind dreißig Punkte Verbesserung in der einen Zahl, die direkt darauf abbildet, dass Ihr Agent einen Anrufer unterbricht, der gar nicht gesprochen hat.

Das ist die gemessene Grundlage der Teilung. Verbesserung verdient sich ihren Platz auf dem Turn-Taking-Zweig bedingungslos und auf dem Transkriptionszweig nur in spezifischen Bedingungen — im selben Lauf, auf demselben Audio, mit demselben Recognizer. Das sind nicht zwei Meinungen, die man gegeneinander abwägt. Das sind zwei Zweige, die zwei verschiedene Signale wollen, und einer davon will je nach Raum ein anderes.

Zwei ehrliche Grenzen daran. Dass sich die F1 kaum bewegt, heißt, dass Verbesserung in gewissem Maß Fehlalarme gegen Verpasser tauscht, und 190 Referenzwörter pro Bedingung trennen große Effekte, nicht kleine. Und das sind VAD-Statistiken auf Frame-Ebene, keine gelabelten Turn-Grenzen: „Weniger falsche Barge-ins" als End-to-End-Produktmetrik braucht weiterhin eine vereinbarte Definition eines falschen Barge-ins, und die haben wir noch nicht.

Die Architektur

Single-Stream ist ein Kompromiss, den niemand bewusst gewählt hat:

                     ┌──────────────┐
  mic ──▶ enhance ──▶│  same buffer │──▶ VAD / endpointing   (happy)
                     └──────────────┘──▶ STT                 (five points worse, pooled)

Die geteilte Pipeline ist dieselbe Analyse, zwei Ausgänge:

                 ┌─▶ enhanced ──▶ VAD / endpointing / barge-in
  mic ──▶ enhance┤
                 └─▶ raw (delay-matched) ──▶ ring buffer ──▶ STT
                          ▲
                          └── turn boundaries index into HERE

Ein Inferenzdurchlauf, zwei Abgriffe. Der Enhancer berechnet intern ohnehin eine Sprachpräsenzschätzung; die Zusatzkosten, beide Streams zu emittieren, sind eine Kopie und eine Delay-Line, kein zweites Modell.

Der Teil, den alle falsch machen: Der rohe Stream ist zu früh

Ein Enhancer hat algorithmische Latenz — den Analyse-Frame plus etwaigen Lookahead. Über die Modelle in unserem Manifest sind das 12 bis 30 ms für alles außer DeepFilterNet3, das wir durch einen Block-Online-Adapter mit 100 ms messen. Die verbesserte Ausgabe hinkt dem rohen Eingang also um diesen Betrag hinterher.

Wer beide Streams naiv emittiert, bekommt vom Turn-Detektor Grenzen in der Zeit des verbesserten Streams und wendet sie auf Indizes des rohen Streams an — jede Äußerung, die Sie für STT herausschneiden, ist also um einen Frame verschoben. Bei 30 ms reicht das, um einen wortinitialen Plosiv abzuschneiden, und ein abgeschnittenes /p/ ist eine Substitution oder eine Auslassung in Ihrem Transkript. Der Bug ist tückisch, weil er nicht laut scheitert; er kostet Sie einfach für immer einen Bruchteil eines WER-Punkts.

Der Fix ist eine Delay-Line auf dem rohen Pfad, abgeglichen auf die deklarierte Verzögerung des Enhancers, sodass beide Streams eine Sample-Uhr teilen. Unser SDK deklariert sie als model.audioDelay — 15 ms bei 16 kHz — und macht den Vertrag prüfbar: process() gibt exakt so viele Samples zurück, wie es bekommen hat, und die ersten audioDelay Samples eines Streams kommen als Stille zurück. Die Delay-Line selbst ist Ihr Code, und sie ist ein Ringpuffer, den man einmal schreibt:

import { Model, Processor, UsageReporter } from '@anecho/sdk';

const reporter = new UsageReporter(process.env.ANECHO_API_KEY);
const model = Model.fromFile('anecho_focus_16k_v2.anecho');  // from your dashboard
const proc = new Processor(model, await reporter.ensureLicense());

const rawTap = delayLine(model.audioDelay);  // yours: audioDelay samples deep

// 20 ms of float32 mono at 16 kHz = 320 samples — one model hop
for await (const block of micBlocks) {
  const enhanced = proc.process(block);
  const raw = rawTap.push(block);       // now sample-aligned with `enhanced`

  turnDetector.push(enhanced);          // clean stream drives boundaries
  rawRing.write(raw);                   // raw stream is what STT will read
}

Die Modelldatei ist das kundenspezifische .anecho, das Sie vom Dashboard herunterladen — ein Modell, 16 kHz, 4.0 MB. Die Sprachentscheidung, die den Turn-Detektor treibt, kann aus der Vad des SDK kommen, die dieselbe Modelldatei liest — die Teilung kostet Sie also weder ein zweites Modell noch einen zweiten Download.

Pre-Roll, oder warum Ihr erstes Wort verschwindet

Eine VAD erklärt Sprache, nachdem sie Sprache gesehen hat. Jeder Detektor hat eine Onset-Verzögerung — die Frames, die er brauchte, um sicher zu sein. Wer den STT-Puffer in dem Moment zu füllen beginnt, in dem die VAD feuert, hat den Attack des ersten Wortes bereits weggeworfen.

Deshalb zählt der Ringpuffer mehr als die Teilung selbst. Sie wollen einen kontinuierlich beschriebenen rohen Ringpuffer mit ein paar hundert Millisekunden Historie, und Turn-Grenzen, die hinein indizieren:

turnDetector.on('turn', async (turn) => {
  // turn.startSample / turn.endSample index the shared sample clock,
  // so they are valid indices into the raw ring too
  const utterance = rawRing.slice(
    turn.startSample - PREROLL_SAMPLES,
    turn.endSample + HANGOVER_SAMPLES,
  );
  await stt.transcribe(utterance);
});

Zwei Defaults, die es verdienen, explizit genannt zu werden, weil sie die sind, an denen zuerst gedreht wird:

• Pre-Roll 300 ms. Billige Versicherung. Bei 16 kHz mono float32 sind das 19.2 KB Speicher pro Stream.
• Hangover über das Offset hinaus. Auslautende Frikative und nicht gelöste finale Verschlusslaute sind energiearm und werden von einem eifrigen Endpointer abgeschnitten. Wenn Ihre Transkripte systematisch das Plural-/s/ verlieren, ist das der Grund.

In Python ist die Gestalt dieselbe:

import os
from anecho import Model, Processor, UsageReporter

reporter = UsageReporter(os.environ["ANECHO_API_KEY"])
model = Model.from_file("anecho_focus_16k_v2.anecho")
proc = Processor(model, reporter.ensure_license())

raw_tap = DelayLine(model.audio_delay())   # yours, as above

for block in mic_blocks(320):          # 20 ms at 16 kHz — one model hop
    enhanced = proc.process(block)
    turn_detector.push(enhanced)
    raw_ring.write(raw_tap.push(block))

Wo die Teilung in einem echten Stack lebt

In einem Agent-Framework muss die Teilung vor dem frameworkeigenen Routing passieren, denn das Framework nimmt eine einzige Audiospur an. Dieser Punkt — der Audio-Callback, der Frame-Prozessor, der Media-Hook, wie auch immer Ihr Framework ihn nennt — ist die Stelle, an die die Schleife oben gehört. Wir liefern sie als Funktion von Block zu Block statt als Plugin pro Framework, genau damit sie in jede dieser Nahtstellen passt: Der Prozessor hat keine Meinung dazu, was stromabwärts liegt, und das Routing bleibt Ihr Code — und damit messbar.

Die Routing-Matrix, schlicht formuliert — jede Zeile ist eine Verdrahtung der zwei Abgriffe, und zwischen ihnen umzuschalten ist eine Zeile in Ihrer Schleife:

Verdrahtung	Turn-Taking erhält	STT erhält	Wann einsetzen
vad-only	verbessert	roh, verzögerungsabgeglichen	Default; laute Umgebungen, Barge-in-Probleme
both	verbessert	verbessert	Traffic mit konkurrierenden Sprechern, wo unsere Daten sagen, dass auch STT gewinnt
stt-only	roh	verbessert	selten; nur wenn Ihre VAD bereits rauschrobust ist und Ihr STT nicht
disabled	roh	roh	Kontrolle, und das, wogegen Sie messen sollten

Wir empfehlen vad-only als Default, weil unsere eigenen Messungen dorthin zeigen — auf unserem Korpus, mit einem Recognizer. Nicht, weil wir es für Ihren Traffic bewiesen hätten.

Die both-Zeile ist nicht hypothetisch, und selten ist sie auch nicht. Verbesserung schlug roh bei der Transkription in 11 unserer 18 Bedingungen — am klarsten dort, wo eine konkurrierende Stimme oder Breitbandrauschen bei niedrigem SNR phonetische Hinweise tatsächlich zerstört. Das größte Einzelergebnis ist ai-coustics Quail VF bei konkurrierendem Sprecher mit 5 dB: Einfügungen von 19 auf 10 gesenkt, WER von 26.3% auf 20.5%. Wenn Ihre Anrufer in Räumen sitzen, in denen ein anderer Mensch redet, ist both-enhanced auf Basis der Evidenz vertretbar. Gepoolt über alle achtzehn Bedingungen ist dasselbe Modell mehr als drei Punkte schlechter als roh, weil es auch auf sauberem, halligem und carrier-degradiertem Audio läuft, wo es nur Information entfernen kann — weshalb es nicht der Default ist, und weshalb das eine Messung pro Deployment ist statt einer Einstellung, die wir für Sie wählen können.

Kosten, und was die Teilung nicht kostet

Der Einwand, den wir hören, ist, dass sich damit das bewegte Audio verdoppelt. Tut es nicht, wenn Sie den rohen Pfad lokal halten. Die Verbesserung läuft dort, wo das Audio ohnehin ist — im Browser-Worklet, in Ihrem Medienserver oder in Ihrem Node-Prozess —, und nur der Stream, den ein gegebener Konsument braucht, überquert eine Netzwerkgrenze. Der verbesserte Stream füttert eine VAD, die üblicherweise in-process ist. Der rohe Stream geht an Ihren STT-Anbieter, wohin er ohnehin gegangen wäre.

Was es kostet:

• Speicher. Ein Ringpuffer pro Session. Rund 19 KB pro 300 ms bei 16 kHz mono float32; sagen wir 64 KB pro Session mit Reserve.
• Eine Delay-Line. Ein Frame Enhancer-Latenz, dem rohen Pfad hinzugefügt, damit die Uhren übereinstimmen. Das erhöht die End-to-End-Antwortlatenz nicht, denn der rohe Pfad war voraus, nicht hinterher — Sie richten sich am langsameren Stream aus, den Sie ohnehin schon hatten.
• Eine Sache mehr, über die man nachdenken muss. Zwei Streams heißt zwei Orte, an denen sich ein Bug verstecken kann. Die Milderung ist, dass beide aus einem process()-Aufruf mit einer Sample-Uhr abgeleitet sind, statt aus zwei unabhängigen Pipelines, die driften können.

Was weiterhin unbekannt ist

• Manche Recognizer sind womöglich auf verbessertem Audio trainiert. Wenn ein Anbieter in seinem eigenen Ingest vorverarbeitet, ist es aus einem anderen Grund richtig, ihm rohes zu füttern — oder aus einem subtilen falsch. Diese Trainingssets kann niemand von uns einsehen.
• Der SNR-Umschlagpunkt. Verbesserung gewinnt klar bei niedrigem SNR und verliert klar auf sauberem Audio, aber wo sie kippt, können wir noch nicht beziffern. Die Dichte der Gewinner hat ihr Maximum bei 0 dB — acht von zehn Engines — und dünnt in beide Richtungen aus, wobei eine Engine selbst auf der clean-Bedingung noch roh schlägt. Das ist eine Steigung, keine Schwelle, und sie wird je Engine anders liegen. Sie sauber zu lokalisieren ist das, was bedingte Verbesserung lieferbar machen würde.
• Die Turn-Taking-Gewinne sind auf Frame-Ebene, nicht auf Turn-Ebene. Wir berichten VAD-F1 und Fehlalarmrate. „Weniger falsche Barge-ins" braucht gelabelte Turn-Grenzen und eine vereinbarte Metrik. Das ist das Nächste, was wir dem Benchmark schulden.
• Telefonie ist ein eigener Fall. Auf einem Schmalbandpfad mit 8 kHz ist der Recognizer außerhalb seiner Trainingsverteilung, bevor Sie irgendetwas anfassen; kein Enhancer in unserer Matrix produzierte dort eine nennenswerte Verbesserung, mehrere verschlechterten erheblich, und die Argumentation ändert sich — siehe 8 kHz ist die Stelle, an der Voice AI wirklich bricht. Wir haben inzwischen ein separates Experiment mit 8 kHz von Ende zu Ende gefahren, mit drei wirklich nativen Schmalbandmodellen darin: Nativ schlägt Resampeln-und-Hoffen beim selben Anbieter um 0.7 Punkte, und gar nichts schlägt das unangetastete Anrufer-Audio.

Der Grund, das Routing in der eigenen Schleife zu halten statt in einem Framework-Default zu vergraben, ist, dass die Frage damit pro Deployment testbar wird. Schalten Sie den STT-Abgriff zwischen roh, verbessert und deaktiviert um, fahren Sie Ihr eigenes Audio durch den Harness, und lesen Sie die ΔWER gegen die Passthrough-Kontrolle. Gewinnt verbessert auf Ihrem Traffic, liefern Sie verbessert aus — dem SDK ist egal, welche Antwort Sie bekommen, und uns auch, solange die Messung echt ist.

Quickstart und SDK-Referenz unter /docs. Der Harness, der die ΔWER-Zahlen produziert, liegt unter github.com/anecho, und die veröffentlichte Matrix unter /benchmark.