Der Bereich "künstliche Intelligenz" ist sicherlich einer der spannendsten und interessantesten seiner Art. Nun sollen auch ATARI-Anwender nahezu kostenfrei in den Genuß der näheren Betrachtung dieses Themengebietes kommen.

Der informierte Laie denkt bei 'KI' zumeist an LISP und PROLOG. Was das Fach sonst noch zu bieten hat, ist allerdings eher den Insidern bekannt. Jetzt tritt ein PD-Programm an, eine Brücke zu schlagen. Trotzdem eignet sich OBOLUS kaum für intellektuelle Quickies: Das saubere GEM-Programm läuft zwar unter MagiC-Mac so problemlos wie unter TOS. Und spezielle Installationen sind auch nicht notwendig. Aber "Learning by doing"? Man wird OBOLUS kaum so benutzen können, wie das xte neue Malprogramm: Beim Zeichnen wissen wir vorher, worum es eigentlich geht, so dass wir uns das Programm auch intuitiv aneignen können (sollten). Fehlt ein solches Vorwissen, muss man sich einarbeiten. Darf man das dem Neuen ankreiden? Eigentlich nicht, man muss nur wissen, worauf man sich einläßt:

Es geht um Tools zur Erzeugung wissensbasierter Expertensysteme, die als Quasi-Programme in etwa so kompetent sein sollten wie normale Experten. Diesen erteilt man Konstruktionsaufträge oder bittet sie um Rat, wenn man nicht weiter weiß.

Ein Expertensystemwerkzeug muss also Wissen erfassen und wiedergeben können. Ist dann auch ST-GUIDE so ein Werkzeug? Nein, denn aus Hypertexten muss der Leser selbst die richtigen Regeln heraussuchen und anwenden. Zu einem Expertensystem gehört dagegen immer eine Dialog- und Inferenzmaschine, die Fragen unmittelbar beantwortet. Also geht es um Datenbanksysteme? Ja und nein: Zwar wird auch dort logisch gefolgert, aber kaum ein kombinatorischer Suchraum skizziert, aus dem die richtige Struktur via Regelanwendung automatisch herausgesucht wird. Hier kommt die KI ins Spiel: Menschen sind weniger begnadete Rechner als geschickte Sucher.

Nochmals: ja und nein. Ja, weil Input evaluiert wird. Nein, weil ungewiß ist, wie die Regel abgearbeitet wird: Sicher ist nur, dass bei wahrem IF das THEN nicht falsch und bei falschem THEN das IF nicht wahr wird. Nicht prozedurale Vorschriften sind gefragt, sondern deklarative Beschreibungen.

Angenommen, jedes Auto habe einen Motor, eine Batterie und einen Tank, die nicht leer sein dürfen, falls das Auto fährt. Das ist ein rudimentäres Wissen, aber als Beispiel reicht es:
OBOLUS erfaßt Teil-Ganzes-Strukturen; und nicht nur technische Objekte haben Komponenten. Vorgeschrieben ist, dass jedes Teil in einem System einen Zweck erfüllt. So wird die kombinatorische Vielfalt über Zweckvarianten (Objekte) und die je konstitutiven Zwecksysteme rekursiv aufgebaut: tiefere Zwecksysteme werden auch wieder von Varianten erfüllt ( ....): ein Auto hat stets etwas, das es antreibt. Und das kann u.a. ein Motor sein. Was sich kompliziert anhört, wird im Purpose-Net intuitiv deutlich: Vielleicht nehmen wir die Welt wirklich so wahr. Immerhin bieten sich Ergänzungsvorschläge fast wie von selbst an: Sie werden über die Knowledge-Kolumne realisiert.

Diese werden über die Pattern-Kolumne definiert. Danach stellt man eine Eigenschaftskombination im Featurebuffer zusammen und schiebt sie auf die Variante. Dadurch wird ihre Ist-Ein-Taxonomie automatisch um alle relevanten Begriffe erweitert. So bildet OBOLUS von sich aus z.B. den 'Dieselmotor', der 'laufende' und 'stehende' Dieselmotoren denotiert. Wer schon einmal IS-A-Hierarchien manuell verwaltet hat, wird diesen Service begrüßen.

Das hat seinen Preis: Die Automation erzwingt die permanente Restauration aller Fenster. Das merkt man je nach Gerät mehr oder weniger. Zudem kosten auch momentan ungenutzte Begriffe Speicher. Zumindest wird man aber davor bewahrt, ganze Taxonomien selbst an neues Wissen anpassen zu müssen. Nun ist nicht jede Kombination in jedem Kontext zulässig. So setzt der laufende Motor eine passende Tankfüllung voraus. Solche Zusammenhänge werden über Events und Regeln formuliert:

Ein Event ist ein unbedingter Satz, der per Dialog über die Event-Rubrik aus dem Zwecknetz abgeleitet wird. Mit der Rule-Spalte werden verschiedene Events zu Wenn-Dann-Regeln verknüpft. Das gilt auch für negierte Sätze, die selbst im Modus-Tollens ausgewertet werden, ohne dass es zu nicht-monotonen Deduktionen käme. Und das ist keine triviale Leistung.

Neben Implikationen dürfen auch Berechnungs- und Vergleichsformeln eingesetzt werden. Die umgekehrt polnische Notation ist aber gewöhnungsbedürftig. Zudem würde es die Arbeit erleichtern, falls der bedingte oder bedingende Vergleich auch direkt realisiert werden könnte.

Die manuelle Einzeldeduktion ist dialogorientiert aufgebaut: Man wählt anhand der Suchraumstruktur solange Varianten und Eigenschaftskombinationen aus, bis das gewünschte Ergebnis konfiguriert ist. Das Angebot wird dabei den Regeln entsprechend automatisch begrenzt.
Die Find-All-Funktionen ermitteln dagegen automatisch alle möglichen Lösungen, sind aber, wie der Autor betont, vorsichtig einzusetzen: Wird hier die Speichergrenze berührt, geht das Ganze in einen undefinierten Zustand über, so dass sich OBOLUS während einer All-Deduktion gelegentlich aufhängt. Ist das wirklich unumgehbar? Aber zugegeben: alle Lösungen einsehen zu wollen, widerspricht der Konfigurationsidee; wichtig ist nur, dass es (bei ausreichendem Speicher) prinzipiell ginge.

OBOLUS ist ein stabiles GEM-Programm, das endlich mal wieder etwas wirklich Neues bietet. Die maus- und dialogorientierte Datenbearbeitung ist bequem, bedarf aber solider Kenntnisse. Und die Inferenzmaschine arbeitet erstaunlich schnell.
Wem eine langwierige Einarbeitung in ein System nicht Hegt, der wird hier nicht glücklich werden: Man muss sich einen ausführlichen deutschen Hypertext im ST-GUIDE-Format aneignen. Zudem gibt es eine Einführung mit großem Register. OBOLUS ist in der neuesten Version 1.01 mit allen Beispieldateien und Hypertexten im Rahmen unserer PD-Serie erschienen; die Einführung muss jedoch gesondert beim Autor geordert werden.
Gewiß weckt Neues neue Begehrlichkeiten, auch wenn wir die Vielfalt von OBOLUS hier nur anreißen konnten. Bemerkenswert ist jedenfalls, dass im ATARI-Bereich noch derartige Innovationen realisiert werden. Und wäre es nicht wirklich eine nette Idee, wenn es irgendwann nicht nur viele Hypertexte gäbe, die man zu Rate ziehen könnte, sondern auch eine Menge von Wissensbasen?

Programmautor:
Karsten Reincke
Schloßstraße 83
49080 Osnabrück