Warum RAG nicht ausreicht: Eine semantische Schicht für Graph-, SQL- und Vektorabfragen
RAG versagt bei mehrstufigen Anfragen, numerischen sowie unklaren Unternehmensfragen. Eine semantische Schicht kümmert sich um die Aufteilung, das Routing und das Schemamapping, wobei Apache Ossie für die Portabilität sorgt.
Sprachmodelle haben es erleichtert, Unternehmensfragen in einfachen Worten zu formulieren. Eine Antwort zu erhalten, ist etwas anderes als zu wissen, was die Frage in verschiedenen Datensystemen bedeutet. Nehmen wir folgende Frage:
Stellen Sie sich vor, ein Analyst fragt: Welche börsengehandelten Fonds besitzen Unternehmen, die strategisch mit NVIDIA zusammenarbeiten, über eine Milliarde Dollar verwalten und in aktuellen Forschungsberichten positiv bewertet werden?
Es liest sich wie eine einzige Frage, enthält aber tatsächlich drei Arten von Aufgaben:
- NVIDIA, strategischer Partner, ETF-Besitz: Darstellung von Beziehungen in einem Graphen.
- Verwalteter Vermögenswert über 1 Milliarde Dollar: genaues numerisches Filtern.
- Positive aktuelle Forschungsergebnisse: Verständnis unstrukturierter Texte.
Unter dieser Oberfläche verbirgt sich ein tieferliegendes Problem. Was bedeutet AUM im zugrundeliegenden Datenmodell – und welche Quelle ist dafür die Autorität? Bevor ein System richtig antworten kann, muss es die Bedeutung der Daten verstehen, nicht nur die Daten selbst. Die semantische Ingenieurwissenschaft zielt auf diese Lücke ab.
Wo RAG endet
Der typische RAG-Pipeline-Prozess holt relevante Abschnitte ab und lässt das Modell daraus antworten. Das ist hervorragend, wenn es darum geht, relevante Texte zu finden und darauf zu antworten. Unternehmensbezogene Fragen erfordern oft mehr als nur Ähnlichkeitsbetrachtungen, und reine Vektorabfragen versagen auf vier erkennbaren Arten.
Zersplitterte Abfragen
Stellen Sie sich ein Produkthandbuch vor, das in drei Teile unterteilt ist:
Chunk 1: Atlas Enterprise — vendor, category
Chunk 2: Pricing — base fee, usage fee
Chunk 3: Risks — lock-in, migration, data residency
Jemand fragt nach den Preisen und Risiken von Atlas Enterprise. Der Produktname darf nur im ersten Teilabschnitt erscheinen. Der zweite und dritte enthalten die Antwort, verlieren aber nach der Aufteilung in Teilabschnitte den Kontext zur jeweiligen Entität. Metadatenvervollständigung, Abruf von Eltern-Kind-Beziehungen sowie Neuranking helfen zwar, doch die Fragmentierung bleibt eine grundlegende Schwäche.
Keine Beziehungsverfolgung
Nun fragen wir, welche ETFs Unternehmen beinhalten, die mit NVIDIA zusammenarbeiten. Der logische Ablauf beruht nicht auf einem einfachen Schlüsselwortabgleich:
NVIDIA
↓ HAS_STRATEGIC_PARTNER
Company
↓ HELD_BY
ETF
Die Vektorsuche wird Dokumente finden, die NVIDIA, seine Partner oder ETFs erwähnen. Was sie jedoch nicht zuverlässig tun kann, ist zu konstatieren, dass diese Erwähnungen eine bestimmte mehrstufige Beziehung bilden. Ein Graph kann den Pfad explizit durchlaufen:
?nvidia corp:hasStrategicPartner ?company .
?etf etf:hasConstituent ?company .
Ähnlicher Text ist nicht dasselbe wie eine Verbindung zwischen Entitäten.
Entitätsambiguität
Ein Name wie „NVIDIA“ kann auf mehrere Dinge verweisen:
NVIDIA → Company
NVIDIA International → Subsidiary
NVIDIA AI Enterprise → Product
Ihre Embeddings können zwar nah beieinander liegen, doch es handelt sich um unterschiedliche Entitäten verschiedener Typen. Eine Ontologie liefert Identität, Typ und Beziehungen – etwas, was Textähnlichkeit nicht kann.
Keine präzise numerische Filterung
Eine Anfrage wie „Kunden mit einem jährlichen Umsatz von über 1 Mio. Dollar und einer Churn-Wahrscheinlichkeit unter 5 %“ ist reiner SQL:
SELECT customer_id
FROM customer_metrics
WHERE annual_revenue > 1000000
AND churn_probability < 0.05;
Embeddings erfassen Ähnlichkeiten. Sie führen zuverlässig keine Operationen wie größer als, kleiner als, ZWISCHEN, Aggregation oder Ranking aus.
Eine Frage, mehrere Engines
Die anfängliche Frage erfordert mehr als nur eine Suchstrategie, und jeder Engine eignet sich für einen anderen Typ von Schlussfolgerung:
Vector → meaning and unstructured text
BM25 → exact lexical matching
Graph → relationships and multi-hop traversal
SQL → filters, numbers and aggregation
Die Aufgabe ist von der Datenerfassung zu einer federierten Abfragenausführung übergegangen. Die Föderierung stellt drei schwierigere Probleme dar: Dekomposition, Routing und Abbildung.
Dekomposition
Das System muss die Frage in natürlicher Sprache in Einheiten aufteilen, die es ausführen kann:
1. Resolve NVIDIA as a Company
2. Find its strategic partners
3. Find ETFs holding those companies
4. Filter AUM > $1B
5. Retrieve the latest research reports
6. Identify positive views
Routing
Jede Einheit muss zum für sie zuständigen Quellgerät gelangen:
relationships → Graph
AUM → SQL
research view → Vector Search
Es reicht nicht aus, Datenbanken zu verbinden. Das System muss wissen, welche Quelle welche Teilfrage beantwortet.
Kartierung
Das ist oft der schwierigste Teil. Ein Benutzer gibt „AUM“ ein, während die Datenbank Felder wie diese enthalten kann:
NET_ASSET_AMT
AUM_USD
FUND_NET_ASSET
Welches ist das zu verarbeitende Konzept? Ebenso könnte ein ETF im Graphen als fund:ETF dargestellt werden, in SQL als dim_fund.fund_id und im Vektorindex als metadata.product_id. Das System benötigt eine Brücke vom Geschäfts-Vokabular zu den physischen Schemata. Das ist die sogenannte Schema-Verankerung – ohne sie kann ein LLM perfekt glaubwürdigen SQL-Code gegenüber Spalten schreiben, die nicht existieren.
Die semantische Schicht
Die semantische Schicht befindet sich zwischen dem, was die Menschen meinen, und der Art und Weise, wie Daten gespeichert werden. Anstatt einem LLM Hunderte von Rohtabellen und Eigenschaften zu zeigen, werden Konzepte bereitgestellt:
Company
Strategic Partner
ETF
Constituent
Assets Under Management
Research Report
und verleihen jedem eine Bedeutung:
Assets Under Management
├─ business definition
├─ currency / unit
├─ effective date
├─ authoritative source
└─ physical column
Die Schicht kann dann direkt am Abfralifezyklus teilnehmen. Das verändert den Zweck einer Ontologie – sie ist nicht mehr nur statische Dokumentation, sondern wird zu einem ausführbaren Kontext für das KI-System.
Wie sie organisiert sein könnte
Bei einem System, das eine relationale Datenbank, ein Wissensgraph und Vektorabfragen kombiniert, könnte die Schicht wie folgt strukturiert sein:
semantic_layer/
├── ontology/
│ ├── tbox.ttl # classes and relationships
│ └── vocabulary.yaml # business terms and synonyms
├── schemas/
│ ├── rdb.yaml # tables, columns, types
│ ├── graph.yaml # entities, predicates, graph paths
│ └── vector.yaml # indexes and document metadata
├── semantics/
│ ├── metrics.yaml # governed metrics such as AUM
│ ├── mappings.yaml # concept → physical source mapping
│ └── relationships.yaml # cross-domain relationships
├── query/
│ ├── routing.yaml # Graph vs SQL vs Vector routing
│ └── examples.yaml # representative query plans
└── validation/
└── rules.yaml # allowed fields and business rules
In dieser Struktur wird tbox.ttl genutzt, um Klassen wie Company und ETF sowie den HAS_STRATEGIC_PARTNER-Verknüpfungspfad zwischen ihnen zu deklarieren, während rdb.yaml die tatsächlichen Tabellen und Spalten dokumentiert. mappings.yaml verknüpft das Konzept der verwalteten Vermögenswerte mit der Spalte fund_metrics.net_asset_amt. Schließlich ermöglicht routing.yaml dem Planer zu entscheiden, ob ein Schritt an das Graphen, an SQL oder an eine Vektorsuche weitergeleitet wird.
Die genauen Dateien hängen von der Implementierung ab. Entscheidend ist es, Bedeutungen, physische Zuordnungen und gültige Ausführungspfade ausdrücklich festzuhalten, anstatt zu erwarten, dass das LLM sie bei jeder Abfrage neu entdeckt. Vier Aufgaben profitieren direkt davon:
- Entdoppelung: Das Unternehmen sowie ähnlich benannte Produkte gehören zu verschiedenen Entitätsklassen.
fund_metrics.net_asset_amt abgebildet.Deshalb umfasst die semantische Ingenieurwesen mehr als nur das Erstellen einer Ontologie. Ziel ist es, geschäftliche Bedeutungen in Echtzeit nutzbar zu machen – durch ein gemeinsames Vokabular, eine Ontologie, Metrikdefinitionen, Beziehungen, Schemamappinge, Geschäftsregeln, Quellmetadaten sowie Validierungsprüfungen. Aus dieser Sicht ähnelt eine semantische Schicht eher einer Kompilierungsstufe für Unternehmensdaten als einem Glossar.
Von der Schicht zum Laufzeitbetrieb
Viele heutige Agentenkonzepte sehen so aus:
User → LLM → Tools
Das LLM erhält Beschreibungen der Tools und entscheidet, wie sie benannt werden sollen. Eine semantische Architektur kann stärker eingeschränkt sein:
User
↓
Semantic Resolution
↓
Logical Query Plan
↓
Validated Execution
↓
Evidence
↓
LLM
Das Modell muss nicht selbst ermitteln, wie es mit jeder Tabelle, jedem Metrikwert, jedem Graphenprädikat und jeder Geschäftsregel umgehen soll. Es arbeitet innerhalb eines begrenzten semantischen Umfelds. Das Ziel ist eine bessere Schnittstelle zwischen Modell und Unternehmensdaten – nicht einfach ein größeres Modell.
Warum ein offenes Austauschformat wichtig ist
Semantische Definitionen neigen dazu, auseinanderzudriften. Ein Unternehmen könnte den Nettoumsatz beispielsweise in seiner Datenplattform, BI-Tool, Katalog, Analyse-App und KI-Agentur separat definieren, wodurch sich die Definitionen im Laufe der Zeit voneinander entfernen.
Open Semantic Interchange (OSI) soll dieses Problem lösen. Die Initiative trat im Juni 2026 dem Apache Incubator bei und existiert weiterhin als Apache Ossie (im Inkubationsprozess). Ihr Ziel ist es, Systemen eine neutrale Möglichkeit zum Austausch semantischer Metadaten zu bieten. Die Kernspezifikation ist in YAML geschrieben und umfasst Datensätze, Felder, Beziehungen, Metriken sowie den KI-Kontext. Ein vereinfachtes Modell sieht wie folgt aus:
version: "0.2.0.dev0"
semantic_model:
- name: investment_products
datasets:
- name: etf
source: analytics.dim_etf
fields:
- name: aum
datatype: Decimal
ai_context:
synonyms: ["assets under management", "net assets"]
metrics:
- name: total_aum
expression:
dialects:
- dialect: ANSI_SQL
expression: SUM(etf.aum)
Die Syntax spielt kaum eine Rolle. Entscheidend ist, dass aum eine einzige Definition erhält – mit seiner physischen Quelle, dem Datentyp, der metrischen Logik sowie den für KI zugänglichen Synonymen – und dass diese Definition als portables Metadaten übertragen wird, anstatt in jedem Tool neu geschrieben zu werden.
┌→ BI
├→ Analytics
Semantic Model ───┼→ AI Agents
├→ Data Catalogs
└→ Data Applications
Ein Katalog könnte die definierte Bedeutung und Abstammung von AUM anzeigen, und ein KI-Agent könnte dieselben Metadaten lesen, um den Ausdruck „verwaltete Vermögenswerte“ auf das richtige Feld zu übertragen, anstatt aus Rohschemata zu raten.
Zusätzlich überprüft Ossie Modelle anhand eines JSON Schemas, unterstützt mehrere Ausdrucksdialekte und definiert ein Konvertierungsmodell zum Wechsel zwischen Herstellerspezifikationen. Zu den geplanten Erweiterungen gehören umfangreichere Metriken, bessere Kompositionseigenschaften, Integration in Kataloge, präzisere Beziehungssemantiken sowie eine verbesserte Ontologiedarstellung.
Die Richtung der Ontologie ist insbesondere für KI interessant, denn allein Metriken und Dimensionen liefern einem Agenten keine solchen Fakten:
Customer is an Organization
Company HAS_SUBSIDIARY Company
Company OWNS_PRODUCT Product
Document DESCRIBES Entity
Falls semantische Modelle und umfangreichere Ontologien zusammenwirken, könnten KI-Systeme tragbare Geschäftsbedeutungen erhalten – und nicht nur tragbare Schemata.
Zurück zur NVIDIA-Frage
Ein semantisches Abfragesystem kann die anfängliche Frage Schritt für Schritt verarbeiten, wobei jede Entscheidung auf expliziten Metadaten beruht. Ohne eine semantische Schicht muss das LLM bei jedem Schritt Bedeutung, Quelle, Schema und Beziehungen selbst ableiten – und eine einzige falsche Annahme kann die gesamte Kette zerstören.
Der größere Wandel
Unternehmens-KI hat verschiedene Entwicklungsstufen durchlaufen:
LLM + Prompt
↓
LLM + RAG
↓
LLM + Tools
↓
LLM + Federated Data
↓
Semantic Layer + Federated Execution + LLM
Die Retrieval-Technologie zeigt an, welche Dokumente relevant erscheinen. Ein Graph zeigt, wie Entitäten miteinander verbunden sind. SQL gibt an, welche Datensätze genaue Bedingungen erfüllen. Die semantische Schicht kümmert sich um die grundlegende Frage: Wie lässt sich diese Frage in das Vokabular unserer Daten übersetzen?
Systeme werden weiterhin Datenbanken, Graphen, Dokumente, APIs und Tools hinzufügen, und allein das Verknüpfen von Daten reicht nicht aus. Auch die Bedeutung muss verknüpft werden. Unternehmensweite KI wird möglicherweise weniger darauf angewiesen sein, einem Modell zusätzliche Daten zur Verfügung zu stellen, und stattdessen stärker darauf, ihm ein klares Verständnis dafür zu vermitteln, was diese Daten bedeuten.