Allein eine Antwort vom KI-Modell zu erhalten, bedeutet noch nicht, dass das System korrekt funktioniert. Bei klassischer Software können wir oft eindeutig prüfen, ob eine Funktion das erwartete Ergebnis zurückgegeben hat. In KI-Systemen kann eine Antwort flüssig, logisch und überzeugend sein und dennoch Fehler enthalten.
Deshalb entsteht mit der Entwicklung von KI ein neues ingenieurtechnisches Problem: Wie misst man systematisch die Qualität eines Systems, dessen Antworten nicht immer identisch sind?
Genau darum geht es bei der AI evaluation, also der Evaluierung von Systemen der künstlichen Intelligenz.
Und sie ist viel umfassender als die Frage, ob ein Chatbot „gut antwortet“.
Testen klassischer Software und Testen von KI sind nicht dasselbe
Stellen wir uns eine einfache Funktion in einer Anwendung vor.
Der Nutzer gibt ein: 2 + 2
Das System sollte zurückgeben: 4
Wenn es 5 zurückgibt, haben wir einen eindeutigen Fehler.
Wir können einen Test vorbereiten: expect(calculate("2 + 2")).toBe(4)
und jedes Mal erhalten wir ein klares Ergebnis: Der Test besteht oder er besteht nicht.
Bei KI-Systemen sieht die Situation anders aus.
Der Nutzer kann fragen: „Schreibe eine kurze Antwort für einen Kunden, der nach dem Liefertermin einer Bestellung fragt.“
Das System kann mehrere verschiedene Antworten generieren. Alle können sprachlich korrekt sein. Alle können professionell klingen. Eine kann jedoch einen falschen Termin enthalten, eine andere zu lang sein, eine dritte eine wichtige Information auslassen und eine vierte ideal sein.
Es reicht also nicht aus zu prüfen, ob die Antwort technisch erzeugt wurde.
Man muss prüfen, ob sie bestimmte Qualitätskriterien erfüllt.
Erstes Problem: Eine gute Antwort ist nicht immer wahr
Das ist eines der charakteristischsten Merkmale generativer KI.
Das Modell kann eine Antwort erzeugen, die sehr überzeugend klingt, aber nicht durch die Quelldaten gedeckt ist.
Bei einem System, das RAG verwendet, ist das Problem noch interessanter. Das System kann eine Frage erhalten, mehrere Dokumentationsausschnitte suchen und anschließend eine Antwort generieren.
Dann muss man mindestens drei Dinge prüfen:
- Wurden die richtigen Informationen gefunden? Hat der Suchmechanismus tatsächlich Fragmente abgerufen, die mit der Frage zusammenhängen?
- Nutzen die Antwort die gefundenen Informationen? Hat das Modell nichts hinzugefügt, was in den Quellen nicht vorhanden war?
- Beantwortet die Antwort tatsächlich die Frage? Man kann nämlich eine korrekt funktionierende Retrieval-Komponente haben, aber eine schlechte Endantwort.
Deshalb trennt die RAG-Evaluierung unter anderem solche Aspekte wie die Relevanz des abgerufenen Kontexts, die Vollständigkeit der Suche, die Korrektheit der Antwort und ihre Übereinstimmung mit den Quellen.
Das ist eine wichtige Veränderung im Denken über Testen.
Wir testen nicht mehr nur: Frage → Antwort
sondern die gesamte Kette: Frage → Suche → Kontext → Modell → Antwort
Man kann ein gutes Modell und ein schlechtes KI-System haben
Das ist eine weitere Sache, die leicht vergessen wird.
Ein Unternehmen kann ein sehr gutes Sprachmodell wählen und trotzdem ein schwaches KI-Produkt erstellen.
Warum? Weil die Qualität des Endsystems nicht nur vom Modell abhängt.
Auch folgende Punkte zählen:
- Datenqualität,
- Art der Aufbereitung des Kontexts,
- Prompt,
- Art der Informationssuche,
- Modellparameter,
- der KI zur Verfügung gestellte Werkzeuge,
- Anwendungslogik,
- Speicher,
- Art der Fehlerbehandlung,
- Sicherheitsmaßnahmen,
- Art der Bewertung der Antworten.
Das bedeutet, dass die Frage: „Welches Modell ist das beste?“
oft weniger nützlich ist als: „Welches Modell funktioniert in unserem konkreten Anwendungsfall am besten?“
Ein Modell, das bei der Generierung von Marketinginhalten hervorragend ist, muss nicht die beste Lösung für Dokumentenklassifikation, Datenanalyse oder Geschäftsprozessabwicklung sein.
Deshalb sollte der Modellvergleich auf realen Aufgaben stattfinden, die das System ausführen soll.
Zuerst muss man einen eigenen Testdatensatz erstellen
Ein KI-System lässt sich nicht sinnvoll bewerten, wenn wir nicht wissen, was wir von ihm erwarten.
Deshalb ist eines der wichtigsten Elemente der Evaluierung die Erstellung eines Testdatensatzes, also einer Menge realer oder repräsentativer Fälle.
Zum Beispiel baut ein Unternehmen KI für den Kundensupport.
Statt nach jeder Prompt-Änderung manuell eine Antwort zu prüfen, kann man mehrere hundert Fälle vorbereiten:
- einfache Fragen,
- mehrdeutige Fragen,
- Fragen mit falschen Annahmen,
- Fragen, die das Suchen eines Dokuments erfordern,
- Fragen zu Ausnahmen,
- Fragen zu Reklamationen,
- Fragen, die eine Ablehnung erfordern,
- Fragen mit Daten, die die KI nicht offenlegen sollte.
Jede Änderung am System kann anschließend auf demselben Satz ausgeführt werden.
Und genau hier beginnt KI, klassischer Software zu ähneln.
Wir testen nicht mehr nur eine einzelne Antwort. Wir testen das Verhalten des Systems über den gesamten Fallbestand hinweg.
Auch Prompts lassen sich testen
Prompts werden oft als Text behandelt, den jemand einmal geschrieben und dann in der Produktion belassen hat.
In Wirklichkeit kann er ein Element der Anwendungslogik sein.
Die Änderung eines einzigen Satzes kann Folgendes bewirken:
- Verbesserung der Antwort in einem Szenario,
- Verschlechterung der Antwort in einem anderen,
- größere Neigung, Ablehnungen auszusprechen,
- mehr Halluzinationen,
- längere Antworten,
- höhere Kosten,
- höheren Tokenverbrauch.
Deshalb sollte ein Prompt ähnlich wie Code behandelt werden.
Wenn wir den Prompt ändern, sollten wir wissen:
- Was hat sich verbessert?
- Was hat sich verschlechtert?
- Ist eine Regression aufgetreten?
Genau deshalb gewinnen automatische Evaluierungen immer mehr an Bedeutung und nicht die manuelle Bewertung einiger Beispielantworten.
KI kann einen Test bestehen und trotzdem ein schlechtes Produkt sein
Nehmen wir an, wir haben 100 Testfälle vorbereitet.
Das System hat 95 korrekt beantwortet. Das Ergebnis sieht großartig aus. Aber was, wenn sich die fünf falschen Antworten auf kritische Situationen beziehen?
Wenn ein Chatbot Fragen zu Öffnungszeiten beantwortet, können fünf Fehler ein Problem sein.
Wenn KI einem Mitarbeiter bei der Analyse von Finanz-, Medizin- oder Rechtsdokumenten hilft, kann die Bedeutung dieser Fehler ganz anders sein.
Deshalb reicht der Durchschnitt allein nicht aus.
Wir brauchen außerdem eine Gewichtung der Fälle.
Wir können festlegen, dass:
- eine normale Frage das Gewicht 1 hat,
- ein schwerwiegender Fehler das Gewicht 5 hat
- Ein Sicherheitsfehler hat ein Gewicht von 10,
- die Offenlegung vertraulicher Informationen hat ein Gewicht von 100.
Dann bekommt das System nicht „95 Prozent“. Wir erhalten ein wesentlich nützlicheres Bild des Risikos.
Nicht alles lässt sich mit einer einzigen Zahl messen
Das ist eines der wichtigsten Probleme der KI-Evaluierung.
Wir können mehrere Metriken haben:
- Accuracy - ist die Antwort korrekt?
- Relevance - beantwortet sie die Frage?
- Faithfulness / groundedness - stützt sie sich auf die bereitgestellten Quellen?
- Context precision - sind die gefundenen Ausschnitte relevant?
- Context recall - hat das System die benötigten Informationen gefunden?
- Safety - führt es keine unerwünschten Aktionen aus?
- Latency - wie lange wartet der Nutzer?
- Cost - wie viel kostet die Ausführung der Aufgabe?
RAG kann also eine sehr gute Antwortqualität haben, aber gleichzeitig enorme Mengen an Kontext abrufen und unakzeptable Kosten verursachen.
Ein anderes System kann sehr billig und schnell sein, aber zu viele Fehler machen.
Es gibt also keine einzige universelle Zahl, die angibt, ob KI „gut“ ist. Qualität muss im Kontext des konkreten Anwendungsfalls definiert werden.
Und was ist mit der Bewertung von KI durch andere KI?
Hier kommt ein weiterer interessanter Mechanismus ins Spiel.
Eine der Möglichkeiten zur Automatisierung der Evaluierung ist der Einsatz eines Modells als Richter, also LLM-as-a-judge.
Zum Beispiel:
Modell A generiert eine Antwort.
Modell B erhält die Frage, die Antwort und bestimmte Kriterien.
Anschließend bewertet es:
- Korrektheit,
- Übereinstimmung mit der Anweisung,
- Vollständigkeit,
- Stil,
- Sicherheit.
Moderne Evaluierungswerkzeuge ermöglichen es außerdem, solche Bewertungen mit klassischen Textvergleichen, eigenen Skripten oder Gradern auf Basis konkreter Regeln zu kombinieren.
Das erhöht die Testskala enorm. Aber es bedeutet nicht, dass der Mensch überflüssig wird. Auch das bewertende Modell kann sich irren. Deshalb lohnt es sich bei geschäftlich bedeutenderen Systemen, automatische Evaluierungen mit einer regelmäßigen Expertenbewertung zu verbinden.
Das größte Problem: Regression
Stellen wir uns ein System vor, das sehr gut funktioniert. Das Team wechselt auf ein neueres Modell. Die neue Version ist schneller und günstiger. Es scheint also, dass alles in die richtige Richtung geht.
Nach dem Deployment stellt sich jedoch heraus, dass:
- die Antworten weniger präzise sind,
- das Modell häufiger Antworten verweigert,
- es die Dokumentation schlechter nutzt,
- es Anweisungen anders interpretiert,
- es in manchen Szenarien beginnt, falsche Informationen zu liefern.
Das ist genau AI regression.
In klassischer Software kennen wir Regression seit Jahren. Auch bei KI müssen wir sie erkennen, aber das Problem ist schwieriger, weil sich das Verhalten des Systems ohne klassischen „Fehler“ ändern kann. Deshalb sollte jede größere Änderung mit der vorherigen Version verglichen werden.
Modell.
Prompt.
Embedding.
Retriever.
Dokumentation.
Agentenlogik.
Parameter.
Jedes dieser Elemente kann das Ergebnis beeinflussen.
Einen Agenten kann man nicht nur nach seiner Endantwort bewerten
Noch schwieriger wird es bei KI-Agenten.
Ein klassischer Chatbot kann eine einzige Aufgabe ausführen: Frage → Antwort.
Ein Agent kann ganz anders arbeiten: Ziel → Plan → Werkzeug → Ergebnis → nächster Schritt → Entscheidung → Handlung → Antwort.
Wenn der Agent das Ziel nicht erreicht hat, wollen wir nicht nur wissen, dass er verloren hat.
Wir wollen wissen: Wo hat er den Fehler gemacht?
- Hat er die Aufgabe falsch verstanden?
- Hat er das falsche Werkzeug gewählt?
- Hat er den falschen Parameter übergeben?
- Hat er die falschen Daten abgerufen?
- Hat er nach Erhalt des Ergebnisses eine schlechte Entscheidung getroffen?
- Hat er zu viele Schritte ausgeführt?
- Hat er zu früh aufgehört?
In der Forschung zur Evaluierung von Agenten analysiert man immer häufiger nicht nur das Endergebnis, sondern auch den Ablauf, den Werkzeugeinsatz, die Planung, das Gedächtnis, die Zuverlässigkeit und die Sicherheit.
Das bedeutet, dass die Zukunft des Testens von KI in hohem Maße mit der Analyse von Traces zusammenhängt, also dem vollständigen Ablauf des Systems.
KI braucht etwas Ähnliches wie CI/CD
Wenn KI Teil des Produkts ist, kann man sie nicht nur vor der ersten Bereitstellung testen.
Das System wird sich verändern.
Das Modell wird sich ändern.
Der Prompt wird sich ändern.
Die Wissensbasis wird sich ändern.
Die Suchmethode wird sich ändern.
Die Konfiguration wird sich ändern.
Deshalb sollte die Evaluierung Teil des Entwicklungsprozesses werden.
Das Schema kann folgendermaßen aussehen: Änderung → Tests → Evaluierung → Vergleich mit der vorherigen Version → Entscheidung über das Deployment
Wenn die neue Version die Qualität in einem Bereich verbessert, aber den festgelegten Fehlerschwellenwert in einem anderen überschreitet, kann das Deployment gestoppt werden.
Das ist eine sehr ähnliche Philosophie wie bei klassischem CI/CD, aber die Kriterien sind andere.
Bei KI-Anwendungen können wir gleichzeitig die Qualität der Antworten, Korrektheit, Sicherheit, Kosten und Latenz prüfen. Es gibt bereits Forschungsansätze, die Evaluierung mit Observability und Qualitäts-Gates im Prozess der Bereitstellung von LLM/RAG-Systemen verbinden.
Kann man KI also genauso testen wie klassische Software?
Ja, aber nur teilweise.
Der klassische Ansatz ist weiterhin notwendig.
Wir testen:
- APIs,
- Integrationen,
- Berechtigungen,
- Datenvalidierung,
- Fehler,
- Timeouts,
- Sicherheit,
- Leistung,
- Anwendungslogik.
Aber dabei können wir nicht aufhören.
Es kommt eine zweite Ebene hinzu: die Evaluierung des KI-Verhaltens.
- Ist die Antwort korrekt?
- Stimmt sie mit den Quellen überein?
- Hält sich das Modell an die Anweisungen?
- Verhält sich das System in unerwarteten Situationen korrekt?
- Wählt der Agent die richtigen Werkzeuge?
- Hat die neue Version die Qualität nicht verschlechtert?
- Bleiben die Betriebskosten akzeptabel?
- Erhält der Nutzer tatsächlich einen Mehrwert?
Das ist kein klassischer Unit-Test mehr.
Der beste KI-Test ist nicht immer ein Labortest
Es gibt noch einen weiteren sehr wichtigen Punkt.
Das System kann in einem vorbereiteten Testdatensatz hervorragend abschneiden und trotzdem in der realen Welt Probleme haben. Deshalb lohnt es sich, auch die tatsächlichen Interaktionen zu beobachten. Nicht, damit jeder Nutzer Tester wird. Es geht darum, das System auf Basis realer Fälle kontinuierlich verbessern zu können:
- wo Nutzer die KI korrigieren,
- wo sie um eine erneute Antwort bitten,
- wo sie das Gespräch abbrechen,
- wo sie den Fall an einen Menschen eskalieren,
- wo der Agent das Ziel nicht erreicht,
- wo ungewöhnliche Fragen auftauchen.
Auf diese Weise entsteht eine kontinuierliche Evaluationsschleife: Nutzer → KI-Aktion → Ergebnis → Analyse → neuer Testfall → nächste Systemversion
Das ist ein völlig anderes Entwicklungsmodell als ein einmaliges „Wir haben KI eingeführt und es funktioniert“.
KI sollte nicht mit der Frage beurteilt werden: „funktioniert sie?“
Das ist zu wenig.
Bessere Fragen lauten:
- Wie oft funktioniert sie korrekt?
- In welchen Situationen macht sie Fehler?
- Wie schwerwiegend sind diese Fehler?
- Ist die neue Version besser als die vorige?
- Ist das System ausreichend sicher?
- Basieren die Antworten auf den richtigen Daten?
- Wie viel kostet es, ein konkretes Ergebnis zu erzielen?
Erst ein solcher Fragenkatalog ermöglicht es, von einem ausgereiften KI-System zu sprechen.
Die wichtigste Veränderung im Denken
Über Jahre galt in der Softwareentwicklung eine einfache Regel: Code sollte funktionieren.
In KI-Systemen muss man sie erweitern: Das System sollte gut, vorhersehbar und messbar funktionieren.
Das ist ein enormer Unterschied. Denn KI ist keine Funktion, die immer dasselbe Ergebnis liefert. Sie ist ein probabilistisches System, dessen Verhalten vom Modell, den Daten, dem Kontext, den Anweisungen und der gesamten Architektur darum herum abhängt.
Deshalb endet eine professionelle KI-Einführung nicht in dem Moment, in dem das Modell anfängt zu antworten.
Dann beginnt erst die Frage: Woher wissen wir, dass wir ihm vertrauen können?
Und genau auf diese Frage sollte eine gut konzipierte Evaluation antworten.
In Zukunft wird das Testen von KI-Systemen wahrscheinlich ebenso natürlicher Bestandteil des Entwicklungsprozesses werden wie Unit-Tests, Integrationstests oder Monitoring. Nicht weil KI „von Natur aus gefährlich“ ist. Sondern einfach deshalb, weil ein System, dessen Ergebnis nicht immer deterministisch ist, eine andere Art der Qualitätsmessung erfordert.
Und je stärker KI von der Textgenerierung zur Unterstützung realer Prozesse, zur Nutzung von Daten, zu RAG und zur Ausführung von Handlungen durch Agenten übergeht, desto wichtiger wird nicht nur die Frage „kann KI das?“, sondern auch: „können wir nachweisen, dass sie es ausreichend gut macht?“
