Wie wir aufgehört haben, LLMs als Black Box zu behandeln

Wer schon mal versucht hat, KI in Produktion zu bringen, kennt das Spiel. Die Demo läuft, der Prototyp ist magisch, und dann willst du das Ding zuverlässig machen und alles fällt auseinander. Hier ist, was wir nach zwei Jahren Trial and Error gelernt haben.

Der LLM Hype Cycle

Drei Jahre. Mehr nicht, seit ChatGPT gelauncht ist. Gefühlt haben wir in dieser Zeit ein Jahrzehnt KI-Evolution durchlebt. GPT-4, Claude 3, Gemini, Models mit Vision, Models mit Reasoning, Models die coden können, Models die Bilder verstehen, Models mit Million-Token Context Windows. Die Releases kommen so schnell, dass wir kaum Zeit haben, einen zu verarbeiten, bevor der nächste droppt.

Und jeder einzelne Release folgt dem gleichen Muster.

Announcement. Hype. Alle stürzen sich drauf. Dieser erste Tag des Staunens, wo du tatsächlich siehst, worauf sie hingearbeitet haben, wo du Glimpses der Zukunft erkennst. Und dann; zurück zum Alltag. Zurück zum Chat Interface. Zurück dazu, diese revolutionäre Technologie genau so zu nutzen wie vor sechs Monaten.

Wir haben jeden Monat smartere Models bekommen, aber wir nutzen sie immer noch auf die gleiche dumme Art.

Chat. Das wars. Wir schicken eine Nachricht, kriegen eine Antwort. Vielleicht chainen wir ein paar zusammen und nennen es Context. Wir behandeln diese Systeme wie Black Boxes. Prompt rein, Response raus, und irgendwo dazwischen passiert irgendeine Magie, über die wir nicht zu viel nachdenken.

Für den alltäglichen Gebrauch? Perfekt. Für Production Systems, wo Unternehmen auf konsistente, verlässliche Ergebnisse angewiesen sind? Die Black Box zerbricht.

Das Problem mit der Vorhersagbarkeit

Ich erinnere mich noch an mein erstes großes Production Deployment. Ich saß vor der CI/CD Pipeline, völlig fertig mit den Nerven. Nägel kauen, Bein wippen, Kaffee ohne Ende. Mein Senior Engineer bemerkte es und setzte sich neben mich.

"Warum bist du so nervös?", fragte er. "Hast du das nicht in QA getestet?"

"Ja, alles hat funktioniert. Aber was wenn es in Production nicht läuft?"

Er schaute mich an, als hätte ich was Offensichtliches übersehen. "Code ist das Einzige, dem wir wirklich vertrauen können. Gleicher Input, gleicher Output. Immer. Das ist nicht wie bei Menschen. Es ist deterministisch. Du lässt den gleichen Code laufen, du kriegst das gleiche Ergebnis, jedes einzelne Mal."

Dieses Prinzip hat alles geleitet, was ich sechs Jahre lang gebaut habe. Code ist vorhersagbar. Du kannst dich drauf verlassen. Einmal testen, es funktioniert genauso in Production. Debuggen, fixen, vertrauen. Keine Überraschungen. Keine Kreativität. Keine Varianz. Nur purer, wunderschöner Determinismus.

Dann kamen LLMs und haben diese Annahme zerstört.

Plötzlich hatten wir Systeme, die mächtig aber unberechenbar waren. Flexibel aber inkonsistent. Smart aber unzuverlässig. Alles, was uns Software Engineering beigebracht hatte zu vermeiden.

Im Kern sind LLMs dafür designed, menschlich zu sein. Neural Networks sind buchstäblich nach unseren Gehirnen modelliert. Sie imitieren menschliche Sprachgenerierung, was bedeutet, dass sie menschliche Unberechenbarkeit erben. Gleiche Frage zweimal stellen? Unterschiedliche Antworten. Ein Wort in deinem Prompt ändern? Komplett andere Response.

Für kreative Arbeit ist das perfekt. Für Production Systems, die tausende Male am Tag laufen müssen? Ein Albtraum.

Denk an eine simple Datenbankoperation: "Update die ID für Rahul in NY, Zip 10001, zu ID Z."

Mit traditionellem Code schreibst du eine deterministische Funktion. Query mit exakten Parametern, Person finden, Feld updaten, Erfolg zurückgeben. Es ist idempotent. Lauf es einmal oder hundert Mal, gleiches Ergebnis. Konsistent. Vorhersagbar.

Mit einem LLM? Du erwartest, dass es natürliche Sprache versteht, Datenstrukturen parst, Feldbeziehungen begreift, korrekt filtert und das Update ausführt. Selbst wenn es 99 von 100 Mal funktioniert, ist diese 1% Fehlerrate inakzeptabel. In Production Systems ist "meistens korrekt" nicht gut genug.

Selbst simple Tasks scheitern. Bitte ein LLM, Text unverändert zurückzugeben, und es wird paraphrasieren oder "verbessern". Weil es genau dafür trainiert wurde.

Das ist die zentrale Spannung. LLMs sind mächtig, weil sie flexibel und menschlich sind. Aber Production Systems brauchen sie starr und maschinengleich.

Also, wenn LLMs von Natur aus unberechenbar sind und Production Vorhersagbarkeit braucht, stecken wir dann fest? Nein. Aber die Lösung erfordert, dass wir komplett umdenken.

Die Lösung: Hör auf, LLMs ausführen zu lassen

Hier ist der Shift, der alles verändert hat. Frag das LLM nicht, die Arbeit zu machen. Frag es, dir zu sagen, welche Arbeit gemacht werden muss.

Statt das LLM als Executor zu behandeln, behandle es als Interpreter. Sein Job ist nicht, Daten zu manipulieren. Es soll Intent verstehen, das auf strukturierte Operationen mappen und deinem deterministischen Code sagen, was er ausführen soll.

Wir nennen diese Operationen Tools.

Ein echtes Beispiel: Text Formatting

User wollten Formatierung mit natürlicher Sprache anwenden. "Mach das Wort hello fett." "Ändere die Überschrift auf 18pt."

Der Black Box Ansatz: Schick dem LLM allen Text und alle Formatierungsdaten, bitte es, die modifizierte Version zurückzugeben.

Für simple Fälle hat es funktioniert. Dann haben wir über 20 Attribute hinzugefügt. Farben, Schriftarten, Abstände, Margins, Absatzumbrüche, Initialen.

Success Rate: Von 90% runter auf 30%.

Die Fehler waren bizarr.

• Hat "hello" fett gemacht, aber random anderen Text verändert.

• Formatierung gefixt, aber die Datenstruktur kaputt gemacht.

• Formatierungsoptionen halluziniert, die gar nicht existierten.

• Manchmal einfach Müll zurückgegeben.

Warum? Wir haben es gebeten, fünf Dinge gleichzeitig zu tun. Natürliche Sprache verstehen, check  (✓). Komplexe Strukturen parsen, fail (✗),. Feldbeziehungen verstehen, fail (✗),. Daten sorgfältig modifizieren, fail (✗),. Validen Output generieren, fail (✗).

Fünf Jobs. Nur bei einem gut.

Der Tools Fix

Wir haben spezifische Tools für jede Operation erstellt.

• make_bold(text)

• change_font_size(text, size)

• change_color(text, color)

• insert_paragraph_break(after_sentence)

Jetzt, wenn ein User sagt "Mach das Wort hello fett":

Job des LLM:
- Den Request verstehen. 
- Das richtige Tool picken, also make_bold(). 
- Zurückgeben: {tool: "make_bold", text: "hello"}

Job unseres Codes:
- "hello" im Dokument finden. 
- Formatierung mit getestetem Code anwenden. 
- Validieren, dass alles korrekt ist.

Das LLM ging von fünf schwierigen Dingen zu einem einfachen Ding. Intent verstehen.

All der harte Kram; Parsing, Struktur, Encoding; wird von regulärem Code gehandelt, den wir testen und dem wir vertrauen können.

Die Ergebnisse

Technische Metriken:

• Success Rate von 30% auf über 95%.

• Fehler wurden vorhersagbar und abfangbar.

• Character Encoding Probleme verschwunden.

• Features hinzufügen ging von Tagen zu Stunden.

Business impact:

• Support Tickets von circa 40 pro Tag auf circa 5 pro Tag.

• Konnten endlich an Enterprise Kunden shippen (verlangen Zuverlässigkeit).

• Development Velocity gestiegen; neue Formatierungsoptionen brauchten eine Stunde statt eine Woche.

• Das Feature ging von "interessanter Prototyp" zu "Core Product Capability".

Das zentrale Muster

Das ist kein Prompt Engineering. Es ist ein architekturelles Pattern.

1. Interpretation, nicht Execution. Das LLM versteht Intent, fasst keine Daten an.

2. Structured Output. Das LLM gibt Tool Calls zurück, keine rohen Modifikationen.

3. Validation. Dein Code validiert vor dem Ausführen.

4. Testability. Tools sind unabhängig testbar.

5. Debuggability. Du weißt exakt, was aufgerufen wurde und warum.

Wir haben das überall angewandt. Natural Language Database Queries, Bildgenerierung, Datentransformationen. Gleiches Pattern, gleiche Zuverlässigkeitsgewinne.

Wenn du neue Fähigkeiten brauchst, musst du keine Models retrainen oder komplexe Prompts schreiben. Du fügst einfach ein Tool hinzu. Das LLM lernt es aus dem Context.

Die zentrale Erkenntnis: Du machst LLMs nicht vorhersagbar, indem du sie einschränkst. Du machst Systeme vorhersagbar, indem du einschränkst, wofür LLMs verantwortlich sind.

Wenn du mit LLMs baust

✓ Definiere deine Tools zuerst. Bevor du Prompts schreibst, liste auf, welche Operationen dein System braucht. Wenn du es nicht als Funktion mit klaren Inputs und Outputs definieren kannst, bist du noch nicht bereit für KI.

✓ Gib dem LLM weniger Verantwortung. Nur Interpretation. Kein Parsen, Validieren, Ausführen, Error Handling.

✓ Mach Tools granular. make_bold() schlägt apply_formatting(). LLMs wählen besser zwischen 20 spezifischen Tools als drei komplexe zu konfigurieren.

✓ Validiere alles. Das LLM hat ein Tool aufgerufen? Die Parameter könnten falsch sein. Prüf sie. Scheitere sicher.

✓ Design für Fehler. Tools werden falsch aufgerufen werden. Scheitere graceful mit klaren Fehlermeldungen, nicht mit stiller Datenkorruption.

Die eigentliche Lektion

Mein Senior Engineer hatte recht. Code ist vorhersagbar. LLMs sind es nicht.

Wir haben zwei Jahre damit verbracht, LLMs vorhersagbar zu machen, indem wir sie smarter gemacht haben. Die echte Antwort war simpler. Mach sie für weniger verantwortlich.

Der Durchbruch für Production KI wird nicht von smarteren Models kommen. Er wird von besserer Architektur kommen. Von Teams, die verstehen, dass KI ein Übersetzer zwischen menschlichem Intent und deterministischem Code ist. Kein Ersatz für Engineering.

Das Ziel ist nicht, deterministische Systeme durch KI zu ersetzen. Es ist, ihnen ein Natural Language Interface hinzuzufügen.

So machst du KI vorhersagbar. Nicht indem du sie smarter machst, sondern indem du sie für weniger verantwortlich machst.

---

Versuch diese Woche: Nimm ein KI Feature, das unzuverlässig ist. Schreib keinen Code. Liste nur auf, welche Tools es bräuchte. Schreib die Function Signatures. Was würde vorhersagbar machen für dein System bedeuten?