Ontologia czy warstwa semantyczna? Czego potrzebuje agent sztucznej inteligencji od obu.
W jaki sposób różnią się ontologie i warstwy semantyczne, co się dzieje, gdy istnieje tylko jedna z nich, gdzie pasują grafy wiedzy oraz praktyczna kolejność budowy warstwy kontekstowej.
Źródła: **Ontology vs. Semantic Layer: Why Your AI Agent Needs Both**
Zadaj jedno pytanie trzem źródłom na temat wysokości przychodów, a odpowiedzi często się różnią: 10,2 mln od działu finansów, 10,4 mln od działu marketingu, 9,8 mln od asystenta AI w Slacku. Nikt się nie zgadza. Kiedyś ludzie rozstrzygali takie kwestie podczas krótkiego spotkania. Agent nie będzie pytał kolegi z pracy o znaczenie danej miary, więc gdy napotka kolumnę o nazwie rev_ttm_adj_v2, wymyśla coś lub bierze pierwszą napotkaną definicję.
Podawanie zmodelowanych informacji z danej dziedziny do systemu wyszukiwania miało spowodować spadek częstości halucynacji o około 40%. Dotyczy to jednak tylko wtedy, gdy te informacje istnieją w zmodelowanej formie, a nie tylko w pamięci nielicznych osób, które stworzyły tabele. Objętość przechowywania i umiejętności agenta mają niewielkie znaczenie, jeśli pomiędzy nimi znajdują się tylko surowe tabele i zapytania SQL, ponieważ biznes nie będzie polegał na wynikach uzyskanych w ten sposób.
Szczegóły kontekstowe
Słownik kontekstowy określa nazwę funkcji, a nie produktu. Gromadzi definicje semantyczne, wiedzę z danej dziedziny, historię rozwoju, zasady zarządzania, wskaźniki jakości oraz status certyfikacji i udostępnia je za pośrednictwem jednej interfejsu zarówno dla ludzi, jak i agentów.
Tutaj główną rolę pełnią ontologie i warstwy semantyczne. Marketing dostawców często łączy je ze sobą, ale każda z nich rozwiązuje inny problem, a budowa ich w niewłaściwej kolejności skutkuje projektami AI, które wyglądają świetnie w demonstracji, ale zawodzą w fazie produkcji.
Rozdział zadań w jednym zdaniu
Wersja skrócona: warstwa semantyczna zajmuje się pytaniami typu, jaki był przychód, natomiast ontologia – pytaniami typu, czym właściwie jest klient.
Kwarstwa semantyczna odpowiada za metryki. Określa, w jaki sposób obliczane są przychody, liczba aktywnych użytkowników miesięcznie oraz wartość życiowa klienta, które dane należy wykorzystać oraz jakie filtry zastosować, aby wszystkie zespoły i narzędzia uzyskiwały identyczne wyniki.
Ontologia zajmuje się znaczeniem. Określa, co stanowi klienta, w jaki sposób klienci są powiązani z zamówieniami, co czyni kogoś klientem klasy Platinum oraz czy oprogramowanie może wyciągnąć nowe wnioski na podstawie już przechowywanych faktów.
Ontologia: koncepcje, relacje, rozumowanie
Klasyczna definicja, czyli wyraźna formalna specyfikacja wspólnej koncepcjonalizacji, składa się z trzech elementów:
- Klasy: typy entytetów w danym obszarze, na przykład Klient, Produkt, Zamówienie, Region.
- Właściwości i relacje: sposób, w jaki te elementy są ze sobą powiązane. Klient składa zamówienie, a produkt należy do określonej kategorii.
Ontologie są zapisywane zgodnie ze standardami W3C, takimi jak RDF i OWL, dzięki czemu maszyny mogą nad nimi rozumować, a także je czytać. Załóżmy, że ontologia stanowi, iż klient kategorii Platinum ma roczne przychody powyżej 1 miliona, a fakty wskazują, że Acme osiąga przychody 2 miliony. Silnik sam doskonale, że Acme należy do kategorii Platinum, przy czym nikt nie napisał żadnych warunków typu if-else. Warstwy semantyczne oraz narzędzia BI nie są w stanie tego zrobić – one wykonywają z góry zdefiniowane obliczenia i nigdy nie wyprowadzają faktów, które nie zostały zdefiniowane.
Ontologie łączą również słowniki pomiędzy systemami. CRM używa terminu Customer, ERP – Client, a działy finansowe – Account; ontologia mapuje je wszystkie na jeden obiekt biznesowy. Agent oparty w ten sposób kieruje się połączoną siecią grafową zamiast zgadywać na podstawie niepowiązanych tabel. W ochronie zdrowia standardem jest SNOMED CT, w usługach finansowych – FIBO, a w sektorach regulowanych formalna ontologia jest niemal obowiązkowa.
Cena jest równie oczywista. Palantir uczynił z ontologii przedsiębiorstw kategorię rynkową, jednak realizacja jest trudna: konieczni są inżynierowie wdrożeniowi, ręczne modelowanie, czas realizacji całego projektu wynosi od sześciu do osiemnastu miesięcy, a kadrę specjalistów od logiki formalnej brakuje.
Warstwa semantyczna: wskaźniki i liczby, które się zgadzają
Ten rodzaj pracy jest bardziej praktyczny. Już w latach 90. Business Objects wprowadziło Universe – narzędzie umożliwiające umieszczenie terminologii biznesowej przed skomplikowanymi schematami. Podstawowy problem pozostaje niezmieniony: przychody są obliczane na różne sposoby, dane się sprzeczają, a zaufanie spada. Dziś stawki są wyższe, ponieważ niezgodność mogła kiedyś doprowadzić do nieporęcznego slajdu, a teraz może skutkować sfabrykowaną liczbą w raporcie, który wpływa na podejmowane decyzje.
Współczesna warstwa semantyczna składa się z czterech elementów:
- Repozytorium metadanych, które mapuje np. mrr_calc_v3 na miesięczne przychody powtarzające się.
- Silnik logiki biznesowej, przechowujący formuły metryk w jednym miejscu, dzięki czemu są one definiowane raz i ponownie wykorzystywane.
- Tłumaczenie zapytań, które generuje operacje łączenia i filtrowania.
- Kontrola dostępu, zapewniająca spójne stosowanie uprawnień na poziomie wierszy i kolumn.
Narzędzia rozwijają się błyskawicznie. dbt dodało warstwę semantyczną opartą na MetricFlow, która przechowuje definicje metryk w formacie YAML pod kontrolą wersji i kompiluje je do różnych wariantów SQL. We wrześniu 2025 roku Snowflake, Salesforce, dbt Labs oraz BlackRock rozpoczęły projekt Open Semantic Interchange (OSI), a jego wersja 1.0 z grudnia 2026 roku zapewniła neutralny format do wymiany metadanych semantycznych. Produkty takie jak Cube, AtScale, LookML, DAX, Databricks Metric Views oraz Snowflake Semantic Views zmierzają w tym samym kierunku – mianowicie warstwa semantyczna staje się standardowym elementem infrastruktury danych przygotowanej do wykorzystania w sztucznej inteligencji.
Istnieje jednak ograniczenie. Warstwa ta może dokładnie określić, w jaki sposób obliczane są przychody, ale nie może wskazać, w jaki sposób klient łączy się z rynkiem i jego regulacjami, ani też czy konto zasługuje na oznaczenie jako wysokiego ryzyka zgodnie z zasadami domeny. Jessica Talisman w artykule dla Metadata Weekly dobrze to ujęła: warstwy semantyczne zajmują się wyszukiwaniem, a ontologie – kontekstem i rozumowaniem.
Co się psuje, gdy ma się tylko jedną
- Samodzielna warstwa semantyczna dostarcza dokładnych, ale powierzchownych odpowiedzi. Który kanał przyniósł najwyższą wartość GMV w zeszłym miesiącu? Odpowiedź jest precyzyjna. Dlaczego ta wartość spadła, czy wydatki powinny wzrosnąć? Milczenie, ponieważ nic nie modeluje wzajemnych powiązań między kanałami, wydatkami i profilami klientów.
- Ontologia sama w sobie dobrze opisuje koncepcje, ale zawodzi w kwestii danych liczbowych. Czy to Acme Platinum? Rozsądne rozumowanie. Co przyniosło Acme w zeszłym miesiącu? Znów trzy sprzeczne odpowiedzi, ponieważ system nie zawiera żadnych wskazówek dotyczących tabeli faktów ani reguł agregacji.
Dane z branży potwierdzają to. Gartner przewiduje, że do końca 2027 roku ponad 40% projektów opartych na sztucznej inteligencji zostanie porzuconych z powodu wysokich kosztów, niejasnej wartości i niewystarczających mechanizmów kontroli. Wśród 248 liderów zarządzania danymi, których przepytano, 63% przyznało, że brakuje im praktyk niezbędnych do wspierania sztucznej inteligencji. Rzadko model jest przyczyną problemów; dane, na których się opiera, nie mają żadnego semantycznego uzasadnienia.
Momentum rozwija się również w przeciwnym kierunku. Przewidywania Gartnera dotyczące szczytu w 2026 roku wskazują na to, że do 2030 roku uniwersalne warstwy semantyczne połączą platformy danych z bezpieczeństwem cybernetycznym jako kluczową infrastrukturę, natomiast Futurum przewiduje wzrost ich adopcji z 16% w tym roku do 30% w 2031 roku. Microsoft prezentuje wbudowaną obsługę ontologii w Fabric IQ, podczas gdy Timbr.ai sprzedaje warstwy semantyczne z dodanym mechanizmem rozumowania. Obie te metody zmierzają w tym samym kierunku.
Grafy wiedzy i taxonomie
Graf wiedzy przechowuje instancje, więc rzeczywiści klienci i zamówienia pojawiają się jako węzły. Ontologię można traktować jako schemat, a graf wiedzy jako same dane. Agent, który na bieżąco analizuje relacje, porusza się po tym grafie.
Taksonomia to uproszczona ontologia: hierarchie rodziców i dzieci, bez żadnych wnioskowań ani połączeń bocznych. Katalogi produktów, klasyfikacja domen danych oraz tagowanie PII zazwyczaj zaczynają się od tego, co stanowi dobry punkt wyjścia. Pełna ontologia staje się konieczna dopiero wtedy, gdy agent musi rozumować między kategoriami, na przykład sprawdzając, czy obniżka rangi w kategorii A wpływa na zapasy w kategorii B.
Jak wszystko się łączy
Szczegóły kontekstu dzielą się na dwie części:
- Kontekst danych: ontologia, warstwa semantyczna, graf wiedzy, ścieżki pochodzenia, wskaźniki jakości oraz polityka dostępu. Informuje sztuczną inteligencję o branży, w której działa.
- Kontekst aplikacji: preferencje użytkownika, historia rozmów, dokumenty z danej dziedziny oraz pozyskane fakty (pamięć w połączeniu z RAG). Informuje sztuczną inteligencję o osobie, z którą rozmawia.
Jedno pytanie przechodzi przez cztery etapy:
- Ontologia definiuje koncepcję taką jak rozpoznawanie przychodów wraz z dołączonymi do niej zasadami.
- Szczegół warstwy semantycznej przekształca to w operacje obliczeniowe: które tabele należy połączyć i jak je agregować.
- Graf wiedzy łączy daną koncepcję z jej wskaźnikami, historią powstawania oraz użytkownikami końcowymi.
- MCP dostarcza kontekst agentowi w momencie wyciągania wniosków.
Tutaj łączą się dwuletnie dyskusje na temat projektowania kontekstu: niezawodny wynik wymaga ustrukturyzowanego kontekstu, a ontologie oraz warstwy semantyczne stanowią dwa najtrudniejsze elementy. MCP rozwiązuje problem dostarczania kontekstu, a nie samego jego treści. Jeśli dać agentowi niekontrolowane tabele i zapytania SQL, protokół wiernie przekaże efekt halucynacji.
Podejście jednego dostawcy
Jeden z dostawców baz danych opisuje swoje rozwiązanie jako otwartą warstwę semantyczną, nazywaną również OSI, która łączy metryki, definicje, surowe dane, graf kontekstowy oraz ontologię zamiast kolejnej warstwy semantycznej BI. Składa się ona z trzech warstw:
- Na dole znajduje się warstwa semantyczna: definicje metryk, reguły obliczeń oraz powiązania między wymiarami a danymi. Opiera się na standardzie Ant-OSI, jest kompatybilna z branżowym standardem OSI i jest już używana w produkcji w Ant Group.
- W środku znajduje się graf kontekstowy: metryki, obiekty, zdarzenia, łańcuchy przekazywania danych oraz użytkownicy połączeni w sieć, nad którą model językowy o dużej mocy rozumowania pracuje znacznie lepiej niż przy użyciu surowych schematów lub plików YAML.
- Na górze znajduje się warstwa ontologiczna: semantyka biznesowa dostosowana do semantyki bazy danych, z terminami lokalnymi dla poszczególnych obszarów pracy oraz koncepcjami obejmującymi całą firmę, które są ze sobą powiązane i rozwijane zgodnie z własnym harmonogramem.
Zasada leżąca u jego podstaw jest semantyczna, podobnie jak kod. Definiuje się semantykę raz, a następnie pozwala narzędziom BI tworzyć panele kontrolne, agentom pisać zapytania SQL, a narzędziom zarządzania śledzić linie przekazu – wszystko na podstawie tej samej definicji, bez odrębnych semantyk dla BI, AI i zarządzania. W testach klientów tego dostawcy dokładność przekładu języka naturalnego na dane znacznie przewyższała alternatywy. Twierdzi się, że modele nie odróżniają produktów, ponieważ wszyscy nazywają to samo rozwiązanie LLM; to jakość kontekstu semantycznego ma znaczenie. Użycie poprawnych definicji biznesowych zamiast surowych tabel poprawia dokładność przekładu z języka naturalnego na SQL bardziej niż dostosowywanie promptów.
Od czego zacząć
Należy zacząć od warstwy semantycznej, gdy:
- Zespoły nie są zgodne co do tego, co oznacza przychód lub aktywny użytkownik.
- Projekt dotyczy analizy konwersacyjnej lub rozmów z danymi.
- Stack danych jest już scentralizowany, a wyniki są oczekiwane w ciągu dwóch do sześciu miesięcy.
Należy rozpocząć od ontologii w następujących sytuacjach:
- Organizacja działa w sektorze finansów, ochrony zdrowia lub administracji publicznej, z surowymi wymogami dotyczącymi przestrzegania regulacji.
- Sztuczna inteligencja musi rozumować dane w różnych domenach, np. według klienta, produktu czy przepisów.
- Jeden koncept ma różne nazwy w kilku systemach.
- Potrzebna jest automatyczna klasyfikacja lub wykrywanie anomalii na podstawie reguł.
Dla większości przedsiębiorstw praktyczny porządek działań jest następujący:
- Najpierw stworzyć warstwę semantyczną, scentralizując kluczowe metryki, aby narzędzia BI i AI korzystały z identycznych definicji.
- Na początku utrzymać ontologię w prostej formie, jako glosariusz biznesowy, a nie pełne rozwiązanie typu OWL.
- Dodać elementy zarządzania: ścieżki pochodzenia danych, oceny jakości, określenie właściciela oraz certyfikację.
- Ujawnij wszystko agentom przez MCP, co przekształca warstwę kontekstową z diagramu w infrastrukturę.
dbt nie dostarczy ontologii, a ontologia w stylu Palantir nie nadaje się do każdego zespołu. Rozwój od glosariusza w kierunku formalnej ontologii jest o wiele bardziej realistyczny niż próba załatwienia wszystkiego od razu.
Własny plan rozwoju dostawcy pokazuje ten sam stopniowy podejście. W krótkim terminie warstwa semantyczna dociera do każdego miejsca pracy, oferując centralnie zarządzane metryki oraz możliwość wyszukiwania terminologii. W średnim terminie pojawiają się glosariusze, hierarchie kategorii i relacje między entytetami, najpierw w formie taksonomii, a następnie zyskują one spójność między systemami oraz możliwości podstawowego rozumowania, rozwijając się obszar po obszarze. Pytanie długoterminowe brzmi: co się stanie, gdy domeny, które modelowały swoją semantykę oddzielnie, będą musiały ją połączyć, oraz jak zapewnić, by definicje lokalne i globalne były nadal rozwijalne.
Literatura pokrewna
- Dlaczego agenci AI potrzebują warstwy zarządzania, a nie tylko lepszych promptów — Prompty kształtują pojedynczą wymianę informacji, a nie cały proces pracy. Jak warstwa zarządzania oparta na regułach, określonym kontekście, ograniczeniach uprawnień oraz potwierdzeniu ukończenia pracy sprawia, że agenci programistyczne są niezawodne.
- Dlaczego pamięć agenta programistycznego powinna przechowywać tylko zmiany oraz jak ją przechowywać — Pamięć agenta powinna rejestrować tylko to, czego model nie mógł odgadnąć. Cztery testy dla każdej wpisywanej informacji, trzy wymagania dotyczące przechowywania oraz dlaczego markdown pasuje do gitu.