Die Bundeswehr muss ihre Systeme stetig anpassen, um modernsten Gefechtsanforderungen gerecht zu werden. Das Projekt Cognitive Services (COS) der BWI zielt darauf ab, KI-Technologien wie Sprach- und Bilderkennung in die IT-Infrastruktur der Bundeswehr erstmalig zu integrieren. Diese durch die BWI entwickelten Dienste nutzen vortrainierte Modelle, die als Microservices über Web-Schnittstellen bereitgestellt werden, um Aufgaben wie Texterkennung und Bildanalyse effizient durchzuführen.
Microservices spielen dabei eine zentrale Rolle, indem sie spezifische Aufgaben innerhalb eines größeren verteilten Systems erfüllen. Dank ihrer Flexibilität und Skalierbarkeit kann die Bundeswehr ihre Softwarearchitekturen modular gestalten, was schnellere Anpassungen und eine vereinfachte Wartung ermöglicht.1
Ein wesentlicher Bestandteil der Bereitstellung solcher KI-Modelle durch die BWI ist der ML Lifecycle, der Schritte von der Modellauswahl (Model Selection) bis zur Überwachung (Monitoring & Evaluation) umfasst. Diese strukturierte Vorgehensweise gewährleistet, dass geeignete Modelle identifiziert, getestet und bereitgestellt werden, um den Nutzeranforderungen gerecht zu werden.
© BWI GmbH/Sami Hassini Dieser Artikel beleuchtet die verschiedenen Schritte des ML Lifecycles, welche helfen, die Effizienz zu steigern und auf digitale Gefechtsherausforderungen vorzubereiten.
Im ersten Schritt hat die BWI im Rahmen von COS geeignete vortrainierte Open Source Modelle ausgesucht, welche im weiteren Verlauf als Service bereitgestellt werden sollen. Nach einer initialen Recherche wird eine Liste von potenziellen Modellen erstellt und ein erster Eindruck gesammelt. Anhand von verschiedenen Merkmalen ergibt sich eine engere Auswahl. Dafür müssen verschiedene Merkmale genauer erörtert werden, wie z.B. Updateintervalle, Ressourcenanforderungen, bekannte Schwächen und vor allem ob die Lizenzbedingungen eine Nutzung im Projekt erlauben. Anschließend erprobt die BWI diese Modelle im Projektumfeld. Im Falle der Object Detection werden mehrere Modelle mit denselben Inputbildern ausgeführt, um die Ergebnisse genauer betrachten und vergleichen zu können. Eine rein subjektive Auswertung der Ergebnisse ist jedoch in keinem Fall hinreichend. Hierfür kommen modellspezifische Bewertungskriterien zum Einsatz. Dabei wird ein Testdatensatz mit Bildern und vorher markierten und benannten Objekten genutzt, welche die sogenannte „Ground Truth“ darstellen. Die Ergebnisse des Modells werden dann mit der Ground Truth auf Übereinstimmung und Abweichungen überprüft. Hierfür eignen sich Metriken wie die „Mean Average Precision“. Außerdem ist es wichtig zu prüfen, wie lange die Inferenz, also die Zeit eine Schlussfolgerung aus den Daten zu ziehen, dauert. Anhand dieser Kriterien kann dann entschieden werden, welches Modell die BWI letztendlich als Microservice bereitstellt.
Die Mean Average Precision ist eine beliebte Metrik zur Bewertung von Object Detection Modellen. Sie beruht auf vier wichtigen Bestandteilen.
Diese Informationen werden pro Klasse erhoben und zu einem gewichteten Durchschnitt zusammengefasst.2
Der Schritt „Model Provisioning“ befasst sich mit der Registrierung und Verwaltung von KI-Modellen. Hier kommt bei der BWI das Open Source Tool MLflow zum Einsatz, das als Model Registry fungiert. Das Tool ermöglicht es, Modelle zu speichern, zu verwalten und für die Integration in verschiedene Anwendungen vorzubereiten. So kann eine Vielzahl von Modelltypen integriert werden, darunter auch solche für komplexere Aufgaben wie das zuvor ausgewählte Object Detection Modell. Neben dem Modell werden dazugehörige Informationen wie unter anderem die Modellkonfigurationen, die Datenschemata von In- und Output sowie Versionsdaten in der Registry gespeichert. Dies erleichtert nicht nur die Nachverfolgbarkeit der Modellversionen, sondern auch den Vergleich verschiedener Modelle.
Um die Integration in andere Systeme zu vereinfachen, bietet MLflow eine einheitliche Schnittstelle, die es der BWI ermöglicht, Modelle unabhängig von der verwendeten Programmiersprache oder genutzten Bibliotheken bereitzustellen. Ab diesen Zeitpunkt werden die verschiedenen und vielfältigen KI-Modelle als MLflow-Modelle angesehen und können so auf einem einheitlichen Weg bereitgestellt werden.
Ein weiterer Vorteil von MLflow ist die Möglichkeit, Modelle für zukünftige Anpassungen und Verbesserungen zu speichern. Zum Beispiel kann das Object Detection Modell bei Bedarf durch weiteres Training oder andere Anpassungen verfeinert werden, um seine Genauigkeit zu erhöhen oder neue Funktionen zu integrieren, ohne dass der gesamte Entwicklungsprozess von vorne beginnen muss.3
Object Detection ist ein Verfahren in der Computer Vision, bei dem das KI-Modell Objekte in Bilddateien identifiziert und lokalisiert. Neben der Lokation und der Objektart gibt das Modell meist einen Confidence Score in Prozent an. Dieser Confidence Score gibt an, wie sicher sich das Modell bei den spezifischen Erkennungen eines Objekts ist.4
© Bundeswehr/Jana Neumann (m. BWI GmbH) Im Model Deployment geht es darum, die in MLflow registrierten KI-Modelle in eine verwaltete Umgebung einzubinden und über sogenannte REST- oder gRPC-Schnittstellen verfügbar zu machen. In COS wird für diesen Schritt KServe verwendet. KServe ist ein Werkzeug, das KI-Modelle in sogenannten Kubernetes Clustern verfügbar macht. Es sorgt dafür, dass das Modell in einer stabilen Umgebung läuft, indem es den für den Betrieb ausreichenden Speicher und die notwendige Rechenleistung bereitstellt. Dabei wird ebenfalls eine flexible Skalierung unterstützt. Sofern viele Anfragen an das Modell gestellt werden, kann KServe automatisch mehr Ressourcen bereitstellen, um die Anfragen effizient zu bearbeiten.
Im Falle des Object Detection Modells kann KServe das MLflow Modell samt benötigter Umgebung und weiteren Artefakten sammeln, um daraus einen containerisierten Microservice bereitzustellen. KServe initialisiert mit einem MLServer-Image alle abgelegten Modellartefakte, um das Modell in einer sicheren Instanz zu starten. Dabei sorgt es dafür, dass die gleiche Python Umgebung mit den wichtigen Abhängigkeiten genutzt wird, die auch beim Registrieren des Modells verwendet wurde. Dies garantiert, dass das Modell auch im Cluster optimal arbeitet und die Ergebnisse zuverlässig bleiben.
Zusätzlich zu der Bereitstellung von KI-Modellen bietet KServe Funktionen zur Vor- und Nachbearbeitung von Daten sowie zur Überwachung der Modellleistung. Diese werden besonders hilfreich, wenn man viele Modelle mit verschiedenen Daten versorgen muss. Zudem kann man durch ein Monitoring sicherstellen, dass das Modell effizient und korrekt arbeitet.5
REST API und gRPC sind Kommunikationsprotokolle, die von KServe zur Bereitstellung von Modellen verwendet werden. Beide Protokolle haben je nach Anwendungsfall ihre Vor- und Nachteile, jedoch unterstützt gRPC neben bidirektionalem Streaming eine binäre Kommunikation, was es ideal für datenintensive Anwendungen macht. In jedem Fall garantiert man sich durch eine Nutzung dieser Schnittstellen die notwendige Flexibilität bei der Bereitstellung von KI-Modellen.6
Die bereitgestellten Modelle können nun in Echtzeit zur Inferenz genutzt werden. Wie effektiv der Einsatz von nötigen Ressourcen ist, wird durch ein Monitoring genauer betrachtet. Wenn also deskriptive Informationen wie durchschnittliche Rechenzeit, Anzahl eingehender Fehler, Anzahl eingehender Anfragen uvm. zu unserem Object Detection Service betrachtet werden sollen, müssen diese erst gesammelt werden.
Dafür setzt die BWI Tools wie Prometheus ein. Dieses spricht den Modell Container per Request an, um genannte und weitere Metriken laufend abzugreifen und als Zeitreihendaten zu erfassen. Um all die gewonnenen Daten nun auch verständlich und nachvollziehbar darzustellen, eignet sich eine Software wie Grafana. Diese nimmt alle von Prometheus abgegriffenen und abgespeicherten Zeitreihendaten an und wandelt diese in eine grafische Darstellung um. Dabei können mehrere Informationen und Kennzahlen gesammelt in einem Dashboard auf einen Blick verfolgt und evaluiert werden.
Ein Monitoring ist wichtig, um ständig im Blick zu behalten, ob der bereitgestellte Service einwandfrei läuft und ob die Performance sich über die Zeit verändert. Zusammen mit dem Feedback des Kunden sind diese Informationen ausschlaggebend für ein Retiring oder Replacement des Modells.78
Wie lange ein Modell im Rahmen eines Service genutzt wird, hängt von mehreren Faktoren ab. Möglicherweise gibt es durch innovative Fortschritte neue und performantere Modelle, welche durchgängig besser als das bestehende Modell für einen Einsatz im COS Kontext geeignet sind. Zudem können sich über die Zeit hinweg die Anforderungen des Kunden an das bereitgestellte Modell ändern. Aber auch im Falle eines Model Drifts verschlechtert sich die Leistungsfähigkeit eines Modells. In jedem Fall ist es dann notwendig, das bestehende Modell mit aktuellen Alternativen zu vergleichen und bei Bedarf auszuwechseln.
Um dies frühzeitig zu erkennen sind quantitatives und qualitatives Monitoring, Feedback der Nutzer aber auch eine regelmäßige Sichtung neu veröffentlichter Modelle wichtige Faktoren, um final zu entscheiden, ob ein Retiring & Replacing stattfinden muss. Im Rahmen von COS wird ein solcher Prozess von technischer Seite unterstützt und begleitet. Sofern also erkannt wurde, dass ein aktuell eingesetztes Modell potenziell nicht mehr den Anforderungen entspricht, können mehrere alternative Modelle mithilfe von MLflow und KServe parallel getestet und ausgewertet werden, sodass ein passendes Austauschmodell ausgewählt und bereitgestellt werden kann.
Hierbei schließt sich der Kreis wieder. Für das Identifizieren alternativer Modelle wird erneut ein Model Selection Prozess angestoßen. Dabei wird auch das momentan genutzte Modell berücksichtigt. Anschließend werden aktualisierte Kriterien zur Auswahl betrachtet und neu entschieden, welches Modell in Zukunft für den betroffenen Service eingesetzt wird.
Ein Model Drift kann verursacht werden, sobald sich die Art der Eingabedaten ändert. Bei dem zuvor ausgerollten Object Detection Microservices kann es also dazu kommen, dass das Modell zu Beginn gute Ergebnisse erzielt, weil die Eingabedaten des Nutzers gut zu den Trainingsdaten des Modells passen. Allerdings könnte sich im Laufe der Zeit die Art der Bilder des Nutzers ändern wie zum Beispiel durch Änderungen in der Umgebung, neue Objekttypen oder territoriale Unterschiede.9
Die BWI zeigt mit dem Projekt „Cognitive Services“, wie die Bundeswehr durch den Einsatz von Microservices und Machine Learning ihren technologischen Fortschritt vorantreiben kann. Aktuell befinden sich die ersten Microservices in der Erprobungsphase, wo sie anhand von Beispielmodellen mit modernsten ML-Technologien wie KServe und MLflow auf der Infrastruktur der Bundeswehr getestet werden. Im weiteren Verlauf des Projekts sollen diese KI-Services in die Produktivumgebung überführt und um zusätzliche Modelle erweitert werden. Der Weg ist dabei das Ziel: Schon jetzt wurde durch die Standardisierung und Automatisierung des ML Lifecycles ein wichtiger Grundstein gelegt, der eine flexible und effiziente Weiterentwicklung ermöglicht. Mit einem strukturierten Ansatz zur Auswahl, Bereitstellung und Überwachung von KI-Modellen stellt die BWI sicher, dass die von der BWI entwickelten Lösungen die Effizienz und Anpassungsfähigkeit der Bundeswehr verbessern, indem sie moderne KI-Technologien nahtlos in IT-Systeme integrieren. Dieser Prozess wird konsequent fortgeführt, um langfristig robuste und skalierbare KI-Dienste für die Bundeswehr bereitzustellen.
Felix ist seit 2023 bei der BWI und arbeitet im Center of Excellence Software Engineering in der Abteilung Software Data Solutions & Analytics.
Aktuell arbeitet er an der Entwicklung und Bereitstellung von Cognitive Services im Rahmen der Data Analytics Platform (DAP).
Weiterhin absolviert er aktuell seinen Master im Bereich „Big Data & Business Analytics“ an der FOM Hochschule für Ökonomie & Management.
© BWI GmbH/Felix Frenger
Benjamin ist seit 2022 im Master@BWI Programm im Bereich „Software Data Solutions“, ehemals „Data Analytics“.
Momentan arbeitet er als Data Scientist im Projekt „Cognitive Services“ daran, containerisierte KI-Modelle im Rahmen der Data Analytics Plattform bereitzustellen.
Das Masterstudium absolviert er mit dem Schwerpunkt „Big Data & Business Analytics“ an der FOM Hochschule für Ökonomie & Management.
© BWI GmbH/Benjamin Raska
Seit September 2023 absolviert Josef das Master@BWI Programm in der Abteilung Software Data Solutions & Analytics.
Derzeit arbeitet er im Projekt „Cognitive Services“, das die Data Analytics Platform um containeriserte KI-Modelle erweitert.
Neben der Arbeit in der BWI studiert Josef die Fachrichtung „Big Data & Business Analytics“ an der Fachhochschule für Ökonomie & Management. (FOM)
© BWI GmbH/Josef Gruber Sami ist seit fast 5 Jahren bei der BWI und hat das Master@BWI-Programm Anfang 2022 erfolgreich absolviert. Seine Masterthesis schrieb er im Bereich NLP und KI, mit Schwerpunkt auf der Auswertung von Freitextantworten.
Bei der BWI ist Sami als Data Scientist tätig und übernimmt im Projekt „Cognitive Services“ die Rolle des Projektleiters und Product Owners.
© BWI GmbH/Sami Hassini 1 https://www.redhat.com/de/topics/microservices/what-are-microservices, Was sind Microservices?, abgerufen am 07.08.24 12:57 Uhr
2https://www.v7labs.com/blog/mean-average-precision, v7labs.com, abgerufen am 05.08.24 10:23 Uhr
3https://mlflow.org/docs/latest/traditional-ml/creating-custom-pyfunc/part2-pyfunc-components.html , mlflow.org, abgerufen am 01.08.24 10:57 Uhr
4https://www.mathworks.com/discovery/object-detection.html, mathworks.com, abgerufen am 07.08.2024 14:59 Uhr
5https://mlserver.readthedocs.io/en/latest/index.html; mlsever.readthedocs.io, abgerufen am 02.08.24 13:24 Uhr
6https://aws.amazon.com/de/compare/the-difference-between-grpc-and-rest/, amazon.com, abgerufen am 08.08.24 10:21 Uhr
7https://prometheus.io/docs/concepts/metric_types/; prometheus.io, abgerufen am 05.08.2024 um 10:37 Uhr
8https://grafana.com/docs/grafana/latest/dashboards/; grafana.com, abgerufen am 05.08.2024 um 10:39 Uhr
9https://www.bigdata-insider.de/was-ist-model-drift-a-0908a980a864f74c823ac7b2cc55c154/, bigdata-insider.de, abgerufen am 13.08.2024 um 11:30 Uhr
Sie werden auf eine externe Seite weitergeleitet:
Diese Einstellung kann in unseren Datenschutzhinweisen erneut konfiguriert werden. In den Cookie-Einstellungen können Sie ihre Einstellungen mit Wirkung auf die Zukunft wiederrufen.
