Wenn die Ontologie zu groß für das LLM wird

Warum es teuer und ungenau wird, einem LLM das komplette Schema zu übergeben und warum eine Retrieve-and-Expand-Strategie gewinnt.

Executive Summary

• Das Problem: Wenn KI große Enterprise-Knowledge-Graphs abfragen soll, wird es langsam, teuer und überraschend ungenau, dem LLM die vollständige Ontologie als Kontext zu übergeben.
• Die Falle: Je größer die Ontologie, desto schwerer findet das Modell die relevanten Konzepte in einem Meer aus Rauschen – ein klassisches Long-Context-Retrieval-Problem. Die Performance sinkt genau dann, wenn Sie sie am dringendsten brauchen.
• Die Lösung: Eine Retrieve-and-Expand-Pipeline. Zuerst findet semantische Suche eine kleine Menge relevanter Entitäten. Anschließend nutzt die Pipeline die Struktur des Graphen, um deterministisch den lokalen Kontext zu ergänzen, den eine korrekte Abfrage braucht.
• Der Effekt: Dieser Ansatz hält die Kosten niedrig und die Performance hoch – unabhängig von der Größe der Ontologie. Es ist der robustere, skalierbare Weg zu verlässlichen Question-Answering-Systemen auf Knowledge Graphs.

Einleitung

LLMs haben eine mächtige neue Möglichkeit eröffnet: natürlichsprachliche Fragen in ausführbare Abfragen auf strukturierten Daten zu übersetzen. Indem wir einen KI-Agenten in der formalen Ontologie eines Knowledge Graph grounden, erhalten wir Antworten, die nicht nur eloquent, sondern auch faktisch korrekt und nachvollziehbar sind.

Doch was passiert, wenn die Ontologie – die semantische Landkarte Ihres Unternehmens – zu groß wird, damit das Modell sie lesen kann? Auf Unternehmensmaßstab können Ontologien Hunderttausende Konzepte umfassen. Ein LLM in diesem gewaltigen Kontext die wenigen relevanten Entitäten für eine einzelne Frage suchen zu lassen, ist, als würde man jemanden eine bestimmte Adresse finden lassen und ihm dafür das Telefonbuch eines ganzen Landes geben.

Das ist ineffizient, teuer und funktioniert, wie wir sehen werden, nicht. Dieser Artikel zeigt, warum der Ansatz „Full-Ontology-Prompting“ scheitert, und stellt eine intelligentere, skalierbare Alternative vor.

Der Bruchpunkt: Warum Full-Ontology-Prompting nicht skaliert

Der einfachste Ansatz für Question Answering auf Knowledge Graphs besteht darin, dem Modell die Frage des Nutzers und die gesamte Ontologie zu übergeben – mit der Aufforderung, die relevanten Entitäten zu identifizieren und eine Abfrage zu generieren. Bei kleinen, in sich geschlossenen Schemata funktioniert das. In einem realen Unternehmen, in dem Ontologien groß, modular und ständig wachsend sind, stößt dieses Muster an eine Wand.

Dafür gibt es drei Hauptgründe:

• Steigende Kosten und Latenz: Je mehr Tokens Sie dem Modell übergeben, desto mehr zahlen Sie und desto länger warten Sie. Bei großen Ontologien wird jede einzelne Frage zu einer langsamen und teuren Operation.
• Sinkende Genauigkeit: Mehr Kontext bedeutet nicht besseres Verständnis. Modelle haben Mühe, wenige relevante Elemente in einem langen, von Rauschen durchsetzten Dokument exakt zu bestimmen. Das ist eine bekannte Schwäche von Long-Context-Modellen. Mit wachsender Ontologie sinkt die Fähigkeit des Modells, die für die Abfrage korrekten Entitäten abzurufen, tatsächlich.
• Zunehmende Ambiguität: Große, modulare Unternehmensontologien enthalten häufig ähnliche Konzepte in unterschiedlichen Domänen. Je mehr Module hinzukommen, desto mehr plausible, aber falsche Interpretationen kann eine Frage annehmen – das verwirrt das Modell und führt zu falschen Antworten.

Unsere Forschung bestätigt dies über mehrere Modelle und Benchmarks hinweg. Mit zunehmender Größe des Ontologie-Kontexts sank die Retrieval-Qualität konsistent, während die Latenz stark anstieg.

Full-Ontology-Prompting ist eine brauchbare Baseline für Demos, aber ein fragiles Fundament für ein Produktivsystem. Es wird langsamer, teurer und unzuverlässiger – genau in dem Moment, in dem Ihr Unternehmensschema zu skalieren beginnt.

Der bessere Weg: Erst abrufen, dann Struktur wiederherstellen

Statt das Modell für jede Fahrt die ganze Landkarte neu lesen zu lassen, können wir ihm nur den relevanten Abschnitt geben. Unsere Alternative ist eine zweistufige Retrieve-and-Expand-Pipeline, die die Ontologie ihrer Struktur entsprechend nutzt.

Dieser Ansatz verändert das Kosten- und Performance-Profil drastisch. Die Kosten pro beantworteter Frage bleiben niedrig und vorhersehbar, selbst wenn die Ontologie auf sehr großen Maßstab wächst.

So funktioniert es:

Schritt 1: Retrieval per semantischer Suche

Zunächst indexieren wir die gesamte Ontologie einmalig. Jede Klasse und jede Property wird auf Basis ihres Namens, ihrer Labels und ihrer Beschreibungen eingebettet. Stellt eine Nutzerin eine Frage, finden wir über schnelle, kostengünstige Vektorsuche eine kleine Menge Kandidaten-Entitäten, deren Beschreibungen der Formulierung der Frage semantisch ähnlich sind.

Dieser Schritt findet die Hauptkonzepte einer Frage zuverlässig. Semantische Suche allein genügt jedoch nicht. Zwei Typen essenzieller Entitäten übersieht sie häufig:

• Generische Properties mit wenig eigenem beschreibenden Text (z. B. hasValue, hasName).
• Verbindende Properties, die die Struktur des Graphen beschreiben und nicht die Fachsprache.

Schritt 2: Expansion zur Wiederherstellung der lokalen Struktur

Hier nutzen wir die Stärke des Graphen. Ausgehend von den im Retrieval gefundenen Entitäten führen wir zwei deterministische Expansionsschritte aus, die die Struktur der Ontologie traversieren – ohne einen weiteren teuren Modellaufruf.

• Lokale Expansion (E1): Wir ergänzen alle Datatype Properties, die direkt an den abgerufenen Entitäten hängen.
• Graph-Expansion (E2): Wir traversieren den Graphen weiter, um Multi-Hop-Beziehungen (Object Properties) und die von ihnen verbundenen Klassen einzubeziehen.

Das Ergebnis ist ein kompaktes, relevantes Schema-Snippet: die Entitäten aus der semantischen Suche plus der umgebende strukturelle Kontext, der für eine korrekte Abfrage nötig ist. Diesen kleinen, gezielten Kontext übergeben wir dem LLM.

Warum das zählt: Eine robustere Arbeitsteilung

Die Retrieve-and-Expand-Pipeline etabliert eine robustere Arbeitsteilung:

• Sprachmodelle für das einsetzen, was sie am besten können: die Nuancen menschlicher Sprache in der Frage interpretieren.
• Den Knowledge Graph für das einsetzen, was er am besten kann: explizite, verlässliche und traversierbare Struktur bereitstellen.

Durch diese Trennung der Zuständigkeiten entsteht ein System, das nicht nur effizienter, sondern auch verlässlicher ist. Über unsere Enterprise-Benchmarks hinweg liefert diese Pipeline konsistent einen Schema-Kontext mit hohem Recall – zu einem Bruchteil der Kosten von Full-Ontology-Prompting.

Trade-offs und Grenzen: Die Herausforderung Ambiguität

Diese Methode ist kein Allheilmittel. Sie verbessert die Performance drastisch, dennoch bleiben Herausforderungen. Die schwierigsten Fragen sind die inhärent mehrdeutigen, bei denen die Absicht der Nutzerin sich weder durch semantische Ähnlichkeit noch durch Graphstruktur allein auflösen lässt.

Fragt jemand etwa nach „Services“, während die Ontologie „Connected Services“, „Financial Services“ und „Internal Services“ enthält, kann es dem System ohne klärenden Dialog weiterhin schwerfallen, das Richtige auszuwählen. Deterministische Expansion stellt Struktur wieder her, sie kann aber keine Absicht erfinden, die in der Frage nicht vorhanden ist.

Fazit: Wenn Sie sich eines merken …

Der begrenzende Faktor beim Question Answering auf Enterprise-Knowledge-Graphs ist nicht die Fähigkeit des LLM, SPARQL zu schreiben. Es ist die Fähigkeit, die kleine Menge an Schema-Entitäten effizient und präzise zu identifizieren, die eine Frage erfordert.

Behandeln Sie Ihre Ontologie nicht als ein einziges, massives Dokument, das man in einen Prompt zwängt. Behandeln Sie sie als semantisches System. Nutzen Sie ihre Struktur zu Ihrem Vorteil.

Indem Sie schnelles semantisches Retrieval mit deterministischer Graph-Expansion kombinieren, entsteht ein System, das mit zunehmender Skalierung günstiger, schneller und verlässlicher wird. So kommen Sie von beeindruckenden Demos zu robuster Analytik auf Enterprise-Niveau. Nutzen Sie Sprachmodelle, um Sprache zu interpretieren, und den Knowledge Graph, um Struktur wiederherzustellen. Das ist der Schlüssel zu Question-Answering-Systemen, die gewinnen.

Wer tiefer einsteigen möchte: Die vollständige Methodik samt Benchmark-Ergebnissen beschreiben wir in unserem 12-seitigen Whitepaper.