Von gesprochener zu geschriebener Sprache: Wie wir ein Textaufbereitungstool entwickelt haben#

Wir haben ein Tool entwickelt, das Transkripte automatisch in professionelle Texte verwandelt – mit drei aufeinanderfolgenden Bearbeitungsschritten. Der Schlüssel zum Erfolg: Fokussierte Einzelaufträge statt komplexer Alles-in-einem-Prompts.

Was war die Herausforderung?#

Wir standen vor einem praktischen Problem. Eine achtstündige Schulungsaufzeichnung lag als Transkript vor.

Transkribierte gesprochene Sprache ist anders als geschriebener Text. Sie enthält Füllwörter, Wiederholungen, abgebrochene Sätze. Eine manuelle Aufbereitung von acht Stunden Material? Nicht praktikabel.

Gleichzeitig wollten wir verstehen: Wie baut man mehrstufige Workflows mit Sprachmodellen? Welche Ansätze funktionieren bei der Textverarbeitung?

Wie funktioniert das Tool?#

Wir haben eine dreistufige Verarbeitungskaskade entwickelt:

Stufe 1 – Bereinigung: Korrektur von Transkriptionsfehlern, Vervollständigung abgebrochener Sätze, Entfernung von Füllwörtern (z. B. “ähm”, “also”, “sozusagen”)
Stufe 2 – Überarbeitung: Umformulierung umgangssprachlicher Wendungen in sachliche Sprache, Verbesserung der Textstruktur
Stufe 3 – Formatierung: Einarbeitung von Überschriften, Gliederung, Markdown-Struktur (z. B. Listen, Absätze, Hervorhebungen)

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

Wie haben wir es entwickelt?#

Die technische Basis:

Frontend (Gradio): ~400 Zeilen für die Benutzeroberfläche
Backend (Python mit asyncio): ~500 Zeilen für asynchrone Verarbeitung
Job-Verwaltung (Gearman): ~200 Zeilen für Hintergrund-Jobs
Gesamtaufwand: Etwa 6-8 Stunden über mehrere Wochen verteilt
Prompt-Optimierung: 3 Stunden (50% der Entwicklungszeit)
Iterationen: Circa 10 Hauptdurchläufe bis zur finalen Version

Längere Texte teilen wir zeichenbasiert in Abschnitte auf. So bleibt die Verarbeitung effizient.

Warum hat der Ansatz funktioniert?#

Weil wir jeder Verarbeitungsstufe genau einen fokussierten Auftrag gegeben haben.

Unsere ersten Versuche waren anders. Wir haben mit einem einzigen, umfassenden Prompt gearbeitet: “Bereinige, überarbeite und formatiere den Text.” Das Ergebnis? Stark beschädigte und gekürzte Texte. Das Sprachmodell versuchte, zu viele Transformationen gleichzeitig durchzuführen.

Dann haben wir den Ansatz geändert. Drei separate Prompts mit je einem klaren Ziel. Diese Kaskadierung ermöglichte behutsame, präzise Textbearbeitung – mit minimalem Informationsverlust.

Wichtige Erkenntnisse#

1. Das Entwicklungsinterface als Optimierungs-Werkzeug

Wir haben zwei Versionen gebaut: Eine für die Entwicklung, eine für Nutzer. Die Entwicklungsversion war entscheidend für die Optimierung.

Sie ermöglichte uns:

Interaktive Anpassung der Prompts während der Verarbeitung
Einsicht in Zwischenergebnisse jeder Verarbeitungsstufe
Experimentelle Iteration ohne Deployment-Zyklen

Erst nach der Optimierung im Entwicklungsinterface haben wir die finale Benutzeroberfläche abgeleitet. So konnten wir schnell testen und verbessern.

2. Die praktische Grenze bei der KI-gestützten Entwicklung

Etwa 1.000 bis 1.500 Zeilen Code erwiesen sich als praktische Grenze ohne detaillierte Spezifikation. Bei größeren Projekten braucht es strukturiertere Ansätze.

Diese Grenze ist wichtig zu kennen. Wer größere Tools plant, sollte mehr Zeit in die Vorabplanung investieren.

3. Einfache technische Lösungen reichen oft aus

Wir haben zeichenbasiertes Chunking verwendet – eine einfache Methode. Sie war völlig ausreichend für unseren Zweck.

Die Lektion: Man muss nicht immer die komplexeste Lösung wählen. Oft funktionieren einfache Ansätze besser.

Was können andere davon lernen?#

Fokussierte Einzelaufträge führen zu besseren Ergebnissen als komplexe Multi-Task-Prompts
Prompt-Optimierung braucht Zeit – hier die Hälfte der gesamten Entwicklung
Ein Entwicklungsinterface beschleunigt die Optimierung erheblich
Einfache technische Ansätze (z. B. zeichenbasiertes Chunking) sind oft ausreichend
Die 1.000-1.500 Zeilen Grenze ist ein guter Richtwert für schnelle Entwicklung ohne Spezifikation

Fazit#

✔ Kaskadierende Workflows mit fokussierten Einzelaufträgen schlagen komplexe Alles-in-einem-Ansätze

✔ Ein Entwicklungsinterface ermöglicht schnelle Optimierung und experimentelles Arbeiten

✔ Einfache technische Lösungen reichen oft aus – Komplexität ist nicht immer nötig

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