Thought Leadership
Im Sektor des Service Managements gewinnt die Anwendung Künstlicher Intelligenz (KI) zunehmend an Bedeutung. Der vorliegende Artikel stellt einen Vergleich an.
Dieser stützt sich auf Untersuchungen, um den Ressourcenbedarf, die Leistungsfähigkeit und die Präzision zwischen herkömmlichem Machine Learning und Deep Learning zu bewerten und beleuchtet dabei die Vorzüge des fortschrittlichen Ansatzes.
KI – immer komplexer, immer teurer?
Parallel zur Entwicklung der Rechenleistung von Computern entwickeln sich immer größere KI-Modelle. Zum Beispiel werden die Sprachmodelle, wie das der gehypten ChatGPT-Anwendung, wochenlang auf riesigen Datensätzen trainiert und besitzen über hundert Milliarden Parameter.
Aber auch in anderen Anwendungen ist der Trend zu stets komplexeren Modellen zu verzeichnen. Beispielsweise nutzte die USU-Anwendung IT Service Management für das KI-gestützte Ticketrouting klassische Machine-Learning-Methoden (ML). Mit dem neuen Release stehen nun Deep Learning (DL) Methoden zur Verfügung. Die verwendete Transformer-Technologie steckt auch hinter ChatGPT.
Heute wollen wir näher betrachten, wie teuer die steigende Komplexität der Modelle wirklich ist. Dazu haben wir einige Experimente mit unserem KI-gestützten Ticket-Routing durchgeführt, um die Auswirkungen auf den Ressourcenverbrauch von Rechenleistung und Rechendauer gegenüber der Vorhersagequalität zu untersuchen. Beim Ticket-Routing geht es darum, Tickets anhand ihres Textinhalts zu klassifizieren. Die Klassifikation erfolgt für jedes Ticket auf mehren Feldern wie beispielsweise Tickettyp, Kategorie oder Bearbeitergruppe.
Für unsere Experimente haben wir einen Datensatz mit initial 100.000 Tickets verwendet. Bei diesem Datensatz sollen Modelle zur Klassifikation von Tickets mit sechs Zielfeldern (Targets) trainiert werden. Dabei hängen die Zahlenwerte stark von der Datengrundlage, der Ticketanzahl, der Anzahl der Targets und der Anzahl der Klassen innerhalb der Targets ab. Sie sind spezifisch für diesen Datensatz berechnet und dienen als Anhaltspunkt. Da viele Kunden ihre Datensätze nicht auf externe Ressourcen übertragen möchten, haben wir für die Experimente eine Kundenhardware von 4 CPU mit 16 GB Arbeitsspeicher vorgegeben.
| Klassisches Machine Learning | Deep Learning |
| – Multinomial Naive Byes – Logistic Regression Classifier – Random Forest Classifier | – Multi-Target-Transformer |
Die Vorverarbeitung von Ticketdaten
Für unsere klassischen ML-Algorithmen müssen die Ticketdaten aufwendig vorverarbeitet werden. Da die Vorverarbeitung von der Ticketzusammenstellung abhängt, muss dies für jedes Training aufs Neue durchgeführt werden. Für das DL werden lediglich die relevanten Spalten aus der Datenbank ausgelesen. Hierbei werden neben den Ticketinhalten, die Ticket-IDs und Sampling-Gewichte verwendet. Mit den persistenten IDs können die Tickets für die Evaluation von den Tickets der Trainingsdatenmenge unterschieden werden. Die Sampling-Gewichte beeinflussen, welche Tickets im Training häufiger gesehen werden. Dies ist abhängig davon, wie oft sie in der Vergangenheit schon berücksichtigt wurden.
Modelltraining – ML vs. DL
Beim Modelltraining des klassischen ML werden für jedes Target verschiedene Modelle trainiert. Das Training für diese Modelle hat inklusive Vorverarbeitung etwa 4 Stunden gedauert. Jedoch ist der Anteil der Vorbereitung an der Trainingszeit mit dem klassischen ML besonders hoch. Da jeweils das beste Modell verwendet wird, resultieren bei unserem Experiment sechs Modelle, für jedes Target eines. Beim initialen Modelltraining des DL-Algorithmus starten wir mit einem bei der USU domain-adaptierten Modell.
Wir verwenden außerdem die intern entwickelte Multi-Target-Transformer-Library, wodurch wir ein Modell erhalten, welches für alle Targets Vorhersagen liefern kann. Dieses Modell wurde auf der CPU für etwa 24 Stunden trainiert und war bereits nach 13 Stunden besser als das klassische ML-Modell. Damit sind wir an dieser Stelle mit DL deutlich langsamer als mit dem klassischen ML.
Noch ein Hinweis zur Domainadaptation: Im DL ist es möglich, bereits trainierte Modelle wieder zu laden und weiter anzupassen und damit ein Finetuning auf Daten der Zieldomäne durchzuführen. Wir haben ein allgemeines, vortrainiertes Sprachmodell genutzt und auf unsere spezielle Anwendung, also auf Ticketdaten, angepasst. Dieses Training lief für 22 Stunden auf 4 A100 NVIDA GPUs und kann nun für alle Kunden des Ticketroutings verwendet werden. Ein initiales Training, das von einem domain-adaptierten Modell startet, ist bis zu sechs Mal schneller fertig als ein Training, das auf einem allgemeinen Sprachmodell gestartet wurde. Außerdem erhöht die Domainadaptation die Modellgenauigkeit.
Ticket-Klassifikation
Wir geben die Modellgenauigkeit mit dem gewichteten F1-Score an. Er wird auf den Tickets des Evaluationsdatensatzes berechnet. Mit dem klassischen ML erreichen wir eine Genauigkeit von 75,2 % und mit dem DL-Ansatz 83,4 %. Eine Ticketklassifikation im Live-Betrieb dauert in beiden Fällen im Bereich einer zehntel Sekunde.
Optimierung des Modelltrainings
Um die Modelle stets aktuell zu halten, führen wir beim Kunden wöchentlich ein Training durch. In dem für dieses Experiment verwendeten Datensatz kommen pro Woche um die 1.000 neue Tickets dazu. Die Größe des Datensatzes ändert sich dabei nicht, da die ältesten 1.000 Tickets dann nicht mehr berücksichtigt werden. Beim klassischen ML wird wöchentlich ein komplettes Training durchgeführt. Sobald das neue Modell deployed ist, wird das alte verworfen.
Damit geht das bisherige Wissen der Modelle verloren und es kommt jede Woche eine Rechendauer von 4 Stunden dazu. Bei den Transformer des DL-Ansatzes können wir jede Woche einfach das aktuelle Modell verwenden und ein bisschen weiter trainieren. Hierzu werden die neuen Tickets im Datensatz stärker gewichtet, sodass das Training weniger als eine Stunde dauert.
Im DL nutzen wir ein Early-stopping. Hierbei wird stetig überprüft, wie stark sich das Modell gegenüber der letzten Evaluation verbessert hat. Sobald sich das Modell, über eine definierte Anzahl an Evaluationen, nicht mehr wesentlich verbessert hat, wird das Training beendet. Im Vergleich zu einer festen Trainingsdauer oder festen Epochenanzahl sparen wir einiges an Rechenzeit, da sich die Modelle gegen Ende nur sehr langsam ihrer maximalen Genauigkeit nähern.
| Klassisches Machine Learning | Deep Learning | |
| Initiales Training | 4 Stunden | 24 Stunden |
| Retraining | 4 Stunden | 1 Stunde |
| Inferenzzeit | ~ 1/10 s | ~ 1/10 s |
| Modellgenauigkeit | 75,2 % | 83,4 % |
| Dauer für Modelltraining in einem Jahr | 208 Stunden | 75 Stunden |
Conclusio
Wir haben gesehen, dass das auf klassischem ML basierende Ticketrouting nicht sehr nachhaltig ist, da die Modelle jede Woche von Null an trainiert werden. Das Ticketrouting mit DL ist deutlich komplexer als der klassische Ansatz, jedoch können die aktuellen Modelle immer weiterverwendet werden. Sie werden lediglich auf die neuesten Daten angepasst. Zudem liefert das DL ein signifikant präziseres Modell. Mit diesem können in der Folge erheblich mehr Tickets automatisch klassifiziert werden. Das bringt Kunden einen großen Mehrwert. Auf ein Jahr gerechnet verbraucht das Training für das klassische ML mit 208 Stunden deutlich mehr Ressourcen als das DL mit 75 Stunden.
Dabei wurden jeweils ein initiales Training und 51 weitere, wöchentliche Retrainings angenommen. Die Ressourcen für die Domainadaptation wurden hier nicht berücksichtigt, da diese einmalig durchgeführt wurde und nun für alle zukünftigen initialen Modelltrainings und Kunden zur Verfügung steht. Unsere Darstellung zeigt, dass die zunehmende Modellkomplexität eine nachhaltigere Modellentwicklung durch eine geschickte Trainingspipeline nicht ausschließt.
