Die richtigen Fragen stellen beim Testen von KI Systemen
Inhaltsverzeichnis
Frage 1: Benötigen wir weiterhin Tester?
Frage 2: Was kann der Tester beitragen?
Frage 3: Was sollten Test potenziell noch lernen?
Frage 4: Was testen Data Scientists eigentlich schon?
Frage 5: Was sollten Data Scientists noch lernen?
Frage 6: Was gewinnen wir eigentlich durch den Einsatz von KI?
Frage 7: Welche Teile des Systems nutzen KI?
Frage 8: Haben wir es mit einem deterministischen System zu tun?
Frage 9: Wann sollten die Ergebnisse gleich sein?
Frage 10: Haben wir es es mit einem riskanten System zu tun?
Frage 11: Was machen die Anwender mit der Ausgabe?
Frage 12: Gibt es einen goldenen Testdatensatz?
Frage 13: Welche Daten vom System müssen wir sammeln bzw. monitoren?
Fazit
Künstliche Intelligenz (KI) ist derzeit in aller Munde und wird über kurz oder lang in nahezu jedem Softwareprodukt Einzug halten. Mit dieser Technologie entstehen aber auch neue Herausforderungen in den klassischen Disziplinen der Softwareentwicklung. In diesem Artikel stelle ich ihnen einen Fragenkatalog vor, den Sie verwenden können, wenn künstliche Intelligenz auch in Ihrem Kontext eingesetzt wird und sie sich fragen, wie Sie das testen sollen. Er hilft ihnen, das Thema von Anfang an zu strukturieren.
Frage 1: Benötigen wir weiterhin Tester?
Es gibt mittlerweile verschiedene Toolhersteller, die zeigen, wie sich Testfälle mithilfe von KI automatisiert erzeugen lassen. Wieso sollten Unternehmen also weiterhin Tester benötigen? Weil es jemanden braucht, der mit geübten Blick auf das Thema schaut, um mögliche Inkonsistenzen und systemische Fehler aufzudecken. Nicht ohne Grund weisen die Hersteller der Werkzeuge zumindest im Kleingedruckten darauf hin, dass das erzeugte Artefakt noch von erfahrenen Anwendern überprüft werden sollte.
In der Regel kann die Frage nach der Notwendigkeit von Testern also mit “Ja” beantwortet werden und muss nicht für jedes System neu gestellt werden.
Frage 2: Was kann der Tester beitragen?
Natürlich eine ganze Menge. Tester sind typischerweise hochqualifizierte Spezialisten auf ihrem Gebiet und haben viele Methoden und Ansätze gelernt, um komplizierte und komplexe Systeme zu testen. Insbesondere Methoden wie
- Boundary Condition Analysis,
- Equivalence Class Partitioning und
- PropertyTesting
sind hier relevant. Der Output der generativen KI ist typischerweise nicht immer genau gleich, sondern muss in bestimmte Bereiche und Kategorien fallen.
Im Großen und Ganzen ist diese Frage auch obsolet, analog zu Frage 1, aber der Vollständigkeit halber möchte ich sie erwähnen.
Frage 3: Was sollten Tester potenziell noch lernen?
Etwas, das man als Tester vielleicht schon gelernt hat, nämlich im Bereich “Testen nicht-funktionaler Anforderungen”: eine Vertiefung im Bereich Statistik.
Man muss kein Statistik-Experte werden oder einen Abschluss in Mathematik haben, der Besuch eines Kurses wie “Statistik 301”, der typischerweise die Kenntnisse der Statistik-Einführung vertieft, ist aber empfehlenswert. Ziel ist ein gutes Verständnis für Ausgaben, die bestimmten Wahrscheinlichkeiten unterliegen.
Schaut man sich den Bereich der nicht-funktionalen Anforderungen genauer an, wird man da mit Aussagen wie “Die Antwortzeit des Dienstes sollte in 90 % der Fälle 200ms nicht überschreiten und in 99 % der anderen Fällen 500ms nicht überschreiten” konfrontiert. Das sind aber Aussagen analog zur Ausgabe von KI basierten Systemen.
Frage 4: Was testen Data Scientists eigentlich schon?
Klare Antwort: Eine ganze Menge. Auch der Data Scientist ist daran interessiert, aus den Daten ein qualitativ hochwertiges Modell zu generieren. Der Fokus mag ein anderer sein als beim Tester, aber der Qualitätsanspruch ist der gleiche. Daher ist es wichtig, dass sich Tester und Data Scientist austauschen. Viele Testfälle, auf die der Tester kommen wird, sind wahrscheinlich schon vom Data Scientist durchgeführt worden, wie z. B. die Sicherstellung, dass Präzision und Genauigkeit den vorgegebenen Werten entsprechen. Dadurch kann viel Redundanz beim Testen vermieden werden.
Frage 5: Was sollten Data Scientists noch lernen?
Der Data Scientist ist meist sehr fokussiert auf die Erstellung der Modelle und die Auswertung der Daten. Was hier noch wichtig wäre, ist, dass man sich auch bewusst ist, wie das generierte Modell in das Gesamtsystem passt, also z.B. welche Anforderungen damit erfüllt werden. Dies kann wiederum sehr einfach im Austausch mit den Testern geschehen, die in der Regel genau diese Sicht auf das System haben.
Frage 6: Was gewinnen wir eigentlich durch den Einsatz von KI?
So trivial es auch klingen mag, auch diese Frage sollte gestellt werden. Brauche ich gerade hier KI oder kann ich das Problem genauso gut mit anderen Mechanismen lösen? Selbst bei Google lautet die erste Regel in der Richtlinie zur Erstellung von Machine Learning (ML) Anwendungen: “Don’t be afraid to launch a product without machine learning”.
Solange also KI oder ML keine signifikanten Vorteile bringen, sollte man sich überlegen, ob man diese Technologien überhaupt einsetzen will, denn der Einsatz hat natürlich auch den Preis der Komplexität und des hohen Verbrauchs an Rechenressourcen beim Training der Modelle.
Frage 7: Welche Teile des Systems nutzen KI?
Auch dies ist eine sehr wichtige Frage. Meistens sind es sehr spezielle Teile des Systems, die KI verwenden, und der Anteil von KI am Gesamtsystem ist eher gering. Es ist nicht unüblich, dass sich große Teile von Systemen mit “ganz normalen” Dingen wie der Bereitstellung von Webservices, der Auswertung von REST-Anfragen, der Persistierung von importierten Daten etc. beschäftigen, und nur eines von mehreren Systemen – bpsw. für die Abfrage von Modellen und die Rückgabe von Antworten – KI nutzt. Das bedeutet im Umkehrschluss, dass sich für einen Großteil des Systems die Frage nach KI überhaupt nicht stellt und es ganz klassisch getestet werden kann.
Frage 8: Haben wir es mit einem deterministischen System zu tun? Ist es (scheinbar) nicht deterministisch?
Die neuesten Forschungsarbeiten aus Dezember 2023 zeigen, dass weit weniger KI-Systeme in einen deterministischen Modus gezwungen werden können als noch vor einem Jahr angenommen. Sowohl Systeme der generativen KI (wie ChatGPT) als auch neuronale Netze im Allgemeinen haben einen systemimmanenten Nicht-Determinismus, auch nach Abschluss ihres Trainings während der Inferenz. Dieser Nicht-Determinismus kann in allen Systemen reduziert, aber nie vollständig eliminiert werden.
Je deterministischer ein System ist, desto mehr sollte es also beim Testen als Black Box betrachtet werden. Salopp gesagt: Was interessiert es mich als Anwender, ob meine Anfrage jetzt von einer KI oder einem anderen Algorithmus bearbeitet wird? Ich brauche möglichst immer das gleiche Ergebnis.
Frage 9: Wann sollten die Ergebnisse gleich sein? Unter welchen Umständen sollten sie unterschiedlich sein?
Diese Frage scheint mit der vorhergehenden identisch oder ihr sehr ähnlich zu sein. Allerdings geht es hier eher um Fälle, die wir schon vor der KI hatten, nämlich eine Situation, die als “letztlich konsistent” bezeichnet wird. Insbesondere bei verteilten unabhängigen Diensten, die miteinander kommunizieren, kann es vorkommen, dass zwar korrekte Ergebnisse angezeigt werden, die konkreten Rückgabewerte bei zwei Anfragen aber unterschiedlich sein können. Ein Beispiel wären hier sogenannte Walls wie bei Facebook, die nicht immer konsistent die gleichen Daten anzeigen, nur um die Daten schneller zum Nutzer zu bringen. Solche Situationen können nun vermehrt bei KI-Systemen auftreten, wenn diese entweder nicht vollständig deterministisch sind oder die Ausgabe mehrerer Systeme zu einem Endergebnis zusammengeführt wird.
Frage 10: Haben wir es mit einem riskanten System zu tun?
Ich denke, der kürzlich verabschiedete EU AI Act¹ ist hier der aktuelle Maßstab, auch wenn er in dieser Einteilung noch interpretierbar bleibt. Man kann daraus drei Kategorien von Systemen ableiten:
- Verbotene Anwendungen,
- hochriskante Anwendungen und
- sonstige Anwendungen.
Ich glaube nicht, dass Sie sich darüber Gedanken machen werden, wie man verbotene Anwendungen testet. Mit hochriskanten Anwendungen sind Anwendungen im sicherheitsrelevanten Umfeld gemeint (also Software, die direkt oder indirekt Menschen gefährden kann). Diese bewegen sich typischerweise bereits in einem regulierten Umfeld und die meisten Testanforderungen lassen sich aus den Regularien ableiten. Umso mehr muss man sich aber mit den anderen Fragen auseinandersetzen.
Frage 11: Was machen die Anwender mit der Ausgabe?
Auch bei nicht risikoreichen Anwendungen sollte überlegt werden, wie der Output der KI weiterverwendet wird. Gibt es ethische Fragen, die gestellt und geprüft werden sollten? Ich denke, wir alle haben schon von ChatBots gehört, die sich relativ schnell in extremistische “Persönlichkeiten” verwandelt haben, oder von Software, die den Bewerbungsprozess im Unternehmen effizienter gestalten soll, dann aber eine bestimmte Personengruppe pauschal ausschließt, weil diese in den Trainingsdaten nicht stark genug vertreten war.
Frage 12: Gibt es einen goldenen Testdatensatz?
Dies scheint eine interessante Frage zu sein, insbesondere für das Training. Sie sollte aber bereits vom Data Scientist beantwortet werden. Aus der Sicht des Testers muss die Frage aus der Sicht des Modellnutzers gestellt werden. Und hier kann sich durchaus herausstellen, dass man gar keinen stabilen Testdatensatz benötigt, sondern die Funktionalität auch mit sich ändernden Daten testen kann.
Besonders interessant wird es, wenn ich ein System habe, das zum Beispiel seine Modelle im Feld aktualisiert und damit seine Ausgabe über die Zeit verändert. Daraus ergibt sich die Notwendigkeit, das Modell mit stabilen Datensätzen im Test zu skalieren, um sicherzustellen, dass es sich auch in die richtige Richtung entwickelt. Ich denke, niemand möchte einen Chatbot, der aufgrund der Eingaben der Nutzer und der Verarbeitung dieser Eingaben plötzlich ausfällig oder bösartig wird.
Frage 13: Welche Daten vom System müssen wir sammeln bzw. monitoren?
Dies ist eine klassische Frage aus dem Monitoring von Systemen, die aber auch hier sehr interessant werden kann. Neben den bekannten Metriken, die man für eine funktionierende Software erheben kann, können auch modellspezifische Metriken auftauchen. Wie verhalten sich z. B. die Metriken für das Modell selbst über die Zeit? Bleiben Genauigkeit und Präzision gleich oder verschlechtern sie sich? Verändert sich die Laufzeit oder die CPU-Last über die Zeit durch das Modell?
In heutigen Cloud-Systemen kann das dann auch Auswirkungen auf die Betriebskosten des Systems haben, wenn ich diese abhängig davon bezahlen muss.
Fazit
Die genannten Fragen helfen, das “Problem” des Testens einer KI-Anwendung strukturiert anzugehen und in seine Bestandteile zu zerlegen. Gehen Sie die Fragen Schritt für Schritt durch und suchen Sie nach Ihren Antworten. So können Sie bspw. für sich festlegen, in welchem Umfang welche Testdaten benötigt werden oder diskutieren, wie Sie Redundanzen und damit unnötige Durchläufe und Wartezeiten beim Testen vermeiden, um schneller Feedback für die Entwicklung zu generieren.
Hinweise:
Der Fragenkatalog ist ein gemeinsames Werk von Marco Achtziger, Alex Schladebeck (von der Bredex GmbH), Andrea Hüttner, Christian Matt (beide von der eschbach GmbH) und Dr. Gregor Endler (von der codemanufaktur GmbH).
Die Fragen dürfen Sie sehr gerne in Ihren Projekten nutzen. Marco Achtziger freut sich über Feedback und Hinweise auf zusätzliche Fragen, die ebenfalls nützlich beim Testen von KI-Systemen sein können.
[1] EU-Gesetz zur künstlichen Intelligenz
Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!
Marco Achtziger
Marco Achtziger arbeitet für Siemens Healthineers als Testarchitekt und Trainer für Testarchitekten. Er ist iSQI Certified Professional for Software Architecture, iSTQB Certified Tester und iSQI Certified Professional for Project Management. Gerne teilt er sein Wissen und seine Erfahrungen auch über Unternehmensgrenzen hinweg und spricht als Referent auf Konferenzen wie der OOP oder den Agile Testing Days.