Roboter in der Pflege
17.11.2018
Schon im Vorfeld hatte ich interessierte Nachfragen zu dem Vortrag „Können Roboter Pflegepersonal ersetzen?“, den ich gestern im LebensPhasenHaus in Tübingen gehalten habe. Hier ist eine Zusammenfassung und meine Eindrücke aus der Diskussion mit dem Publikum.

Mein Ziel für diesen Vortrag war es, Leuten die normalerweise nichts mit Robotern zu tun haben, einen Einblick in den Stand der Technik zu geben, damit sie besser gerüstet sind für Diskussionen, sei es wenn es darum geht Geld zu verteilen, Lösungen für bestimmte Anwendungsfälle zu finden, oder die zukünftige Notwendigkeit von menschlichem Pflegepersonal abzuschätzen. In erster Linie habe ich verschiedene Varianten von Robotern vorgestellt mit meinen Annahmen, was davon in der Pflege relevant sein könnte.

Lastenroboter

Es gibt Roboter, die helfen können schwere Lasten zu heben, wie Riba, der Menschen vom Bett in den Rollstuhl heben kann, oder die Botengänge verrichten, wie Casero, der schmutzige Wäsche in Krankenhäusern transportiert. Solche Roboter sind für ganz spezielle Aufgaben gemacht und können zumindest in einigermaßen strukturierten Umgebungen wie Pflegeheimen oder Krankenhäusern langweilige oder körperlich anstrengede Arbeiten von Pflegepersonal übernehmen. Sie fallen damit in das klassische Muster, nach dem Roboter Arbeiten übernehmen, die „dull, dirty, dangerous“ sind. Ich zähle hierzu auch Roboter, die Hilfsaufgaben für Leute mit speziellen Bedürfnissen erledigen, wie El-E, der motorisch stark eingeschränkten Menschen Objekte bringen kann.

Roboterbegleiter

Einer der bekanntesten „Pflegeroboter“ ist Paro. Er ist quasi ein Stofftier mit Bewegung und Geräusch. Paro wird seit einigen Jahren für die Demenz-Pflege angepriesen und verkauft. Endlich gibt es eine Studie, die den Unterschied zu normaler Pflege und zum Einsatz eines normalen Stofftiers untersucht hat [1]. Das Ergebnis ist, dass Paro nur wenig mehr bringt als ein Stofftier. Und dieses ist insgesamt betrachtet ein wenig wirtschaftlicher [2]. Das heißt nicht, dass man Paro grundsätzlich nicht einsetzen sollte, es zeigt aber, dass Paro keinen ernsthaften Vorteil gegenüber anderen Behandlungsmethoden bringt. Andere Unterhaltungsroboter haben keine bestimmte Zielgruppe, wie unser Kopernikus, den wir bei Intuity als Open Source Roboter entwickelt haben. Auch wenn ich das kleine Kerlchen sehr putzig finde und hoffe, ihn irgendwann dazu zu bringen, dass er situationsbezogen erinnert und unterhält, würde ich nicht behaupten, dass er in irgendeiner Form menschlichen Kontakt ersetzen oder Pflege effizienter machen kann. Ich sehe ihn eher als eine Art besseren Fernseher.

Ein weiteres Beispiel aus dieser Kategorie hat gestern zu einiger Diskussion geführt. Der Film Ik ben Alice fasst ein niederländisches Forschungsprojekt zusammen, bei dem eine Roboterpuppe über mehrere Tage bei drei verschiedenen allein lebenden Rentnerinnen getestet wurde. Darin sieht man, wie die Puppe in natürlicher Sprache kommuniziert und situationsbezogen, sogar stimmungsbezogen, auf die Frauen eingeht. Was in dem Film nicht gesagt wird und nur einmal kurz zu sehen ist, ist dass ein Großteil dieses Verhaltens ferngesteuert oder fest gescriptet war. Eine Zuhörerin gestern kannte den Film und hatte wirklich geglaubt, dass die Puppe das alles selbst entschieden hat. Während mindestens eine andere Zuhörerin kein Problem damit hatte, dass so eine Maschine dann eben ferngesteuert ist, wurde das ganze von einem anderen schlichtweg als Fake bezeichnet. Letzterer Meinung schließe ich mich an.

Haushaltsroboter

Eine der größten Sorgen ist für viele Leute, dass sie so lang wie möglich unabhängig leben wollen. Insofern wären Roboter, die Haushaltsaufgaben erledigen und nach dem Rechten sehen können, eine echte Hilfe. Produkte, die heutzutage als Haushaltsroboter angeboten werden, können Staubsaugen bzw. den Boden wischen, Rasen mähen oder Fenster putzen. Es kann nett sein, wenn man diese Dinge nicht selbst erledigen muss, aber keine dieser Tätigkeiten allein ist ein Hindernis, dass Leute allein leben könnten. Richtig toll wären Roboter, die wie ein Butler alles erledigen, was im Haushalt anfällt, inklusive Getränkekisten schleppen und aufpassen, dass alle Aktivitäten des täglichen Lebens wie Essen, Trinken und Reinlichkeit stattfinden. Doch heutige Roboter sind noch nicht einmal annähernd dazu in der Lage. Dieses Bewerbungsvideo für einen internationalen Roboterwettbewerb zeigt recht gut, wo der Stand der Technik gerade ist. Das gezeigte Szenario ist aus technischer Sicht absolut beeindruckend, aber es besteht immer noch eine große Lücke zwischen dem, worauf die Roboterforschung stolz ist, und dem, was im täglichen Gebrauch einen Mehrwert liefert.

Auch hier waren die Reaktionen des Publikums interessant. Einige waren sichtlich erfreut, einmal einen klaren Stand präsentiert zu bekommen und zu wissen, mit welchen Techniken man in nächster Zeit rechnen sollte. Teilweise gab es Zweifel, ob das wirklich der Stand der Technik ist und ob man nicht in den USA oder in Asien weiter wäre. Es wurde auch Kritik geäußert, dass man auch mit einfacherer Technik viel erreichen könnte. Das sehe ich genauso, aber das muss ich ja nicht erzählen, denn die Existenz von Tablets, Smart Watches und Spülmaschinen ist ausreichend bekannt. Ich glaube, hinter der Frage stand eine Erwartung, dass ich als Robotikerin fertige Lösungen für die Pflege im Gepäck hätte. Mir ist bei der Diskussion erst richtig bewusst geworden, wie schwierig es ist Technik und Pflege zusammen zu bringen. Ich habe selbst mehrere Anträge für Verbundforschungsprojekte geschrieben oder Ideen dazu ausgelotet. Bei solchen Vorhaben geht es leider nicht nur das gemeinsame Ziel die Pflege zu verbessern, sondern man muss auch Notwendigkeiten wie die Publizierbarkeit von Ergebnissen in Fachjournalen aller Beteiligten berücksichtigen. Ich glaube, dass wirklich sinnvolle Lösungen nur entstehen werden, wenn man eine Mischung von Leuten und Herangehensweise wie bei Intuity hat. Dort sehen wir uns erstmal das Problem als Ganzes an, erdenken verschiedene Lösungsideen und haben die Kompetenz zu jeder Variante schnell Prototypen zu bauen, sei es für Software, Hardware oder Organisationsstrukturen.

Künftige Entwicklungen

Bisher habe ich nur über vorhandene Roboter geschrieben. Aber die Forschung macht doch so große Fortschritte, sicher sieht das in ein paar Jahren anders aus, vor allem wenn wir jetzt ordentlich in die Forschung investieren? Dieses Argument höre ich ständig, aber ich muss leider auch da die Erwartungen dämpfen. Als Beispiel sehen wir uns das vieldiskutierte Beispiel des autonomen Fahrens an. Entgegen der Meinung, die man aus der Presse gewinnen könnte, gibt es autonomes Fahren nicht erst seit 2005 und es wurde auch nicht von Google erfunden. Seit Anfang der 1980er Jahre hat die Forschungsgruppe von Ernst Dickmanns an der Universität der Bundeswehr in München an autonomen Autos geforscht. 1987 wurden dabei Testfahrten mit bis zu 96 km/h unternommen. In weiteren Projekten, in Zusammenarbeit mit deutschen Autofirmen, wurde die Technik verfeinert. 1995 fuhr man 1758 km, davon 95% autonom, mit bis zu 175 km/h auf deutschen Autobahnen. In diesem Licht erscheint der Erfolg der DARPA Grand Challenge 2005, in der autonome Autos eine 212 km lange Strecke durch die kalifornische Wüste bewältigen mussten, etwas weniger beeindruckend. Seit diesem Erfolg und Google's öffentlich zur Schau gestelltem Interesse an autonomem Fahren gibt es kaum mehr eine Uni ohne autonomes-Auto-Projekt. Man traf sich auch weiterhin zu Wettbewerben, in Europa vor allem zum European Land Robot Trial (Elrob). Der Wettbewerb in diesem Jahr konnte zumindest den anwesenden Redakteur von Heise online nicht überzeugen:

Was sich einfach anhört, ist es manchmal nicht: Das autonome Hin- und Herfahren einer Strecke brachte manche Roboter auf der Elrob an ihre Grenzen. [Heise Online, 27.09.2018]
Halten wir also fest: die Entwicklung in der Robotik ist nicht ganz so rasant wie man gern glauben würde.

Ein weiterer Aspekt ist die ethische Dimension. In jedem Forschungsantrag, der mit Robotern und Pflege zu tun hat, findet man Zusicherungen, dass es nicht darum geht den menschlichen Kontakt zu ersetzen. Man möchte aber Kosten senken. Da fragt man sich, wie das gehen soll. Pflege besteht nun mal aus der Interaktion von Menschen. Wenn man menschliche Arbeiten ersetzt, und sei es nur das Verteilen der Klopapierrollen, ersetzt man automatisch auch menschliche Interaktion [3]. Vielleicht ist ein Einsatz trotzdem gerechtfertigt, aber vergessen sollte man diesen Aspekt nicht.

Zusammengefasst sehe ich Roboter in der Pflege als Zusatz zu anderen technischen oder organisatorischen Merkmalen. Wenn man über den Einsatz von Robotern diskutiert, hält man sich besser an den aktuellen Stand der Technik anstatt Träumereien von autonomen Butlern zu verfallen. Ich hatte den Eindruck, dass der Großteil der Zuhörerschaft gestern diese Ansicht geteilt hat. Ich hoffe, ich konnte ihnen helfen den Stand der Technik besser einzuschätzen und daraus sinnvolle Verbesserungen für die Pflege zu entwickeln.

  1. Wendy Moyle, Cindy J. Jones, Jenny E. Murfield, Lukman Thalib, Elizabeth R.A. Beattie, David K.H. Shum, Siobhan T. O'Dwyer, M. Cindy Mervin, Brian M. Draper. Use of a Robotic Seal as a Therapeutic Tool to Improve Dementia Symptoms: A Cluster-Randomized Controlled Trial. Journal of the American Medical Directors Association, 18(9), pp. 766 – 773, 2017.
  2. Merehau C. Mervin, Wendy Moyle, Cindy Jones, Jenny Murfield, Brian Draper, Elizabeth Beattie, David H.K. Shum, Siobhan O'Dwyer, Lukman Thalib. The Cost-Effectiveness of Using PARO, a Therapeutic Robotic Seal, to Reduce Agitation and Medication Use in Dementia: Findings from a Cluster–Randomized Controlled Trial. Journal of the American Medical Directors Association, 19(7), pp. 619 - 622.e1, 2018. (Focus on Care of Persons with Alzheimer's Disease and Related Dementias)
  3. Robert Sparrow. Robots in aged care: A dystopian future?. AI and Society, 31(4), pp. 445 – 454, 2016.
Usability eines Toasters
17.04.2018
Auch einfache Geräte können schwer zu bedienen sind, zum Beispiel ein Toaster. Das Beispiel zeigt auch, dass schlechtes Design durch noch so gute Dokumentation nicht zu retten ist.

So schön Reisen in Australien ist, so schade ist es, zum Frühstück keine Semmeln zu haben. Stattdessen gibt es Toastbrot, und damit es zumindest frisch und warm auf den Teller kommt, haben die Hotels am Buffet einen Toaster stehen, mit dem man das Brot nach eigenen Wünschen toasten kann.

In einem Hotel kam mein Freund mit einem verkohlten Toastbrot nach dem anderen zurück, und die Lage wurde immer verzweifelter. „Diesmal habe ich den Toaster ganz auf Stufe 1 zurückgedreht und das Brot kommt immer noch schwarz heraus.“ Interessanterweise hatten andere Leute goldbraunen Toast auf dem Teller. Was kann man an einem Toaster falsch bedienen?

Der Trick besteht darin, genau zu lesen:

Toaster Schalter: Stufe 1 bedeutet dark, Stufe 10 bedeutet light
Der Schalter war so gebaut und beschriftet, wie es aus Konstruktionssicht sinnvoll ist: auf Stufe 1 läuft der Toast langsam durch und wird dadurch dunkel, auf Stufe 10 läuft er schneller durch und bleibt heller. Mein Freund (und bestimmt nicht nur er) hatte aber das mentale Modell, das den meisten Toastern zugrunde liegt: 1 bedeutet leicht, 10 stark getoastet.

Wer immer diesen Toaster gebaut hat, würde entgegnen: die Leute müssen halt lesen können, es steht ja ganz klar auf dem Schalter. Aber offenbar lesen die Leute nicht. Auf dem Toaster steht nämlich zur Sicherheit nochmal ein Schild:

White Bread 6.5
Multigrain 6.0
Wholemeal 5.5
Toaster im ganzen mit zusätzlichem Schild

Mein Freund hatte dieses Schild gelesen, es aber ganz bewusst ignoriert, weil er es unlogisch fand, dass Vollkornbrot weniger stark getoastet werden sollte als helles Brot.

Die Moral von der Geschicht:

  1. Man halte sich an Konventionen und konstruiere Geräte nach dem mentalen Modell der Nutzenden.
  2. Keine noch so klare oder groß angebrachte Dokumentation kann unintuitive Bedienung wettmachen.

    Die Sprachen der KI
    Teil 4: Die aktuellen Champions
    24.02.2018
    Clojure und Python sind meine aktuellen Champions in der KI. Das Label „KI Sprache“ prangt nicht so deutlich wie an Lisp und Prolog, aber durch einen schnellen Entwicklungszyklus und Unterstützung durch Bibliotheken, zum Beispiel für statistisches maschinelles Lernen, sind sie die modernen Sprachen der KI.
    Dieser Blogbeitrag ist Teil einer Serie. Lesen Sie hier die bisherigen Teile:
    Teil 1: Die feinen Unterschiede
    Teil 2: Lisp – Der Klassiker
    Teil 3: Prolog – Logik pur

    Prolog ist aus der Mode gekommen, weil seine grundlegende Annahme der logischen Informationsverarbeitung an Ansehen verloren hat. Wie steht es mit Lisp, das nichts von seiner Flexibilität und Mächtigkeit verloren hat?

    Lisp gilt immer noch als die klassiche KI Sprache. 1994 wurde ein ANSI Standard für Common Lisp eingeführt, der in verschiedenen kommerziellen und freien Implementierungen umgesetzt wird. In den letzten 60 Jahren haben viele Programmiersprachen in Sachen Programmierkonzepte aufgeholt. Funktionale Sprachen implementieren jetzt die Konzepte des Lambda Kalküls – und das oft in „reinerer“ Form als Lisp; Mainstream-Sprachen haben der Reihe nach Konzepte von Lisp übernommen – sogar Java unterstützt jetzt Funktionen höherer Ordnung. Und das sind die Sprachen, die üblicherweise an Universitäten in Grundvorlesungen gelehrt werden. In einer KI Vorlesung steht man als Dozent dann vor der Wahl, einen guten Teil des Semesters zu investieren um Lisp als Sprache einzuführen, oder auf Java oder eine sonstige bekannte Sprache auszuweichen und sich stärker auf die Algorithmen zu konzentrieren (auch wenn deren Implementierung in Java oft etwas unbequemer ist als in Lisp).

    Außerdem hat sich die KI als Feld in viele kleine Einzelfelder aufgespalten. Jedes dieser Gebiete hat andere Ansprüche und kann spezifische Sprachen verwenden. So verwendet man bei der Bildverarbeitung maschinennahe Sprachen, die schnelle und optimierte Matrizenrechnungen erlauben.

    All dies hat dazu beigetragen, dass es weniger starke Sprachpräferenzen gibt als in den 80er und 90er Jahren. Trotzdem möchte ich zwei Sprachen herausheben: Clojure als moderne Variante von Lisp und Python als fast-schon-Standard für datengetriebene Verfahren.

    Clojure ist eine Neuimplementierung von Lisp auf der Java Virtual Machine. Es ist keine Umsetzung von ANSI Common Lisp, sondern fügt neue Konzepte hinzu. Beispielsweise sind die klassischen Assoc-Listen aus Lisp zu Hashmaps geworden, die auch in Java verbreitet sind. Clojure hat sämtliche Vorteile von Lisp inklusive des Makro-Mechanismus zur Definition von Spezialsprachen, und erweitert diese um

    • einen stärkeren Fokus auf funktionales Programmieren durch unveränderbare (immutable) Datenstrukturen;
    • die Unterstützung von paralleler Verarbeitung durch explizite, abstrakte Konzepte zur synchronen und asynchronen Prozesskommunikation;
    • volle Kompatibilität zu Java, man kann also alle Java-Bibliotheken nutzen. Dies ist besonders nützlich wenn man graphische Nutzeroberflächen erstellen möchte, wofür die Möglichkeiten in Lisp sehr eingeschränkt sind. Auch die Verwendung der gut ausgebauten Software WEKA zum maschinellen Lernen ist damit einfach möglich.

    Besonders außerhalb der Spezialgebiete der KI, dort wo Leute weiterhin versuchen intelligente Gesamtsysteme zu bauen (heute meist unter dem Stichwort „Kognitive Systeme“), ist Clojure die Sprache der Wahl.

    Python ist der neue Star unter den KI Sprachen. Python gilt als Skriptsprache, also eine Sprache, in der man nicht unbedingt große Programm schreibt, sondern kleine Schnipsel, die schnell kleinere oder auch mal größere Aufgaben erledigen. Wie auch Clojure ist Python eine interpretierte Sprache. Man kann also in einer Python-Konsole einfach lostippen mit 5 * 3 und bekommt als Antwort 15. In Java oder C ist das nicht möglich. Dort braucht man ein vollständiges Programm, das erst compiliert und dann ausgeführt wird. Der Entwicklungszyklus in interpretierten Sprachen ist daher viel kürzer als in compilierten Sprachen.

    Nehmen wir an, ich möchte in Python eine Funktion schreiben, die die Fakultätsfunktion berechnet (der Klassiker aus jeder Informatik-Vorlesung: man multipliziert alle Werte bis zum gegebenen Wert n, also fak(3) = 1 * 2 * 3 = 6). Ich tippe los: def fak(n): if (n == 1): 1 else: n * fak(n-1) Das sieht soweit gut aus für mich, also probiere ich es aus: fak(2) Python ist weniger überzeugt von meiner Funktion und antwortet mit einem Fehler: Traceback (most recent call last): File "", line 1, in File "", line 3, in fak TypeError: unsupported operand type(s) for *: 'int' and 'NoneType' Ach ja, in Clojure gedacht, dort wird der letzte Wert automatisch als Rückgabewert interpretiert. In Python braucht man dafür ein explizites return: def fak(n): if (n == 1): return(1) else: return(n * fak(n-1)) Der Umbau hat mich maximal eine halbe Minute gekostet und schon kann ich wieder ausprobieren: fak(3) Diesmal antwortet Python wie gewollt mit 6. Jetzt könnte ich die Funktion kopieren und in ein größeres Programm einfügen. Gesamte Entwicklungszeit für diese Funktion: unter 5 Minuten. Wenn ich das gleiche in Java probieren würde, würde ich die 5 Minuten allein dafür brauchen ein Projekt anzulegen, mir einen nichtssagenden Klassennamen auszudenken (in Java muss alles in eine Klasse), eine main-Methode anzulegen, und die Funktion zu schreiben. Obendrein müsste ich noch überlegen, wie ich das ganze testen möchte: der einfachste Fall wäre, einen Wert für n fest einzuprogrammieren und zu sehen, was das Programm ausgibt. Allerdings muss ich dann für jeden Testwert das Programm neu compilieren. Ich könnte in der main-Methode auch eine Schleife schreiben, die einen Eingabewert einliest und daraus die Fakultät berechnet. Das kostet mich wieder Zeit und wenn ein Fehler auftritt, kann dieser ebenso in meiner Fakultätsfunktion sein wie in der Schleife zum Einlesen der Werte.

    Interpretierte Sprachen erlauben also einen viel schnelleren Trial-and-Error Zyklus. Jetzt könnte man einwenden, dass Programmieren doch kein Ausprobieren sein sollte, sondern ein wohl überlegter Vorgang. Diese Denkweise stammt aus der Zeit des Wasserfallmodells, wo man daran glaubte, dass man Programme abstrakt vorkonzipieren kann und wenn man das ordentlich erledigt hat, der Code nur noch heruntergeschrieben werden muss. Dieses Vorgehen hat nie funktioniert und kann es auch gar nicht. Programmieren ist ein kreativer Prozess und der lebt vom Ausprobieren (oder eleganter ausgedrückt Prototyping, besser noch Rapid Prototyping). Agile Entwicklungsmethoden setzen deswegen auf kurze Entwicklungszyklen, in denen man schnell Fehler machen und diese genauso schnell korrigieren kann.

    In der KI ist diese Anforderung noch höher, nehmen wir als Beispiel maschinelles Lernen: Der Erfolg beim maschinellen Lernen resultiert in erster Linie von menschlicher Ingenieurskunst. Es gibt kaum theoretische Grundlagen, die sagen würden, welche und wie viele Daten man benötigt, wie man diese vorverarbeiten und repräsentieren muss. Diese Parameter kommen aus menschlicher Erfahrung und schnellem Ausprobieren, was insbesondere durch geeignete Visualisierung vereinfacht wird.

    Hingegen sind die Algorithmen an sich weniger entscheidend. Man hat keinen Grund, einen Lernalgorithmus selbst zu implementieren, das haben schon andere erledigt. Wichtig ist der Zugriff auf entsprechende Bibliotheken. Und hier liegt Python gerade ganz vorn. Es gibt nicht nur Bibliotheken für statistische Analyse und maschinelles Lernen, sondern auch welche zum Visualisieren von Daten. Lernbibliotheken sind nicht unbedingt in Python geschrieben, aber sie bieten fast immer eine Schnittstelle dazu an (z.B. TensorFlow von Google).

    Bei modernen KI-Sprachen zählt also vor allem ein schneller Entwicklungszyklus und die Verfügbarkeit von Bibliotheken. Sowohl Clojure als auch Python bieten beides und sind damit meine Favoriten.

      Die Sprachen der KI
      Teil 3: Prolog – Logik pur
      19.02.2018
      Prolog war die Sprache des letzten KI Hypes. Vor allem in Europa, Kanada und Japan hat man große Hoffnungen auf sie gesetzt.
      Dieser Blogbeitrag ist Teil einer Serie. Lesen Sie hier die bisherigen Teile:
      Teil 1: Die feinen Unterschiede
      Teil 2: Lisp – Der Klassiker

      Prolog ist die zweite klassische Sprache für KI Anwendungen. Sie wurde 1972 von Alain Colmerauer und Philippe Roussel entwickelt. Reines Prolog verwendet eine eigene Syntax, aber frühe und auch einige heutige Implementierungen verwenden das Makrosystem von Lisp, sie definieren Prolog also als Spezialsprache unter Verwendung von Lisp.

      Prolog steht für PROgrammation en LOGique und setzt damit schon im Namen ein klares Ziel: Programme in Prädikatenlogik zu schreiben. Das Ziel leitet sich von der Annahme ab, dass Wissen gut in Prädikatenlogik repräsentierbar ist (wie das Beispiel aus Teil 2: auf(Laptop,Tisch)) und dass intelligentes Verhalten aus logischen Schlussfolgerungen resultiert.

      Diese Ansicht war im letzten KI Hype der 80er Jahre weit verbreitet. Insbesondere im japanischen Fifth Generation Computing Project spielte Prolog eine wichtige Rolle. Eine der großen Aufgaben zu dieser Zeit war die Sprachverarbeitung. Diese basierte damals vor allem auf der Idee der Universalgrammatik von Noam Chomsky. Dieser nahm an, dass alle Sprachen - egal ob natürlich oder formal - auf dem gleichen Prinzip beruhen. Prolog unterstützt diese Art der Sprachverarbeitung mit einem eingebauten Parser und einer speziellen Syntax zum Definieren von Grammatiken.

      Satz --> Nominalphrase, Verbalphrase. Nominalphrase --> Name. Nominalphrase --> Artikel, Substantiv. Verbalphrase --> IntransitivesVerb. Aus dieser einfachen Grammatik kann man bereits eine Menge Sätze generieren, wenn man noch ein keines Wörterbuch hinzufügt (die Wörter sind alle klein geschrieben, da Großbuchstaben für Prolog Variablen sind):

      • Name: asterix, obelix
      • Artikel: der, die
      • Substantiv: ente, tisch
      • IntransitivesVerb: steht, schläft
      Daraus entstehen Sätze wie „obelix schläft“, „asterix steht“, „die ente schläft“, „der tisch steht“. Allerdings auch „die tisch schläft“ oder „der ente steht“.

      Prolog kann solche Sätze – mit gegebener Grammatik und Wörtern – sowohl generieren als auch parsen, also testen ob sie grammatikalisch korrekt sind. Prolog ermöglicht es auch, solche Grammatiken mit weiteren Syntaxprüfungen zu erweitern (z.B. die Kongruenz zwischen Artikel und Substantiv sicher zu stellen) und die Satzstruktur mit Bedeutung zu verknüpfen, sodass beispielsweise ein Satz wie „wer ist der freund von asterix“ mit der Antwort „obelix ist der freund von asterix“ beantwortet wird.

      Ich habe Prolog in 4 Semestern in Vorlesungen verwendet und die Studierenden einfache Chatbots und sprachbasierte Computerspiele damit implementieren lassen. Daran lässt sich wunderbar ein Dilemma der KI aufzeigen: Man kann mit geeigneten Werkzeugen sehr einfach Programme erstellen, die beeindruckende Ergebnisse liefern; ein einfacher Chatbot ist mit Prolog in 100 Code-Zeilen zu bekommen. Aber der Schritt von einem einfachen ersten Aufschlag zu einem nützlichen Programm, das auch mit unerwarteten Fragen zurecht kommt, ist eine komplett andere Aufgabe. Da genügt es nicht, aus 100 Zeilen 150 Zeilen Code zu machen. Vielleicht schafft man es mit sehr viel Nutzertesten, einer guten Story außenrum und viel Handarbeit einen verwendbaren Chatbot für eine Spezielaufgabe daraus zu entwickeln; dann ist aber auch Schluss.

      Ein Programm, das auf jede beliebige Frage zumindest sinnvoll antwortet, ist eine andere Geschichte. Man kann kaum erwarten, dass eine Programm auf jede beliebige Frage eine Antwort weiß. Da Menschen aber meist von ihrem eigenen Funktionsumfang ausgehen, erwartet man intuitiv zumindest, dass ein Chatbot eine sinnvolle Frage („Welchen Umfang hat die Erde“) von einer reinen Wortfolge („Umfang Erde“) oder komplettem Unsinn („asdf“) unterscheiden kann; oder dass es mitbekommt, wenn es beleidigt wird (ein Schicksal das Chatbots häufig widerfährt, Beispiele erspare ich der Leserschaft). Ich bezweifle, ob so ein Programm überhaupt mit den (Standard-)Mitteln von Prolog erzeugbar ist.

      Prolog ist also eine Spezialsprache zur Verarbeitung von Wissen und natürlicher Sprache nach einem bestimmten Paradigma, nämlich Logik. Programme, die auf logischem Schlussfolgern beruhen, kann man mit Prolog deutlich eleganter und in kürzerer Zeit schreiben als mit jeder anderen Sprache. Die Frage ist aber, ob Intelligenz tatsächlich durch Logik entsteht. Die aktuelle Mode setzt jedenfalls auf datengetriebene Verfahren – so ziemlich das Gegenteil von Logik. Damit ist Prolog nicht automatisch tot. Einerseits kann die Mode sich wieder ändern, und andererseits kann Logik als Bestandteil eines komplexeren Programms dienen. Moderne Prolog Implementierungen bieten deshalb Schnittstellen zu Mainstream-Sprachen wie Java oder C.

        Weitere Teile in dieser Serie:
        Teil 4: Die aktuellen Champions
        Die Sprachen der KI
        Teil 2: Lisp – Der Klassiker
        12.02.2018
        Lisp ist seit 60 Jahren die Sprache der KI. Dieser Beitrag erklärt, was Lisp einzigartig macht.
        Dieser Blogbeitrag ist Teil einer Serie. Lesen Sie hier die bisherigen Teile:
        Teil 1: Die feinen Unterschiede
        If you give someone Fortran, he has Fortran.
        If you give someone Lisp, he has any language he pleases.
        Guy Steele

        Lisp wurde 1958 von John McCarthy am MIT entwickelt, ein Jahr nach Fortran. Sprachen wie Fortran (prozedurale Sprachen) gehen von der „mitgelieferten“ Sprache der Maschine aus und abstrahieren oft genutzte Operationen, wie bei dem Beispiel der Multiplikation in Teil 1 dieser Blog-Serie. Lisp stützt sich dagegen auf ein mathematisches Konzept (das Lambda-Kalkül), bei dem die Funktionalität durch Funktionen beschrieben wird. Diese Art von Sprachen bezeichnet man als deklarativ, weil man mehr beschreibt, was das Ergebnis sein soll, und weniger in welchen Schritten die Maschine dieses errechnen soll.

        Ein deklaratives Konzept, das in der KI immer eine große Rolle gespielt hat, ist Logik. Man möchte vielleicht etwas ausdrücken wie „Der Laptop ist auf dem Tisch“. Mathematisch lässt sich das in Prädikatenlogik ausdrücken durch auf(Laptop,Tisch) (Hier wird angenommen, das Laptop und Tisch Konstanten sind, es gibt also nur diesen einen Laptop und diesen einen Tisch.)

        Computer sind aber nunmal Rechenmaschinen und können originär nur Zahlen repräsentieren. Aber man kann die Nullen und Einsen in einem Speicher statt als Binärzahl als Repräsentation für eine Konstante wie Tisch auffassen. Dies fällt leichter, wenn die Programmiersprache diese Umwandlung bereits vornimmt und man als Programmierer nur noch mit Symbolen wie Tisch und Laptop arbeiten muss. Lisp bietet ausgezeichnete Unterstützung für solche symbolische Repräsentationen. Anders als Prolog, das wir im nächsten Teil genauer ansehen, ist Lisp aber nicht auf Symbole beschränkt, sondern unterstützt genausogut „normale“ Berechnungen. Sie bietet damit eine enorme Vielfalt an Repräsentationsmöglichkeiten und Herangehensweisen zur KI. Denn bis heute kann man sich nicht darauf einigen, ob KI (rein) symbolisch arbeitet oder ob subsymbolische Prozesse (also Rechnen) Intelligenz ausmachen.

        Am Rande sei erwähnt, dass die Idee der symbolischen Repräsentation bereits in der (KI-) Sprache IPL vorhanden war. Im Gegensatz zu Lisp war diese spezifisch für symbolische Verarbeitung und ihr Abstraktionsgrad erinnert eher an Assembler als an eine moderne Programmiersprache. Deshalb wurde sie sehr schnell von Lisp abgelöst.

        Neben der Allgemeinheit war Lisp in vielen Aspekten ihrer Zeit voraus. Konzepte wie Rekursion, Funktionen höherer Ordnung (d.h. dass man Funktionen als Wert übergeben kann) und automatische Speicherverwaltung, sind mittlerweile vor allem in funktionalen Sprachen vorhanden und finden schrittweise ihren Weg in Mainstream-Sprachen wie Java. Ein Beispiel, das zeigt, wie weit Lisp seiner Zeit voraus war: Funktionen höherer Ordnung kamen bei Java mit Version 8, im Jahr 2014, und damit 56 Jahre später als in Lisp.

        Ein Merkmal, das Lisp bis heute einmalig macht, ist die schmale Grenze zwischen Daten und Code. Beispielsweise ist (+ 1 2 3) die Aufforderung die drei gegebenen Zahlen zu addieren, das Ergebnis ist 6. Dagegen wird die Zeile '(+ 1 2 3) als reine Daten interpretiert, genaugenommen als Liste. Man kann z.B. das erste Element dieser Liste abfragen: (first '(+ 1 2 3)) und erhält das Symbol (!) + zurück. Auch folgende Zeile akzeptiert Lisp als Liste von Zahlen und +-Symbolen: '(+ 1 + 2 + 3) Interpretiert man diese Liste jedoch als Code (+ 1 + 2 + 3) dann liefert Lisp einen Fehler zurück (nur das erste Element bezeichnet ein Funktionssymbol, der Rest wird als Argumente interpretiert und + ist kein sinnvolles Argument für eine Addition). Man kann also durch ein Hochkomma aus Code Daten machen. Anders herum geht das auch: die Funktion eval macht aus Daten Code: (eval '(+ 1 2 3)) liefert als Ergebnis 6.

        Das klingt vielleicht erstmal nach Spielerei, und tatsächlich verwendet man eval höchst selten. Das Konzept Daten in Code und andersherum verwandeln zu können, erlaubt jedoch einen Mechanismus, um eigene Sprachen zu definieren. Auch wieder mit deutlicher Verspätung zu Lisp, wird so etwas heute als Domain Specific Language bezeichnet. In meiner Dissertation habe ich diesen Mechanismus verwendet, um die Sprache ROLL (Robot Learning Language) zu implementieren, die Lernverfahren für Roboterprogramme so zur Verfügung stellt, dass Roboter aufgrund eigener Erfahrungen ständig weiterlernen können. Dazu musste ich keinen eigenen Compiler schreiben, ich konnte den vollen Funktionsumfang von Lisp nutzen und ihn für meine Zwecke erweitern. Eine schöne Erklärung zur Besonderheit von Lisp Macros bietet dieses Diskussionsforum.

        Lisp verdankt ihre Beliebtheit also ihren modernen Programmierkonzepten und ihrer Universalität bezüglich symbolischer und numerischer Verarbeitung, sowie der Möglichkeit aus ihr Spezialsprachen zu definieren.

          Die Sprachen der KI
          Teil 1: Die feinen Unterschiede
          05.02.2018
          Lisp und Prolog sind klassische Vertreter von KI-Programmiersprachen. Aber ist künstliche Intelligenz überhaupt an die Sprache gebunden? Ich erkläre in dieser Blog-Serie warum manche Sprachen bevorzugt für KI genutzt wurden und werden.

          Was macht eine Programmiersprache besonders geeignet für KI Projekte? Aus Sicht der theoretischen Informatik sind alle gängigen Programmiersprachen Turing-vollständig. Das heißt, sie haben die gleiche Ausdruckskraft, können also den vollen Funktionsumfang eines Computers ausschöpfen.

          Unterschiede gibt es im Abstraktionsniveau: Maschinensprache bzw. Assembler verfügen über wenige Kommandos, die quasi vom Prozessorhersteller mitgeliefert wurden. Häufige Kombinationen von Assembler-Kommandos werden in abstrakten Sprachen zu kürzeren und besser lesbaren Kommandos zusammen gefasst. Will man beispielsweise zwei Zahlen multiplizieren, sieht das in einer Assemblersprache in etwa so aus (die Syntax folgt dem Little Man Computer): lda 16 sto 52 in sto 50 in sto 51 lda 51 brz 14 sub 17 sto 51 lda 52 add 50 sto 52 br 6 lda 52 out cob dat 1

          Das sind 18 Zeilen für das Einlesen von zwei Zahlen, ihre Multiplikation und Ausgabe. In einer prozeduralen Sprache erreicht man das gleiche mit 4 Zeilen: x := read() y := read() r = x * y output(r)

          Abstrakte Sprachen unterscheiden sich wiederum durch ihren Stil. So wie bei der Malerei fließende Farbübergänge mit Ölfarben einfacher zu bewerkstelligen sind als mit Acrylfarben, sind bestimmte Operationen in einigen Sprachen einfacher, in anderen komplizierter. Beispielsweise sind Listen das zentrale Konzept in Lisp (die Abkürzung für LISt Processor). In Lisp ist deshalb das Erzeugen und Bearbeiten von Listen eine sehr einfache Angelegenheit: (map + '(1 2 3) '(5 7 9)) addiert jeweils die Elemente der gegebenen Listen (1 2 3) und (5 7 9), und liefert die neue Liste (6 9 12).

          Im Gegensatz dazu stammt Java aus der objektorientiert-prozeduralen Welt, wo die typische Datenstruktur der Array ist, der eine direkte Abbildung des Speichers darstellt. Für das Additionsbeispiel ist es egal, ob man Listen oder Arrays verwendet, doch auch mit Arrays ist diese Operation in Java komplizierter (weitere Varianten zum Addieren von zwei Arrays werden hier diskutiert): int[] a1 = {1, 2, 3}; int[] a2 = {5, 7, 9}; int[] result = new int[a1.length]; for (int ii = 0; i < result.length; ++ii) { result[ii] = a1[ii] + a2[ii]; } return(result);

          Bei der Wahl der Programmiersprache sollte man also einerseits auf den Abstraktionsgrad allgemein achten, damit man in wenigen Code-Zeilen viel ausdrücken kann, und andererseits auf die Passung der Programmiersprache zur Aufgabe. In den folgenden Teilen zeige ich, welche Anforderungen in der KI dazu geführt haben, dass Lisp und Prolog lange Zeit bevorzugt wurden. Im letzten Teil diskutiere ich die aktuellen Anforderungen, insbesondere in Bezug auf maschinelles Lernen und die daraus hervorgehenden neuen Stars in der KI: Python und Clojure.

            Forschung vs. Wissenschaft
            13.01.2018
            Sind Forschung und Wissenschaft das gleiche? Betrachtet man die Begriffe genauer, erhält man eine neue Sicht auf die Probleme im aktuellen Wissenschaftssystem. Auch Vorurteile, dass Wissenschaft abgehobene, unnütze Theorien hervorbringe, lösen sich dabei auf.

            Mit meinem Entschluss mich selbständig zu machen kam die Frage nach meiner neuen Berufsbezeichnung auf. „Independent Scientist“ in Anlehnung an andere freie Berufe wie Journalisten gefiel mir. Aber heißt es eigentlich „Scientist“ oder „Researcher“?

            Ein wenig Internetrecherche [1] [2] bringt folgende Unterscheidung hervor: „Research“ ist das Durchführen von Forschungsarbeiten. Im Hinblick auf ein Ziel oder eine Forschungsfrage wendet man fachspezifische Methoden an (z.B. Experimente oder Literaturrecherche). Am Ende steht eine möglichst objektiv nachvollziehbare Lösung der Aufgabenstellung. „Science“ geht darüber hinaus, indem Forschungsergebnisse zu abstrakten Modellen und Theorien verallgemeinert werden. Somit ist „Research“ ein Teilschritt von „Science“.

            Im Deutschen scheint die Unterscheidung weit weniger stark ausgeprägt zu sein [3]. Ich glaube aber, die Unterscheidung im Englischen lässt sich auch gut im Deutschen anwenden. In Unternehmen gibt es Forschungs- und Entwicklungsabteilungen, aber keine Wissenschaftsabteilungen. Daher könnte man auch hier Forschung als projektbasierte Tätigkeit auffassen, während Wissenschaft eine weitere Abstraktion sucht.

            Kürzlich habe ich das wissenschaftliche System mit seinem Versuch wissenschaftliche Leistung zu quantifizieren dafür verantwortlich gemacht, dass in der Künstlichen Intelligenz in den letzten Jahrzehnten kaum Fortschritte an grundlegenden Fragen erzielt wurden [4]. Wenn ich jetzt über die Unterscheidung von Wissenschaft und Forschung nachdenke, ist das Problem weniger, dass Wissenschaft falsch betrieben wird, sondern dass an Universitäten nur noch geforscht wird, ohne den Schritt der wissenschaftlichen Verallgemeinerung. Das zeigt sich schon an der Finanzierung, die immer mehr auf Projekten beruht, die einzeln beantragt werden. Auch die Bewertungsmaßstäbe zielen rein auf Forschung ab: die Länge der Publikationsliste und die Höhe der eingeworbenen Drittmittel sind die Indikatoren für gute „Wissenschaft“ (also eigentlich Forschung). Diese Kennzahlen eignen sich noch nicht einmal zur Bewertung von Forschung, denn auch hier kann man ordentlich oder schlampig arbeiten, einfache oder schwere Fragen stellen usw. Der wissenschaftliche Aspekt, der über Forschung hinausgeht, wird bei Berufungsverfahren noch nicht einmal als Kriterium gelistet.

            Daher ist die Frage vielleicht nicht „Was stimmt nicht an der Wissenschaft?“, sondern eher „Will sich unsere Gesellschaft Wissenschaft leisten oder kommen wir mit Forschung aus?“. Die Realität gibt eine klare Antwort: An Universitäten wird man nicht für Wissenschaft bezahlt, sondern für Forschung.

            Um dies zu rechtfertigen, könnte man das Argument der Praxisnähe anbringen. Da Forschung auch in Unternehmen betrieben wird, wird der Begriff automatisch mit dem Lösen praktischer Probleme assoziiert, während Wissenschaft eher mit realitätsfernen, abgehobenen Konzepten in Verbindung gebracht wird. Meine Unterscheidung oben sagt allerdings überhaupt nichts über die Anwendbarkeit von Forschung oder Wissenschaft aus. Das Erarbeiten einer Theorie oder eine allgemeinen Modells bedeutet nicht, dass man sich damit von der Realität abwendet. Ich finde Wissenschaft sollte Probleme angehen, die auch tatsächlich vorhanden sind. Der Ruf der Realitätsferne in der Wissenschaft kommt wohl eher daher, dass die Forschung in Universitäten keine nachvollziehbaren Ziele verfolgt. Während Forschung in der Wirtschaft auf das Erschaffen von Produktion, Prozessen oder Dienstleistungen abzielt, sollte die Forschung an Universitäten durch wissenschaftliche Konzepte motiviert sind. Da aber Wissenschaft geradezu bestraft wird, werden Forschungsfragen danach ausgewählt, was sich am einfachsten und schnellsten veröffentlichen lässt. Und nach diesem Kriterium fallen echte Probleme automatisch weg, da diese üblicherweise sehr schwierig sind und damit ein großes Risiko beinhalten, nicht schnell oder „gut“ genug veröffentlicht werden zu können.

            Was ist nun meine korrekte neue Berufsbezeichnung? Ich sehe mich ganz klar als „Scientist“. Wenn ich zum zweiten Mal das gleiche Problem zu lösen habe, fange ich an, die Aufgabe zu abstrahieren und ein allgemeines Modell zu entwickeln. Meine Kunden profitieren davon, indem wir Lösungen nicht von Null auf erarbeiten müssen und stattdessen grundlegende Mechanismen von früheren Projekten nutzen können. Forschung gehört damit zu meinen Aufgaben: ich recherchiere Techniken und verwandte Ansätze, ich erprobe Lösungsalternativen und evaluiere diese. Aber mein Anspruch ist die Verallgemeinerung und Abstraktion, nicht als kognitive Spielerei, sondern um darauf aufzubauen und in Zukunft komplexere Aufgaben bewältigen zu können. Im universitären Forschungssystem wurde mir dieser Anspruch an mich selbst immer negativ ausgelegt. Ich hoffe, dass ich nun meine Leidenschaft zur Wissenschaft im Kontext realer Probleme produktiv anwenden kann.

            1. Matjaž Hren. Are You a Scientist or a Researcher?. https://scinote.net/blog/are-you-a-scientist-or-a-researcher/ 11 Aug., 2015.
            2. Jeff Fulton. The Difference Between Research & Science. http://classroom.synonym.com/difference-between-research-science-5989843.html
            3. Christian Lehmann. Wissenschaft. http://www.christianlehmann.eu/ling/epistemology/Wissenschaft.html 22 Feb., 2012.
            4. Alexandra Kirsch. Lessons from Human Problem Solving for Cognitive Systems Research. Advances in Cognitive Systems, 5 2017.