KI-Demos sehen in Woche eins und Woche neun gleich aus. Das System in Produktion tut das nie. Die Brücke zwischen beiden, der Teil, den die meisten Teams erst nach dem verschobenen Launch entdecken, ist eine Eval-Harness: ein deterministisches Testset für ein nicht-deterministisches System. Zuerst gebaut, ist sie die billigste Position im Projekt. Zuletzt gebaut, ist sie der Grund, warum das Projekt sechs Wochen zu spät kommt.

Die Demo-Falle.

Jedes KI-Engagement, das wir je auditiert haben, hatte in Woche drei dieselbe Form: eine schöne Demo, ein lächelnder Stakeholder, und ein privates Sheet, in dem jemand jeden seltsamen Output notiert, den er gesehen hat. Die Demo besteht, weil die Demo ein Input ist. Produktion scheitert, weil Produktion zehntausend Inputs sind, und niemand hat aufgeschrieben, was «gut» heisst.

Das Muster wiederholt sich: ein Sales-Copilot, der für die Top fünf Accounts wunderbar formuliert und bei den nächsten fünfzig halluziniert; ein CRM-Anreicherungsagent, der börsennotierte Firmen trifft und bei privaten rät; eine Customer-Support- Zusammenfassung, die meistens funktioniert ausser bei den Tickets, die eine Eskalation brauchen.

«Ein KI-System ohne Evals ist eine Stimmung. Eine Stimmung ist kein Produkt.»

Was eine Eval-Harness wirklich ist.

Eine Eval-Harness ist die Antwort auf die Frage: ist diese Version besser oder schlechter als letzte Woche? Sie besteht aus einer Sammlung realer Eingaben (Fixtures), einer geschriebenen Definition von «gut» (Rubrik), und einem Skript, das beides zusammenführt und eine Zahl ausgibt, die zwischen Releases vergleichbar ist. Das Artefakt überlebt Modellwechsel, Prompt-Refactors, und Retrieval-Umbauten unverändert.

Die drei Schichten.

Jede funktionierende Eval-Harness hat drei Schichten. Lässt man eine weg, wird die Harness zum Schmeichler statt zum Schiedsrichter.

  1. Fixtures. Ein kuratierter Datensatz aus echten Inputs, beschriftet mit dem, was ein guter Output aussieht. 50 bis 200 Beispiele reichen zum Start. Aus echtem Traffic, nicht aus erfundenen Personas. Wer keine Fixtures produzieren kann, versteht das Problem noch nicht und jedes KI-System wird diese Lücke widerspiegeln.
  2. Rubrik. Die geschriebene Definition von «gut». Manchmal deterministisch (parst das JSON, matcht der Function Call das Schema), manchmal LLM-geprüft (trifft der Draft den Briefing-Ton), gelegentlich von Menschen bewertet. Versioniert zusammen mit dem Prompt.
  3. Regression Gates. Eine Baseline-Zahl pro Metrik bei jedem Release. Eine neue Version geht nur live, wenn keine Metrik unter eine definierte Toleranz fällt. Das einzige Artefakt, das verhindert, dass Donnerstag-um-zwei-Uhr-morgens- Rollbacks zur Routine werden.

Die Harness zuerst bauen.

Die Reihenfolge zählt. Erst die Fixtures, dann die Rubrik, dann die Pipeline. Wer den Agent zuerst baut und die Evals nachholt, biegt die Evals unbewusst dorthin, wo der Agent gerade steht. Das Resultat ist eine Harness, die das System sehr gut bestätigt und die Probleme verfehlt, die wirklich da sind.

Drei Fehler, die wir immer wieder sehen.

  1. Imaginierte Personas statt echtem Traffic. Die Fixtures sind erfunden, die Harness bestätigt sich selbst, die Produktion bricht an genau den Inputs, die niemand bedacht hat.
  2. Der Grader-Modell-Drift. Das LLM, das gradet, ist nicht gepinnt. Der Anbieter aktualisiert es still. Die Scores verschieben sich, ohne dass im Workflow etwas geändert hätte. Das Team jagt eine Verbesserung, die ein Mess-Artefakt ist.
  3. Die manuelle Override-Klappe. Ein Release schlägt das Gate, das Team entscheidet einmal, «es trotzdem laufenzulassen». Innerhalb von zwei Releases ist das Gate Theater.

Eine Feldcheckliste.

Wenn der Engineering-Lead Ihnen das Eval-Skript und die Tabelle vom letzten Release nicht zeigen kann, ist das KI-System nicht shipping-bereit. Es läuft nur.

Häufige Fragen.

Wie viele Fixtures brauchen wir zum Start? 50 bis 200 Beispiele aus echtem Traffic. Qualität schlägt Menge. Holdout- Set strikt vom Trainingsset trennen.

Wer schreibt die Rubrik? Engineering und Operator gemeinsam, in einer Sitzung. Beide unterschreiben. Ohne gemeinsame Definition von «gut» gibt es keine gemeinsame Definition von Fortschritt.

Wie kommt das Regression Gate in CI? Als Check auf jedem PR. Aktuelle Scores gegen die letzte grüne Baseline. Toleranz pro Metrik. Bei Überschreitung schlägt der Check fehl, der PR wird nicht gemergt. Keine Ausnahmen.

Vollständige englische Fassung mit Beispielcode: Eval-driven AI · the only kind that ships. Die zugehörige Spezifikation: The Morvion Eval Spec.

Diese deutschsprachige Fassung ist eine eigenständige Übersetzung der englischen Ausgabe. Read the English original ›