Vom Erfahrungswissen zum Expertensystem
Fachwissen wird nicht dadurch automatisierbar, dass man es vollständig aufschreibt. Es wird nutzbar, wenn Entscheidungen, Beispiele, Grenzen und Ausnahmen prüfbar zusammenspielen.

Erfahrene Menschen erkennen oft früh, dass etwas nicht stimmt. Sie sehen eine unstimmige Zahl, hören eine riskante Formulierung oder merken, dass ein Fall nicht in die übliche Kategorie passt. Dieses Urteil wirkt manchmal intuitiv, ist aber selten grundlos. Dahinter liegen beobachtete Muster, Ausnahmen, Folgen und über Jahre geschärfte Prioritäten. Ein Expertensystem beginnt nicht mit dem Versuch, eine Person zu kopieren. Es beginnt damit, einen begrenzten Ausschnitt dieser Entscheidungsarbeit sichtbar und überprüfbar zu machen.
Erfahrung ist mehr als eine Sammlung von Regeln
Fachleute handeln nicht wie ein starres Wenn-dann-Programm. Sie berücksichtigen Reihenfolge, Kontext und Wechselwirkungen. Eine Regel, die im Normalfall trägt, kann bei einer bestimmten Kundengruppe, einem fehlenden Nachweis oder einer hohen Schadensfolge ungeeignet sein. Deshalb scheitert Wissensautomatisierung, wenn sie nur einzelne Merksätze sammelt.
Erfahrung enthält mindestens vier Schichten: erkennbare Signale, eine begründete Regel, bekannte Ausnahmen und einen Maßstab für die Folgen eines Irrtums. Erst ihr Zusammenspiel erklärt, warum dieselbe Beobachtung in zwei Fällen zu unterschiedlichen Entscheidungen führen kann.
Das Ziel ist also keine vollständige Enzyklopädie des Fachgebiets. Gesucht wird ein kleiner Entscheidungsraum, dessen Eingaben, Regeln, Grenzen und Ergebnisse so klar sind, dass Fachleute ihn prüfen und andere Menschen ihn anwenden können.
Beginne mit einer Entscheidung, nicht mit einem Berufsbild
„Baue einen digitalen Experten“ ist kein bearbeitbarer Auftrag. Besser ist eine konkrete Frage: Ist dieses Briefing bereit für die nächste Phase? Welche von drei Kategorien passt zu diesem Fall? Welche Information fehlt vor einer Empfehlung? Ein guter Ausschnitt hat einen erkennbaren Auslöser und ein begrenztes Ergebnis.
Formuliere zunächst, wer die Entscheidung nutzt und welche Handlung davon abhängt. Danach werden die notwendigen Eingaben bestimmt. Alles, was interessant, aber nicht entscheidungsrelevant ist, bleibt außerhalb. Diese Begrenzung schützt vor einem System, das allgemein klingt und in keinem Fall zuverlässig hilft.
Auch das Ergebnis braucht eine feste Form. Es kann eine Einordnung mit Begründung, eine Liste fehlender Angaben, ein Risikosignal oder die Weitergabe an eine Fachperson sein. „Antwort erzeugen“ ist kein ausreichender Output. Das Ergebnis muss eine sinnvolle nächste Handlung ermöglichen.
Beispiele zeigen den Normalfall, Gegenbeispiele die Grenze
Eine Regel bleibt abstrakt, bis sie an Fällen sichtbar wird. Ein positives Beispiel zeigt Eingabe, relevante Beobachtung, angewandte Regel und begründetes Ergebnis. Es erklärt nicht nur, was entschieden wurde, sondern woran die Entscheidung hing.
Noch wertvoller sind Gegenbeispiele. Sie sehen dem Normalfall ähnlich, dürfen aber nicht zum gleichen Ergebnis führen. Vielleicht fehlt ein zwingender Nachweis, eine scheinbar kleine Ausnahme verändert das Risiko oder zwei Angaben widersprechen sich. Solche Fälle verhindern, dass ein System oberflächliche Ähnlichkeit mit fachlicher Gleichheit verwechselt.
Ein gutes Wissensmodul enthält deshalb mindestens einen typischen Fall, einen schwierigen Grenzfall und einen unzulässigen Fall. Der Grenzfall zeigt, wann zusätzliche Prüfung nötig ist. Der unzulässige Fall zeigt, wann das System stoppen muss. Erst diese Kontraste geben einer Regel Kontur.
Jede Regel braucht einen Gültigkeitsbereich
Regeln werden gefährlich, wenn sie ohne Bedingungen zirkulieren. Zu jeder Fachregel gehören Voraussetzungen: Für welche Situation, Datenqualität, Zielgruppe und Zeitspanne gilt sie? Welche Faktoren setzen sie außer Kraft? Wer darf eine Ausnahme bestätigen?
Der Gültigkeitsbereich muss nicht kompliziert formuliert sein. Oft reichen vier Felder: gilt wenn, gilt nicht wenn, unsicher wenn und erneut prüfen ab. Dadurch wird sichtbar, dass Wissen einen Zustand besitzt. Eine bewährte Regel kann durch neue Vorgaben, veränderte Produkte oder andere Rahmenbedingungen veralten.
Ausnahmen sollten nicht als Fußnote behandelt werden. Wenn eine Ausnahme häufig auftritt, ist sie möglicherweise eine eigene Fallklasse. Wenn sie selten, aber folgenreich ist, braucht sie ein deutliches Eskalationssignal. Das System wird nicht durch möglichst viele Regeln robust, sondern durch klare Übergänge zwischen Regel, Ausnahme und menschlichem Urteil.
Sprachmodell und deterministische Logik haben verschiedene Rollen
Sprachmodelle sind stark darin, unstrukturiertes Material zu lesen, Informationen zu extrahieren, Rückfragen zu formulieren und Begründungen verständlich darzustellen. Sie sind weniger geeignet, verbindliche Regeln jedes Mal exakt gleich anzuwenden oder allein zu beurteilen, ob eine harte Grenze überschritten wurde.
Eine belastbare Architektur trennt deshalb Interpretation und Entscheidung. Das Modell kann Angaben aus einem Text in ein festes Schema übertragen. Eine deterministische Regel prüft Pflichtfelder, Schwellenwerte oder unzulässige Kombinationen. Anschließend kann das Modell das Ergebnis erläutern – ohne die Regel heimlich neu zu erfinden.
Diese Trennung macht Fehler lokalisierbar. Wurde eine Information falsch extrahiert? War die Regel unvollständig? Oder war der Fall außerhalb des Gültigkeitsbereichs? Ein monolithischer Prompt vermischt diese Fragen. Ein kleines Expertensystem macht sie zu getrennten, prüfbaren Schritten.
Wissen braucht Herkunft, Version und Testfälle
Eine Fachregel ist nur so verlässlich wie ihre Grundlage. Deshalb sollte jede Regel eine Herkunft besitzen: Dokument, beobachtete Praxis, verantwortliche Entscheidung oder vorläufige Hypothese. Diese Kategorien sind nicht gleich stark und dürfen im System nicht gleich behandelt werden.
Änderungen brauchen Versionen. Wird eine Schwelle angepasst oder eine Ausnahme ergänzt, muss erkennbar bleiben, welche Fälle davon betroffen sind und welche Tests erneut laufen müssen. Ohne Versionierung kann ein System besser erscheinen, während niemand weiß, warum sich seine Ergebnisse verändert haben.
Testfälle bilden das Gedächtnis des Expertensystems. Sie halten fest, welcher Fall wie behandelt werden soll und warum. Jede relevante Fehlentscheidung sollte – anonymisiert und bereinigt – zu einem neuen Test oder einer klareren Grenze führen. So wächst das System aus überprüfter Erfahrung statt aus immer längeren Anweisungen.
Das System unterstützt Verantwortung, es übernimmt sie nicht
Ein Expertensystem kann Facharbeit zugänglicher und konsistenter machen. Es kann fehlende Angaben erkennen, Regeln zuverlässig anwenden und begründen, warum ein Fall eskaliert wird. Es darf jedoch nicht den Eindruck erzeugen, sein Output sei schon deshalb richtig, weil er formal aus Regeln entstanden ist.
Menschen bleiben für Auswahl, Aktualität und Folgen der Regeln verantwortlich. Sie entscheiden, welches Wissen aufgenommen wird, welche Fehler tolerierbar sind und welche Fälle niemals ohne Freigabe abgeschlossen werden dürfen. Auch ein transparentes System kann eine falsche oder überholte Regel konsequent anwenden.
Die beste Form des Expertensystems ist daher kein künstlicher Ersatz für Expertise. Sie ist eine lesbare Zusammenarbeit zwischen Erfahrung, formaler Prüfung und menschlichem Urteil. Sie macht sichtbar, wo Wissen trägt – und ebenso sichtbar, wo es endet.
Das Entscheidungsmodul
Ein kompaktes Modul hält eine begrenzte Fachentscheidung an einer Stelle prüfbar zusammen:
# ENTSCHEIDUNGSMODUL
**Entscheidungsfrage**
Welche begrenzte Frage soll beantwortet werden?
**Benötigte Eingaben**
Welche Angaben müssen vorliegen, welche Quelle gilt?
**Fachregel**
Wenn …, dann …, weil …
**Gültigkeitsbereich**
Gilt wenn … / gilt nicht wenn … / unsicher wenn …
**Beispiele**
Normalfall, Grenzfall und unzulässiger Fall.
**Deterministische Prüfung**
Welche Pflichtfelder, Schwellen oder Kombinationen werden fest geprüft?
**Eskalation**
Wann stoppt das System, wer entscheidet dann?
**Version und Tests**
Was wurde geändert, welche Fälle müssen erneut geprüft werden?Erfahrungswissen wird nicht kleiner, wenn es in Regeln, Fälle und Grenzen übersetzt wird. Es wird teilbar. Entscheidend ist, die Übersetzung nicht mit Vereinfachung zu verwechseln: Gute Systeme bewahren nicht jedes Detail einer Fachperson, sondern genau jene Unterschiede, an denen eine verantwortbare Entscheidung hängt.
Übungsblatt: Baue ein kleines Expertensystem
Wähle eine wiederkehrende Fachentscheidung mit überschaubaren Folgen. Entwickle kein vollständiges Produkt, sondern ein prüfbares Entscheidungsmodul.
1. Entscheidungsraum begrenzen. Formuliere eine Frage, eine Nutzergruppe und die nächste Handlung. Streiche alles, was für diese Entscheidung nicht benötigt wird.
2. Regel und Herkunft schreiben. Formuliere eine Wenn-dann-Regel mit Begründung. Kennzeichne, ob sie aus Quelle, Praxis, Entscheidung oder Hypothese stammt.
3. Drei kontrastierende Fälle bauen. Schreibe Normalfall, schwierigen Grenzfall und unzulässigen Fall. Erkläre, welches Detail jeweils die Entscheidung verändert.
4. Gültigkeit und Prüfung festlegen. Ergänze gilt wenn, gilt nicht wenn und unsicher wenn. Bestimme mindestens eine deterministische Kontrolle.
5. Eskalation und Test definieren. Formuliere zwei Stoppsignale, eine verantwortliche Rolle und die Testfälle, die nach jeder Änderung erneut laufen.
● Nur für Mitglieder
Lies den vollständigen Artikel und lade alle Dateien mit einer Mitgliedschaft herunter.
Vollständigen Artikel + Downloads freischalten → Abonnieren0 Kommentare
● Kommentare werden geladen…