Entwurf von Wissenssystemen

Die meisten Unternehmen arbeiten mit mehreren, überlappenden, teilweise inkompatiblen Vokabularen für dieselben Konzepte. Derselbe Kunde wird in verschiedenen Systemen in unterschiedlichen Formaten erfasst; dasselbe Produkt wird von Vertrieb und Betrieb unterschiedlich klassifiziert; dasselbe Risiko wird von Handel und Compliance in inkompatibler Sprache beschrieben. Eine Ontologie ist das explizite, vereinbarte Modell dieser Konzepte – was als Instanz zählt, welche Attribute obligatorisch sind, wie Konzepte zusammenhängen – und sie ist die Grundlage, auf der nachgelagerte Wissenssysteme aufbauen.

Wir entwerfen Ontologien pragmatisch statt philosophisch. Ziel ist nicht eine perfekte Darstellung der Welt, sondern eine nützliche Darstellung des Teils der Welt, auf dem das System arbeitet. Wir beginnen mit den Abfragen, die das System beantworten muss, und den Entscheidungen, die es unterstützen muss, und modellieren nur die Konzepte und Beziehungen, die diese Abfragen erfordern, mit explizitem Raum für Erweiterungen, wenn neue Anwendungsfälle entstehen.

Standards — schema.org, FIBO, SNOMED CT, GS1, branchenspezifische Referenzmodelle — werden wiederverwendet, wo sie passen, angepasst, wo sie fast passen, und ignoriert, wo sie nicht passen. Das Risiko, von einer leeren Leinwand aus zu beginnen, ist größer als das Risiko, die angesammelte Komplexität zu übernehmen, aber das Gegenteil ist am langen Ende der Fall.

• Entwurf von Domänenontologien und Taxonomien
• Wiederverwendung und Anpassung von Standards
• Semantische Datenintegration
• Referenzdatenmanagement
• Versionierungs- und Evolutionsstrategie
• Tools für Governance und Überprüfung

Ein Wissensgraph realisiert eine Ontologie anhand realer Daten. Kunden, Produkte, Lieferanten, Transaktionen, Ereignisse und die Beziehungen zwischen ihnen werden zu einer verbundenen, abfragbaren Struktur, auf die nachgelagerte Systeme — Suche, Empfehlung, Betrugserkennung, Compliance, Generative-KI-Fundierung — vertrauen können. Der Wert liegt nicht im Graphen selbst, sondern in den Produkten, die er ermöglicht.

Wir erstellen Wissensgraphen in den für die Arbeitslast geeigneten Technologien — Neo4j, Amazon Neptune, JanusGraph, AnzoGraph, native RDF-Speicher oder Property-Graph-Schichten über relationalen Data Warehouses, wo sie besser passen. Wir achten genau auf die Entitätsauflösung, da ein Graph, in dem dieselbe reale Entität als mehrere Knoten erscheint, schlechter ist als gar kein Graph, und wir implementieren Continuous-Integration-Praktiken, damit der Graph sich mit den vorgelagerten Daten und der Ontologie vorhersehbar weiterentwickelt.

Wo der Anwendungsfall es erfordert, erweitern wir den Graphen um Embedding-basierte Darstellungen, die Ähnlichkeitssuche, Empfehlungen und die Art der semantischen Abfrage unterstützen, die große Sprachmodell-Anwendungen erdet, ohne dass diese Modelle alles speichern müssen. Die Kombination aus strukturiertem Graphen und gelernten Embeddings ist ungewöhnlich mächtig und zunehmend Mainstream.

“Der Graph selbst ist selten das Ergebnis. Die Produkte, die er ermöglicht, sind es.”

Wo Entscheidungen durch komplexe Richtlinien — Berechtigung, Preisgestaltung, Risikoklassifizierung, behördliche Einhaltung, klinische Pfade — geregelt werden, sind reine statistische Modelle das falsche Instrument. Die Richtlinienlogik lässt sich am besten als Richtlinienlogik ausdrücken: als lesbare Regeln, strukturierte Entscheidungstabellen und Inferenz-Engines, die aus Fakten und einem Regelsatz Konsequenzen ableiten können. Das Ergebnis ist ein System, dessen Verhalten vollständig nachvollziehbar ist und das von Fachexperten ohne erneutes Training eines Modells aktualisiert werden kann.

Wir setzen moderne Entscheidungsmanagementplattformen (Camunda DMN, Drools, Werkzeuge für Entscheidungsmodelle und Notation) ein, wo sie zum Anwendungsfall passen, und maßgeschneiderte Regelwerke, wo dies nicht der Fall ist. Wir legen besonderen Wert auf den redaktionellen Prozess: wer eine Regel ändern kann, mit welcher Überprüfung, mit welchen Tests gegen historische Fälle und mit welchem schrittweisen Rollout. Ohne diesen Prozess verfallen Regelwerke schnell zu unleserlichen Ansammlungen.

Hybride Architekturen kombinieren das Beste aus beiden Welten. Ein neuronales Modell übernimmt die Wahrnehmung oder Mustererkennung, wo Regeln nicht geschrieben werden können; ein Regelwerk kümmert sich um die Einhaltung von Richtlinien und die endgültige Entscheidungsfindung, wo Regeln existieren. Die neuronale Komponente liefert Eingaben an das Regelwerk – extrahierte Entitäten aus einem Dokument, eine kalibrierte Wahrscheinlichkeit, eine Klassifizierung – und das Regelwerk trifft eine Entscheidung, die gegen jede Prüfung verteidigt werden kann. Wir entwerfen diese Architekturen explizit, mit einer klaren Trennung zwischen Lern- und Schlussfolgerungskomponenten und expliziten Schnittstellen zwischen ihnen.

Erklärbarkeit ist keine Funktion, die man einem Modell nachträglich hinzufügt. Sie ist eine Eigenschaft der gesamten Architektur. Wissensbasierte Systeme sind konstruktionsbedingt erklärbar: Jede Entscheidung ist das Ergebnis von Fakten und Regeln, die überprüft werden können, und die Erklärung ist eine direkte Spur der Inferenzkette und keine nachträgliche Rekonstruktion.

Wo maschinell gelernte Komponenten Teil des Systems sind, koppeln wir sie mit Erklärungs-Tools, die für die Modellklasse geeignet sind – Feature-Attribution für tabellarische Modelle, Aufmerksamkeits- und Begründungsextraktion für Sequenzmodelle, prototypenbasierte Erklärung für Bildmodelle – und wir zeigen diese Erklärungen neben der Systemausgabe in einer Sprache an, mit der ein Fachexperte arbeiten kann. Ziel ist es nicht, das Modell abstrakt interpretierbar zu machen; es geht darum, dem menschlichen Prüfer die Beweise zu liefern, die er benötigt, um die Empfehlung des Systems zu überstimmen oder zu akzeptieren.

Wir arbeiten eng mit Risiko- und Compliance-Abteilungen zusammen, um die Standards zu definieren, die Erklärungen erfüllen müssen, und wir testen diese Standards anhand tatsächlicher Fälle als Teil der Abnahme. Eine Erklärung, die einen Datenwissenschaftler zufriedenstellt, aber einen Fallmanager verwirrt, ist nicht ausreichend.

Wissenssysteme erfordern kontinuierliche Pflege. Ontologien entwickeln sich mit dem Geschäft weiter; Graphen benötigen Entitätsauflösungs-Wartung, wenn neue Quellen verbunden werden; Regelwerke müssen bereinigt, dedupliziert und anhand tatsächlicher Ergebnisse überprüft werden. Wir entwerfen das Betriebsmodell parallel zur Technologie: die redaktionellen Rollen, den Überprüfungszyklus, den Änderungskontrollprozess, die Leistungsüberwachungs-Dashboards. Das Ergebnis ist ein System, dessen Halbwertszeit in Jahren, nicht Monaten, gemessen wird.

Viele unserer Implementierungen sind mit Managed Services gekoppelt, die diese laufende Pflege übernehmen, insbesondere in den ersten Jahren, bevor die internen Teams des Kunden die Praktiken übernommen haben. Wir freuen uns gleichermaßen, wenn Kunden die Betriebsverantwortung sofort übernehmen; das Design berücksichtigt beides.