LLM-Enabled Development: Kaskadierende LLM-Workflows#

Eine Fallstudie zur mehrstufigen Textverarbeitung mit fokussierten Prompts

Abstract#

Dieser Artikel dokumentiert Erkenntnisse aus der Entwicklung eines Tools zur Aufbereitung von Speech-to-Text-Transkripten mittels kaskadierender LLM-Workflows. Fokussierte, sequenzielle Prompts mit je einem spezifischen Auftrag führten dabei zu signifikant besseren Ergebnissen als komplexe Multi-Task-Prompts. Das Projekt lieferte übertragbare Erfahrungen zu Skalierungsgrenzen, Prompt-Engineering-Patterns und der Rolle von Experimentierumgebungen in der LLM-gestützten Entwicklung.

1. Experimenteller Kontext und Motivation#

1.1 Das zugrundeliegende Problem#

Die Ausgangssituation war zweifach motiviert: Einerseits bestand ein konkretes praktisches Problem, andererseits ein exploratives technisches Lernziel.

Praktischer Anlass: Eine achtstündige Schulung zu den Hintergründen von Large Language Models lag als Audioaufzeichnung transkribiert vor. Das Ziel war die Erstellung einer Dokumentation sowie eines KI-basierten Assistenten auf Basis dieser Schulungsinhalte. Die automatische Transkription mittels Speech-to-Text lieferte zwar den vollständigen Wortlaut, dieser war jedoch in der Form gesprochener Sprache verfasst – mit Füllwörtern, Wiederholungen, abgebrochenen Sätzen, umgangssprachlichen Formulierungen und typischen Merkmalen spontaner mündlicher Kommunikation.

Eine manuelle Aufbereitung von acht Stunden Transkriptionsmaterial in geschriebene Sprache war zeitlich nicht praktikabel. Gleichzeitig sollte die Aufbereitung behutsam erfolgen, um Informationsverlust zu minimieren und die inhaltliche Integrität zu wahren.

Technisches Lernziel: Parallel bestand das Interesse, mehrstufige LLM-Workflows technisch zu implementieren und deren Möglichkeiten zu evaluieren. Wie lassen sich kaskadierende Verarbeitungspipelines strukturieren? Welche Patterns bewähren sich bei der Transformation längerer Texte? Welche technischen Herausforderungen entstehen bei asynchroner Verarbeitung mit lokalen LLM-Instanzen?

1.2 Institutioneller Kontext#

An der Humboldt-Universität Berlin gibt es bereits seit 2024 ein etabliertes Speech-to-Text-System, das in die Verarbeitungsketten von OpenCast und Moodle integriert ist. Dieses System transkribiert Audio- und Videoaufzeichnungen bis zu 4 GB Größe und liefert die Ergebnisse in verschiedenen Formaten per E-Mail zurück.

Während wortgetreue Transkriptionen für bestimmte Zwecke (beispielsweise Untertitelung mit Zeitstempeln) unverzichtbar sind, bestand Bedarf an einer behutsamen Transformation in lesbaren Fließtext für andere Anwendungsfälle – insbesondere für die Weiterverarbeitung in RAG-Systemen und KI-Assistenten oder für Skripte.

1.3 Vom Lernprojekt zur produktiven Nutzung#

Ursprünglich war das Tool als exploratives Projekt konzipiert. Die Entwicklung zur produktiven Nutzung erfolgte graduell, als sich während der Entwicklung und ersten Tests herausstellte, wie robust die Ergebnisse waren und wie groß der institutionelle Bedarf an solcher Textaufbereitung ist.

Diese unerwartete Entwicklung zeigt, wie iterative, explorative Entwicklung mit LLMs zu Lösungen führen kann, deren Qualität und Anwendbarkeit die initialen Erwartungen übertrifft.

2. Technische Architektur und Implementierung#

2.1 Architektur-Überblick#

Die technische Architektur wurde bewusst auf Basis bestehender Infrastruktur und bewährter Komponenten gewählt:

Frontend: Gradio 5.0 für die webbasierte Benutzeroberfläche. Die Wahl fiel auf Gradio aufgrund vorhandener Deployment-Erfahrung und der Möglichkeit, schnell iterative Prototypen zu erstellen.

Backend: Python mit asyncio für asynchrone Verarbeitung. Die Implementierung nutzt aiohttp für nicht-blockierende API-Calls und ermöglicht parallele Verarbeitung mehrerer Textchunks.

Job-Verwaltung: Gearman für asynchrone Hintergrundverarbeitung. Diese Komponente war bereits in anderen Projekten im Einsatz und erwies sich als notwendig, da die Verarbeitung längerer Texte aufgrund zahlreicher LLM-API-Calls mehrere Minuten bis Stunden in Anspruch nehmen kann. Ergebnisse werden per E-Mail zugestellt.

LLM-Anbindung: Lokale LLM-Instanz über OpenAI-kompatible API. Dies ermöglicht die Nutzung institutioneller Compute-Ressourcen und wahrt Datenschutzanforderungen.

2.2 Modulare Struktur#

Die Implementierung umfasst 1.100 Zeilen Code in drei Hauptdateien.

Diese Modularisierung trennt Präsentations-, Verarbeitungs- und Orchestrierungslogik sauber voneinander und erleichtert Wartung und Testing.

2.3 Chunking-Strategie#

Längere Texte überschreiten typischerweise die Kontextfenster-Grenzen von LLMs. Die Implementierung nutzt daher einfaches zeichenbasiertes Chunking:

Die Entscheidung für zeichenbasiertes Chunking statt komplexerer Ansätze (beispielsweise satz- oder absatzbasiert) ist entlang von Tests in diesem Szenario entstanden.

2.4 Dreistufige Verarbeitungskaskade#

Das Kernkonzept ist die sequenzielle Verarbeitung durch drei fokussierte Prompts:

Stufe 1 – Bereinigung und Fehlerkorrektur:

• Korrektur offensichtlicher Transkriptionsfehler
• Vervollständigung abgebrochener Sätze
• Beseitigung von Füllwörtern und Wiederholungen
• Behutsame Verbesserung der Lesbarkeit

Stufe 2 – Stilistische Überarbeitung:

• Umformulierung umgangssprachlicher Wendungen in sachliche Sprache
• Transformation in professionellen Schreibstil
• Aktiv-Formulierungen statt Passiv
• Direkte Rede

Stufe 3 – Markdown-Formatierung:

• Einarbeitung von Überschriften und Strukturelementen
• Gliederung in Absätze
• Fachgerechte Terminologie
• Klare, professionelle Struktur

Jede Stufe erhält als Input das Output der vorherigen Stufe. Die Prompts enthalten eine {context}-Variable, in die Nutzende Fachgebiete oder spezifische Terminologie eintragen können, um die Qualität bei Fachtexten zu verbessern.

2.5 Fehlerbehandlung und Robustheit#

Die Implementierung enthält mehrere Mechanismen zur Sicherstellung der Robustheit:

Retry-Logik: Bei API-Fehlern erfolgen bis zu fünf Wiederholungsversuche mit exponentiellem Backoff (20 Sekunden Basisverzögerung)

Fallback-Strategie: Schlägt die Verarbeitung eines Chunks fehl, wird der ursprüngliche Text mit Fehlermarkierung übernommen

Timeout-Handling: API-Calls haben einen Timeout von 300 Sekunden

Datei-Validierung: Eingabedateien werden auf Typ, Größe (maximal 10 MB), Encoding und Binärdaten geprüft

Graceful Degradation: Bei Ressourcenüberlastung kann die Parallelität automatisch reduziert werden

3. Entwicklungsprozess mit LLM#

3.1 Iterativer Entwicklungsansatz#

Die Entwicklung erfolgte über mehrere Wochen mit etwa zehn Hauptiterationen. Die Gesamtentwicklungszeit betrug circa 6-8 Stunden, wobei etwa drei Stunden allein auf Prompt-Optimierung entfielen – ein signifikanter Anteil von 37-50% der Gesamtzeit.

Der Prozess war bewusst iterativ angelegt:

• Initiale Spezifikation der Anforderungen in Diskussion mit der LLM
• Implementierung einer ersten funktionierenden Version
• Testing mit realen Transkripten
• Identifikation von Schwachstellen
• Verfeinerung der Prompts oder des Codes
• Erneutes Testing

Dieser Zyklus wiederholte sich, bis die Ergebnisqualität den Anforderungen entsprach.

3.2 Rolle des Entwicklungsinterfaces#

Ein zentraler Ansatz war die Erstellung eines erweiterten Entwicklungsinterfaces. Während die finale Produktivversion eine reduzierte Oberfläche entlang der Hauptnutzungsszenarien bietet, enthielt die Entwicklungsversion zusätzliche Funktionalität:

• Editierbare Prompt-Felder für alle drei Verarbeitungsstufen
• Anzeige der Zwischenergebnisse nach jeder Stufe
• Detaillierte Statistiken und Timing-Informationen
• Konfigurierbare Parameter für Chunk-Größe und Parallelität

Dieses Interface diente als experimentelle Sandbox, in der Prompts iterativ verfeinert werden konnten, ohne den Code zu modifizieren oder das Tool neu zu deployen. Die Möglichkeit, Zwischenergebnisse zu inspizieren, war entscheidend für das Verständnis, an welcher Stelle der Pipeline Probleme auftraten.

Erst nachdem die Prompts im Entwicklungsinterface optimiert waren, wurde die finale Benutzeroberfläche abgeleitet und die Prompts im Code fixiert.

3.3 Verwendetes LLM#

Die Textverarbeitung selbst erfolgt über eine lokale LLM-Instanz.

Die Wahl des lokalen LLM für die Verarbeitung war durch institutionelle Verfügbarkeit und Datenschutzanforderungen motiviert. Gleichzeitig ermöglichte dies Experimente mit Prompt-Optimierung für ein spezifisches Modell.

3.4 Spezifikation und Kommunikation#

Die Kommunikation mit dem Code-generierenden LLM erfolgte primär iterativ im Dialog. Es gab keine umfassende Vorab-Spezifikation – stattdessen entwickelten sich Anforderungen und Implementierung schrittweise.

3.5 Management von Komplexität#

Die Vermeidung von Overengineering erfolgte primär durch Erfahrung: Wenn erkennbar wurde, dass vorgeschlagene Lösungen zu komplex waren, wurde aktiv auf Vereinfachung gedrängt. Beispiele:

• Verzicht auf komplexe NLP-basierte Chunking-Algorithmen zugunsten einfacher zeichenbasierter Aufteilung
• Fixierung der Prompt-Reihenfolge statt dynamischer Workflow-Konfiguration
• Einfache Dateivalidierung statt umfassender Content-Analyse

Das KISS-Prinzip (Keep It Small and Simple) wurde konsequent angewendet: Komplexität nur dort, wo sie nachweislich notwendig ist.

4. Methodische Kernerkenntnisse#

4.1 Kaskadierende Single-Purpose-Prompts#

Eine zentrale Erkenntnis dieses Projekts betrifft die Prompt-Architektur:

Initiale Versuche mit einem umfassenden Prompt – der das LLM anwies, Text gleichzeitig zu bereinigen, stilistisch zu überarbeiten und zu formatieren – führten zu stark beschädigten und gekürzten Ergebnissen. Das Modell versuchte, zu viele Transformationen simultan durchzuführen, was zu Informationsverlust, Halluzinationen und inkonsistenten Ergebnissen führte.

Die funktionierende Herangehensweise bestand in fokussierter Sequenzierung. Jede Verarbeitungsstufe erhielt genau einen klar definierten Auftrag. Statt “bereinige, überarbeite und formatiere” wurden drei separate Prompts eingesetzt:

• Nur Bereinigung
• Nur stilistische Überarbeitung
• Nur Formatierung

Diese Kaskadierung ermöglichte behutsame, präzise Textbearbeitung mit minimalem Informationsverlust. Jede Stufe baute auf dem Output der vorherigen auf, wodurch inkrementelle Verbesserung statt abrupter Transformation erfolgte.

4.2 Skalierungsgrenzen ohne tiefe Spezifikation#

Eine pragmatische Erkenntnis betrifft die Skalierbarkeit des Ansatzes:

Circa 1.000 bis 1.500 Zeilen Code markieren bei den ersten Experimenten das Maximum, das ohne tiefgehende Vorab-Spezifikation realisiert werden konnte. Jenseits dieser Größenordnung steigt die Komplexität des Kontexts, die Anzahl der Abhängigkeiten und die Notwendigkeit konsistenter Architekturentscheidungen so stark an, dass strukturiertere Ansätze erforderlich werden.

4.3 Prompt-Engineering als Kernkompetenz#

50% der Entwicklungszeit entfiel auf Prompt-Optimierung. Dies unterstreicht die Bedeutung von Prompt-Engineering als Kernkompetenz in der LLM-gestützten Entwicklung.

Erfolgreiche Prompts für die Textverarbeitung zeigten folgende Merkmale:

Explizite Output-Constraints: Klare Anweisungen zur Ausgabe

Kontext-Integration: Worum geht es und was ist der thematische Zusammenhang

Strukturelle Hinweise: Anweisungen zum strukturellen Kontext

Positive Formulierung: Aufgaben anstelle Verboten formulieren.

4.4 Randbedingungen von LLMs in der Textverarbeitung#

Zwei wichtige Randbedingungen wurden deutlich:

Geschwindigkeit: LLMs sind nicht schnell. Die Verarbeitung längerer Texte mit mehreren hundert Chunks kann Stunden in Anspruch nehmen. Dies erzwingt asynchrone Architekturen mit Job-Queues und E-Mail-Benachrichtigung.

Kontextgrenzen: Trotz wachsender Kontextfenster bleiben Grenzen. Chunking ist für längere Dokumente unvermeidlich, und die Zusammenführung der Chunks erfordert sorgfältige Behandlung von Überlappungen.

Diese Limitierungen sind keine Schwächen des Ansatzes, sondern Rahmenbedingungen, die Architekturentscheidungen beeinflussen müssen.

4.5 Entwicklungsumgebungen als methodisches Werkzeug#

Die zusätzliche Entwicklungs-UI erwies sich als wichtiges Element, um rasch mit den Entwicklungen voranzukommen. Die Möglichkeit, Prompts interaktiv zu adjustieren und Zwischenergebnisse zu inspizieren, beschleunigte die Iteration erheblich.

Eine übertragbare Beobachtung: Bei LLM-Workflows erwies sich die Investition in Experimentierumgebungen als hilfreich, die:

• Schnelle Iteration ohne Deployment ermöglichen
• Zwischenergebnisse sichtbar machen
• Parameter-Tuning erleichtern
• Ausreichend Metainformationen zur Verarbeitung bereitstellen
• Als Sandbox für Nutzer-Feedback dienen

Nach der Stabilisierung der Funktionen kann die finale Produktivoberfläche abgeleitet werden.

5. Validierung und produktive Nutzung#

5.1 Validierungsprozess#

Die initiale Validierung erfolgte mit dem acht-Stunden-Schulungstranskript, das den ursprünglichen Anlass für die Entwicklung bildete. Weitere Tests umfassten Vorlesungstranskripte, Seminaraufzeichnungen und spontane mündliche Notizen.

Die Validierung fokussierte auf:

• Inhaltliche Korrektheit (kein Informationsverlust)
• Sprachliche Qualität (flüssige, professionelle Formulierungen)
• Strukturelle Kohärenz (logischer Aufbau, sinnvolle Gliederung)
• Robustheit bei unterschiedlichen Textlängen und -qualitäten

Die produktive Nutzung wurde möglich, als deutlich wurde, dass die Ergebnisqualität konsistent den Erwartungen entsprach.

Metadaten#

Projektumfang: 1.100 Zeilen Code in 3 Dateien
Entwicklungszeit: 6-8 Stunden über mehrere Wochen
Iterationen: ~10 Hauptiterationen
Verwendetes LLM: Mistral Small 2506 (Code-Entwicklung), lokales llm3 (Textverarbeitung)
Technologie-Stack: Python, Gradio 5.0, asyncio, aiohttp, Gearman, OpenAI-kompatible API
Status: In produktiver Nutzung

Diese Dokumentation ist Teil einer Serie über methodische Erkenntnisse aus LLM-gestützten Entwicklungsprojekten. Der Fokus liegt auf übertragbaren Patterns und Grenzen verschiedener Entwicklungsansätze. Weitere Fallstudien folgen.