Was tun, wenn eine KI nicht zufriedenstellend lernt?

Warum versagen einige KI-Modelle in kritischen Situationen, obwohl man Best Practices befolgt? Und was tun, wenn kein Modell zufriedenstellende Ergebnisse liefert?

Nehmen wir an, wir wollen ein Regressions- oder Klassifikationsproblem mit Machine Learning lösen. Wir haben nach allen Regeln der Kunst gearbeitet und haben ein gutes Problemverständnis, genügend und saubere Daten, relevante Inputfeatures, sorgfältig erstellte Labels, passende Architektur, geeignete Trainingsverfahren und -parameter. Die Gesamtperformance ist gut, aber es gibt einzelne Fälle, in denen keines der trainierten Modelle den Targetparameter “trifft”.

Im folgenden Beispiel wird die Kritikalität einer Trainings-Fahrsituation von Machine Learning Modellen geschätzt. Keine der farbig dargestellten Modelloutputs entspricht dem gelabelten Target (schwarz), im Zeitbereich zwischen 0.4 und 1.4s wird die Kritikalität durch alle Modelle deutlich überschätzt.

Das ist der Punkt, an dem man mit Machine LearningKnow-how nicht mehr weiter kommt und man tiefer ins Engineering einsteigen muss. Doch vorher einen Schritt zurück.

Worum geht es?

Von einem (embedded cyber-physical) System erwarten wir deterministisches Verhalten: gleiche Inputs (x) sollen zu gleichen Outputs (y) führen. Mathematisch kann ein deterministisches System als Funktion modelliert werden: f(x) = y.

In vielen Fällen erwarten wir sogar starke Kausalität: Kleine Änderungen im Ausgangszustand sollen nur zu kleinen Änderungen im Ergebnis führen, also x₁ ≈ x₂ ⇒ f(x₁) ≈ f(x₂). Im Rahmen der Mess- und Reproduziergenauigkeit von Versuchen wird in der Regel gleiches Systemverhalten gefordert. Dabei liegt die eigentliche Herausforderung oft in inkonsistentem Labeling und Anforderungskonflikten.

Hier setzt die distanzbasierte Konfliktanalyse an. Im Trainingsdatensatz werden Paare von Samples identifiziert, die unterschiedlich gelabelt sind, und somit verschiedene Modelloutputs erwartet werden, aber eine sehr kleine Distanz der Inputvektoren haben.

Solche Samples stellen einen Anforderungskonflikt dar: Bei nicht oder kaum unterscheidbarem Sensorbild werden unterschiedliche Outputs gefordert. Kein Algorithmus kann das leisten, und zwar unabhängig davon, ob sie auf analytischen Gleichungen oder auf Machine Learning beruht.

Beim autonomen Fahren kann beispielsweise Regen bei unterschiedlichen Straßenbedingungen zu ähnlichen Sensorwerten führen. Wenn ein Szenario als „sicher“ und ein anderes als „kritisch“ gelabelt wird, entsteht ein Anforderungskonflikt, der gelöst werden muss.

Anforderungs-Konfliktmanagement

Anforderungskonflikte sind innerhalb der Funktion f unlösbar. Um einen Konflikt zu lösen, stehen einem Systementwickler genau drei Optionen zur Verfügung:

1. Inputs x erweitern oder ändern: zum Beispiel eine bessere Parametrierung oder die Nutzung weiterer Sensoren oder Informationen, so dass die Inputvektoren x₁ und x₂ unterscheidbar werden.

2. Geforderten Output y ändern: man akzeptiert in einem der beiden Samples “falsches” Verhalten durch das System und definiert die entsprechend Labels neu sodass sie konsistent werden.

3. Gültigkeitsbereich reduzieren: Exklusion von x₁, x₂, oder beiden aus der Operational Design Domain (ODD) des Systems. Zum Beispiel könnte bei Regen oder bei niedrigen Geschwindigkeiten das System abgeschaltet werden.

Ist ein Konflikt erfolgreich behoben, ist es sinnvoll, so lange weiter zu iterieren, bis keine Konflikte mehr in den Anforderungen nachweisbar sind. Am Ende dieses Prozesses steht ein Datensatz, der die funktionalen Anforderungen an das System beispielbasiert, konsistent und widerspruchsfrei beschreibt.

Natürlich hat jede der drei Optionen Auswirkungen, z.B. auf die Herstellungskosten, potenziell falsches Systemverhalten oder den Nutzen im Feld. Daher müssen solche Entscheidungen bewusst und evidenzbasiert getroffen werden. Sowohl die Durchführung der Konfliktanalyse als auch die Quantifizierung der Auswirkungen einer Entscheidung sind Teil des aktiven Anforderungs-Konfliktmanagements, das im Rahmen von ANDATAs Scenario Management as a Service (SMaaS) als Dienstleistung verfügbar ist.

Toolunterstüztung

Konfliktanalyse ist bereits eine seit langem etablierte Funktionalität der ANDATA Software, die nun komplett neu überarbeitet wurde. Nutzer können Konfliktanalysen jetzt intuitiver konfigurieren, Berechnungen deutlich schneller durchführen und durch verbesserte Visualisierungen tiefere Einblicke gewinnen. Die überarbeitete distanzbasierte Konfliktanalyse ist mit dem nächsten Frühlingsrelease der ANDATA Tools in STIPULATOR und BRAINER verfügbar.