Orientierung

RAG & Semantic Layer: Wissenszugang für KI in Organisationen

KI braucht Wissen — und Wissen braucht Zugang. Ohne verlässlichen Retrieval-Mechanismus bleibt jedes Sprachmodell ein Halluzinator. Diese Seite zeigt, welche Wissenszugänge es gibt, wann sie sich lohnen und warum die Qualität des Zugriffs über den Erfolg von KI in Organisationen entscheidet.

Ausgangspunkt

Warum RAG im Zentrum steht

RAG (Retrieval-Augmented Generation) ist der einstiegsfreundlichste KI-Bereich für Organisationen: Er setzt auf vorhandenen Dokumenten und Daten auf, ist erklärbar und die Qualität hängt direkt von der Datenqualität ab.

Gleichzeitig wird RAG oft falsch eingeschätzt. Viele Teams starten mit einer einfachen Chunk-Vector-Suche und merken erst später, dass komplexe Fragen, Beziehungen zwischen Entitäten oder hohe Genauigkeitsanforderungen einen anderen Ansatz brauchen. Die Frage ist nicht, ob RAG, sondern in welcher Tiefe.

Drei parallele Entwicklungen machen RAG und Semantic Layer heute zum strategischen Thema:

  • KI-Agenten brauchen Kontext — ohne verlässlichen Wissenszugang bleiben Agenten unberechenbar
  • Datenplattformen integrieren Semantik — Databricks, Snowflake, Microsoft Fabric machen Bedeutung zur Plattformfrage
  • Evaluierung wird zum Engpass — RAG-Systeme, die im Test glänzen, scheitern im Betrieb an veralteten Quellen und falschen Metriken

Drei Ebenen

Vom Chunk zur Ontologie: die Evolution des Retrieval

Jede Ebene löst ein Problem der vorherigen — und schafft neue Anforderungen an Aufbau, Betrieb und Governance.

1

Klassisches RAG – Chunk + Vector Search

Der Standard: Dokumente zerteilen, einbetten, ähnliche finden.

Stärken

  • Schnell einzurichten, viele Tools, gute Einstiegslösung
  • Funktioniert zuverlässig für einfache Faktenfragen
  • Große Auswahl an Vektordatenbanken (Pinecone, Qdrant, Weaviate, pgvector)

Grenzen

  • Flache Chunks erfassen keine Beziehungen zwischen Entitäten
  • Mehrstufige Fragen (Multi-Hop) werden schwer
  • Kontext geht verloren, wenn Information auf mehrere Chunks verteilt ist
Enterprise Knowledge beschreibt es treffend: Traditionelles RAG stößt an Grenzen, sobald Fragen mehrere Entitäten, verschachtelte Kontexte, komplexe Beziehungen oder hohe Genauigkeitsanforderungen umfassen.
Enterprise Knowledge — GraphRAG in the Enterprise
2

GraphRAG – Beziehungen, Subgraphen, Hybrid

Nicht nur Dokumente, sondern ihre Verbindungen durchsuchen.

Stärken

  • Findet Beziehungen zwischen Konzepten, nicht nur Textähnlichkeit
  • Unterstützt verifizierbares Multi-Hop-Reasoning
  • Kombiniert Knowledge-Graph-Reasoning mit Vector Search (Hybrid-Retrieval)

Grenzen

  • Aufwändiger im Aufbau: Text muss erst in einen Graphen überführt werden
  • LLM-gestützte Extraktion kann fehlerbehaftet sein
  • Für einfache Fragen oft Overkill
Microsofts GraphRAG ist das bekannteste Open-Source-Beispiel. Es beschreibt sich als Data Pipeline und Transformation Suite für strukturierte Daten aus unstrukturiertem Text — und verbessert nachweislich die Fähigkeit von LLMs, über private Daten zu reasoning.
Microsoft Research — GraphRAG
3

Ontologie-getriebenes RAG – Vertrag, nicht vage Ähnlichkeit

Das Domänenmodell wird zum expliziten, governed Vertrag.

Stärken

  • Ontologie als verbindlicher Vertrag: Was bedeutet ein Begriff? Welche Regeln gelten?
  • Explizite Struktur (RDF-Graph) statt impliziter Ähnlichkeit
  • LLMs nur dort, wo sie wirklich Mehrwert bringen — nicht für die gesamte Logik

Grenzen

  • Höchster Aufbauaufwand: Ontologie-Pflege braucht Domänenexpertise
  • Weniger Tools und Community als klassisches oder GraphRAG
  • Lohnt sich vor allem in regulierten, compliance-intensiven Umfeldern
OntoRAG formuliert es präzise: Die Ontologie wird zum Contract — ein governed Modell der Domäne, verknüpft mit Evidenz, callable durch Agenten via Tools (SPARQL, MCP).
OntoRAG — Ontology-Driven RAG

Bedeutung als Infrastruktur

Semantic Layer & Context Layer

Retrieval allein reicht nicht. Organisationen brauchen eine Schicht, die Bedeutung explizit macht, und eine zweite, die Kontext zur Laufzeit liefert.

Semantic Layer

Die strukturelle Bedeutung hinter Daten und Wissen. Ein Semantic Layer macht explizit, was Begriffe in einer Organisation bedeuten — unabhängig davon, in welchem System sie liegen.

Grundlage: Einmal definierte Bedeutung, überall nutzbar.

Enterprise Knowledge

Context Layer

Erweitert den Semantic Layer um Geschäftsregeln und Domänenwissen zur Laufzeit. Ein Context Graph speist governed Data Relationships, Business Rules und Domain Knowledge in Agenten.

Erweiterung: Bedeutung allein reicht nicht — Kontext braucht Regeln und Runtime.

Enterprise Knowledge

Plattform-Semantik (z. B. Databricks Unity Catalog)

Business Semantics als Kern der Datenplattform: Metriken, Dimensionen und Metadaten werden einmal definiert und in BI, Notebooks und KI-Agenten wiederverwendet — offen, portabel, governed.

Infrastruktur: Semantik wird zur Plattformfrage, nicht zum Tool-Feature.

Databricks — Unity Catalog Business Semantics

Enterprise Knowledge bringt es auf den Punkt: Die Debatte ist nicht Semantic Layer oder Knowledge Graph — sondern warum diese Ebenen allein nicht ausreichen, um KI-Agenten zuverlässig zu grounden. Erst die Kombination aus struktureller Bedeutung (Semantic Layer), Geschäftsregeln zur Laufzeit (Context Layer) und governed Runtime-Daten schafft verlässliche Kontext-Infrastruktur.

Risiko

Die Evaluierungsfalle: Wenn Metriken falsche Sicherheit geben

Eines der größten Risiken in RAG-Systemen: Die Metriken sehen gut aus — und die Antworten sind trotzdem falsch. Atlan beschreibt RAG-Evaluation als zweidimensional: Retrieval-Qualität und Generations-Qualität müssen getrennt gemessen werden. Und selbst dann übersehen Standard-Metriken Geschäftsfehler.

Die gefährlichste Lücke: Ein System kann hohe Faithfulness-Scores liefern und gleichzeitig falsche Geschäftsantworten geben — wenn der Index veraltet, die Quellen nicht owned oder die kanonische Version nicht erkannt ist.

Retrieval-Qualität

Findet das System die richtigen Quellen?

  • Hohe Retrieval-Scores können über falsche, veraltete oder unzuständige Quellen hinwegtäuschen
  • Ähnlichkeitssuche findet ähnliche Texte, nicht unbedingt richtige Antworten

Antwortqualität (Faithfulness)

Bleibt die Antwort nah an den Quellen?

  • Eine Antwort kann quellentreu sein — und trotzdem die falsche Geschäftsantwort liefern
  • Faithfulness misst keine Korrektheit, nur Nähe zum gefundenen Material

Source-Governance

Sind die Quellen aktuell, owned und kanonisch?

  • Veraltete Quellen (Stale Sources) brechen Vertrauen — auch bei guten Metriken
  • Fehlendes Ownership: Niemand ist verantwortlich, wenn ein Source-Dokument falsch ist
  • Kanonische Quellen fehlen: Welche Version ist die autoritative?

Multi-Dimensionale Diagnostik

Misst das System, was im Betrieb wirklich zählt?

  • Einzelne Metriken (Accuracy) spiegeln nicht die Betriebsrealität
  • Reasoning-Komplexität, Retrieval-Schwierigkeit und Erklärbarkeit sind eigene Dimensionen

Quelle: Atlan — RAG Evaluation: Metrics, Tools, and the Context Gap; ergänzt durch Enterprise Knowledge — Semantic Layer vs Context Layer

Governance

Warum RAG-Governance kein Randthema ist

RAG-Governance wird oft vergessen — bis die erste falsche Antwort rechtliche Konsequenzen hat. Drei Felder sind für Organisationen entscheidend:

Source Ownership

Wer ist verantwortlich, wenn eine Quelle veraltet, falsch oder nicht mehr zuständig ist? Jede Quelle im RAG-Index braucht einen Owner — nicht technisch, sondern fachlich.

Kanonische Quellen

Welche Version eines Dokuments ist autoritativ? Wenn mehrere Versionen kursieren, entscheidet der RAG-Index nicht nach Richtigkeit, sondern nach Ähnlichkeit — und zieht die falsche.

Die Ontologie als Vertrag

Wenn RAG auf Ontologien aufsetzt, wird das Domänenmodell zum Vertrag: Jeder Begriff ist governed, jede Beziehung explizit. Agenten callen nicht vage Ähnlichkeit — sie fragen definierte Strukturen. (OntoRAG)

Entscheidungsmatrix

Welcher Ansatz passt zu welchem Problem?

Nicht jede Organisation braucht GraphRAG oder eine Ontologie. Die Frage ist: Welche Fragen soll das System beantworten?

ProblemtypPassender AnsatzAufwandGeeignet für
Einfache Faktenfragen aus DokumentenKlassisches RAG (Chunk + Vector)GeringDokumentation, Wissensdatenbanken, interne FAQs
Fragen mit Beziehungen (Wer arbeitet woran? Welche Produkte hängen zusammen?)GraphRAGMittelProduktkataloge, Organisationswissen, vernetzte Fachdaten
Hochpräzise, regulierte Umgebungen (Welche Vorschrift gilt? Was ist die autoritative Quelle?)Ontologie-getriebenes RAGHochCompliance, Legal, Pharma, Finanzaufsicht
KI-Agenten brauchen verlässlichen GeschäftskontextSemantic + Context LayerHochEnterprise-Agenten, Multi-System-Integration, Entscheidungsunterstützung

Einordnung

Was bedeutet das für deine Organisation?

RAG und Semantic Layer sind keine reinen Technologie-Entscheidungen. Sie sind Infrastruktur-Entscheidungen. Wer heute mit einfachem Chunk-RAG startet, wird morgen vor der Frage stehen, ob GraphRAG, ein Semantic Layer oder eine Ontologie der richtige nächste Schritt ist.

Der Fehler ist nicht, mit Ebene 1 zu starten. Der Fehler ist, nicht zu wissen, dass es Ebene 2 und 3 gibt.

Drei Fragen für den Einstieg:

  1. Welche Fragen soll das System wirklich beantworten — einfache Fakten oder mehrstufige Zusammenhänge?
  2. Wer owned die Quellen, und wie stellen wir sicher, dass sie aktuell und kanonisch sind?
  3. Messen wir das Richtige — oder nur das Leichte?

Weiterlesen

Quellen und Vertiefung

Die folgenden Quellen haben diese Seite informiert. Sie sind alle öffentlich zugänglich.

  • Enterprise Knowledge — GraphRAG in the Enterprise

    enterprise-knowledge.com/graphrag-in-the-enterprise/ — Grundlage für die Analyse der drei Ebenen und die Grenzen des chunk-basierten Retrieval.

  • Microsoft Research — GraphRAG

    github.com/microsoft/graphrag — Open-Source-Pipeline für strukturierte Datenextraktion und Hybrid-Retrieval.

  • OntoRAG — Ontology-Driven RAG

    ontorag.codeberg.page — Ontologie als governed Contract, SPARQL + MCP als Tooling für LLM-Reasoning.

  • Atlan — RAG Evaluation: Metrics, Tools, and the Context Gap

    atlan.com/know/how-to-evaluate-rag-systems-explained/ — Zweidimensionale RAG-Evaluation, Stale Sources, Ownership und kanonische Quellen.

  • Enterprise Knowledge — Semantic Layer vs Context Layer

    enterprise-knowledge.com/what-is-the-difference-between-a-semantic-layer-and-a-context-layer/ — Warum Semantic Layer allein nicht ausreicht und Context Layer die Lücke schließen.

  • Databricks — Unity Catalog Business Semantics

    databricks.com/blog/redefining-semantics-data-layer-future-bi-and-ai — Business Semantics als Kern der Datenplattform, Metric Views, Genie Code.

Verwandte Seiten

Vertiefung im AI-Hub

Diese Seite ist Teil der KI-Orientierung unter /themen/ai. Vertiefende Perspektiven:

  • AI Data Strategy— Datenplattform, Katalog, Lifecycle und Runtime Governance
  • Beyond LLMs— Retrieval, RAG und GraphRAG im Kontext der gesamten KI-Landkarte
  • Daten verantworten— Daten als Training, Kontext und Feedback-Loop
  • Agentic AI— Was passiert, wenn Agenten auf RAG und Semantic Layer aufsetzen