LLM-Enabled Development: Kaskadierende Workflows am Beispiel eines Textverarbeitungstools#
Von gesprochener zu geschriebener Sprache – in drei aufeinanderfolgenden Schritten
Im Rahmen der experimentellen Serie zu LLM-gestützter Entwicklung wird ein Projekt zur Erstellung eines Textaufbereitungstools vorgestellt. Fokussierte, kaskadierende Prompts führten in diesem Projekt zu besseren Ergebnissen als komplexe Alles-in-einem-Ansätze.
Das Problem#
Ausgangspunkt war eine praktische Herausforderung: Eine achtstündige Schulungsaufzeichnung zu LLM-Hintergründen lag als Transkript vor. Transkribierte gesprochene Sprache unterscheidet sich jedoch erheblich von geschriebenen Texten – sie enthält Füllwörter, Wiederholungen, abgebrochene Sätze und umgangssprachliche Formulierungen. Eine manuelle Aufbereitung von acht Stunden Material war nicht praktikabel.
Parallel bestand ein exploratives Lernziel: Wie lassen sich mehrstufige LLM-Workflows technisch implementieren? Welche Patterns bewähren sich bei der Textverarbeitung?
Die technische Umsetzung#
Es entstand ein Tool mit dreistufiger Verarbeitungskaskade:
Stufe 1 – Bereinigung: Korrektur offensichtlicher Transkriptionsfehler, Vervollständigung abgebrochener Sätze, Beseitigung von Füllwörtern
Stufe 2 – Überarbeitung: Umformulierung umgangssprachlicher Wendungen in sachlich-professionelle Sprache, Verbesserung der Textstruktur
Stufe 3 – Formatierung: Einarbeitung von Überschriften, Gliederung, Markdown-Strukturierung
Die technische Basis bildeten Gradio für die Benutzeroberfläche, Python mit asyncio für asynchrone Verarbeitung und Gearman für die Hintergrund-Jobverwaltung. Längere Texte werden mittels zeichenbasierten Chunking in Abschnitte aufgeteilt.
Entwicklungsaufwand: Circa 6-8 Stunden über mehrere Wochen verteilt, davon drei Stunden für Prompt-Optimierung. Codeumfang: 1.100 Zeilen in drei Dateien. Etwa zehn Hauptiterationen.
Zentrale Beobachtungen#
Initiale Versuche mit einem einzelnen, umfassenden Prompt führten zu stark beschädigten und gekürzten Texten. Das LLM versuchte, zu viele Transformationen gleichzeitig durchzuführen, was zu Informationsverlust führte.
Der gewählte Ansatz: Jede Verarbeitungsstufe erhielt genau einen fokussierten Auftrag. Statt “bereinige, überarbeite und formatiere den Text” drei separate Prompts mit je einem klaren Ziel. Diese Kaskadierung ermöglichte behutsame, präzise Textbearbeitung mit minimalem Informationsverlust.
Aus einem Transkript wie “LLMs sagen ja niemals, das weiß ich nicht” wird durch diese Pipeline “LLMs sagen niemals: Das weiß ich nicht” – inhaltlich identisch, sprachlich professionell.
Das Entwicklungsinterface als methodisches Werkzeug#
Eine hilfreiche Technik war die Erstellung eines erweiterten Entwicklungsinterfaces. Während die Produktivversion eine reduzierte Benutzeroberfläche bietet, erlaubte die Entwicklungsversion:
- Interaktive Anpassung der Prompts während der Verarbeitung
- Einsicht in Zwischenergebnisse jeder Verarbeitungsstufe
- Experimentelle Iteration ohne Deployment-Zyklen
Erst nach Optimierung der Prompts im Entwicklungsinterface wurde die finale Benutzeroberfläche abgeleitet.
Möglichkeiten und Erkenntnisse#
Eine wichtige Erkenntnis betrifft die Skalierbarkeit: Etwa 1.000 bis 1.500 Zeilen Code erwiesen sich als praktische Grenze für Entwicklungen ohne detailliertere Spezifikation. Größere Projekte erfordern strukturiertere Ansätze und detailliertere Vorabplanung.
Weitere Erkenntnisse:
- Klare, single-purpose Prompts zeigten in diesem Projekt bessere Ergebnisse als komplexe Multi-Task-Prompts
- Prompt-Optimierung benötigte signifikante Zeit (hier: 50% der Entwicklungszeit)
- Iterative Entwicklung mit Experimentierumgebungen beschleunigte die Optimierung
- Einfache technische Ansätze (zeichenbasiertes Chunking) erwiesen sich als ausreichend
Dies ist Teil einer Serie über methodische Erkenntnisse aus LLM-gestützten Entwicklungsprojekten. Der Fokus liegt auf übertragbaren Patterns und Beobachtungen zum Ansatz, nicht auf den Tools selbst.