Wissensmodelle validieren: Regeln und Zusammenhänge kontrolliert prüfen

Wissensmodelle zu validieren heißt, ihre Eignung gezielt zu prüfen

Validierung beginnt deshalb nicht mit einem einzelnen Prüfwerkzeug. Zuerst wird festgelegt, wofür das Modell verwendet werden soll und welche Fehler dabei relevant wären. Ein Modell zur Einordnung von Chargenzuständen benötigt andere Prüfungen als ein Modell, das Rollen, Berechtigungen oder Materialbeziehungen beschreibt.

Technische Verfahren können dabei sehr viel leisten. Die Shapes Constraint Language SHACL wurde vom World Wide Web Consortium ausdrücklich dafür standardisiert, RDF-Graphen gegen definierte Bedingungen zu validieren.^[1] Ob diese Bedingungen fachlich die richtigen sind, muss jedoch weiterhin von den zuständigen Menschen begründet und geprüft werden.

Das Prüfziel bestimmt, welche Qualität erforderlich ist

Vor der Validierung steht eine präzise Zweckbeschreibung. Sie benennt die Entscheidungen oder Aufgaben, die das Modell unterstützen soll, die betroffenen Objekte und Rollen, die zulässigen Datenquellen und die Folgen eines fehlerhaften Modellergebnisses. Daraus entstehen prüfbare Anforderungen.

Für ein Modell zur Chargenfreigabe kann beispielsweise verlangt werden, dass jede Charge einem Produkt, einer Herstellungsfassung, einem Status und einer verantwortlichen Freigaberolle zugeordnet ist. Für ein Kontextmodell einer Arbeitsanweisung kann entscheidend sein, dass Anlage, Prozessphase, Materialzustand und gültige SOP gemeinsam betrachtet werden.

Ein allgemeines Qualitätsurteil wie „Das Modell ist gut“ reicht nicht. Die Forschung zur Ontologiequalität unterscheidet mehrere Merkmale und Messgrößen, weil strukturelle Qualität, funktionale Eignung und Verständlichkeit nicht auf denselben Wert reduziert werden können.^[5] Ein Modell kann logisch konsistent und dennoch für die betriebliche Aufgabe ungeeignet sein.

Prüffall: Eine Empfehlung widerspricht der Vorgabe

Ein fiktives Modell soll zusätzliche Inprozessprüfungen vorschlagen. Für Testfall T-04 gilt eine ausdrücklich angenommene Prüfvorschrift: Ein dokumentierter Gerätewechsel bei ansonsten erfüllten Bedingungen soll für sich allein keine Zusatzprüfung auslösen. Das ist eine Testvorgabe dieses Beispiels, keine allgemeine Aussage über Gerätewechsel.

Das erwartete Ergebnis lautet deshalb „keine Zusatzprüfung allein wegen Gerätewechsel“. Beobachtet wird jedoch eine Empfehlung zur Zusatzprüfung. Obwohl die Eingaben vollständig und syntaktisch gültig sind, weicht das fachliche Ergebnis vom Soll ab. Der Bericht hält die verwendete Modellfassung, den Testfall und diese Abweichung fest.

Eine mögliche begrenzte Verwendung schließt Situationen mit Gerätewechsel aus. Dafür muss die Anwendung solche Situationen zuverlässig erkennen und an die vorgesehene fachliche Prüfung weitergeben. Diese Abgrenzung und die weiterhin zugelassenen Fälle werden gesondert getestet. Der ursprüngliche Fehler bleibt zur Bearbeitung offen.

Aus den Ergebnissen folgt noch keine automatische Freigabe. Die Verantwortlichen bewerten, ob der begrenzte Einsatz mit seinen verbleibenden Risiken vertretbar ist. Nur auf diesen dokumentierten Bereich kann sich eine entsprechende Entscheidung beziehen.

Vier Prüfebenen machen unterschiedliche Fehler sichtbar

Für die folgende Prüfung werden vier Ebenen unterschieden. Diese Gliederung ist eine Arbeitshilfe, kein vollständiger Prüfstandard. Die formale Ebene prüft, ob die Daten syntaktisch lesbar und die verwendeten Datentypen korrekt sind. Die strukturelle Ebene untersucht, ob erforderliche Eigenschaften, Kardinalitäten und Beziehungen vorhanden sind.

Die logische Ebene fragt, ob sich Aussagen widersprechen oder unerwünschte Schlussfolgerungen ergeben. Die fachliche Ebene prüft schließlich, ob Begriffe, Regeln und Ergebnisse mit der vorgesehenen betrieblichen Wirklichkeit übereinstimmen.

Diese Ebenen ergänzen sich, ersetzen einander aber nicht. Ein bestandener SHACL-Test kann zeigen, dass eine Charge genau einen Status besitzt. Er beweist nicht, dass der erfasste Status fachlich richtig ist. Ein logischer Reasoner kann einen Widerspruch zwischen Klassen erkennen. Er weiß nicht ohne fachliche Vorgabe, ob die modellierte Klassifikation für den Produktionsprozess angemessen ist.

Reale Testfälle zeigen, ob das Modell für seine Aufgabe taugt

Struktur- und Logiktests sollten durch konkrete Fachfälle ergänzt werden. Dazu gehören typische Abläufe, bekannte Grenzfälle, bewusst fehlerhafte Eingaben und seltene Situationen mit hoher Auswirkung. Für jeden Fall wird vorab festgelegt, welches Ergebnis oder welche Reaktion erwartet wird.

Ein Wissensmodell für Materialfreigaben sollte beispielsweise erkennen, dass ein gesperrtes Material nicht als verfügbar behandelt werden darf. Es muss zugleich einen zulässigen Sonderfall abbilden können, in dem eine Probe für eine ausdrücklich dokumentierte Untersuchung entnommen wird. Nur der Normalfall würde diese Differenz nicht prüfen.

Gegenbeispiele sind besonders wichtig. Sie untersuchen, ob eine Regel zu weit greift. Wenn alle bekannten positiven Fälle richtig eingeordnet werden, kann das Modell trotzdem unbrauchbar sein, weil es zahlreiche nicht passende Fälle ebenfalls akzeptiert. Positive und negative Tests müssen deshalb gemeinsam betrachtet werden.

Strukturregeln machen erwartete Modellzustände maschinenprüfbar

SHACL trennt den zu prüfenden Datengraphen von einem Shapes-Graphen, der Bedingungen beschreibt. Solche Bedingungen können etwa festlegen, welche Eigenschaft vorhanden sein muss, wie viele Werte zulässig sind, welchen Datentyp ein Wert besitzt oder zu welcher Klasse ein verbundenes Objekt gehören soll.

Für ein betriebliches Wissensmodell könnte eine Shape verlangen, dass jede freigegebene Arbeitsanweisung genau eine Versionskennung, ein Freigabedatum und eine zuständige Rolle besitzt. Eine weitere Bedingung könnte sicherstellen, dass ein Messwert mit Einheit, Zeitpunkt und Messobjekt verbunden ist. Verstöße erscheinen in einem Validierungsbericht und lassen sich gezielt bearbeiten.

Strukturregeln sind besonders wertvoll, wenn Wissen aus mehreren Quellen zusammengeführt wird. Sie machen implizite Erwartungen explizit. Gleichzeitig besteht die Gefahr, nur jene Fehler zu finden, für die bereits eine Bedingung formuliert wurde. Eine unvollständige Shape-Sammlung kann daher ein scheinbar sauberes Ergebnis erzeugen, obwohl fachlich wichtige Anforderungen fehlen.

Logische Konsistenz prüft Beziehungen und Schlussfolgerungen

Ontologien können Klassen, Eigenschaften, Hierarchien und logische Einschränkungen formal ausdrücken. OWL 2 stellt dafür eine standardisierte Sprache bereit und erlaubt es, aus expliziten Aussagen weitere Aussagen abzuleiten.^[2]

Eine Konsistenzprüfung kann beispielsweise erkennen, dass ein Objekt gleichzeitig zwei ausdrücklich unvereinbaren Klassen zugeordnet wurde. Davon zu unterscheiden ist die Erfüllbarkeit einer Klasse: Sind ihre Bedingungen nicht gemeinsam erfüllbar, kann sie keine Instanzen besitzen. Eine solche Klasse macht die gesamte Ontologie nicht schon inkonsistent. Ein Widerspruch entsteht, wenn die Ontologie zugleich verlangt, dass dieser Klasse eine Instanz angehört.^[6]

Doch auch logische Widerspruchsfreiheit ist nur eine Qualitätsdimension. Ein konsistentes Modell kann falsche Annahmen enthalten oder wichtige Ausnahmen nicht beschreiben. Außerdem arbeitet die offene Welt vieler semantischer Modelle anders als klassische Datenbankprüfung: Eine fehlende Aussage bedeutet nicht automatisch, dass ihr Gegenteil gilt. Validierungsregeln müssen diese Modellannahme berücksichtigen.

Die Anforderung muss auf ihre Grundlage zurückführbar sein

Bei Testfall T-04 muss die angenommene Prüfvorschrift die erwartete Reaktion tatsächlich tragen. Eine angegebene Quelle hilft wenig, wenn ihre Fassung unklar ist oder ihre Aussage bei der Modellierung verändert wurde. Die Prüfung verfolgt deshalb die Verbindung von der Anforderung zur konkreten Grundlage.

Data Provenance beschreibt solche Herkunftsbeziehungen. PROV-O kann die beteiligten Entitäten, Aktivitäten und Akteure ausdrücken.[3] Für das Prüfurteil bleibt zusätzlich zu bewerten, ob die Übertragung fachlich zutrifft.

Fachliche Prüfung braucht mehr als Zustimmung

Fachverantwortliche sollten ein Modell nicht nur vollständig durchlesen und pauschal freigeben. Wirksamer sind klar abgegrenzte Prüffragen: Sind die verwendeten Begriffe eindeutig? Fehlen relevante Ausnahmen? Entspricht die Regel der aktuellen SOP? Wird eine beobachtete Korrelation fälschlich als Ursache dargestellt? Ist der Geltungsbereich enger oder weiter als die zugrunde liegende Evidenz?

Unterschiedliche Rollen können dabei verschiedene Fehler erkennen. Ausführende Personen kennen praktische Sonderfälle und missverständliche Begriffe. Qualitätssicherung und fachliche Leitung beurteilen Anforderungen, Risiken und Freigabebedingungen. Technische Prüfer untersuchen Struktur, Verarbeitung und reproduzierbare Testergebnisse.

Widersprechende Bewertungen sollten nicht durch Mehrheitsentscheidung verschwinden. Sie markieren eine ungeklärte Annahme. Das Modell bleibt an dieser Stelle entweder eingeschränkt, erhält eine dokumentierte offene Frage oder wird erst nach einer weiteren Untersuchung freigegeben.

Aus Prüfergebnissen eine Einsatzentscheidung ableiten

Ein Prüfbericht dokumentiert Gegenstand, Verfahren, Ergebnisse und offene Abweichungen. Die Einsatzentscheidung bewertet diese Befunde für einen bestimmten Zweck. Sie kann die Verwendung erlauben, begrenzen oder ablehnen. Bericht und Entscheidung sind miteinander verbunden, aber nicht dasselbe.

Bei einem eingeschränkten Einsatz muss der zulässige Bereich praktisch erkennbar und durchsetzbar sein. Ein Hinweis im Bericht genügt nicht, wenn die Anwendung ausgeschlossene Fälle weiter wie gewöhnliche Fälle verarbeitet. Im Beispiel gehört die zuverlässige Erkennung eines Gerätewechsels deshalb zur Prüfung der Einschränkung.

Ändert sich die Fassung, sind die Auswirkungen auf bestehende Prüfergebnisse zu bewerten. Das NIST AI RMF betrachtet Bewertung im Lebenszyklus von KI-Systemen.[4] Die Übertragung dieser Lebenszyklusperspektive auf andere Wissensmodelle ist hier eine fachliche Einordnung, keine vom Framework vorgegebene allgemeine Validierungsnorm.

Im Betrieb muss die Gültigkeit weiter beobachtet werden

Ein Modell kann zum Freigabezeitpunkt geeignet sein und später an Gültigkeit verlieren. Neue Produkte, Anlagen, Materialien, SOPs oder regulatorische Anforderungen verändern den Kontext. Deshalb gehören Beobachtungen aus der tatsächlichen Anwendung zur fortlaufenden Validierung.

Warnsignale sind beispielsweise ungewöhnlich viele manuelle Abweichungen, wiederkehrende Rückfragen, häufige Überschreibungen einer Empfehlung oder Fälle, für die keine passende Modellkategorie existiert. Diese Signale beweisen keinen Modellfehler. Sie eröffnen eine gezielte Prüfaufgabe.

Auch technische Änderungen können eine erneute Prüfung auslösen. Wird eine Datenquelle ersetzt, ein Transformationsschritt geändert oder eine neue Ontologie eingebunden, muss geprüft werden, ob bisherige Struktur- und Bedeutungsannahmen weiterhin gelten.

Validierung ist mehr als Versionierung oder ein Syntaxcheck

Versionierte Wissensmodelle erhalten, welche Modellfassung wann galt, wodurch sie verändert wurde und für welchen Bereich sie freigegeben ist. Validierung beantwortet eine andere Frage: Ist genau diese Fassung für den vorgesehenen Zweck geeignet und erfüllt sie die festgelegten Anforderungen?

Auch ein technisch gültiges Dokument ist nicht automatisch ein valides Wissensmodell. Eine Datei kann korrektes RDF oder JSON-LD enthalten und dennoch einen falschen Begriff verwenden, eine notwendige Beziehung auslassen oder eine Regel auf den falschen Geltungsbereich anwenden. Syntaxprüfung erkennt, ob die Darstellung formal lesbar ist. Struktur-, Logik- und Fachprüfung untersuchen erst danach, was dargestellt wird.

Umgekehrt muss nicht jedes fachlich unvollständige Modell sofort fehlerhaft sein. Kein Modell bildet die gesamte Wirklichkeit ab. Entscheidend ist, ob die bewusste Begrenzung zum konkreten Verwendungszweck passt und für die Nutzer erkennbar bleibt.

Was eine bestandene Validierung nicht garantiert

Eine bestandene Validierung beweist nicht, dass ein Wissensmodell in jeder zukünftigen Situation richtig arbeitet. Sie zeigt, dass die geprüfte Fassung die festgelegten Anforderungen und Tests für einen dokumentierten Zweck erfüllt hat.

Automatisierte Prüfungen finden nur Fehler, die durch Regeln oder erwartete Ergebnisse erfassbar sind. Fachliche Prüfer können ihrerseits Annahmen übersehen oder denselben blinden Fleck teilen. Auch umfangreiche Testfälle bilden niemals alle möglichen Betriebssituationen ab.

Validierung ersetzt außerdem keine Verantwortung im konkreten Prozess. Ein freigegebenes Modell kann Informationen strukturieren, Zusammenhänge prüfen und Handlungsoptionen unterstützen. Die fachliche Entscheidung an festgelegten Prüf- und Freigabepunkten bleibt bei den berechtigten Menschen.

Die Abweichung gehört zum Ergebnis

T-04 liefert einen verwertbaren Befund gerade dadurch, dass Soll und Ist auseinanderfallen. Eine technisch fehlerfreie Verarbeitung darf diesen Widerspruch nicht überdecken. Ebenso wenig darf ein eingeschränkter Einsatz den nicht bestandenen Fall aus der Dokumentation entfernen.

Ein tragfähiges Prüfurteil benennt, was untersucht wurde, welche Anforderungen erfüllt sind und wo Grenzen bestehen. Damit wird die Einsatzentscheidung überprüfbar – und eine spätere Änderung kann gezielt an den noch offenen Fragen ansetzen.