Dlaczego RAG nie wystarcza: warstwa semantyczna dla zapytań grafowych, SQL i wektorowych
RAG zawodzi przy zapytaniach wieloetapowych, numerycznych oraz niejednoznacznych w środowisku korporacyjnym. Warstwa semantyczna zajmuje się dekompozycją, routowaniem i mapowaniem schematów, przy czym do zapewnienia przenośności wykorzystywany jest Apache Ossie.
Modele językowe ułatwiły sformułowanie pytań biznesowych w prostych słowach. Otrzymanie odpowiedzi to coś innego niż zrozumienie znaczenia pytania w kontekście kilku systemów danych. Weźmy takie przykład:
Załóżmy, że analityk pyta: które fundusze ETF posiadają spółki, które są strategicznymi partnerami NVIDIA, zarządzają kapitałem przekraczającym miliard dolarów i otrzymują pozytywne oceny w najnowszych raportach badawczych?
Wygląda to jak jedno pytanie, ale w rzeczywistości obejmuje trzy rodzaje zadań:
- NVIDIA, partner strategiczny, posiadane ETF: przedstawienie relacji w postaci grafu.
- Kapitał zarządzany powyżej 1 miliarda dolarów: dokładne filtrowanie liczbowe.
- Pozytywne najnowsze badania: analiza tekstu niestrukturyzowanego.
Pod spodem kryje się głębszy problem. Co oznacza AUM w podstawowym modelu danych i jaki jest źródło autorytetu w tym względzie? Zanim system będzie mógł poprawnie odpowiedzieć, musi zrozumieć znaczenie danych, a nie tylko same dane. Inżynieria semantyczna ma na celu wypełnienie tej luki.
Gdzie kończy się RAG
Typowy proces RAG pobiera istotne fragmenty tekstu i pozwala modelowi odpowiadać na ich podstawie. Jest to doskonałe rozwiązanie, gdy zadaniem jest znalezienie odpowiedniego tekstu i odpowiedź na jego podstawie. Pytania typu enterprise często wymagają czegoś więcej niż tylko podobieństwa, a czyste wyszukiwanie wektorowe zawodzi na cztery wyraźnie rozpoznawalne sposoby.
Rozproszone wyszukiwanie
Wyobraźmy sobie instrukcję obsługi produktu podzieloną na trzy części:
Chunk 1: Atlas Enterprise — vendor, category
Chunk 2: Pricing — base fee, usage fee
Chunk 3: Risks — lock-in, migration, data residency
Ktoś pyta o ceny i ryzyka związane z Atlas Enterprise. Nazwa produktu może pojawić się tylko w pierwszym fragmencie. Drugi i trzeci zawierają odpowiedź, ale po podziale na fragmenty nie zachowują już kontekstu tej jednostki. Wzbogacanie metadanych, wyszukiwanie elementów rodzicielsko-dziecięcych oraz ponowna klasyfikacja pomagają, jednak fragmentacja pozostaje podstawową słabością.
Zastanówmy się teraz, które ETF-y obejmują firmy współpracujące z NVIDIA. Ścieżka rozumowania nie polega na jedynie dopasowaniu kluczowego słowa:
NVIDIA
↓ HAS_STRATEGIC_PARTNER
Company
↓ HELD_BY
ETF
Wyszukiwanie wektorowe znajdzie dokumenty, które wspominają NVIDIA, jej partnerów lub ETF-y. Nie może jednak w sposób pewny stwierdzić, że te wzmianki tworzą określoną relację wieloetapową. Graf może wyraźnie przejść tę ścieżkę:
?nvidia corp:hasStrategicPartner ?company .
?etf etf:hasConstituent ?company .
Tekst podobny nie jest tym samym co związek pomiędzy entytetami.
Ambiwalencja entytetu
Nazwa taka jak „NVIDIA” może odnosić się do kilku rzeczy:
NVIDIA → Company
NVIDIA International → Subsidiary
NVIDIA AI Enterprise → Product
Ich embeddingi mogą znajdować się blisko siebie, ale są to różne entity o różnych typach. Ontologia dostarcza informacji o tożsamości, typie i relacjach, czego nie potrafi podobieństwo tekstowe.
Brak dokładnego filtrowania numerycznego
Zapytanie takie jak „klienci o rocznych przychodach powyżej 1 miliona dolarów i prawdopodobieństwie odejścia poniżej 5%” to zwykły SQL:
SELECT customer_id
FROM customer_metrics
WHERE annual_revenue > 1000000
AND churn_probability < 0.05;
Embeddingi reprezentują podobieństwa. Nie realizują w sposób niezawodny operacji typu „większe niż”, „mniejsze niż”, „MIĘDZY”, agregacji ani rankingu.
Jedno pytanie, kilka silników
Pierwotne pytanie wymaga więcej niż jednej strategii wyszukiwania, a każdy silnik nadaje się do różnego rodzaju rozumowania:
Vector → meaning and unstructured text
BM25 → exact lexical matching
Graph → relationships and multi-hop traversal
SQL → filters, numbers and aggregation
Zadanie przestało polegać na wyszukiwaniu i stało się wykonywaniem zapytań w modelu federacyjnym. Federacja stwarza trzy trudniejsze problemy: dekompozycję, routowanie i mapowanie.
Dekompozycja
System musi podzielić pytanie w języku naturalnym na jednostki, które może wykonać:
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
Ścieżki przesyłania
Każda jednostka musi udać się do źródła, które ma dla niej autorytet:
relationships → Graph
AUM → SQL
research view → Vector Search
Połączenie baz danych to nie wystarczy. System musi wiedzieć, która źródło odpowiada na który pytanie.
Kartowanie
To często najtrudniejszy etap. Użytkownik podaje AUM, natomiast baza danych może zawierać takie pola:
NET_ASSET_AMT
AUM_USD
FUND_NET_ASSET
Który z nich jest koncepcją zarządzaną? Podobnie ETF może być fund:ETF w grafie, dim_fund.fund_id w SQL oraz metadata.product_id w indeksie wektorowym. System potrzebuje mostu łączącego słownictwo biznesowe z fizycznymi schematami. To właśnie nazywa się ugruntowaniem schematu, a bez niego LLM może tworzyć w pełni wiarygodny SQL dotyczący kolumn, których w rzeczywistości nie ma.
Szczegół warstwy semantycznej
Warstwa semantyczna znajduje się pomiędzy tym, co ludzie mają na myśli, a sposobem przechowywania danych. Zamiast pokazywać LLM setki surowych tabel i właściwości, prezentuje się koncepcje:
Company
Strategic Partner
ETF
Constituent
Assets Under Management
Research Report
i nadaj znaczenie każdemu z nich:
Assets Under Management
├─ business definition
├─ currency / unit
├─ effective date
├─ authoritative source
└─ physical column
Kwarstwa ta może wtedy bezpośrednio brać udział w cyklu życia zapytania. To zmienia cel ontologii – przestaje ona być statyczną dokumentacją i staje się wykonywalnym kontekstem dla systemu AI.
Jak może być zorganizowana
Dla systemu łączącego bazę danych relacyjną, graf wiedzy i wyszukiwanie wektorowe, kwarstwa mogłaby być ułożona w następujący sposób:
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
W takiej strukturze tbox.ttl to miejsce, gdzie deklarowane są klasy takie jak Company i ETF, wraz z powiązaniem HAS_STRATEGIC_PARTNER między nimi, natomiast rdb.yaml dokumentuje rzeczywiste tabele i kolumny. mappings.yaml łączy koncepcję Aktywów pod Zarządem z kolumną fund_metrics.net_asset_amt. Wreszcie routing.yaml umożliwia planerowi decydowanie, czy dany krok ma trafić do grafu, do SQL czy do wyszukiwania wektorowego.
Dokładna lista plików zależy od implementacji. Ważne jest, aby jasno zapisać znaczenie, fizyczne mapowania oraz poprawne ścieżki wykonywania, zamiast polegać na tym, że model językowy odkryje je na każdej zapytaniu. Bezpośrednio od tego korzystają cztery zadania:
- Rozjaśnianie niejednoznaczności: firma oraz produkty o podobnej nazwie należą do różnych klas entytetów.
fund_metrics.net_asset_amt.Dlatego inżynieria semantyczna obejmuje więcej niż tylko tworzenie ontologii. Celem jest umożliwienie wykorzystania znaczeń biznesowych w czasie rzeczywistym poprzez wspólną słownictwo, ontologię, definicje metryk, relacje, mapowania schematów, reguły biznesowe, metadane źródłowe oraz sprawdzania walidacji. Patrząc w ten sposób, warstwa semantyczna bardziej przypomina etap kompilatora dla danych przedsiębiorstwa niż glosariusz.
Od warstwy do czasu rzeczywistego
Wiele dzisiejszych projektów agentów wygląda w ten sposób:
User → LLM → Tools
LLM otrzymuje opisy narzędzi i decyduje, jak je nazwać. Architektura semantyczna może być bardziej ograniczona:
User
↓
Semantic Resolution
↓
Logical Query Plan
↓
Validated Execution
↓
Evidence
↓
LLM
Model nie musi samodzielnie zgadywać, jak postępować z każdą tabelą, metryką, predykatem wykresu oraz regułą biznesową. Działa w ograniczonym środowisku semantycznym. Celem jest lepsza integracja modelu z danymi przedsiębiorstwa, a nie po prostu większy model.
Dlaczego ważny jest otwarty format wymiany
Samodzielne definicje semantyczne mają tendencję do fragmentacji. Firma może definiować dochód netto oddzielnie w swojej platformie danych, narzędziu BI, katalogu, aplikacji analitycznej oraz agencie AI, a z upływem czasu te definicje się różnią.
Otwarty Standard Wymiany Semantycznej (OSI) ma na celu rozwiązanie tego problemu. Inicjatywa dołączyła do Apache Incubator w czerwcu 2026 roku i funkcjonuje pod nazwą Apache Ossie (w fazie inkubacji). Jej celem jest zapewnienie systemom neutralnego sposobu wymiany metadanych semantycznych. Podstawowa specyfikacja jest napisana w formacie YAML i obejmuje zestawy danych, pola, relacje, metryki oraz kontekst AI. Uproszczony model wygląda w ten sposób:
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)
Syntaksa ma niewielkie znaczenie. Ważne jest to, że aum otrzymuje jedną definicję, zawierającą jego fizyczne źródło, typ danych, logikę metryczną oraz synonimy przeznaczone dla sztucznej inteligencji, a ta definicja jest przekazywana jako przenośne metadane, zamiast być ponownie pisana w każdym narzędziu.
┌→ BI
├→ Analytics
Semantic Model ───┼→ AI Agents
├→ Data Catalogs
└→ Data Applications
Katalog mógłby pokazywać definicję i genezę AUM, a agent AI mógłby odczytać te same metadane, aby przypisać wyrażenie „aktywa pod zarządem” do odpowiedniego pola, zamiast zgadywać na podstawie surowych schematów.
Ponadto Ossie weryfikuje modele według JSON Schema, umożliwia kilka dialektów wyrażeń oraz definiuje model konwertera do przenoszenia danych między formatami dostawców. Planowane działania obejmują bardziej rozbudowane metryki, możliwość łączenia komponentów, integrację z katalogiem, bardziej precyzyjną semantykę relacji oraz reprezentację ontologii.
Kierunek rozwoju oparty na ontologii jest szczególnie interesujący dla sztucznej inteligencji, ponieważ same metryki i wymiary nie dostarczają agentowi takich informacji.
Customer is an Organization
Company HAS_SUBSIDIARY Company
Company OWNS_PRODUCT Product
Document DESCRIBES Entity
Jeśli modele semantyczne i bardziej złożone ontologie się połączą, systemy AI będą mogły otrzymywać przenośne znaczenia biznesowe, a nie tylko przenośne schematy.
Z powrotem do pytania o NVIDIA
System zapytań semantycznych może przetwarzać początkowe pytanie krok po kroku, przy czym każda decyzja opiera się na wyraźnych metadanych. Bez warstwy semantycznej model językowy musi na każdym kroku wywnioskować znaczenie, źródło, schemat oraz relacje, a jedno błędne założenie może zniszczyć cały łańcuch.
Bardziej ogólna zmiana
Sztuczna inteligencja w przedsiębiorstwach przechodziła przez różne etapy:
LLM + Prompt
↓
LLM + RAG
↓
LLM + Tools
↓
LLM + Federated Data
↓
Semantic Layer + Federated Execution + LLM
Systemy wyszukiwania wskazują, które dokumenty wydają się istotne. Grafy pokazują, w jaki sposób powiązane są różne entity. SQL określa, które rekordy spełniają dokładne warunki. Warstwa semantyczna zajmuje się pierwszym pytaniem: jak to pytanie można przetłumaczyć na język naszych danych?
Systemy będą nadal pozyskiwać bazy danych, grafy, dokumenty, API oraz narzędzia, a same połączenia większej ilości danych nie wystarczą. Konieczne jest również połączenie znaczeń. Sztuczna inteligencja korporacyjna może coraz mniej polegać na dostarczaniu modelowi dodatkowych danych, a coraz bardziej na zapewnieniu mu jasnego zrozumienia tego, co te dane oznaczają.
Literatura pokrewna
- Poprawa systemu RAG za pomocą ontologii i grafu wiedzy w dokumentacji półprzewodnikowej — Jak zestaw dokumentacji EDA oparty na DITA otrzymał ontologię RDF/OWL, graf Neo4j oraz mechanizm wyszukiwania ograniczony ontologią, co przyniosło 30% mniej zapytań dodatkowych.
- Utrzymanie uczciwości sklepu wektorowego: cykl życia, dzierżawa, metadane, wyszukiwanie hybrydowe — Jak uruchomić sklep wektorowy do zastosowań RAG w środowisku produkcyjnym: zarządzanie stanami cyklu życia dokumentów, odświeżanie wektorów reprezentujących treści, filtrowanie według użytkowników, wyszukiwanie hybrydowe, schemat metadanych oraz śledzenie zapytań.