Das Grounding Problem in der Geschichte der KI

 In der Geschichte der Künstlichen Intelligenz gab es zwei wesentlichen Ansätze zur Wissensmodellierung: einmal die symbolische KI die in der Frame Theory ihren Höhepunkt fand und bei der Wissen als Objekte abgelegt werden die untereinander kommunizieren und zweitens die Programmiersprachen angefangen von C/C++ als Systemprogrammiersprachen bis hin zu modernen KI Sprachen wie LISP und Prolog welche beide das Speichern von Wissen unterstützen.

Leider gibt es mit diesen Ansätzen ein Problem: es skaliert nicht. Will man ein konkretes Problem lösen z.b. eine Robotersteuerung entwickeln wird man mit Frames, Lisp, Prolog oder semantischen Netzen keinen Erfolg haben. Woran es mangelt ist die praktische Relevanz. Selbst für Triviale Probleme wie towers of honoi ist es extrem schwer eine Implementierung in Prolog oder als Frames zu realisieren. Man kann also unterstellen, dass die Künstliche Intelligenz in einer Sackgasse ist.

Diese Sackgasse wird deutlich sobald man versucht einem Computer das denken einzuprogrammieren. Mag das Schreiben eines normalen Computerprograms in C/C++ noch halbwegs lösbar sein, ist das Einprogrammieren von Faktenwissen in eine Maschine eine unlösbare Aufgabe. Wichtig ist zu wissen dass selbst weiterentwickelte Konzepte wie agentenbasierte Programmiersprachen oder Web 2.0 Semantiken welche die Frame Theorie weiterentwickelt haben nicht zu erfolg führen.

Es ist gut nachvollziehbar warum Anfang der 1990er Jahre die Künstliche Intelligenz Forschung wiedereinmal für gescheitert erklärt wurde. Die ursache liegt darin wie in der Nicht KI Informatik Software entwickelt wird nähmlich um sie auf einer CPU auszuführen. Die Vorstellung der Programmierer lautet, dass ein Spiel oder eine Datenbank auf einer konkreten CPU ausführbar ist, entweder als direkte Assembler routine oder als imperative Programmiersprache die mittels Compiler in Assembler code konvertiert wird. Vorhandene Bibliotheken die grafikroutinen oder Hardwaretreiber enthalten sind ebenfalls mit dieser Zielstellung entwickelt worden. Man kann sagen, dass Softwareentwicklung immer prozessororientiert funktioniert.

Dieses Konzept ist ungeeignet für die Erstellung von KI Applikationen, das war jedoch den Forschern Anfang der 1990er Jahre nicht bekannt. Sie unterstellten, dass KI Anwendungen ebenfalls prozessororientiert erstellt werden könnten. So wurden mit viel Aufwand KI Programmiersprachen und sogar KI Softwarebibliotheken erstellt in der wagen HOffnung das man dieses Konzept hochskalieren könnte zu leistungsfähigeren Anwendungen.

Das Gegenmodel zu einer computational approach ist ein Kommunikationsparadigma das erstaunlicherweise sogar in der klassischen Informatik diskutiert wird. Überall dort wo Computernetzte gebildet werden liegt der Fokus auf dem Datenbus und nicht auf der Einzel-CPU. Diese Kommunikationsorientierte Perspektive kann auf die Künstliche Intelligenz und Robotik übertragen werden und hilft dabei intelligente Maschinen zu entwickeln. Anstatt zu diskutieren welcher Algorithmus und welche Programmiersprache benötigt wird, lautet die neue Fragestellung welches Protokoll sinnvoll ist und wie Daten übertragen und geparst werden müssen.

Betrachten wir beide Konzepte im direkten Verrgleich um die Unterschiede zu verdeutlichen. Die klassische CPU orientierte Sichtweise fokussiert auf einen Einzelcomputer und versucht für die dort vorhandene CPU Software zu erstellen. Die Idee ist dass die CPU die Software ausführt und daraufhin eine 2d Grafik auf den Bildschirm zeichnet oder eine Datenbank durchsucht. Umgekehrt liegt bei einer Kommunikationsorientierte Sichtweise der Fokus auf dem Bus, also dem Kabel zwischen zwei Computern. Dieses Kabel ist entweder als phyissches Koaxial Kabel, als Lichtwellenleiter oder sogar als Airgap bei Wifi realisiert und enthält weder eine CPU noch eine Datenspeicher, sondern ein Kabel ist ein Medium über das Daten überrragen werden. Man kann für einen Bus auch keine Software schreiben im traditionellen  Sinne sondern man kann lediglich Protokolle erfinden die zur Kommunikation verwendet werden.

Sämtliche Entwicklungen der Künstlichen Intelligenz ab dem Jahr 2020 wie Question/answering Pairs, motion capture annotation, Speaker Hearer interaction, Vision language modelle können als Kommunikation zwischen zwei Systemen verstanden werden. Immer wird von einerm Sender an einen Receiver ein Datenpaket übertragen. im Fall einer Question answer challenge ist das Datenpaket eine Frage auf die der receiver mit einem Datenpaket antwortet während bei einem Instruction following task der sender einen Befehl sendet welcher vom receiver ausgeführt wird. Es gibt also nicht eine CPU die ein Program ausführt, sondern es gibt immer zwei instanzen zwischen denen Daten übertragen werden.

Damit verlagert sich der Fokus weg von der internen Funktionsweise eines Computers hin zu offenen Systemen die mit ihrer Umwelt interagieren. Wie diese Systeme intern arbeiten ist zweirangig.

AI as the art of finding problems

 In classical computer engineering there are many obvious problems available for example how to compress a videogame into 64kb of RAM, how to design a CPU which is 50% faster, how to render a 3d animation on the screen. These problems are creating a creativity space in which possible answers are discussed, revised or rejected. A typical programmer never interprets a challenge as a dead end but as an opportunity to find an answer.

For Artificial Intelligence there is no such a problem available. This makes it hard to discuss what AI is about. The philosophical problem space of "AI is to build an intelligent machine" isn't a problem space in a technical space because no existing tools or algorithm can be applied to this challenge.

If classical computer engineering is about problem solving, AI is maybe the art of searching for problems. A good AI problem can be solved and is related to thinking machinery. Typical examples for these problems are computer chess, micromouse challenge and a chatbot competition in which the answers of a chatbot are scored. These problems can be solved with existing tools like hardware, software, libraries and AI algorithms.

A new and very powerful problem space is a dataset which is discussed in the literature frequently after the year 2000. A dataset is a universal problem because there are datasets for image recognition, trajectory planning, OCR, question answering, motion capture and so on. MOst real world problems can be presented as a dataset. The dataset is not the answer to a problem and it doesn't controls a robot, but a dataste formulates an AI problem in a machine readable format. A single dataset can be solved with different tools e.g. a certain neural network, a handcoded software, or with a pattern matching algorithm.

What can be observed in the literature is, that the amount of datasets has exploded since the year 2000 and the difficulty has increased. From today's perspective a dataset is a universal problem generator which is used to measure every new generation of large language models.

Let me give an example how a dataset works. Suppose there is a table with 10 motion capture poses including the textual annotation. The task for a computer is replicate the shown picture to text pairs. That means, the computer sees a picture and has to print the correct annotation on the screen. In this specific case, Artificial Intelligence is defined as the ability to find matching pairs in the dataset. In other words, the definition of AI can't be discovered in nature but it has to be constructed similar to a painting. The art of dataset creation means basically to discover new sort of problems not available before.

Vision to language dataset for a warehouse robot

 

another example:

 

Short history of ingame AI

 Apart from automation tasks in a factory, there are major attempts available since the 1980s to build intelligent ingame characters targetted towards videogames. This subject seems to be easier to solve because in a videogame all the information are known.

Typical ingame AI in the 1980s was realized with Finite state machines. Especially the pacman game is using this single technique to control the ghosts. Another famous approach is depth first search used in board games likes chess and Nine men's morris.

Both concepts have major disadvantages. A finite state machine is difficult to program and a game state traversal in chess needs a lots of CPU ressources. Until around the year 2000 there were no improvements available. Even if finite state machine have evolved into behavior trees it was also hard to implement.

The main challenge in programming an ingame AI can be summarized as the reality gap between the videogame and the internal representation of the AI agent. A Finite state machine has a certain perspective towards the game encoded in state. For example a pacman ghost has states like attack, evade, idle, random and these states are applied to the current situation. In most cases the reality of a game is more complex than the game AI representation which causes an asynchronous situation. In other word, the game AI isn't communicating enought with the videogame and this explains its poor decision making.

To overcome the bottleneck of ingame AI created until the year 2000 the focus should be on the communication between a videogame and an ingame AI. For reason of simplication there is a virtual referee who is talking to the ingame AI in natural language. This virtual referee is the source of intelligence. He will guid the AI agent. In case of Pacman the referee might say to a ghost "move to upper left", in case of chess the referee might say "protect the center".

Such kind of textual interaction solves the former reality gap. The game AI gets a constant flow of commands from the referee and the only obstacle is to understand and execute them.

Lets compare old school ingame AI with modern communication based AI. The typical AI for a videogame before the year 2010 was realized as a software project. The idea was to encode the knowledge in the source code and make the AI smart by itself. The goal was that the AI acts independent from its environment and has all the needed knowledge and all the needed algorithm as internal software modules for pathfinding, decision making, perception and case based reasoning. Of course it was very complicated to program such an AI but there was no alternative available.

In contrast, modern AI created after the year 2010 is working with the extend mind thesis. The source of knowledge and intelligence is located ooutside of the game bot, either in the game engine, in a virtual referee or in a human operator. There is no need to encode knowledge into the AI itself but the AI is realized as parser for external commands, similar to a receiver in a RC Car teleoperation. The receiver listens to the signals and converts into action. this principle results into a minimalistic software which is much easier to realize and is more flexible at the same time.

The surprising situation is, that technically such a concept was realized in the 1980 already but it was recognized as a here to stay technology. In case of text adventure likes Zork and early role playing games, the human user was entering text commands which were executed by the game engine. So there was no AI available as a compuational engine, but there was only a parser available which executed a two word command.

Such a parser has no reality gap because it has no internal representation. The external human operator is responsible that the avatar is reaching its goal. The parser is only a command receiver.

Vision and language dataset generator

The screenshot consists of a random scene generator plus a textual annotation for a food collecting robot. The algorithm generates a maze including food items, and the text widget shows the description of the scene.

Such a setup is useful to generate a synthetic dataset with picture/text pairs to train a neural network.

Sprachverstehen durch Computer

Zuverlässige Spracherkennung funktioniert nur in Science fiction Serien aber nicht in der Realität. Über Jahrzehnte war es ein ungelöstes Problem der Informatik ein natürlich-sprachliches Interface zu programmieren. Mit ein Grund dürfte darin liegen, dass aus Linguistischer Perspektive unklar war, was genau natürliche Sprache eigentlich ist.

Man kann Sätze als String-array in Computern speichern und sogar Subjekt / Verb und Objekt erkennen, nur folgt daraus nichts für einen Computer. Ein Computer versteht nur eine Sprache und das ist Assemblersprache oder notfalls eine Programmiersprache wie C/C++. Natürliche Sprache funktioniert nach komplett anderen Regeln. Um den Gap zu schließen gitl es das Problem Spracherkennung zunächst einmal mathematisch zu beschreiben in Form eines Datasets. In der ersten Spalte werden natürlich sprachliche Kommandos abgelegt wie "fahre zum Regal B" während in der zweiten Spalte eine Sequenz von Bildern hinterlegt ist die Zeigen was der Roboter tun soll.

Dieser Dataset definiert was das Problem ist und zwar soll der Computer so agieren wie in dem Dataset dargestellt. Erst in einem zweiten Schritt überlegt man sich dafür passende Alogirthmen oder entwirft neuronale Netze welche die Fehlerzahl möglichst minimieren. Sprachverstehen ist nach dieser Definition also die Fähigkeiten einen vorhandenen Dataset zu imitieren. Zuerst entwirft man einen Sprachtest und dann ermittelt man die punktzahl eines Computerprograms um diesen Test zu bestehen. Das ist das Grundprinzip beim Deep Learning wie es seit den 2010er Jahren erfolgreich in der Informatik erforscht wird.

Geschlossene Systeme und das Scheitern Künstlicher Intelligenz

 In Ergänzung zu früheren Blogposts über geschlossene Systeme soll ausführlicher erläutert werden wo das Problem mit solchen Systeme besteht.

Zunächst einmal ist ein geschlossenes System etwas gutes in der Technikgeschichte weil es dabei hilft Komplexität zu senken. Ein Dieselmotor basiert auf physikalischen Prinzipien realisiert in der Anordnung der Bauteile. Alles was nichts mit der Umwandlung von fossiler Kraftstoffe in Drehbewegung zu tun hatt gehört defnitionsgemäß nicht zu einem Dieselmotor und liegt außerhalb. Es kann ignoriert werden. Dadurch kann man räumlich wie sachlich eingrenzen worum es bei einer Kraftmschine geht. Man kann Bücher darüber verfassen, man kann das Prinzip verstehen und nachbauen.

Auch Softwareentwicklung funktioinert als geschlossenes System. Ein Tetric Computerspiel realisiert in der C/C++ Sprache besteht aus dem sourcecode der ca. 500 lines of code umfasst. Alles was nicht in diesem Sourcecode definiert wurde, gehört nicht zum Projekt, liegt außerhalb und kann ignoriert werden. Folglich besteht Programmieren darin, den vorhandenen Sourcecode zu verbessern. Es gibt auch hier ein sachliches Thema auf das man fokussieren kann und was in ein erfolgreiches Projekt mündet.

Geschlossene Systeme zeichnen sich dadurch aus, dass eine scharfe Systemgrenze gezogen wird, etwas ist Bestandteil des Systems oder eben nicht. Auch sehr große umfangreiche Softwareprojekte wie ein Betriebssystem können als geschlsosene Systeme betrachtet werden. Sie bestehen aus mehreren tausend Dateien mit dem Sourcecode, und alles was darin nicht definiert wurde gehört nicht zum Betriebssystem. Diese banale Feststellung ist so allgegenwertig dass man in der Realität verinfacht nur von Systeme spricht und annimmt, dass alle Systema auf diese Weise erstellt und verbessert werden.

Genau dieser Trugschluss führte bis 2010 dazu, dass Künstliche Intelligenz nach einem ähnlichen Prinzip imaginiert wurde. Die Annahme war, dass ein Roboter oder eine KI Software als geschlsosenes System funktioniert, wo also in Software bestimmte Module und Algorithmen enthalten sind. Z.B. könnte ein Roboter eine pfadplanungs routine enthalten.

Ein solches KI System wird dadurch verbessert dass man weiteren Sourcecode anfügt und vorhandene algorithmen verbessert. Die meisten Robotikprojekte bis 2010 wurden nach dieser Prämisse entwickelt. Speziell der umfangreiche Sourcecode von selbstfahrenden Autos vor dem Jahr 2010 wurde ähnlich wie ein Softwaregroßprojekt programmiert: es gab Bugtracker, es gab versionsverwaltungssysteme und es gab eine Codebasis die in eine ausführbare Exe datei kompiliert wurde.

Leider gibt es mit geschlossenen KI systemen ein Problem. Je mehr ein solcher Roboter leisten soll, desto mehr Sourcecode wird benötigt. Und damit steigt die Fehleranzahl an. Bereits sehr kleine ingame AI projekte bei denen nur eine Spielfigur von einem NPC gesteuert wird, benötigen sehr viele Codezeilen. Will man selbstfahrende Autos programmieren steigt der bedarf an Lines of Code weiter. Vorhandene Werkzeuge um große Informatik Projekte zu organisieren, wie wikis oder bugtracker mögen für die klassische Softwareentwicklung gute Dienste leisten, bei dezidierten Robotik-Projekten versagen sie jedoch. Das problem ist eben nicht wie man die Software programmiert, sondern das Problem ist dass unklar ist welche Art von Software benötigt wird.

Der Ausweg aus dem Dilemma besteht darin die Annahme von geschlossenen Systemen in frage zu zustellen. Ein solches System bedeutet aus Software-Perspektive dass der Sourcecode für einen Computertyp geschrieben wird. Der Algorithmus wird auf der CPU ausgerührt und berechnet dort etwas. Die Berechnung wird im Sourcecode des Programms definiert. Das gegenteil sind offene Systeme. Dort wird nichts berechnet sondern es werden Nachrichten versendet. Das TCP/IP Protokoll im Internet ist ein Besipiel für ein offenes System, aber auch die DIKW pyramide, der Morse code oder die Unicode Tabelle sind offene Systeme.

Offene Systeme zeichnen sich dadurch aus dass sie als Nachrichtenübermittlung konzipiert sind. Es gibt einen Sender und einem Empfänger. Meist erfolgt die Datenübertragung über Schichten um die Komplexität zu senken. Offene Systeme wurden in der KI Geschichte bis zum Jahr 2010 meist ignoriert. Die einzige Ausnahme sind Multiagentensysteme, wo also Softwareagenten untereinander Botschaften senden, vergleichbar mit objektorientierter Programmierung. Es war jedoch unklar wie man diese Technik zur Robotiksteuerung einsetzen kann.

An dieser Stelle ein kleiner Exkurs wie vor dem Jahr 2010 selbstfahrendew Autos als geschlossene Systeme programmiert wurden. Die Idee war, dass es ein computerprogram gibt, welche die Künstliche Intelligenz ist. Dieses computerprogram besteht aus rund 500 MB Sourcecode programmiert in der Sprache C/C++ und enthält alle Module die für die Steruerung des Autos benötigt werden. Also planung, Bilderkennung, Entscheidungen treffen, Fehlerroutinen, Logging, Situationsbewertung usw. Die Intelligenz des Roboters ist in dieser 500 MB großen Datei gebündelt, es gibt keine Außenwelt die weitere Module enthält.

Aus Sicht der Informatik stellt so ein Softwareprojekt die best practice Methode da. Es wird klar definiert was Teil des Roboters ist, und es gibt Tools um die 500 MB große Sourcecode datei zu erstellen und zu verbessern. Leider funktioniert in der Realität so ein Workflow nicht. Die 500 MB Datei geschrieben in C/C++ ist eben nicht im Stande den Roboter zu kontrollieren und zwar generell nicht. Je mehr man versucht den Fehler zu finden desto mehr zusätzlicher Sourcecode muss erstellt werden, der neue Fehler enthält und der niemals im Stande ist die komplexe Realität abzubilden. Der Unterschied zwischen der internen Darstellung im Roboter und der Realität außerhalb des Roboters ist gewaltig.

Innerhalb des bekannten paradigmas geschlsosener Softwaresysteme ist es unmöglich den Fehler zu finden. es ist eben nicht so, dass der 500 MB Sourcecode für das selbstfahrende Auto veraltete algorithmen enthält oder schlecht programiert wäre. Sondern das Problem ist viel grundsätzlicher Natur und betrifft die Annahme hinter solchen Projekten. Das Ziel in der Robotik bis 2010 war es, autonome Roboter zu bauen welche keine menschliche Sprache verstehen. Dieser Bias wurde nirgendwo explizit definiert, sondern ergibt sich automatisch wenn man geschlossene Systeme entwickelt.

Nochmal: Geschlossene Systeme -- KI Forschung bis zum Jahr 2010

 Über Jahrzehnte war die KI Forschung von Misserfolgen geprägt die Resultat waren einer selbstgewählten Perspektive auf Künstliche Intelligenz. Die Zielstellung der Forscher bestand darin, eine Technologie zu entwickeln welche denken kann. Also eine Maschine, oder noch besser einen Computer, der geistige Leistungen ausführen kann. Dieser Bias ist naheliegend weil es zugleich auch die Vorstellung von Robotern ist welche in Romanen von isaac Asimov transportiert wird.

Was die KI Forscher vor dem Jahr 2010 jedoch nicht wussten bzw. verdrängt haben, war die bittere Erkenntnis dass das selbstgewählte Ziel nicht erreichbar ist. KI ist zwar grundsätzlich möglich, aber nicht als geschlossenes technologische Artefakt. Um die Leistungsgrenzen geschlossener Systeme zu veranschaulichen zunächst ein kleiner Exkurs wann dieses Konzept funktioniert.

Die meisten Erfindungen der Menschheit funktionieren als geschlossenes System: dazu zählt die mechanische uhr, die Dampfmaschine, die Schnellpresse von König&BAuer, das Automobil der Mikroprozessor, und Software wie z.b. das Windows Betriebssystem. Ein geschlossenes System ist demnach historisch gesehen die beste Methode wie man eine Technologie entwickelt. Man definiert zuerst einmal was die Maschinen können soll, z.b. soll ein Auto auf einer Straße fahren, und überlegt sich dann welche Bauteile man in die Maschine einbauen muss damit die Aufgabe erfüllt wird.

Der Vorteil von geschlossener Systeme ist, dass damit die Komplexität gesenkt wird, z.b. besitzt ein Elektromotor eine Breite und eine Höhe in Centimetern und was sich innerhalb dieser Abmessungen befindet gehört zur Maschine. Auf dieses physische Artefakt fokussiert man dann die Entwicklung und überlegt welche Materialien oder physikalischen Prinzipien wirken.

Auch bei der Softwareentwicklung wird das Prinip eines geschlossenen Systems verwendet. Eine Software besteht aus einem Source code der wiederum in Dateien unterteilt wird. In diesem Sourcecode ist die Funktionsweise der Software definiert. Alles was nicht im Sourcecode steht wird ignoriert. Es liegt außerhalb des System und ist für die Funktionsweise ohne Bedeutung. Stattdessen geht es darum, besagten Sourcecode zu optimieren, also effizientere Algorithmen zu verwe4nden, weniger Codezeilen zu verbrauchen udn vorhandene Fehler zu beseitigen.

Die unreflektierte Annahme der KI Forschung vor dem Jahr 2010 lautete, dass Robotik und KI nach demselben Prinzip funktioniert. Die Idee war, dass KI eine Art von Algorithmus sei, der innerhalb des Sourcecode definiert wird. Folgerichtig wurde versucht einen Roboter in einer Programmiersprache wie C/C++ zu programmieren. Relativ spät erkannten die Forscher dass genau dieser Ansatz problematisch ist. Damit ein Roboter intelligent in einer Umgebung agieren kann, muss der Roboter mindestens so komplex sein wie diese Umgebung. Eine KI zu programmieren die den kürzesten Weg in einem Labyrinth findet ist überschaubar, aber eine KI welche einen Roboter in der physischen Realität steuert ist eine unüberwindliche Aufgabe. Das benötigte Software programm für so einen Roboter würde sehr viele Codezeilen benötigen und selbst diese könnten nicht die komplexe Realität abbilden.

Eine Zeitlang gab es innerhalb der Robotik-Forschung eine wirkmächtige Antwort auf das Phänomen, genannt Model predictive control. Die Idee war, die Realität als vereinfachte Physiksimulation in Software nachzubauen, in dieser Simulation Prognosen auszuführen und dadurch dann die beste Entsheidung zu treffen. In den 2000er Jahren gab es mehrere Projekte wo mittels Model predictive control, Dronen gesteuert wurden und sogar grasp planning realisiert wurde. Leider ist model predictive control sehr rechenaufwendig. Eine halbwegs präzise physik Simulation benötigt sehr viele CPU Taktzyklen, gleichzeitig braucht aber der KI eine Prognose mehrmals pro Sekunde um auf Veräderungen zu reagieren. Model predictive control funktioniert nur auf dem Papier, aber nicht auf echter Hardware, speziell die Vorhersage längerer Zeiträume bis Minuten in die Zukunft sind technisch  nicht umsetzbar.

Abstrakt gesagt entstehen durch geschlossene Systeme in der KI Forschung zwei grundsätzliche Probleme: a) hohe Komplexität des Source codebode b) hoher Rechenaufwand bei der Ausführung von Algorithmen und der Model predictive Control Vorhersagen.

Anfangs dachten die Forscher, beide Problemen wären lösbar. Das war Wunschdenken. Es ist nicht durchführbar einen Roboter zu programmieren der hundertausende Codezeilen benötigt, und hohe Anforderungen an die CPU gleichzeitig hat. Ein solches Projekt wird in der REalität scheitern.

Betrachten wir geschlossene Systeme etwas genauer. Im wesentlichen Funktionieren diese Systeme nach Naturwissenschaftlichen Prinzipien. Ein Elektromotor verwendet einen Magneten um eine Drehbewegung zu erzeugen, während ein Mikroprozessor über elektrischen Strom kleine Transistoren schaltet. Es gibt also jeweils ein physikalisches Prinzip was in einer Maschine praktisch angewendet wird. Dadurch dreht sich ein Motor, der Computer beginnt zu rechnen oder ein Flugzeug fliegt durch die Luft. Man glaubte anfangs, dass Künstliche Intelligenz auf ähnliche Weise realisiert werden könnte, das es also ein wissenschaftlich-technisches Prinzip gibt was man in einem Softwareprogramm anwenden kann um darüber Roboter zu steuern. Was die Forscher vor dem Jahr 2010 nicht wussten war dass es ein solches Naturprinzip nicht gibt, das es also nicht möglich ist, auf diese Wweise Künstliche Intelligenz zu erzeugen.

Eine mögliche Erklärung warum die KI Forschung bis ca. 2010 sich auf geschlossene Systeme fokussierte ist, dass die Informatik insgesamt nach diesem Muster funktioniert. Definitionsgemäß untersucht Informatik die Funktionsweise von Computern, also speziell die Hardware und die Software. Damit ist zugleich definiert wofür die Informatik nicht zuständig ist. Alles was keine Computerhardware ist und nicht smit Software zu tun hat, liegt außerhalb der Informatik und entzieht sich einer wissenschaftlichen Analyse.

Diese Einschränkung ist für die klassische Informatik kein Problem und sogar erwünscht weil es dabei hilft echte Probleme zu lösen, also z.b. neue CPU zu entwickeln, bessere Programmiersprachen zu erfinden oder Betriebssysteme zu entwickeln. All diese Thmene sind entweder im Bereich Hardware oder im Bereich Software angesiedelt.