Die Lücke zwischen Fähigkeit und Zuverlässigkeit
- Warum 'es hat in meiner Demo funktioniert' kein Beleg dafür ist, dass es in der Produktion funktioniert
- Fähigkeit vs. Zuverlässigkeit — sie sind verschiedene Eigenschaften, und die meisten Leitfäden verwechseln sie
- Wie Varianz eine 95-%-Aufgabe still und leise in ein kaputtes Produkt verwandelt
- Eine vierstufige Golden-Set-Eval-Schleife, die du heute mit einer Tabellenkalkulation starten kannst
- Warum Evals der eigentliche Burggraben sind — nicht Prompts
Hier ist ein Muster, das fast jeden trifft, der zum ersten Mal KI an echte Nutzer ausliefert:
Das Modell macht die Sache in deinem Test perfekt. In der Produktion versagt es. Du bist verwirrt, weil du es funktionieren gesehen hast.
Was du erlebt hast, ist die Lücke zwischen Fähigkeit und Zuverlässigkeit.
Fähigkeit bedeutet, dass das Modell eine Aufgabe erledigen kann — es produziert mindestens einmal, unter bestimmten Bedingungen, eine korrekte Ausgabe.
Zuverlässigkeit bedeutet, dass das Modell die Aufgabe konsistent korrekt erledigt — über verschiedene Inputs, über wiederholte Läufe, über leichte Änderungen in Formulierung oder Kontext hinweg.
Demos beweisen Fähigkeit. Produktion verlangt Zuverlässigkeit. Das sind verschiedene Eigenschaften, und die meisten Leitfäden verwechseln sie.
Warum Demos lügen
Wenn du einen Prompt testest, tust du typischerweise Folgendes:
- Du führst ihn auf Inputs aus, die du selbst entworfen hast
- Du führst ihn eine Handvoll Male aus
- Du pickst die Ausgabe heraus, die gut aussieht
- Du passt den Prompt an, bis er richtig aussieht
Dieser Prozess optimiert auf Fähigkeit. Der Prompt funktioniert jetzt auf deinen Beispielen. Du hast eine korrekte Ausgabe gesehen. Du lieferst aus.
Das Problem ist, dass Nutzer-Inputs in der Produktion nicht deine Beispiele sind. Sie sind unordentlicher, vielfältiger, auf Arten formuliert, die du nicht vorausgesehen hast. Das Modell wurde nie auf ihnen getestet. Du hast keine Ahnung, wie es darauf abschneidet.
Eine einzelne gute Ausgabe ist keine Leistungsschätzung. Sie ist eine Anekdote.
Varianz ist die versteckte Variable
LLMs sind stochastisch. Führe denselben Prompt zweimal aus und du bekommst oft unterschiedliche Ausgaben. Diese Varianz ist normal und meist in Ordnung. Aber sie bedeutet, dass die relevante Frage nicht lautet „hat es funktioniert?" — sondern „in welchem Anteil der Fälle funktioniert es?"
Eine Aufgabe, bei der das Modell in 95 % der Fälle erfolgreich ist, sieht in einer Demo großartig aus und bricht bei etwa einem von zwanzig Nutzern. Eine Aufgabe, bei der es in 60 % der Fälle erfolgreich ist, sieht in Ordnung aus, wenn du derjenige bist, der sie ausführt. Das sind sehr verschiedene Situationen, und du kannst sie ohne Messung nicht auseinanderhalten.
Das Fähigkeit-Zuverlässigkeit-Spektrum in der Praxis
| Dimension | Fähig, aber unzuverlässig | Zuverlässig |
|---|---|---|
| Getestete Inputs | Vom Autor entworfene Beispiele | Vielfältige, echte Nutzer-Inputs |
| Stichprobengröße | Ein paar Läufe | Wiederholte Läufe auf vielen Beispielen |
| Sichtbarkeit der Fehlermodi | Fehler sind im Test selten, in der Produktion häufig | Fehler werden gemessen und verstanden |
| Wie du erfährst, dass es kaputt ist | Nutzerbeschwerden | Deine Eval-Suite |
| Wie du es verbesserst | Prompts raten und prüfen | Bestehensrate verfolgen, Fehler systematisch debuggen |
| Deployment-Vertrauen | Bauchgefühl-basiert | Evidenz-basiert |
Evals sind der eigentliche Burggraben
Bessere Prompts können die Fähigkeit erhöhen. Nur Evals können dir sagen, ob du die Zuverlässigkeit erhöht hast.
Ein Eval ist ein strukturierter Test: eine Menge von Inputs, erwartete Ausgaben oder Bewertungskriterien und eine Möglichkeit, die Bestehensrate zu messen. Du führst das Modell auf den Inputs aus, bewertest die Ausgaben und bekommst eine Zahl. Dann änderst du etwas — den Prompt, das Modell, die Temperatur — und führst es erneut aus. Jetzt hast du ein Signal.
Das ist nicht glamourös. Es ist der Teil der KI-Produktarbeit, den die meisten Tutorials komplett überspringen. Aber es ist die einzige Möglichkeit, die Frage zu beantworten, die beim Ausliefern wirklich zählt: „Wie oft funktioniert das auf Inputs, die ich nicht gesehen habe?"
Ein einfacher Einstieg
Du brauchst keine Infrastruktur, um anzufangen. Hier ist eine minimal funktionsfähige Eval-Schleife:
- Sammle 20-50 echte oder realistische Inputs. Schreibe für jeden auf, wie eine korrekte Ausgabe aussieht (oder Kriterien, um sie zu beurteilen). Das sind deine Golden-Beispiele. Bevorzuge echte Nutzer-Inputs gegenüber erfundenen — du suchst nach der Verteilung, gegen die du noch nicht getestet hast.
- Führe deinen Prompt auf jedem Beispiel mehrmals aus (3-5 ist eine vernünftige Untergrenze). Varianz über Läufe hinweg sagt dir etwas über Prompt-Stabilität; Varianz über Beispiele hinweg sagt dir etwas über Abdeckung. Beides zählt.
- Notiere für jedes (Input, Lauf)-Paar bestanden oder nicht bestanden. Berechne die Gesamtrate. Diese eine Zahl ist der Anfang deines Zuverlässigkeitsbildes — alles andere ist Rauschen, bis du sie hast.
- Jedes Mal, wenn du Prompt, Modell oder Temperatur änderst, führe das Eval erneut aus. Sinkt die Bestehensrate, hast du etwas kaputt gemacht. Steigt sie, hast du eine echte Verbesserung erzielt — im Gegensatz zu einer Änderung, die sich auf dem einen Beispiel, das du dir angesehen hast, besser anfühlte.
Das ist alles. Eine Tabellenkalkulation reicht. Die Disziplin zählt mehr als das Tooling.
Warum das ein Engineering-Problem ist, kein Prompting-Problem
Der Instinkt, wenn ein Modell scheitert, ist, den Prompt umzuschreiben. Manchmal ist das richtig. Aber oft ist es eine Art, auf den Fehlerfall zu optimieren, den du gesehen hast, auf Kosten von Regressionen bei Fällen, die du nicht geprüft hast.
Zuverlässigkeits-Engineering für KI sieht so aus:
- Definieren, was „korrekt" bedeutet, bevor du irgendetwas ausführst
- Gegen eine repräsentative Input-Verteilung messen
- Änderungen über die Zeit mit konsistenter Methodik verfolgen
- „Dieses Modell kann diese Aufgabe nicht" von „diese Aufgabe ist unterspezifiziert" unterscheiden
Prompt Engineering ist ein Werkzeug innerhalb dieses Prozesses. Es ist kein Ersatz dafür.
Die ehrliche Einordnung
Die meisten KI-Fähigkeiten sind real. Die Modelle können wirklich bemerkenswerte Dinge tun. Die Lücke zwischen Fähigkeit und Zuverlässigkeit ist kein Argument dafür, dass die Fähigkeiten vorgetäuscht sind — sie ist ein Argument dafür, dass es nicht reicht, zu wissen, dass sie existieren.
Wenn du brauchst, dass eine Aufgabe in 95 % der Fälle funktioniert, brauchst du Belege, dass sie in 95 % der Fälle funktioniert. Diese Belege kommen aus strukturierten Tests, nicht aus dem Vertrauen in die Demo.
Die Ingenieure, die langlebige KI-Produkte bauen, sind nicht unbedingt die, die die besten Prompts schreiben. Es sind die, die wissen, was „funktionieren" bedeutet, bevor sie ausliefern, und die eine Messung haben, die ihnen sagt, ob es stimmt.
Teste dich selbst
0/3- Fähigkeit ist 'kann es das?' Zuverlässigkeit ist 'wie oft tut es das?' — Demos beweisen das Erste, Produktion verlangt das Zweite.
- Eine einzelne gute Ausgabe ist eine Anekdote, keine Leistungsschätzung. Echte Belege brauchen vielfältige Inputs, mehrfach ausgeführt.
- Varianz ist die versteckte Variable: 95 % Erfolg sieht in einer Demo großartig aus und bricht bei einem von zwanzig Nutzern.
- Starte mit einem Golden Set aus 20-50 echten Inputs, führe jeden N-mal aus, verfolge die Bestehensrate und führe es bei jeder Änderung erneut aus.
- Bessere Prompts erhöhen die Fähigkeit. Nur Evals erhöhen (und beweisen) die Zuverlässigkeit — Evals sind der eigentliche Burggraben.
Verwandt
- Dein erster API-Aufruf
- Prompting-Grundlagen
- Die Aktualitäts-Halbwertszeit
- Wenn Agenten ein Unternehmen führen — die Lücke konkret gemacht: zwei echte Experimente, in denen Frontier-Modelle ein echtes Budget bekamen.
- Agenten unter KPI-Druck — ein Benchmark, der zeigt, wie dieselbe Lücke zu Regelverstößen wird, sobald ein KPI in den Prompt kommt.
- Der Verifikations-Flaschenhals — die industrielle Version der Lücke: wenn KI Code schneller schreiben kann, als Teams ihm vertrauen können.