intelligente Help- und Support-Systeme

Transkript

1 Seminararbeit intelligente Help- und Support-Systeme für Seminar (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 /19 v3.0

2 Abstract Die Erstellung eines selbstlernenden Support-Systems führt zu einem Verschmelzen bisher voneinander getrennter Gebiete: Help-Systeme und Trouble Ticket Systeme. Die Grundlagen ersterer werden anhand dreier konkreter Beispiele erläutert Berkeley Unix Consultant, OSCON und USCSH. Daraufhin folgt eine kurze Einführung in die Welt der Trouble Ticket Systeme und abschließend wird erläutert, wie mittels (Reinforcement-Trained) Case Based Reasoning die Grundideen dieser beiden Welten verbunden werden können. 1 Einführung Diese Arbeit entstand im Zuge der Entwicklung eines selbstlernenden Support-Systems (CubicMind Support System). Sie soll einen technischen Überblick über die (entfernt) verwandten Themengebiete intelligente Help-Systeme und Trouble Ticket-/Help Desk- Systeme geben. Zuerst werden kurz die Unterschiede dieser beiden Gebiete erläutert. Darauf folgt der eigentliche Hauptteil dieser Arbeit: ein Vergleich zwischen den bestehenden Help-Systemen Berkeley Unix Consultant [1], OSCON Operating System Consultant [2] und USCSH University of South Carolina SHell [3]. Im Anschluss folgt ein detaillierter Blick hinter die Kulissen der anfangs erwähnten Trouble Ticket- bzw. Help Desk-Systeme. Der letzte Teil dieser Arbeit beschäftigt sich mit der Zusammenführung der beiden Themengebiete im Laufe der Entwicklung des CubicMind Support System. Hier werden auch weitere Technologien behandelt - Case Based Reasoning und Reinforcement Learning bzw. wie diese in Verbindung gebracht werden können. 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. 2 Begriffserklärungen 2.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 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: /19 v3.0

3 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ührten, aber zum Textverständnis notwendigen - 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 Anwendungsfeld Intelligente Help-Systeme gehen meist aus der AI (Artificial Intelligence)-Forschung in den Gebieten NLP (Natural Language Processing) und Wissens-Repräsentation und Akquisition hervor. Der Bereich der Betriebssysteme bietet sich für die praktische Anwendung an, da dieser eine möglichst abgeschlossene Domäne darstellt. Help-Systeme verbleiben aufgrund ihres Ursprungs der Forschung meist im experimentellen Stadium, in welchem sie aber (soweit die jeweilige Forschungsgruppe noch daran arbeitet) stets weiterentwickelt werden. 2.2 Trouble Ticket-/Help Desk-Systeme Trouble Ticket-Systeme (TTS) dienen in der Regel zur Verwaltung von eingehenden Problemstellungen und deren Organisation innerhalb einer Gruppe von Help Desk Agents (zb Call Center). TTS besitzen meist keine intelligenten Funktionen zumindest im Bereich des NLP (Natural Language Processing) Anwendungsfeld TTS werden hauptsächlich im Help Desk-Bereich eingesetzt. Im Gegensatz zu den intelligenten Help-Systemen findet hier die Entwicklung hauptsächlich im kommerziellen Bereich statt die Forschung steht hier (wenn überhaupt vorhanden) sehr im Hintergrund. Das führt auch dazu, dass TTS der Ausdruck intelligent meist gänzlich abgesprochen werden muss sie stellen meist nur Bedien-Oberflächen zur Verwaltung von Problemfällen dar /19 v3.0

4 3 Help-Systeme: bestehende Anwendungen In diesem Abschnitt werden drei verschiedene Help-Systeme vorgestellt: Berkeley Unix Consultant OSCON Operating System Consultant USCSH (University of South Carolina SHell) Zuerst werden diese Systeme einzeln vorgestellt und anschließend ein direkter Vergleich gezogen. Insbesondere wird hierbei auf die Systemarchitektur eingegangen. Weiters sei anzumerken, dass alle Informationen und Beispiele über diese Systeme den Quellen [1], [2] und [3] entnommen wurden. 3.1 Berkeley Unix Consultant (UC) Der Unix Consultant hervorgegangen aus dem Berkeley UNIX Consultant Project - stellt ein intelligentes, natürlichsprachiges Interface dar. Zielsetzung ist es, den Anwender den Umgang mit dem Betriebssystem UNIX zu lehren und dabei einen menschlichen Unix- Consultant zu simulieren Systemarchitektur Das System setzt sich aus folgenden Komponenten, auf welche in der Folge näher eingegangen wird, zusammen: Sprach-Analyse (ALANA) Inferenz-System (Concretion Mechanism) Planung/Ziel-Analyse (PAGAN) Agent (UCEgo) User Modeling (KNOME) Domain Planer (KIP) Expression Mechanism (UCExpress) Sprachgenerierung (UCGen) Lern-Mechanismus (UCTeacher) Alle UC-Komponenten greifen auf das Knowledge-Representation System KODIAK zurück. Auf dieses soll hier nicht näher eingegangen werden nähere Informationen sind zu finden in [9] Sprach-Analyse (ALANA) ALANA (Augmentable LANguage Analyzer) ist das konzeptuelle Sprach-Analyse-Werkzeug des UC. Es verarbeitet die Eingabe des Anwenders in ein Konzept, welches für die anderen UC-Komponenten verständlich ist dieses basiert, wie zuvor erwähnt, auf KODIAK. Das Ergebnis dieser Analyse wird primal content genannt. Die Idee des primal content basiert grundsätzlich auf dem Gedanken des literal meaning bzw. sentence meaning, unterscheidet sich aber darin, dass nicht (nur) von Wörtern und grammatischen Konstrukten /19 v3.0

5 abgeleitet wird, sondern auch idiomatisch (phraseologisch); außerdem steht der primal content generell auf einer wesentlich abstrakteren Stufe. Im Gegensatz zum primal content existiert der actual content. Dieser ist kontext-abhängig und benötigt im Allgemeinen - auf globalem Wissen basierende Inferenzen. Als grundsätzliches Wissen verwendet ALANA das Konzept des pattern-concept pair, welches die natürliche Sprache mit der konzeptuellen Struktur in Verbindung bringt. UC arbeitet hier mit 476 Patterns (Muster) und 284 Wörtern Inference System (Concretion Mechanism) Um die entsprechenden Inferenzen zu finden, welche den primal und den actual content verbinden, wird manchmal ein sogenannter concretion-prozess benötigt. Durch den concretion-prozess wird eine spezifischere Interpretation eines Ausdrucks abgeleitet, als dies allein durch direkte sprachliche Ableitung möglich wäre. Im Unix Consultant wird der concretion-mechanismus hauptsächlich genutzt um das Wissen um diese spezifischeren Interpretationen herum zu organisieren. Die Ausgabe des concretion-prozesses ist wiederum eine KODIAK-Repräsentation. Anmerkung: Der Concretion Mechanism ist ein speziell für UC entwickelter und optimierter Mechanismus. Die Autoren von [1] würden es mittlerweile bevorzugen einen allgemeineren Text-Inferenz-Mechanismus zu einzusetzen Ziel-Analyse (PAGAN) Nachdem nun der actual content ermittelt wurde, wird diese interne Repräsentation an PAGAN (Plan And Goal ANalyzer) übergeben, welcher versucht Hypothesen zu erstellen, 1. welche(s) Ziel(e) hinter der User-Anfrage stecken und 2. welcher der richtige Weg ist (Plan) um zu diesem zu gelangen. Hierbei ist zu beachten, dass das Ziel einer Frage nicht immer direkt in der Frage steckt, sondern erst leicht abgeleitet werden muss. Ein Beispiel: Does ls r recursively list subdirectories? Eine einfache Antwort wäre No.. Es ist aber weiters Aufgabe von PAGAN zu erkennen, dass es Ziel der Frage ist, herauszufinden was ls r wirklich macht bzw. wie Subdirectories rekursiv aufgelistet werden können. Eine entsprechende Antwort wäre also zb: No, it reverses the order of the sort of the directory listing; ls R recursively lists subdirectories. Fragen werden also sowohl auf eine direkte als auch auf eine indirekte Interpretation hin untersucht. Das Ergebnis ist eine KODIAK-Repräsentation des Netzes an Plänen und Zielen /19 v3.0

6 Agent (UCEgo) Jetzt sind die Ziele des Users bekannt allerdings muss auch von der Möglichkeit ausgegangen werden, dass der User (ob beabsichtigt oder nicht) gefährliche Aktionen ausführen oder unberechtigterweise sensible Daten einsehen möchte. In solchen fällen soll der UC nicht helfen bzw. zusätzliche wichtige (nicht gefragte) Informationen ausgeben. Um dieser Strategie zu folgen, ist der Unix Consultant als Agent konstruiert das Herz des UC heisst UCEgo. Dieser Agent folgt prinzipiell den Zielen des Users, folgt aber zusätzlich (übergeordnet) einer eigenen Agenda an Zielen. So erkennt UCEgo, wenn es zu Konflikten zwischen den Zielen des Users und den eigenen kommt und reagiert entsprechend darauf. So werden entweder Informationen über zb unberechtigte Aktionen gegeben oder die Ziele des Users leicht angepasst User Modeling(KNOME) Die meisten Komponenten von UC benötigen genaue Informationen über den jeweiligen Benutzer des Systems. So ist es zum Beispiel wichtig zu wissen, ob ein User eher als Anfänger oder als Experte einzustufen ist, um entsprechende Antworten geben zu können. Für den Zweck, den Wissensstand von Usern einzuschätzen, wird das User-Modellierungs- Programm KNOME eingesetzt. Nähere Informationen zu KNOME sind zu finden in [10] Domain Planer (KIP) Während UCEgo zuoberst die eigenen Ziele verfolgt, gibt es an den Domain Planer KIP die Aufgabe weiter, herauszufinden wie die Ziele des Users erreicht werden können. KIP verwendet dafür eine Wissensbasis von Fakten über die Domäne (UNIX) eine Planungskomponente, die dieses Wissen verwendet für: o das Finden potentieller Pläne zur Problemlösung o das Auffinden möglicher Probleme mit diesen Plänen o die Verwendung von Meta-Planungs-Wissen (Wissen über Pläne) um zu entscheiden, welche Pläne ausgewählt werden Das Ergebnis ist ein Plan, welcher wiederum in Form von KODIAK repräsentiert wird Expression Mechanism (UCExpress) Nach dem Erhalt des Planes durch KIP, versucht UCEgo nun diesen Plan dem User zu übermitteln. Es entscheiden, welche Teile des Plans Sinn machen übermittelt zu werden und welcher Weg der beste ist um diese Teile zu kommunizieren. Hier kommt UCExpress zum Einsatz es sortiert die unwichtigen Informationen aus der konzeptuellen Antwort von KIP. Das Ergebnis ist ein annotiertes KODIAK Netzwerk, bei dem die Annotation festlegt, welcher Teil des Netzes in weiterer Folge generiert wird /19 v3.0

7 Sprach-Generierung (UCGen) UCGen wird nun nachdem entschieden wurde, was kommuniziert wird - dafür benutzt, um die Antwort in menschlicher Sprache (Englisch) auszugeben. UCGen ist ein einfacher Generator, der als Input das, von UCExpress ausgegebene, annotierte KODIAK Netz übernimmt und - mit Hilfe von Wissen aus dem Englischen Sätze produziert Lern-Mechanismus (UCTeacher) Da der Unix Consultant grundsätzlich als erweiterbares System konzipiert wurde, besteht die Möglichkeit Erweiterungen einzubinden was durch das UCTeacher-Modul erfolgt ist. Dieser Mechanismus erlaubt es sowohl die Wissensbasis von UNIX-Fakten als auch jene des Englisch-Vokabulars zu erweitern. UCTeacher ist um Missverständnisse auszuschließen kein Tool, welches selbstlernend arbeitet, sondern grob gesagt ein Interface, das die Eingabe (und Speicherung) zusätzlicher Daten ermöglicht Probleme Die Architektur des UC wie auch einzelne Komponenten, die allesamt in den 1980er-Jahren entwickelt wurden, geben im Nachhinein betrachtet technische Probleme zu lösen. Ein Hauptproblem ist der uni-direktionale Kontroll-Fluss durch den gesamten UC wie er in folgender Abbildung zu erkennen ist. Abb. 2: Kontroll-Fluss in Berkeley UC /19 v3.0

8 3.2 OSCON Operating System Consultant OSCON ist ein weiterer Consultant für Betriebssysteme er unterstützt Befehle (und Parameter) aus der UNIX- und aus der DOS-Welt. Wie UC gibt er englische Antworten auf englische Fragen und ist auf User unterschiedlicher Fachwissensstufen ausgelegt Systemarchitektur Der Grundgedanke des Frage-Antwort-Systems besteht darin alle Fragen in 3 Kategorien einzuteilen, worauf weiter unten näher eingegangen wird. Das OSCON-System selbst setzt sich aus folgenden sechs voneinander funktional unabhängigen Modulen zusammen: Sprach-Parser (Syntax) und Fragen-Typ-Erkennung (ParseCon) Sprach-Parser (Semantik) (MeanCon) Wissens-Repräsentation für Verständnis (KnowCon) Wissens-Repräsentation für Lösung (DataCon) Lösungs-Mechanismus (SolveCon) Sprach-Generator (GenCon) ParseCon Die Aufgabe von ParseCon, dem syntaktischen Parser von OSCON, besteht darin die gestellt Fragen in eine von drei Kategorien, auf welchen das System basiert, einzuordnen: 1. Anforderung von Information (eines Vorgangs/Befehls) 2. Anforderung von Erklärung (Wortdefinition) 3. Anforderung von Anleitung Die erste Kategorie lässt sich wiederum in drei Fälle aufteilen: 1. die Auswirkung 2. die Form (Syntax) 3. Vorbedingung eines Befehls. Die zweite Kategorie unterteilt sich in zwei Arten: 1. Erklärung eines Befehls 2. Erklärung eines Konzeptes Anhand der natürlichsprachigen Fragestellung (Vorkommen von bestimmten Phrasen, Befehlsnamen etc) wird die Kategorie der Frage ermittelt /19 v3.0

9 MeanCon Die Aufgabe des MeanCon-Moduls liegt in der Ergründung der Bedeutung der gestellten Frage. Dies geschieht durch das Durchsuchen nach dem Auftreten folgender sieben Textteile: Befehlsnamen Optionsnamen Verb-Referenzen (zb delete, see...) Objekte (Datei, Verzeichnis etc) Objekt-Modifizierer (zb Datei-Inhalt) Objekt-Orte (zb Bildschirm, Drucker, Verzeichnis etc) Konzepte (zb Dateisystem etc) KnowCon KnowCon besteht aus einer Sammlung von Daten-Dateien, welche das Wissen über die domänen-spezifische Sprache enthalten, um englische Fragen zu verstehen (zb erstellen, senden, löschen etc). Neben dem Wissen über die möglichen Aktionen innerhalb des Betriebssystems werden hier auch jene Daten gesammelt, welche benötigt werden, um Betriebssystems-Objekte zu beschreiben (zb Datei, Speicher etc). Diese Daten sind grammatische Regeln von typischen Wegen, wie Menschen über diese Objekte (im Englischen) sprechen DataCon DataCon ist nun jenes Modul, in dem die Informationen über das jeweilige Betriebssystem gespeichert werden. Für Unix unterteilen sich die Daten hier in sieben Kategorien: 1. Befehls-Vorbedingungen 2. Befehls-Auswirkungen 3. Befehls-Syntax 4. Befehls-Name 5. Befehls-Vorbedingungs-Optionen 6. Befehls-Auswirkungs-Optionen 7. Befehls-Namens-Optionen Da für DOS keine Optionen unterstützt werden, beschränkt sie der Umfang hier auf die ersten vier der angeführten Kategorien SolveCon SolveCon ist das Lösungs-Modul des OSCON-Systems. Es konstruiert weiterverarbeitbare Repräsentationen der natürlichsprachigen Fragen (sog. formal queries ) und vergleicht diese mit dem DataCon-Wissen. Nach dem Erhalt der entsprechenden DataCon-Daten werden diese in eine entsprechende (weiterverarbeitbare) Struktur gebracht und GenCon (siehe nächster Abschnitt) weitergegeben. Dies wird in folgender Graphik veranschaulicht /19 v3.0

10 Abb. 3: Übersicht SolveCon Die Fähigkeit, aus natürlichsprachigen Sätzen die entsprechende Antwort (in interner Darstellung, auch instantiated formal query ) abzuleiten, macht SolveCon zum Herzstück des Systems GenCon Abschließend wird die zuletzt von SolveCon aufbereitete Frage in eine entsprechende Antwort umgesetzt. GenCon beinhaltet auch die Funktionen zur Ausgabe von Vorbedingungen, Auswirkungen und Syntax von Befehlen. Diese Daten werden von DataCon bezogen. Letztendlich werden die Informationen, welche dem User zurückgeliefert werden, durch die Art der Frage, die er zuvor gestellt hat, bestimmt. 3.3 USCSH (University of South Carolina SHell) USCSH stellt ein weiteres aktives intelligentes Help-System für UNIX dar. Es kann grundsätzlich auf zwei Arten arbeiten im active mode oder im intelligent mode. Im aktiven Modus werden die Bedienschritte des Users aufgezeichnet und zu entsprechenden Zeitpunkten Verbesserungsvorschläge geboten. Im intelligenten Modus ist es dem User möglich natürlichsprachige Fragen zu stellen und darauf unter Rücksichtnahme auf Kontext und User-Wissen eine Antwort zu bekommen. Hier soll auf den aktiven Modus Hauptaugenmerk gelegt werden /19 v3.0

11 3.3.1 Systemarchitektur Das System (für den active mode) basiert hauptsächlich auf dem User Model, welches zwei weitere Modelle einschließt: User Model o Overlay Model (Beschreibung des (UNIX-)Systems) o Process Model (Erkennung von Ineffizienz und höheren Zielen) Abb. 4: Architektur USCSH (active mode) User Model Die Hauptaufgabe des User Models ist die Repräsentation des Wissensstandes des Users was weiß er, was weiß er nicht? USCSH verfolgt hierbei allerdings kein System von User- Kategorien bzw. Stereotypen, sondern erstellt ein ständig aktuelles Profil während der User seiner gewöhnlichen Arbeit (in der Unix-Umgebung) nachgeht, indem es im Hintergrund laufend jegliche Interaktion des Users aufzeichnet Overlay Model Das Overlay Model wird durch eine Hierarchie von Knoten realisiert, wobei jeder dieser Knoten für eine Ressource bzw. ein Konzept des Unix-Systems steht. In dieser Hierarchie werden umso spezifischere Ressourcen/Konzepte dargestellt, je weiter unten sich der Knoten in dieser Hierarchie befindet, bzw. werden diese nach oben hin mehr und mehr abstrahiert. Abb. 5: USCSH: Overlay Model Jeder dieser Knoten speichert einerseits den aktuellen Wissensstand des Users bezüglich des Objekts, welchen der Knoten repräsentiert, und andererseits zwei Nummern, welche die Schwierigkeit und Wichtigkeit dieses Objekts widerspiegeln /19 v3.0

12 Diese beiden Nummern sind nicht vom User abhängig, sondern werden vom USCSH- System vorgegeben. Anders verhält sich dies bei der Ermittlung des Wissensstandes. Dieser wird ständig durch das Beobachten der User-Interaktionen ermittelt. Es wird beobachtet, ob der User einen einfachen Befehl richtig oder falsch einsetzt je nachdem erhöht oder vermindert sich der Wissenstand in diesem Knoten. Der Wissenstand an höher stehenden abstrakten Knoten ermittelt sich durch die Ableitung aus den Kind-Knoten. Hierbei werden jeweils die Wichtig- und Schwierigkeit und der Wissensstand in Betracht gezogen und danach eine gewichtete Summe errechnet. Es gibt allerdings auch höher stehende Knoten, deren Wissenstand-Ermittlung aus einer Kombination von lokaler Berechnung und Kind-Knoten-Ableitung erfolgt. Der jeweilige Wissenstand wird in weiterer Folge von der USC Shell verwendet um auf den User zugeschnittene Vorschläge machen zu können. Das System gibt dem User Vorschläge zu jenen Themen, von denen es ermittelt, dass diese für den User wichtig sein könnten. Dies geschieht auf eigene Initiative des USCSH-Systems. Es versucht hierbei jenes Themen-Gebiet zu ermitteln, welches 1. in Verbindung zu den aktuellen Aktionen des Users steht und 2. möglichst viele neue Unix-Features und -Funktionen, über die der User wenig/nicht bescheid weiß (über Wissensstand ermittelt), beinhaltet Process Model Das Process Model besteht aus zwei Komponenten: 1. die ideale Komponente und 2. die nicht-ideale" Komponente. Die ideale Komponente besteht aus einer Menge von Regeln, welche höher liegende Ziele spezifizieren. Diese Spezifizierung erfolgt durch Pläne, die beschreiben, wie komplexere Aufgaben durch Abfolgen einfacherer Aufgaben und Befehle erledigt werden können. Diese Informationen können auch in die gegengesetzte Richtung verwendet werden, und zwar um festzustellen welcher Aktivität der User momentan nachgeht. Die nicht-ideale Komponente besteht aus Regeln, die fehlerhafte Befehle und uneffiziente Befehls-Abfolgen beschreiben, welche üblicherweise von Usern ausgeführt werden sie kann demnach als Liste schlechter Pläne angesehen werden Intelligent Mode Auf den Intelligent Mode soll hier nur beschränkt eingegangen werden, da er sicher nicht das Herzstück des Systems ist. Es können hier nur zwei Klassen von Fragen gestellt werden: 1. how do I <action> <objects> und 2. what is a <concept>/<capability>, von denen die Autoren von [3] allerdings überzeugt sind, dass diese einen Großteil der relevanten Fragen abdecken /19 v3.0

13 3.4 Überblick/Vergleich Help-Systeme Zum Abschluss dieses Teils der Arbeit über Help-Systeme wird an dieser Stelle noch ein kurzer Vergleich geboten. Während UC und USCSH nur auf ein Betriebssystem (UNIX) spezialisiert sind, ermöglicht OSCON zusätzlich auch den Einsatz unter DOS. Hier kann der Schein allerdings trügen OSCON zb ist wesentlich mehr auf die Domäne der Betriebssysteme spezialisiert als der Berkeley UC, welcher ein weiters Spektrum an Wissens-Repräsentation, Planung und NLP ermöglicht[4]. Die University of South Carolina Shell (USCSH) bietet durch die Neuprogrammierung in C eine direkte Integration in die UNIX Shell. Abschließend erfolgt in der folgenden Abbildung ein kurzer direkter Vergleich der Systeme Berkeley UC und OSCON und ihrer Haupt-Komponenten. (USCSH ist hier nicht vertreten, weil der Scherpunkt dieses Systems im active mode liegt, welcher nicht dem Question- Answer-Prinzip folgt). Berkeley UC OSCON Betriebssystem Unix Unix/DOS Grundgedanke primal vs. actual content Frage-Typ-Kategorisierung Sprach-Analyse ALANA concretion-mechanismus ParseCon MeanCon Herzstück UCEgo SolveCon User-Modellierung KNOME - Wissens-/ Plan- Speicher KIP KnowCon DataCon Sprachgen. UCGen GenCon Erweiterungen UCTeacher - Abb. 6: Vergleich Berkeley UC vs. OSCON 4 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 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 Support-Abteilungen gelegt. Die Grundfunktionalität eines TTS lässt sich wie folgt veranschaulichen: /19 v3.0

14 Abb. 7: 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 frei. 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 /19 v3.0

15 5 Die Synthese: CubicMind Support System Wie in der Einführung erwähnt entsteht diese Ausarbeitung während der Entwicklungsphase des selbstlernenden Support-Systems CubicMind Support System. Dieses hat das Ziel die Vorteile der zwei vorgestellten 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 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. 7 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. 5.1 Case Based Reasoning (CBR) Bei Case Based Reasoning auf Deutsch Fallbasiertes Schließen werden neu auftretende Problemfälle aufgrund des bisherigen Wissensstandes gelöst bzw. versucht zu lösen[5]. Klare Vorteile gegenüber Regelbasiertem Schließen (auf welches hier nicht näher eingegangen werden soll) sind [6][7]: Problemlösungen sind auch in nicht vollständig beschriebenen Domänen möglich (es wird kein explizites Domänen-Modell benötigt) Vorgang der Lösungsfindung ähnlich dem menschlichen (durch Erfahrungswerte) schnelle Wissens-Akquisition Zu beachten ist allerdings, dass die Ergebnisse stark von Umfang und Qualität der sogenannten case library (auch case memory ; dh. Sammlung der bisherigen Fälle) abhängen[7]. Hier bedeutet dies also, dass die Anzahl der gespeicherten abgeschlossenen Tickets und die Qualität deren Problemlösungs-Beschreibungen von großer Wichtigkeit in Bezug auf die Antwort-Zuverlässigkeit des gesamten Systems sind /19 v3.0

16 5.1.1 Der CBR-Prozess Der Prozess des CBR lässt sich in fünf Schritte gliedern [6][8]: 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 gespeichert und miteinander in Verbindung gebracht. 2. Retrieval Bei einer neuen Problemstellung werden entsprechende (möglichst ähnliche) Fälle ausgewählt. Durch concept refinement methods oder partial matching (oder eine Kombination aus beiden)[6] wird dann der ähnlichste Fall ausgewählt. - Beim Support System werden aufgrund bestimmter Algorithmen (auf diese soll hier nicht näher eingegangen werden 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 diese nicht erfolgreich, 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. Es wird jedoch davon ausgegangen, dass der User keine falschen Antworten als richtig deklariert (richtige jedoch schon) Reinforcement-Trained CBR (RETCBR) [5][6] Beim RETCBR wird Feedback vom User verwendet um die Übereinstimmung des/der gefundenen Falls/Fälle zu überprüfen. Dieses Feedback wird in Form eines Binärwerts (zb ja/nein) gegeben. Dann werden Techniken des Reinforcement Learnings (RL) verwendet, um die Ähnlichkeits- Matrix anzupassen und in weiterer Folge die Fall-Auswahl zu verbessern. RL wird auch learning with a critic oder learning with a teacher genannt. Der Vorteil besteht darin, dass es nicht nötig ist den korrekten Fall für jede Eingabe zu kennen /19 v3.0

17 5.2 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) 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. Wie im CubicMind Support System die restlichen Schritte des CBR-Prozesses angewandt werden, wurde bereits in Pkt erläutert. 6 Zusammenfassung Nach einer kurzen Einführung wurde im Hauptteil dieser Arbeit - ein Vergleich zwischen den drei Help-Systemen Berkeley Unix Consultant (Berkeley UC), Operating System Consultant (OSCON) und University of South Carolina SHell (USCSH) gezogen. Dabei wurde jeweils die System-Architektur näher erläutert und abschließend diese Architekturen miteinander (soweit wie möglich) verglichen. Diese drei Produkte stellen nur einen Ausschnitt der Palette an Help-Systemen dar, bieten aber dennoch einen guten Einblick in die gebotenen Möglichkeiten solcher (intelligenten) Assistance-Systeme. Im Anschluss daran wurde das Konzept des Trouble Ticket-Systems vorgestellt und erläutert inwiefern es sich von den Help-Systemen unterscheidet. Abschließend wurde aufgezeigt, wie mittels Case Based Reasoning, Reinforcement Learning und - in Kombination dieser beiden Technologien Reinforcement-Trained CBR die Grundgedanken von Help- und Trouble Ticket-System zusammengeführt werden können /19 v3.0

18 7 Abkürzungs-Verzeichnis Abkürzung AI ALANA CBR FAQ KODIAK NLP OSCON PAGAN RETCBR RL TRS TT TTS UC USCSH Artificial Intelligence Augmentable LANguage Analyzer Case-Based Reasoning Frequently Asked Questions Keystone to Overall Design for Integration and Application of Knowledge Natural Language Processing Operating System Consultant Plan And Goal ANalyzer Reinforcement-Trained CBR Reinforcement Learning Ticket Request System Trouble Ticket Trouble Ticket-System Berkeley Unix Consultant University of South Carolina SHell /19 v3.0

19 8 Literaturliste [1] Wilensky R., Chin D. N., Luria M., Martin J., Mayfield J., Wu D. (1988), The Berkeley UNIX Consultant Project, Computational Linguistics, Vol 14, Issue 4, Dec 1988 [2] Kevitt P. Mc (2000), The OSCON Operating System Consultant, Artificial Intelligence Review, Vol 14, Issue 1-2, April 2000, p [3] Matthews M., Pharr W., Biswas G., Neelakandan H. (2000), USCSH: An Active Intelligent Assistance System, Artificial Intelligence Review, Vol 14, Issue 1-2, April 2000, p [4] Kevitt P. Mc (2000), Editorial: Intelligent Help Systems for UNIX: Computational Models and Systems, Artificial Intelligence Review, Vol 14, Issue 1-2, April 2000, p. 1-4 [5] Zhi-Wei Ni, Shan-Lin Yang, Long-Shu Li, Rui-Yu Ji (2003), Integrated case-based reasoning, International Conference on Machine Learning and Cybernetics, Vol. 3, 2-5 Nov. 2003, p [6] Xu Li D. (1994), Case-based reasoning, IEEE Potentials, Vol. 13, Issue 5, Dec Jan. 1995, p [7] Babka O., Si Yain Whar (1997), Case-based reasoning and decision support systems, 1997 IEEE International Conference on Intelligent Processing Systems, Vol 2, Oct. 1997, p [8] 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 [9] Wilensky R. (1987), Some Problems and Proposals for Knowledge Representation, University of California at Berkeley, Technical Report: CSD [10] Chin, D.N. (1989), KNOME: Modeling What the User Knows in UC, Springer Verlag: Berlin, User Models in Dialog Systems, p /19 v3.0