Klinisches ASR-Flywheel – Stufe 3 (Bewertung)

⚠ Agent: Lies den Abschnitt „Kritische Workflow-Regeln“ weiter unten, bevor du antwortest. Diese SKILL.md-Datei ist in sich geschlossen – evals/, references/ und assets/ sind Verweise und nicht funktionsrelevant. Beantworte methodische Fragen direkt anhand dieser Datei; rufe Tools nur auf, wenn der Benutzer ausdrücklich darum bittet, die Ausführung anhand eines echten Manifests durchzuführen.

Sie sind die „Score-and-Route“- Stufe. Der Benutzer reicht eine manifest.jsonl im NeMo-Format ein (entweder aus /digital-health-clinical-asr-build oder von einer anderen Quelle). Sie transkribieren es über das ausgewählte ASR-NIM, bewerten vier Metriken, erstellen eine Rangliste mit fünf Abschnitten und lesen den Entscheidungsbaum aus, um zu entscheiden, ob der Nutzer zu /digital-health-clinical-asr-finetune weiterleiten, zu /digital-health-clinical-asr-build zurückkehren oder die Auswertung beenden und stabilisieren soll.

Diese Skill erzeugt keine Audiodaten. Falls die Manifestdatei fehlt oder leer ist, leiten Sie den Nutzer zurück zu /digital-health-clinical-asr-build.

Audiodaten verlassen Ihre Umgebung – weisen Sie den Nutzer darauf hin, bevor ein Clip gesendet wird

In dieser Phase werden die WAV-Datei jeder Manifestzeile sowie der zugehörige Referenztext an einen externen NVIDIA-Dienst übertragen. Weisen Sie den Nutzer vor dem Aufruf des ersten ASR-Aufrufs darauf hin:

Die Clips sollten synthetische Audiodaten sein, die in Stufe 2 generiert wurden (Magpie TTS auf Basis einer vom Benutzer kuratierten Begriffsliste) – keine echten Patientenaufnahmen. Übermitteln Sie keine echten ASR-Aufnahmen, keine echten Patientengespräche und keine personenbezogenen Gesundheitsdaten (PHI) über diesen Skill. Die Bewertung erfolgt anschließend lokal (WER/CER/KER/SER in reinem Python oder jiwer, falls installiert). Der Bewertungsschritt selbst überträgt keine Daten; dies geschieht ausschließlich im ASR-Schritt.

Wichtige Workflow-Regeln (gelten bei jeder Aktivierung)

Bei methodischen Fragen (Ranglistenstruktur, KER-Definition, Entscheidungsbaum) antworten Sie anhand dieser Datei. Rufen Sie keine Tools auf, rufen Sie keine anderen Skills an und führen Sie keine Skripte aus, es sei denn, der Nutzer fordert ausdrücklich die Ausführung anhand eines echten Manifests an. Geben Sie diese Fakten in jeder Antwort an:

1. Zuerst die „Off-Ramp“. Wenn der Nutzer nach etwas fragt, das nicht zur Bewertung gehört, leiten Sie die Anfrage weiter und brechen Sie den Workflow ab, ohne ihn auszuführen:
   • Auswahl / Vergleich / alternative NIMs aus dem ASR-Modellkatalog → /riva-asr
   • ASR-Authentifizierung (API-Schlüssel, Bearer-Token, Funktions-IDs) → /riva-asr
   • ASR-gRPC-Protokoll, Streaming, Batching, Chunking, Wiederholungsversuche → /riva-asr
   • NIM-Bereitstellung / riva-build / riva-deploy → /riva-asr-custom
   • NGC / Docker / NVIDIA Container Toolkit → /riva-nim-setup
   • Noch kein Manifest → /digital-health-clinical-asr-build
   • Möchte jetzt mit einem bekannten KER feinabstimmen → /digital-health-clinical-asr-finetune
2. Das Standard-ASR-NIM ist nvidia/parakeet-tdt-0.6b-v2 (NVCF-Funktions-ID d3fe9151-442b-4204-a70d-5fcc597fd610, Offline-gRPC). Überschreibungen über Umgebungsvariablen: ASR_MODEL_NAME (Anzeigename im Leaderboard), ASR_NVCF_FUNCTION_ID (Wechsel zu einem anderen gehosteten NIM – z. B. Whisper Large v3 b702f636-…, wenn das Parakeet-Backend ausfällt, oder ein feinabgestimmtes NIM), ASR_ENDPOINT (selbst gehostetes gRPC; hat Vorrang). Das ausgewählte NIM und die aufgelöste Funktions-ID werden zurückgemeldet, bevor API-Guthaben verbraucht werden.
3. Die ASR-Transkription erfolgt inline in Schritt 3b (NVCF gRPC + riva.client.ASRService.offline_recognize, dasselbe Authentifizierungsmuster wie in Stufe 1). Bei tiefergehenden Fragen zu Protokoll/Authentifizierung, alternativen NIM-Katalogen oder der Konfiguration eines selbst gehosteten Riva-NIM siehe /riva-asr.
4. KER ist die wichtigste Kennzahl. Zeilenweise Prüfung: Die markierten Begriffswörter müssen in der normalisierten Hypothese der Reihe nach, zusammenhängend und nebeneinander erscheinen. „cefazolin“ → „cefa zolin“ ist ein Fehler. Die aggregierte WER verschleiert klinisch gefährliche Fehler; beide werden gemeldet, KER ist das entscheidende Kriterium.
5. Die Aufschlüsselungnach „ipa_source“ ist die aussagekräftigste Einzelzahl in der Rangliste. Die Differenz zwischen „merriam-webster“ und „magpie_g2p“ beweist, dass die SSML-Override-Pipeline tatsächlich funktioniert. Lesen Sie dies dem Nutzer laut vor.
6. Routing für Sonderfälle. „merriam-webster “-Zeilen gut, „magpie_g2p “-Zeilen schlecht → Lücke in der Ausspracheabdeckung, keine Modelllücke. Zurückleiten zu /digital-health-clinical-asr-build Schritt 2d. /digital-health-clinical-asr-finetune NICHT als erste Antwort empfehlen.
7. Reihenfolge der fünf Abschnitte in der Rangliste. Überschrift (WER/CER/KER/SER) → KER nach „entity_category“ → KER nach „ipa_source“ → KER nach „noise_level“ → KER pro Term, vom schlechtesten zum besten. Der Abschnitt„by-ipa_source“ ist obligatorisch; er ist der Beweis dafür, dass die SSML-Pipeline funktioniert.

Zweck

Ein klinisches ASR-Manifest bewerten, eine KER-Rangliste mit fünf Abschnitten erstellen und den Benutzer über den Entscheidungsbaum nach der Auswertung weiterleiten. Details zur Methodik (Definitionen der Metriken, Normalisierung, Reihenfolge der Rangliste, Weiterleitung in Sonderfällen) finden Sie oben unter „Wichtige Workflow-Regeln“ und unten unter „Anweisungen“.

Wann diese Funktion verwendet werden sollte

Aktivieren Sie die Funktion bei Benutzerphrasen wie:

• „Bewerte mein ASR-Manifest“
• „Wie lautet der KER-Wert für Parakeet TDT v2?“
• „Führe die Bewertung für Zyklus N durch“
• „Vergleiche zwei ASR-Modelle anhand des klinischen Benchmarks“
• „Erstelle die Rangliste“
• „Ich habe eine manifest.jsonl-Datei – wie berechne ich die Punktzahl?“
• „Warum beträgt der KER 0,4, wenn der WER 0,07 beträgt?“
• „Sollten wir eine Feinabstimmung vornehmen?“ (Dies ist die Frage auf der Evaluierungsseite – der Entscheidungsbaum nach der Evaluierung befindet sich in diesem Skill)

Prüfung auf Nicht-Aktivierung durch bestimmte Schlüsselwörter – wenn die Nachricht des Nutzers Begriffe wie „authenticate“, „API key“, „bearer“, „function ID“, „gRPC“, „streaming“, „chunking“, „batching“, „transcription retry“, „riva-build“, „riva-deploy“, „NIM deploy“, „NGC“, Docker oder Container Toolkit enthält oder nach „Welches ASR-Modell ist am besten?“, „Modelle vergleichen“ oder „Anbieterunterschiede“ fragt – den Bewertungs-Workflow NICHT aktivieren. Wende die oben genannte kritische Workflow-Regel Nr. 1 an, um zur richtigen gleichrangigen Skill weiterzuleiten und den Prozess zu beenden. Dies gilt auch dann, wenn der Nutzer neben dem Schlüsselwort „KER“ oder „eval“ erwähnt.

Voraussetzungen

• Ein Manifest im NeMo-Format mit den klinischen Erweiterungsfeldern (term, entity_category, ipa_source, voice_id, noise_level, context_type). Das Schema ist in der Datei „references/manifest-schema.md“ des Build-Skills dokumentiert.
• NVIDIA_API_KEY exportiert (Voraussetzung aus Stufe 1 gilt weiterhin).
• „nvidia-riva-client“ + „soundfile“ installiert (Voraussetzung für Stufe 1). Details zum selbst gehosteten Riva NIM finden Sie unter /riva-asr Option B.
• Audiodateien müssen tatsächlich auf der Festplatte vorhanden sein – führen Sie den Pre-Flight „audio-existence“ aus der Referenz „manifest-schema“ durch, bevor Sie API-Guthaben verbrauchen.

Anleitung

3a. Wählen Sie das ASR-NIM aus

Standard: nvidia/parakeet-tdt-0.6b-v2 über NVCF gRPC (offline), Function-ID d3fe9151-442b-4204-a70d-5fcc597fd610. Die aktuelle Empfehlung von NVIDIA für englisches ASR – das schnellste und kostengünstigste Modell im Katalog, das im standardmäßigen SFT-Rezept von NeMo unterstützt wird, sodass die Stage-3-Baseline und die Stage-4-Feinabstimmung auf derselben Modellfamilie basieren.

Drei Regler zum Überschreiben von Laufzeit-Umgebungsvariablen (ASR_MODEL_NAME für die Leaderboard-Anzeige, ASR_NVCF_FUNCTION_ID zum Wechsel zu einem anderen gehosteten NIM, ASR_ENDPOINT für selbst gehostetes gRPC) sowie den vollständigen Katalog alternativer NIMs (Parakeet TDT 1.1B, Parakeet CTC 1.1B, Whisper Large v3, Nemotron Streaming) mit Funktions-IDs und Hinweisen zur Aufrufstruktur: references/offline-asr-recipe.md.

Geben Sie dem Benutzer das ausgewählte NIM, die aufgelöste Funktions-ID und etwaige Überschreibungen von Umgebungsvariablen zurück, bevor API-Guthaben verbraucht werden. Ein Manifest mit 200 Zeilen auf einem gehosteten Parakeet TDT v2 ist kostengünstig; eine versehentliche Ausführung mit dem falschen Modell bei einem Manifest mit 1.000 Zeilen hingegen nicht.

3b. Transkribieren

Transkribieren Sie für jede Zeile in „manifest.jsonl“ den „audio_filepath“ und erstellen Sie „per_sample.json“ (ein JSON-Objekt pro Zeile, JSONL oder ein JSON-Array – nach Wahl des Aufrufers):

{
  "audio_filepath": "...",
  "ref": "",
  "hyp": "",
  "term": "",
  "entity_category": "",
  "ipa_source": "",
  "voice_id": "",
  "noise_level": "",
  "context_type": ""
}

Rezept (vollständiger Python-Code in references/offline-asr-recipe.md): transcribe_manifest(api_key, manifest_path, out_path, language_code="en-US") öffnet einen Offline-gRPC-Stream zu NVCF (oder zu ASR_ENDPOINT, falls für selbst gehostetes Riva festgelegt), ruft riva.client.ASRService.offline_recognize pro Zeile auf – Sätze in einem klinischen Manifest sind ≤ 30 s lang, sodass kein Streaming/Batching erforderlich ist – und schreibt das oben genannte JSONL. Gleiche „auth_for“-Form wie beim Smoke-Test für die Einrichtung von Stufe 1. Der Agent-Harness übergibt den `api_key` explizit; das Rezept liest die drei Überschreibungen der Umgebungsvariablen (ASR_NVCF_FUNCTION_ID, ASR_MODEL_NAME, ASR_ENDPOINT) ganz oben ein, damit Prüfer die Einstellmöglichkeiten an einer Stelle sehen können.

Fallback auf „Whisper“ (wenn das NVCF-Backend von Parakeet aufgrund eines unzulässigen CUDA-Speicherzugriffs von Triton ausfällt) und selbst gehostetes Riva NIM (ASR_ENDPOINT=localhost:50051) – Muster für Umgebungsvariablen: siehe references/offline-asr-recipe.md (§Whisper-Fallback, §Selbst gehostetes Riva NIM).

Einstellmöglichkeiten zur Ausfallsicherheit werden dem Benutzer überlassen. Wenn NVCF mitten im Batch den Fehler RESOURCE_EXHAUSTED zurückgibt, bricht die Schleife an dieser Zeile ab; die Ausführung wird ab der fehlerhaften Zeile fortgesetzt. Streaming, Batching und Wiederholungsversuche mit Backoff liegen außerhalb des Geltungsbereichs – siehe /riva-asr.

3c. Vier Metriken berechnen

Berechnen Sie für jede Zeile:

Normalisierung (gilt für „ref“ und „hyp“ vor allen vier Metriken):

1. Kleinbuchstaben.
2. NFKD-Normalisierung (Anführungszeichen → ASCII usw.).
3. Zeichensetzung bis auf Bindestriche entfernen.
4. Weißraumsequenzen auf ein einzelnes Leerzeichen reduzieren.

Inline-Bewertungsrezepte – normalize / edit_distance / wer / cer / ker / ser (reines Python, keine jiwer-Ab hängigkeit): siehe references/scoring-recipes.md. Aggregation über die Zeilen hinweg durch Berechnung des Mittelwerts (der zeilenweisen Bewertung) für jede Metrik.

Strenges KER – Suchbegriffe müssen in der normalisierten Hypothese in der richtigen Reihenfolge und nebeneinander erscheinen. Dies ist konservativ: „cefazolin“ → „cefa zolin“ gilt als Fehler. Klinisch gesehen ist das richtig – eine nachgelagerte Apothekenabfrage würde aufgrund des falsch geschriebenen Tokens fehlschlagen.

KER bestraft keine umgebenden Fehler. Eine Zeile, in der der Begriff korrekt ist und der Rest des Satzes Unsinn ist, erhält dennoch einen KER-Wert von 0; der WER dieser Zeile wird das übergeordnete Problem separat aufzeigen.

3d. Aufschlüsselungen + Rangliste

Erstellen Sie eine Markdown-Rangliste mit fünf Abschnitten in folgender Reihenfolge:

1. Überschrift – Gesamtwerte für WER, CER, KER und SER für das ausgewählte Modell.
2. KER nach „entity_category“ – Medikament vs. Verfahren vs. Anatomie vs. … Das ist es, was den Nutzer bei der Implementierung tatsächlich interessiert.
3. KER nach „ipa_source“ – die aussagekräftigste Einzelzahl in der Rangliste. Die Differenz zwischen den Zeilen „merriam-webster“ und „magpie_g2p“ ist der Beweis dafür, dass die SSML-Override-Pipeline tatsächlich funktioniert. Lesen Sie diesen Abschnitt dem Nutzer laut vor.
4. KER nach „noise_level“ – klinische Umgebungen sind laut. „snr_5db“- Zeilen entsprechen eher der Realität als „clean“-Zeilen.
5. KER pro Term (vom schlechtesten zum besten) — das sind Ihre Feinabstimmungsziele für Stufe 4.

Eine repräsentative „ipa_source “-Aufteilung mit der Interpretation der Differenz zwischen „merriam-webster“ und „magpie_g2p“: references/scoring-recipes.md §Representative ipa_source split. Das Delta gibt Aufschluss über den Stand der Implementierung – wenn der Benutzer eine große Lücke sieht und fragt: „Sollten wir eine Feinabstimmung vornehmen?“, lautet die Antwort: noch nicht; leiten Sie ihn zurück zur IPA-QA-Pipeline von /digital-health-clinical-asr-build(Stufe 2d). Siehe den Entscheidungsbaum unten.

Entscheidungsbaum (nach der Bewertung)

Lesen Sie die KER der Prioritätskategorie (Arzneimittel-KER für die meisten klinischen Arbeitsabläufe, Verfahrens-KER für chirurgische Arbeitsabläufe) und leiten Sie weiter:

Sonderfall – „merriam-webster“-Zeilen schneiden gut ab, „magpie_g2p“-Zeilen hingegen schlecht. Das ist eine Lücke in der Abdeckung der Aussprachehinweise, keine Modelllücke. Kehren Sie zurück zu /digital-health-clinical-asr-build Schritt 2d (IPA-QA-Überprüfung), nicht zu /digital-health-clinical-asr-finetune. Eine Feinabstimmung über eine TTS-Aussprachelücke hinweg bringt dem Modell bei, seine eigenen Fehler falsch zu erkennen – das ist die falsche Lösung.

Beispiele

Szenario A – erste Bewertung anhand eines neuen Manifests aus Zyklus 1. Benutzer: „Ich habe eine `manifest.jsonl`-Datei mit bereits 200 klinischen Audiozeilen, die die Felder `term` und `entity_category` enthalten. Wie bewerte ich diese?“ → Überspringe Stufe 2 vollständig. Führe die Vorabprüfung auf Audio-Vorhandensein durch. Wählen Sie „parakeet-tdt-0.6b-v2“ (Standard) aus und geben Sie die Auswahl sowie die aufgelöste Funktions-ID wieder. Führen Sie das eingebettete Rezept für Schritt 3b aus (transcribe_manifest(...)). Bewerten Sie die vier Metriken. Erstellen Sie die Rangliste mit fünf Abschnitten. Lesen Sie dem Benutzer die Aufteilungnach „ipa_source“ vor. Wenden Sie den Entscheidungsbaum auf „drug KER“ an.

Szenario B – Interpretation eines gemischten Ergebnisses. Benutzer: „Die Auswertung zeigt einen KER von 0,05 für Zeilen mit dem Tag ‚merriam-webster‘, aber 0,40 für Zeilen mit dem Tag ‚magpie_g2p‘. Sollte ich eine Feinabstimmung vornehmen?“ → Nein – dies ist ein Sonderfall. Das Modell ist in Ordnung; die Aussprachehinweise decken die Long-Tail-Begriffe nicht ab. Leiten Sie den Nutzer zurück zu /digital-health-clinical-asr-build Schritt 2d, um die „magpie_g2p“- Zeilen zu prüfen und verifizierte IPA-Angaben an „pronunciation_overrides.csv“ anzuhängen . Führen Sie Stufe 3 nach dem Neuaufbau erneut aus, bevor Sie Stufe 4 erneut in Betracht ziehen.

Erzeugte Artefakte

• per_sample.json – Transkriptionsergebnisse pro Zeile, wobei alle Felder der klinischen Erweiterung erhalten bleiben (die ASR -Hyp wird mit der Referenz und den Metadaten des Manifests verknüpft)
• results.csv – WER-/CER-/KER-/SER-Werte pro Zeile
• leaderboard_cycle.md — Markdown-Bericht in fünf Abschnitten

(Die Dateinamen werden vom Benutzer gewählt; die oben genannten Namen sind Konventionen, von denen im weiteren Verlauf dieses Skills ausgegangen wird.)

Fehlerbehebung

• „Kein Manifest gefunden“ → Der Benutzer hat Stufe 2 übersprungen. Wechseln Sie zu /digital-health-clinical-asr-build oder überprüfen Sie $MANIFEST_PATH.
• Alle Zeilen KER=1 → Normalisierungsabweichung zwischen ref und hyp. Wende die vier Normalisierungsschritte auf beide Seiten an.
• Alle Zeilen KER=0, aber WER hoch → wahrscheinlich falsch ausgerichtetes Manifest (Nichtübereinstimmung der Audiozeilen). Überprüfen Sie einige (Ref, Hyp) -Paare manuell stichprobenartig.
• merriam-webster niedrig, magpie_g2p hoch → Lücke in der Ausspracheabdeckung. Gehen Sie zu /digital-health-clinical-asr-build, Schritt 2d. Keine Feinabstimmung vornehmen – das Modell ist nicht das Problem.
• Sowohl „merriam-webster“ als auch „magpie_g2p“ hoch → echte Modelllücke. Stufe 4 ist der richtige Weg (Manifest ≥ 100 Zeilen).
• Saubere Zeilen in Ordnung, snr_5db schießt in die Höhe → Robustheitslücke; Rauschvielfalt über /digital-health-clinical-asr-build erweitern.
• Ergebnisse von Riva-NIM und Offline-NeMo weichen voneinander ab → Riva-Vorverarbeitung / „riva-build“-Flags. Wählen Sie den Pfad zu /riva-asr-custom.
• RESOURCE_EXHAUSTED bei großen Manifesten → Wiederholung nach 30 s; Ausschnitt + erneuter Lauf der verworfenen Zeilen. Integrierte Rückfallzeit: /riva-asr.
• Auth.__init__() hat „ssl_cert“ erhalten / unzulässiger Speicherzugriff durch CUDA bei Parakeet-Funktions-ID: siehe references/offline-asr-recipe.md (Umbenennung von ssl_root_cert + §Whisper-Fallback).

Sonstiges: Identifizieren Sie den Upstream-Eigentümer. ASR-Protokoll / NIM-Bereitstellung → /riva-asr. Bewertung → hier.

Einschränkungen

• Standardmäßig nur Englisch. Tokenisierung + Normalisierung gehen von lateinischer Schrift und en-US-Wortschatz aus.
• Strict-Contiguous-KER ist konservativ. Ein „Near-Miss“ wie „cefa zolin“ zählt als Fehltreffer. Das ist beabsichtigt – bei Apothekenabfragen schlagen Suchvorgänge bei Near-Misses fehl. Nutzer, die eine „weiche“ Übereinstimmung wünschen, können auf die Bearbeitungsdistanz auf Phonemebene umstellen; dies ist eine methodische Erweiterung und keine Konfigurationsanpassung.
• Ein Modell pro Auswertungslauf. Der Vergleich zweier Modelle bedeutet, die Auswertung zweimal durchzuführen und die beiden „leaderboard_cycle.md“-Dateien zu vergleichen (oder das Rezept so zu erweitern, dass Sie selbst Zeilen für mehrere Modelle schreiben).
• Es wird von ausschließlich gehosteten Pfaden ausgegangen. Selbst gehostete NIMs funktionieren, erfordern jedoch zunächst die Ausführung von /riva-nim-setup.

Nächste Schritte

• Vorwärts (KER > 0,3, Manifest ≥ 100 Zeilen): /digital-health-clinical-asr-finetune.
• Zurück zum Build (KER 0,1–0,3 bei erster Bewertung oder „magpie_g2p “-Lücke): /digital-health-clinical-asr-build.
• Beenden (KER < 0,1): Die Bewertung ist gesättigt. Optimieren Sie das Modell, bevor Sie den Erfolg verkünden.
• Weitere Informationen zu ASR-Protokoll, Authentifizierung, Streaming und selbst gehostetem NIM: /riva-asr.

Referenzen

• references/offline-asr-recipe.md — vollständiges Python-Rezept für Schritt 3b (transcribe_manifest, resolve_asr_config, build_asr_auth), Funktions-ID-Katalog mit Anmerkungen zur Aufrufstruktur, Whisper-Fallback, Einrichtung eines selbst gehosteten Riva-NIM
• references/scoring-recipes.md – reine Python-Bewertungsfunktionen für WER/CER/KER/SER mit der kanonischen 4-Stufen-Normalisierung