LLMs im Produktivbetrieb: Mythen und Realitäten im Jahr 2026

Warum fast alles, was dir über LLMs in der Produktion erzählt wurde, nur die halbe Wahrheit ist

Ich habe Teams gesehen, die sechs Monate Arbeit weggeworfen haben, weil sie zwei gegensätzliche Annahmen für bare Münze genommen haben: dass ein LLM wie ein REST-Endpunkt funktioniert und es ausreicht, ihn einfach zu starten, oder dass er so unvorhersehbar ist, dass es sich nicht lohnt, ihn aus dem Labor zu holen. Keine von beiden hält dem Kontakt mit echtem Traffic stand. Laut der offiziellen Dokumentation der wichtigsten Modellanbieter variieren Latenz, Kosten und Qualität nicht linear mit dem Kontext, der Temperatur und der Antwortlänge, und das bricht viele der Versprechen, die in Vorträgen und Posts kursieren.

Dieser Artikel geht die Mythen durch, die beim Bringen von Sprachmodellen in die Produktion am meisten Schaden anrichten, und stellt sie dem gegenüber, was passiert, wenn das System echte Nutzer bedient: Wiederholungsversuche, fehlerhaft formatierte Prompts, sensible Daten und Lastspitzen. Es gibt keine Garantien für Ergebnisse: Es gibt Muster, die in bestimmten Kontexten funktionieren, und andere, die kläglich scheitern.

Mythos 1: „Der perfekte Prompt macht Engineering überflüssig»

Der Prompt ist wichtig, aber er ersetzt nicht die Architektur. Ein Team, mit dem ich zusammengearbeitet habe, baute einen Support-Assistenten, der in manuellen Tests präzise antwortete. In der Produktion versagte derselbe Prompt, sobald die Nutzer anfingen, in Großbuchstaben zu schreiben, mit Fehlern oder indem sie Screenshots einfügten, die von einer fehlerhaften OCR transkribiert worden waren. Die Rate nützlicher Antworten sank, ohne dass sich das Modell geändert hatte.

Was tatsächlich funktioniert

• Eingabevalidierung: Text normalisieren, Länge begrenzen und die Sprache erkennen, bevor das Modell aufgerufen wird.
• Ausgabekontrakte: JSON mit einem Schema verlangen und es mit einer Bibliothek validieren; bei Fehlschlag mit einem begrenzten Korrektur-Prompt erneut versuchen.
• Deterministischer Fallback: Für häufig auftretende Anfragen können eine Vorlage oder Regeln besser und günstiger antworten als das Modell.

Die Realität ist, dass der Prompt ein Baustein des Systems ist, nicht das System. Reife Teams versionieren Prompts wie Code, evaluieren sie mit Testsätzen und messen Regressionen, bevor sie deployen.

Mythos 2: „Mehr Kontext verbessert immer die Antwort»

Ein großes Kontextfenster ist nützlich, aber nicht kostenlos. Laut der Dokumentation der Anbieter wachsen Kosten und Latenz mit den Eingabe-Tokens, und in der Praxis verbessert sich die Qualität nicht monoton: Zehn irrelevante Dokumente einzufügen verwässert das Signal und erhöht die Wahrscheinlichkeit, dass das Modell Randinformationen zitiert.

Konkretes Fehlerbeispiel

In einer internen Suche über technische Dokumentation verbesserte der Wechsel von 3 auf 15 abgerufene Fragmente die Abdeckung korrekter Antworten bei breiten Fragen, verschlechterte aber die Antworten auf Detailfragen, weil das richtige Fragment unter anderen ähnlichen begraben wurde. Die Lösung war nicht, den Kontext zu erweitern, sondern das Ranking des Abrufs zu verbessern und sich auf die Fragmente mit der höchsten Punktzahl zu beschränken, mit einer Abschneideschwelle.

Grenzen, die man anerkennen sollte

Es gibt keine magische Anzahl von Fragmenten. Sie hängt von der Domäne, der Qualität des Index und der Art der Frage ab. Wer behauptet „verwende immer top-k=5″, vereinfacht. Man muss es mit einem eigenen Evaluationssatz messen.

Mythos 3: „Das Modell ist deterministisch, wenn ich Temperatur 0 setze»

Temperatur 0 reduziert die Variabilität, beseitigt sie aber nicht bei allen Anbietern oder allen Modellen. Außerdem verbirgt die scheinbare Determinismus noch eine andere Variationsquelle: stille Änderungen am gehosteten Modell. Derselbe Bezeichner kann aktualisiert werden und Antworten verändern, worauf die Dokumentation mehrerer Anbieter ausdrücklich hinweist.

Praktische Konsequenzen

• Konkrete Versionen festlegen, wenn der Anbieter es erlaubt.
• Einen Regressionstestsatz pflegen, der nach jeder Versionsänderung ausgeführt wird.
• Die Modellversion zusammen mit jeder Antwort protokollieren, um auditieren zu können.

Wenn dein Produkt davon abhängt, dass die Ausgabe zwischen Ausführungen identisch ist, ist ein LLM nicht das richtige Werkzeug für diesen Teil. Dort ist deterministische Logik angebracht.

Mythos 4: „Es kostet wenig, weil das Token billig ist»

Die Kosten pro Token scheinen niedrig, bis man sie mit Nutzern, Wiederholungsversuchen und Kontext multipliziert. Ein Muster, das ich häufig sehe: ein Chatbot, der bei jedem Aufruf den vollständigen Gesprächsverlauf mitschickt. Bei Gesprächen mit zwanzig Turns wachsen die Kosten quadratisch mit der Anzahl der Turns, nicht linear.

Was man tun kann

• Den alten Verlauf zusammenfassen und nur die letzten relevanten Turns behalten.
• Antworten für wiederholte Fragen cachen, wenn die Domäne es erlaubt.
• Einfache Anfragen an kleine Modelle weiterleiten und die großen für komplexe Fälle reservieren.
• Ausgabenlimits pro Nutzer oder pro Sitzung setzen.

Es gibt keine universelle Sparformel. Jede Zahl, die ohne Kontext zu Traffic und Kontextlänge geteilt wird, ist anekdotisch. Was jedoch konsistent ist: Ohne Observability der Eingabe- und Ausgabe-Tokens geraten die Kosten außer Kontrolle.

Mythos 5: „Wenn es in der Demo funktioniert, ist es bereit für die Produktion»

Die Demo zeigt den glücklichen Pfad. Die Produktion ist der unglückliche Pfad: leere Eingaben, Versuche von Prompt-Injection, Nutzer, die Dinge außerhalb des Geltungsbereichs verlangen, Ausfälle des Anbieters und Wartezeiten. Laut Branchenstudien zur Zuverlässigkeit von Diensten sind Ausfälle externer Abhängigkeiten eine häufige Ursache für Vorfälle, und ein LLM ist eine weitere externe Abhängigkeit.

Minimale Checkliste, bevor man es Nutzern aussetzt

1. Timeouts und Wiederholungsversuche mit exponentiellem Backoff, mit begrenzter Anzahl an Versuchen.
2. Circuit Breaker, um den Anbieter bei Ausfällen nicht zu bombardieren.
3. Klare Degradationsmeldungen, wenn das Modell nicht verfügbar ist.
4. Ein- und Ausgabefilter für personenbezogene Daten und schädliche Inhalte.
5. Trace-Protokollierung mit Prompt, Antwort, Latenz und Kosten, mit definierter Aufbewahrungsfrist.

Nichts davon ist glamourös, aber es ist das, was einen Prototyp von einem Dienst trennt, der einen Montagmorgen übersteht.

Mythos 6: „Die Evaluation lässt sich mit guten automatischen Metriken lösen»

Automatische Metriken wie BLEU oder ROUGE korrelieren schwach mit dem wahrgenommenen Nutzen bei offenen Aufgaben. Für ein Datenextraktionssystem mit festem Schema funktioniert eine Genauigkeitsmetrik. Für einen konversationellen Assistenten nicht.

Was in der Praxis funktioniert

• Ein kleiner, aber repräsentativer Evaluationssatz, überprüft von Personen aus der Domäne.
• Paarweise Bewertung oder Rubriken für subjektive Aufgaben.
• Regelmäßige Stichproben echter Antworten, um Drift zu erkennen.

Ich erkenne eine Einschränkung an: Diesen Satz aufzubauen und zu pflegen kostet Zeit und skaliert nicht so gut wie ein automatisches Skript. Aber ohne ihn ist jede Aussage über die Qualität des Systems eine Meinung.

Mythos 7: „Datenschutz löst man mit einem rechtlichen Hinweis»

Nutzerdaten an einen externen Anbieter zu senden hat Implikationen, die ein Hinweis nicht löst. Man muss wissen, was gesendet wird, wie lange es aufbewahrt wird und in welcher Jurisdiktion es verarbeitet wird. Manche Teams entdecken spät, dass sie E-Mails und Telefonnummern in die Prompts aufgenommen hatten, weil das Ursprungsformular sie ungefiltert erfasste.

Konkrete Maßnahmen

• Bezeichner pseudonymisieren, bevor der Prompt erstellt wird.
• Definieren, welche Felder das System niemals verlassen.
• Die Aufbewahrungsbedingungen des Anbieters prüfen und bei Bedarf Deployments nutzen, die keine Daten speichern.

Dies ist keine Rechtsberatung, und man sollte sich mit der zuständigen Stelle beraten. Aber technisch gesehen ist Filtern vor dem Senden günstiger als Nachbessern danach.

Mythos 8: „Ein LLM ersetzt das Support- oder Content-Team»

Es kann die Last bei repetitiven Aufgaben reduzieren, führt aber einen Überwachungsaufwand ein. Ein Modell, das selbstsicher zu Themen antwortet, die es nicht beherrscht, erzeugt mehr Arbeit, als es einspart. In Kundenservice-Projekten bleibt die menschliche Prüfung von Antworten mit geringer Konfidenz weiterhin notwendig, um kostspielige Fehler zu vermeiden.

Die Realität ist langweiliger: Das LLM ist ein Werkzeug innerhalb eines Ablaufs, mit Menschen an den Risikopunkten. Die Fälle, in denen es ohne Aufsicht funktioniert, sind die mit geschlossenem Schema und geringen Fehlerfolgen, wie das Klassifizieren von Tickets oder das Zusammenfassen interner Texte.

Was man vor dem Start annehmen sollte

• Du wirst Observability vom ersten Tag an brauchen, nicht erst später.
• Die tatsächlichen Kosten versteht man, wenn Traffic da ist, nicht im Labor.
• Die Qualität misst man mit eigenen Daten, nicht mit öffentlichen Benchmarks.
• Es wird Änderungen beim Anbieter geben, die dein Produkt betreffen, ohne dass du etwas anfasst.
• Manche Aufgaben sollten nicht mit einem LLM gelöst werden: exakte Berechnungen, strenge regulatorische Compliance oder Entscheidungen mit irreversiblen Folgen.

LLMs in der Produktion zu implementieren ist weniger Magie und mehr Engineering-Disziplin: Versionierung, Evaluation, Grenzen und kontrollierte Degradation. Die Mythen verkaufen Abkürzungen; die Realität verlangt, zu messen, bevor man verspricht.