CubicMind Support System -> more than just ticketing <-

Transkript

1 Bakkalaureatsarbeit CubicMind Support System -> more than just ticketing <- für Projektpraktikum mit Bakkalaureatsarbeit am Institut für Medizinische Kybernetik und Artificial Intelligence betreut durch ao.prof.univ.-doz.dipl.-ing.dr.harald Trost Name: Gerald Seidler MatNr.: StdKz.: e gerald@cubicmind.at /28 v2.0

2 1 Inhaltsverzeichnis 1 INHALTSVERZEICHNIS 2 2 EINFÜHRUNG 4 3 BEGRIFFSERKLÄRUNGEN INTELLIGENTE HELP-SYSTEME TROUBLE TICKET-SYSTEME 5 4 TECHNOLOGIE & SYSTEM-ARCHITEKTUR PROBLEMSTELLUNG/LÖSUNGSANSATZ CASE BASED REASONING (CBR) DER CBR-PROZESS ANWENDUNG NATURAL LANGUAGE PROCESSING (NLP) ALLGEMEINES ANWENDUNG GEWICHTUNG I GEWICHTUNG II ZUSAMMENHANG CBR & NLP LERNEN DATENBANKMODELL RELATIONEN Relationen mit Datentypen NESTED SET MODEL Motivation NSM Theorie Vorteile Nachteile Erweiterungen ANWENDUNG SYSTEM-ARCHITEKTUR ALLGEMEINES USER INTERFACE Admin Interface Agent Interface User Interface USER PROFILER CBR MODUL Parser Weigher Similar Case Retriever (SCR) Refinement Learner LEMMATIZER DATENQUELLEN SERVER-VERTEILUNG ERWEITERUNGS-MÖGLICHKEITEN CATEGORY INVENTOR /28 v2.0

3 Funktionsweise Aktivierung AUTO-PRIORITIZATION AUTO-ASSIGNMENT & REQUEST FORWARDING 27 5 ZUSAMMENFASSUNG 27 6 ABKÜRZUNGS-VERZEICHNIS 28 7 LITERATURLISTE /28 v2.0

4 Abstract Die Erstellung eines selbstlernenden Support-Systems führt zu einem Verschmelzen bisher voneinander getrennt betrachteter Gebiete: intelligente Help-Systeme und Trouble Ticket Systeme. Nach der Erläuterung der Grundlagen dieser Gebiete wird gezeigt, wie mittels (Reinforcement-Trained) Case Based Reasoning die Grundideen dieser beiden Welten verbunden werden können. Die Umsetzung dieser Verschmelzung in eine natürlichsprachige, Datenbankgestützte und Browser-basierte Geschäftsanwendung ist das Ziel dieser Arbeit. Bei der Software-Erstellung werden aktuellste Technologien angewandt, welche durch das Microsoft.NET Framework bereitgestellt werden. 2 Einführung Die Grundidee hinter der Entwicklung eines selbstlernenden Support-Systems stammt aus der aktiven Mitarbeit des Autors in der EDV-Abteilung der Billa Dienstleistungs-GmbH im 1st-highest Level Support über eine Dauer von über drei Jahren. Trouble Ticket Systeme sind für die Unterstützung dieser Arbeit prinzipiell sehr gut geeignete Werkzeuge, bieten diese Unterstützung aber "nur" bei der Verwaltung von eingehenden Problemfällen. Da in der Praxis aber viele Problemfälle häufiger auftreten, ist es nahe liegend eine automatische Abwicklung dieser anzustreben. Bei diesbezüglichen Recherchen kristallisierten sich intelligente Help-Systeme (auch "intelligent Assistance Systems" genannt) als artverwandte Anwendungen und Reinforcement-Trained Case Based Reasoning als geeignete Technologie zur Wissensverarbeitung heraus. Ebenso wichtig sind Teilaspekte des NLP (Natural Language Processing). Diese Gebiete wurden im Vorfeld dieser Arbeit gesondert in [1] ausgearbeitet und erklärt. Im nächsten Abschnitt werden nochmals die wichtigsten Grundlagen von intelligenten Help-Systemen und Trouble Ticketing Systemen erläutert und danach zum Hauptteil dieser Arbeit der Erläuterung der System-Architektur in Verbindung mit den eingesetzten Technologien übergegangen. Daraufhin werden abschließend Möglichkeiten zur Erweiterung des Systems angeführt. In der vorliegenden Ausarbeitung werden teilweise englische Begriffe verwendet, welche nicht übersetzt werden. Diese Begriffe sind im Fachjargon gängig und Übersetzungen dieser würden eher zur Verwirrung führen als dem allgemeinen Verständnis dienen. Weiters sei angemerkt, dass im Anhang ein Abkürzungsverzeichnis zu finden ist /28 v2.0

5 3 Begriffserklärungen 3.1 intelligente Help-Systeme Zuallererst sei anzumerken, dass der Begriff intelligentes Help-System kein standardisierter, genormter oder offizieller Ausdruck ist, sondern in dieser Arbeit als Überbegriff - in der Literatur findet sich auch der Begriff (intelligent) Assistance System für folgende Definition dient: Ein intelligentes Help System ist ein Natural Language Interface, welches in einer abgeschlossenen Domäne - auf natürlichsprachige Fragen mit ebenso natürlichsprachigen Antworten reagiert und unterschiedliche intelligente Funktionen zur Interaktion mit dem Menschen zur Verfügung stellt. Die Grundkomponenten eines solchen Systems zeigt folgende Abbildung: Abb. 1: Help-System Grundkomponenten Nach der Eingabe einer Frage in natürlicher Sprache wird diese Frage (nach syntaktischer und semantischer Analyse) im Inferenz-System weiterverarbeitet um zusätzlich deren - zwar nicht direkt angeführte, aber zum Textverständnis notwendige - Inhalte zu erhalten. Danach wird durch unterschiedliche Methoden ein Konstrukt für eine entsprechende Antwort ermittelt (Answer-Retrieval) und in der weiteren Folge dieses Konstrukt mittels einer Sprach-Generierungs- Komponente zur ausgegebenen natürlichsprachigen Antwort umgewandelt. 3.2 Trouble Ticket-Systeme Trouble Ticket-Systeme (TTS) werden aufgrund ihres Einsatzortes auch Help Desk-Systeme genannt - eine weitere Bezeichnung lautet Ticket Request System (TRS). Ihre Entwicklung geht meist nicht aus wissenschaftlicher Forschung hervor diese ist für deren Erstellung auch nicht notwendig. Das Ziel solcher /28 v2.0

6 Systeme ist eine möglichst übersichtliche Verwaltung eingehender Problemstellungen und die (organisierte) Aufteilung dieser auf die Support- Mitarbeiter. Jedes eingehende Problem (zb per Telefon, etc) wird als neues Ticket angenommen, welches wie man sagt - gezogen wird. Hauptziel solcher Anwendung ist er Einsatz im kommerziellen Bereich Hauptaugenmerk wird hier auf die Vereinfachung, Optimierung und Verbesserung von Abläufen in Support-Abteilungen gelegt. Die Grundfunktionalität eines TTS lässt sich wie folgt veranschaulichen: Abb. 2: Architektur TTS Ein Trouble Ticket (TT) besteht aus Problem und zugehöriger Lösung. Trifft nun ein neues Problem beim System ein (zb per Telefon, , System-Oberfläche etc) wird ein neues Trouble Ticket erstellt und die Problembeschreibung dazu abgespeichert. Sobald sich ein Help Desk Mitarbeiter (in weiter Folge auch Agent genannt) dieses Problems annimmt also das Ticket öffnet geht es in den Status in Bearbeitung über. Dies hat den Sinn, dass kein weiterer Agent das gleiche Ticket öffnet und parallel bearbeitet. Nun gibt es mehrere Möglichkeiten: 1. Der Agent findet eine Lösung, diese wird zum TT gespeichert und das TT wird geschlossen (als erledigt markiert). 2. Der Agent findet keine Lösung und gibt das TT für die Bearbeitung durch einen anderen Agent wieder frei /28 v2.0

7 3. Der Agent gibt das Problem (direkt) an einen anderen Agent weiter. In der Folge können wiederum Möglichkeit 1, 2 und 3 eintreten. Die Sammlung aller Trouble Tickets ergibt eine Art Wissensdatenbank, die in den meisten TT-Systemen auf eine einfache Art und Weise durchsuchbar sind (zb: Suche nach Schlagwort) oder als FAQ (Frequently Asked Questions) widergespiegelt werden kann. 4 Technologie & System-Architektur 4.1 Problemstellung/Lösungsansatz Bei der Erstellung eines selbstlernenden Support Systems sieht man sich mit einigen interessanten Herausforderungen konfrontiert. So stellt sich zum einen die Frage, wie sich aus dem bisherigen Datenstand eine Antwort auf eine neue Frage finden lässt, und zum anderen wie aus einer in natürlicher Sprache gestellten Frage der entsprechende Informationsgehalt extrahiert werden kann. Der Ansatz des CubicMind Support Systems ist nun die Vorteile der beiden im vorherigen Abschnitt erläuterten Welten zu verbinden. Es basiert einerseits auf dem Grundgedanken eines TTS, soll aber andererseits die Möglichkeit bieten, auf eingehende Problemlösungs-Anfragen automatisch entsprechende Antworten zu geben. Hierbei wird allerdings anders vorgegangen, als dies bei den in [1] vorgestellten Help-Systemen der Fall ist. Die Antwort auf eine Frage soll nicht generiert werden, sondern aus den bisherigen Antworten eine oder mehrere entsprechende (bzw. entsprechendste) ausgewählt werden bzw., wenn eine solche nicht gefunden werden kann, wird das Problem an einen (menschlichen) Agent weitergeleitet. Das CubicMind Support System umfasst ein komplettes TTS wie es in Abb. 2 dargestellt ist das Herzstück übernimmt aber die Funktion eines "vorgeschalteten" Agents, welcher bei Nicht-Erfolg seiner Problemlösung dieses Ticket wieder "zurücklegt" und so für die Bearbeitung durch einen menschlichen Agent freistellt. Die Grundaufgabe besteht also darin, eine eingehende Anfrage mit schon gestellten Anfragen zu vergleichen und bei Übereinstimmung (welche nach bestimmten Algorithmen - basierend auf Keywords und deren Gewichtungen - berechnet wird) die zu dieser Übereinstimmung gespeicherte Antwort auszugeben. Für das Suchen nach diesen Übereinstimmungen wird die Technologie Case Based Reasoning (CBR) in Verbindung mit Reinforcement Learning (RL) eingesetzt, was in Kombination Reinforcement-Trained CBR (RETCBR) genannt wird /28 v2.0

8 4.2 Case Based Reasoning (CBR) Case Based Reasoning und die Erweiterung Reinforcement-Trained CBR (RETCBR) wurden bereits in [1] genau erläutert zur besseren Übersicht wird in der Folge der CBR-Prozess nochmals angeführt Der CBR-Prozess Der Prozess des CBR lässt sich in fünf Schritte gliedern [2][3]: 1. Indexing & Organization Die gespeicherten Fälle werden je nach Bedürfnis indiziert und in eine brauchbare Struktur gebracht. Dies passiert von Anfang an durch das System, da dieses genau darauf ausgelegt ist. Es werden zu jeder Frage auch die einzelnen Wörter genauer gesagt deren Stammformen gespeichert und miteinander in Verbindung gebracht. 2. Retrieval Bei einer neuen Problemstellung werden entsprechende (möglichst ähnliche) Fälle (dh. Fragen) ausgewählt. Durch concept refinement methods oder partial matching (oder eine Kombination aus beiden)[2] wird dann der ähnlichste Fall ausgewählt. - Beim Support System werden aufgrund bestimmter Algorithmen (siehe sie basieren hptsl. auf Keywords und deren Gewichtungen) die ähnlichsten Antworten ausgewählt. 3. Adaption Stimmt die neue Problemstellung (und damit auch die Lösung) nicht genau mit der gefundenen überein, so muss die Lösung auf den neuen Fall adaptiert werden. Die Adaption findet im Support System nicht bzw. nur minimal statt in Antworten werden nur User-Daten abgeändert. 4. Testing Die neue Problemlösung muss getestet werden, damit sie im nächsten Schritt in die Case Library aufgenommen werden kann. für Anwendung im Support- System siehe Pkt Learning Hat die neue Lösung die Phase 4 bestanden, so wird sie in die Case Library aufgenommen. War dies nicht der Fall, so muss versucht werden diesen Fehler in Zukunft zu verhindern. Im CubicMind Support System wird der Begriff Learning auf das Aufnehmen in die Case-Library beschränkt, weil durch den Benutzer vermeintlich erkannte Fehler keine sein müssen, da der User (als nicht EDV- Mitarbeiter) selbst keine zuverlässige Quelle darstellt (da er über kein bzw. ungenügend Domänenwissen verfügt). Es wird jedoch davon ausgegangen, dass der User keine falschen Antworten als richtig deklariert (richtige jedoch schon) Anwendung CBR ist eine fast maßgeschneiderte Technologie für Question & Answer Systeme. Es wird hier in Verbindung mit der Kategorisierung von Fällen und deren textueller Auswertung eingesetzt. RETCBR wird möglichst sparsam eingesetzt, da die Lösungsfindung sonst lang und umständlich wäre genauer gesagt wird es in CBR-Phase 4 (Testen) /28 v2.0

9 verwendet, wodurch es möglich wird, dass selbst ein User ohne Domänenwissen diesen Schritt durchführen kann der User muss nur die Auswahl treffen, ob die vorgeschlagene Lösung zum Ziel führt oder nicht. Der sich daraus ergebende Vorteil ist, dass das System selbst die Lösung nicht zu testen braucht, was die Erstellung eines solchen Programms wesentlich weniger komplex macht. 4.3 Natural Language Processing (NLP) Allgemeines NLP ist ein umfassender Bereich der AI, der sich zb Verständnis und Generierung natürlicher Sprache, Dialogsysteme und maschinelle Übersetzung - um nur einige zu erwähnen auseinandersetzt[4]. Hierbei werden Technologien wie morphologische Analyse oder Thesauren (diese Gruppieren Wörter nach Ähnlichkeit) [5]. Die meisten dieser Technologien benötigen große Informationssammlungen und arbeiten entsprechend zeitintensiv Anwendung Um diese beiden Probleme möglichst zu umgehen wird ein anderer (aber nicht unverwandter) Ansatz verwendet: Eine Frage in natürlicher Sprache soll möglichst erst zum Einsatz kommen, wenn ein entsprechender Fall nicht allein durch die Eingrenzung der Kategorisierung der Fälle gefunden werden kann. Die Kategorisierung selbst bietet eine Grundstruktur durch die die Nähe verschiedener Fälle und Worte gegeben ist. Es wird versucht den Informationsgehalt eines Wortes bezüglich des Falles, in dem es vorkommt, im Vergleich zu anderen Fällen, zu bewerten. Im Folgenden wird dies genauer ausgeführt. Wird eine neue Frage eingegeben, so werden zuerst die Stammformen der einzelnen Wörter gespeichert und zunächst überprüft, ob solche ohne besonderen Informationsgehalt enthalten sind (zb Bindewörter). Wenn ja, werden diese aus den nachfolgenden Schritten ausgeschlossen. Nun wird jedes einzelne Wort (genauer gesagt die Stammform jedes Wortes) der Frage wie folgt analysiert: Anmerkung: Es wird davon ausgegangen, dass die Fragen in einer Baumarchitektur nach Kategorien gespeichert werden (siehe folgende Abbildung). Eine Kategorie kann gleichzeitig Sub-Kategorien und Fragen enthalten. Näheres dazu folgt im Datenbank-Kapitel /28 v2.0

10 Abb. 3: Schematische Darstellung der Kategorie/Fall- Struktur Gewichtung I Wörter werden in diesem ersten Gewichtungs-Schritt in verschiedene Prioritäten eingeteilt: Priorität 0 (= von der Suche ausschließen): Das Wort kommt nun in allen (Sub-)Kategorien vor. Wort kommt zum 1. Mal vor Priorität 1: Wort kommt bisher in nur einer Frage vor Priorität 2: Das Wort kommt nur in Fragen einer Kategorie (ohne Unterkategorien) vor. Priorität 3: Das Wort kommt im Namen einer (Sub-)Kategorie vor, die Kategorie ist nicht Root. Das Wort kommt in den Namen mehrerer (Sub-)Kategorien vor, deren kleinste gemeinsame Überkategorie (kgü) nicht Root (Wurzel der Baumstruktur) ist. Das Wort kommt in Fragen mehrerer (Sub-)Kategorien vor, deren kgü nicht Root (Wurzel der Baumstruktur) ist. Priorität 4: Das Wort kommt im Namen der Root-Kategorie vor. Das Wort kommt in den Namen mehrerer (Sub-)Kategorien vor, deren kgü Root (Wurzel der Baumstruktur) ist. Das Wort kommt in Fragen mehrerer (Sub-)Kategorien vor, deren kgü Root (Wurzel der Baumstruktur) ist /28 v2.0

11 4.3.4 Gewichtung II Für alle Wörter, die den Prioritätsklassen 2 bis 4 zugeordnet wurden, wird zusätzlich eine Gewichtung aufgrund der Häufung des Vorkommens von Fällen (Fragen), welche das jeweilige Wort (ein- oder mehrmals) enthalten, in den verschiedenen Kategorien vorgenommen. Ziel ist es innerhalb der einzelnen Prioritätsklassen eine weitere Rangordnung einzuführen. (Wörter aus Prioritätsklasse 1 haben alle das gleiche bzw. kein Gewicht). VK AK VU AU VUR Vorkommen entsprechender Fälle direkt in einer Kategorie Anzahl aller Fälle direkt in einer Kategorie Vorkommen entsprechender Fälle in einer Über-Kategorie (dh. Kategorie inkl. Unterkategorien) Anzahl aller Fälle in Über-Kategorie (inkl. Unter-Kategorien) Vorkommen entsprechender Fälle im gesamten Baum (also VU mit U = Root) Tab. 1: Variablen Gewichtung II Prioritätsklasse Formel 2 VK / AK 3 VU / AU 4 1 / VUR Tab. 2: Formeln Gewichtung II Je höher das errechnete Gewicht ist, desto besser eignet sich das jeweilige Wort innerhalb seiner Prioritätsklasse zum Ermitteln des richtigen Ergebnisses (bzw. desto wahrscheinlicher ist dies). 4.4 Zusammenhang CBR & NLP Nach diesen beiden Arten der Gewichtung wird wie folgt vorgegangen: Zuerst wird nach Fällen gesucht, welche Wörter der obersten Priorität enthalten. Diese liefern die (voraussichtlich) besten Ergebnisse. Dann wird mit den Wörtern der 2.-höchsten Priorität (Wort = Kategoriename) fortgefahren. Die Suche beschränkt sich auf die entsprechende Kategorie (samt Sub-Kategorien). Hier wird mit dem am höchsten gewichteten Wort begonnen und die zu dieser Gewichtung zugehörige Kategorie ausgewählt. In dieser wird nach dem nächst schlechter bewerteten Wort fortgefahren usw. Sobald auf diese Weise ein Fall eindeutig identifiziert wird, stoppt die Suche. Analog wird bei 3.-höchster Priorität verfahren mit Beschränkung auf entsprechende Überkategorie. Bei 4.-höchster Priorität wird der Root-Knoten als Beschränkung verwendet. Damit ist die Phase 2 (Retrieval) des CBR-Prozesses abgeschlossen. Adaption (Phase 3) ist keine vorgesehen es werden nur die zu den ausgewählten Fällen passenden Lösungen ausgegeben (über eine einfache Datenbank-Abfrage). Damit wären wir bei Phase 4 (Testing) angelangt /28 v2.0

12 Das Testen erfolgt - wie schon erwähnt - auf denkbar einfache Weise der User gibt an, ob ihm die jeweilige Lösung geholfen hat oder nicht Lernen Wurde eine Antwort gefunden, so wird diese mit der Frage verknüpft. Dies ist ein einfacher Vorgang, hat aber zwei große Auswirkungen: 1. Die Frage wird der entsprechenden Kategorie zugeordnet und 2. dadurch mit den anderen Fragen in dieser Kategorie in eine Art Nähe- Verhältnis gesetzt. Wurde keine Antwort gefunden so wird die Frage an den Support Agent weitergeleitet. Dieser hat dann die Möglichkeit, nochmals nach Antworten zu suchen oder die Frage mit einer bestehenden Antwort zu verbinden. Muss der Support Agent eine neue Antwort erstellen, so wird diese dann mit der Frage verbunden /28 v2.0

13 4.5 Datenbankmodell In Abbildung 4 ist das grundsätzliche Datenbank-Model ersichtlich. Abb. 4: Datenbank-Modell CubicMind Support System /28 v2.0

14 4.5.1 Relationen agents(users.userid, answers(answerid, answertitle, answer) answers2agents(answers.answerid, agents.userid) categories(categoryid, nsmleft, nsmright, nsmparentid, category, categorytrees.treeid) categorytrees(treeid, treename, treexml) keyword_useless(keywords.keywordid, categorytrees.treeid) keywords(keywordid, keyword) *Anmerkung: ID als PrimaryKey aus Speicherplatz-Gründen question_waiting(questions.questionid) questionpriorisation(questions.questionid, agents.userid, priorisation) questions(questionid, question, categories.categoryid, questiondatetime, users.userid) questions2answers(questions.questionid, answers.answerid) questions2keywords(questions.questionid, keywords.keywordid) requestforward(questions.questionid, toagent(agents.userid)) fromagent(agents.userid), requiresadmin(answers.answerid) users(userid, userlogon, lastname, firstname) *Anmerkung: zusätzliche Felder sinnvoll je nach Anwendung Legende: fett unterstrichen: kursiv unterstrichen: fett kursiv unterstrichen: primary key foreign key primary foreign key /28 v2.0

15 Relationen mit Datentypen agents users.userid bigint(8) NOT NULL PRIMARY KEY answers answerid answertitle answer bigint(8) NOT NULL auto_increment PRIMARY KEY varchar(100) NOT NULL varchar(8000) answers2agents answers.answerid agents.userid bigint(8) NOT NULL PRIMARY KEY bigint(8) NOT NULL PRIMARY KEY categories categoryid nsmleft nsmright nsmparent category categorytrees.treeid bigint(8) NOT NULL auto_increment PRIMARY KEY bigint(8) NOT NULL bigint(8) NOT NULL bigint(8) NOT NULL varchar(50) NOT NULL int(4) NOT NULL categorytrees treeid treename treexml int(4) NOT NULL auto_increment PRIMARY KEY varchar(50) NOT NULL varchar(5000) keyword_useless keywords.keywordid categorytrees.treeid bigint(8) NOT NULL PRIMARY KEY int(4) NOT NULL PRIMARY KEY keywords keywordid keyword bigint(8) NOT NULL auto_increment PRIMARY KEY varchar(50) NOT NULL question_waiting questions.questionid bigint(8) NOT NULL questionpriorisation questions.questionid agents.userid priorisation bigint(8) NOT NULL PRIMARY KEY bigint(8) NOT NULL PRIMARY KEY smallint(2) NOT NULL /28 v2.0

16 questions questionid question categories.categoryid questiondatetime users.userid questions2answers questions.questionid answers.answerid questions2keywords questions.questionid keywords.keywordid requestforward questioins.questionid fromagent (agents.userid) toagent (agents.userid) requiresadmin answers.answerid users userid userlogon lastname firstname bigint(8) NOT NULL auto_increment PRIMARY KEY varchar(8000) NOT NULL bigint(8) datetime bigint(8) bigint(8) NOT NULL PRIMARY KEY bigint(8) NOT NULL PRIMARY KEY bigint(8) NOT NULL PRIMARY KEY bigint(8) NOT NULL PRIMARY KEY bigint(8) NOT NULL PRIMARY KEY bigint(8) NOT NULL PRIMARY KEY bigint(8) NOT NULL PRIMARY KEY bigint(8) NOT NULL PRIMARY KEY bigint(8) NOT NULL auto_increment PRIMARY KEY varchar(25) NOT NULL varchar(25) NOT NULL varchar(25) Nested Set Model Die Art und Weise wie die Kategorien mit den dazugehörenden Fällen (= Fragen) in der Datenbank gespeichert werden sollen, birgt eine interessante Herausforderung Motivation Grundsätzlich ist festzustellen, dass eine Baumstruktur geschaffen werden muss. Die klassische Speicher-Struktur dafür ist eine selbst-referenzierende adjazente Liste /28 v2.0

17 Ausgehend von folgendem Baum (die Zahlen in den Knoten sind die IDs) Abb. 5: Baumstruktur würde in der Datenbank folgendes gespeichert werden: ID ParentID Tab. 3: selbst-referenzierendes Modell Durch Einfachheit und Robustheit dieses Modells lässt sich beispielsweise ohne großen Aufwand ein Unterbaum umhängen oder löschen. Eine falsch eingetragene ParentID ergibt zwar einen logischen Fehler, beeinträchtigt allerdings nicht die Baumstruktur. Allerdings stößt man hier auf das Problem, dass entweder JOINS [6] in der Datenbankabfrage oder rekursive Methoden [7] zur DB-Abfrage benötigt werden, was die Laufzeit stark beeinträchtigt. Abhilfe schafft hier das Nested Set Model in weiterer Folge NSM genannt NSM Theorie Das NSM basiert - wie der Name schon andeutet - auf verschachtelten Mengen und ist damit vom Grundgedanken her jenem der Relationalen Datenbanksysteme artverwandt /28 v2.0

18 Das oa. Beispiel sieht in Mengendarstellung wie folgt aus: Abb. 6: Baum in Mengendarstellung Um dieses Mengen-Modell nun in der Datenbank speichern zu können, werden jedem Knoten (dh. jeder Menge) ein left- und ein right-wert in einem Preorder- Walk zugewiesen (inkrementell mit 1 beginnend), indem beim 1. Antreffen der left-wert gefüllt wird und beim 2. (und damit letzten) Antreffen der right-wert gefüllt wird [8]. In diesem Beispiel erhält man also folgendes Ergebnis: Abb. 7: Baumdarstellung im NSM bzw. als Datensätze: (siehe nächste Seite Tabelle 4) /28 v2.0

19 ID left right Tab. 4: NSM Datensätze Hierbei ist anzumerken, dass das Feld ID eigentlich nicht mehr notwendig ist, da jeder Knoten durch seinen left- bzw. right-wert (bzw. durch beide gemeinsam) eindeutig identifiziert wird Vorteile Der große Vorteil des Nested Set Models ist, dass die - bei den selbstreferenzierenden Listen erwähnten - Rekursionen und JOINS großteils umgangen werden können. Hier einige Beispiele für schnelle Berechnungen (sonst) aufwendiger Abfragen: Anzahl der Unterknoten eines Knotens (nicht Root): floor( (Knoten(right) Knoten(left)) /2 ) Anzahl aller Knoten: Root(right) /2 ist Knoten ein Blatt?: (Knoten(right) Knoten(left)) == 1 Ein Beispiel für eine schnelle sonst aufwendige Abfrage über die Tiefe aller Knoten: SELECT a.id, COUNT(*) AS Tiefe FROM NSM a, NSM b WHERE a.left BETWEEN b.left AND b.right GROUP BY a.left; Ergebnis: (siehe nächste Seite Tabelle 5) /28 v2.0

20 ID Tiefe Tab. 5: Abfrage-Ergebnis: Tiefe aller Knoten Weiters bietet das NSM eine Reihenfolge der Elemente aufgrund ihres left-wertes. So kommt in diesem Beispiel der Knoten 8 vor 9. Zusammengefasst kann man sagen, dass Lesezugriffe auf die Struktur sehr performant sind Nachteile Was beim Lesen große Vorteile bringt, wendet sich bei Schreib-Operationen ins Gegenteil. So müssen beispielsweise beim einfachen Einfügen eines neuen Elements als Blatt alle nachfolgenden Werte bei left und right um 2 erhöht werden und alle darüber liegenden beim right-wert um ebenfalls um 2 erhöht werden. Noch komplizierter und aufwendiger wird es, wenn zb Teilbäume verschoben werden sollen. Weiters ist zu beachten, dass die Laufzeit bei Schreiboperationen mit zunehmender Größe extrem anwächst. Die Robustheit ist meist schon bei einem einzigen Falsch-Eintrag gefährdet es ist also besonderes Augenmerk auf den Integritäts-Erhalt zu richten. Ein NSM eignet sich also überall dort, wo hauptsächlich gelesen werden soll Erweiterungen Eine meist sehr nützliche Erweiterung wurde schon erwähnt das ID-Feld. Eine weitere kommt aus den man könnte sagen konkurrierenden selbstreferenzierenden Listen: das zusätzliche Einfügen eines Parent -Feldes. Dies bringt den Vorteil, bei einer einfachen Abfrage über das Vater -Element eines bestimmten Elements nur ein triviales SELECT-Statement absetzen zu müssen /28 v2.0

21 4.5.3 Anwendung Für die Verwirklichung des Systems soll eine besondere Vorgehensweise eingesetzt werden. Es sollen die Vorteile des NSM erhalten bleiben und die Nachteile auf ein Minimum reduziert werden. Aus diesem Grund werden nur die Kategorien in einem NSM gespeichert. Die Cases (dh. Fragen) selbst sind in einer eigenen Tabelle gespeichert gemeinsam mit einer Referenz auf die Kategorie, der sie zugeordnet sind. Die Schreiboperationen beschränken sich damit auf eine wesentlich kleinere Datensatz-Menge die Laufzeit bleibt auf einem akzeptablen Niveau. Hier nun die Veranschaulichung als detaillierter Ausschnitt des DB-Modells: Abb. 8: Ausschnitt DB-Modell NSM /28 v2.0

22 4.6 System-Architektur Abb. 9: System-Architektur /28 v2.0

23 4.6.1 Allgemeines Das System besteht aus vier Hauptmodulen: User Interface User Profiler Lemmatizer CBR Modul Zwischen den Modulen dieser grundsätzlichen Architektur soll eine möglichst große Unabhängigkeit bestehen, sodass es zb möglich ist, statt einem intranetbasierten User Interface für den User eine eigene Applikation einzusetzen. Die systemeigenen Datenquellen sind die Datenbank, welche die Fragen, Antworten und die dazugehörenden Daten enthält, eine User-Datenbank und XML-Files, welche (sprachenabhängig) die Feldbeschriftungen etc. enthalten. Aus den externen Quellen Active Directory (Verzeichnisdienst) und WMI-Steuerung werden User-spezifische Daten, wie zb Standort und PC-Konfiguration, ermittelt User Interface Es stehen grundsätzlich drei verschiedene User Interfaces zur Verfügung Admin Interface Das Admin Interface dient zur Konfiguration und Wartung des Support Systems Agent Interface Das Agent Interface steht dem Support-Mitarbeiter zur Verfügung. Hier wird diesem zb die Weiterleitung eines Problems an einen Kollegen ermöglicht User Interface Das User Interface ist für den normalen PC-Anwender gedacht hier erhält dieser die Möglichkeit entweder durch das Durchwandern der Problem-Kategorien oder durch die Eingabe einer (natürlichsprachigen) Frage eine Lösung zu finden oder das Problem an den Support weiterzugeben User Profiler Das User Profiler Modul dient zur Ermittlung der Daten des jeweiligen Users, zb: Rechte Anmeldedaten PC-Konfiguration Standort /28 v2.0

24 4.6.4 CBR Modul Das CBR Modul ist das eigentliche Herzstück des Systems Parser Der Parser zerlegt die eingegebene Frage in einzelne Wörter und übergibt diese über den Lemmatizer (siehe 4.6.5) dem Weigher. Außerdem ist er für das Herausfiltern von zu ignorierenden Wörtern zuständig Weigher Der Weigher gewichtet die vom Parser übergebenen Worte wie in und beschrieben und erstellt daraus resultierend ein gewichtetes Modell, welches nun an den Similar Case Retriever weitergegeben wird Similar Case Retriever (SCR) Der SCR ermittelt nun die (je nach Konfiguration) x besten Fälle und übergibt diese dann dem User Interface Refinement Hier wird das zuvor erwähnte RETCBR eingesetzt findet der User nicht die gewünschte Antwort, so kann die Suche wie in 4.4 beschrieben fortgesetzt werden Learner Wird eine entsprechende Antwort gefunden, so wird diese mit der neuen Frage verknüpft (siehe 4.4.1) Lemmatizer Der sogenannte Lemmatizer stellt einen separaten Server dar. Seine Aufgabe ist das Zurückgeben der Stammformen der an ihn übergebenen Wörter bzw. Wortlisten. Dazu verwendet er eine Art Dictionary, in welchem über Wörter mit zugehöriger Stammform gespeichert sind Datenquellen Die Funktionen der Datenquellen wurden schon zuvor angeführt. Auf die Datenbanken wird nicht direkt aus dem Programm-Code zugegriffen, sondern ein DB-Zugriffs-Layer zwischengeschaltet. Dies dient der leichteren Adaptierbarkeit auf eine andere/erweiterte Datenbankstruktur. Außerdem bleiben die Implementierungsdetails der Geschäftslogik des Systems verborgen, sodass diese von Änderungen an der Datenbank-Programmierung unberührt bleibt. Besonders zu erwähnen ist weiters, dass jeglicher statischer Text im Programm nicht fest im Quelltext verankert ist, sondern über XML-Files gespeichert wird. Dies hat hauptsächlich den Vorteil, dass es ermöglicht wird, das gesamte User Interface in anderen Sprachen darzustellen, ohne am Source Code selbst Änderungen vornehmen zu müssen (sondern nur das XML-File zu ändern bzw. ein neues zu erstellen). Die Konfiguration des Systems selbst soll ebenfalls über XML-Files gespeichert werden, was eine Zeitersparnis bei Neuinstallationen oder Konfigurations- Änderungen mit sich bringt /28 v2.0

25 Während die Konfigurationens-Dateien in der aktuellen Version implementiert sind, werden die oa. Sprach-XML-Files erst in der nächsten Version verfügbar sein Server-Verteilung Nachfolgend wird veranschaulicht, welche Programmteile auf welche Server verteilt sind und wie diese untereinander kommunizieren. Abb. 10: Server-Verteilung /28 v2.0

26 4.7 Erweiterungs-Möglichkeiten Es sind diverse Möglichkeiten zur Erweiterung der Funktionalität des Support Systems angedacht. Wichtig ist hierbei die schon zuvor erwähnte, aber noch nicht implementierte, Auslagerung jeglicher statischer Texte (Beschriftungen etc.) in XML-Files, sodass diese nur ausgetauscht bzw. referenziert werden müssen um das Web-Interface in anderen Sprachen anzeigen zu können. Die drei möglichen Zusatzfunktionen "Category Inventor", "Auto-Prioritization" und "Auto-Assignment & Request Forwarding" werden in der Folge vorgestellt Category Inventor Das Modul Category Inventor in weiterer Folge CI genannt hat die Aufgabe neue Kategorien zu finden und vorzuschlagen. Der CI ist eine Automations-Hilfe für die Wartung des Systems. Das System kann wahlweise mit oder ohne CI betrieben werden und es besteht die Möglichkeit der sofortigen, mengen- und zeitgesteuerten Aktivierung Funktionsweise Nach erfolgter Verknüpfung einer Frage mit einer Antwort (und damit auch Zuordnung dieser zu einer Kategorie) wird der CI darüber benachrichtigt. Er überprüft nun, ob ein Wort innerhalb der Kategorie bzw. Sub-Kategorien die entsprechenden Ansprüche erfüllt um eine potenzielle neue Sub-Kategorie zu verkörpern: 1. Vorkommen in mindestens X % aber mindestens Y Fällen (X und Y durch System-Konfiguration durch den Administrator) festgelegt. 2. Vorkommen des Wortes hauptsächlich in dieser Kategorie max 10% des Vorkommens ausserhalb (auch dieser Prozentsatz kann über die Konfiguration geändert werden) Aktivierung Aktiviert wird der CI durch drei mögliche Aktionen (je nach Konfiguration): a) sofort: nach jeder Fragen-Antworten-Verknüpfung (FAV) b) mengengesteuert: i) nach X FAVen insgesamt ii) nach Y FAVen in der jeweiligen Kategorie c) zeitgesteuert: je nach gewünschter zeitlicher Periode (zb täglich um 23:00 Uhr, wöchentlich etc) d) kombiniert: zb jeden Freitag um 22:00 Uhr, wenn insgesamt mindestens X FAVen erfolgt sind Auto-Prioritization Gelangt eine Frage zu den Support-Agents (entweder durch das CBR-Modul nicht beantwortbar oder ein Administrator ist für die Lösung notwendig), so haben diese die Möglichkeit, diese Frage nach Wichtigkeit zu priorisieren. Eine durch das System selbst nicht beantwortbare oder noch nicht priorisierte Frage gelangt (standardmäßig durch Konfiguration abänderbar) mit höchster Priorität zum Agent. Eine Frage, deren Lösung eines Administrators bedarf, und /28 v2.0

27 die schon (ein- oder mehrfach) priorisiert wurde, gelangt mit dem Durchschnitt der vergebenen Prioritäts-Werte als Priorisierung zum Agent Auto-Assignment & Request Forwarding Gelangt eine Frage zu den Support-Agents, so wird diese jenem Agent zugewiesen, der diese (aufgrund der bisherigen Lösungen) schon gelöst hat oder, wenn die Frage noch nicht gelöst ist, eine möglichst ähnliche schon gelöst hat. Der Agent hat die Möglichkeit (bei Falschzuweisung, Zeitmangel oä.) die Frage an einen anderen Agent weiterzuleiten. 5 Zusammenfassung Nach den einführenden Begriffserklärungen wurde die Problemstellung näher erläutert und eine Möglichkeit aufgezeigt, wie intelligente Support Systeme und Trouble Ticket Systeme kombiniert werden können um unter Zuhilfenahme von Reinforcement-Trained Case Based Reasoning und Teilen des Natural Language Processing ein selbstlernendes Support System zu erstellen. Der wissenschaftliche Hintergrund wurde bereits in [1] erläutert und so beschränkt sich der Hauptteil dieser Arbeit auf die Implementierung des CubicMind Support Systems und auf die Verknüpfung der Theorie mit der Praxis. Die Entwicklung des CubicMind Support Systems ist "still in progress" und wird ständig weitergeführt. Zur Weiterverfolgung der Neuerungen am System wird demnächst die Möglichkeit geschaffen Zusatzinformationen im Internet auf abzurufen. Im Anhang befinden sich ein Abkürzungsverzeichnis und die Literaturliste /28 v2.0

28 6 Abkürzungs-Verzeichnis Abkürzung NLP TTS TRS TT FAQ CBR RetCBR NSM Natural Language Processing Trouble Ticket System Ticket Request System Trouble Ticket Frequently Asked Questions Case Based Reasoning Reinforcement Trained Case Based Reasoning Nested Set Model 7 Literaturliste [1] Seidler G. (2005), intelligente Help- und Support-Systeme, Seminararbeit am Institut für Medizinische Kybernetik und Artificial Intelligence, Wien [2] Xu Li D. (1994), Case-based reasoning, IEEE Potentials, Vol. 13, Issue 5, Dec Jan. 1995, p [3] Tsatsoulis C., Cheng Q., Wei H.-Y. (1997), Integrating case-based reasoning and decision theory, IEEE Expert [see also IEEE Intelligent Systems], Vol 12, Issue 4, July-Aug. 1997, p [4] Manaris B.Z. (1994), Natural language processing tools and environments: the field in perspective, Sixth International Conference on Tools with Artificial Intelligence, Proceedings, 6-9 Nov. 1994, p. 228 [5] Kilgarriff A. (2003), Thesauruses for natural language processing, 2003 International Conference on Natural Language Processing and Knowledge Engineering, Proceedings, Oct. 2003, p [6] Schmidt S. (2002), Weltenbaum: Selbstreferenzierende Bäume in MySQL, Software & Support Verlag GmbH, PHP Magazin, Ausgabe 2.02, p [7] Gorski D. T., Morgenstern Holger (day of view: ), Das 'Nested Sets' Modell - Bäume mit SQL, [8] Reeg C. (day of view: ), Bäume in SQL, /28 v2.0