Vom Mega-Prompt zur Pipeline: wie wir einen KI-Prozess von 58s auf 14s gebracht haben

Vor einigen Monaten mussten wir an ein System heran, das freien Text — Notizen von Vertriebsleuten, Gesprächstranskripte, weitergeleitete E-Mails — in strukturierte CRM-Datensätze verwandelte: Kunden, Opportunities, nächste Schritte, kumulative Zusammenfassungen. Die Geschäftslogik war gut durchdacht, und den Prompt hatte jemand geschrieben, der die Vertriebsdomäne sehr gut kannte.

Das Problem lag woanders: Pro Eingabe dauerte es zwischen 46 und 68 Sekunden.

Achtundfünfzig Sekunden im Schnitt. Mehr als eine Minute Spinner, jedes Mal wenn jemand aus dem Vertrieb eine Notiz vom Handy speicherte. Heute antwortet derselbe Prozess in 8-12 Sekunden: bis zu 8-mal schneller, bei gleichem Funktionsumfang, gleichem Basismodell und ohne ein einziges gestrichenes Feld im Ergebnis.

Dieser Artikel erzählt, wie wir diesen Prozess unter 20 Sekunden gebracht haben, ohne eine einzige Funktion zu streichen. Es steckt kein Prompt-Trick dahinter. Die Änderung war architektonisch, und die Schlussfolgerung — die wir schon ahnten, die hier aber gemessen wurde — lautet: Ein riesiger Prompt ist keine Architektur, sondern ein Aufschub der Architektur.

Das Projekt gehört einem Kunden, deshalb ist alles Folgende anonymisiert: keine Namen, keine wörtlichen Prompts, keine Geschäftsdaten. Real sind die Struktur des Problems, die Messwerte und die Entscheidungen.

Schritt 1: alles in einem einzigen Aufruf

Der Ausgangspunkt war der klassische, und das sage ich nicht abwertend: So beginnen 90 % der KI-Funktionen, die zuerst im Chat validiert werden. Ein einziger Modellaufruf mit einem System-Prompt von mehreren tausend Wörtern, der all das gleichzeitig erledigte:

• Erkennen, welche kommerziellen Ereignisse im Text stecken
• Sie nach Typ klassifizieren
• Den Subtext interpretieren und entscheiden, welcher Zug der wichtigste ist
• Pro Ereignis ein JSON mit über dreißig Feldern bauen
• Narrative Inhalte erzeugen: Zustandsbilder, taktische Insights, Briefings, Gesprächsleitfäden
• Die kumulativen Zusammenfassungen jedes Kunden und jeder Opportunity konsolidieren, unter Wahrung der Historie

Es funktionierte. Im Chat, mit einem hübschen Beispiel, funktionierte es sogar recht gut. In Produktion aber, mit Temperatur 0.7 und zehn Anfragen hintereinander, sahen die Zeiten so aus:

Die Temperatur auf 0.2 zu senken — der übliche Verdächtige — änderte nichts: 59,1 s im Schnitt. Da wussten wir, dass das Problem keine Konfigurationsfrage war.

Der Ausgangspunkt: ein Aufruf, fünf Verantwortungen, ein riesiger Output und 58,3 Sekunden Wartezeit.

Warum ein einziger Aufruf das Problem war

Es gibt drei Gründe, und man sollte sie trennen, weil sie unterschiedlich zu beheben sind.

Die Latenz bestimmt der Output, nicht der Input. Ein LLM erzeugt Token für Token. Man kann ihm 8.000 Token Kontext geben, die verarbeitet es schnell — aber jedes Token, das es schreibt, kostet Zeit. Ein Prompt, der ein JSON mit dreißig Feldern plus fünf narrative Texte pro erkanntem Ereignis verlangt, ist nicht langsam, weil er viel denkt: Er ist langsam, weil er enorm viel schreibt. Und enthält der Eingabetext drei kommerzielle Ereignisse, verdreifacht sich der Output.

Die Aufmerksamkeit verwässert. Wenn Formatregeln, Felddefinitionen, Tonalitätsvorgaben, Priorisierungskriterien und bedingte Logik im selben Prompt stehen, konkurrieren sie alle um dasselbe Aufmerksamkeitsbudget. Eine Namensregel kann der Ereigniserkennung Denkkapazität stehlen. Es ist derselbe Effekt, als würde man einen Menschen bitten, in einem Durchgang einen Text zu lesen, ihn zu klassifizieren, ein Formular mit dreißig Feldern auszufüllen, drei Absätze strategische Analyse zu schreiben und eine Historie zu aktualisieren. Er schafft es. Er macht es schlechter, als wenn man es in Teilen verlangt.

Das Denken ist undurchsichtig. Erkennt das System ein Ereignis falsch, zieht sich der Fehler durch Strukturierung, Narrative und Konsolidierung. Man kann weder feststellen, wo es schiefging, noch nur diesen Teil wiederholen. Und optimieren lässt sich auch nichts einzeln: Wenn die Narrative lange dauert, kann man sie nicht entfernen, ohne den Rest des Outputs zu zerstören.

Dieser dritte Punkt ist der, der mittelfristig am teuersten wird — und der in einer Demo am wenigsten sichtbar ist.

Schritt 2: den Prompt aufteilen, um zu sehen, nicht um schneller zu sein

Die erste Änderung nahmen wir nicht zur Optimierung vor. Wir nahmen sie vor, um zu verstehen.

Wir trennten den einzelnen Aufruf in Phasen mit expliziten Ein- und Ausgaben, maßen jede einzeln und ließen alles andere unverändert. Keine Parallelisierung, keine anderen Modelle, keine Prompt-Kürzungen. Nur zerlegen und stoppen.

Das Ergebnis war eine bescheidene Verbesserung — von 58 auf 28,4 Sekunden, im Wesentlichen weil jeder Aufruf auf einmal weniger Text erzeugte —, aber darum ging es nicht. Entscheidend war: Aus einer Blackbox wurde ein beobachtbares System. Zum ersten Mal konnten wir beantworten: „Wo bleiben die Sekunden?”

Dieselbe Arbeit, drei messbare Phasen. Der Zeitgewinn war bescheiden, der Sichtbarkeitsgewinn total.

Und die Antwort war eindeutig: Der Strukturierungsschritt war weiterhin ein vollständiges Mini-Gehirn. Er erkannte, strukturierte, priorisierte, schrieb Narrative und konsolidierte Entitäten. Wir hatten den Monolithen in Stücke zerlegt, aber eines der Stücke war immer noch ein Monolith.

Dieser Zwischenschritt wirkt im Nachhinein verzichtbar. Ist er nicht. Wären wir direkt zum finalen Design gesprungen, hätten wir blind optimiert — und wahrscheinlich den falschen Schritt.

Schritt 3: spezialisieren, parallelisieren und vom kritischen Pfad nehmen

Mit den Messwerten vor Augen ergab sich das Redesign von selbst. Drei Entscheidungen:

1. Eine Verantwortung pro Aufruf. Der große Schritt wurde erneut geteilt: das Operative (Daten für die Datenbank) getrennt vom Narrativen (Texte, die ein Mensch liest).
2. Was von nichts abhängt, läuft parallel. Mehrere Schritte brauchten nur die Ausgabe der ersten Erkennung, nicht die der anderen. Es gab keinen Grund, sie seriell auszuführen.
3. Was nicht blockiert, ab in den Hintergrund. Die Narrative ist am langsamsten zu erzeugen und am wenigsten dringend: Niemand liest ein Meeting-Briefing in derselben Sekunde, in der er eine Notiz speichert.

So sieht die Pipeline aus:

Die Schritte 2, 3 und 4 starten gleichzeitig, sobald Schritt 1 fertig ist, denn alle drei verbrauchen dasselbe: die Liste der erkannten Ereignisse. Schritt 5 wird gestartet, nachdem der Nutzer bereits eine Antwort erhalten hat, und aktualisiert die Datensätze, sobald er fertig ist.

Das finale Design: ein leichter Schritt öffnet den Graphen, drei Schritte laufen parallel, alles Narrative liegt außerhalb des kritischen Pfads.

Die Zahlen

In einem Satz: Der Prozess wurde mehr als 4-mal schneller von Anfang bis Ende und bis zu 8-mal schneller in dem, was der Nutzer wahrnimmt. Die Wartezeit sank von 58,3 Sekunden — mehr als eine Minute vor einem Spinner — auf 8-12 Sekunden: -83 %, bei gleicher Funktionalität und gleichem Basismodell.

Und das ist nicht einmal der härteste Vergleich. Der schlechteste gemessene Fall im ursprünglichen System lag bei 67,9 Sekunden: über eine Minute, um eine Notiz zu speichern. Heute liegt der langsamste Abschnitt des gesamten Prozesses — die Narrative, 10-15 Sekunden — nicht mehr auf dem kritischen Pfad. Der Nutzer wartet nie darauf.

Was 48 Sekunden weniger bedeuten

Prozentwerte vergisst man, aufsummierte Zeit nicht. Bei 100 Eingaben pro Tag, einem bescheidenen Volumen für ein mittelgroßes Vertriebsteam:

Das sind 26 Stunden im Monat — mehr als drei volle Arbeitstage —, die ein Team nicht mehr vor einem Bildschirm verbringt, der nicht reagiert.

Die wichtige Veränderung ist aber nicht arithmetisch, sondern eine des Verhaltens. Oberhalb von 40 Sekunden schickt man die Anfrage ab und geht: neuer Tab, ins Auto, vergessen. Unterhalb von 20 bleibt man beim Ergebnis — und wenn etwas schiefging, korrigiert man es sofort, solange man das eben geführte Gespräch noch im Kopf hat. Dieser Unterschied taucht in keinem Latenzdiagramm auf, und er entscheidet, ob die Funktion genutzt oder aufgegeben wird.

Und ein Teil steht ebenfalls nicht in der Tabelle: Wir wissen jetzt, welcher Schritt versagt, wenn etwas versagt, wir können nur diesen wiederholen, wir können das Modell eines Schritts ändern, ohne die anderen anzufassen, und wir können einen neuen Schritt ergänzen, ohne einen Prompt mit 4.000 Wörtern neu zu schreiben.

Wie die Prompts in der Praxis aussahen

Nichts davon funktioniert allein mit einer Architektur aus Kästchen und Pfeilen. Hinter jedem Schritt stecken konkrete Prompting-Techniken, und das ist der Teil, der normalerweise nicht erzählt wird. Wir können Ihnen nicht den echten Prompt des Kunden zeigen — er ist dessen Eigentum —, aber das Muster schon, und das lässt sich in jedem Projekt mit dieser Form wiederverwenden.

Vorher: ein System-Prompt mit fünf Aufgaben darin

Der ursprüngliche Prompt hatte die klassische Form des „mach alles”: eine lange Liste von Anweisungen, alle auf derselben Ebene, im Wettbewerb um dieselbe Aufmerksamkeit, mit dem Ausgabe-JSON am Ende in Fließtext beschrieben.

Du bist ein Assistent, der Vertriebsnotizen verarbeitet.

1. Erkenne alle kommerziellen Ereignisse im Text (Meeting, Angebot, Einwand, Abschluss...)
2. Klassifiziere jedes Ereignis nach Typ und Dringlichkeit
3. Baue ein JSON mit: Kunde, Opportunity, Typ, Datum, Betrag, Wahrscheinlichkeit,
   nächste Schritte, erwähnte Kontakte... (30+ Felder)
4. Schreibe eine Statusnarrative, ein Meeting-Briefing und einen Gesprächsleitfaden
5. Aktualisiere die kumulative Zusammenfassung des Kunden und der Opportunity, indem
   du sie mit der Historie zusammenführst, ohne vorherige Informationen zu verlieren

Antworte immer im JSON-Format: {...}

Generisch korrekt und sehr schwer zu pflegen. „Antworte in JSON” als Freitext zu verlangen — statt die Ausgabe per Schema zu erzwingen — führt mit einer gewissen Regelmäßigkeit zu Parsing-Fehlern, und jede Tonanpassung in Punkt 4 riskiert, Punkt 3 zu zerstören, weil beide im selben Textblock leben.

Nachher: ein Prompt, eine Aufgabe, in jedem eine andere Technik

Schritt 1 — Erkennung. Kurzer Prompt, leichtes Modell, Temperatur 0, und die Ausgabe wird per Tool Calling erzwungen, statt JSON in Prosa zu verlangen:

const result = await client.messages.create({
  model: "leichtes-modell",
  temperature: 0,
  system: "Erkenne die kommerziellen Ereignisse im Text. Nichts weiter.",
  tools: [{
    name: "erkannte_ereignisse",
    input_schema: {
      type: "object",
      properties: {
        ereignisse: {
          type: "array",
          items: {
            type: "object",
            properties: {
              typ: { enum: ["meeting", "angebot", "einwand", "abschluss"] },
              ausschnitt: { type: "string" }
            },
            required: ["typ", "ausschnitt"]
          }
        }
      },
      required: ["ereignisse"]
    }
  }],
  tool_choice: { type: "tool", name: "erkannte_ereignisse" }
});

Die Ausgabe per Schema zu erzwingen, statt „Antworte in JSON” zu verlangen, eliminiert eine ganze Fehlerkategorie an der Wurzel: schlecht geschlossenes JSON, eingeschmuggelte Kommentare, erfundene Felder, die nicht im Vertrag standen. Punkt 3 des ursprünglichen Prompts — der die meisten stillen Fehler verursachte — verschwand mit dieser einen Änderung fast vollständig.

Schritt 2 — Strukturierung. Gleiches Muster, größeres Schema, aber eine einzige Aufgabe: ein bereits erkanntes Ereignis in einen Datensatz umzuwandeln. Er entscheidet nicht, was relevant ist, und schreibt keine einzige Zeile Narrative; das hat bereits Schritt 1 gelöst und wird Schritt 5 lösen.

Schritt 5 — Anreicherung. Hier ändert sich fast alles andere: hohe Temperatur (0.7-0.8), das Hauptmodell, und ein System-Prompt, der nicht mehr um Platz mit Formatregeln konkurriert:

Du bist [die Stimme des Assistenten]. Deine einzige Aufgabe ist es, ausgehend
von diesem bereits strukturierten und validierten Datensatz eine kurze
Narrative für den Vertriebsmitarbeiter zu schreiben: was passiert ist, was
beim nächsten Schritt auf dem Spiel steht, wie man den nächsten Anruf eröffnet.

Ton: direkt, nahbar, ohne Unternehmens-Floskeln.
Erfinde keine Daten, die nicht im Datensatz stehen.

Dieser Prompt hat keine JSON-Formatregeln, keine Felddefinitionen, keine Klassifizierungslogik. Nur Ton und eine Aufgabe. Das ist der Unterschied zwischen jemanden bitten, gut zu formulieren, und jemanden bitten, gut zu formulieren, während er gleichzeitig ein Formular mit dreißig Feldern ausfüllt.

Drei Techniken, die mehr veränderten als das Redesign selbst

• Tool Calling / Structured Outputs bei jedem operativen Schritt, niemals „Antworte in JSON” als Freitext. Das ist die Änderung mit dem besten Aufwand-Nutzen-Verhältnis im gesamten Projekt: Sie verwandelt einen unvorhersehbaren Parsing-Fehler in einen Schema-Validierungsfehler, der abgefangen und wiederholt werden kann.
• Prompt-Caching des gemeinsamen Kontexts. Die Schritte 2, 3 und 4 nutzen einen Großteil desselben Kontexts wieder — das erkannte Ereignis, die Geschäftsregeln der Domäne. Diesen Block zu cachen vermeidet, ihn bei jedem der drei parallelen Aufrufe vollständig als neue Token zu bezahlen.
• Ein Evaluierungsdatensatz pro Schritt, nicht ein globaler. Bevor wir einen Prompt in Produktion anfassen, lassen wir ihn durch 20-30 Beispielfälle mit erwarteter Ausgabe für diese konkrete Phase laufen. Ohne das ist jede Prompt-Anpassung ein unkontrolliertes Experiment: Sie können die Erkennung verbessern und erst merken, dass Sie die Konsolidierung kaputt gemacht haben, wenn ein Kunde es bemerkt.

Nichts davon ist exotisch oder erfordert eine neue Bibliothek. Es ist grundlegendes Prompting — Temperatur je Aufgabe, Schema statt Prosa, gecachter Kontext, Evaluierung pro Phase — diszipliniert und schrittweise angewendet, statt in einem einzigen Textblock zusammengeworfen.

Die Regeln, die wir mitgenommen haben

Wenn Sie eine KI-Funktion haben, die in einem einzigen Aufruf zu viel erledigt, würden wir sie heute in dieser Reihenfolge angehen:

1. Trennen Sie Daten von Narrative. Das ist die lohnendste Aufteilung von allen, und es gibt sie fast immer. Operative Felder sind kurz, deterministisch und gegen ein Schema validierbar. Narrative Texte sind lang, subjektiv und profitieren von einem Prompt mit Persönlichkeit. Beides zu vermischen zwingt das Modell, mitten in der Generierung das Register zu wechseln, und verteuert jede Neugenerierung: Wenn Sie nur die Tonalität eines Briefings anpassen wollen, sollten Sie nicht die Daten erneut extrahieren müssen.

2. Schicken Sie alles in den Hintergrund, was der Nutzer nicht jetzt liest. Das Kriterium ist nicht die Wichtigkeit, sondern der Zeitpunkt des Konsums. Eine Zusammenfassung, die morgen vor einem Meeting gelesen wird, darf 20 Sekunden Generierung brauchen. Ein Wert, der beim Speichern auf dem Bildschirm erscheint, nicht.

3. Parallelisieren Sie nach echten Abhängigkeiten, nicht nach logischer Reihenfolge. Es ist leicht, die Schritte in der Reihenfolge zu verketten, in der man sie gedacht hat. Zeichnen Sie auf, was jeder Schritt wirklich braucht: Bei uns hingen drei von fünf nur vom ersten ab.

4. Nutzen Sie das günstige Modell dort, wo kein Ermessen nötig ist. Klassifizieren, erkennen und explizite Änderungen extrahieren ist mechanische Arbeit. Dafür braucht es nicht das teuerste Modell, sondern klare Anweisungen und niedrige Temperatur. Das gute Modell bleibt der Interpretation vorbehalten.

5. Fangen Sie mit Messen an, nicht mit Optimieren. Zerlegen, um zu beobachten, hat eigenen Wert, selbst wenn es die Zeiten nicht verbessert. Ohne Messwerte pro Phase ist Optimieren Raten.

Was diese Architektur kostet

Wer Ihnen Agenten-Pipelines verkauft, ohne diesen Teil zu erwähnen, verkauft Ihnen die Hälfte.

Mehr Fehlerpunkte. Fünf Aufrufe sind fünf Dinge, die in einen Timeout laufen, kaputtes JSON zurückgeben oder auf halbem Weg abbrechen können. Sie brauchen Retries pro Schritt, Schema-Validierung bei jeder Ausgabe und eine klare Regel, was passiert, wenn ein Hintergrundschritt scheitert (Wiederholen? Leer lassen? Melden?). Diesen Code gab es nicht, als alles ein einziger Aufruf war.

Wiederholte Input-Token. Jeder Schritt braucht seinen Teil des Kontexts, und mancher Kontext reist in mehreren Aufrufen mit. Die Input-Kosten steigen. Bei uns wurde das durch den Rückgang der Output-Token — die teuren — und durch Prompt-Caching mehr als ausgeglichen, aber diese Rechnung muss man aufmachen, nicht voraussetzen.

Konsistenz der Stimme. Wenn die Narrative einen eigenen Schritt bekommt, sieht dieser Schritt den vollständigen Prompt mit der ganzen Persönlichkeit des Assistenten nicht mehr. Gibt man ihm zu wenig Tonalitätskontext, wird das Ergebnis korrekt, aber blass. Wir brauchten ein paar Iterationen, um das einzustellen.

Echte Orchestrierung. Jemand muss Parallelität, Timeouts, Schreibreihenfolge in der Datenbank und den Fall verwalten, dass der Hintergrundschritt fertig wird, nachdem der Nutzer den Datensatz von Hand bearbeitet hat. Das ist normale Ingenieursarbeit, aber es ist Arbeit.

Keiner dieser Nachteile ließ uns an der Entscheidung zweifeln. Alle kosteten uns Tage, die wir für die Pflege des Monolithen nicht aufgewendet hätten.

Die wichtigste Änderung war nicht technisch

Es gibt einen Nutzen, der in keiner Metrik auftaucht und der sich mit der Zeit als der wertvollste erwies.

In einem solchen Projekt gibt es zwei verschiedene Arten von Wissen. Da ist das Wissen derjenigen, die definieren, was ein relevantes kommerzielles Ereignis ist und wie es strukturiert wird — Domänen- und Datenwissen. Und da ist das Wissen derjenigen, die definieren, wie der Assistent spricht — Produkt-, Ton- und Markenwissen. Bei einem monolithischen Prompt bearbeiten diese beiden Personen denselben Textblock mit 4.000 Wörtern und geraten sich ständig ins Gehege. Jede Tonanpassung erzwingt eine erneute Validierung der Datenextraktion, und jede Anpassung der Extraktion kann die Stimme ruinieren.

Durch die Trennung der Schritte bekommt jeder einen Verantwortlichen. Wer die Stimme definiert, iteriert am Anreicherungs-Prompt, ohne Operatives anzufassen. Das technische Team justiert die Extraktion, ohne die Persönlichkeit neu zu schreiben. Beides lässt sich getrennt versionieren, vergleichen und zurückrollen.

Anders gesagt: Wir haben aufgehört zu versuchen, dass das Modell alles macht, und angefangen zu gestalten, wie es denken soll. Und als Nebeneffekt war auch klar, wer was entscheidet.

Wie Sie das in Ihrem Projekt nachbauen

Wenn Sie am Ausgangspunkt stehen — eine KI-Funktion, die in der Demo gut und in Produktion mittelmäßig läuft — würden wir in dieser Reihenfolge vorgehen:

1. Instrumentieren Sie, bevor Sie irgendetwas anfassen. Messen Sie Latenz, Input- und Output-Token pro Anfrage. Wenn Sie nicht sagen können, wie viele Token Ihr schlimmster Fall erzeugt, kennen Sie Ihr Problem noch nicht.
2. Listen Sie die Verantwortungen des aktuellen Prompts auf. Kommen dabei mehr als drei verschiedene Verben heraus (erkennen, klassifizieren, formulieren, konsolidieren …), steckt in Ihrem Prompt eine versteckte Pipeline.
3. Zerlegen und messen, ohne zu optimieren. Akzeptieren Sie, dass die erste zerlegte Version wenig verbessert. Das Ziel ist Sichtbarkeit.
4. Zeichnen Sie den Graphen der echten Abhängigkeiten und parallelisieren Sie, was nicht voneinander abhängt.
5. Nehmen Sie alles Narrative vom kritischen Pfad und liefern Sie es nach, sobald es fertig ist.
6. Legen Sie eine Bewertung pro Schritt fest, bevor Sie weiter optimieren: eine Menge Beispieleingaben mit erwarteten Ausgaben, für jede Phase. Ohne das ist jede Geschwindigkeitsverbesserung eine Wette auf die Qualität.

Punkt 6 wird am häufigsten übersprungen und ist am teuersten. Eine modulare Architektur ohne Bewertung pro Modul ist eine modulare Architektur, von der Sie nicht wissen, ob sie funktioniert.

Nichts davon erforderte ein besseres Modell, mehr Token-Budget oder eine Agenten-Bibliothek. Es erforderte die Entscheidung, worüber das Modell in welchem Moment nachdenken soll — und diese Änderung war, gemessen, 48 Sekunden pro Eingabe wert.

Wenn Sie KI-Funktionen auf Basis von LLMs bauen und auf Antwortzeiten stoßen, die nicht zusammenpassen, oder auf einen Prompt, den im Team niemand mehr anzufassen wagt: sprechen wir darüber. Wir haben dieses Muster oft genug gesehen, um es schnell zu erkennen.

Und wenn Sie die wirtschaftliche Seite dieser Entscheidung interessiert: In was der Betrieb von LLMs in Produktion wirklich kostet schlüsseln wir Token-, Infrastruktur- und Optimierungszahlen mit aktuellen Daten auf.