Fatalismus bei Marvin Minsky

Der AI-Vordenker Marvin Minsky kommt in seinem Vortrag auf,

zu der ernüchternen Erkenntnis, dass er seine Lebenszeit mehr oder weniger verschwendet habe und trotz aller Versuche es ihm und seinen Kollegen nicht gelungen sei, eine denkende Maschine zu bauen. Somit sind alle Änsätze die im Laufe der Jahre entstanden sind, mehr oder weniger falsch gewesen. Hat Minsky recht mit seiner deprimierenden Erkenntnis?

Wenn man Artificial Intelligence als Ziel definiert vielleicht. Denn was soll das sein? Niemand kann es definieren und niemand kann es erreichen. Aber wenn man etwas bescheidener von Narrow AI spricht und diese zu erreichen gedenkt, dann gibt es sehr wohl Möglichkeiten es zu tun. Das bedeutet konkret: wenn man in einem Computerspiel wie OpenRA eine Künstliche Intelligenz haben möchte, wird vermutlich Marvin Minsky und auch sonst keiner der Vordenker wissen wie man sowas implementiert. Es gibt zwar einige Ansätze wie Neuronale Netzen, Expertensysteme usw. von denen weiß man aber das sie sich in der Praxis nicht bewähren. Aber wenn man hingegen etwas bescheidener lediglich eine Software möchte, die in der Lage ist mit den Ore-Harvestern auszuschwärmen, die Basis autonom zu vergrößern, die Verteidigung sicherzustellen und am Ende das Spiel zu gewinnen, dann gibt es in der Tat sehr viele erfolgversprechende Ansätze sowas zu implementieren.

Und was für Ingame gilt, das gilt auch im real Live. Wenn man ganz allgemein einen intelligenten Roboter bauen will, dann dürfte es schwierig werden dieses Ziel zu erreichen. Wenn man sich aber mit einer vollautonomen Fabrik zufriedengibt wo drinnen Fahrzeuge herumfahren, wo Laufroboter die Maschinen warten und wo das ganze auch noch mit hoher Effizienz stattfindet, für solche Aufgaben gibt es einige Vorschläge es zu erreichen.

Von einem philosophischen Standpunkt aus betrachtet ist es verständlich wenn einige ehrenvolle Leute die schon alles gesehen haben als Quintessenz über die AI-Forschung sagen, dass sie vergeblich war. Weil man es so ja auch sehen kann. Im Grunde äußern diese Leute sich jedoch nicht objektiv über die AI-Forschung sondern lediglich über ihre eigene Rolle darin. Kurz gesagt, es ist anzunehmen dass Minsky einfach keinen Bock hat (anders kann man es nicht sagen) konkrete Probleme aus der Praxis zu lösen und auch nicht gefragt werden möchte, wie man beispielsweise Expertensysteme dafür einsetzt um eine Fabrik zu automatisieren. Und natürlich ist auch die Haltung verständlich angesichts von selbstfahrenden Autos, autonomer Ingame AI oder von Bin Picking Robotern auf dem Standpunkt zu verharren, dass nichts davon etwas mit Künstlicher Intelligenz zu tun habe, sondern lediglich unwichtige Optimierungsaufgaben aus der Praxis lösen würde. Aber genau darum geht es doch: Probleme zu lösen, die Automatisierung voranzutreiben, Roboter zu bauen, cognitive Maschinen zu entwickeln.

Es ist schlichtweg Selbsttäuschung wenn man sagt, dass die AI-Forschung der letzten 50 Jahren nichts relevantes entwickelt habe, und das schlichtweg alle Probleme die etwas mit Denken zu tun haben, nicht von Maschinen gelöst werden könnten. Das ist eine dreiste Lüge. Es ist vor allem eine moralische Haltung bei der die Kritik am Technikeinsatz von jenen Leuten formuliert wird, die eigentlich die Aufgabe haben, die Technik voranzutreiben.

Wahr ist hingegen folgendes: es gibt unterschiedliche AI-Wettbewerbe aus den Bereichen Robotik, Textverständnis oder Ingame AI. Und jeder dieser Wettbewerbe ist mit AI-Systeme prinzipiell lösbar. Der Standpunkt, dass die AI insgesamt nichts zu bieten habe, bedeutet im Grunde dem Wettbewerb auszuweichen. Es ist Feigheit vor dem Feind.

Es geht doch nicht darum, auf dem Gebiet der Künstlichen Intelligenz zu brillieren oder gar eine neue Theorie des Denkens zu erfinden. Sondern Künstliche Intelligenz ist nur Mittel zum Zweck. Eigentlich geht es um etwas anderes, eigentlich geht es darum einen besseren Roboter ins Rennen zu schicken als die 20 anderen Teams, die ebenfalls versuchen Fußball zu spielen. Ob dieser Roboter nun mit Künstlicher Intelligenz, mit schwarzer Magie oder mit einem stinknormalen C++ Programm angetrieben wird ist egal. Er muss lediglich Punkte holen für das eigene Team, nichts anderes.

Im Grunde spielt es keine Rolle, wenn die AI-Forschung nichts wichtiges erfunden hat. Das kann nur von Vorteil sein, weil dann die gegnerischen Teams ebenfalls keine AI einsetzen können. Dann herscht zumindest gleichstand und man kann sich überlegen mit welcher herkömlichen Programmiermethode man gewinnen möchte.

Interessanterweise kann man sogar eine Robot Challange veranstalten, wenn man gar keine Ahnung von Robotern hat. Man kämpft ja immer gegen andere Leute die ebenfalls keine Ahnung haben und kann deshalb prinzipiell gewinnen. Und das sieht man einigen Wettbewerben auch an, wo die Leute nicht nur keine Ahnung von Expertensystemen haben, sondern auch keine Ahnung von sonstiger Informatik. Aber ist das Grund freiwillig aufzugeben? Im Gegenteil, die Leute haben Spaß, vor allem wenn sie es schaffen am Ende den ersten Platz zu gewinnen. Wen stört es, wenn das ganze wissenschaftlich betrachtet wertlos ist?

Advertisements

Bug: Mario AI startet nicht

Das Mario AI Projekt mag als Youtube-Video vielleicht ganz spannend klingen, wenn man das ganze jedoch selbst einmal ausprobieren möchte ist es schon deutlich anstrengender. Zunächst einmal gibt es gleich zwei unterschiedliche Webseiten auf denen auch noch unter verschiedenen Bezeichnungen Wettbewerbe abgehalten werden. Weiterhin verweißt der Downloadlink auf ein Google Code Konto, wozu gesagt sei, dass Google Code inzwischen gar nicht mehr online ist. Aber das beste ist, in der Anleitung wird auf nicht weniger als 4 unterschiedliche Programmversionen verwiesen die teilweise nur Source-Code enthalten und nicht fertig kompilierte Java-Dateien. Irgendwo gibt es im Sourcecode zwar eine build.xml Datei, doch wie man damit aus dem Quelltext die fertige Java-Class-Files erzeugt ist mehr oder weniger nicht dokumentiert (es sei denn man kennt sich mit Eclipse/Ant aus). Wie auch immer, eine dieser Versionen kann gestartet werden, allerdings war das leider nicht das richtige Mario AI Spiel, sondern nur jene Version mit der man Levels erstellen kann nicht jedoch eigene AI Bots entwickeln.

Insgesamt drängt sich der Eindruck auf, dass Mario AI eines von diesen „messy“ Java Projekten ist wo ferne Verwandte der Collyer Brüder mal wieder zu Gange waren und irgendwas angesammelt haben, was bei näherer Betrachtung dringend mal entrümpelt werden müsste. Zusätzlich kommt noch die ungeklärte Rechtslage hinzu, die sich darin äußert, dass zwar am Ende von Level 1 ein wunderhübscher Kopf von Mario zu sehen ist, der aber mit Sicherheit keine offizielle Genehmigung von Nintendo Inc. besitzt und auch die Duddelmusik im Hintergrund klingt zwar angenehm, aber leider ein wenig zu gut, als das sie selber komponiert sein dürfte. Wie auch immer, bleiben bei Mario AI zu viele Fragen unbeantwortet.

Online Question Answering Systeme

Die schlechte Nachricht vorneweg: außer START vom MIT http://start.csail.mit.edu/index.php habe ich kein einziges Question Answering System gefunden, dessen Server online ist und wo man tatsächlich etwas eingeben kann. Alles was ich finden konnte sind ehemalige Projekte die inzwischen wieder offline sind, Sourcecode auf github für mögliche Chatbots die ontop von DBpedia laufen, sowie jede Menge Paper die RDF erläutern. Doch schön der Reihe nach: worum geht es eigentlich? Die Grundidee lautet, Informationen nicht als Volltext sondern als Datenbank zu speichern, genauer gesagt als RDF Triple wodurch man leichter Anfragen stellen kann. Wenn so ein System korrekt konfiguriert ist, funktioniert es so wie IBM Watson. Das heißt, man postet eine Frage wie „Wer ist Albert Einstein?“ und das System beantwortet diese Frage. Genauer gesagt wird die Frage zuerst in eine SPARQL Anfrage übersetzt, diese an die RDF Datenbank gesendet, und dann die Antwort zurückübersetzt in natürliche Sprache.

Warum es derzeit keine Online-Demos hat weniger technische Gründe (die Technologie funktioniert ausgezeichnet) sondern das Problem sind patentrechtliche Fragestellungen. Firmen wie Google, Microsoft, IBM könnten sehr wohl derartige Portale freischalten, nur wollen sie es nicht, weil diese Technologie ziemlich mächtig ist. Genauer gesagt, ist Question Answering mit Semantic Networks leistungsfähiger als die heutige Google Suchmaschine. Man kann damit vorhandene Datenbestände sehr viel effizienter auswerten als mit einer simplen Volltextsuche plus Pagerank Algorithmus womit derzeit die Massen abgespeist werden.

Aber das Nichtvorhandensein von Q&A Demoseiten kann man zugleich als Ansporn verstehen sich auf theoretischem Gebiet damit näher zu beschäftigen. Denn zumindest Paper wo das Konzept näher erläutert wird gibt es. Es ist nur so, dass sie keiner ließt, weil die Leute zuviel Zeit auf Abnehmblogs und mit Filme schauen vertrödeln.

Künstliche Intelligenz bedeutet große Softwareprojekte

In der populärwissenschaftlichen Aufbereitung von Künstlicher Intelligenz stehen häufig Algorithmen im Mittelpunkt. Damit sind magische Abläufe gemeint die eine tote Maschine in einen lebendigen Roboter verwandelt. Eine gängige Theorie lautet, dass sich mit Hilfe von neuronalen Netzen, selbstlernenden Algorithmen oder eine besonders geschickte Programmierung Künstliche Intelligenz realisieren ließe. Demzufolge ist Künstliche Intelligenz vergleichbar mit einer Erfindung wie dem Differentialgetriebe. Also eine fein ausgetüftelte Idee, die sich auf nicht mehr als 10 Seiten DIN A4 beschreiben lässt wodurch der Computer dann anfängt zu sprechen oder sogar Aufgaben erledigen kann.

Diese naive Vorstellung hat etwas mit der Entstehungsgeschichte des Computers zu tun. In der Anfangszeit waren Computer in Hardware realisierte Maschine. Also Transistoren, die einen logischen Schaltkreis bildeten. Und die Vorstellung lautet, dass man diesen Schaltkreis auf eine geschickte Weise anordnen müsse um darüber die gewünschte Funktionalität zu erzielen. Diese Sichtweise blendet das Thema Software aus. Es wird schlichtweg geleugnet, dass man Programme erstellen muss und wenn dann haben diese eine unbedeutende Funktion. Die Wahrheit ist jedoch dass Computer sich durch ihre Software definieren. Die Microchips sind technisch gesehen uninteressant. Nehmen wir beispielsweise den Rasberry PI Minicomputer. Von der Hardware her kann man das ganze als Abfall bzw. Ausschuss bezeichnen. Er verwendet Technologie die vor vielen Jahrzehnten erfunden wurde, die sich unglaublich preiswert herstellen lässt und die man bei Fehlern einfach wegwerfen kann. Der Rasberry PI ist nicht der eigentliche Computer, er ist nur die Hardware. Der eigentliche Computer ist die Software auf diesem Computer. Und mit ihr wird Künstliche Intelligenz realisiert.

Künstliche Intelligenz ist direkt proportional zu den Lines of Code. In dem Sinne, dass ein Roboter mit 100 Lines of Code, keinerlei Eigentintelligenz besitzt, einer mit 100M LoC hingegen eine sehr hohe Eigenintelligenz besitzt. Obwohl nicht genau geklärt ist ab wann ein Roboter sich menschenähnlich verhält kann man sagen, dass es oberhalb von 100M LoC passieren dürfte. Das heißt man braucht eine bestimmte Menge an Codezeilen damit die Sprachausgabe realistisch klingt, damit die Subroutinen sinnvolle Dinge tun. Um Künstliche Intelligenz zu realisieren muss man vor allem große umfangreiche Programme schreiben. Und damit ist auch der eigentliche Flaschenhals definiert. Hat man keine Leistungsfähige Hochsprache, hat man kein großes Softwareentwicklungsteam ist es unmöglich Roboter zu realisieren. Ein wundertechnologie mit der ein einzelner Programmierer in weniger als 1k LoC einen Roboter realisieren kann der denkt, fühlt und spricht gibt es nicht. Auf der anderen Seite erhält man auf wundersame Weise wenn die Software umfangreicher wird automatisch die gewünschte Funktionalität. In dem Sinne, dass man immer weitere Features in das System hineinprogrammiert und es dabei immer menschenähnlicher wird.

Programmieren eines Computers bedeutet immer Domain-Modelling. Damit ist gemeint, dass man die Anwendung in Software nachbaut. Man kann sich das vorstellen wie bei einem Computerspiel. Je mehr Megabyte das Spiel auf der Festplatte benötigt, desto besser ist die Grafik, desto besser ist die Soundausgabe. Ein gutes Beispiel dafür ist das Computerspiel Simcity. Die Version 1 welche im Jahr 1989 war vom Codeumfang und von den Features noch sehr minimalistisch. Die Stadtsimulation war abstrakt, sie war nur in 2D und es gab keine Missionen. Spätere Versionen von Simcity enthielten mehr Sourcecode und das Spiel war um einiges realistischer. Die letzte Iterationsstufe des Spiels enthält neben der Stadtsimulation auch noch eine Trafficsimulation und animierte Figuren die herumlaufen. Das simple Prinzip dass die Qualität automatisch ansteigt durch mehr Lines of Code ist ein Universalgesetz in der Programmierung. Das Limit was eine Software zu leisten vermag wird durch die Ressourcen an menschlichen Programmierern definiert. Je mehr Programmierer eine Firma für ein Projekt abstellen kann desto leistungsfähiger die Software.

Manchmal wird von sogenannten gescheiterten Softwareprojekten gesprochen. Das Scheitern lässt sich auf eine simple Formel reduzieren: benötigte Lines of Code vs. ausgelieferte Lines of Code. Dazu ein Beispiel: angenommen eine Firma benötigt Java Software um ihre Geschäftsabläufe zu optimieren. Der geschätzte Umfang für ein ERP System (Enterprise Ressource Planning) beträgt 1 Mio Lines of Code. Wenn man jetzt ein Softwareprojekt durchführt was mangels Ressourcen jedoch nur 0,1M LoC liefert wird die fertige Software als dysfunktional wahrgenommen. Damit ist gemeint, dass sie nicht die Anforderungen erfüllt.

Anders als manchmal zu lesen geht es also nicht um best-practices in der Softwareerstellung, um die richtige Programmiersprache oder um agile Softwareentwicklung, sondern man kann das Gelingen von Softwareentwicklung auf die Kennzahl Lines of Code reduzieren. Und wenn man nicht die benötigten Ressourcen bereitstellt um diese Zahl zu erreichen scheitert das Projekt automatisch. Es ist nicht möglich ein ERP System in 100 Zeilen Code zu realisieren.

Der Clou ist, dass es zu jedem Softwareprojekt ein Drumherum gibt. Also eine Infrastruktur in der sich die Entwickler aufhalten. Traditionell finden Softwareprojekte in Firmen und Universitäten statt. In neuerer Zeit auch als OpenSource. In jedem Fall gibt es menschliche Programmimerer die daran mitwirken. Der Zusammenhang ist dabei simpel: Ein Programmierer kann pro Tag rund 10 Codezeilen schreiben, egal ob in Python, Java oder C#. Will man ein kleines Softwareprojekt realisieren reicht ein Ein-Mann-Projekt aus, will man Großprojekte wie Betriebssysteme oder gar Robotik-Software entwickeln braucht man mehr als 1000 Entwickler. Anders ausgedrückt, wenn man vorhat mit einer kleinen 10 Mann Firma ein autonomes Auto zu entwickeln wie das George Hotz angekündigt hat, lautet mein Ratschlag: vergiss es. Wie eingangs schon erwähnt gibt es keine magische Algorithmen oder Patente die man geschickt implementieren muss und das Auto fährt, sondern ein selbstfahrendes Auto besteht aus rund 10M LoC und ein 10 Mann Unternehmen kann diese Codemenge nicht schreiben. Für ein driverless Car benötigt man eher ein Unternehmen wie Google, Microsoft oder Apple was 10000 Entwickler an das Projekt dransetzen kann. Nominell ist es in solchen Strukturen möglich, die 10M LoC Marke zu überspringen.

Das mzScheme Betriebssystem

Beim durchstöbern alter Texte zur Computergeschichte bin ich über ein Betriebssystem gestoßen was relativ interessant ist. Es handelt sich um mzScheme, zu dem im Jahr 1997 ein Handbuch veröffentlicht wurde. Laut Selbstdefinition ist mzScheme kein Betriebssystem sondern eine Programmiersprache, man kann es als Nachfolger von LISP-artigen Betriebssystemen beschreiben. Aus heutiger Sicht ist die Kombination aus Programmiersprache und Betriebssystem etwas höchst sonderbares, in den 1980’er war das Konzept jedoch weit verbreitet. Genauer gesagt waren die Programmiersprachen der 5. Computergeneration (LIsp und Smalltalk) nicht einfach nur Programmiersprachen um Software zu entwickeln, sondern sie beinahlteten auch einen Kernel und Treiber zur Grafikausgabe. Man hatte also das Rundumsorglos Paket.

Aus heutiger sicht ist es deshalb ungewöhnlich weil eigenltich beides getrennt ist. In einem Betriebssystem wie Linux kann man mehrere Programmiersprachen gleichzeitig benutzen. Lisp natürlich auch, aber nicht nur. Bei mzScheme und den Lisp-Maschinen war das anders. Das hatte nicht so sehr technische Gründe sondern war Ausdruck eines Verständnis von Software. Dieses hat sich im Laufe der Zeit gewandelt. Man dachte damals, dass Betriebssystem ein Thema wären, was die Informatik gelöst habe und ontop habe man dann die eigentliche Innovation erfunden: Computersprachen der 5. Generation. Also Programmiersystem die mit einer natural language Schnittstelle ausgestattet sind und dessen Unterbau direkt mit der Hardware kommunziert. Ungefähr in diesem Denkmodell ist mzScheme einzuordnen.

Das interessante ist, dass es dazu eine Alternative gibt. Einmal wurde sie von der Firma Microsoft in den 1990’er auf ökonomische Weise definiert, dass nähmlich ein Betriebssystem eigenständige Software ist, die seperat verkauft wird, und für die andere Firmen wie Borland Sprachcompiler in Pascal und C liefern. Aber auch die OpenSource Bewegung hat den Begriff Betriebssystem besetzt. Danach handelt es sich um Sourcecode der der Allgemeinheit gehört und der nach dem Einschalten des Rechners geladen wird. Beide Definition weichen stark ab von dem was im mzScheme Umfeld als Betriebssystem definiert wurde.

Der tiefergehende Aspekt betrifft die Art der Programmerstellung also wie genau ein Betriebssystem entwickelt wird. Nach der Vorstellung von Lisp führt Metaprogramming und künstliche Inteligenz zu Leistungsfähiger Software. Das also in mathematischer Logik ein Problem definiert wird und dann ein Codegenerator daraus Maschinencode erzeugt. In der Vorstellungswelt von Microsoft ist Softwareerstellung ein Business, was ähnlich funktioniert wie der Bau eines Hauses, wo man also einen Geschäftsführer, eine Aktiengesellschaft und einen Kunden benötigt. Während aus Sicht von Linux Softwareerstellung eine Ausdrucksform von Computernerds ist, die sich über Mailinglisten und Versionscontrol-S<steme abstimmen.

Durchgesetzt als Wahrheit haben sich eigentlich nur die Definitionen von Microsoft und von Linux. Das heißt, Betriebssysteme sind menschengemacht und werden durch Programmierer erstellt die zusammenarbeiten. Nicht durchgesetzt hat sich hingegen die Vorstellung, dass es autonome Betriebssysteme gäbe, die quasi aus dem Nichts entstehen und Ausdruck des Lamdba Kalküls sind. Das Scheitern von mzScheme ist darauf zurückzuführen, dass die darin vertretene Ideologie über das Entstehen von Software falsch war.

LELISP
https://hal.archives-ouvertes.fr/file/index/docid/76238/filename/RR-0319.pdf ist ein Dokument aus dem Jahr 1984 was ein System namens "Lelisp" beschreibt. Die Autoren bezeichnen es als LISP System. Auffällig ist, dass praktisch alles eine Einheit bildet. Ausgangspunkt war wohl ein VLSI Projekt am INRIA Institut (Frankreich) was zum Ziel hatte, eine leistungsfähige CPU zu entwickeln, auf diese wurde dann Lelisp portiert. Das umfasste sehr viele Dinge die man heutzutage als Betriebssystemdistribution bezeichnen würde, also einmal die Programmiersprache selber inkl. Parser, ein Fensterbetriebssystem, einen Texteditor, Bibliotheken. In einem Abschnitt wird sogar erläutert, dass selbst das Microcoding des Kernels ausgeführt wurde, also Teile des Lisp-Kernels auf die CPU hin optimiert wurden. Warum alles inhouse entwickelt wurde ist simpel: es herschte damals Mangelwirtschaft. Es gab zu dieser Zeit keine kommerzielle Softwareindustrie wo man hätte die Software bestellen können, ja es gab noch nichtmal ein Internet wo man sich das neueste Linux hätte herunterziehen können. Wollte man einen Computer haben, muss man ihn selber in eine Leiterplatte ätzen und wollte man ein Betriebssystem haben, so musste man eines programmieren. Ein wenig erinnert das an die Firma Apple welche sich bis heute diesen Luxus erlaubt alles selbst zu entwickeln. Zumindest behauptet sie es, in Wahrheit kommt die CPU von ARM, die Fertigung wird außerhalb der USA ausgeführt und die Software basiert auf vorhandenem Code der modifiziert wurde.

Warum ist die 5. Computergeneration gescheitert?

Eigentlich hat es in den 1980’er so gut angefangen, man hatte LISP, VLSI-Chipfertigung und man hatte eine Idee. Sie lautete, dass man einen stackbasierenden Prozessor zu einem Transputer hochrüstet, darauf ein Lisp-Betriebssystem per Bootstrapping installiert und auf der Maschine dann Künstliche Intelligenz betreibt. Ein sehr schöner Plan nur wurde daraus nichts. Rein formal gab es sie, die Lisp-Maschinen der 5. Computergeneration mit leistungsfähiger Software wo 3D Animation und Vernetzung möglich war. Und sie verwendeten tatsächlich Transputer welche der Stackarchitektur von heutigen GA144 Chips zum verwechseln ähnlich sahen. Das entscheidene war nicht so sehr die 5. Computergeneration sondern das was danach kam. Wenn man bereits die besten Computer der Welt besitzt auf der die schnellste und schönste Software läuft, kann man von dort aus nur noch verlieren. Wer auf dem Berg ganz oben steht hat nichts mehr was er bezwingen kann, also heißt es den Abstieg wagen. Und genau das ist die eigentliche Herausforderung. Wie entwickelt man Computer die weniger leistungsfähig sind als die Generation davor? Wie programmiert man Software die nicht mehr sondern weniger leistet?

Was danach kam steht in den Geschichtsbüchern drin. Es ist die Zeit ab dem Jahr 1990, wo nicht Lisp-Maschinen sondern Wintel-Systeme ihren Siegeszug antraten. Sie wurden betrieben mit der x86 Architektur und verwendeten Microsoft Windows als Betriebssystem. Später wurde noch das Telefonkupferkabel mit einer Uralt-Technologie namens DSL in Hochgeschwindigkeitsbandbreite umgewandelt worüber die Erfinder Lisp Maschinen nur müde gelächelt haben. Der Unterschied ist, dass sich die Lisp Maschinen nicht durchsetzen konnten, aber die Windows98 PCs hingegen schon. Das ist merkwürdig wenn man unterstellt, dass es nur ein höher schneller weiter gibt. Aber offenbar kann man Technologie auch in unterschiedliche Richtungen entwickeln, hin zu kaputten dysfunktionalen Systemen. Unnötig zu erwähnen, dass als nächste Iterationsstufe dann Issue tracking bei der Softwareentwicklung berühmt wurde. Gab es in den 1980’er Jahren keinerlei Probleme bei der Softwareentwicklung und konnte man komplette Betriebssysteme in weniger als 1000 Zeilen Forth Code schreiben, hat man heute Bugtracker mit genervten Usern und überforderte Developern die sich durch Millionen Zeilen von Java Code wühlen. Die Software ist nicht leistungsfähiger geworden, sondern sie ist heute kaputter denn je.

In den 1980’er gab es noch Schönheit in der Informatik, also Maschinen die rein waren. Es waren elegante saubere Systeme auf denen funktionsfähige KI-Software lief, schön in sterilen Reinräumen in denen gesunde Menschen arbeiteten. Heute ist alles anders. Heute sitzen überfettete Nerds vor gammligen Gamer-PCs und müssen sich durch schlampig programmierte Software kämpfen, die teilweise von Viren heimgesucht wird. Zwischendurch macht der Router Probleme und die Programmierprojekte scheitern reihenweise. Was ist seit den 1980’er schiefgelaufen, sind die Menschen etwa dümmer und fauler geworden? Was ist aus den Idealen geworden nach denen früher einmal Hard- und Software entwickelt wurde, wo sind sie geblieben die schönen Metageneratoren, welche sauberen Code aus Spezifikationen generieren anstatt so wie in der verkommenen Gegenwart wo git und ähnlicher Unsinn Einzu gehalten hat und die Teams vergiftet?

Die Blütezeit der Informatik waren die 1980’er Jahre. Dort war die Technologie auf ihrem Scheitelpunkt angelangt, sie hatte sich diesen Sieg mühsam erkämpfen müssen. Aber man war stolz darauf. Die 1980’er waren gekennzeichnet durch eine gesellschaftliche Stabilität, wo also Programmierer in gut bezahlten Berufen arbeiteten und dort leistungsfähige Systeme entwickelten. Es gab damals Roboter, Computeranimation, Internet, Virtual Reality, eigentlich alles was man mit Computern machen kann. Leider sind die 1980’er Jahre vorbei. Sie kommen nie wieder zurück. Die Art wie damals Informatik betrieben wurde ist heute nicht mehr angesagt. Ich glaube es ist an der Zeit, die 1980’er dezidiert zu untersuchen. Es war nicht irgendeine Epoche in der Computergeschichte sondern es war die letzte Epoche.

In den 1980’er gab es HDTV Fernsehen auf superscharfen Monitoren. Und was gibt es heute? Verwackelte youtube Aufnahmen in 240p, die zwischendurch noch Verbindungsprobleme verursachen. Die Technologie hat sich seit damals beträchtlich zurückentwickelt. Ursache dafür ist, dass heute Leute an der Software herumprogrammieren die davon keine Ahnung haben. Linus Torvalds wurde schon genannt, aber auch die Firma ARM und Google zählen dazu. Alles keine reinen Technikprojekte mehr sondern die Unternehmen verstehen sich als Bildungseinrichtungen die ihren Angestellten Wissen vermitteln. Heute wird typischerweise Software nicht mehr von Programmierern sondern von Literaturwissenschaftlern oder sogar Musikern programmiert. Das kann nur schiefgehen.

Head up Displays vs Behavior Trees

Behavior Trees gelten als gute Möglichkeit, domänenspezifisches Wissen als Computerprogramm zu speichern. Sie verwenden Variablennamen und Methodenaufrufe um mögliche Aktionen der Künstlichen Intelligenz zu strukturieren. Üblicherweise kommen Behavior Trees in Computerspielen zum Einsatz wenn Non-Player-CHaraktere gescriptet werden. Neben Behavior Trees gibt es noch eine weitere Methode, wie man Domänenwissen speichern kann. Diese hat den Vorteil, auch mit ungenaumen Wissen umgehen zu können. Gemeint sind Head-up Displays. Head up Displays werden ähnlich wie normale Computerprogramme auch programmiert. Das heißt, im Stile der objektorientierten Programmierung erstellt. Ihr Vorteil ist, dass sie einerseits machinenlesbar sind, aber gleichzeitig nicht die undankbare Aufgabe besitzen eine künstliche Intelligenz steuern zu müssen. Sondern Head up Displays sind unverbindliche Zusatzinformationen, die für den Spieler eingeblendet werden. Er kann sich daran orientieren muss es aber nicht.

Behavior Trees sind 1:1 mit einer Künstlichen Intelligenz verbunden. Wenn als Methode enthalten ist „walkto“ dann wird diese Methode nach dem Start des Bots tatsächlich so ausgeführt. Wurde sie falsch programmiert, stürzt der Roboter ins Chaos. Im Gegensatz dazu werden Head-up Displays nicht ausgeführt, jedenfalls nicht direkt. Sie werden zwar auch innerhalb der Game-loop abgearbeitet aber im worst-Case sind die dargestellten Informationen verpixelt, es sind nur Bildpunkte mehr nicht. Head-up Displays erfordern eine weitere Instanz will man sie zur Steuerung von Robotern einsetzen. Und zwar eines Head-up Display Parsers, also ein Computerprogramm was die dargestellten Informationen abgreift und zu sinnvollen Entscheidungen weiterverarbeitet. Dieser Head-up Display Parser ist sehr viel kompakter aufgebaut als ein klassischer Behavior Tree, er enthält nicht das komplette Domänen-Wissen sondern ist nur ein Zusatzlayer der dafür sorgt, dass der Bot auch mit unklaren Informationen noch klarkommt.

Bei der Wissensmodellierung wird Expertenwissen machinenlesbar aufbereitet. Behavior Trees sind dazu in der Lage. Das Prozesswissen wird in Task untergliedert, die sich gegenseitig aufrufen können. Es handelt sich um eine verbesserte Finite State Machine, die ebenfalls Wissen darstellen kann. Bei Head-up Displays ist das Abstraktionsniveau höher. Damit ist gemeint, dass ein Head-UP Display ebenfalls Wissen enthält, das aber nicht direkt mit den Aktoren verbunden ist. Die Funktionsweise ist üblicherweise so, dass das Head-up Display Informationen anzeigt, die werden von einem Man-in-the-loop interpretiert und der Man-in-the-loop bewegt dann den Joystick. Das Head-up Display kann also nicht direkt den Joystick bewegen.

Das interessante an Head-up Displays ist, dass sie anders funktionieren als man es erwarten dürfte. Sie verwenden keineswegs Programmiersprachen wie Prolog und auch keine OWL Ontologien um Wissen in deklarativer Form darzustellen, sondern wie der Name schon sagt sind Head-up Display ein Grafikfenster von 300×200 Pixel auf denen unstrukturierte Informationen angezeigt werden. Also Piktogramme, Zahlen, Texte und Karten. Sie sind damit das genaue Gegenteil einer formalen OWL-Ontologie. Dieser Unterschied kommt dadurch zustande, dass bei der OWL-basierenden Wissensmodellierung von einem autonomen System ausgegangen wird, während Head-up Display einen Human-Operator in the-loop benötigen. Wenn kein Mensch vor dem Bedienpult sitzt, der die lustigen Grafiken auswertet, bewegt sich der Roboter keinen Millimeter. Head-up Displays sind keine autonomen Systeme sondern sie sind hochgradig abhängig von menschlicher Intelligenz.

Es geht darum, einerseits den menschlichen Operator in der Loop zu belassen gleichzeitig jedoch die Domäne durch ein Computerprogramm abzubilden. Also sowohl Künstliche Intelligenz als auch menschliche Intelligenz zu verwenden. An dieser Stelle sei an den wegweisenden Vortrag „Edwin Olson: Winning the MAGIC 2010 Autonomous Robotics Competition“ erinnert, https://www.youtube.com/watch?v=OuOQ–CyBwc