Einige der erfolgreichsten Expertensysteme wie MYCIN [BS84] oder R1 [McD80] benutzen zur Wissensdarstellung einen Formalismus, der auf sogenannten Produktionsregeln beruht. Sie sind von der Form
wenn <Bedingungen> dann <Aktionen>
Der Zustandsraum wird durch den sogenannten Arbeitsspeicher repräsentiert, in dem die Beschreibung der Welt niedergelegt ist. Im Prinzip lassen sich hier alle bisher besprochenen Repräsentationsformalismen verwenden, nicht zuletzt also auch der Logikformalismus. OPS5 verwendet eine rahmenartige Form, mit der Konzepte durch Schlitze mit Namens- und Wertfacette (``Attribut''/``Wert'') beschrieben werden. Die Facettennamen oder Attribute werden mit einem Hochpfeil gekennzeichnet. Ein Beispiel eines solchen OPS5 Attribut-Wert-Elements ist das folgende.
Es genügt zum Verständnis, sich den Arbeitsspeicher als eine Menge (genauer eine Konjunktion) logischer Grundaussagen vorzustellen. Abbildung 2.27 zeigt die Illustration der Ausgangs- und Zielsituation in einer Klötzchenwelt sowie die Beschreibung dieser Problemstellung sowohl in der logischen als auch in der OPS5-Form. 
Abbildung 2.27: Ein Klötzchenweltproblem in logischer und OPS5-Darstellung
Der Produktionsspeicher enthält die Produktionsregeln, deren globale Form wir bereits beschrieben haben. <Bedingungen> ist eine Folge (oder Konjunktion) von einzelnen Bedingungselementen. Ein solches Element kann aus einem (durch Weglassen von Attribut-Wert-Paaren entstehenden) Teil eines Attribut-Wert-Elementes bestehen. Dabei können anstelle von konkreten Werten auch Variablen auftreten. Auch logische Operationen wie Negation, Konjunktion und Disjunktion sind in einer OPS5-spezifischen Form erlaubt (-- die Bemerkung ``warum einfach logische Formeln verwenden, wenn es auch komplizierter geht'' drängt sich einem beim genaueren Studium dieser OPS5-spezifischen Form auf).
Der Teil <Aktionen> in einer Produktionsregel besteht aus einer Folge von Aktionen, die jeweils aus dem Namen der jeweiligen Aktion und den zugehörigen Argumenten bestehen. Eine Aktion kann neue Elemente in den Arbeitsspeicher eintragen, alte löschen, in bestehenden Werte ändern, hinzufügen usw. Sie kann auch Werte an Variablen in der betreffenden Regel binden, so daß die gleiche Regel im weiteren Verlauf ein anderes Verhalten zeigen würde. Sie kann schließlich in den Kontrollablauf des Programmes eingreifen, diesen zum Beispiel abbrechen, einen Ausdruck veranlassen usw. Wie eben geschehen werden wir statt Produktionsregel im folgenden oft auch kurz Regel sagen. Man beachte jedoch, daß Regel im Sinne einer Produktionsregel zunächst verschieden von der üblichen Bedeutung einer logischen (Hornklausel-) Regel ist, bei welcher zunächst keinerlei Aktion intendiert ist. Zusammen mit einer prozeduralen Semantik verhält sich eine Hornklausel eines PROLOG Programmes jedoch schließlich doch genau so wie Produktionsregeln, so daß dann der Unterschied verschwindet.
Die beiden Regeln der Abbildung 2.27 illustrieren diese Sprachbeschreibung. Die erste
beschreibt die Aktion, ein oberstes Klötzchen, das nicht auf dem Tisch
liegt, dorthin zu legen, die zweite es, hier gegebenfalls auch vom Tisch aus,
auf ein anderes freies Klötzchen zu legen. Man beachte, daß die Operation
in der logischen Darstellung keine logische Implikation darstellt. Auf
diese Beziehung werden wir in Abschnitt 4.7 zu sprechen kommen.
Der Programmablauf schließlich gestaltet sich zu jedem Zeitpunkt (auch am Beginn) durch die zyklisch wiederkehrende Abfolge: Bedingungsprüfung oder Musterung (engl. matching), Regelselektion und Aktionsausführung. Sie ist in Abbildung 2.28 schematisch dargestellt.
Abbildung 2.28: Der Ausführungszyklus von OPS5
In der Bedingungsprüfung wird diejenige Teilmenge der Regeln im Produktionsspeicher durch eine Art Musterung (siehe unten) bestimmt, deren Bedingungen aufgrund der Einträge im Arbeitsspeicher erfüllt sind und die daher ausführbar sind. Diese Teilmenge wird etwas mißverständlich als Konfliktmenge bezeichnet.
Die Prüfung auf das Erfülltsein der Bedingungen ist eine rein deduktive Operation, in der festgestellt wird, ob die betreffende Bedingung logisch aus den Einträgen im Arbeitsspeicher folgt oder, anders ausgedrückt, ob sie zusammen mit einem Eintrag im Arbeitsspeicher eine unifizierbare Konnektion ergibt. Hierbei legen wir das Verständnis zugrunde, daß sowohl die Einträge im Arbeitsspeicher als auch die Bedingungen Repräsentationen logischer Formeln sind. Da der Arbeitsspeicher jedoch nur Grundaussagen enthält, benötigt man bei dieser deduktiven Operation nur eine eingeschränkte Form des Unifizierens, das wir Mustern (engl. matching) nennen. Eine erfolgreiche Musterung einer Bedingung besteht dabei in einer Belegung ihrer Variablen so, daß die Bedingung mit einer Aussage im Arbeitsspeicher identisch übereinstimmt. Im Gegensatz zur vollen Unifikation sind hier also Substitutionen von Termen für Variablen nur in einer der beiden konnektierten Formeln nötig.
Im Prinzip kann jede Regel in der Konfliktmenge nun zur Ausführung ausgewählt werden. Man wird jedoch versuchen, solchen Regeln den Vorzug zu geben, die das erstrebte Ziel eher zu erreichen versprechen. Konfliktlösungsstrategien sollen solche Versuche realisieren. Es sind die verschiedensten solcher Strategien zum Einsatz gebracht worden. Die wichtigsten sind die folgenden samt deren Kombinationen.
erfüllt. Nach ihrer
Ausführung könnten im zweiten Durchgang jedoch beide Regeln gefeuert
werden. Schon dieses einfache Beispiel illustriert, daß eine Auswahl nach
einer Reihenfolge oder nach syntaktischen Kriterien wenig Sinn macht. In
diesem Fall ist es allein die genannte antizyklische Meta-Regel, die die
zweite Regel mit ausschließt, und die gewünschte
Erfüllung von Zielbedingungen, die der zweiten Regel mit 
den
Vorzug gibt. Das Gleiche gilt im letzten Zug. Bei OPS5 wird die Zielsituation
explizit als Regel realisiert.
Wir haben die Abarbeitung der Regeln bisher in unserer Beschreibung nach der Methode der Vorwärtsverkettung (engl. forward-chaining oder forward-reasoning) durchgeführt. Ausgehend von dem Ausgangszustand des Arbeitsspeichers werden Regeln so lange angewandt, bis der Zielzustand erreicht ist. Man kann natürlich auch umgekehrt vom Zielzustand ausgehen und rückwärts verfolgen, welche Regeln diesen Zustand hergestellt haben könnten, solange bis der Ausgangszustand erreicht ist. Man spricht dann von einer Rückwärtsverkettung (engl. backward-chaining oder backward-reasoning). Auch Mischformen sind möglich. In unserem Beispiel würde die Ausführung der einzig möglichen Regel im Ausgangszustand sowie unabhängig davon die rückwärtige Ausführung der einzig möglichen Regel, die in den Endzustand führt, die beiden entstehenden Zustände einen Zug voneinander entfernt nahebringen, der dann leicht bestimmt werden kann.
Das Mustern der Regeln ist insbesondere bei größeren Systemen ein aufwendiger Prozeß; tatsächlich ist seine Lösung ein NP-vollständiges Problem (``multiple objects/multiple patterns matching problem''. Bisher haben wir diesen Prozess so beschrieben, daß er in jedem Zyklus voll durchgeführt wird. Dies ist ein äußerst redundantes Vorgehen. In [For82] wurde ein Algorithmus, genannt Rete, entwickelt, der sich dieser Redundanz weitestgehend entledigt. Rete hat offensichtlich auch für logische Inferenz für den Teil eine große Bedeutung, wo Inferenzschritte die Faktenbasis tangieren.
Rete macht sich einerseits zunutze, daß Teile der Bedingungen verschiedener Regeln ähnlich auftreten. Zum Beispiel können bei Nichterfülltsein einer Bedingung alle Regeln ausgeschlossen werden, die diese Bedingung mitenthalten. Die optimale Ausnutzung dieser Idee führt zu einer Darstellung der Regeln in Form eines Netzwerkes ineinander verschachtelter Bäume, deren innere Knoten Bedingungselemente der Regeln sind. Ein Zweig von der Wurzel zu einem Blatt listet hierbei genau alle Bedingungen einer Regel auf.
Eine zweite offensichtliche Verbesserung liegt in dem naheliegenden Gedanken, nach jedem Zyklus nur solche Regeln neu zu mustern, bezüglich derer sich im vorangegangenen Zyklus Änderungen im Arbeitsspeicher ergeben haben. Dies wird durch die eben beschriebene Netzstruktur in optimaler Weise unterstützt.
Produktionssysteme konzentrieren sich auf einen besonders wichtigen Aspekt bei der Wissensrepräsentation, bei dem es um die Darstellung von sich ändernden Situationen geht. Von Seiten der Logik wurde diese Problematik in [MH69] zum ersten Male (mittels eines zusätzlichen Zeitparameters) behandelt, worauf wir in Abschnitt 4.7 zurückkommen werden. Dort werden wir auch erweiterte Logiken kennenlernen, in denen Zeit und Veränderungen behandelt werden können. Auch in PROLOG ist mit dessen außerlogischen Sprachanteilen ein Produktionssystem leicht repräsentierbar. Danach werden die Produktionsregeln als PROLOG Regeln repräsentiert. Eine Aktion ist dann eine PROLOG Prozedur, dh. ein mittels weiterer Regeln definiertes Prädikat. Dem Arbeitsspeicher von OPS5 entsprechen dann die Fakten im PROLOG Programm und der aktuellen Bindungsumgebung, dh. den zu einem bestimmten Zeitpunkt vorhandenen Bindungen von Termen an Variable.
Ein weiterer Beitrag der Produktionssysteme ist der eben beschriebene Rete-Algorithmus. Die übrigen Details eines Systems wie OPS5 sind eher dazu geeignet, Verwirrung zu stiften, statt mehr Klarheit zu schaffen. Bezüglich eines Vergleichs von Produktionen als Berechnungsmodell mit dem der Rahmen sei erwähnt, daß in [Per88a] gezeigt worden ist, daß Konzeptrahmen und Produktionssysteme gegenseitig mit linearem Aufwand simulierbar sind, so daß von hier kein Argument für oder gegen beide Ansätze zu holen ist. Bei beiden spricht man übrigens von ``datengesteuerter Programmierung'', weil der Kontrollfluß durch die Struktur des Wissens bzw. der Daten gesteuert wird. Als historische Anmerkung sei noch erwähnt, daß Produktionssysteme ursprünglich in [Pos43] als allgemeinste Form eines Berechnungsmodelles eingeführt worden sind.
Christoph Quix, Thomas List, René Soiron
name