SOAR

Soar (für State, Operator, Apply, Result) ist eine kognitive Architektur, die von John Laird, Allen Newell und Paul Rosenbloom in den 1980er Jahren entwickelt wurde. Wie ACT-R versucht auch dieses Projekt die notwendigen Grundbausteine für ein allgemeines intelligentes System zu finden und zu integrieren, das nicht nur begrenzte Aufgabenbereiche sondern eine Vielzahl an Problemstellungen und Domänen meistert, alle möglichen Arten von Wissen lernt und speichert sowie die volle Bandbreite an menschlichen kognitiven Fähigkeiten von Entscheidungsfindung, Planung bis zum Sprachverständnis ausführen kann.

Die Theorie Soar sieht den Menschen als symbolverarbeitendes System, welches basierend auf einer Menge von interpretierbaren und kombinierbaren Symbolen eine Menge von Aktionen ausführen kann. Dies seien den Entwicklern zufolge bereits die notwendigen und hinreichenden Bedingungen für intelligentes Handeln.

Problemlösen ist in Soar nicht die Anwendung einer einzelnen richtigen Regel, sondern besteht im Absuchen eines Problemraums, welcher durch einen Anfangszustand, einen oder mehrere Endzustände und eine Menge von Operatoren, die den aktuellen Zustand verändern können, definiert ist. Entscheidungsfindung ist daher die Selektion und Anwendung einer Reihe von Operatoren, die von sog. Produktionsregeln vorgeschlagen, evaluiert und eingesetzt werden. In Soar ist das gesamte Wissen des Systems in diesen Produktionsregeln innerhalb eines Regelspeichers kodiert. Um auf diesen Regelspeicher und das dort kodierte prozedurale und Faktenwissen zugreifen zu können, benötigt man einen Arbeitsspeicher (working memory), der auch die Ziele des Systems verwaltet. Zum Vergleich: In ACT-R wird dagegen das Faktenwissen im deklarativen Gedächtnis in Form von unabhängigen Wissenseinheiten, sog. Chunks, gespeichert und es gibt kein separates Arbeitsgedächtnis, sondern Chunks werden nach Überschreiten einer Mindestaktivierung abgerufen. Prozedurales Wissen wird allerdings in beiden Architekturen in einem Regelspeicher abgelegt.

Ein klassischer Verarbeitungs-Zyklus in Soar sieht folgendermaßen aus (für eine ausführliche Beschreibung siehe unten):

1. Input (optional)
   • Daten über die Umwelt werden in den Arbeitsspeicher aufgenommen
2. Operator-Vorschläge
   • Produktionsregeln überprüfen, ob der Arbeitsspeicher (im aktuellen Zustand) bestimmte Bedingungen erfüllt
   • Wenn ja, schlagen die Regeln die Anwendung eines bestimmten Operators vor
3. Operator-Vergleich
   • Allen vorgeschlagenen Operatoren wird eine Präferenz zugeordnet
4. Operator-Selektion (A oder B)
   • A: Ein Operator hat eine höhere Präferenz als alle anderen, weiter mit Schritt 5.)
   • B: Es kann eindeutig kein Operator ausgewählt werden  Konfliktresolution
   1. • Es wird ein Zwischenzustand mit Unterziel erstellt
      • Ziel ist es nun, den Konflikt aufzulösen, z. B. durch Trial-and-Error (neuer Zyklus mit anderem Zielzustand) oder Frage an den Benutzer
      • Bei Konfliktlösung Generierung eines „Chunks“, der sich die Lösung „merkt“
5. Operator-Anwendung
   • Alle passenden Produktionsregeln werden angewandt, was zu einem neuen Zustand führen oder den Zyklus beenden kann
6. Output (optional)
   • Kommandos werden an die Umwelt weitergeleitet
7. Setze fort mit Schritt 1.)

Wenn die Bedingungen der Produktionsregeln zu den Inhalten im Arbeitsspeicher (dem Zustand) passen bzw. erfüllt sind, werden sie parallel aktiviert („feuern“). Regeln können Faktenwissen im Arbeitsspeicher ablegen, einen Operator vorschlagen oder Operatoren bewerten (z.B. schlägt eine Regel die Auswahl von Operator A statt Operator B vor). Sollte in diesem Prozess kein bester Operator gefunden werden, wird die Konfliktresolution eingeschaltet. Dafür generiert Soar ein neues Unterziel, um den besten aus mehreren zur Ausführung geeigneten Operatoren herauszusuchen. Wenn ein optimaler Operator gefunden wurde, dessen Bedingungen durch den aktuellen Zustand aber noch nicht erfüllt sind, werden von Soar Teil- oder Unterziele generiert, um diese Bedingungen zu erfüllen. Zum Beispiel möchte jemand einen Artikel über kognitive Architekturen schreiben, hat aber von diesem Thema keine Ahnung. Das System würde dann ein erstes Ziel generieren um z.B. Literatur zu recherchieren. Wenn die Person keine Literatur besitzt, wird ein Unterziel generiert um diese zu besorgen usw.

Der selbstständige Wissenserwerb bzw. das Lernen neuer Produktionsregeln und neuen Faktenwissens hängt ebenso mit den generierten Unterzielen zusammen, denn bei jeder Bewältigung eines Unterziels erstellt Soar eine neue Regel. Diese neue Regel hat als Bedingungskomponente den Systemzustand vor der Generierung des Unterziels und als Aktionskomponente das Ergebnis nach Bearbeitung des Unterziels. Dieser als „chunking“ bezeichnete Mechanismus ist die einzige Möglichkeit, in Soar neues Wissen zu erwerben. In ACT-R wird über mehrere Mechanismen gelernt z.B. über die Generierung neuer Chunks aus alten Zielen oder die Parameterveränderung von Chunks oder Produktionsregeln (z.B. die Erhöhung der Chunk-Aktivierung bei mehrfachem Abruf).

Neuere Versionen von Soar unterstützen auch Reinforcement Learning, welches die Präferenzen für die Evaluierung von Operatoren basierend auf erhaltenen Belohnungen (die im Arbeitsspeicher repräsentiert sind) moduliert.

Software

Aktuell unterliegt die Instandhaltung und Aktualisierung von Soar der Gruppe um John Laird an der University of Michigan. Die Software ist auf Basis von C und C++ programmiert und als Standalone-Version frei verfügbar.

Anwendungen

Soar wird u.a. als Künstliche Intelligenz in einer Vielzahl von Computerspielen (z.B. Quake II, StarCraft) eingesetzt, aber auch um Roboter zu steuern, Pilotverhalten im Flugzeug oder Menschen in virtuellen Realitäten zu simulieren.