Soar (Kognition)

Soar (früher SOAR als Akronym für State, Operator Apply Result) ist eine kognitive Architektur; also eine Theorie, die alle primitiven Mechanismen und Strukturen definiert, die menschlicher Kognition zugrunde liegen. Diese primitiven Prinzipien bleiben über lange Zeiträume und verschiedene Anwendungsdomänen hinweg konstant. Die wichtigsten dieser primitiven Prinzipien sind in Soar:

1. Problemlösen wird als Suche in Problemräumen repräsentiert
2. dauerhaftes Wissen wird durch Produktionsregeln repräsentiert (im Produktionsspeicher)
3. temporäres Wissen wird durch Objekte repräsentiert (im Arbeitsspeicher)
4. neue Ziele werden nur generiert, wenn Sackgassen (Impasses) auftreten
5. Lernmechanismus: Chunking und ab Version 9.0.0 auch Reinforcement Learning

Auf der Grundlage dieser Architektur können jetzt komplexere menschliche Fähigkeiten modelliert werden (z. B. Kopfrechnen, Sprachverarbeitung, Lernprozesse etc.). Wenn diese Modelle ausgereift und vollständig sind, soll es möglich sein, einen künstlichen intelligenten Agenten zu erschaffen, der sämtliche menschlichen Verhaltensformen aufweist. Soar wäre dann die lang gesuchte "einheitliche Kognitionstheorie" (Newell 1990), die alle bisherigen, unzusammenhängenden Theorien vereint.

Implementierung von Soar

Die oben genannten fünf primitiven kognitiven Prinzipien wurden in einem Computerprogramm implementiert (aktuelle Version: Soar Suite 9.0.0), das zum freien Download bereitsteht (s. u. Weblinks).

Funktionsweise von Soar

Soar bewegt sich während des Problemlöseprozesses von einem Anfangszustand hin zu einem von möglicherweise mehreren Zielzuständen. Jeder Zustand repräsentiert eine bestimmte Situation innerhalb des Problemraumes (z. B. der momentane Standort in einem Labyrinth). Auf jeden Zustand wird genau ein Operator angewandt, der einen neuen Zustand herbeiführt (z. B. führt Bewegung in einem Labyrinth zu einem neuen Standort). Dies geschieht solange, bis ein Zielzustand erreicht ist. Ein Problemraum muss also nie vollständig repräsentiert werden, sondern nur ein oder mehrere Zustände in ihm.

Ein in der Programmiersprache Soar geschriebenes Programm sieht z. B. so aus: (Kommentare werden mit # gekennzeichnet)

Quelltext	Kommentar
	# Produktionsregel 1:
sp { propose*hello-world	# Diese Regel schlägt vor, den Operator "hello-world" anzuwenden
(state <s> ^type state)	# Bedingung: WENN im Arbeitsspeicher ein Zustand <s> existiert, dann "feuert" die Regel (Aktion 1 und 2 werden ausgeführt)
→
(<s> ^operator <o> +)	# Aktion1: schlägt vor, auf den momentanen Zustand einen Operator <o> anzuwenden
(<o> ^name hello-world)}	# Aktion2: <o> bekommt den Namen "hello-world"
	.
	# Produktionsregel 2:
sp { apply*hello-world	# Diese Regel wird angewandt, wenn der Operator "hello-world" angewandt werden soll
(state <s> ^operator <o>)	# Bedingung1: Ein Operator <o> wurde ausgewählt
(<o> ^name hello-world)	# Bedingung2: <o> hat den Namen "hello-world"
→
(write |Hello World|)	# Aktion1: gib "Hello World" aus
(halt) }	# Aktion2: Halte Problemlöseprozess an

Wenn dieses Programm geladen wird, werden die zwei Produktionsregeln dem Produktionsspeicher (dauerhaftes Wissen) hinzugefügt. Erzeugt man jetzt auch einen Agenten und startet ihn, gibt der Agent "Hello World" aus und hält dann an. Ohne das Programm ist Soar nur eine Architektur ohne Problemlösefähigkeiten. Komplexere Programme könnten zum Beispiel menschliche kognitive Fähigkeiten modellieren (s. o.).

Wenn ein Agent gestartet wird, durchläuft Soar einen Zyklus:

1. Input (optional)
   • neue Sensordaten über die Umwelt werden in den Arbeitsspeicher aufgenommen
2. Operator-Vorschläge
   • Produktionsregeln testen, ob der Arbeitsspeicher (mit dem aktuellen Zustand) bestimmte Bedingungen erfüllt
   • Im Beispiel oben ist dies Produktionsregel 1
   • Ist dies der Fall, schlagen die Regeln vor, einen bestimmten Operator anzuwenden (sie "feuern")
3. Operator-Vergleich
   • Allen Operator-Kandidaten wird eine Präferenz zugeordnet
4. Operator-Selektion
   • 1. Fall: Ein Operator hat eine höhere Präferenz als alle anderen, weiter mit Schritt 5.)
   • 2. Fall: Es kann nicht genau ein Operator ausgewählt werden (engl.: Impasse, dt.: Sackgasse)
     • → es wird ein Substate (Zwischenzustand) erstellt, mit eigenem Zielzustand
     • → Ziel ist es nun, die Sackgasse aufzulösen, z. B. durch Versuch und Irrtum (neuer Zyklus) oder Frage an den Benutzer
5. Operator-Anwendung
   • Alle passenden Produktionsregeln werden angewandt, dies kann einen neuen Zustand herbeiführen oder den Zyklus beenden
   • Im Beispiel oben ist dies Produktionsregel 2
6. Output (optional)
   • Kommandos werden an die Umwelt weitergeleitet
7. Mache weiter mit Schritt 1.)

Im Falle des oben angegebenen Programms wird dieser Zyklus nur einmal durchlaufen, es gibt aber auch komplexere Programme.

Arbeitsspeicher

Hier werden der momentane Zustand, der momentane Operator und eventuelle Substates als sogenannte WMEs (Working Memory Elements) gespeichert. Ein WME besteht aus einem Identifier (z. B. Operator1), einem Attribut (z. B. ^name) und einem Wert (z. B. "hello-world"). Alle WMEs mit demselben Identifier werden zu einem "Objekt" zusammengefasst. Der Wert eines Attributs kann eine Konstante oder der Identifier eines anderen Objektes sein.

Lernmechanismus Chunking

Wenn im Schritt 4.) des Entscheidungszyklus eine Sackgasse erreicht wird, muss diese aufgelöst werden (z. B. durch neuen Zyklus mit anderem Zielzustand). Kann die Sackgasse aufgelöst werden, so wird eine neue Produktionsregel kreiert, die man "chunk" nennt. Wird diese neue Regel dem Produktionsspeicher hinzugefügt, so tritt eine ähnliche Sackgasse in Zukunft nicht mehr auf, da die neue Regel eine Möglichkeit zur Auflösung der Sackgasse beinhaltet (z. B. die richtige Wahl des Operators).

Anwendungsgebiete von Soar

• Modellierung kognitiver Prozesse in der Kognitionswissenschaft und in der Künstlichen Intelligenz
• Vorhersagen menschlicher Performanz
• kommerzielle Version von Soar: "KB Agent" (Explore Reasoning Systems, Inc.)
• Soar als Roboterkontrollarchitektur
• TacAirSoar: Simulation gegnerischer Kampfpiloten in einer virtuellen Umgebung
• Simulation gegnerischer Spieler im Computerspiel "Quake II"

Geschichte von Soar

Zu Beginn der Entwicklung von Soar wurde komplett in Großbuchstaben als „SOAR“ geschrieben und stand für „State, Operator And Result“, denn in Soar ist Problemlösen stets die Suche im zugehörigen Problemraum, in dem auf einen Zustand ein Operator angewandt wird, um ein Resultat zu erhalten. Entwickelt wurde Soar zu Beginn der 1980er Jahre von Allen Newell, John Laird und Paul Rosenbloom.

Kritik

Kognitive Architekturen setzen voraus, dass alle kognitiven Prozesse auf wenige Prinzipien zurückzuführen sind (z. B. das "Feuern" von Regeln). Es soll jedoch Evidenzen geben, die eine Vielzahl hochspezialisierter, nicht untersuchbarer, neuroanatomisch festgelegter Funktionen nahelegen (z. B. Kolb, Wishaw 1990).

Literatur

• B. Kolb, I. Q. Wishaw: Fundamentals of human neuropsychology. 2. Auflage. New York 1996, ISBN 3-8274-0052-X.
• A. Newell: Unified theories of cognition. Cambridge 1990, ISBN 0-674-92099-6.
• J. F. Lehman, J. Laird, P. Rosenbloom: A Gentle Introduction to Soar. (ai.eecs.umich.edu, PDF-Datei; 113 kB)
• F. E. Ritter u. a.: Techniques for Modeling Human Performance in Synthetic Environments: A Supplementary Review. (ritter.ist.psu.edu, PDF-Datei; 241 kB)

Weblinks

• Soar-Homepage, Soar Suite 9.4.0 Download
• Überblick über kognitive Architekturen
• Geschichte von Soar