Steffen Süpple
07.03.2019
Themenabend: Die Modellierung unserer Welt im Computer
Wissensrepräsentation in der künstlichen Intelligenz
Dr. Alexandra Kirsch ist Expertin für künstliche Intelligenz und maschinelles Lernen bei Intuity. In über 15 Jahren universitärer Forschung und Lehre hat sie sich mit verschiedenen Aspekten kognitiver Systeme beschäftigt.
Das Fachgebiet der künstlichen Intelligenz erhebt den Anspruch (mindestens) die volle Denkfähigkeit von Menschen zu reproduzieren. Dies setzt voraus, dass meschliches Wissen über die Welt zumindest repräsentierbar ist, d.h. dass es Formalismen gibt, die einerseits den vollen semantischen Umfang von menschlicher Sprache erfassen können und andererseits im Computer abbildbar sind.
In den 60 Jahren seit der Begriff „künstliche Intelligenz” zum ersten Mal verwendet wurde, hat man eine Reihe von Darstellungsformen und dazu passenden Verarbeitungsalgorithmen entwickelt. In Form von Logik oder Ontologien lassen sich Objekte und Relationen zwischen Objekten gut repräsentieren und daraus Schlussfolgerungen ableiten. Die Welt folgt jedoch nicht immer logischen Regeln oder man hat unzureichende Informationen, um diese Regeln anzuwenden. Deshalb sind aktuell Repräsentationen beliebt, die Sachverhalte mit Wahrscheinlichkeiten repräsentieren. Die reichhaltige Information über Objektrelationen, die durch Logik ausdrückbar ist, bleibt dabei jedoch nur bedingt erhalten. Ähnlich verhält es sich bei der Repräsentation von unscharfen Sachverhalten. Fuzzy Logic berücksichtigt die Möglichkeit, dass eine Eigenschaft teilweise erfüllt ist (z.B. “ein einigermaßen gutes Buch”), ist aber in der Ausdruckskraft auf einzelne Objekte bzw. Eigenschaften beschränkt.
Diese Techniken können also gewisse Aspekte menschlicher Sprache und menschlichen Denkens abbilden, jedoch immer nur isoliert. Es gibt bisher keine Repräsentation, die reichhaltige Relationen, Wahrscheinlichkeiten und Unschärfe gleichzeitig darstellen und effizient verarbeiten kann. Durch einen mangelnden Austausch zwischen Fachgebieten, finden sich zu all diesen Repräsentationen äquivalente Datenstrukturen aus anderen Teilgebieten der Informatik, oft unter anderem Namen. Daher hat die künstliche Intelligenz hinsichtlich Repräsentationen kaum etwas zu bieten, was nicht mit einer normalen Datenbank und etwas zusätzlicher Mathematik zu erledigen wäre.
Die Erkenntnis, dass die meisten Techniken direkt auf Datenbanken zurückführbar sind, kann man als Befreiung von ausgetretenen Denkpfaden verstehen. Datenbanken sind extrem effiziente, gut verfügbare Werkzeuge. Aufbauend auf dieser stabilen Basis sollte die KI nun reichhaltigere Repräsentationen und Werkzeuge abseits der restlichen Informatik erforschen.
Rectangular Only (…and I’m ok with it)
Prof. Dr. Torsten Grust ist Professor für Datenbanksysteme an der Universität Tübingen. Sein Lehrstuhl beschäftigt sich unter anderem damit, nichtrelationale Daten mit Hilfe von Datenbanktechnologie effizient zu verarbeiten.
Datenbanken bilden die Welt in Form von Tabellen ab; man kann also sagen, dass man jedes Wissen über die Welt in eine rechteckige Form gießen muss, um Datenbanken zu nutzen. Dies mag auf den ersten Blick als Einschränkung erscheinen, dennoch funktioniert diese Form für erstaunlich viele Sachverhalte, die auf den ersten Blick überhaupt nicht “rechteckig“ wirken. Zudem kommen Datenbanken mit einem gut verstandenen mathematischen Fundament, das eine effiziente Implementierung von Suchanfragen erlaubt.
Folgende Beispiele zeigen, wie man auf den ersten Blick nicht tabellarische Daten in eine rechteckige Form transformieren und mit Hilfe von Datenbankoperationen Schlüsse daraus ziehen kann:
Igelgraphiken
Einfache Diagramme aus Linien und Eckpunkten kann man elegant als sogenannte Igelgraphik repräsentieren. Dabei kann man sich einen Igel vorstellen, der mit einem Stift über eine Zeichenoberfläche läuft. Er kann dabei mit abgesengtem Stift laufen, um zu zeichnen, oder den Stift absetzen und ohne Spur laufen. Eine Graphik kann demnach durch eine Liste von geradlinigen Streckenabschnitten des Igels beschrieben werden.
Solche Graphiken könnte man naiv als BLOB in einer Datenbank darstellen, d.h. als ein Objekt, das für die Datenbank keine weitere Bedeutung hat. Dadurch verliert man jedoch jede Möglichkeit inhaltliche Anfragen über die Graphik durch eine Datenbankanfrage zu beantworten. Sinnvoller ist es, die Liste, die eine Graphik repräsentiert, selbst als Tabelle zu speichern. Dadurch kann die Datenbank direkt Fragen beantworten wie zum Beispiel “gib mir alle Objekte, die gezeichnet werden können ohne den Stift abzusetzen”.
Baumstrukturen
Eine typische Datenstruktur in der Informatik sind Bäume, in denen Elemente hierarchisch angeordnet sind. Ein typisches Beispiel dafür sind XML Dateien. Typischerweise würde man XML Dateien mit einem speziellen Parser durchlaufen, um bestimmte Elemente zu finden. Diese Funktionalität erhält man jedoch auch gratis mit einer Datenbank, wenn man den XML Baum entsprechend kodiert darin ablegt. Der Schlüssel dazu ist eine geschickte Nummerierung der Elemente im Baum, die die hierarchische Struktur erhält. Anfragen darüber — z.B. den Pfad zu einem bestimmten Element zu finden — sind nicht nur möglich, sondern sogar besonders effizient in einer Datenbank ausführbar.
Graphen
Graphen sind eine weitere verbreitete Datenstruktur, mit der man beispielsweise Städte und Verbindungsstraßen auf einer Karte repräsentieren kann. Typische Fragen, die man damit beantworten möchte, ist ob ein Graph zusammenhängt — also ob jede Stadt von jeder anderen erreichbar ist — oder alle möglichen Pfade zwischen zwei Punkten zu bekommen. Mit zwei Tabellen, eine für die Knoten und eine für die Kanten, hat man einen Graphen so repräsentiert, dass alle Information vorhanden ist. Durch rekursive Anfragen können die genannten Anfragebeispiele durch die Datenbank beantwortet werden.
Automaten, Zeitreihen und Physiksimulationen: all das hat der Lehrstuhl für Datenbanksysteme der Uni Tübingen bisher in eine rechteckige Form gebracht und bisher ist keine Aufgabe aufgetaucht, die sich diesem Prozess entzogen hätte.
Wenn Designer modellieren (…und über den Tellerrand schauen!)
Steffen Süpple war Gründer und Geschäftsführer von Intuity. Zuvor war er Professor für Interaktionsgestaltung an der HfG Schwäbisch Gmünd und wissenschaftlicher Mitarbeiter am Institut für Organisation und Management von Informationssystemen an der Universität Ulm.
Wir leben in einer programmierbaren Welt. Daraus ergeben sich komplexe Systeme, die wiederum mit weiteren komplexen Systemen interagieren. Wir müssen lernen die neuen Verknüpfungen zu modellieren; je besser wir modellieren können, je bessere Werkzeuge wir dafür erfinden, um so besser können wir die Welt gestalten!
In einem Designprozess modelliert man einen Sachverhalt in enger Absprache mit Stakeholdern. Man repräsentiert das Modell als Skizzen und Graphiken, und wendet es an um Prototypen und Produkte zu entwerfen. Die daraus entstehenden Produkte ändern die Welt, damit müssen auch die Modelle kontinuierlich aktualisiert werden.
Verschiedene Beispiele aus der Praxis von Intuity zeigen wie DesignerInnen solch eine Aufgabe angehen und wie sich durch den Modellierungsprozess auch die ursprüngliche Aufgabe verändern kann. So hatte Intuity den Auftrag eines mittelständischen Maschinenbauunternehmens ein User Interface zur Kalibrierung einer Schweißzange zu verbessern. Dabei hat sich herausgestellt, dass das eigentliche Problem nicht im User Interface, sondern im Prozess der Kalibrierung lag. Intuity hat den kompletten Prozess analysiert (wer macht wann, was, an welchem Gerät?), neu strukturiert und entsprechende Werkzeuge entworfen.
Ein weiteres aktuelles Beispiel ist die Zusammenarbeit mit Cuboid Parking, bei der der gesamte Geschäftsprozess von Miniparkhäusern in Innenstädten entwickelt wird. Dabei gilt es ein komplexes System von Unteraufgaben zu koordinieren und miteinander zu vernetzen.
Intuity hat aus diesen und weiteren Projekten gelernt, dass es wichtig ist
- mit Domänen-ExpertInnen zu reden und der Bedeutung des Problems auf den Grund zu gehen
- über den Rand eines Problems hinauszudenken und das richtige Framing zu finden
- eigene Werkzeuge wie Landkarten zur Kommunikation und Bearbeitbarmachung von Ideen zu entwickeln
- Modellierung als sozialen Prozess zu verstehen, der sozialen Regeln folgt
Great software is built in teams, not in isolation: Team-Driven Modeling
Golo Roden ist Gründer, CTO und Geschäftsführer von the native web. Matthias Wagler ist leitender Entwickler bei the native web und Creative Technologist bei Intuity. Beide entwickeln wolkenkit, ein semantisches Javascript Backend, das auf dem Domain-Driven Design Konzept basiert.
Ein Modell ist ein spezifischer Ausschnitt aus der Welt, der einige Aspekte sehr genau wiedergibt, andere nur ungenau oder gar nicht. Selten wird erwähnt, dass ein Modell immer ein Kompromiss ist. Beispielsweise stellt eine Mercator-Projektion eine Weltkarte exakt winkeltreu dar, die Längen- und Flächenmaße jedoch verzerrt. Für Seekarten ist diese Darstellung der Welt ausgezeichnet, für einen Größenvergleich von Ländern nicht.
In der Informatik herrscht immer noch der Mythos des “Kellerkindes“ vor, wonach Software am besten von weltfremden Nerds geschrieben wird, die in einer dunklen Kammer vor sich hinarbeiten. Es ist jedoch längst erwiesen, dass gute Software nur durch funktionierende transdisziplinäre Teams entsteht.
Viele Softwareprojekte scheitern heute an der mangelnden Diskussion zwischen InformatikerInnen und DomänenexpertInnen. Dies ist nicht nur darauf zurückzuführen, dass eine derartige Diskussionskultur im Informatikstudium nicht gelehrt wird, sondern auch auf die Bequemlichkeit beider Seiten, wonach es einfacher ist Anforderungsdokumente in einem wohldefinierten Prozess auszutauschen anstatt sich intensiv mit der gemeinsamen Aufgabe und der anderen fachlichen Sichtweise auseinander zu setzen.
Team-Driven Modeling ist ein Ansatz um eine bessere Zusammenarbeit zwischen Domänen – und Technikperspektiven herzustellen, sodass alle Beteiligten Spaß daran haben. Domain-Driven Design dient dabei als Sprache für das gemeinsam erarbeitete Domänenmodell, Event-Storming als Methode um ein gemeinsames Verständnis zu entwickeln. Daraus ergibt sich ein interaktives Workshop-Format, in dem alle Beteiligten mitreden können. Indem mögliche Workflows mit Klebezetteln notiert werden, können diese nicht nur schnell und gemeinsam erstellt, sondern ebenso schnell geändert oder verworfen werden. Man entwickelt so ein gemeinsames mentales Modell und nebenbei ein Gruppengefühl, in dem alle Beteiligten Verantwortung für das Projekt entwickeln.
In dem resultierenden Prozess wird mehr Zeit auf die Kommunikation verwendet und weniger Zeit auf die Erstellung des Codes. the native web entwickelt wolkenkit als Werkzeug, mit dem ein Domain-Driven Design Modell direkt in Code überführt wird.
Wir bedanken uns bei den Vortragenden für Ihre interessanten Beiträge und beim Publikum für das große Interesse und die anschließenden Diskussionen.