// DEEP DIVE | KI-WORKFLOWS
Multi-Step Pipelines: Architektur für komplexe KI-Aufgaben
Ein einzelnes Modell ist mit komplexen Aufgaben überfordert. Kontextfenster sind begrenzt, Halluzinationen wachsen mit jeder zusätzlichen Anforderung im Prompt. Die Lösung ist das Zerlegen in eine Kette spezialisierter, kontrollierbarer Schritte. Nicht ein Universal-Modell, das alles versucht, sondern viele kleine Modelle, die jeweils eine Sache gut machen und sich gegenseitig prüfen. So entsteht aus prompt-basiertem Experimentieren echte Software-Engineering-Disziplin.
DAS PROBLEM
Warum Single Prompts an komplexen Aufgaben scheitern
ChatGPT bekommt die Aufgabe, eine 50-seitige Analyse zu schreiben. Die ersten fünf Seiten klingen brillant. Ab Seite 10 verliert das Modell den roten Faden, ab Seite 20 widerspricht es sich selbst, ab Seite 30 erfindet es Quellen. Das ist kein Bug, es ist die Natur eines Modells, das einen langen, komplexen Auftrag in einem Durchgang erledigen soll.
Das Kontextfenster ist endlich. Was am Anfang der Antwort steht, vergisst das Modell am Ende. Hinzu kommt: Je länger der Prompt, desto mehr Anweisungen muss das Modell gleichzeitig beachten. Prüfe Tonalität, halte Format, nutze Quellen, vermeide Wiederholungen, bleibe im Markenstil. Alles auf einmal, in einem Schuss. Das funktioniert für Tweet-längen, nicht für Reports.
Die Lösung ist das Prinzip aus der industriellen Fertigung: Fließband statt Universal-Werkbank. Station 1 stanzt, Station 2 schweißt, Station 3 lackiert. Bei KI bedeutet das: Ein Modell extrahiert Fakten, ein zweites strukturiert sie, ein drittes formuliert sie, ein viertes prüft das Ergebnis. Jede Station hat eine klare Aufgabe und ein klares Prüfkriterium.
Was ist LLM Chaining und Prompt Chaining?
LLM Chaining ist das Verknüpfen mehrerer KI-Modell-Aufrufe zu einer Pipeline, bei der der Output eines Schritts der Input des nächsten wird. Anders als ein Single-Prompt-Ansatz zerlegt eine Chain eine komplexe Aufgabe in eine Sequenz von Teilaufgaben, die je für sich klein und kontrollierbar sind. Implementiert wird das über Frameworks wie LangChain oder Flowise. Drei Grundmuster decken die meisten Fälle ab: Sequential Chains (Output A wird Input B), Parallel Processing nach dem Map-Reduce-Prinzip (mehrere Modelle bearbeiten Teilaufgaben gleichzeitig) und Conditional Loops ("wenn Ergebnis schlecht, gehe zurück").
Vier Bausteine, beliebig kombiniert
/ UNSER ANSATZ
01
Schritt 01
Sequential Chains (linear)
Der einfachste Fall: Schritt A produziert Output, Schritt B verarbeitet ihn weiter, Schritt C prüft das Ergebnis. Beispiel für Produktdaten: Schritt 1 extrahiert Attribute aus einem Lieferanten-PDF. Schritt 2 klassifiziert das Produkt nach ECLASS. Schritt 3 schreibt den Marketing-Text. Schritt 4 prüft auf Faktenkonflikte gegen Schritt 1. Vier kleine Aufgaben, jede einzeln optimierbar und testbar.
02
Schritt 02
Router Chains (Wenn-Dann-Logik)
Nicht jeder Datensatz braucht denselben Pfad. Ein Router-Schritt entscheidet, ob der Input technisch (geht in die Dokumentations-Pipeline) oder werblich (geht in die Marketing-Pipeline) verarbeitet werden soll. So entsteht ein Entscheidungsbaum statt einer linearen Sequenz. Was unsicher ist, wird in einen Default-Pfad geroutet oder zur menschlichen Prüfung markiert.
03
Schritt 03
RAG Pipelines (Retrieval-Augmented Generation)
Bevor das Modell antwortet, sucht ein Retrieval-Schritt in Ihrer Wissensbasis nach den relevanten Quellen. Das Modell antwortet dann nur auf Basis dieser Quellen, nicht aus seinem allgemeinen Training. Das ist der Standard-Pfad gegen Halluzinationen bei dokumentenbasierten Fragen (interne FAQ, Compliance, Produktdokumentation). Quellen werden mitgeliefert, der Nutzer kann nachprüfen.
04
Schritt 04
Parallel Processing (Map-Reduce)
Für große Datenmengen splitten wir die Aufgabe auf mehrere Modelle, die parallel arbeiten. Fünf Modelle übersetzen je tausend Produkttexte gleichzeitig, ein Aggregator-Modell führt die Ergebnisse zusammen und prüft auf Konsistenz. Das verkürzt die Gesamt-Latenz dramatisch, ohne dass die Einzelqualität leidet.
Error Handling und Robustheit
Eine produktive Pipeline ist mehr als verbundene Prompts. Sie hat Error Handling: Was passiert, wenn ein Schritt fehlschlägt? Retry mit anderem Modell? Skip und Markierung als manuell zu prüfen? Stopp der gesamten Kette? Sie hat Logging: jeder Schritt hinterlässt eine Spur mit Input, Output und Latenz, sodass Fehler nachvollziehbar bleiben. Sie hat Determinismus: was zweimal mit denselben Daten läuft, liefert vergleichbare Ergebnisse. All das macht den Unterschied zwischen Demo und Produktion.
20+
Teilschritte in einer typischen produktiven Pipeline
Was ein Single Prompt als 1-Schritt-Aufgabe formuliert, wird in einer produktiven Pipeline auf 20 oder mehr spezialisierte Teilschritte verteilt: Datenladen, Vorverarbeitung, Anreicherung, Klassifikation, Generierung, mehrere Validierungs-Layer, Logging, Output-Formatierung. Was für den Nutzer als "ein KI-Vorgang" wirkt, ist intern ein orchestrierter Workflow mit klaren Verantwortlichkeiten pro Knoten.
Wo Pipelines Single Prompts schlagen
Kriterium
Single Prompt (Chatbot)
Multi-Step Pipeline (Xanevo)
Komplexität
Begrenzt durch Kontextfenster
Beliebig, durch Aufteilung in Schritte
Halluzinationen
Wahrscheinlich bei langen Aufgaben
Reduziert durch Validierungs-Layer
Determinismus
Niedrig (jeder Run anders)
Hoch (klare Prüfkriterien pro Schritt)
Error Handling
Kein, Fehler werden Output
Retry, Skip, Loop, Eskalation
Auditierbarkeit
Black Box
Jeder Schritt loggable
Drei Fragen, die Engineers und Process Architects stellen
LangChain für Python-basierte Pipelines, Flowise oder n8n für Low-Code-Setups mit Visualisierung, LangGraph für komplexe Agent-Architekturen mit Schleifen. Welche Kombination sinnvoll ist, hängt von der Aufgabe ab. Für deterministische Batch-Jobs reicht oft eine einfachere Lösung, für agentenbasierte Aufgaben mit Tool-Aufrufen brauchen wir die Tiefe von LangGraph.
Stimmt grundsätzlich. Wir setzen drei Hebel ein: Parallel Processing wo möglich (mehrere Schritte gleichzeitig statt nacheinander), Caching identischer Teilergebnisse, und kleinere, schnellere Modelle für Routine-Schritte. Für Echtzeit-Anwendungen ist eine 4-Schritt-Pipeline unter 2 Sekunden machbar. Für Batch-Jobs spielt die Latenz pro Vorgang ohnehin keine Rolle.
Das ist eine berechtigte Frage. Deshalb bauen wir auf etablierten Open-Source-Frameworks (LangChain, Flowise, n8n) statt auf einer proprietären Xanevo-Plattform. Pipeline-Definitionen sind als Code oder Flowise-Export bei Ihnen. Ihr Team oder ein anderer Dienstleister kann übernehmen, ohne dass Sie auf uns angewiesen sind. Kein Vendor-Lock-in.
Verwandte Deep Dives
SAP Integration
Pipelines werden besonders wertvoll, wenn sie mit Bestandssystemen sprechen müssen. SAP ist der typische Endpunkt einer Multi-Step-Pipeline.
Microsoft Dynamics
Power-Automate-Flows als visuelle Pipeline-Sprache für den Microsoft-Stack, erweitert um Custom-KI-Schritte, wo Standard nicht reicht.
// MULTI-STEP PIPELINES
Skizzieren wir Ihre Pipeline.
Beschreiben Sie uns Ihren komplexen Workflow, an dem Single Prompts heute scheitern. Wir entwerfen eine Pipeline-Architektur mit definierten Knoten, Prüfschritten und Error Handling und liefern Ihnen ein konkretes Diagramm plus Aufwandsschätzung. In einer Woche.