Teil 7: Intelligenter Kontext durch logisches Graph Traversal

Teil 7: Intelligenter Kontext durch logisches Graph Traversal

Viele Chatbots haben ein Problem. Sie können sich nur begrenzt oder nur auf sehr umständlichen Wegen den Kontext einer Konversation merken. Oft muss derartige Logik mit viel Programmieraufwand implementiert werden. Bei meinen Experimenten mit Graph-Datenbanken habe ich jedoch bemerkt, dass sich diese Logik komplett in die vernetzte Struktur einer solchen Datenbank auslagern lässt. Das führt dazu, dass Anwender keinen umständlichen Code mehr schreiben müssen, wenn sie ihren Bot bauen. Auch dann nicht, wenn die Konversation komplexer wird. Die Logik entsteht ganz von selbst durch das Design der netzwerkartigen Struktur.

Der Wanderer

In den letzten Beiträgen hast du gelernt, was Graph Traversal ist, was das mit Wandern zu tun hat und wie Logik in Form von einfachen Gattern in einem Graph abgelegt werden kann. Nun zeige ich dir, wie diese Logik ganz einfach ausgeführt werden kann, indem der Wanderer nach und nach die Wege im Netzwerk abläuft.

Unterwegs macht er dabei immer wieder halt, da viele Wege noch verschlossen sind und erst nach und nach geöffnet werden. So folgt der Wanderer nur den Wegen, die von einer Frage oder einem Antwortvorschlag wegführen, wenn diese auch beantwortet sind. Trifft er unterwegs auf eine unbeantwortete Frage, wird er diese an den Chatbot übergeben. Das sind einfache Regeln, die wir dem Wanderer bereits mit auf den Weg geben können. Wie aber überprüft der Wanderer, ob die Logikgatter bereits durchlaufen werden dürfen, auf die er unterwegs erst spontan trifft?

ODER-Bedingungen

Kurioserweise müssen wir für ODER-Bedingungen überhaupt nichts programmieren. Unser Wanderer löst dieses Problem nämlich von ganz allein. Zeigen nämlich mehrere Verbindungen auf eine Frage, spielt es für unseren Wanderer zunächst keine Rolle, aus welcher Richtung er auf diese trifft. Er kann entweder dem einen ODER dem anderen Weg gefolgt sein, um nun weitere ausgehende Wege zu entdecken. Wir haben somit ein logisches ODER definiert, indem wir mehrere eingehende Verbindungen auf eine Frage gesetzt haben. Experten bezeichnen das auch als ODER-Gatter. Auf der nachfolgenden Grafik kommt unser Wanderer von rechts auf die Frage. Er hätte aber genauso gut auch von oben kommen können.

simple-or-condition

UND-Bedingungen

Was ist, wenn eine Frage erst ausgelöst werden soll, wenn vorher mehrere andere beantwortet sind? Beim ODER hast du gelernt, dass es egal ist, von welcher Straße der Wanderer ursprünglich kommt, damit er weiter gehen darf. Das müsste ja bedeuten, dass der Wanderer bei einer UND-Kreuzung von allen eingehenden Wegen gleichzeitig kommen muss, um den ausgehenden Wegen zu folgen.

Nicht ganz. Der Wanderer kann sich ja nicht aufteilen. Man könnte nun für jeden Knoten prüfen, ob die Bedingungen schon erfüllt sind, indem man den eingehenden Verbindungen rückwärts folgt und wiederum prüft, ob die gefundenen Knoten ihrerseits erfüllt wurden und so weiter. Das allerdings führt zu wenig flexiblen und umständlichen Sub-Querys.

Es geht auch einfacher: Der Wanderer muss schlicht prüfen, ob er schon mal an der Kreuzung war und beim letzten Mal über den anderen Weg gekommen ist. Dazu merkt er sich einfach die Namen der Straßen. Ist er auf allen eingehenden Wegen der Straße schon mal gewandert, darf er weiter gehen.

Auch hier ist es möglich, durch das bloße setzen von Verbindungen diese UND-Logik zu implementieren. Experten bezeichnen das auch als UND-Gatter. Wir müssen dem Wanderer lediglich sagen, dass es sich bei dem Knoten um einen UND-Knoten handelt. Diese Information ist idealerweise im Knoten selbst hinterlegt, sodass der Wanderer sie dort findet. Auf dem nachfolgenden Bild sind zwei Wege rot markiert. Der Wanderer muss auf beiden schon mal gelaufen sein, damit die nächste Frage ausgelöst wird.

simple-and-condition

Coding wird weitgehend überlüssig

Programmierung ist nicht mehr erforderlich um komplexe Konversationen abzubilden. Durch die Kombinationen verschiedener Kreuzungen vom Typ UND bzw. ODER und deren Vernetzung mit Verbindungen kannst du einfach visuell sehr komplexe logische Strukturen erschaffen. Das ist es, was ich mit logischem Graph Traversal meine. Es ermöglicht, den Kontext auch unabhängig von der Größe und Komplexität in einem langen Gespräch zu erhalten.

keeping-the-context

Die Übersichtlichkeit bleibt bestehen. Willst du wissen, wann eine bestimmte Frage gestellt wird, musst du dir lediglich die direkten Abhängigkeiten ansehen.

Damit hast du es geschafft, einen ersten Teil der Logik auf die Ebene der Datenbank zu verlagern.

Im nächsten Artikel zeige ich dir, wie die Bedingungen von den Fragen und Antworten isoliert werden können, damit wir mehr Übersicht darüber bekommen.

Mehr Artikel zum Thema findest du hier