November 05, 2024

Development time for programming a video game

 

Comparing programming languages is traditional measured in machine performance. The overall question is how small the binary file is, how fast its run on hardware. Sometimes, its asked how well the source code looks, but this depends on individual preferences.
A more practical approach is to compare how long it takes to program the same software in different languages. A rough estimation for coding a pong like videogame including graphics is:
  • Assembly language, 14 days
  • Forth language, 7 days
  • C language, 3 days
  • Python, 1 day
Such a table might explain why a certain language is popular while other not. In the 1980s the first two languages on the list were very popular. For many 8bit computers there was no alternative available over Assembly and Forth. Both languages need only a small amount of RAM and are working fine without any hard drive. In the 1990s the C language has become the standard for programming. Not because C is better than Assembly but because it takes a shorter amount of time to write a program. A good starting point to create a pong like video game in C is to use existing graphics libraries like SDL, this allows to finish the project in around 3 days. Since the year 2010 the python programming has become more popular. This might be a surprise from a technical perspective, because Python is known for its slow performance, especially in game development.
Nevertheless, Python allows to create complex software in a smaller amount of time. Finding bugs in a python program is much faster, and the sourcecode is dramatically shorter than the C counterpart. Its not very hard to predict which sort of programming language will replace python in 10 years, which are of course large language model which require only a text prompt as input and can generate the game by itself. This will reduce the time until a new game was programmed further down to hours.

October 31, 2024

Chronological notetaking with problems


 The easiest way to make notes is to append new information at the end. There is no need to use a ring binder or note cards but a normal notebook works fine. A possible entry would be “date: March 10, headline, body of text”. The note is written down on paper and can be read again forever.

There is a large problem available with such a note taking technique. Chronological notetaking will mess up the notes on the long run. Notes about mathematics will follow notes about history and language. The only sorting order available is the date. This makes it hard to read the notes again. Let me give an example.
Suppose the user has written down over a horizon of 2 weeks multiple notes from different subjects. Now he likes to retrieve all the notes about math. The problem is, that the math notes are distributed over different sections in the notebook. Some math notes are written down on march 10, while other are from march 16 and the notes in between have nothing to do with prime numbers but are from different subjects.
Even if the notes are technically well written its impossible to retrieve them because they aren't sorted by topic but only by date. To sort notes by topic, there is need to use a different principle than only adding notes at the end. Some sort of ring binder or Zettelkasten is needed. With such a tool its possible to add new math notes after the old math notes.
The main advantage is, that its much easier to read the notes again. All the math notes are collected together. The user doesn't has to read the entire notebook, but only the math section. This makes it likely that the notes are consulted multiple times. The disadvantage of ring binders and card catalogs is, that its more demanding to create the notes. Before new notes can be added to the system the correct position has to be located. Which slows down the writing process.

October 22, 2024

Pipeline for developing chatbot based robotcs

 Since the introduction of large language models in the year 2023, the term "artificial intelligence" was defined very clearly. AI means simply that the user interacts with a chatbot in natural language. The chatbot is able to answer questions, can draw pictures and also the chatbot controls a robot.

From the user perspective, the software works suprisingly easy to explain. The user enters a sentence like "open left hand" and submits the text to the chatbot. The chatbot is parsing the sentence and executes the command, which means that the robot will open indeed the hand. More complex actions like moveing to a table and wash all the dishes are the result of more advanced text prompts which contains a list of sub actions.

The unsolved issue is how to program such advanced chatbots in software. Before a user can talk to a robot this way, somebody has to program the chatbot first which can be realized in C++, Java, and so on. The basic element of any chatbot isn't a certain programming library like nltk and its not a certain operating system like Windows or Unix, but the needed building block is a dataset. Or to be more specific, a dataset which maps language to perception, and language to action.

Such a mapping is realized with multiple column because the dataset is always a table. In the easiest example the table consists of a images in the first column and the nouns in the second column:

[picture1.jpg], apple
[picture2.jpg], banana
[picture3.jpg], table
[picture4.jpg], spoon

The chatbot software is using such a dataset to understand a text prompt from the user. For example if the user types into the textbox "take apple". The word apple is converted into [picture1.jpg] and this picture allows to find the apple with the camera sensor.

More complex interactions like generating entire motion data are provided the same way. A verb like "grasp" is converted into motion capture trajectory with the following table:

[trajectory1.traj], open
[trajectory2.traj], grasp
[trajectory3.traj], standup
[trajectory4.traj], sitdown
[trajectory5.traj], moveto

Let me give a longer example to make the point clear. Suppose the user enters the command "moveto table. grasp apple". This command sequence is converted into:
1. [trajectory5.traj], moveto
2. [picture3.jpg], table
3. [trajectory2.traj], grasp
4. [picture1.jpg], apple

In the next step of the parsing pipeline the given jpeg images and .traj data are converted into search patterns and motion pipelines. This allows to convert a sentence into robot actions.

There are mutiple techniques available how to program a chatbot in detail. Its possible to use ordinary programming languages or more advanced deep neural networks. What these methods have in common is, that they are requiring always a dataset in the background. Somebody has to create a table with pictures with objects, and annotate the pictures. Also a dataset with mocap data is needed. Such a dataset allows a chatbot to convert a short sentence into something meaningful. Meaning is equal to a translation task from a word into a picture, and from a word into a trajectory.

So we can say, that a chatbot is the frontend of an AI while the dataset is the backend.

October 11, 2024

Einführung in grounded language

 Ins deutsche übersetzt heißt es soviel wie gelenkte Sprache oder strukturierte Sprache. Es geht darum die Realität mit Hilfe eines Fragebogens zu beschreiben um darüber die Maschinenlesbarkeit zu erhöhen. Dazu ein Beispiel:

Angenommen, es soll eine Verkehrszählung durchgeführt werden. Im einfachsten Fall beginnt man ohne größere Vorbereitung und führt eine Strichliste. Die bessere Alternative besteht darin, vor dem Zählen zuerst einmal ein Formblatt zu entwerfen worin Variablen definiert werden, welche beschreiben was genau gezählt wird. Zur Erfassung des Autoverkehrs bieten sich folgende Variablen an:
Fahrtrichtung: von links / von rechts
Autofarbe: schwarz / blau / grün / rot / sonstiges
Fahrzeugtyp: PKW / LKW / Bus / sonstiges
Uhrzeit

Ein solcher Zählbogen ist weitaus detailierter als eine simple Strichliste weil man viele wertvolle Details zum Straßenverkehr erhält. Die o.g. statistischen Variablen sind identisch mit grounded language. Es wird dabei natürliche Sprache so verwendet, dass ein Vektorraum entsteht innerhalb derer dann etwas gezählt wird. Am Ende der Verkehrszählung kann man dann sagen, wieviele rote PKWs von links kamen oder wieviele LKW insgesamt die Straße befahren haben.

Im Bereich Statistik und Soziologie sind solche Erhebungsbögen allgemein bekannt und werden seit Jahrzehnten verwendet. Sie dienen als Hilfsmittel um komplexe Fragestellungen zu strukturieren und zahlenmäßig zu erfassen. Was jedoch neu ist, ist dass mit der selben Methode das Problem der Robotik und Künstlichen Intelligenz maschinenlesbar aufbereitet werden kann.

Im Grunde muss ein Roboter, der sich in einem Labyrinth bewegen soll, nur mit einem Formblatt versehen werden, was grounded language enthält. Über dieses Formblatt kann die Umgebung in einen symbolischen Vektorraum überführt werden, also maschinell-mathematisch gespeichert werden. EIne Kategorie in dem Formblatt wie z.B. "Farbe=blau" kann entweder wahr oder falsch sein. Die Strichliste kann einen Strich enthalten oder eben nicht. Darüber vermag der Roboter ein Protokoll anzulegen und Entscheidungen zu treffen. Das komprimiert den Handlungsraum. Anstatt Sensoren hardwaremäßig abzufragen, hat der Roboter ein konzeptionelles Verständnis der Umgebung. Man erhält einen high level Sensor der die Daten des Fragebogens inkl. der darin verwendeten Sprache verwendet.

September 30, 2024

Chatbot Evolution in den 2010er Jahren

 Es ist naturgemäß schwierig aktuelle Entwicklungen unter historischen Aspekten zu beleuchten, weil die Menge an Literatur zunimmt je näher man sich der Gegenwart nähert und weil die Strömungen schwerer zu überblicken sind. Anstatt die tatsächliche Gegenwart in Bezug auf Chatbots zu beschreiben welche von 2020 bis heute geht, besteht eine mögliche Alternative darin, etwas weiter zurück zu gehen und nur die 2010'er Jahre zu beschreiben.

Einerseits gab es in den 2010er neu entwickelte Algorithmen im Bereich Machine Learning und Natura language processing um Chatbots an sich zu verbessern.  Es gab darüberhinaus aber noch eine weitere weit weniger offensichtliche Technik und zwar die Einführung von Chatbots benchmarks. Dabei geht es nicht darum, einen chatbot in der Leistung zu erhöhen ihn also menschlicher zu gestalten sondern bei einer chatbot challenge geht es darum, vorhandene Chatbots untereinander in ihrer Leistung nach Punkten zu bewerten. Die Annahme lautet dass jemand anderes bereits mehrere Chatbots programmiert hat und es darum geht diese zu ranken.

Die Entwicklung dieser Chatbot vergleichsbenchmarks sind der eigentliche Grund der Verbesserung der Chatbot technologie. Bevor man neuartige Algorithmen inkl. neuronaler Netze entwickelt muss man zuerst einmal wissen wie vorhandene Konzepte leistungsmäßig abschneiden. Praktisch werden die Benchmarks als Dataset realisiert, was übersetzt soviel wie Datenbasis oder Tabelle bedeutet.  Datasets haben ihren Ursprung im Machine learning wo man zwischen Training dataset und test dataset unterscheidet.

Der Übergang von manuell programmierten Chatbots hin zu Dataset benchmark wird durch den ALICE chatbot (1995) aufgezeigt, der das AIML format verwendete. AIML ist einerseits das Datenformat für den Chatbot aber dient gleichzeitig als Korpus für eine Wissensdatenbank. Wenn man jetzt nur den Datensatz verbessert aber nicht den Chatbot, erhält man einen Chatbot dataset. Wo also die Entwicklung eines Punktesystems im Vordergrund stteht. Andere chatbots haben nun die Aufgabe, in Bezug auf einen konkreten AIML Korpus eine möglichst hohe Punktzahl zu erzielen.

Spätere Chatbot benchmarks basierten nicht länger auf dem AIML format sondern verwendeten csv dateien oder sogar Textdateien. Der Benchmark wurde in Form einer dokumentensammlung bereitgestellt was den Übergang zu Question & Answering systemen darstellt. Die Aufgabe für diese Generation von chatbots bestand darin, Fragen zu einem Dokumentencluster zu beantworten. Auch hierbei gab es Algorithmen, die dabei sehr gut abschneiden und andere denen es weniger gut gelang.

September 29, 2024

Chatbots bis zum Jahr 2010

 Die Geschichte von Chatbots kann man grob in 2 Phasen einteilen: 1960-2010 und 2010-heute. Die ältere Zeitperiode ist gut dokumentiert und leicht nachvollziehbar. Projekte wie Eliza und Cleverbot wurden programmiert um menschliche Dialoge zu imitieren. Sie basieren auf einem parser, der die Eingabe des menschlichen Benutzers auswertet und einem Satzgenerator der daraufhin eine Antwort erzeugt. In der Interaktion führt das dazu, dass Chatbots einerseits Sätze erzeugen aber gleichzeitig die Schwächen der KI deutlich werden.

Ab Anfang der 2000er Jahre gab es in der Chatbot Technologie eine Neuerung und zwar das AIML Dateiformat. Darin können Frage / Antwort Paare außerhalb des eigentlichen Quellcodes abgelegt werden. Man muss also einerseits die Chatbot software programmieren und dann noch eine AIML Wissensdatenbank erstellen die eine normale Datenbank ist. Aber, auch mit AIML ist die Leistungsfähigkeit der erzeugten Chatbots nicht besonders hoch. Es ist nur leichter diese zu programmieren.

Ab dem Jahr 2010 gab es in der Chatbot Entwicklung eine massive Verbesserung. Diese hatte nur indirekt etwas mit Maschine Learning zu tun sondern die Veränderung bestand darin, zunächst einmal das Problem zu definieren um das es geht. Bis 2010 war die implizite Annahme es geht darum einen Chatbot zu programmieren, also eine Computersoftware die auf Sprache reagiert. Nur, das ist nicht das eigentliche Problem. Worum es wirklich geht ist das Question answering Problem zu lösen. Als Q&A challenge bzw. als Q&A dataset wird eine Tabelle mit Quizfragen bezeichnet die ein Mensch oder ein Computer richtig beantworten muss. Es geht also eben nicht um die innere Funktionsweise einer künstliche Intelligenz sondern es geht um eine Wissensspiel ähnlich wie Trivial Pursuit, Jeopardy usw.

Bevor man einen Chatbot programmieren kann muss man zunächst einmal eine Aufgabe programmieren die dieser Bot lösen soll. Also eine Art von Computerspiel ähnlich wie Tetris, Pong usw. Allerdings geht es bei diesem Spiel anders als bei Arcade spielen nicht um schnelle Reaktionsfähigkeiten sondern um das Verstehen von Sprache. Daher auch die Bezeichnung Question&Answering challenge. Dieses Spiel funktioniert so: dem Spieler wird eine Frage präsentiert, z.B. "Was ist 5+2?" und der Spieler muss antworten "7". Eine weitere Frage könnte lauten "Welcher Kontient ist der trockenste und heißeste der Welt?" Antwort: Afrika.

Für ein Quizspiel spielt es keine Rolle ob jemand darin gut abschneidet oder schlecht. Und ob jemand das Spiel als Mensch löst, als Computerprogram oder als neuronales Netz. Sondern ein Quizspiel ist nur ein formalisiertes Problem. Es besteht aus einer Anzahl von quizfragen aus unterschiedlichen Bereichen und es gibt Antworten auf jede Frage die geheim sind für die Kandidaten. Jetzt kann der Quizmaster ermitteln wieviele Antworten ein Kandidat richtig beantwortet.

Das besondere an Q&A challenges ist dass man damit die Performance von Computersystemen bestimmen kann. Man kann unterschiedliche AI Algorithmen entwerfen die die Fragen beantworten und dann lässst sich sagen, welcher Ansatz besser war. Q&A challenges sind die Grundlage um fortschrittliche Chatbots zu entwickeln. Ein chatbot ist schlichtweg eine Software, die in einer Q&A challenge besonders gut abschneidet.

Mit diesem Hintergrundwissen lässt sich besser herausarbeiten was der Unterschied ist zwischen den Chatbots bis 2010 und jenen die danach entwickelt wurden. Chatbots vor 2010 wie Eliza wurden nicht mit Punkten bewertet. Die Software hat zwar einen Dialog geführt aber es gab keine Punktzahl über die Qualität der Ausgaben. Bei neueren Bots wie IBM Watson gibt es eine solche Bewertung. Eben weil neuere Chatbots als Antwortgeneratoren für Q&A Challenges entwickelt wurden.

Um einen neuen Chatbot zu programmieren benötigt man keine besonderen Algorithmen aus dem Bereich sondern benötigt wird ein conversational dataset. Also eine Tablele mit Frage/Antwort Paaren aus dem Bereich smalltalk.  Dieser Dataset wird als Benchmark und als Problemdefinition verwendet. Der Dataset ist eine Art von Small talk spiel und im zweiten Schritt kann man ein Computerprogramm erstellen, dass dieses Spiel spielt. Im wesentlichen geht es also darum zu unterscheiden zwischen einer Aufgabenstellung (dem Q&A Dataset) einerseits und einem Teilnehmer (dem chatbot) der innerhalb des Spiels aktionen ausführt.

September 28, 2024

Obsolete technische Erfindungen

 Technischen Fortschritt direkt zu messen ist niccht möglich, weil unklar ist was die Zukunft bringen wird. Was man aus Technikhistorischer Perspektive jedoch weitaus besser untersuchen kann sind Dinge die es heute nicht mehr gibt. Also Erfindungen die durch etwas besseres ersetzt wurden wie z.B. die 3.5 Floppy disk, Telefonzellen oder die mechanische Schreibmaschine.

Diese Dinge waren in ihrer jeweiligen Zeit mehr als nur Kuriositäten von verschrobenen Wissenschaftlern, sondern es gab große Unternehmen die die Produkte hergestellt haben und Millionen von Menschen die das benutzt haben. Die 3.5 Floppydisk beispielsweise gab es früher überall zu kaufen, sie war das universale Speichermedium in den 1990er Jahren. Und zwar für die Heimcomputer wie auch die PCs gleichermaßen. Es war also eine Art von Industriestandard. Heute hingegen ist diese Technologie komplett verschwunden, es gibt lediglich noch alte Bücher darüber und natürlich Technikmuseen wo das Medium neben einer 5.25 Zoll Floppy und der Lochkarte ausgestellt ist, die ebenfalls verschwunden ist aus der öffentlichen Wahrnehmung.

Je schneller die Welt voranschreitet, desto zahlreicher sind die Erfindungen die obsolet werden. Die meisten Erfindungen waren relativ fortschrittlich wurden aber durch bessere Erfindungen verdrängt. z.B. waren dampfgetriebene Schaufelradschiffe zu ihrer Zeit das beste Transportmittel um Flüsse in den USA zu befahren. Allerdings gilt die Technologie heute als veraltet. Selbst sehr alte Schiffe werden mit Diesel angetrieben und nicht länger mit Kohlekraft. Demnach wurde eine frühere Kraftquelle durch eine neuere ersetzt. So ähnlich ist es auch mit dem Commodore 64 Heimcomputer der in den 1980er millionenfach verwendet wurde, heute hingegen verschwunden ist und nur noch als Nostalgie-Computer weiterlebt. Die Chance ist groß dass viele der heutigen Dinge wie z.B. Benzin getriebene Autos irgendwann in ferner Zukunft durch andere / bessere Technologien ersetzt werden.

Produkte im Bereich Computertechnologie veralten besonders schnell. So sind frühere Betriebssysteme wie OS/2 oder Windows NT heute nur noch im Museum zu finden. Und neu eingeführte Software wie z.B. eine Linux Distribution wird bereits in der Auslieferung mit einem Verfallsdatum von 3 Jahren versehen. Danach werden die Benutzer aufgefordert auf die Nachfolgeversion zu wechseln. Nach der Selbstwahrnehmung der Programmierer ist die kontinuierliche Weiterentwicklung von Software sogar eine best practice methode damit immer alle wichtigen Anforderungen erfüllt werden.

September 27, 2024

Das State space Problem innerhalb der Robotik

 Bis zum Jahr 2010 war das Forschungsgebiet der Robotik leicht zu überschauen weil es zwischen Anspruch und Wirklichkeit einen unüberwindlichen Graben gab. Der Ausgang von dezidierten KI und Robotikforschungsprojekten zu dieser Zeit konnte man mit einem simplen Wort beschreiben: Scheitern. Egal ob die Forscher versuchen 4 beinige Laufroboter zu programmieren, eine Roboterhand die einen Apfel greifen sollte oder auch nur eine ingame AI die in einem Computerspiel Punkte sammelt, kamen die Forscher mit den vorhandenen Methoden niemals zum Ziel. Konkret hieß dass, dass es zwar möglich war, die Roboterhardware zu bauen aber es fehlte dann an einer Software die die Bewegung erzeugte. Auch gelang es zwar Computerspiele selber zu erstellen, inkl. 3d Grafik und Soundausgabe, aber sobald eine AI innerhalb eines Spiels benötigt wurde, gab es dafür weder Algorithmen noch Bibliotheken.

Im wesentlcihen scheiterte die Entwicklung an einem Phänomen, dass bereits James Lighthill im Jahr 1973 beschrieben hat und zwar die kombinatorische Explosion. Selbst eine simple Roboterhand die einfach nur ein Objekt greifen soll hat bereits Millionen von Millionen unterschiedliche Servomotor Einstellungen und selbst Supercomputer sind nicht im Stande diesen Gametree in Echtzeit zu durchsuchen. Laienhaft ausgedrückt ist es unmöglich eine Software zu entwickeln die Roboter autonom steuert.

Obwohl diese Feststellung nicht dezidiert in jedem Einzelnen Paper zu Robotik beeschrieben wurde, war es doch die gemeinsame Ansicht zur damaligen Zeit. Jedenfalls gibt es vor 2010 kein einziges Paper in dem erläutert wird, wie man das P=NP problem oder die kombinatorische Explosion lösen könnte, also muss man unterstellen, dass damals das Problem ungelöst blieb. Und das bedeutete, dass die Gesammte KI Community im Grunde nur Fehlschläge, Rückschläge oder nicht eingelöste Versprechungen produzierte. Ganz im Gegensatz zur restlichen Informatik die im Bereich Hardwareentwicklung, Entwicklung neuer Programmiersprachen oder Netzwerk-Protokolle laufend Fortschritte feierte. Mit der normalen Nicht-KI Informatik konnte man immerhin das Internet betreiben und Anwendersoftware programmieren, während die KI Sparte keine praktische Relevanz hatte.

Die einzige Ausnahme bis zum Jahr 2010 wo Künstliche Intelligenz einen Teilerfolg vermelden konnte war Computerschach. Die Bewältigung dieses Brettspiels mit Hilfe von Computer war ein wiederkehrendes Thema seit den 1960er Jahren und im Laufe der Jahre wurden Computer darin immer besser. In 2010 waren selbst Desktop PCs im Stande den amtierenden Menschlichen Großmeister klar und wiederholbar zu besiegen. Allerdings gab es mit dieser technischen Leistung mehrere Probleme: erstens, war der rechenaufwand dafür hoch, typische Schachprogramme haben alle Kerne einer CPU auf 100% ausgelastet und selbst dann mussten sie mehrere minunten Rechnen um den nächsten Zug zu ermitteln, und zweitens ließen sich Schachalgorithmen nicht auf andere Probleme wie der Robotik übertragen. Das heißt, die Schach AI konnte nur schach spielen und sonst gar nichts.

Selbst geringfügig andere Brettspiele wie Backgammon oder Go waren bereits extrem schwierig für eine Schach-KI zu meistern. Man musste den kompletten Quellcode umschreiben und selbst dann war ungewiss ob es gelang menschliche Spieler zu besiegen. Insofern waren schachspielende Computer eher ein Beweis dafür, dass KI nicht realisierbar war.

Obwohl KI bis 2010 utopisch war, haben die Forscher weiterhin die Thematik untrsucht. Und zwar mit einer modifizierten Fragestellung. Wenn es offenbar nicht möglich war, Roboter zu programmieren, wollte man wenigstens wissen woran es genau scheitert. Das führte dazu dass sich die Richtung der Forschung änderte. Anstatt Roboter zu programmieren hat man zunächst versucht, in der Simulation Roboter zu steuern. Wo es also keine Hardware gibt sondern nur eine virtuelle Realität und wo die Aktionsmöglichkeiten des Roboters kleiner sind. Weiterhin wurde besonders von 2000 bis 2010 stark das Gebiet des Deep learning erforscht. Man glaubte durch ein besseres Verständnis von neuronalen Netzen vielleicht etwas über Künstliche Intleligenz im Allgemeinen zu verstehen. Eine weitere Antwort auf gescheiterte KI Projekte war die Fokussierung auf synthetische Probleme wie Robocup oder Micromouse. Damit wurde der Schwierigkeitsgrad gesenkt was bedeutete die Chance auf Erfolg zu erhöhen.

Speziell der Micromouse Wettbewerb ist aus technischer Sicht ein überschaubares Problem. Es gibt nur einen simplen Roboter der nochdazu Räder, und dieser muss einen Weg finden wobei man auf einen Blick sieht ob dieser Weg zum Ziel führt oder nicht. Selbst wenn der Roboter zufällig im Labyrinth herumfährt, wird er irgendwann von ganz allein am Ziel ankommen.

Auch die beschriebenen veränderten Fragestellungen wie synthetische Probleme, Deep Learning und Simulationen vermochten nicht das Problem der kombinatorischen Explosion zu lösen. Selbst bei einem simplen Maze roboter enthält der gametree mehrere Millonen möglicher Systemzustände. Dieses eine Problem des übergroßen Suchbaumes ist der rote Faden der seit den 1950er Jahren verhinderte, dass Robotik und Künstliche Intelligenz realisiert werden konnte. In der theoretischen informatik wird es manchmal als P=NP Problem bezeichnet und gilt nach übereinstimmender Aussage als unlösbar.

Selbstverständlich gab es auch vor 2010 ernstgemeinte Versuche trotzdem Algorithmen zu entwerfen die dezidierte np harte Probleme lösen können. Nur die Ansätze waren unausgereift und verfolgten sehr unterschiedliche Ansätze, es gab beispielsweise Rapidly exploring random tree algorithmen, heuristische Algorithmen, Bewertungsfunktionen, reinforcement learning, probabilistische Suchalgorithmen oder simulated annealing. In manchen Fällen wie dem traveling salesman problem oder dem 15 puzzle problem lässt sich damit tatsächlich eine Lösung finden. In diesem Fall muss der Spielbaum nicht komplett traversiert werden, sondern heuristische Algorithmen finden die optimale Route zum Ziel sehr viel effizienter. Das Problem war jedoch, dass sich diese Verfahren nicht verallgemeinern ließen und das es keine generalierten Lösungen gab die auf mehrere Probleme insbesondere im Bereich Robotik anwendbar waren.

Das einzige was bis 2010 halbwegs zuverlässig funktionierte waren Pfadplanungsalgorithmen mit einer Evaluationsfunktion, also A* und ähnliche Verfahren. Diese wurden sowohl in Computerspielen als auch in der Robotik eingesetzt um auf einer 2d Karte den kürzesten Weg zu planen. Nur A* ist für die Planung einer Roboter hand nutzlos und kann auch nicht für biped walking eingesetzt werden.

Man kann die Kernproblematik der Robotik vor 2010 in einem simplen Satz zusammenfassen: "Mit welchem Algorithmus lässt sich ein sehr großer Zustandsraum schnell durchsuchen?" Schon die Frage offenbart, dass das Problem quasi unlösbar ist. Einerseits gibt es einen Zustandsraum, der aus Millionen von States besteht, gleichzeitig soll dieser Zustandsraum in kurzer Zeit also in realtime durchwandert werden. Dies schließt sich gegenseitig aus. Es gibt mehrere Paper aus der theoretischen Informatik die sogar mathematisch begründen dass so ein Algorithmus unmöglich existieren kann. Im Grunde läuft es auf das altbekannte P=NP Problem hinaus, also der Fragestellung wie man komplexe Probleme auf einem langsamen Computer lösen will.

Die Antwort auf die Probleme ist banal. Keineswegs bedarf es Quantencomputer um np harte Probleme zu lösen, sondern es reicht aus die Prioritäten zu verschieben. Bei einem Schachcomputer fokussiert man auf die Bewertungsfunktion und vernachlässigt die Suche im Gametree. Im Extremfall nutzt man eine optimierte Bewertungsfunktion die auf die Nachkommastelle genau ermittelt ob Weiß oder Schwarz im Vorteil ist und senkt den Suchhorizont ab auf 1 Zug in die Zukunft. Wenn man dann beschreibt, wie sich Bewertungsfunktionen im Allgemeinen mittels Feature engineering erzeugen lassen lässt sich das Paradigma auf andere Aufgaben aus der Robotik ausdehnen und man erhält eine mächtige Methode zur Lösung komplexer Optimierungsaufgaben.

Eine moderne KI die Schach spielen kann besteht weniger darin, irgendwelche neue Algorithmen zu entwickeln sondern als modern gilt eine Chess engine dann, wenn sie bestimmte Dinge einfach weglässt. Im einfachsten Fall nehme man einfach einen Schachcomputer aus den 1980er der durchschnittlich Schach spielt, deaktiviert dort die Suche im Spielbaum und lässt die vorhandene Bewertungsfunktion als einziges Softwareelement aktiviert. Und schon erhält man eine erstaunlich Leistungsfähiges Beispiel für eine heuristisches KI die in der Lage ist, die aktuelle Spielsituation in eine Punktzahl überführen.