Dlaczego agenci analityki AI potrzebują warstwy semantycznej zamiast surowego SQL
Text-to-SQL w przypadku surowych tabel wymyśla metryki i pomija zasady dostępu. Warstwa semantyczna taka jak Cube, dostępna przez MCP, nadaje agentom AI kontrolowane przez biznes znaczenie.
Źródła: The Semantic Layer for AI Agents: How to Stop LLMs From Inventing Metrics
Użycie agenta analitycznego opartego na AI do pisania zapytań SQL to najszybszy sposób na stworzenie demonstracji, która zachwyci odbiorców. Jest to jednak także najszybszy sposób na powstanie problemów, jeśli te zapytania są wykonywane na surowych tabelach magazynowych bez żadnego kontekstu biznesowego. Problemem nie jest składnia – problemem jest znaczenie.
Weźmy słowo „przychód” i zastanówmy się, co ono obejmuje:
- Koszt brutto czy netto?
- Czy odlicza się zwroty?
- Która kolumna daty określa kwartał?
- Czy „aktywny klient” oznacza klienta aktywnego w momencie złożenia zamówienia, czy aktywnego dzisiaj?
- Która mapa regionów jest stosowana?
- Która zasada konwersji walut?
- Czy ten użytkownik w ogóle ma prawo do oglądania danych tego klienta?
Prosta metoda przekształcania tekstu w SQL zawodzi dokładnie w tych kwestiach. Model może generować poprawny SQL, baza danych może go bez problemów wykonać, a liczby mogą nadal być błędne. Z tego powodu agent analityczny potrzebuje warstwy semantycznej pomiędzy sobą a danymi biznesowymi. Cube to dobrze opracowany przykład takiej warstwy, która służy jako przykład w dalszej części tekstu.
Schematy nie niosą znaczenia
Przekształcanie tekstu w SQL to dobry pomysł – umożliwia ono programistom, analitykom i użytkownikom biznesowym szybszą pracę. Jednak schemat magazynu rzadko zawiera to znaczenie, którego oczekuje od niego człowiek.
Tabela zawiera kolumny takie jak amount, status, created_at, customer_type, region_id i currency, ale nikt w biznesie nie formułuje pytań w ten sposób. Nikt nie pyta o sum(amount) grouped by region_id where status = 'paid'. Zamiast tego pytają, jak wzrosły przychody przedsiębiorstw w południowych Indiach w zeszłym kwartale.
To pojedyncze zdanie kryje całą serię decyzji. Co to jest przychód i co czyni klienta przedsiębiorstwem? Która data oznacza kwartał, a jak mapuje się Południowe Indie? Czy anulowane zamówienia i zwroty są usuwane? Która zasada walutowa obowiązuje i co może zobaczyć osoba zadająca pytanie? Model może tylko zgadywać co do każdego z tych elementów. Jednak zgadywanie to nie zarządzanie. Jeśli odpowiedź agenta różni się od danych na panelu kontrolnym, ludzie przestają mu ufać. Jeśli zostanie dołączona do niewłaściwej tabeli, liczba może wydawać się wiarygodna, ale jest błędna. Jeśli zignoruje zasady dostępu, odpowiedź staje się wyciekiem danych.
Prawdziwe pytanie nie brzmi więc, czy model potrafi pisać SQL. Chodzi o to, czy w ogóle powinien tworzyć logikę biznesową.
Co robi warstwa semantyczna
Kwarstwa semantyczna znajduje się pomiędzy surowymi danymi a osobami, które je wykorzystują, przekształcając techniczne struktury bazy danych w spójne koncepcje biznesowe. Określa ona metryki, miary, wymiary, połączenia, segmenty, hierarchie, zasady dostępu, zasady buforowania, wstępne agregacje oraz API służące do ich wyświetlania, zamiast ujawniać tabele i kolumny.
W praktyce orders.amount, customers.type, orders.created_at oraz refunds.amount stają się przychodem, klientem korporacyjnym, datą zamówienia i przychodem skorygowanym o zwroty. Pracownicy potrzebują takiego słownictwa. Bez kwarstwy semantycznej pracownik analizuje schemat i sam wyciąga wnioski. Z jej pomocą pracuje na podstawie zatwierdzonych definicji. Pracownik nadal nie jest doskonały, ale znika jeden z głównych powodów błędów w analizach, ponieważ definicję metryki nie trzeba już odtwarzać na podstawie surowych tabel.
To kategoria, a nie pojedynczy produkt. Cube, dbt Semantic Layer (zbudowany na MetricFlow) oraz LookML od Lookera każdy na swój sposób rozwiązuje ten sam problem w swoich ekosystemach. Cube przyciąga tutaj uwagę, ponieważ jego podejście dla agentów jest niezwykle kompleksowe, chociaż architektura ma większe znaczenie niż marka.
Dlaczego Cube jest dobrym przykładem
Cube to nie tylko warstwa dashboardów. Jeden zarządzany model dostarcza dane zarówno do narzędzi BI, analityki wbudowanej, API, jak i agentów AI, zbudowanych na bazie kostek danych, miar, wymiarów, połączeń, segmentów, hierarchii, uprzednich agregatów oraz polityk dostępu. Są to elementy niemal identyczne z tymi, których potrzebuje agent analityczny.
Jego własny opis projektu dobrze oddaje istotę koncepcji: agenci nie wysyłają zapytań bezpośrednio do magazynu danych, lecz do warstwy semantycznej, a warstwa wykonawcza pełni rolę zabezpieczenia pomiędzy agentem a magazynem.
Porównaj, co każda z tych metod przekazuje modelowi. Gdy otrzymuje surową tabelę, widzi tylko nazwy kolumn i nic więcej. Gdy ma dostęp do warstwy semantycznej, otrzymuje również zatwierdzone koncepcje, obliczenia za nimi stojące, sposób ich powiązania, to, do czego może mieć dostęp aktualny użytkownik, oraz bezpieczny sposób wyszukiwania informacji. Ponowne odkrywanie logiki biznesowej przy każdym pytaniu jest marnotrawstwem zasobów, dlatego agent powinien korzystać z warstwy, która już ją zawiera.
Łączenie z znaczeniem: gdzie pasuje MCP
MCP to powszechny sposób łączenia asystentów AI z zewnętrznymi narzędziami i danymi, jednak połączenie nie jest równoznaczne z zrozumieniem. Nawet jeśli agent otrzyma przez MCP bezpośredni dostęp do surowych tabel magazynowych, nadal musi sam domyślać się ich znaczenia, co stanowi pierwotny problem w nowej architekturze.
Silniejszy wzorzec polega na kierowaniu agenta przez warstwę semantyczną:
AI agent
→ MCP client
→ semantic-layer MCP server (e.g. Cube's)
→ semantic layer (governed metrics, dimensions, joins, policies)
→ data warehouse
MCP zajmuje się dostępem, natomiast warstwa semantyczna odpowiada za znaczenie. Agent nie powinien pytać bazy danych, które tabele należy połączyć w celu obliczenia przychodów. Zamiast tego powinien zwrócić się do warstwy semantycznej o zatwierdzoną miarę przychodów oraz wymagane wymiary.
Dwie uwagi sprawiają, że informacje te są rzetelne, ponieważ ten obszar rozwija się szybko i łatwo jest przesadzać. Oficjalny serwer MCP Cube, będący częścią Cube Cloud i dostępny przez HTTPS z użyciem OAuth, różni się od serwerów MCP społecznościowych dla Cube, takich jak te rozpowszechniane przez Smithery. Ich poziom zaufania, wsparcia i konserwacji jest inny, a użycie w środowisku produkcyjnym wymaga oficjalnej, kontrolowanej metody. Ponadto natywne wsparcie MCP pojawiło się stosunkowo niedawno w tym obszarze, dodane na wierzch do API typu REST, SQL i GraphQL, które te produkty oferują od lat. Funkcjonuje to, ale jest to rozwiązanie typu 2025–2026, więc należy sprawdzić je w odniesieniu do wersji, którą faktycznie używasz.
Bezpieczniejsza architektura od początku do końca
Gdy wszystko jest połączone, przepływ wygląda w ten sposób:
user question
→ AI analytics agent
→ MCP / tool call
→ semantic layer (approved metrics, dimensions, joins, segments, policies)
→ data warehouse
→ governed result
→ agent explanation
Agent nie ma pełnej swobody w dostępie do surowych danych. Dostaje zintegrowany interfejs, dzięki któremu zespół kontroluje, jakie metryki istnieją, jakie wymiary są ważne, w jaki sposób odbywają się połączenia, jakie filtry są dozwolone, kto może widzieć konkretne wiersze, czy odpowiedzi pochodzą z pamięci cache czy z wcześniej zebranych danych, oraz w jaki sposób zapytania są udostępniane przez API. To jest lepsze niż proszenie modelu o napisanie kodu SQL i liczenie na to, że logika biznesowa będzie poprawna.
Przykład zastosowania: wzrost przychodów
Proszę o informację o wzroście przychodów przedsiębiorstwa z ostatniego kwartału. Bez warstwy semantycznej agent musi sam odgadnąć, która tabela zawiera dane o przychodach, czy chodzi o przychody brutto, netto, zarejestrowane czy uznane, czy zwroty są uwzględniane, w jaki sposób identyfikowane są konta przedsiębiorstw, która kolumna czasowa określa ostatni kwartał, czy waluty wymagają konwersji oraz czy dany użytkownik może przeglądać wszystkie segmenty danych. Kod SQL może zostać wykonyany, ale jego uruchomienie nie oznacza automatycznie poprawności wyników.
Dzięki warstwie semantycznej takie odpowiedzi już istnieją. Przychód to zatwierdzona miara, Klient korporacyjny to zatwierdzony segment, Data zamówienia to zatwierdzona wymiar czasu, logika zwrotu pieniędzy jest zdefiniowana raz, a polityka dostępu jest stosowana w zależności od tego, kto o to prosi. Agent nie wymyśla metryki, lecz żąda tej zatwierdzonej. To odróżnia generowanie zapytań SQL w języku naturalnym od zorganizowanej analityki opartej na agentach.
Co może pójść nie tak przy bezpośrednim dostępie do magazynu
Dostęp bezpośredni daje agentowi zbyt dużo swobody do domysłów, a błędy są przewidywalne:
- Wymyślanie metryk: przychód jest obliczany inaczej niż na panelu finansowym.
- Nieprawidłowe połączenia: zapytanie się uruchamia, ale połączenie powoduje duplikację wierszy lub usunięcie rekordów.
- Brak filtrów: anulowane zamówienia, konta testowe, usunięte rekordy lub użytkownicy wewnętrzni pozostają w bazie.
- Ucieczka uprawnień: uzasadnione pytanie powoduje wyświetlenie danych klientów, zespołów lub regionów, które dana osoba nie powinna widzieć.
- Przestarzała logika: schemat uległ zmianie, a agent nadal używa starego wzorca.
- Wiarygodne, błędne odpowiedzi – najgorszy scenariusz, w którym liczby wydające się pewne są w rzeczywistości błędne.
Agenci odpowiadający na pytania biznesowe potrzebują silniejszych zabezpieczeń niż te dostarczane przez generowanie zapytań SQL. Potrzebują ograniczeń semantycznych.
Zachowanie SQL bez ujawniania surowych tabel
Rezygnacja z elastyczności nie jest ceną za zarządzanie danymi. Dojrzała warstwa semantyczna może utrzymać „drzwi” do SQL otwarte, skierowane na zarządzane obiekty zamiast na fizyczne tabele. W API SQL Cube każdy kub czy widok wygląda jak tabela, a jego miary, wymiary i segmenty jak kolumny. Ponieważ wykorzystuje protokół i dialekt Postgres, może się do niego połączyć niemal każdy klient obsługujący Postgres.
Narzędzia i agenci umożliwiają zadawanie zapytań w stylu SQL, ale model określa, co można zapytać. Agent nie przegląda surowych tabel – pracuje z zatwierdzonymi metrykami i wymiarami, co stanowi praktyczne rozwiązanie znacznie bliższe temu, jak powinny funkcjonować analizy produkcyjne.
Reguły dostępu są równie ważne jak metryki
Dla agentów konwersacyjnych kontrola dostępu staje się kluczowa, ponieważ okno czatu zachęca do zadawania otwartych pytań. Ktoś wpisuje „pokaż mi przychody według klientów”, a system musi wiedzieć, jakich klientów ta osoba może zobaczyć, która region lub użytkownik ma zastosowanie, oraz czy dozwolone są szczegóły na poziomie klienta, czy powinny być zwracane tylko dane agregowane.
Cube stosuje polityki dostępu oraz zabezpieczenia na poziomie wierszy w warstwie semantycznej. Taka lokalizacja jest celowa: nikt nie powinien polegać na agencie, który samodzielnie przypomni sobie wszystkie zasady. Zapisanie frazy „nigdy nie ujawniaj nieuprawnionych danych” w instrukcji stanowi prośbę. Ograniczenie określonego użytkownika do określonych wierszy, wymiarów i miar przez tę warstwę to natomiast egzekwowanie zasad. Egzekwowanie jest znacznie silniejsze i odbywa się w warstwie danych, a nie w instrukcji.
Aspekt wydajności: cache i preagregacje
Analityka konwersacyjna ma charakter iteracyjny. Osoba pyta o przychody według regionów, następnie dzieli je według produktów, porównuje z poprzednim kwartałem, a potem ogranicza je do klientów korporacyjnych. Jeśli każdy krok staje się nowym, złożonym zapytaniem do magazynu danych, opóźnienia i koszty szybko rosną.
Wstępna agregacja danych i cacheowanie w Cube, obsługiwane przez silnik CubeStore, przyspieszają często wykonywane zapytania analityczne. Jednym z odnotowanych efektów było mniej więcej dwukrotne obniżenie kosztów magazynowania po przeniesieniu danych do pamięci CubeStore. Dlatego w przypadku powtarzających się pytań warstwa semantyczna pełni rolę warstwy optymalizującej wydajność, oprócz funkcji zarządzania danymi.
Gdzie ten model przynosi korzyści
Największe korzyści osiągają agenci, którzy odpowiadają na pytania dotyczące przychodów, segmentów klientów, wykorzystania produktów, wbudowanych narzędzi analitycznych dostępnych dla klientów, paneli operacyjnych, wskaźników kluczowych efektywności lub wyjaśnień metryk, a także każdy scenariusz self-service BI.
Największy efekt jest widoczny tam, gdzie już istnieją powtarzające się definicje. Zdefiniuj raz modele ARR, MRR, przychody, stopę odejść klientów, retencję, aktywnych użytkowników, wskaźnik konwersji, marżę brutto, czas rozwiązania problemu oraz stopę przyjęcia nowych funkcji, a każdy agent będzie je ponownie wykorzystywał zamiast przeliczać je za każdym razem, gdy zmienia się pytanie.
Gdzie zespoły powinny być ostrożne
To wszystko nie jest magią, a zasady zarządzania muszą być rzeczywiste, a nie tylko etykietą. Niekompletny model sprawia, że agent ma trudności. Błędne definicje metryk dają poprawne, ale błędne wyniki. Zbyt szerokie zasady dostępu nadal narażają dane na niebezpieczeństwo. Model przepełniony mylącymi, niemal identycznymi metrykami pozwala agencie wybrać tę niewłaściwą. A jeśli aktualność nie jest widoczna, odpowiedź może wyglądać na aktualną, mimo że opiera się na przestarzałych danych.
Zatem istotne pytanie brzmi nie o to, czy istnieje warstwa semantyczna, ale o to, czy ta warstwa jest wystarczająco dobra, aby agent mógł jej bezpiecznie używać. Model musi być udokumentowany, wersjonowany, przetestowany, mieć kontrolę dostępu i być zrozumiały, musi być zgodny z panelami kontrolnymi, którym ludzie już ufają, łączyć się z kontrolami jakości danych oraz jasno wskazywać aktualność i ograniczenia. Słaba warstwa skutkuje słabymi odpowiedziami agenta.
Od surowego SQL do zarządzanych analiz
Różnica pomiędzy tymi podejściami polega na tym, co widzi agent i co może ulec awarii:
- Surowy przekład tekstu na SQL: agent widzi tabele i kolumny w magazynie, a głównym ryzykiem jest wymyślona logika biznesowa.
- SQL wraz z dokumentacją schematu: to ulepszenie, jednak połączenia i metryki nadal są łatwo niewłaściwie używane.
- Tylko warstwa semantyczna: agent pracuje z zdefiniowanymi metrykami, wymiarami, relacjami i zasadami. Jest to bezpieczniejsze, a jakość jest ograniczona modelem, który za tym stoi.
- Warstwa semantyczna plus MCP: analityka zarządzana udostępniana jako narzędzia agenta, obecnie najlepsze rozwiązanie dla kontrolowanej analityki AI.
Przekład tekstu na SQL pozostaje przydatny, ale do analityki biznesowej powinien być wykorzystywany w oparciu o zarządzaną semantykę, a nie o domysły dotyczące surowego schematu.
Lista kontrolna przed tym, jak agent dotknie danych biznesowych
- Najpierw umieść kluczowe metryki w warstwie semantycznej.
- Określ dokładnie, które wymiary i połączenia są dozwolone.
- Wdroż polityki dostępu oraz reguły na poziomie wierszy w warstwie.
- Zaoferuj zarządzane API zamiast oryginalnych tabel.
- Dostęp do warstwy przez MCP możliwy jest wyłącznie za pośrednictwem zatwierdzonych, oficjalnych narzędzi.
- Przechowuj rejestr każdego zapytania agenta wraz z wygenerowanym SQL.
- Dołącz do każdej odpowiedzi definicję metryki, na której się opiera.
- W każdej odpowiedzi podaj informację o aktualności danych.
- Przetestuj znane pytania biznesowe i porównaj wyniki z wiarygodnymi panelami analitycznymi.
- Wyłącz bezpośredni dostęp do wrażliwych tabel magazynowych.
- Decyduj, co się stanie, gdy żądana metryka nie ma definicji.
- Nauč agenta odpowiadać „nie zdefiniowane”, zamiast improwizować.
- Wersjonuj definicje metryk tak jak kod.
- Przetestuj reguły dostępu przy użyciu rzeczywistych ról użytkowników.
- Uważaj na zapytania, które zwracają błędy lub niejednoznaczne wyniki.
Najważniejsza zasada: gdy jakaś metryka nie jest zdefiniowana, agent nie powinien jej wymyślać. Powinien poprosić o wyjaśnienia lub stwierdzić, że metryka nie jest dostępna.
Pytania skierowane do zespołów produktowych
Zanim przekażesz nowemu agentowi analitycznemu pełny schemat magazynu, zatrzymaj się i uporządkuj kilka kwestii. Zdecyduj, jakie pytania biznesowe powinien on odpowiadać, jakie metryki są zatwierdzone, jakie wymiary są dopuszczalne oraz jakie połączenia są bezpieczne. Określ, kto może widzieć co, jak świeże muszą być dane, jakie odpowiedzi wymagają definicji lub odniesienia, a które zapytania muszą zostać odrzucone. Dopiero wtedy udostępnij temu ograniczonemu zestawowi informacji agenta.
Kostka to jeden ze sposobów tworzenia powierzchni danych, natomiast dbt Semantic Layer, LookML i MetricFlow podchodzą do tego samego problemu z innych perspektyw. Kluczowa lekcja nie ma nic wspólnego z konkretnym produktem – agenci potrzebują zdefiniowanych semantyk biznesowych, zanim będą mogli pracować z danymi biznesowymi.
Główny punkt
Traktowanie analiz AI wyłącznie jako zadania przekształcania tekstu w SQL pomija istotę problemu, ponieważ zarządzanie znaczeniem jest trudniejszą częścią. Agent pracujący z surowymi tabelami magazynowymi może pisać w pełni poprawny SQL, a mimo to podawać błędne odpowiedzi biznesowe, dzięki wymyślonym metrykom, błędnym połączeniom, pominiętym regułom dostępu lub danym sprzecznym z informacjami na panelu kontrolnym. Warstwa semantyczna zmienia interfejs – zatwierdzone metryki, wymiary, połączenia, polityki i API zastępują surowy schemat, który musiałby być interpretowany. MCP zapewnia połączenie, warstwa semantyczna – znaczenie, a analityka zarządzana wymaga obu tych elementów.
Literatura pokrewna
- Stwórz agenta do weryfikacji klientów w AI w Pythonie za pomocą FastAPI i Pydantic — Przekształć surowe dane klientów w weryfikowane: strukturyzowane wydobywanie informacji z modeli językowych, walidacja za pomocą Pydantic, ocenianie na podstawie reguł, przechowywanie w PostgreSQL, kolejki oraz możliwość przeglądu przez człowieka.
- Porównanie agentów zarządzanych: Anthropic, LangGraph i Google ADK — Kto kontroluje środowisko testowe, dane uwierzytelniające i ślady działania? Porównanie agentów zarządzanych Anthropic, LangGraph i Google ADK wraz z cenami, możliwymi awariami i prostym przewodnikiem decyzyjnym.