Wenn die KI es sich anders überlegt … und was das für den Test bedeutet
Wie alle Software-Firmen beobachten wir einen deutlichen Trend weg von der „klassischen“ Software hin zur sogenannten künstlichen Intelligenz. So auch in der Medizintechnik. Schon früher gab es Mustererkennungsverfahren, welche die Mediziner bei der Diagnose unterstützten. Diese Verfahren basieren auf fest programmierten Algorithmen mit vorab definierten Regeln, was zwar zu guten Ergebnissen führt, in der Regel jedoch langwierig zu programmieren ist. Außerdem sind die Verfahren nicht lernfähig.
Nun gibt es Deep Learning-Verfahren, die dies ändern.
Hier wird das System zunächst mit Trainingsdaten angelernt. Wir sagen dem Programm, welches Bild Auffälligkeiten zeigt und welches nicht. Im Produktivbetrieb lassen wir das Programm dann die antrainierten Auswertungsverfahrens auf neue Untersuchungsergebnisse anwenden. Weiterlernende Systeme können obendrein ihren Erfahrungsschatz erweitern und sich durch „Nachtrainieren“ an lokale Besonderheiten und neue Entwicklungen anpassen.
Doch der Trend zu immer mehr Deep Learning wirft Fragen auf. Unserer Erfahrung nach stößt KI in der Medizintechnik auf zwei große Hürden. Die erste Hürde ist regulatorischer Art. Hier hat die FDA vor einiger Zeit ein höchst interessantes Konzeptpapier herausgegeben: Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD). Darin wird die Frage diskutiert, wie die Zulassung weiterlernender Systeme aussehen könnte. Im Dokument fallen Begriffe wie „Good Machine Learning Practices“, „SaMD Prespecifications” und „Algorithm Change Protocol”. Die Grundidee besteht darin, vorab zu spezifizieren, wohin sich die KI entwickeln darf und Mechanismen zu implementieren die sicherstellen, dass sie (die KI) im laufenden Betrieb nicht aus der Reihe tanzt.
Die zweite Hürde ist eigentlich ganz klassischer Art und betrifft die Qualitätssicherung. Zu den guten Praktiken im Machine Learning gehört natürlich, Trainingsdaten und Validierungsdaten sauber zu trennen. Während die Trainingsdaten dazu verwendet werden, den Algorithmus anzulernen, dienen die Validierungsdaten für den Test. Beide Datenpools müssen streng getrennt werden, denn sonst können wir das Testergebnis blind vorhersagen. Die Trainingsdaten werden immer „passed“ ergeben.
Wenn Testdaten nicht oder nur schwer künstlich erzeugt werden können, muss auf reale Daten zurückgegriffen werden. Jeder, der schon einmal Testdaten für diagnostische Software zusammenstellen musste, weiß um die damit verbundenen Schwierigkeiten. Zum einen müssen die Daten anonymisiert werden. Zum anderen sollen sie hinsichtlich der Krankheitsbilder, Patienteneigenschaften (Alter, Geschlecht, Gewicht…) repräsentativ sein. Bei einer KI kommt noch erschwerend hinzu, dass es zum „Bias“-Effekt kommen kann.
Beispiel 1: Die meisten Menschen in Deutschland sterben im Krankenhaus. Daraus zu schließen, Krankenhäuser seien lebensgefährlich, ist nicht korrekt. (Zugegeben: Man kann darüber streiten, wie gesund ein Krankenhausaufenthalt ist, aber Sie verstehen, worauf ich hinaus will…). Zu genau solchen Fehlschlüssen kann es jedoch beim Deep Learning leicht kommen. Die Lösung besteht darin, eine „Heat Map“ anzeigen zu lassen die darstellt, woran die KI ihre Entscheidung festmacht. Dadurch wird die Entscheidung für den Mediziner nachvollziehbar.
Beispiel 2: Manche Krankheiten sind sehr ungleich auf die Geschlechter aufgeteilt. Dass auch Männer Brustkrebs bekommen können, mag Ärzten bekannt sein, aber wie bekomme ich Testdaten, um diese Feinheiten auch einer KI beizubringen?
Das zweite Beispiel mag extrem sein, illustriert jedoch, worauf ich hinauswill. Es ist unter Umständen schon schwierig, eine ausreichende Anzahl an Trainingsdaten zu bekommen. Umso glücklicher sind wir Tester, wenn schließlich sogar Validierungsdaten vorliegen.
Und dann kommt es, das Update des Algorithmus. Die Magie des Deep Learnings wird erneut angestoßen und plötzlich kommen völlig neue Ergebnisse heraus. In einem unserer Projekte hatte sich die Sensitivität des Algorithmus geändert. Krankes Gewebe wurde erst ab einem höheren Schwellwert erkannt. Systemtestfälle, die im letzten Testlauf noch vollkommen in Ordnung waren, schlugen im Regressionstest fehl. Wir mussten warten, bis neue Validierungsdaten zur Verfügung standen. Dabei testen wir gar nicht den Algorithmus an sich, sondern die Funktionen ”drumherum”, also die Anzeige, das Abspeichern etc… Daher war es nicht so offensichtlich, dass auch unsere Tests betroffen sein würden.
Leider kann ich an dieser Stelle aktuell keine bereits bewährte Lösung für das Problem anbieten. Dieser Beitrag ist ein Erfahrungsbericht – gedacht als Warnung an alle, die sich mit dem Test von KI befassen. Ich habe jedoch eine Reihe von Ideen, die sich als hilfreich erweisen könnten:
- Stellen Sie einen Verantwortlichen für die Verwaltung der Testdaten ab (oder ein), der sich hauptsächlich um dieses Thema kümmert und nicht – wie der Product Owner – noch jede Menge andere Aufgaben erfüllen muss. Damit vermeiden Sie einen weiteren Flaschenhals im Projekt. (Der Product Owner ist ja auf jeden Fall schon einer.)
- Verankern Sie im Änderungsmanagement nicht nur die Frage, ob die Änderungen Einfluss auf die Testfälle hat, sondern ganz explizit auch die Frage, ob Testdaten betroffen sein könnten. Denken Sie dabei auch an die Systemtests.
- Verankern Sie die Bereitstellung der Testdaten in der Definition of Done des Algorithmus.
Das Änderungsmanagement von Testdaten ist übrigens auch außerhalb der künstlichen Intelligenz eine Herausforderung. Im datengetriebenen Test beobachten wir beispielsweise, dass die Qualität der Testdaten über die Zeit hinweg abnimmt. Der erste Datenpool ist noch sehr repräsentativ. Dann wird ein neuer Parameter eingeführt. Ist dieser optional, bleiben die bestehenden Testdaten weiterhin gültig. Es werden also nur ein paar neue Datensätze hinzugefügt, diese eben diesen optionalen Parameter prüfen sollen. Das führt jedoch dazu, dass bei 99% der Testdaten besagter Wert nie gesetzt ist. Ist der Parameter zwingend erforderlich, muss ich die bestehenden Testdaten anpassen. Auch hier ist der Weg des geringsten Widerstandes verlockend. Ich setze einfach in einigen Testfällen die verschiedenen Äquivalenzklassen für den neuen Parameter ein und fülle alle verbleibenden Datensätze mit einem gültigen Wert auf. Auch hier haben wir bei 99% der Testdaten den gleichen Wert.
Wir setzen an dieser Stelle auf Datenmodellierung. Ganz wie beim modellbasierten Test lässt sich die Kombinatorik sehr gut in Ablaufdiagrammen darstellen. Der Testfallgenerator – in unserem Fall natürlich die MBTsuite – liefert uns dann einen minimalen Satz an Testdaten, der gesichert alle Äquivalenzklassen bzw. Grenzwerte abdeckt. Bei jeder Änderung erhalte ich einen neuen, optimalen Satz an Testdaten, was die Varianz des Tests erhöht. Ich wiederhole also nicht zwangsläufig in jedem Sprint die identischen Tests der vergangenen Sprints. Dadurch erhöhen sich die Chancen, doch noch etwas zu finden und wir umgehen das famose Pestizid-Paradoxon des ISTQB® Certified Tester (wenn alles tot ist, bringt es nichts mehr, weiterhin Gift zu spritzen).
