What is AI?
Part 2: Strong, weak and no AI
13.01.2019
Following up on the question what destinguishes AI from non-AI we look at the more fine-grained distinction of strong vs. weak AI.
This blog post is part of a series. Read the previous parts here:
Part 1: The original definition

We have seen how AI started with an intuitive notion of reproducing or simulating intelligence in the form of a computer program. The open question was how general the methods have to be to deserve the label AI as opposed to standard engineering.

The idea of intelligent machines has been taken up by philosophers to discuss whether this goal is possible or desirable. John Searle considered AI to be impossible, because a computer can never be "conscious", illustrating the idea in his famous Chinese Room thought experiment. He argued that outward intelligent behavior (which he assumed wrongly could be implemented with simple rules) is distinct from consciousness. I have always wondered why anyone bothered to respond to such a foolish argument. But they did and the solution was a split of AI into imaginary subfields:
The claim that machines can be conscious is called the strong AI claim; the weak AI position makes no such claim. [1]

Psychologists and neuroscientists avoid the term consciousness since it contradicts the generally accepted view that human behavior stems from physical, albeit very complicated, processes. But if we just follow fixed mechanical rules, is there anything such as free will? And we all feel something like consciousness, where does it come from? Current scientific methods cannot answer these questions, and therefore, they are usually considered to be outside the scope of science. This also implies that strong AI is not worthy as a scientific endeavour as it involves the notion of consciousness.

Coming back to the original endeavour of understanding and reproducing intelligent behavior with computers, to make philosophers happy, we call it weak AI and ignore the consciousness debate. But this is not the end, unfortunately. Some people seem to equal intelligence with consciousness, and consequently no consciousness implies no (general) intelligence (in exact contradiction of Searle's argument). In this way, the original idea of AI got thrown into the strong AI box, which had already been labeled as unscientific.

What remains is the weaker version of weak AI, also called narrow AI: solving small, well defined problems. This field has been celebrated as having made tremendous achievements in the last decades. Apart from the little detail that these achievements had nothing to do with the understanding of intelligence (they are mostly due to the increase in computing power and infrastructure), how are they different from any other type of computational engineering? They are not, and they should not be called AI.

The narrowing of AI down to standard engineering is correlated with the dilemma of funding. Specific applications with well-defined goals are more justifiable, graspable, and achievable in the short time horizons of third-party funded research projects, and therefore the easier path for most scientists. AI in the sense of general mechanisms that are applicable to a wide range of problems, is so hard that we have not even found the right research questions. In an ideal world this would be seen as a challenge. But in the world we live in researchers are forced to tackle small, simple problems to be able to publish at the prescribed pace. Instead of producing, you would have to sit back and think, very likely thinking in the wrong direction most of the time.

In my opinion, the distinction of strong and weak AI has damaged the field and contributed to the confusion of what we want to call AI. The celebrated successes all fall into the domain of narrow AI (the weakened version of weak AI), while the scenarios of thinking robots that take over the world (for good or bad) are based on very optimistic (not to say unrealistic) expectations of general AI (the general version of weak AI).

  1. Stuart Russell, Peter Norvig. Artificial Intelligence — A Modern Approach., 1st th edition. Prentice-Hall. 1995. pp. 29
What is AI?
Part 1: The original definition
04.01.2019
A fundamental problem in the public discussion is the missing definition of Artificial Intelligence. In this blog series I provide possible destinctions of AI from non-AI. Whatever anybody believes AI to be, one should make the definition clear before starting any discussion on the impacts of AI.

I usually try to avoid any definition of Artificial Intelligence. There is no well-agreed definition of human intelligence, therefore it seems pretentious to find one for the artificial variant. I have changed my mind, however, since AI is discussed in so many different variants—often in the same text. The usual story goes ``We already have AI or are very close to having it, therefore AI development will accelerate and destroy/save humanity.'' The problem here is that the definitions of AI change from phrase to phrase, but since the same word is used, they are mingled into one.

Let's go back to the time when the term "Artificial Intelligence" was coined, to 1955. Computers were still a rarity, being a treasure of any university that could afford one. People might just have been happy to have a tool for doing fast computations. But the idea of thinking machines is much older than computers, and with the now available remarkable power of doing arithmetic, old dreams were rekindled. In 1955 John McCarthy organized a workshop titled "Dartmouth Summer Research Project on Artificial Intelligence" and thereby coined the term. The proposal [1] starts as follows

We propose that a 2-month, 10-man study of artificial intelligence be carried out during the summer of 1956 at Dartmouth College in Hanover, New Hampshire. The study is to proceed on the basis of the conjecture that every aspect of learning or any other feature of intelligence can in principle be so precisely described that a machine can be made to simulate it. An attempt will be made to find how to make machines use language, form abstractions and concepts, solve kinds of problems now reserved for humans, and improve themselves. We think that a significant advance can be made in one or more of these problems if a carefully selected group of scientists work on it together for a summer.
This paragraph shows the definitional problem of AI from its very beginnings: the generality of the methods. If a machine is expected to learn, did they mean that it can learn anything in any circumstance or would this learning refer to one specific problem (in this case learning could simply mean storing new values in a database)? Solving problems reserved for humans, do we have to find one method that solves them all or are we happy with a tailored solution for each problem?

Basic idea of AI: the ability to expand a simple specification of a task to a complicated program

The zigzaged area in this picture represents a tough problem that requires human intelligence. One interpretation of AI could be to write a computer program that solves the complicated task equally well as people do. This would be a typical engineering task, so why invent a new name for it? I think what McCarthy and his colleagues had in mind was the process shown in the middle. Instead of handcoding the complete task, we would like to specify some aspects of the task (we somehow have to tell the machine what we want from it), and this simple specification would expand by AI mechanisms into the more complicated program. There is still a lot of room for interpretation: how big or small is the central specification, how much is added by "intelligent" mechanisms, how much is so specific to the task that it has to be implemented manually?

The picture also illustrates two possible ways to develop AI: from inside out or outside in. Alan Newell and Herbert Simon followed the first approach. They started early with the Logic Theorist and later the General Problem Solver to develop general mechanisms that solve a wide range of problems (not necessarily any problem). Even at the Dartmouth workshop it became clear that the outside-in method would simplify funding [2]. Working on specific problems, one might gradually identify commonalities and thereby extract more general mechanisms. I think both approaches are important and should interact.

But do we know now what differentiates AI from non-AI? The AI arrows represent what any software library does: extending a simple specification of a frequently occurring problem class into a more complex solution.

I will not be able to give you any real definition of AI, but I will provide several perspectives from which you can create your own understanding (or perplexity) of what AI is.

  1. McCarthy, J., Minsky, M., Rochester, N., Shannon, C.E.. A Proposal for the Dartmouth Summer Research Project on Artificial Intelligence. 1955.
A journalist understanding AI
02.12.2018
Is the AI hype coming to an end? At least some journalists such as Esther Paniagua start to realize that AI is not radically changing the world.

Esther Paniagua recently published this wonderful article (in Spanish) where she gives a realistic image on the state of AI. She had taken the trouble to interview several AI experts, including myself, to really understand where we are and how slow progress still is. I am delighted to read such realistic accounts of AI as a counterbalance to the apocalyptic or utopian futures that are often predicted.

    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.