---
title: "KI-Evaluation: das Verhalten testen, das tatsächlich ausgeliefert wird"
description: "Published Arne Kellmann website information and agent integration guidance."
canonical: https://arnekellmann.de/de/ki-evaluation
last-updated: 2026-09-26
---

# KI-Evaluation: das Verhalten testen, das tatsächlich ausgeliefert wird

Echte Aufgaben als Evaluationsgrundlage nutzen, Fehlerverhalten prüfen und Qualität, Latenz sowie Kosten vergleichen. Mit eigenen Replay- und Prompt-Injection-Studien.

## Eine brauchbare Antwort definieren, bevor Modelle verglichen werden

Eine gültige JSON-Antwort kann trotzdem die falsche Entscheidung enthalten. Formatprüfung und die für den Nutzer relevante Bewertung sollten getrennt werden. Eingabe, verfügbarer Kontext und erwartetes Verhalten werden dokumentiert — auch für Fälle, in denen das System keine Antwort geben sollte.

Den Anfang machen repräsentative Aufgaben und bekannte Fehler. Ein zurückgehaltener Datensatz dient der Release-Entscheidung, damit wiederholtes Prompt-Tuning nicht nur auf bereits bekannte Beispiele optimiert.

## Grenzen ebenso prüfen wie den Erfolgsfall

Ein Evaluationsdatensatz braucht ausdrücklich definierte Fehlerfälle. Nicht akzeptable Ergebnisse werden vor dem Lauf festgelegt; die Belege zu jedem Ergebnis bleiben erhalten.

| Fall | Was geprüft werden sollte |
| --- | --- |
| Fehlende oder widersprüchliche Belege | Benennt das System Unsicherheit, statt eine Antwort zu erfinden? |
| Prompt Injection in einer abgerufenen Quelle | Kann Quelltext Anweisungen verändern oder eine unzulässige Aktion auslösen? |
| Timeout oder Rate Limit beim Anbieter | Bleiben Wiederholung und Fallback innerhalb des vereinbarten Zeit- und Kostenbudgets? |
| Ungültige oder nicht unterstützte Ausgabe | Stoppt deterministische Validierung die Aktion, bevor sie eine Nebenwirkung hat? |

## Den vollständigen Anfrageweg vergleichen

Für alle Kandidaten gelten dieselben Eingaben, derselbe Kontext und dieselben Bewertungsregeln. Modell- und Prompt-Version, Qualität, Round-Trip-Latenz, Token-Verbrauch, Wiederholungen und Fallback-Ergebnisse werden erfasst. Wo menschliches Urteil nötig ist, verwenden Reviewer schriftliche Kriterien statt eines nicht dokumentierten Eindrucks.

Langsame oder fehlgeschlagene Anfragen gehören in den Bericht. Eine gute Antwort nach Ablauf der Nutzerfrist erfüllt nicht dieselbe Aufgabe wie eine rechtzeitige Antwort.

## Ein Replay liefert Belege mit klaren Grenzen

Mein veröffentlichter Modellvergleich nutzte 506 Entscheidungen pro Modell und einen Tag Kraken-BTC/USD-Trades. Er zeigt, warum Latenz den praktischen Wert einer Entscheidung verändern kann. Er belegt weder Live-Handel noch eine allgemeine Modellrangfolge. Methode, Messergebnisse und Grenzen stehen im unten verlinkten Artikel.

Bei Änderungen an Prompt, Modell, Retrieval-Quelle oder Werkzeugberechtigungen werden die relevanten Fälle erneut geprüft. Diese Ergebnisse unterstützen die Release-Entscheidung; Produktion wird separat beobachtet. Ein Replay kann nicht jedes Verhalten eines laufenden Systems nachweisen.

- [Das langsame Modell lag öfter richtig: Replay-Methode und Grenzen](/de/blog/das-langsame-modell-lag-oefter-richtig)
- [Jev: Entscheidungen statt generiertem Text](/de/blog/jev-entscheidungen-statt-text)
- [Prompt-Injection-Tests in meiner eigenen KI-Fabrik](/de/blog/ich-habe-meine-ki-fabrik-angegriffen)