Von Transkript zu Text: Wie mehrstufige KI-Workflows helfen#

Transkripte sind unleserlich. Ein dreistufiger Ansatz macht sie zu professionellen Texten – ohne Informationsverlust.

Wir haben ein Tool entwickelt, das gesprochene Sprache in drei Schritten in geschriebene Texte verwandelt. Das Besondere: Jeder Schritt macht nur eine Sache, und genau das funktioniert.

Was war die Herausforderung?#

Acht Stunden Schulungsmaterial. Alles transkribiert.

Aber transkribierte Sprache ist ein Problem. Sie enthält Füllwörter wie “äh” und “also”, Wiederholungen, abgebrochene Sätze und umgangssprachliche Formulierungen. Das liest sich niemand durch.

Eine manuelle Aufbereitung von acht Stunden Material? Nicht praktikabel. Gleichzeitig wollten wir verstehen: Wie baut man mehrstufige KI-Workflows technisch auf? Welche Ansätze funktionieren bei Textverarbeitung?

Wie funktioniert das Tool?#

Das Tool verarbeitet Texte in drei aufeinanderfolgenden Schritten:

  • Stufe 1 – Bereinigung: Korrektur offensichtlicher Fehler (z. B. falsch erkannte Wörter, Tippfehler), Vervollständigung abgebrochener Sätze, Beseitigung von Füllwörtern
  • Stufe 2 – Überarbeitung: Umformulierung umgangssprachlicher Wendungen in professionelle Sprache, Verbesserung der Textstruktur
  • Stufe 3 – Formatierung: Einarbeitung von Überschriften, Gliederung, Strukturierung mit Markdown

Ein Beispiel: Aus “LLMs sagen ja niemals, das weiß ich nicht” wird “LLMs sagen niemals: Das weiß ich nicht” – inhaltlich identisch, sprachlich professionell.

Wie sind wir vorgegangen?#

Wir haben das Tool mit gängigen Technologien gebaut:

  • Benutzeroberfläche (Gradio): Einfache Web-Oberfläche für den Upload
  • Verarbeitung (Python mit asyncio): Asynchrone Abarbeitung der drei Stufen
  • Job-Verwaltung (Gearman): Hintergrund-Verarbeitung für längere Texte
  • Text-Aufteilung: Zeichenbasiertes Chunking für große Dokumente

Gesamtaufwand: Circa 6-8 Stunden über mehrere Wochen verteilt, davon 3 Stunden für Prompt-Optimierung. Codeumfang: 1.100 Zeilen in drei Dateien. Etwa 10 Hauptiterationen.

Die Entwicklung lief iterativ: Wir haben zuerst eine erweiterte Entwicklungsversion gebaut, die interaktive Prompt-Anpassungen während der Verarbeitung erlaubte. Erst nach der Optimierung haben wir die finale Benutzeroberfläche erstellt.

Warum hat das gut funktioniert?#

Weil jeder Schritt nur eine Aufgabe hatte.

Unsere ersten Versuche mit einem umfassenden Prompt schlugen fehl. Das Sprachmodell versuchte, alle Transformationen gleichzeitig durchzuführen – bereinigen, überarbeiten, formatieren. Das Ergebnis: stark beschädigte und gekürzte Texte mit massivem Informationsverlust.

Der Durchbruch kam mit der Aufteilung. Jede Stufe erhielt genau einen fokussierten Auftrag. Nicht “bereinige, überarbeite und formatiere”, sondern drei separate Prompts mit je einem klaren Ziel. Diese Kaskadierung ermöglichte behutsame, präzise Textbearbeitung.

Wichtige Erkenntnisse#

1. Fokussierte Prompts schlagen komplexe Prompts

Klare, single-purpose Prompts funktionierten deutlich besser als Multi-Task-Prompts. Ein Prompt mit einem Ziel lieferte präzisere Ergebnisse als ein Prompt mit mehreren Zielen. Der Grund: Das Sprachmodell kann sich auf eine Transformation konzentrieren, ohne andere Aspekte zu berücksichtigen.

2. Prompt-Optimierung braucht Zeit

Die Hälfte der Entwicklungszeit floss in die Prompt-Optimierung. Das klingt viel, war aber nötig. Ohne gute Prompts funktioniert das Tool nicht. Die Investition hat sich gelohnt: Die finalen Prompts liefern konstant gute Ergebnisse.

3. Entwicklungsinterfaces beschleunigen die Iteration

Eine erweiterte Entwicklungsversion mit direktem Zugriff auf Prompts und Zwischenergebnisse war entscheidend. Wir konnten während der Verarbeitung experimentieren, ohne neue Versionen zu deployen. Das reduzierte die Optimierungszyklen erheblich.

4. Einfache Techniken reichen oft aus

Zeichenbasiertes Chunking funktionierte für unseren Anwendungsfall ausreichend gut. Komplexere Ansätze (z. B. semantisches Chunking) waren nicht nötig. Manchmal ist die einfachste Lösung die richtige.

5. Etwa 1.000-1.500 Zeilen sind die praktische Grenze

Bei dieser Codegröße funktioniert die Entwicklung mit Sprachmodellen ohne detaillierte Vorabspezifikation noch gut. Größere Projekte benötigen strukturiertere Ansätze und mehr Planung.

Was können andere davon lernen?#

  • Teile komplexe Aufgaben in einzelne, fokussierte Schritte auf – jeder Schritt sollte nur eine Sache machen.
  • Investiere Zeit in Prompt-Optimierung, das macht den Unterschied zwischen “funktioniert manchmal” und “funktioniert zuverlässig”.
  • Baue Entwicklungsversionen mit direktem Zugriff auf interne Zustände, das beschleunigt Experimente erheblich.
  • Starte mit einfachen technischen Ansätzen und optimiere nur, wenn wirklich nötig.
  • Für Projekte über 1.500 Zeilen Code: Plane detaillierter im Voraus.

Fazit#

✔ Mehrstufige Workflows funktionieren besser als Alles-in-einem-Ansätze bei komplexen Textverarbeitungen

✔ Fokussierte Prompts mit einem klaren Ziel liefern präzisere Ergebnisse als Multi-Task-Prompts

✔ Iterative Entwicklung mit Experimentierumgebungen spart Zeit bei der Optimierung

Dies ist Teil einer Serie über Erfahrungen mit KI-gestützter Softwareentwicklung. Der Fokus liegt darauf, was man aus solchen Projekten lernen kann – nicht nur auf den Ergebnissen.