Erstellen Ihrer Taxonomiestruktur

Einer der grundlegendsten Faktoren, die bestimmen,wie gut Ihr Modell funktioniert und wie gut es Ihre Geschäftsziele erfüllt, ist die Struktur Ihrer Taxonomie, einschließlich der Informationen, die von den einzelnen Bezeichnungen erfasst werden.

Es ist daher wichtig, dass Sie vor dem Modelltraining über Ihre Zieltaxonomiestruktur denken. Allerdings sollten Sie über ein gewisses Maß an Flexibilität verfügen, um es im Verlauf des Trainings (nach Bedarf) anzupassen, zu erweitern und zu verbessern. Das nennen wir den „datengestützten“ Trainingsansatz.

Letztendlich sollten die Beschriftungen in der Taxonomie und die für jede Beschriftung bereitgestellten Trainingsbeispiele eine genaue und ausgewogene Darstellung des Datasets als Ganzes erzeugen. Jede Beschriftung sollte aber auch nützlich sein, indem sie in irgendeiner Weise die Nachrichten eindeutig darstellt, für die sie vorhergesagt wird.

Wenn Beschriftungen verwendet werden, um sehr umfassende, vage oder unklare Konzepte zu erfassen, ist die Wahrscheinlichkeit nicht nur höher, dass sie schlecht funktionieren, sondern es ist auch weniger wahrscheinlich, dass sie einen Geschäftswert bieten. Dies kann nützliche Einblicke in dieses Konzept geben oder dazu beitragen, dass ein Prozess im Anschluss vollständig oder teilweise automatisiert wird.

Beispiel für die Taxonomiestruktur

Dies ist ein Beispiel für eine Taxonomie auf hoher Ebene mit typischen Bezeichnungen, die für verschiedene Anwendungsfälle/Branchen anwendbar sind. Nicht alle davon sind auf Ihr Modell anwendbar.

Um dies in einen Kontext zu bringen, stellen Sie sich ein Beispiel aus einem echten Anwendungsfall vor:

Ein Unternehmen erhält jedes Jahr Millionen von E-Mails von Kunden in verschiedenen Posteingängen zu einer Vielzahl von Problemen, Fragen, Vorschlägen, Ansprüchen usw.

Dieses Unternehmen beschließt, seine betriebliche Effizienz, Prozessstandardisierung und Transparenz über die Vorgänge in seinem Unternehmen zu erhöhen, indem es diese E-Mails von Kunden automatisch in Workflow-Tickets umwandelt. Diese können dann mithilfe bestimmter Prozesse und innerhalb festgelegter Zeitpläne nachverfolgt und bearbeitet werden.

Dazu entscheiden sie sich dafür, die Plattform zu verwenden, um diese eingehende, unstrukturierte Kommunikation zu interpretieren und eine Klassifizierung in Bezug auf den Prozess und Unterprozess bereitzustellen, auf den sich die E-Mail bezieht. Diese Klassifizierung wird verwendet, um das Workflow-Ticket zu aktualisieren, das automatisch mit einem Automatisierungsdienst erstellt wird, und sicherzustellen, dass es an das richtige Team oder die richtige Person weitergeleitet wird.

Um sicherzustellen, dass dieser Anwendungsfall so erfolgreich wie möglich ist und um die Anzahl der Ausnahmen zu minimieren (falsche Klassifizierungen oder E-Mails, die die Plattform nicht sicher klassifizieren kann), sollte jede eingehende E-Mail eine sichere Vorhersage erhalten, die ein übergeordnetes Label und ein übergeordnetes Element hat eine untergeordnete Bezeichnung, d. h. [Prozess X] > [Unterprozess Y].

Wie sollte diese Taxonomie also strukturiert sein?

Da das Ziel darin besteht, jede eingehende E-Mail mit einem [Prozess] und [Unterprozess] zu klassifizieren, sollte jede Beschriftung in der Taxonomie diesem Format entsprechen:

Beispieltaxonomie nach einer Struktur von [Prozess X] > [Unterprozess Y].

Was soll mit den Beschriftungen erfasst werden?

In diesem Anwendungsfall könnte jede E-Mail, die keine sichere Vorhersage sowohl für eine übergeordnete als auch für eine untergeordnete Beschriftung enthält, eine Ausnahme sein, die zur manuellen Überprüfung und Ticketerstellung gesendet wird. Wenn er jedoch eine hochkonfidente Vorhersage der übergeordneten Bezeichnung, aber keine sichere Vorhersage der untergeordneten Bezeichnung hat, könnte dies dennoch verwendet werden, um die E-Mail teilweise weiterzuleiten oder ein Ticket zu erstellen, mit etwas zusätzlicher manueller Arbeit, um den relevanten Unterprozess hinzuzufügen.

Wenn wir uns vorstellen, dass Ersteres der Fall ist und jede E-Mail ohne eine Vorhersage mit hoher Konfidenz in Form von [Prozess] > [Unterprozess] zu einer manuellen Ausnahme wird, möchten wir sicherstellen, dass alle Beispiele, die wir für jede Bezeichnung angeben, wenn zum Trainieren des Modells dieses Format widerspiegeln.

Jede übergeordnete Bezeichnung in der Taxonomie sollte sich auf einen breiten Prozess beziehen, der für den Inhalt in den E-Mails relevant ist, z. B 'Rechnungsstellung '. Jede untergeordnete Bezeichnung sollte dann ein spezifischerer Unterprozess sein, der sich unter einer übergeordneten Bezeichnung befindet, z. B „Rechnungsstellung“ > „ Statusabfrage“.

Denken Sie daran, dass es wichtig ist, dass jede Bezeichnung eindeutig ist, was sie erfassen möchte. Sehr breite Beschriftungen wie „Allgemeine Abfrage“ oder „Alles andere“ können sehr nicht hilfreich sein , wenn viele verschiedene, unterschiedliche Themen zusammengeführt werden und kein klares Muster oder Gemeinsamkeit zwischen den angehefteten Beispielen besteht.

In diesem Anwendungsfall würden sie auch keinen großen Geschäftswert bieten, wenn ein Workflow-Ticket erstellt und als „Allgemeine Abfrage“ oder „Alles andere“ klassifiziert wurde. Dennoch muss jemand sie sorgfältig lesen, um zu verstehen, worum es geht und ob es für das eigene Team relevant ist, bevor Maßnahmen ergriffen werden können.

Dadurch wird der Nutzen der Zeitersparnis zunichte gemacht und das Unternehmen hätte keine nützliche Informationen darüber, welche Arbeit tatsächlich von den Teams erledigt wurde.

Hinweis: Dies ist nur ein Beispiel dafür, wie Sie eine Taxonomie für einen bestimmten Anwendungsfall strukturieren können. Es handelt sich nicht um einen universellen Ansatz. Jedes Projekt erfordert eine eindeutige Taxonomie von Bezeichnungen, die stark von Ihrem spezifischen Anwendungsfall, Dataset und Ihren Zielen abhängt.