Wissensgraphen & Domänenontologie-Engineering

Ihre KI kann nicht über das nachdenken, was sie nicht kennt

Die Vektorsuche findet Dinge, die ähnlich klingen. Wissensgraphen finden Dinge, die wahr sind. Dieser Unterschied ist der Unterschied zwischen einem KI-System, das rät, und einem, das schlussfolgert.

Klinische Benchmarks machen dies greifbar: In ontologiestrukturierten Wissensgraphen verankerte LLMs reduzierten die Halluzinationsraten von 63 % auf 1,7 %, während rein vektorbasiertes Retrieval bei komplexen Wissensaufgaben bei etwa 70 % Genauigkeit stagniert, verglichen mit 85 %+ bei hybriden Ansätzen aus Vektor plus Graph (siehe unsere Forschung zu fundierter KI im Gesundheitswesen).

Die meisten Teams, die sich an Wissensgraphen versuchen, landen bei etwas ganz anderem: einem beschrifteten Property-Graphen in Neo4j ohne formale Semantik, ohne Inferenzfähigkeit und ohne Herkunftsnachverfolgung. Das ist eine Datenbank, kein Wissensgraph. Sie funktioniert, bis Sie Fragen beantworten müssen, die die Schema-Designer nicht vorhergesehen haben, eine KI-Ausgabe auf ihre Quellfakten zurückverfolgen möchten oder Ihr Domänenmodell weiterentwickeln müssen, ohne jeden nachgelagerten Verbraucher zu beeinträchtigen.

Unser Ansatz besteht darin, das Echte zu bauen: formale Ontologien mit Inferenz, produktive Graph-Infrastruktur mit Herkunftsnachweis auf Tripel-Ebene und Wartungs-Frameworks, die darauf ausgelegt sind, das Wissen aktuell zu halten, wenn sich Ihre Domäne unweigerlich ändert.

Property-Graph, RDF-Triple-Store oder beides: Die richtige Architektur wählen

Die Debatte Neo4j gegen RDF verschlingt mehr Entwicklungszyklen als nötig, meist weil die Entscheidung getroffen wird, bevor die Anforderungen verstanden sind.

Der Vorteil von RDF ist das automatisierte Schlussfolgern: Deklarieren Sie, dass jedes Medikament, das mit einem MAO-Hemmer interagiert, für SSRI-Patienten kontraindiziert ist, und der Reasoner leitet jede spezifische Kontraindikation ohne manuelle Aufzählung ab.

Unser Ansatz bevorzugt Hybridsysteme, bei denen die formale Ontologie für Schlussfolgern und Compliance in einem RDF-Store liegt, während ein Property-Graph Traversierungsabfragen übernimmt, wobei eine Synchronisierungsschicht sie konsistent hält. Ergänzen Sie Vektor-Embeddings (TransE, CompGCN oder Graph Neural Networks) für die semantische Ähnlichkeit, und Sie erhalten ein Retrieval-System, das exakte Übereinstimmungen, logische Inferenz und unscharfe Ähnlichkeit in einer Pipeline bewältigt.

Ontologie-Engineering: Der Teil, den alle unterschätzen

Eine Graphdatenbank zu kaufen ist einfach. Die Ontologie zu bauen, die sie nützlich macht, ist der Punkt, an dem Projekte ins Stocken geraten. Eine Domänenontologie ist eine formale Spezifikation dessen, was in Ihrer Domäne existiert, wie Dinge zusammenhängen und welche Einschränkungen diese Beziehungen regeln.

Dies richtig hinzubekommen erfordert zwei Arten von Fachwissen, die selten zusammen auftreten: tiefes Domänenwissen (was ein pharmazeutischer Regulierungsspezialist über IDMP-Substanzklassifikationen weiß) und formale Fähigkeiten zur Wissensrepräsentation (wie man dieses Wissen in OWL 2 DL ausdrückt, ohne Engpässe beim Schlussfolgern zu erzeugen), ausführlich beschrieben in unserem Whitepaper zu neuro-symbolic KI in einer regulierten klinischen Domäne.

Beginnen Sie mit Kompetenzfragen

Unser Ontologie-Engineering-Prozess beginnt mit Kompetenzfragen: den konkreten Abfragen, die der Wissensgraph beantworten können muss. Nicht vage Anforderungen wie „Arzneimittelsicherheitsanalyse unterstützen“, sondern präzise wie „Ermittle anhand der Medikamentenliste eines Patienten und eines neuen Rezepts alle transitiven Kontraindikationen über Interaktionen von Stoffwechselwegen innerhalb von 200 Millisekunden.“ Diese Kompetenzfragen bestimmen jede Modellierungsentscheidung und werden zur Regressionstest-Suite für die Ontologie-Evolution.

Den richtigen Formalismus wählen

Wir wählen den richtigen Formalismus für die jeweilige Aufgabe:

• OWL 2 DL – Domänen, die vollständiges Description-Logic-Schlussfolgern erfordern (Pharmazie, Recht, Regulierung).
• OWL 2 EL – große Ontologien, bei denen eine handhabbare Klassifikation zählt (SNOMED CT hat über 350.000 Konzepte und läuft in EL problemlos).
• SKOS – Taxonomien und kontrollierte Vokabulare, bei denen Sie Hierarchie und Bezeichnungen benötigen, aber keine logische Inferenz.
• SHACL – Constraints für Datenvalidierungsregeln, die neben der Ontologie stehen.

Die meisten Produktivsysteme verwenden mehrere Formalismen in Kombination, und zu wissen, welchen man wo anwendet, ist ein wesentlicher Teil dessen, was ein Engagement liefert.

Entitätsauflösung: Der 3-fache Budgetmultiplikator, mit dem niemand plant

Bevor ein Wissensgraph über Ihre Daten schlussfolgern kann, müssen diese Daten bereinigt, dedupliziert und verknüpft werden. Entitätsauflösung – festzustellen, dass „JPMorgan Chase“, „JP Morgan“, „JPMC“ und „J.P. Morgan Chase & Co.“ dieselbe Entität sind – klingt einfach und ist im Unternehmensmaßstab wirklich schwer.

Die Schwierigkeit vervielfacht sich bei heterogenen Quellen. Wissen aus 10 bis 15 verschiedenen Quellsystemen zusammenzuführen bedeutet, sich mit widersprüchlichen Schemata, unterschiedlichen Kennungskonventionen, schwankender Datenqualität und zeitlichen Inkonsistenzen auseinanderzusetzen (ein System sagt, das Unternehmen sei im Q3 übernommen worden, ein anderes sagt Q4). Teams unterschätzen die Kosten der Entitätsauflösung routinemäßig um das 3- bis 5-Fache.

Wir entwerfen Entitätsauflösungs-Pipelines, die regelbasiertes Matching, erlernte Ähnlichkeitsmodelle und menschliche Überprüfung (Human-in-the-Loop) für Grenzfälle kombinieren. Die Pipeline ist so konzipiert, dass sie einen kanonischen Entitätsgraphen mit Herkunftsverknüpfungen zu jedem Quelldatensatz ausgibt, sodass Sie stets nachvollziehen können, warum zwei Datensätze zusammengeführt oder getrennt gehalten wurden.

Diese Herkunftskette wird entscheidend für die regulatorische Nachverfolgbarkeit unter Rahmenwerken wie dem EU-KI-Gesetz, wo die Artikel 12–13 von Ihnen verlangen, den Verlauf der Daten nachzuweisen, die Hochrisiko-KI-Systeme speisen.

Warum Wissensgraph-Projekte scheitern (und wie man es vermeidet)

Das Fehlermuster der Branche ist gut dokumentiert: 95 % der GenAI-Pilotprojekte in Unternehmen scheitern, und Wissensgraph-Projekte haben ihre eigenen spezifischen Fehlerarten.

1. Die POC-Falle. Ein kleiner Proof-of-Concept gelingt mit einem kuratierten Datensatz und einem einfachen Schema, also gibt die Führung grünes Licht für den vollständigen Aufbau. Dann stellt das Team fest, dass reale Daten 10-mal unordentlicher sind, die Ontologie 50-mal mehr Konzepte benötigt und die Abfragemuster, für die sie optimiert haben, nur 30 % der tatsächlichen Anwendungsfälle abdecken. Unser Ansatz dimensioniert Engagements von Tag eins an rund um Produktivdatenstichproben und reale Abfragelasten.
2. Über-Axiomatisierung. Ontologie-Ingenieure mit akademischem Hintergrund fügen jedes mögliche Axiom und jede mögliche Einschränkung hinzu, und der Reasoner verlangsamt sich bei bescheidenen Wissensbasen von Sekunden auf Stunden. Wir profilieren die Reasoner-Leistung früh und kontinuierlich und wenden das Prinzip der minimalen Axiomatisierung an: Constraints nur hinzufügen, wenn sie einer bestimmten Kompetenzfrage dienen.
3. Ontologie-Drift. Der Wissensgraph geht in Betrieb, funktioniert gut, verschlechtert sich dann aber langsam, während sich die Domäne weiterentwickelt – SNOMED CT veröffentlicht vierteljährliche Updates, regulatorische Taxonomien verschieben sich, neue Produktkategorien entstehen, und niemand ist für die Wartung zuständig. Ein Engagement ist so dimensioniert, dass es Ontologie-Wartungs-Frameworks mit Änderungserkennung, Auswirkungsanalyse und Regressionstests hervorbringt, wobei jedes neue Konzept und jede neue Beziehung vor der Bereitstellung gegen die vollständige Kompetenzfragen-Suite validiert wird.
4. Keine Verantwortung auf Führungsebene. Wissensgraphen sind Infrastruktur – sie ermöglichen nachgelagerte KI-Fähigkeiten, erzeugen aber für sich genommen keine sichtbaren Funktionen. Ohne ein Sponsoring auf Führungsebene, das die Graphqualität mit Geschäftsergebnissen verbindet (weniger Halluzination, schnellere Compliance, bessere Erkennung von Arzneimittelwechselwirkungen), verliert das Projekt im zweiten Jahr die Finanzierung. Wir helfen Teams, den Business Case mit konkreten Kennzahlen aufzubauen, die an ihre spezifischen Anwendungsfälle geknüpft sind.

Wissensgraphen mit LLMs, RAG und agentic AI verbinden

Microsofts GraphRAG (und seine kostenreduzierte Variante LazyGraphRAG, die die Extraktionskosten auf 0,1 % des ursprünglichen Werts senkt) hat gezeigt, dass graphstrukturiertes Retrieval bei komplexen Multi-Hop-Abfragen besser abschneidet als rein vektorbasiertes. Aber produktives GraphRAG ist schwieriger, als die Paper vermuten lassen: Community-Detection erzeugt Retrieval-Artefakte, Extraktions-Pipelines brauchen domänenspezifisches Tuning, und es gibt keine integrierte Herkunftsnachverfolgung.

Wir entwerfen KG-gestütztes Retrieval, bei dem jeder abgerufene Fakt sein Quelltripel, seinen Konfidenzwert und seine zeitliche Gültigkeit mitführt. Wenn das LLM eine Aussage generiert, verifiziert das System sie gegen den Graphen und zitiert die konkreten Tripel, die sie stützen oder ihr widersprechen (siehe eine funktionierende Demo der Zitationsverifizierung gegen den Graphen). Bei Vektor-RAG ist „das Modell hat eine ähnliche Passage gefunden“ die stärkste Attribution, die Sie erhalten.

Wissensgraphen als agentenzugängliche Werkzeuge

Für agentic-AI-Architekturen dienen Wissensgraphen als werkzeugzugängliche Wissensquellen. Neo4j hat im April 2026 eine Wissensschicht für agentische Systeme auf Google Cloud eingeführt, und die Verbreitung des Model Context Protocol (MCP) beschleunigt sich als Konnektorstandard zwischen Agenten und Wissen.

Unser Ansatz besteht darin, Wissensgraphen zu bauen, die von Tag eins an agenten-abfragbar sind: SPARQL-Endpunkte, strukturierte APIs oder MCP-kompatible Schnittstellen, die es KI-Agenten ermöglichen, auf Domänenwissen als Werkzeugaufruf statt als Prompt-Injektion zuzugreifen – ein Ansatz, der ausführlich beschrieben ist in unserer Forschung zur Haftungs-Firewall für Unternehmens-KI-Agenten.

Was wir liefern

Jedes Engagement ist auf Ihre Domäne, Ihre Datenlandschaft und Ihre nachgelagerten KI-Anforderungen zugeschnitten. Zu den Lieferergebnissen gehören:

• Eine formale Domänenontologie (OWL, vollständig annotiert), validiert durch automatisierte Reasoner.
• Der befüllte Wissensgraph mit Ingestion-Pipelines für strukturierte und unstrukturierte Quellen.
• Entitätsauflösungs-Services mit vollständigem Herkunftsnachweis.
• SHACL-Constraint-Definitionen für die Datenvalidierung.
• Eine Kompetenzfragen-Testsuite (SPARQL- oder Cypher-Muster) als Regressionstests für die Ontologie-Evolution.
• Integrationsschnittstellen für RAG, LLM-Grounding oder Werkzeugzugriff durch agentic AI.
• Ein Ontologie-Wartungs-Framework mit Änderungserkennung und versionierter Bereitstellung.

Wir liefern außerdem eine ehrliche Einschätzung, wo Ihnen ein einfacherer Ansatz ebenso gut dienen würde.