• llm
• prompt-engineering
• retrieval
• optimierung

Als wir begonnen haben, lange Texte ueber eine LLM-Pipeline zu erzeugen, sah das Hauptproblem zuerst nach Modellqualitaet aus. In der Praxis war es vor allem Systems Engineering: Request-Groesse, Latenzvarianz, Proxy-Timeouts und unbegrenzter Output.

Dieser Bericht fasst zusammen, was unter produktionsnahen Bedingungen funktioniert hat, wenn die Ziele waren:

• Lange Texte zuverlaessig erzeugen,
• Tokenverbrauch vorhersagbar halten,
• Timeout-Risiko senken,
• Qualitaet ueber mehrere Abschnitte erhalten.

1) Warum Single-Shot-Prompting scheiterte #

Der naive Ansatz war ein grosser Request mit vollem Quelltext plus viel Kontext. Das fuehrte zu drei Problemen:

• Hohe Input-Token-Kosten bei jedem Lauf,
• Hohe Latenzvarianz je nach Promptlaenge und Modelllast,
• Gateway-504s, obwohl das Modell spaeter noch eine Antwort lieferte.

Zentrale Erkenntnis: Eine erfolgreiche Modellantwort ist wertlos, wenn eine vorgelagerte Komponente vorher in den Timeout laeuft. Zuverlaessigkeit muss auf Pipeline-Ebene entworfen werden, nicht nur auf Modell-Ebene.

2) Architektur, die lange Texte stabil gemacht hat #

Wir sind von One-Shot-Generierung auf eine begrenzte, mehrstufige Pipeline gewechselt.

Stufe A: Retrieval-Kontext mit strikten Budgets #

Statt alles verwandte Material mitzuschicken, haben wir:

• Quelltexte in absatzbasierte Segmente gechunkt,
• Embeddings einmal erzeugt und gecacht,
• Pro Request nur die relevantesten Chunks gewaehlt,
• Harte Limits gesetzt: Gesamtzahl Chunks, Chunks pro Datei, Snippetlaenge und Retrieval-Zeichenbudget.

Das reduzierte wiederholte Tokenverschwendung und machte Requests vorhersagbarer.

Stufe B: Adaptives Input-Budgeting #

Vor jedem Modellaufruf berechnen wir ein dynamisches Budget aus:

• Aktueller Inhaltslaenge,
• Promptlaenge,
• Erwartetem Overhead des Systemprompts.

Wenn der Input das Budget ueberschreiten wuerde:

• Zuerst Retrieval-Kontext reduzieren,
• Dann Hauptinhalt mit kontrollierter Middle-Trim-Strategie kuerzen,
• Kopf und Ende behalten, damit Einleitung und Schlusskontext erhalten bleiben.

Das liefert bessere Qualitaet als harte Abschneidung nur von einer Seite.

Stufe C: Segmentierte Generierung fuer grosse Texte #

Bei grossen Dokumenten verzichten wir auf Single-Pass-Generierung.

Ablauf:

• Text in ueberlappende Segmente aufteilen,
• Jedes Segment separat mit kleinerem Max-Output ueberarbeiten,
• In Originalreihenfolge zusammenfuehren,
• Einen finalen Konsistenz-Pass ueber den Gesamttext laufen lassen.

So wird aus einem fragilen Grossaufruf eine Reihe robusterer Kleinaufrufe.

Stufe D: Konsistenz-Pass #

Nach dem Zusammenfuehren laeuft ein kurzer globaler Pass mit Fokus auf:

• Terminologiekonsistenz,
• Tonalitaetsabgleich,
• Stilharmonisierung.

Wichtig ist hier regelbasiertes Prompting: kein neuer Inhalt, kein strukturelles Umschreiben, keine Meta-Kommentare.

3) Token- und Latenz-Kontrollen mit groesster Wirkung #

Diese Kontrollen hatten den groessten Effekt:

• Max-Output-Tokens pro Aufruf, angepasst an die Input-Groesse,
• Reduziertes Retrieval-Budget bei groesseren Dokumenten,
• Weniger Retrieval-Chunks bei sehr grossen Inputs,
• Segmentmodus oberhalb einer Inhalts-Schwelle,
• Verkuerzter Retrieval-Kontext waehrend Segmentaufrufen,
• Persistenter Embedding-Cache mit Content-Hash als Schluessel.

Der Cache ist kritisch. Ohne ihn bezahlt ein Long-Form-Workflow Embedding-Kosten immer wieder und verliert den Grossteil des Effizienzgewinns.

4) Betriebskontrollen und Observability #

Wir haben strukturiertes Logging rund um jede Stufe eingefuehrt:

• Request-Metadaten: model, input_chars, context_chars, max_tokens, timeout,
• Retrieval-Metadaten: Cache-Hits, neu eingebettete Dateien, ausgewaehlte Chunks, Laufzeit,
• Segment-Metadaten: Segmentanzahl, Output-Groesse je Segment, Status des Konsistenz-Passes,
• Outcome-Metadaten: Quellmodell, Fallback-Grund, Laufzeit pro Datei.

Dadurch wurde Debugging von Bauchgefuehl zu messbarem Tuning.

Wenn Aufrufe exakt an der Timeout-Grenze scheiterten, war klar: lokales oder clientseitiges Timeout-Verhalten, nicht mangelnde Modellqualitaet.

5) Praktisches Implementierungsmuster #

Eine einfache Implementierungsstrategie fuer Entwickler:

• Limits aus Inhalts- und Promptlaenge vorab berechnen,
• Retrieval-Kontext innerhalb dieser Limits aufbauen,
• Bei Ueberschreiten der Schwelle Segmentmodus aktivieren,
• Fuer jeden Modellaufruf Max-Output-Tokens setzen,
• Zusammenfuehren und optional Konsistenz-Pass ausfuehren,
• Vorschlag plus Metadaten fuer Observability und Retries persistieren.

Pseudo-Flow:

compute limits
retrieval_context = bounded_retrieval(...)
if segmented_mode:
  segments = split_with_overlap(...)
  revised_segments = map(revise_segment)
  merged = join(revised_segments)
  final = consistency_pass(merged)
else:
  final = revise_single_pass(...)
store result with source and error metadata

6) Trade-offs und worauf man achten sollte #

Segmentmodus verbessert Zuverlaessigkeit und Kostenkontrolle, kann aber Merge-Artefakte erzeugen, wenn die Ueberlappung zu klein ist. Eine kurze Ueberlappung plus Konsistenz-Pass loest das meist.

Zu aggressives Trimming senkt die Qualitaet. Immer erst Retrieval kuerzen, dann erst bei Bedarf den Hauptinhalt.

Zu hoher Max-Output erhoeht das Timeout-Risiko, zu niedriger verursacht abgeschnittene Antworten. Besser dynamische Baender nach Input-Groesse statt eines festen Werts.

7) Empfohlene Defaults fuer den Start #

• Segment-Schwelle: etwa 26k Zeichen,
• Segmentgroesse: etwa 5k Zeichen mit 300-350 Ueberlappung,
• Retrieval-Budget: hoeher bei kleinen Dokumenten, niedriger bei grossen,
• Max-Output-Tokens: niedriger bei kleinen Dokumenten, moderat bei grossen, aber gedeckelt,
• Timeout: Modell-Timeout ueber der durchschnittlichen Antwortzeit, Gateway-Timeout ueber dem Modell-Timeout.

Zentrales Fazit #

Long-Form-LLM-Generierung mit niedrigen Token-Kosten ist primaer ein Pipeline-Design-Problem, kein Prompt-Trick. Das erfolgreiche Muster ist:

• Weniger, aber besseres Retrieval,
• Aggressives Input-Budgeting,
• Segmentierung grosser Arbeitspakete,
• Output-Caps,
• Vollstaendige Instrumentierung.

Diese Kombination liefert niedrigere Kosten, weniger 504s und besser vorhersagbare Qualitaet fuer reale Engineering-Workflows.