Sollten Sie die ISO/IEC TR 29119-11 zum Testen von KI-/ML-Software kennen?

Ende 2020 veröffentlichte die ISO den Technical Report ISO/IEC TR 29119-11. Er trägt den Titel „Guidelines on the testing of AI-based systems“.

Viele Firmen möchten wissen, wie sie ihre Produkte, die auf Verfahren der künstlichen Intelligenz (KI) basieren, nach dem Stand der Technik testen sollen. Daher hat sich die ISO/IEC TR 29119-11 auf den Weg gemacht, konkrete Hilfestellung zu geben und damit den Stand der Technik zu beschreiben. Doch wird die Norm diesem Anspruch gerecht?

Wenn Sie gleich die Antwort wissen wollen, springen Sie ins Kapitel 3 „Zusammenfassung“.

1. Übersicht über die ISO/IEC 29119-11

a) Anwendungsbereich

Die ISO/IEC 29119-11 ist Teil einer Normenreihe zum Software-Testing. Beispielsweise beschreibt der Teil 2 die Testprozesse, Teil 4 die „Test techniques“. Der hier vorgestellte Teil 11 soll Hilfestellung für das Testen von KI-basierter Software geben, und zwar unabhängig von

• Branche,
• Art des Produkts (Standalone-Software, physisches Produkt),
• Anzahl der KI-Komponenten.

b) Aufbau der Norm

Die ISO 29119-11 umfasst 60 Seiten und besteht aus 10 Kapiteln und einem Anhang.

2. Die wichtigsten Inhalte

Kapitel 1: Scope

Das erste Kapitel ist zwar mit „Scope“ überschrieben, beschreibt aber eher Ziele und Inhalte der Norm.

Kapitel 2: Normative references

Die Norm nennt keine normativen Referenzen.

Kapitel 3: Terms, definitions and abbreviations

Das dritte Kapitel enthält 88 Definitionen. Das ist sehr umfassend. Einen Verweis auf Quellen fehlt weitgehend. Einige Definitionen sind zumindest überraschend. Experten für Machine Learning verstehen beispielsweise unter „false positive“ etwas anderes als die Autoren, die den Begriff aus der Sicht der Software-Tester definieren:

„incorrect reporting of a pass when in reality it is a failure”

ISO/IEC TR 29119-11 Kapitel 2

Kapitel 4: Introduction to AI and testing

Die sehr anspruchsvolle Einführung des vierten Kapitels stellt u. a. Anwendungsfälle, Typen von KI-Modellen, KI-Frameworks wie Tensorflow und regulatorische Standards vor. Über Aktualität, Inhalte und Auswahl dieser Listen mag es geteilte Meinungen geben.

Die für den Bereich der Medizinprodukte relevanten Regularien fehlen fast vollständig.

Kapitel 5: AI Characteristics

Die Autoren stellen das Qualitätsmodell der ISO 25010 vor und kommen zu der überraschenden Erkenntnis:

However, AI-based systems have some unique characteristics that are not contained with this quality model, such as flexibility, adaptability, autonomy, evolution, bias, transparency/interpretability/explainability, complexity and non-determinism.

ISO/IEC TR 29119-11 Kapitel 4

Die ISO/IEC TR 29119-11 nennt diese Attribute sogar „non-functional characteristics“.

Der Einschätzung „not contained within this quality model“ lässt sich aus mehreren Gründen nur schwer folgen:

1. Die Aufzählung in Kapitel 4 der ISO 29119 umfasst verschiedene Konzepte wie Qualitätseigenschaften (z. B. adaptability) und Fehlertypen (bias). Die Freiheit von Fehlern, hier die Korrektheit von Werten, ist explizit Teil des Qualitätsmodells (Functional correctness).
2. Auch weitere Qualitätsaspekte sind sehr wohl im Qualitätsmodell der ISO 25010 enthalten. Beispielsweise ist die interpretability ein Aspekt der maintainability, insbesondere der analysability.
3. Die Begriffe der Aufzählung beziehen sich auf das Modell und auf das Produkt (autonomy). Beides sollte man nicht verwechseln. Ob Produkte autonom sind, ist unabhängig von KI.
4. Es bleibt unklar, wie die Autoren zu der Einschätzung gelangen, dass der Output von KI-Modellen nicht-deterministisch ist.

Kapitel 6: Introduction to the testing of AI-Based systems

Als besondere Herausforderung sehen die Autoren der ISO/IEC 29119-11 das Erstellen von Spezifikationen. So sei häufig der gewünschte Output des Systems nicht bekannt, was auch beim Erstellen des Testorakels ein Problem sei.

Ein Medizinproduktehersteller, der so etwas behaupten würde, hätte wahrscheinlich Schwierigkeiten mit seiner Benannten Stelle. Er müsste bereits für Testdaten genau angeben können, ob das System beispielsweise auf einem konkreten CT-Bild Krebsgewebe erkennen können soll oder nicht. Das muss er bereits beim Labeling festlegen.

Die ISO 29119-11 sieht das Konzept von Unit-, Integrations- und Systemtests auch auf Software übertragbar, die KI-Komponenten enthält. Das ist nachvollziehbar. Konkrete Hinweise, wie diese Tests durchzuführen sind, gibt die Norm nicht; sie verweist dazu auf die späteren Kapitel.

Bei den Unittests unterscheidet die IESO 29119-11 nicht zwischen

• Software, die Teil des Medizinprodukts ist, und
• Software, die dem Data-Processing dient.

Aus Sicht des Software-Engineerings ergibt das Sinn. Aus regulatorischer Sicht sind die beiden Fälle jedoch zu unterscheiden. Mit der ISO 13485 und der IEC 62304 sind sogar verschiedene Normen anwendbar.

Kapitel 7: Testing and QA of ML systems

Das siebte Kapitel spricht im Gegensatz zu den anderen Kapiteln nur von Machine Learning, nicht von künstlicher Intelligenz. Weshalb dieser Wechsel stattfindet, offenbart die Norm nicht.

Wer hofft, in diesem Kapitel konkrete Hilfestellung zu finden, wie man ML-Systeme testet, wird enttäuscht. Zwei bis drei relativ allgemeine Sätze widmen die Autoren verschiedenen Aspekten wie „Test Data Quality“, denen jeweils ein Unterkapitel gewidmet ist.

Statt dieser Hilfestellung findet sich z. B. im Unterkapitel „Adversarial Attacks“ eine Beschreibung dieser Angriffe, aber keine Vorgabe, wie man die Robustheit (ISO 25010-Kriterium) des Systems gegen diese Angriffe prüft.

Kapitel 8: Blackbox testing of AI based systems

Auch das achte Kapitel bleibt relativ oberflächlich. Beispielsweise schildert das Unterkapitel zum kombinatorischen Testen in wenigen Sätzen, worum es sich dabei handelt; was aber konkret getan werden muss und wie bzw. ob sich das kombinatorische Testen auf Bilddaten übertragen lässt, führt die ISO 29119-11 nicht aus.

Dafür finden sich an anderer Stelle einige Hinweise:

• Back-to-back Testing
  Hersteller können/sollen beispielsweise über alternative Implementierungen die zu erwartenden Ergebnisse (Test Orakel) ermitteln. Im Medizinproduktebereich wäre die Unkenntnis dieser Ergebnisse nur schwer zu vermitteln (s. o.). Aber die alternativen Implementierungen können helfen, das leistungsfähigste Modell zu finden und die konkrete Wahl dieses Modells zu begründen.
• Metamorphic Testing
  Das Metamorphic Testing soll helfen, Testfälle abzuleiten. Dazu untersucht der Test, wie sich Änderungen am Test-Input auf den Test-Output auswirken. Als Beispiele nennt die Norm ein Modell, das das Alter von Personen abhängig von deren Lebensgewohnheiten abschätzt. Beim „Metamorphic Testing“ würde man den Einfluss des Nikotingenusses bei sonst gleichen Inputs untersuchen.
  Letztlich beschreiben die Autoren damit die Partial Dependency Plots.

Kapitel 9: Whitebox testing of neural networks

Das Kapitel heißt in der Tat “Whitebox testing of neural networks“ und nicht „Whitebox testing of AI based systems“. Weshalb die Autoren das Whitebox-Testing nur auf neuronale Netzwerke beschränken, bleibt unklar.

Das Kapitel erklärt kurz, was neuronale Netzwerke, Neuronen, Gewichte und hidden layer sind. Danach legt das Kapitel seinen Schwerpunkt auf die Prüfabdeckung (Test Coverage). Es führt mehrere Metriken ein:

• Neuron Coverage
• Threshold Coverage
• Sign Change Coverage
• Value Change Coverage
• Sign-sign Coverage
• Layer Coverage

Die ISO 29119-11 erklärt jede Metrik mit etwa zwei Sätzen. Welche Aussagekraft diese Metriken haben, gar in Abhängigkeit vom Input (Bilder, tabellarische Daten, Texte) oder von der Architektur des neuronalen Netzwerks, erläutert die Norm hingegen nicht. Das wäre hilfreich gewesen, zumal viele Entwickler nicht nur auf fully-connected layers setzen.

Auch auf die Rolle der Aktivierungsfunktion gehen die Autoren nicht ein. Dass man ein Neuron als aktiviert definiert, wenn dessen Output größer als Null ist, mag für eine RELU-Funktion zutreffen. Doch schon bei einer Sigmoid-Funktion wird dieser Ansatz scheitern.

Referenzen zu einer entsprechenden Literatur fehlen ebenfalls weitgehend.

Kapitel 10: Test environments for AI-based systems

Das letzte Kapitel geht auf die Testumgebungen ein. Es nennt die Vorteile von virtual test environments.

Eine Anregung ist hilfreich: Die Gestaltung dieser Testumgebungen nicht nur aus den Systemanforderungen, sondern aus den konkreten Problemen (Accident Reports, Issues) abzuleiten.

Allerdings sollten bei Medizinprodukten nicht primär Post-Market-Daten, sondern das Risikomanagement die Wahl dieser Testumgebungen bestimmen.

Wie die Hersteller z. B. aus Accident Reports Rückschlüsse auf die Testumgebung ziehen sollen, beschreibt die Norm nicht.

3. Zusammenfassende Bewertung der ISO/IEC TR 29119-11

Die ISO/IEC TR 29119-11 ist – wie bereits deren Namen erkennen lässt – ein Technical Report. Bei Technical Reports ist es üblich, dass sie nicht nur konkrete Anforderungen enthalten, sondern auch Hintergrundinformationen liefern.

a) Unkonkret und mangelnde Handlungsleitung

Die ISO/IEC TR 29119-11 bleibt für einen Technical Report auf einem sehr oberflächlichen Niveau. Die Norm kann als Einführung dienen, auch wenn vieles an anderer Stelle präziser, ausführlicher und verständlicher erklärt wird.

Weil die ISO/IEC TR 29119-11 alle Konzepte nur streift, erfahren die Leser nicht, was sie konkret tun können. Beispielsweise stellt die Norm fest, dass die Güte der ML-Systeme von der Güte der Test- und Trainingsdaten abhängt. Das dürfte niemanden überraschen. Die Norm fordert:

The selection of training data in terms of the size of the dataset and characteristics such as bias, transparency and completeness should be documented and justified and confirmed by experts where the level of risk associated with the system warrants it (e.g. for critical systems).

ISO/IEC TR 29119-11 Kapitel 7.5

Was sollen die Hersteller nun konkret tun?

Schon fast wie eine Tautologie wirken Sätze wie:

a system can be tested for bias by the use of independent testing using bias-free testing sets

ISO/IEC TR 29119-11 Kapitel 6.1.8

b) Unvollständig

Keine Norm wird den Anspruch auf Vollständigkeit erheben. Das Maß, in dem die ISO 29119-1 vorhandenes Wissen ausblendet, erstaunt dennoch. Dies betrifft beispielsweise:

• Definitionen von Konzepten wie Explainabiliy, Interpretability und Transparency, die vorhandene Definitionen ignorieren
• Whitebox-Testing-Ansätze für KI-Verfahren, die sich nur auf neuronale Netzwerke beziehen
• Ignoranz von relevanten Metriken zum Bestimmen von Coverage-Graden, z. B. die Abdeckung des Input- und Output-Datenraums
• Fehlender Bezug zum Stand der Technik bei modellspezifischen und modellagnostischen Verfahren zum Interpretieren und Überprüfen von ML-Modellen (wie z. B. im Buch von Christoph Molnar vorgestellt)
• Ignorieren von Verfahren, die eine sehr hohe Verbreitung haben, wie die Gruppe der Ensemble Trees (Die Norm geht auf die Besonderheiten von neuronalen Netzwerken ein).
• Die sehr anspruchsvolle Validierung von Machine Learning Libraries. Dass die Norm hierauf nicht eingeht, ist bedauerlich, da bei den vielen Produkten dort der meiste Code zu finden ist.

c) Nicht immer nachvollziehbare Struktur

Sowohl die „makroskopische Ebene“ der Norm (z. B. Kapitelstruktur) als auch die „mikroskopische Ebene“ (einzelne Sätze und Aufzählungen, Verwendung von Begriffen) lassen Zweifel an der konzeptionellen Integrität aufkommen.

• Die Kapitel genügen nicht den Anforderungen der MECE-Regel.
• Begriffe werden verwechselt, z. B. Gefährdungen und Safety bzw. Feature Selection und Feature Engineering gleichgesetzt.
• Der Text wechselt in nicht ganz nachvollziehbarer Weise zwischen KI und ML.
• Verschiedene Konzepte wirken zusammengewürfelt (z. B. taucht Reinforcement Learning in der Liste von Verfahren aus, die sonst neuronale Netzwerke und Entscheidungsbäume enthält).

d) Relevanz

Wie relevant die auf zwei Nachkommastellen genauen Vorhersagen zur Nutzung der AI, die aus dem Jahr 2018 stammen, in wenigen Jahren sein werden, lässt sich diskutieren.

Das gleich gilt für die gewählten Coverage-Grade und den Fokus auf die neuronalen Netzwerke.

Viele implizite Einschränkungen (z. B. auf einen Teil der Aktvierungsfunktionen) engen den tatsächlichen Anwendungsbereich der Norm weiter ein.

4. Fazit

Menschen, die Wissen zusammentragen, dieses strukturieren und in Normen gießen, verdienen Anerkennung und Dank. Meist leisten sie diese Arbeit ehrenamtlich.

Die ISO 29119-11 wirkt, als sei sie von Personen mit fundiertem Wissen in Software-Engineering geschrieben. Eine besondere Expertise im Bereich des maschinellen Lernens strahlt sie nicht im gleichen Maße aus.

Für eine Norm dieser Güte 178 CHF zu verlangen, erscheint als nicht angemessen.

Für Medizinproduktehersteller und Auditoren muss klar sein:

Ob man das Geld zum Kaufen und die Zeit zum Lesen der Norm aufwenden oder beides lieber in das Testing seiner KI-basierten Systeme investieren will, möge jeder selbst entscheiden.

In einem künftigen Beitrag wird das Johner Institut konkrete Hilfestellungen zum Testing von ML-basierter Software geben. Eine umfassende Hilfe hat es bereits im AI-Leitfaden kostenfrei publiziert, den in abgewandelter Form auch die Benannten Stellen verwenden und auf dem ein künftiger Leitfaden der WHO basieren wird.