Suchstrategien

Die Suche nach einer passenden Regel zu einer Benutzereingabe unterliegt einer bestimmten Suchstrategie bzw. einer Reihenfolge bestimmter Verhaltensweisen. Es wird zwischen der proaktiven und der reaktiven Suche unterschieden. Die reaktive Suche hat das Ziel, eine zur Benutzereingabe passende Antwort zu finden. Die proaktive Suche wird z. B. dann gestartet, wenn die Eingabe des Benutzers nicht verstanden wurde oder aber Gründe dafür sprechen, das laufende Gespräch in andere Bahnen zu lenken.

Der grobe Ablauf sieht so aus, dass zunächst die aktuelle Suchstrategie, also die Suchstrategie, die in der zuletzt gefeuerten Regel gesetzt wurde, abgearbeitet wird. In der Regel handelt es sich um die Default-Strategie.

Die reaktive und die proaktive Suchstrategie wird in jeder Regel, die aufgerufen wird, nicht nur reaktiv, sondern auch über Verknüpfungen wie GOTO oder ANALYZER neu gesetzt. Dies gilt für die gesamte Wissensbasis, d.h. die zuletzt angesprochene Regel bestimmt die Suchstrategie bei der nächsten Suche.
Wird über diese reaktive Suchstrategie eine Antwort gefunden, so wird das Gespräch auf seine Qualität hin überprüft. Außerdem wird die Quantität des vorhandenen Restwissens geprüft. Sollte eine der beiden Prüfungen ein unbefriedigendes Ergebnis liefern, erfolgt ebenfalls ein Übergang zur Proaktivität, andernfalls wird die Antwort an den Benutzer übermittelt.
Die proaktive Suche richtet sich nach der proaktiven Suchstrategie, die in der letzten gefeuerten Regel selektiert wurde. In vielen Fällen ist das die proaktive Default-Strategie.
Sollte auch nach der proaktiven Suche immer noch keine passende Regel gefunden worden sein, wird das Event „AVOID” ausgelöst, über dessen Regel eine entsprechende Antwort ausgegeben werden kann, also zum Beispiel: „Dazu fällt mir leider nichts ein“. Wird das Event AVOID ausgelöst, so werden die weichen Übergänge aus den zuvor ausgegebenen Events nicht ausgegeben, die Eventregeln CANNOTSHOWMORE und LEAVINGTOPICSCOPE werden also nicht gefeuert.

Reaktive Verhaltensweisen

Grundsätzlich entscheidet der Vergleich des Regel-Ausdrucks mit der Benutzer-Eingabe, ob eine Regel ausgeführt wird oder nicht. Dieses Verfahren reicht jedoch für einen intelligent geführten Dialog nicht aus. Da die Regeln in einem hierarchisch strukturierten Kontext-Baum abgelegt sind, ergeben sich bei der Suche nach einer auf die Benutzer-Eingabe passenden Regel unterschiedliche Suchmöglichkeiten.

Die reaktive Standard-Strategie oder auch DEFAULT-Strategie ist neben der ANALYZER-Strategie die am häufigsten verwendete Suchstrategie. Sie besteht aus den nachfolgenden Verhaltens-weisen, die nacheinander ausgeführt werden:

1. Abfangen von Ereignissen (HANDLE_EVENTS)
2. Suche in den gesprächsblockierenden Regeln (CONTROL_DIALOG_FLOW_BLOCK)
3. Suche in den informationsanfordernden Regeln (CONTROL_DIALOG_FLOW_SHOWMORE)
4. Suche in den themenablehnenden Regeln (CONTROL_DIALOG_FLOW_JUMPAWAY)
5. Überprüfen von Schlüsselwörtern (DISPATCH_ON_KEYS)
6. Suche im aktuellen Kontext (SEARCH_INPLACE)
7. Suche in untergeordneten Kontexten (SEARCH_TOPDOWN)
8. Suche in übergeordneten Kontexten (SEARCH_BOTTOMUP)
9. Suche in der gesamten Wissensbasis (SEARCH_BOTTOMUP_AND_TOPDOWN_RECURSIVE)
10. Ausführen von Analyzer-Regeln (ANALYZE_INPUT)
11. Suche in den Stichwortregeln(DISPATCH_ON_PHRASES)
12. Suche in den Teilausdruck-Regeln (SEARCH_IN_SHARED_KNOWLEDGE)
13. Benutzerrückfrage (GIVE_USER_ANOTHER_TRY)

Einige davon sollen hier näher erläutert werden.

HANDLE_EVENTS: Verarbeitung eigehender Events

Agenten können auf sogenannte Events (Ereignisse) reagieren. Ein Event kann eine Aktion des Benutzers auf der Website sein, z. B. das Anklicken einer Seite innerhalb einer Website. Hierauf könnte seitens des Agenten als Reaktion ein Kommentar zu dieser Seite erfolgen.

CONTROL_DIALOG_FLOW: Suche in Dialogsteuerungsregeln

Diese Verhaltensweise übernimmt eine spezielle Funktion für den Dialog zwischen Agent und Benutzer. Mit ihr werden Regeln in den Kontexten SHOWMORE, JUMPAWAY und BLOCK nach passenden Ausdrücken untersucht.

Standardmäßig werden diese Kontexte im Common-Bereich schon beim Erstellen eines Projektes angelegt. Inhaltliche Ergänzungen sollten sich an der Aufgabe des jeweiligen Kontextes orientieren. BLOCK beinhaltet Regeln, die Benutzereingaben abfangen, die den Dialog inhaltlich nicht vorantreiben und abgeblockt werden sollen, Beispiele hierfür sind Beschimpfungen und ordinäre Anmachen. Die Regeln im Kontext JUMPAWAY reagieren auf Eingabemuster, die klar signalisieren, dass der Benutzer das Thema wechseln möchte, wie z. B. „Ich interessiere mich nicht für das Thema XYZ“.

Greift eine Regel hieraus, springt der Dialog anschließend wieder in den vorherigen Themen-Kontext. Der Vorteil dieser Verhaltensweise besteht darin, dass nicht themenbezogene Benutzereingaben (z. B. „Erzähl mir mehr“) zentral verwaltet werden und nicht für jeden Kontext explizit erstellt werden müssen. Im Kontext SHOWMORE befinden sich Regeln, die auf Interesse bekundende Eingaben des Benutzers reagieren und proaktiv eine weitere Aktion zu dem aktuellen Thema auslösen.

DISPATCH_ON_KEYS: Beeinflussung des Suchstartpunkts durch Keywords

Diese Verhaltensweise versucht, den Startpunkt der Suche zu verändern, wenn in der Benutzereingabe ein oder mehrere Schlüsselbegriffe vorkommen, die in einem Kontext als Keywords definiert wurden. Hierbei kommt ein Bewertungsverfahren zum Einsatz, das für jeden Kontext und jedes vorhandene Schlüsselwort Punkte aufsummiert.

Nehmen wir an, dass sich der Benutzer mit einem Agenten über Slalomboards unterhält, nun aber über Waveboard-Segel beraten werden möchte. So könnte der Benutzer z. B. eingeben:

„Haben Sie preisgünstige Segel für Waveboards?“

Aus der Abbildung ist ersichtlich, dass im hierarchischen Baum in den Kontext ‚Waveboards‘ gewechselt werden muss, da der Benutzer sonst fälschlicherweise über Slalomboard-Segel beraten werden würde. Um dies zu erreichen, wird bei dieser Verhaltensweise die Benutzereingabe bezüglich vorkommender Schlüsselwörter bewertet, wobei die Anzahl aller Keywords die Punktzahl des jeweiligen Kontexts darstellt.

Kontext	Punkteanzahl
Windsurfboards	0 Punkte
Slalomboards	0 Punkte
Finnen (für Slalomboards)	0 Punkte
Segel (für Slalomboards)	2 Punkte
Waveboards	1 Punkt
Finnen (für Waveboards)	1 Punkt
Segel (für Waveboards)	2 Punkte + 1 Punkt vom Kontext „Waveboards“ = 3 Punkte

Aufgrund der höchsten Punktzahl von 3 Punkten wird der Kontext „Segel“ (für Waveboards) zum Startpunkt der nachfolgenden Suchprozesse und nicht das aktuelle Thema.

Negative Keywords

Wenn ein Kontext ein positives Keyword zugewiesen bekommen hat, welches in der Benutzereingabe vorkommt, bekommt dieser Kontext in der Regel nach dem oben beschriebenen Verfahren eine bestimmte Punktzahl zugewiesen. Hat dieser Kontext aber ein negatives Keyword, welches ebenfalls in der Benutzereingabe vorkommt, erhält der Kontext keine Punkte zugewiesen. Ist also ein negatives Keyword für einen Kontext gesetzt und die Benutzereingabe enthält dieses Wort, wird der Kontext nie zum neuen Startpunkt für die weitere Suche ausgewählt und er wird auch bei der weiteren Suche nicht berücksichtigt. Negative Keywords sind somit ein sehr mächtiges Mittel, um einen Kontext bei der Suche unberücksichtigt zu lassen.

ANALYZE_INPUT: Anwendung von Antwort-Erwartungsregeln

Diese Verhaltensweise untersucht, ob eine Regel eine Analyzer-Adressierung besitzt. Ist dies der Fall, so wird die adressierte Regel bei der nächsten Benutzereingabe ausgeführt. Auf diese Weise kann die Eingabe analysiert und für den weiteren Gesprächsverlauf verwendet werden. Um zu verhindern, dass nach einer gezielten Frage des Agenten, nicht die normale reaktive Regel feuert, muss ein Analyzer gesetzt werden. Hier ein Beispiel:

Ohne Analyzer:
Agent: Interessieren Sie die Kosten von iHELP oder iAGENT?
Kunde: iHELP
Agent: iHELP ist eine Software zur Erstellung von virtuellen Agenten…

Mit Analyzer:
Agent: Interessieren Sie die Kosten von iHELP oder iAGENT?
Kunde: iHELP
Agent: Die Kosten von iHELP…

Ohne den Analyzer würde als Reaktion auf die Antwort des Kunden die allgemeine iHELP-Regel feuern und der Agent würde nichts über die Kosten von iHELP erzählen. Im Composer werden die Analyzer-Adressierungen in den Regeln oder in den Regelaktionen vorgenommen.
Analyzer-Angaben der Aktionen überschreiben die Angaben der eigenen Regel.

DISPATCH_ON_PHRASES: Suche in allgemeinen Stichwortregeln

Diese Verhaltensweise vergleicht die Benutzereingabe mit den Regelausdrücken im PHRASES-Kontext. Der PHRASES-Kontext wird automatisch beim Anlegen eines Projektes/Agenten erzeugt und beinhaltet bereits einige typische Ausdrücke. Wenn der Benutzer z. B. fragt, „Kennst du dich mit Astrologie aus?“, gibt es eine Astrologie-Regel, die auf verschiedene Stichworte aus dem Themengebiet Astrologie reagiert. Bei den Regeln dieses Kontextes handelt es sich um Welt- bzw. Allgemeinwissen, auf das der Agent reagieren aber nicht näher eingehen sollte.

Diese Verhaltensweise sollte erst dann zum Einsatz kommen, wenn alle Themenkontexte bereits nach passenden Regeln durchsucht wurden.

SEARCH_IN_SHARED_KNOWLEDGE

Diese reaktive Verhaltensweise durchsucht den Kontext SHARED im Common-Bereich nach passenden Ausdrücken. Wenn der Benutzer z. B. „Kennst Du denn auch Hintertupfingen?“ eingibt, wird in den Themenkontexten vermutlich keine sinnvolle Eingabe auf ‚Hintertupfingen‘ gefunden. Im SHARED-Bereich ist aber eine Regel, die auf das Eingabemuster „Kennst Du…“ reagiert und mit der Aktion „Hintertupfingen? Ist mir leider unbekannt.“ reagiert. Die Antwort ist zwar ausweichend, signalisiert aber, dass die eingegebene Frage verstanden wurde.

Proaktive Verhaltensweisen

Wird über die reaktiven Verhaltensweisen keine geeignete Regel auf eine Benutzer-Eingabe gefunden, wird versucht, proaktiv zu handeln, d.h. dem Benutzer ein neues Thema aus den Fachgebieten des Agenten anzubieten. Hierfür müssen Regeln als proaktiv gekennzeichnet werden.

Die proaktive Standard-Suchstrategie ist eine Zusammenstellung von einzelnen Suchstrategien, die in einer vorgegebenen Reihenfolge abgearbeitet werden. Mit dem Composer wird eine proaktive Default-Suchstrategie ausgeliefert, die folgende Strategien durchläuft:

1. CHECK_KNOWLEDGE_LIMIT
2. CHECK_COMMUNICATION_LEVEL
3. FOLLOW_GUIDED_TOUR
4. SHOW_MORE_INFORMATION
5. CLIMB_UP_IN_TOPIC_HIERARCHY
6. JUMP_TO_A_MOST_IMPORTANT_TOPIC

CHECK_KNOWLEDGE_LIMIT

Dieses proaktive Suchverhalten kontrolliert den Grad des vorhandenen Wissens im aktuellen Kontext und versucht, den Kontext zu verlassen, falls der Grad unter den gesetzten Schwellenwert gefallen ist. Diese quantitative Kontrolle beugt einer thematischen Erschöpfung vor und bewirkt, dass das Gespräch abwechslungsreicher gestaltet wird. Stellen Sie sich beispielsweise einen Kontext vor, der neun Regeln zum Thema Sicherheit beim Surfen beinhaltet. Sie haben die Eigenschaft KNOWLEDGELIMIT auf 30 (entspricht 30 %) gesetzt. Wenn bereits 70 % der Regeln dieses Kontexts im bisherigen Gesprächsverlauf eingesetzt wurden, ist das Knowledge-Limit erreicht und dieser Kontext wird nicht mehr in das Suchverfahren einbezogen. Das Thema „Sicherheit beim Surfen im Web“ ist zwar für jeden Internet-Agenten wichtig und sollte auch beantwortet werden, aber wenn der Schwerpunkt auf anderen Themen liegen soll, ermöglicht die Verhaltensweise CHECK_KNOWLEDGE_LIMIT das Wechseln des Themas, nachdem verschiedenste Sicherheitsfragen bereits beantwortet wurden.

CHECK_COMMUNICATION_LEVEL

Dieses proaktive Suchverhalten unterzieht das Gespräch einer qualitativen Kontrolle. Über die Eigenschaft IMPORTANCE kann jeder Regel und jedem Kontext eine prozentuale Wichtigkeit in Bezug auf die Erreichung des Kommunikationsziels zugeordnet werden. Die Wichtigkeit der zuletzt gefeuerten Regeln wird gemittelt und mit der Importance verglichen. Ist der Mindest-Level unterschritten, versucht das Verfahren, das aktuelle Umfeld zu verlassen, in der Hoffnung, in Themenbereiche mit einer höheren Relevanz zu stoßen.
Wie viele Regeln hierbei berücksichtigt werden, kann über eine Systemvariable (STEP_BACK_IN_HISTORY) individuell gesteuert werden. Standardmäßig werden zur Ermittlung des Communication Levels die Importance-Werte der letzten fünf gefeuerten Regeln gemittelt.

Diese Funktionalität ist vor allem für Themengebiete bzw. Kontexte sinnvoll, die nicht zu den Top-Themen zählen bzw. nicht zur Verwirklichung des Dialogziels beitragen. Wenn ein Besucher wiederholt nach dem Wetter fragt, soll der Agent zwar demonstrieren, dass er den Besucher versteht und auch relevante Wetterdaten präsentieren kann – ein Gespräch über das Wetter entspricht jedoch nicht dem Dialogziel des Agenten, der seinen Schwerpunkt in der Beratung bzw. dem Verkauf von Produkten hat. Mit der Funktionalität CHECK_COMMUNICATION_LEVEL wird erreicht, dass das Gespräch vom Wetter abgelenkt wird.

FOLLOW_GUIDED_TOUR

Dieses proaktive Suchverhalten ermittelt, ob sich der Benutzer gerade auf einer geführten Tour befindet. Ist dies der Fall, wird zum nächsten Wegpunkt dieser Tour gesprungen. Wegpunkte, die bereits abgehandelt wurden, werden übersprungen. Existiert im aktuellen Kontext kein Wegpunkt, wird untersucht, ob sich im aktuellen Kontext der Beginn einer geführten Tour befindet. Falls doch, wird dem Benutzer die Frage gestellt, ob er diese Tour beginnen möchte, und die Tour wird am ersten Wegpunkt gestartet.

SHOW_MORE_INFORMATION

Dieses proaktive Suchverhalten sucht in der näheren Umgebung nach einer Regel, die das Merkmal PROACTIVE besitzt. Falls eine solche Regel gefunden wird, wird diese ausgeführt.

CLIMB_UP_IN_TOPIC_HIERARCHY

Ausgehend vom aktuellen Kontext werden schrittweise alle übergeordneten Kontexte überprüft, ob sie Informationen bereitstellen, die proaktiv angewandt werden können. Sobald eine proaktive Information gefunden wurde, wird der Suchvorgang abgebrochen und die entsprechende Regel ausgeführt.

Diese Strategie ermöglicht eine neue Themenentfaltung. Beispiel: Die Themen „iHELP“ und „iAGENT“ sind dem Oberkontext „PRODUCTS“ zugeordnet. War das letzte Thema des Dialogs iHELP, wird zunächst überprüft, ob zu diesem Thema noch proaktives Wissen zur Verfügung steht. Wurde schon alles über iHELP gesagt, wird das proaktive Produktwissen im Kontext PRODUCTS überprüft und so ggfs. dem Besucher ein proaktiver Text zu der gesamten Produktpalette präsentiert, der z. B. einen Intellilink für das Produkt iAGENT enthält.

JUMP_TO_A_MOST_IMPORTANT_TOPIC

Alle Kontexte und Regeln mit einem IMPORTANCE-Wert von 100 werden automatisch im SHARED-Bereich registriert. Dieses proaktive Suchverhalten sucht zufallsmäßig eines dieser Topics aus und springt dorthin.

Suchreihenfolge innerhalb der Suchstrategien

Für alle Suchstrategien gilt, dass Kontexte und Regeln in alphabetischer Reihenfolge – d.h. der Darstellung im Kontextbaum entsprechend, also von oben nach unten – durchsucht werden. Dies gilt sowohl für die Standard-Kontexte im Agenten-Bereich als auch für die Kontexte unter BLOCK, SHOWMORE, JUMPAWAY und PHRASES. Man kann einer Regel somit dadurch einen Vorrang einräumen, dass man sie in einem Kontext ablegt, der aufgrund der alphabetischen Suche vorrangig durchsucht wird.
Bei dieser Vorgehensweise ist jedoch Vorsicht geboten. Nehmen wir an, es gibt die drei Kontexte

• A_KONTEXT
• B_KONTEXT
• C_KONTEXT

Grundsätzlich wird erst der A_KONTEXT, dann der B_KONTEXT, dann der C_KONTEXT überprüft. Nehmen wir an, es feuert eine Regel aus dem B_KONTEXT. Diese Regel bzw. der Kontext ist der Startpunkt der Suche für den nächsten Dialogschritt. In diesem Fall wird im aktuellen B_KONTEXT mit der Suche begonnen und nicht im A_KONTEXT.
Für die Rangfolge der Regeln innerhalb eines Kontextes kann diese Methode zwar auch angewendet werden, eleganter ist hier aber die Verwendung der Priorität über die Regeleigenschaften.

Kontexte und Regeln

Lokale Regeln

Da manche Regeln nur dann greifen dürfen, wenn Sie in einem bestimmten Themenzusammen-hang angesprochen werden, können Regeln innerhalb eines Kontextes als lokal gekennzeichnet werden, d.h. die Regel greift nur dann, wenn der Benutzer über eine vorherige Eingabe in den Kontext gekommen ist. Dies lässt sich sehr gut an einem Beispiel verdeutlichen.

So könnte der Benutzer in einem Teilbereich des hierarchischen Baumes über Segel und Finnen von Surfboards informiert werden.

Zunächst könnte der Benutzer z. B. die Frage stellen:
„Was für Produkte haben Sie im Angebot?“

Die Antwort vom Agenten könnte lauten:
„Ich habe die Produkte A, B und C für Sie.“

Anschließend könnte der Benutzer nach dem Preis fragen:
„Wie teuer ist das Produkt A?“

Hierauf würde der Agent korrekt antworten:
„Das Produkt A kostet nur 199,00 Euro!“

Nun möchte der Benutzer die Bedingungen für den Versand erklärt bekommen:
„Versenden Sie Ihre Produkte auch mit der Post?“

Der Agent erklärt:
„Auf Wunsch können Sie die meisten Produkte gern auch per Post zugesandt bekommen.“

Nun möchte der Benutzer die Bedingungen für den Versand erklärt bekommen:
„Versenden Sie Ihre Produkte auch mit der Post?“

Der Agent erklärt:
„Auf Wunsch können Sie die meisten Produkte gern auch per Post zugesandt bekommen.“

Diese Antwort ist in diesem Zusammenhang natürlich völlig falsch. Die Ursache liegt darin, dass die strategische Suche auf die Regel „WieTeuer“ in dem Kontext „Produkt A“ trifft. Dort wurde die Expression sehr allgemein formuliert und feuert. Diese Verhaltensweise kann vermieden werden, wenn die Regel „WieTeuer“ auf Lokal gesetzt wird.

Dies stellt sicher, dass eine Regel nur dann gefeuert werden kann, wenn der aktuelle Kontext derjenige ist, in dem sich die lokale Regel befindet. Die letztgefeuerte Regel bestimmt den aktuellen Kontext – unabhängig davon, ob diese durch ein Goto oder reaktiv ausgelöst wurde.

Die reaktive Suche (wie auch die proaktive Suche) im Kontextbaum wird immer vom aktuellen Kontext aus gestartet. Welches der aktuelle Kontext ist, bestimmt immer die letztgefeuerte Regel – unabhängig davon, wodurch diese ausgelöst wurde. Dies gilt nur für den Agenten-Bereich – ein Kontext aus dem Common-Bereich wird nie zum aktuellen Kontext. Daher können lokale Regeln auch nur im Agenten-Bereich verwendet werden.

Eine lokale Regel kann zudem auch als Deep markiert werden. Ist dieser Schalter umgelegt, verhält sich die lokale Regel in dem Kontext, in dem sie liegt und in allen Unterkontexten dieses Kontextes als lokale Regel. Sie kann also dann feuern, wenn vorher eine Regel aus dem gleichen Kontext oder aus einem seiner Unterkontexte gefeuert hat. Dies erspart einem das Kopieren von lokalen Regel für Unterkontexte, die man aus thematischen Gründen angelegt hat.