Ausgangslage
Die effiziente und richtige Klassifizierung von Support-Tickets ist eine der bekannten Herausforderungen im Service-Management Bereich. Das korrekte und zeitnahe Routing von Anfragen in die richtige Abteilung ist essenziell, um dem Kunden rasch bei der Lösung seines Problems behilflich zu sein. In der Realität werden aber viele Tickets erst spät oder der falschen Abteilung bzw. Kategorie zugeordnet, weil der zuständige Dispatcher meist überlastet ist und sich nicht immer die Zeit nimmt, die Tickets genau zu lesen und zu verstehen.
Ziel
Das Routing von Tickets soll mittels künstlicher Intelligenz automatisch erfolgen. Somit kann sowohl die Geschwindigkeit, bis eine Anfrage in der richtigen Abteilung ankommt, maximiert werden, als auch die Qualität der Zuweisung gesteigert werden.
Umsetzung
Machine Learning Modelle müssen mit Daten gefüttert werden – ein Modell ist immer nur so gut, wie die Daten, mittels denen es trainiert wird. Um ein Ticket-Klassifikations System von Grund auf zu trainieren, wäre also ein grosser Datensatz an Tickets und derer Klassifizierung nötig, um befriedigende Ergebnisse zu erzielen – in einer Testumgebung nicht unbedingt ein reales Szenario. Meist enthalten diese Daten auch sehr sensible Inhalte, welche Firmen nicht einfach so herausgeben, um ein ML-Model für einen Proof of Concept zu trainieren.
Versuche, mittels OpenAI «Fake» Datensätze zu generieren, oder öffentlich verfügbare Datensätze zu verwenden, waren leider nicht sehr Erfolg versprechend, die mit diesen Daten trainierten Modelle waren zu ungenau.
Zero-Shot Klassifizierung
Zero-Shot-Klassifizierung bedeutet, dass ein Klassifizierungsalgorithmus ohne Trainingsdaten auskommt. Stattdessen wird ein allgemeines Modell der zu klassifizierenden Objekte erstellt. Dieses Modell wird dann verwendet, um neue Objekte zu klassifizieren, ohne dass zuvor Trainingsdaten für diese Objekte erfasst wurden. Klingt nach Zauberei, ist aber eigentlich ganz einfach. Das in diesem Fall verwendete Model (svalabs/gbert-large-zeroshot-nli · Hugging Face) basiert auf dem German-BERT Model (German BERT | State of the Art Language Model for German NLP (deepset.ai)). Dieses wurde mittels einem kompletten Wikipedia Dump, dem deutschen Recht, sowie ca. 3.6 GB an News-Artikeln trainiert. Zusätzlich dazu wurde es mittels Natural Language Inference (NLI) trainiert – dabei werden dem Modell 2 Sätze geliefert, anhand derer es lernen soll, inwiefern diese zueinander stehen (Widerspruch, neutral, die Folge von)
Mehr zum Thema Zero-Shot sowie NLI unter Zero-Shot Learning in Modern NLP | Joe Davison Blog (joeddav.github.io)
Eingesetzte Technologien / Tools
- Matrix42 Enterprise Service Management
- API Schnittstelle für Prediction (Python)
- Webservice-Addon für Matrix42 (C#)
Architektur

Classifier (KI)
Der Classifier ist eine API Schnittstelle, welche mittels dem Framework FLASK (Python) realisiert wurde:
#Laden des Modelles
zershot_pipeline = pipeline("zero-shot-classification",
model="svalabs/gbert-large-zeroshot-nli")
@app.route('/api/category', methods=['POST'])
def category1():
if not request.json or 'description' not in request.json:
abort(400)
description = request.json['description']
#Hard-Coded for PoC - could be dynamic in Real-Life
labels = ["IT", "Facility Management", "Human Ressources", "Sales", "Marketing", "Finance", "Legal", "Other"]
result = zershot_pipeline(description, labels)
print(result['labels'][0])
pred_json = json.dumps({'class_predicted': result['labels'][0], 'predict_proba': result['scores'][0]})
print(pred_json)
return pred_json
Der Output bei einem Test mittels Postman sieht dann wie folgt aus:

Um nun innerhalb von Matrix42 eine Klassifizierung zu erhalten, wurde die Logik im Self-Service-Portal implementiert. Möglich wäre es auch beim Ticket Erstellen mittels CoRu etc. Dafür wurde zur API Abfrage ein Webservice erstellt, welcher relativ einfach in der Matrix42 Applikation registriert und genutzt werden kann. Der Vorteil eines eigenen Webservices dafür ist, dass die API URL nicht preisgegeben werden muss und bei Bedarf diese auch mittels Token gesichert werden kann.
DescriptionData descriptionSend = new DescriptionData();
descriptionSend.description = subject + " " + descriptionRaw;
String jsonData = JsonConvert.SerializeObject(descriptionSend);
HttpClient client = new HttpClient();
var content = new StringContent(jsonData, Encoding.UTF8, "application/json");
try
{
var response = await client.PostAsync(ConfigURI, content);
var result = await response.Content.ReadAsStringAsync();
response.EnsureSuccessStatusCode();
return JsonConvert.DeserializeObject<object>(result);
}
catch (HttpRequestException e)
{
return "Error on API " + e.Message;
}
}
Dieser neue Webservice kann wiederum im Layout-Designer eingebunden und verwendet werden.

Das Ergebnis ist eine ziemlich genaue Klassifizierung der Tickets. Für einen produktiven Einsatz müsste das Modell regelmässig mit echten Daten trainiert werden, um seine Präzision zu erhöhen. Auch ist zu bemerken, dass die Klassifizierung ohne Training des Modells auf einer hohen Ebene stattfindet (IT / Facility-Management / Sales etc.).
Weitere mögliche Anwendungsfälle
- Automatische Priorisierung & Klassifizierung der Tickets
- Erkennen von Zusammenhängen einzelner Störungen
- Automatisches Antworten mittels Knowledge-Base Einträgen
Nächste Posts: Chatbot-Integration (In Arbeit)
