Vom Prompt zum Produkt: Wie aus LLMs echte Anwendungen werden

Ein Prompt, der in einem Playground funktioniert, ist ein Demo, kein Produkt. In der Lücke zwischen beiden sterben die meisten KI-Projekte leise. LLM-Anwendungen zu bauen, die echten Nutzern standhalten, hat weniger mit cleverem Prompting zu tun, als die Demos vermuten lassen, und viel mehr mit ganz gewöhnlicher Software-Disziplin. Wir haben genug davon ausgeliefert – Youp, MadaiOps und jetzt Linea –, um eine Meinung darüber zu haben, was diese Lücke tatsächlich schließt. Nichts davon ist glamourös.

Die Falle: Die erste Version fühlt sich fertig an. Man fügt einen cleveren Prompt ein, das Modell liefert etwas Beeindruckendes zurück, und es liegt nahe, das Ganze in ein UI zu verpacken und es einen Launch zu nennen. Dann kommen echte Nutzer mit Eingaben, die man sich nie vorgestellt hat, das Modell macht etwas selbstbewusst Falsches, und man stellt fest, dass man keine Möglichkeit hat zu beurteilen, ob der eigene Fix die Sache besser oder schlechter gemacht hat. Dieser Beitrag handelt vom Gerüst, das aus jenem beeindruckenden Demo etwas macht, das man in Produktion betreiben und dabei die Nacht durchschlafen kann.

Beginnen Sie mit Evals, nicht mit Prompts

Das Wirkungsvollste, was man früh aufbauen kann, ist ein Evaluations-Set. Kein Benchmark, kein Leaderboard – ein Ordner mit echten Eingaben, gepaart mit dem, wie eine gute Ausgabe aussieht. Zwanzig Beispiele schlagen null, und fünfzig kuratierte schlagen tausend zusammengekratzte.

Der Grund ist einfach. Sobald man Evals hat, hört Prompt Engineering auf, ein Bauchgefühl zu sein. Man ändert eine Zeile, lässt das Set laufen und sieht, wie sich die Zahl bewegt. Ohne Evals ist jede Änderung Aberglaube. Wir haben Teams zugesehen, die eine Woche mit der Verbesserung eines Prompts verbracht haben, nur um bei Fällen zurückzufallen, die sie Monate zuvor gelöst hatten – weil nichts die Fälle maß, auf die sie gerade nicht schauten.

Ein paar Überzeugungen, die wir fest vertreten:

Bewerten Sie Ergebnisse, nicht Formulierungen. Für alles Strukturierte – Extraktion, Klassifikation, Routing – prüfen Sie das geparste Ergebnis, nicht die String-Ähnlichkeit. Für offenen Text ist ein LLM-als-Richter mit einer engen Bewertungsrubrik in Ordnung, aber validieren Sie den Richter zuerst gegen eine Handvoll menschlicher Labels, sonst messen Sie nur den Geschmack eines Modells.
Führen Sie eine Regressions-Datei. Jeder Produktionsfehler wird zu einem dauerhaften Testfall. So bleibt Ihr Eval-Set ehrlich – es wächst genau in die Richtungen, in die die Realität drückt.
Versionieren Sie Ihre Evals gemeinsam mit Ihren Prompts. Ein Prompt ohne sein Eval-Set ist eine ungetestete Code-Änderung.

Wenn Sie aus diesem Artikel eine Sache umsetzen, dann diese. Alles Nachgelagerte hängt davon ab, die Frage beantworten zu können: Hat das die Sache besser gemacht?

Guardrails sind billiger als Entschuldigungen

Modelle versagen auf Weisen, wie es gewöhnliche Software nicht tut. Sie erfinden eine API, die nicht existiert, stimmen der falschen Prämisse eines Nutzers zu oder geben valide aussehendes JSON mit einem halluzinierten Feld aus. Guardrails sind die Schicht, die das abfängt, bevor es einen Nutzer erreicht oder – schlimmer – einen Ausführungsschritt.

Denken Sie in drei Positionen.

Input-Guardrails weisen ab oder bereinigen, bevor das Modell läuft: Prüfung auf Prompt-Injection, Schwärzung von PII, Filterung von Off-Topic-Inhalten.
Output-Guardrails validieren, was zurückkommt: Schema-Validierung, Prüfung auf Zitations-Belegbarkeit, Richtlinienfilter.
Aktions-Guardrails sitzen zwischen dem Modell und allem, was Seiteneffekte hat.

Bei der dritten Position liegt das eigentliche Risiko. In Linea, unseren Agenten für Workflow-Automatisierung, kann das Modell Aktionen vorschlagen – eine API aufrufen, einen Datensatz verschieben, eine Nachricht senden. Der Vorschlag und die Ausführung sind bewusst getrennte Schritte. Jede folgenreiche Aktion durchläuft einen typisierten Vertrag und eine Richtlinienprüfung, bevor irgendetwas läuft, und destruktive oder irreversible Aktionen erfordern ein explizites Bestätigungs-Gate. Ein Agent, der das Falsche vorschlägt, ist ein UX-Problem, an dem man iterieren kann. Ein Agent, der das Falsche tut, ist ein Vorfall. Halten Sie diese beiden Fehlermodi auf gegenüberliegenden Seiten einer harten Grenze.

Die meinungsstarke Fassung: Validieren Sie strukturierte Ausgaben gegen ein Schema und wiederholen Sie bei Fehlern, statt darauf zu vertrauen, dass das Modell konsistent ist. Und lassen Sie niemals die rohe Ausgabe eines Modells das sein, was eine irreversible Aktion auslöst. Setzen Sie immer eine deterministische Prüfung dazwischen.

Budgetieren Sie Latenz und Kosten wie Features

Latenz und Kosten sind nichts, was man am Ende misst. Sie sind Rahmenbedingungen, gegen die man von Anfang an entwirft, weil sie die Architektur verändern, nicht nur die Rechnung.

Setzen Sie explizite Budgets pro nutzerseitiger Aktion: ein p95-Latenzziel und eine Kostenobergrenze pro Aufruf. Sind diese einmal festgeschrieben, fallen die Design-Entscheidungen leichter. Ein paar Muster, zu denen wir immer wieder greifen:

Dimensionieren Sie das Modell pro Schritt richtig. Die meisten Pipelines haben ein oder zwei Schritte, die wirklich das Frontier-Modell brauchen, und mehrere, die ein kleineres, schnelleres Modell problemlos erledigt. Einfache Klassifikation an ein günstiges Modell zu routen und das teure für den harten Reasoning-Schritt zu reservieren, ist die renditestärkste verfügbare Optimierung – und sie verbessert meist auch die Latenz.
Streamen Sie das erste Token. Bei allem Konversationellen wird die wahrgenommene Latenz von der Zeit bis zum ersten Token dominiert. Eine gestreamte Antwort, die vier Sekunden braucht, fühlt sich besser an als eine blockierende, die zwei braucht.
Cachen Sie aggressiv. Prompt-Caching auf stabilem System-Kontext, gewöhnliches Ergebnis-Caching auf wiederkehrenden Eingaben. Ein nennenswerter Anteil des Produktionsverkehrs ist nahezu identisch.

Der Trade-off, den man im Kopf behalten sollte: Größere Modelle senken Ihren Engineering-Aufwand, erhöhen aber Ihre Grenzkosten und Latenz auf Dauer. Günstigere Modelle wälzen Arbeit auf Sie ab – mehr Sorgfalt beim Prompt, mehr Guardrails, mehr Evals –, aber diese Arbeit ist eine einmalige Kosten gegen eine dauerhafte Ersparnis. Bei allem mit Volumen investieren Sie das Engineering.

Halten Sie Menschen bewusst im Loop

„Human in the Loop“ wird so oft gesagt, dass es aufgehört hat, etwas zu bedeuten. Gut gemacht ist es kein Notnagel für den Fall, dass die KI versagt – es ist eine gestaltete Arbeitsteilung. Die Frage ist nicht, ob man einen Menschen einbindet, sondern wo das Urteil des Menschen mehr wert ist als die Latenz, die es hinzufügt.

Das Muster, das uns am besten gedient hat, ist die konfidenzgesteuerte Eskalation. Das System bearbeitet die zuversichtliche Mehrheit automatisch und leitet die unsichere Minderheit an eine Person weiter – mit der Begründung des Modells im Anhang, sodass der Mensch in Sekunden entscheidet, nicht in Minuten. In MadaiOps laufen Auftragsvorgänge innerhalb normaler Parameter durch; alles Anomale wird einem Operator mit Kontext vorgelegt, statt still ausgeführt zu werden. Der Prüfer hütet nicht die Maschine. Er verwendet seine Aufmerksamkeit nur dort, wo sie knapp und wertvoll ist.

Noch eine Regel: Erfassen Sie die Korrekturen des Menschen und speisen Sie sie zurück in Ihr Eval-Set und Ihre Prompts. Ein Human-in-the-Loop-System, das nicht von seinen Menschen lernt, bezahlt einfach zweimal für dieselbe Arbeit.

Wissen Sie, was Sie nicht automatisieren sollten

Das schwierigste Urteil in dieser Disziplin ist Zurückhaltung. Nicht jede Aufgabe gehört einem Modell übergeben, und Reife heißt zu wissen, welche man in Ruhe lassen sollte.

Unser grober Test: Automatisieren Sie dort, wo die Kosten eines Fehlers gering sind oder der Fehler leicht zu erkennen und umzukehren ist. Entwerfen, Zusammenfassen, Extrahieren, Klassifizieren, Routing – gute Kandidaten. Ein falscher Entwurf wird redigiert; eine falsche Zusammenfassung fällt beim Lesen auf. Seien Sie weitaus vorsichtiger, wo Fehler teuer, schwer erkennbar oder irreversibel sind: alles, was Geld bewegt, eine unwiderrufliche Kommunikation versendet oder eine juristische oder medizinische Entscheidung trifft. Dort gehört das Modell in eine unterstützende Rolle – Optionen aufzeigen, für die Prüfung entwerfen –, nicht ans Steuer.

Die Linie, an der wir festhalten: Wenn Sie nicht beschreiben können, wie Sie das Modell beim Fehler ertappen würden, sind Sie nicht bereit, diesen Schritt zu automatisieren. Die Fähigkeit, Fehler zu erkennen, ist die eigentliche Voraussetzung – mehr als die Genauigkeit. Ein zu 95 % genauer Schritt, den Sie vollständig verifizieren können, lässt sich sicherer ausliefern als ein zu 99 % genauer, den Sie nicht verifizieren können.

Die Form der Arbeit

Aus einem Prompt ein Produkt zu machen, ist überwiegend der wenig glamouröse Teil: Evals, damit man messen kann; Guardrails, damit Fehler eingedämmt bleiben; Budgets, damit es schnell und bezahlbar bleibt; Menschen dort platziert, wo Urteil zählt; und die Disziplin, manches nicht zu automatisieren. Das Modell ist vielleicht zwanzig Prozent des Systems. Die anderen achtzig Prozent sind das Engineering, das seine gelegentliche Brillanz sicher verlässlich macht.

Die gute Nachricht ist, dass dies vertraute Arbeit ist. Sie belohnt dieselben Instinkte, die gute Software jeder Art ausmachen: messen, bevor man ändert; den Explosionsradius eindämmen; die Zeit der Nutzer respektieren. Das Modell ist neu. Das Handwerk ist es nicht.