Agenci potrzebują interpretowalnych znaczeń: warstwy semantyczne, ontologie i kontrolowane metryki

Wyobraź sobie codzienne spotkanie w poniedziałek. Kolega z zespołu wkleja odpowiedź agenta do Slacka: przychód na klienta z poprzedniego kwartału, starannie sformatowany, krótko wyjaśniony i przedstawiony z pełną pewnością siebie. Jedno spojrzenie ze strony działu finansów i rozmowa się zatrzymuje. Ta liczba odnosi się do rezerwacji, podczas gdy uznany przychód jest przechowywany w innej tabeli o innej strukturze i z własną listą wykluczeń. Z SQL nie było żadnego problemu. Nikt nie ustalił dokładnie, co oznacza to pytanie.

Po wystarczającej liczbie takich sytuacji stwierdzenie „model wygenerował poprawny SQL” przestaje być uważane za sukces. Modele językowe sprawiły, że niemal wszystkie dane magazynowe stały się czytelne dla maszyn. Czytelność jest tania. Interpretowalność jest tym rzadkim elementem: co oznaczają takie pojęcia jak klient, przychód, aktywność, odejścia klientów oraz poprzedni kwartał w danej firmie, przy podejmowaniu konkretnej decyzji.

Zanim pojawiły się agenty, osoba ta tłumaczyła zapytania przed ich napisaniem. Przekazanie tego zadania agentowi w czasie wykonywania aplikacji pozwala mu wymyślić wiarygodną historię, chyba że dostarczono już przygotowaną. Trwałym rozwiązaniem jest zarządzanie znaczeniem w przedsiębiorstwie jak produktem: nadanie mu tożsamości, wersjonowanie, testowanie, powiązanie z danymi fizycznymi oraz umożliwienie ludziom i oprogramowaniu korzystania z niego w identyczny sposób.

Dla większości zespołów krokiem końcowym jest zorganizowana warstwa semantyczna lub metryczna. Dłuższym celem jest model oparty na ontologii, który kompiluje późniejsze projekcje – czy to LookML, widoki SQL, umowy API czy narzędzia agentów – tak aby żaden produkt nie musiał wymyślać własnej „prawdy”.

Dlaczego pewna odpowiedź stanowi ryzyko

BI oparte na czacie jest często opisywane jako przekład z języka naturalnego na SQL, co jest określeniem ukrywającym trudną część zadania. Trudna część polega na odczytaniu pytania w jednym kontekście i przeniesieniu jego znaczenia do innego.

Rozważmy pytanie: „Jaki był przychód od poszczególnych klientów w zeszłym kwartale?”. Dla magazynu wykonanie precyzyjnego zapytania jest łatwe. Trudność polega na wyborze tego zapytania, które najlepiej odpowiada pytaniu. Przychód może oznaczać zamówienia, faktury lub uznany przychód. Klientem może być strona, do której dokonano sprzedaży, strona, do której wysyła się fakturę, lub dowolny węzeł hierarchii kont, który pojawia się w kwartalnych sprawozdaniach sprzedaży. Zeszły kwartał może odnosić się do miesięcy kalendarzowych, roku finansowego lub okna czasowego preferowanego przez dział operacyjny.

Na panelu kontrolnym analityk już dokonał tych decyzji. Płytka o nazwie „Przychód” wydaje się wiarygodna, ponieważ decyzja semantyczna jest wbudowana w sam element interfejsu. W przypadku czatu kolejność jest inna – decyzja podejmowana jest w czasie rzeczywistym, dla dowolnych pytań, wewnątrz oprogramowania, co przekształca semantykę z strony wiki w infrastrukturę działającą w czasie rzeczywistym.

Nieprzyjemną konsekwencją jest to, że im lepiej model radzi sobie z wiarygodnym SQL, tym bardziej niebezpieczne stają się jego błędy. Poprawność składniowa nic nie mówi o semantycznej ważności. Dobrze sformułowane wyjaśnienie może tak płynnie odpowiedzieć na niewłaściwe pytanie, że nikt tego nie zauważy, dopóki zestaw danych nie będzie sprzeczny z zapisami z czatu. Zespoły, które pytają jedynie o to, czy zapytanie zostało wykonane, uczą się ufać płynnej, lecz błędnej informacji.

Modele wymiarowe już zawierają pewne znaczenie

Nic z tego nie czyni magazynu czystą kartką. Modelowanie wymiarowe w stylu Kimballa od dziesięcioleci próbuje nadrobić braki ogólnych schematów relacyjnych. Fakty, wymiary, miary, struktura danych, hierarchie oraz wymiary dostosowane – wszystko to wprowadza biznesowe znaczenia do struktur, którymi ludzie mogą przeprowadzać zapytania.

Dobrze zaprojektowana schematologia gwiazdowa już sama w sobie pełni rolę nieformalnej warstwy semantycznej. Współczesne warstwy semantyczne dodają jeszcze więcej – definicje metryk, reguły obliczeń, terminologię, dozwolone relacje oraz reguły biznesowe, których nazwy kolumn nie mogą ujawnić. Formalna ontologia idzie jeszcze dalej, oddzielając model koncepcyjny od jego implementacji relacyjnej i celowo tworząc mapowanie pomiędzy nimi.

Najlepiej postrzegać to jako ciągłość, a nie proces konwersji:

• schematologia relacyjna operacyjna
• model wymiarowy
• warstwa semantyczna
• ontologia formalna

Im niżej w liście, tym więcej znaczeń jest zapisywanych, a model musi mniej zgadywać. Każdy element pozostawiony w formie domyślnej to zakład, że wnioski będą odpowiadać definicji, której przysiągłby zaufanie dyrektor finansowy.

To, co pokazują badania

Niedawne badania nad przekładem tekstu na SQL wskazują na jeden wspólny wynik. Jasne określenie znaczenia biznesowego zwiększa dokładność, i dotyczy to nawet schematów już stworzonych do analizy.

W teście przeprowadzonym przez Figueiredo i współpracowników użyto GPT-4 Turbo na schemacie typu gwiazda. Sam schemat generował około 58% poprawnych zapytań, a dodanie semantyki kontekstowej podniosło ten wskaźnik do około 89%. Rumiantsau i Fokeev dodali krótki dokument semantyczny do modelu magazynu analitycznego opartego na Contoso, co sprawiło, że dokładność wzrosła z około 48 do 52 procent, osiągając poziom powyżej sześćdziesięciu procent. Te poprawy są istotne, ponieważ punkty odniesienia nie stanowiły chaotycznych schematów transakcyjnych.

Gdy fizyczny schemat mówi niewiele o biznesie, skutki stają się coraz większe. Painter i jego koledzy pracowali nad bazą danych operacyjną zawierającą ponad 500 tabel i zwiększyli stopień generowania zweryfikowanych zapytań SQL z około 8% do około 78%, dostarczając odpowiednią terminologię, reguły, relacje oraz mapowania. Nascimento i jego współpracownicy zaobserwowali wzrost dokładności wykonywania zadań w złożonej bazie danych przemysłowej z 41% do 65% dzięki użyciu nazw koncepcyjnych ukierunkowanych na potrzeby biznesu, a do 74%, gdy dodatkowo zostały uwzględnione istotne semantyki relacji.

Formalne modele wykazują podobny kierunek rozwoju. W jednym z badań przeprowadzonych przez Sequedę, Allemanga i Jacoba, bezpośrednie zadawanie pytań bazie danych relacyjnej przyniosło dokładność około 17%, natomiast korzystanie z grafu wiedzy wspieranego ontologią dało wynik około 54%. W kolejnym badaniu Nascimento nadal używał SQL do wykonywania zadań, ale najpierw zastosował graf wiedzy w celu powiązania koncepcji biznesowych z fizycznym schematem. Mierząc dokładność za pomocą wskaźnika F1, sam model językowy osiągnął wynik około 0,85. Podejście oparte na grafie dało wynik 0,90, połączenie grafu z modelem językowym – 0,93, a pełny proces powiązania semantycznego z doskonałą pamięcią przywoływania – 0,996.

Rozsądna interpretacja jest taka, że chodzi o aspekty architektoniczne, a nie promocyjne: należy uczynić jawnym powiązanie między koncepcjami a strukturami relacyjnymi, odebrać modelowi możliwość improwizacji semantycznej i pozostawić wykonywanie zadań w silniku relacyjnym, gdzie już dobrze funkcjonuje.

Co osiągnął, a czego nie osiągnął model relacyjny

Model relacyjny Codd’a zapewnił niezależność od danych: aplikacje nie powinny zależeć od sposobu fizycznego przechowywania danych. To osiągnięcie pozostaje istotne do dziś.

BI oparte na rozmowach wymaga czegoś bardziej konkretnego i trudniejszego do zrealizowania. Sam schemat analityczny relacyjny nie określa sam w sobie wszystkich znaczeń biznesowych potrzebnych do odpowiedzi na pytanie. Nazwy, klucze, ograniczenia i komentarze pomagają, a modele wymiarowe jeszcze bardziej. Mimo to definicje metryk, role pełnione przez poszczególne elementy, konwencje czasowe, informacje o pochodzeniu danych oraz zasady łączenia koncepcji z obiektami fizycznymi nadal często znajdują się w umysłach ludzi lub na slajdach prezentacyjnych.

Dlatego wokół magazynów powstały glosariusze, magazyny metryk, warstwy semantyczne oraz katalogi. Stopniowo ujawniają one to, co analityk lub model językowy typu LLM w przeciwnym razie musiałby wymyślić improwizowanie. Współczesna warstwa semantyczna stanowi praktyczne rozwiązanie w miejscu, gdzie wykorzystywane są narzędzia BI. Pozostaje węższa niż ogólny model koncepcyjny przedsiębiorstwa, a traktowanie ich jako identycznych powoduje, że zespoły później są zaskoczone.

Dodawanie ontologii przy zachowaniu magazynu

W praktyce informatycznej ontologia opisuje to, co istnieje w danym obszarze zainteresowań – czyli entity, relacje i ograniczenia – sformułowane w taki sposób, aby oprogramowanie mogło je wykorzystać. Ma wspólne korzenie z modelem relacyjnym w logice predykatywnej: stanowią one stwierdzenia o rzeczach oraz relacjach między nimi.

Bazy danych od dawna pracują nad tym problemem. W3C Direct Mapping oraz R2RML określają, w jaki sposób dane relacyjne przekształcają się w słowniki RDF. Ontology-Based Data Access idzie o krok dalej: użytkownik formułuje zapytania do modelu koncepcyjnego, a system przekłada je na zapytania SQL wykorzystujące już istniejące źródła danych. Ontop, dojrzała otwarta grafika wiedzy wirtualnej, robi dokładnie to samo za pomocą mapowania R2RML oraz lekkich ontologii OWL 2 QL.

Wybór OWL 2 QL ma mniej efektowne, ale praktyczne uzasadnienie. Należy do rodziny DL-Lite, której ograniczenia są celowe, aby zapytania przetwarzane za pomocą ontologii pozostały zarządzalne wobec dużych baz danych relacyjnych. Zrezygnowano z mocy wyrażeniowej w zamian za możliwość przepisania kodu na SQL. Prace nad ontologiami dla magazynów i modeli wielowymiarowych rozpoczęły się jeszcze wcześniej i obejmują reprezentację wymiarów, miar oraz hierarchii oraz wyprowadzanie struktur analitycznych z modeli koncepcyjnych.

To, co nadal ma niewielką widoczną popularność, to język ontologiczny skierowany bezpośrednio do nowoczesnych narzędzi BI, który umożliwia przechowywanie jednostek biznesowych, relacji, miar, poziomu szczegółowości, agregacji, czasu, informacji o pochodzeniu oraz mapowania magazynów w jednym, uporządkowanym modelu.

Przyjęcie tego rozwiązania nie oznacza przenoszenia magazynu do bazy danych grafowych. Znaczenia można opisać w ontologii, podczas gdy fakty pozostają w tabelach relacyjnych, a obliczenia w SQL. Materializacja grafu jest opcjonalna, przydatna dla obciążeń pracy, które od niej korzystają, i nie stanowi kryterium oceny.

Zapisane fakty i to, co oznaczają

Wiersze i trojki RDF są ze sobą bliżej spokrewnione, niż sugerują różnice pomiędzy narzędziami. Wiersz wskazuje, że tupla należy do określonej relacji, natomiast trojka dzieli propozycję na podmiot, predykat i obiekt. Silna normalizacja już teraz skłania projektowanie relacyjne ku mniejszym faktom. Choć oba podejścia nie są formalnie równoważne, ich podobieństwo jest przydatne.

Dla agentów istotne rozróżnienie to nie tabela kontra graf. Chodzi o dane ekstensjonalne kontra znaczenie intencjonalne: fakty, które są przechowywane, oraz reguły określające, co te fakty oznaczają. Ontologia może stwierdzić, że jedna klasa zawiera się w innej, że dwa predykaty są odwrotnymi, że relacja jest transytwna lub że określona kombinacja jest niemożliwa. OWL zapewnia formalną semantykę dla takich stwierdzeń, SHACL weryfikuje struktury grafów, a istnieją również bardziej zaawansowane ramy logiczne do wykorzystania w takich przypadkach.

Nie każda ontologia daje się łatwo przepisać na SQL, ponieważ niektóre języki są bardziej wyrażalne, niż mogą obsłużyć efektywne fragmenty przepisania. Badania w dziedzinie OBDA otwarcie stawiają czoła temu problemowi, oferując opcje ograniczania wyrażalności, aproksymacji, materializacji lub przeprowadzania rozumowań w oddzielnym kroku. To ograniczenie jest przydatne, ponieważ zmusza do jasnego określenia, które semantyki obowiązują na ścieżce wykonywania, które są kompilowane z góry, a które wykraczają poza wybrany profil. Niewiele firm dziś rejestruje takie straty, więc objawiają się one jako kłótnie w kanałach czatowych.

Kontekst dostawcy to nie twoja ontologia

Dostawcy już podejmują działania. Google Cloud stanowi przykład tego zjawiska, ponieważ kilka z jego wersji z 2026 roku skupia się na środowisku korporacyjnym, które mogą wykorzystywać maszyny. Dataplex Universal Catalog został przekształcony w Knowledge Catalog i funkcjonuje bardziej jak żywy graf kontekstowy niż statyczny rejestr. Oferuje on wyszukiwanie semantyczne, wzbogacone opisy, grafy relacji, zweryfikowane wzory SQL, API kontekstowe oraz ścieżki dostępu dla agentów. Tymczasem interfejs Open SQL w Looker umożliwia klientom JDBC przeprowadzanie zapytań do modeli LookML tak, jakby były to schematy, przy ponownym wykorzystaniu już tam zdefiniowanych wymiarów, agregatów, obliczeń i relacji.

Takie rozwiązania podkreślają podstawową kwestię: agent potrzebuje czegoś więcej niż tylko dostępu do wierszy danych. Potrzebuje starannie przygotowanego kontekstu, modeli semantycznych, relacji, zweryfikowanych przykładów oraz zintegrowanych interfejsów.

Mimo to brakuje im spójnej ontologii przedsiębiorstwa. Semantyka LookML, terminy katalogowe, definicje grafów w BigQuery oraz kontekst napisany przez agenty to powiązane, lecz odrębne reprezentacje. Jeśli organizacja nie posiada kanonicznych identyfikatorów oraz wyraźnych map między nimi, obietnica jednorazowego zdefiniowania czegoś zamienia się w konieczność definiowania tego dla każdego produktu osobno.

Kilka kwartałów zostało straconych z powodu tej pułapki. Graf kontekstowy dostawcy może być bardzo cenny, ale nie musi stanowić formalnego źródła prawdy semantycznej. Można go swobodnie przyjąć, pamiętając jednak, że przyjęcie nie oznacza posiadania.

Sześć zasad projektowania

Zasada, która stoi ponad wszystkimi innymi, jest taka, że znaczenie musi być czytelne zarówno dla ludzi, jak i maszyn, a także musi pozostać spójne we wszystkich reprezentacjach.

Nadaj znaczeniu tożsamość. Każdy pojęcie, związek, metryka, zasada oraz stwierdzenie dotyczące jakości powinien mieć stabilny identyfikator. Nazwa to jedynie etykieta, natomiast identyfikator stanowi to, czym jest sam obiekt. Termin „klient” pojawia się na panelach sterowania, w API, w tabelach magazynowych oraz w komunikatach dla agentów, a wszystko to powinno odnosić się do jednego obiektu semantycznego, lub świadomie do odrębnych obiektów, jeśli w biznesie rzeczywiście istnieją oddzielne koncepcje. Dział obsługi klienta i finanse mogą definiować „aktywnego klienta” inaczej, pod warunkiem że nigdy nie będą dzielić się tym samym identyfikatorem bez wyraźnego powiedzenia o tym.

Uczynij definicje wykonywalnymi. Proza służy ludziom i modelom, ale wszystko, co wpływa na obliczenia, wymaga struktury: typów, związków, kardynalności, jednostek, wzorów, granulacji, okresu ważności, ograniczeń, reguł mapowania oraz zasad. Opisowy akapit w katalogu jest w dużej mierze konwencją ludzką.

W architekturach opartych na Google Cloud jedno możliwe rozwiązanie wygląda następująco. Knowledge Catalog przechowuje informacje o tożsamości, definicjach, jednostkach, właścicielu, okresie ważności, zasadach, relacjach oraz mapowaniach. LookML zawiera formuły wykonywalne, wymiary, operacje łączenia oraz mechanizmy generowania zapytań. Conversational Analytics interpretuje język naturalny w kontekście tych danych, przy czym zweryfikowane zapytania służą jako punkty odniesienia do analizy regresji. Taka struktura jest możliwa tylko wtedy, gdy identyfikatory celowo przekraczają granice pomiędzy poszczególnymi elementami.

Jasno powiązuj semantykę z danymi fizycznymi. Załóżmy, że ontologia stwierdza, iż Klient posiada Konto. W takim przypadku implementacja musi określić nazwę relacji lub procesu, który sprawia, że to stwierdzenie jest prawdziwe, a mapa ta powinna być wersjonowana wraz z obiema jej stronami. Żaden narzędzie jednym kliknięciem nie przekształca OWL w każdy produkt katalogowy. Ktoś musi stworzyć i utrzymywać tę „mostek”, w przeciwnym razie pojęcie semantyki oznacza niewiele więcej niż prostą markę.

Traktuj relacje jako elementy pierwszej klasy. Rola nabiera znaczenia dzięki swoim powiązaniom z procesami, organizacjami, działaniami, zdolnościami i kosztami, a nie dzięki kolumnie o nazwie role_type. Klienci, produkty, umowy, konta i metryki funkcjonują w ten sam sposób. Niewłaściwe nazewnictwo i prozaiczny styl już pomagają przy przekształcaniu języka naturalnego w SQL, ale to formalna semantyka relacji odróżnia wygodę modeli relacyjnych od jasności ontologicznej. Ich opracowanie wymaga rzeczywistego wysiłku, a ontologia, która ignoruje ten koszt, ponosi porażkę już na etapie testów pilotażowych.

Zachowuj metryki w obrębie tego samego modelu. Miary wymiarowe już zawierają informacje o tożsamości, formule, strukturze danych oraz zachowaniu agregacji, a warstwy semantyczne umożliwiają lepsze wykorzystanie tych elementów. Szersze znaczenie tych metryk, obejmujące kwestie właściciela, jednostek miary, wykluczeń, pochodzenia danych, zasad stosowania, dat wejścia w życie oraz powiązań z koncepcjami biznesowymi, ma tendencję do przenoszenia się do innych systemów. Fragmentacja jest często rzeczywistym problemem architektonicznym: miara wymiarowa, miara typu LookML oraz termin z katalogu opisują każda z osobna część tej samej koncepcji biznesowej, lecz pod trzema różnymi tożsamościami.

Kompiluj raz, udostępniaj na wiele sposobów. Jeden kanoniczny model powinien generować lub regulować swoje projekcje, takie jak LookML, widoki SQL, schematy API, wpisy w katalogu, kształty grafów, umowy narzędziowe dla agentów, dokumentację oraz testy walidacyjne. Platformy mogą zachować własną składnię, ale nie powinny same wymyślać jej znaczenia.

LinkML pokazuje, że model niezależny od technologii może wytwarzać SQL DDL, BigQuery DDL, JSON Schema, OpenAPI, OWL, SHACL, dokumentację oraz narzędzia do weryfikacji. Nie może jednak samodzielnie wybrać faktów, wymiarów, miar, poziomu szczegółowości ani zgodnych wymiarów w imieniu kogokolwiek. Istnieją badania nad przekształcaniem ontologii w schematy typu star, ale żaden powszechnie używany proces nie obejmuje całego szlaku – od kanonicznej ontologii, przez zarządzany magazyn wymiarów i wykonywalny model semantyczny, aż po przekład tekstu naturalnego na SQL oparty na ontologii. Właśnie w tym brakującym etapie leży największe wyzwanie inżynieryjne, a wytwarzanie DDL to jedynie prosta demonstracja tego możliwości.

Dwie drogi i potrzeba integracji

Większość przedsiębiorstw nie może wstrzymać programu magazynowego i najpierw odbudować go w oparciu o ontologię. To nie problem. Zadaniem jest sprawienie, by agent w sposób niezawodny rozumiał, co można wysłać, oraz zaprojektowanie takiej taktyki, aby mógł osiągnąć pełną sprawność.

Zgodnie z Planem A, kanoniczna ontologia przedsiębiorstwa posiada autorytet semantyczny, dzięki stabilnym identyfikatorom i wyraźnej semantyce logicznej. Dane fizyczne się nie zmieniają, a ontologia jest mapowana na reprezentacje relacyjne i inne. Wskaźniki analityczne stają się skompilowanymi prognozami. Agenci pobierają formalne koncepcje, relacje, zasady oraz informacje o pochodzeniu, a zmiany są wersjonowane i wypuszczane w taki sam sposób jak kod. Reprezentacje zawarte w produktach są generowane na podstawie semantyki należącej do przedsiębiorstwa lub są do niej mapowane.

Plan B rozpoczyna się od już zajmowanego obszaru: warstwa metryk zarządzanych w połączeniu z katalogiem i modelem kontekstowym, do których celowo dodawane są stabilne identyfikatory kanoniczne. Magazyn pozostaje źródłem autorytetu, a mapowanie obiektów semantycznych na tabele, kolumny, połączenia i filtry jest zapisywane. Agenty wybierają certyfikowane pola i metryki zamiast surowych tabel, czerpiąc kontekst z usług kontekstowych, zweryfikowanych zapytań oraz mechanizmów wyszukiwania, które respektują uprawnienia. Metryki, mapowania, „złote pytania” oraz testy regresji semantycznej są włączane do procesu CI/CD. Identyfikatory lokalne dla danego produktu nigdy nie stają się tożsamościami przedsiębiorstwa, a mechanizmy przekierowań umożliwiają migrację.

Konkretny Plan B w Google Cloud łączy Knowledge Catalog, który zapewnia kontekst i ułatwia znajdowanie informacji, z Lookerem – tam zarządzany model semantyczny dostosowuje analizę konwersacyjną do certyfikowanych obiektów semantycznych, przechowuje zweryfikowane zapytania jako punkty odniesienia do analiz regresji oraz przechowuje identyfikatory przedsiębiorstwa poza jakimkolwiek pojedynczym produktem. Knowledge Catalog przypomina ontologię jedynie w wąskim sensie, oferując typowane konteksty i relacje dla agentów, ale nie stanowi kompletnego formalnego systemu ontologicznego. Traktuj go jak materiał budulcowy, a nie jak święte pisma.

Ryzykiem jest taki poziom semantyczny o charakterze taktycznym, którego identyfikatory i logika nigdy nie mogą zostać przeniesione do bardziej formalnego modelu. Plan B, który nie może dojść do konwergencji, to ślepa uliczka przyozdobiona panelami analitycznymi.

Najpierw rozwiąż problem, potem zajmij się tabelami

Poprawna ścieżka w zakresie analityki konwersacyjnej nie powinna zaczynać się od wyboru tabel – powinna zaczynać się od rozwiązania problemów semantycznych.

Weźmy pytanie „Czy w tym kwartale wzrosła rotacja wśród klientów detalicznych o wysokiej wartości?”. Terminy takie jak rotacja, klienci detaliczni o wysokiej wartości oraz ten kwartał muszą najpierw zostać przekształcone w zarządzane obiekty. Te obiekty zawierają definicję metryki, klasyfikację, konwencję czasową, dozwolone wymiary, mapowania źródeł oraz zasady funkcjonowania. Dopiero potem warstwa wykonawcza może sformułować fizyczną zapytanie.

Zespoły zajmujące się pętlami powinny być w stanie opisać proces w ośmiu krokach:

1. Pytanie i kontekst użytkownika
2. Przekształcenie semantyczne na zarządzane koncepcje i metryki
3. Pobieranie kontekstu z filtrowaniem według zasad i uprawnień
4. Mapowanie obiektów semantycznych na dane fizyczne
5. Generowanie zapytania lub planu narzędziowego
6. Wykonanie i weryfikacja
7. Odpowiedź poparta dowodami i źródłami

Regresja lub ocena semantyczna, wraz z sterowanymi działaniami tam, gdzie to stosowane

Podejście to dalekie jest od prostego wklejenia schematu analitycznego do instrukcji i oczekiwania na rezultat. LLM nadal może wyjaśnić intencję i stworzyć plan, ale robi to poprzez sterowane obiekty semantyczne oraz umowy narzędziowe, a nie poprzez dekodowanie słownictwa CFO z tabeli o nazwie fct_rev_v3.

Weryfikowane zapytania są cenne jako testy i przykłady, ale nie stanowią samej semantyki. Potwierdzają jedynie, że określone pytanie w danym momencie doprowadziło do przyjętej implementacji. Podlegająca im znaczenie nadal wymaga własnej tożsamości i definicji.

Co nie stanowi architektury semantycznej

Katalog pełen opisów prozatorskich ułatwia odkrywanie informacji. Nie jest to wykonywalny system semantyczny.

Domyślnie wskazywanie narzędzi na surowe schematy magazynowe i nazywanie tego samousługowym BI jedynie przenosi ryzyko semantyczne na model probabilistyczny.

Kopiowanie każdej informacji o magazynie do grafu wiedzy „dla AI”, bez wyraźnych korzyści z jego wykorzystania, tworzy drugą wersję prawdy przedsiębiorstwa, która jest w tyle z powodu opóźnień synchronizacji.

Całkowite oddzielenie metryk od ontologii w taki sposób, że jeden koncept biznesowy ma sprzeczne identyfikatory w BI i modelach wiedzy, prowadzi do konfliktów w przyszłości.

Pomylenie reprezentacji z semantyką, na przykład poprzez założenie, że graf jest z natury bardziej semantyczny niż model wymiarowy, to sposób myślenia typu cargo cult. Modele wymiarowe, warstwy semantyczne, grafy wiedzy i ontologie każdy w różnym stopniu kodują znaczenie, a sam wybór grafu nie dodaje sam w sobie znaczenia.

Traktowanie metadanych lub relacji wygenerowanych przez sztuczną inteligencję jako faktów, bez podania źródła lub statusu weryfikacji, sprawia, że pozornie wiarygodna fikcja przekształca się w politykę.

Cel w jednym zdaniu

Ludzie chcieliby uzyskiwać dane z zeszłego miesiąca tak swobodnie, jak pytają o pogodę. To już nie jest fantazja. Oprogramowanie przejmuje zadania semantyczne, które kiedyś wykonywali analitycy i inżynierowie bez żadnej uwagi, a uzyskiwanie spójnych odpowiedzi wymaga ujawnienia tych działań.

Ani LLM zainstalowane w magazynie, ani katalog połączony z wyszukiwaniem wektorowym nie stanowią ostatecznego rozwiązania. Chodzi o zorganizowany system semantyczny, w którym pojęcia, relacje, metryki, ograniczenia, zasady, jakość i źródło zachowują jednoznaczne znaczenie zarówno dla ludzi, jak i maszyn, powiązane formalnymi mapami z danymi leżącymi u ich podstaw.

Znaczna część danych leżących u podstaw nadal najlepiej przetwarza się za pomocą silników analitycznych relacyjnych i SQL, a technologie semantyczne lub ontologiczne nie są w stanie je zastąpić. Ich zadaniem jest doprowadzenie modelu do poziomu, którego sam schemat relacyjny nigdy nie był zaprojektowany, by samodzielnie obsłużyć, nawet po zastosowaniu modelowania wymiarowego i starannego nadawania nazw w maksymalnym możliwym stopniu.

Gdy tworzenie i utrzymywanie kompletnej ontologii analitycznej nie jest jeszcze realne, należy wdrożyć zorganizowaną warstwę semantyczną, zachowując przy tym stałą strukturę nagłówków. Semantyka powinna przenosić się w górę łańcucha, z paneli kontrolnych i interfejsów użytkownika do modelu przedsiębiorstwa pierwszej klasy, przy czym każda warstwa odpowiadająca poszczególnemu produkcie powinna być traktowana jako zkompilowana widok.

Celem nie jest pojedyncza baza danych, narzędzie ani składnia. Chodzi o jednoznaczne znaczenie, takie, aby osoba, panel sterowania, aplikacja oraz agent AI interpretowały je w ten sam sposób. Jeśli te cztery elementy się nie zgadzają, problem nie leży w LLM – to problem tożsamości, który został odroczony.