Ein KI-QA-/Eval-Engineer baut die Messsysteme – Testsets, Metriken, Regressions-Suiten, Human-Review-Loops –, die Ihnen sagen, ob ein KI-Feature wirklich funktioniert und nach jeder Modell- oder Prompt-Änderung weiter funktioniert. Klassische QA verifiziert deterministisches Verhalten; Eval-Engineering quantifiziert probabilistisches Verhalten – und ist zur Rolle geworden, die entscheidet, ob KI-Features shippable sind.
Was die Rolle ownt
- Goldene Testsets, die echte Nutzung repräsentieren, inklusive der hässlichen Edge Cases.
- Metriken, die auf Nutzerergebnisse mappen, nicht nur generische Accuracy-Scores.
- Regression-Gates: Keine Prompt- oder Modell-Änderung shippt, ohne die Evals zu bestehen.
- LLM-as-Judge-Pipelines, kalibriert gegen menschliche Bewertungen.
- Fehler-Taxonomien, damit aus „die KI lag falsch“ handhabbare Kategorien werden.
- Human-Review-Loops für die Fälle, die Automatisierung nicht bewerten kann.
Wie sie sich von klassischer QA unterscheidet
Klassische QA fragt: „Gibt die Funktion den richtigen Wert zurück?“ Eval-Engineering fragt: „Wie oft ist der Output über tausend unordentliche echte Inputs hinweg gut, wie schlimm sind die Fehler, und hat die Änderung von gestern es besser oder schlechter gemacht?“ Es ist statistisch, adversarial und nie fertig – allein Modell-Updates können das Verhalten verschieben, ohne dass sich eine Zeile Code ändert.
Wann Sie einen einstellen
- Ein KI-Feature ist Kern Ihres Produkts, und Qualitätsbeschwerden sind anekdotisch, nicht gemessen.
- Prompt-Änderungen shippen ungetestet, weil „es gut aussah“.
- Engineers verbringen ernsthaft Zeit damit, Outputs von Hand zu prüfen.
- Ein Modell-Upgrade hat still etwas kaputtgemacht, und Sie haben es von Nutzern erfahren.
