Twój model semantyczny to API: dostarczanie agentom certyfikowanych metryk
Dlaczego agenci AI tworzą własne definicje przychodów i zapasów, oraz w jaki sposób zarządzany model semantyczny z detalami, właścicielami i odrzuceniami zapewnia im jeden kontrakt.
Dwa liczby, obie oficjalne
Spotkanie planistyczne rozpoczęło się od slajdu z tytułem „W zeszłym tygodniu, sprzedaż”. Poprzedniego wieczoru od obu współpilotażystów poproszono o odpowiedź na to samo pytanie, a obaj przynieśli wykresy z dołączonym kodem SQL. Jedna z wartości była o 4% wyższa od planu, a druga o 3% niższa.
Nikt w pomieszczeniu nie obwiniał fałszywych kolumn. W magazynie rzeczywiście istniała tabela sales z kolumną net_amt oraz datami. Zapytania kompilowały się poprawnie, klucze łączeniowe istniały, więc z punktu widzenia bazy danych obie odpowiedzi były prawidłowe.
Finanse przedstawiły wtedy trzecią wartość, tę, która została już zamrożona na potrzeby cotygodniowego listu do zarządu. Odzwierciedlała ona uznane przychody według daty faktury, odejmowała notatki kredytowe i wykluczała zarówno zakupy pracowników, jak i sprzedaż hurtową. Copilot jeden opierał się na datie zamówienia i uwzględniał zakupy dokonywane w sklepach pracowników. Copilot dwa bazował na dacie wysyłki i brał region z adresu docelowego, a nie z organizacji sprzedającej.
Gdy w tym samym temacie zapytano o to, na jakiej dacie opierał się każdy z narzędzi, jedno wskazało na order_dt, a drugie na ship_dt. Żadne z nich nie wspomniało o notatkach kredytowych. Odnośnie do tego, czy uwzględniano zakupy pracowników, jedno stwierdziło, że nie widziało żadnego filtru na ten temat, a drugie wymyśliło historię o flagi channel, która okazała się być polem przypisywania zadań marketingowych, niepowiązanym ze sklepami pracowników.
Tutaj problemem była posłuszeństwo. Obaj agenci zachowywali się jak kompetentni analitycy, którzy mieli trudny dzień: zauważyli kolumnę, której nazwa przypominała pytanie, i ją podsumowali. Człowiek normalnie zatrzymałby się i zapytał, który numer sprzedaży jest potrzebny, natomiast agent potraktował prawdopodobną kolumnę jako sygnał do zakończenia pracy.
Później w temacie Slacka znajdowały się trzy wykresy oraz jeden numer finansowy. Nikt nie dodał nazwy wskaźnika, tylko zrzuty ekranu, a to jest przydatnym sygnałem ostrzegawczym. Gdy spór dotyczy obrazków, umowa nigdy nie jest przywoływana.
Daj agencie magazyn i przyjazne polecenie, a ona sama wymyśli biznes. To „wymyślenie” wygląda na oznakę kompetencji i trafia do Slacka, gdzie ludzie kłócą się o wagi modeli, podczas gdy powinni dyskutować o braku umowy. Takie spory łatwo przypisać problemom kulturowym, ale w rzeczywistości wynikają one z braku odpowiedniej interfejsu, a jedynie podczas spotkań standupowych awaria staje się widoczna.
Praktycznym sposobem na wyobrażenie sobie modelu semantycznego jest postrzeganie go jako API, ale nie w sensie popularnego trendu REST. Wyobraź sobie interfejs, który wyklucza prywatną interpretację. Gdy ktoś pyta o sprzedaż z zeszłego tygodnia, osoba zadająca pytanie nie ma wpływu na to, która kolumna z datą ma być użyta. System wykonywa funkcję recognized_revenue według określonych zasad, w przeciwnym razie otrzymuje odmowę. Silnik nadal może generować kod SQL, ale agencja go nie pisze.
Wyobrażanie sobie punktów końcowych i kluczy API jest w porządku, jeśli to pomaga. Ważne jest coś bardziej konkretnego: operacja z nazwą i ustalonym znaczeniem, którą może wywołać każdy uprawniony użytkownik.
API mają również właścicieli, wersje oraz zasady dotyczące zmian zakłócających funkcjonowanie. Wskaźnik bez właściciela to jedynie plotka, która przypadkowo daje wynik. Gdy dział finansów zmienia sposób obsługi notatek kredytowych, powinno to skutkować podniesieniem wersji, które odczuje każdy użytkownik, w przeciwnym razie wracamy do poprzedniego stanu. Wydrukowywanie wersji wskaźnika na dole cotygodniowego biuletynu przez miesiąc może wydawać się pedantyczne, ale przekształca rozmowę o „który dochód” z konfliktu osobistego w kwestię związaną z wersją.
Zapytanie było doskonałe, ale znaczenie nie
Podaj nowoczesnemu modelowi plik z schematem wraz z pytaniem o dochód, a SQL zazwyczaj będzie na tyle uporządkowany, że dziesięć lat temu wydawałby się imponujący. To już nie jest miejsce, gdzie leży ryzyko.
Przychód nie jest kolumną. Nawet jedna firma może mieć zapisane, fakturyzowane, dostarczone i uznane przychody, a także wszystko to, co zostało zarejestrowane w kasyfikatorach przed zwrotami. Notatki kredytowe mogą się wzajemnie anulować, a mogą też tego nie robić. Sprzedaż międzyspółkowa może być uwzględniana, a może też nie. „Holandia” może oznaczać kraj fakturowania, kraj dostawy lub organizację sprzedaży będącą właścicielem konta, a „ostatni miesiąc” może to być miesiąc kalendarzowy lub okres finansowy kończący się w niedzielę.
Żadna z tych kwestii nie dotyczy składni JOIN. Klasyczne połączenie danych może nadal dać błędną odpowiedź w kontekście decyzji, od której zależy wynik.
Inwentarz zachowuje się w ten sam sposób. Zapasy obecne na magazynie nie są dostępne do przydzielenia, a te dostępne do przydzielenia to nie to, co silnik alokacji faktycznie wyda e-commerce dziś wieczorem. Pracownik, który odpowiada „czy możemy obiecać dostawę w piątek” na podstawie ilości obecnych zapasów, może sprawiać wrażenie profesjonalisty, ale mimo to pozostawia klienta w trudnej sytuacji.
W jednym przypadku pracownik uspokoił kierownika magazynu co do określonego modelu, ponieważ dodał wartość qty_on_hand ze wszystkich lokalizacji, włączając uszkodzoną skrzynię, mimo że system planowania już oznaczył tę skrzynię jako niewykorzystywalną. Zapytanie SQL było poprawne, ale jego znaczenie było jedynie domysłem. Kierownik osobiście sprawdził tę skrzynię wcześniej tego dnia, a pracownik miał do dyspozycji tylko dane z tabeli.
Raporty w czasie rzeczywistym pokazują tę samą różnicę. Dział handlowy wymaga danych o transakcjach zrealizowanych przed godziną 16:00, natomiast dział finansowy potrzebuje odnotowanych przychodów po uwzględnieniu rabatów. Na spotkaniu obie strony mówią o „wczorajszych sprzedażach”. Pracownik, który otrzymuje to zdanie, wybiera kolumnę z datą i kolumnę z kwotą, a potem przestaje pracować; dyskusja rozpoczyna się dopiero po wyświetleniu wykresu.
Planowanie asortymentu napotyka na ten sam problem. Popyt różni się od danych z punktów sprzedaży, a dane z POS różnią się od sprzedaży netto po odliczeniu zwrotów. Dany model może być wyświetlany jako wyprzedany w systemie planowania e-commerce, podczas gdy tabela widoczna dla pracownika nadal pokazuje dostępne zapasy, ponieważ zawiera ona również towary w transporcie, te w kontroli jakości oraz ilości przeznaczone na pakowanie i przechowywanie w oczekiwaniu na sprzedaż hurtową. Jeśli pracownik odpowie na pytanie „czy to mamy?” na podstawie błędnych danych, firma może rano dać zbyt optymistyczne obietnice, a potem spędzić popołudnie na tłumaczeniu się z braku towaru, którego tabela w ogóle nie pokazywała.
Nazywanie tego niepowodzeniem promptu to błąd, ponieważ prompt „czy to mamy” był w porządku. Brakowało obiektu available_to_promise zawierającego dokładnie określone informacje: zestaw lokalizacji, rodzaje towarów wykluczonych z dostawy, liczby zapasów w trakcie transportu oraz czas, do którego odnoszą się dane. Bez tego każdy użytkownik musi samodzielnie organizować swoją łańcuch dostaw.
Dlatego stary komfort samodzielnych narzędzi analitycznych nie przekłada się na nowoczesne rozwiązania. Dziesięć osób patrzących na jeden panel sterowania przynajmniej dzieli się tym samym błędnym wynikiem. Dziesięć pracowników tworzących po dziesięć osobistych zapytań wydaje się lokalnie rozsądnych, ale w rezultacie organizacja ma tylko chaos i brak jednoznacznych danych.
Analityk, który nie zna kontekstu, zadaje dodatkowe pytanie. Agent, który nie zna kontekstu, uzupełnia zdanie. W demonstracjach było to ciekawostką, ale w produkcji stanowi zagrożenie, ponieważ ta sama architektura, która ułatwiała dostęp do danych, ułatwiała też ich wyszukiwanie bez uzgodnienia żadnych zasad.
Przez dwa dekady pracowano nad tym, aby dane były dostępne za pośrednictwem magazynów danych, lakehouse, rozwiązań ELT, notatek i API, więc teraz wąskie gardło znajduje się gdzie indziej. Kwestia tego, czy oprogramowanie może widzieć tabelę, jest już rozstrzygnięta. Natomiast to, czy oprogramowanie może decydować o znaczeniu tabeli, nie jest rozstrzygnięte.
Co obejmuje umowa znaczeniowa
Glosariusz jest niewystarczający, ponieważ można go błędnie odczytać, natomiast umowa albo działa, albo zostaje odrzucona. Operacje określone przez użyteczny model semantyczny to te, o których biznes już walczył i które zostały rozstrzygnięte:
- Przychód uznany ma precyzyjną definicję, a określone wiersze nigdy nie stanowią jego części.
- Aktywny klient jest określany na podstawie reguły, a nie intuicji.
- Relacja klienta z regionem to ta, za którą finanse są gotowe ręczyć.
- Dla tego KPI okres jest określany na podstawie daty faktury, a nigdy daty zamówienia.
- Niektóre wymiary można dzielić zgodnie z wymogami prawnymi, a pozostałe służą jedynie dekoracyjnemu celowi.
Poniżej znajdują się miary, wymiary, hierarchie, pola obliczane, metadane oraz filtry wierszy, a nie ma znaczenia, który plik dostawcy je zawiera. Funkcjonalnie fragment języka biznesowego został przechwycony w formie, którą oprogramowanie może wywołać. Do niedawna głównym narzędziem wywoływania była raporty. Nowe narzędzie nigdy się nie nudzi, nigdy nie podchodzi do biurka analityka i nie odczuwa wstydu z powodu błędów.
Zboże to element, który zespoły pomijają, ponieważ wydaje się jak zadanie domowe z modelowania, a jednak jest to kluczowy element API. Jeśli nic nie zostanie zadeklarowane, każdy użytkownik sam wymyśla takie rozwiązanie. Sprowadza się to do czterech pytań, na które potrzebne są odpowiedzi w tym samym miejscu:
- Która data kończy okres.
- Którą jednostkę opisuje dana liczba – czy to organizacja sprzedająca, adres dostawy czy adres faktury.
- Które wiersze są wykluczane, np. pracownicy, zamówienia hurtowe, międzyfirmowe oraz testowe.
- Które zasady bezpieczeństwa nadal obowiązują, gdy użytkownikiem jest agent.
Gdy tych odpowiedzi brakuje w modelu, trafiają one do wątku na Slacku, co oznacza, że nie ma ich w żadnym miejscu.
Metryka marży pokazuje, jak to wygląda. Wzór był dobry, ale data była błędna. Jeden z dzwoniących użył daty zamówienia, ponieważ tabela faktów używała jej domyślnie, a inny użył daty faktury, ponieważ widok finansowy tak postanowił. Obaj podawali „marżę”, a w ciągu tygodnia, gdy koszty transportu gwałtownie wzrosły, ich wartości różniły się o dwa punkty. Pracownik wziął na siebie winę, chociaż prawdziwym błędem było brak odpowiednich danych. Dodanie daty faktury, reguły uwzględniającej koszty transportu oraz określenia właściciela naprawiło sytuację, a wartości z następnego tygodnia były zgodne. Nikt nie podziękował modelowi, ale sygnały ping przestały przychodzić.
Trasa, którą należy obrać, jest celowo prosta: intencja, powiązanie, egzekwowanie, wykonywanie, odpowiedź. W żadnym momencie model nie decyduje o tym, co oznacza przychód. Wybór odpowiedniej, certyfikowanej miary pasującej do pytania jest do przyjęcia, ponieważ jest to klasifikacja. Składanie miary z surowych tabel to interpolacja, a interpolacja jest sposobem, w jaki dwa oficjalne liczby pojawiają się przed pierwszą kawą.
Ślad opowiada historię. Jeśli agent wybiera kolumny na podstawie podobieństwa nazw, jest to zbieracz danych. Jeśli wywołuje funkcję recognized_revenue z określonym okresem i regionem, jest to osoba dokonująca wywołania. Drugi ślad jest mniej „kinowy”, i to właśnie go należy przedstawić podczas audytu.
Metadane przestały być dokumentacją
Opisy kiedyś były czymś dodanym później, wpisywanym dopiero po dostarczeniu panelu sterowania, i to tylko wtedy, gdy w sprintzie pozostały jeszcze godziny, co zdarzało się rzadko. Miara o nazwie [NS Adj LY %] była akceptowalna, ponieważ trzy osoby edytujące plik znały jego historię.
Agent nie zna tych specyfikacji. Wskazówki Microsoft dotyczące przygotowywania modeli semantycznych dla agentów danych mówią o tym jasno: nazwy, opisy, relacje oraz zmniejszenie niejednoznaczności decydują o jakości odpowiedzi, i to dotyczy również sytuacji poza tym stackiem. Te ciągi znaków stanowią teraz obowiązkowy element wejściowy. Pusty opis nie powstrzymuje agenta przed udzieleniem odpowiedzi – po prostu wiąże się z jakimś pogłoskiem.
Tę zmianę łatwo nie docenić, ponieważ plik wygląda identycznie. Nadal zawiera model z miarami. Zmienił się natomiast użytkownik: człowiek-developer wnioskuje, podczas gdy agent łączy dane, a niedbale wykonane połączenie nadal generuje odpowiedź z dołączoną wykresem.
Tajemnicza nazwa metryki jest teraz uważana za wadę produkcyjną, podobnie jak nieudokumentowana funkcja publiczna. Nikt nie wypuściłby fn_x3() jako API do fakturowania, a mimo to przez dekadę funkcjonowało ono jako API do metryk, ponieważ tylko ludzie je używali.
Platformy postawiły na to samo
Gdy usuniemy kolory marki z stron produktów, pojawia się pewien wzorzec. Microsoft, Snowflake, Databricks i ThoughtSpot inwestują we warstwy semantyczne, zasady zarządzania oraz to, co nazywają zaufanym kontekstem biznesowym. Ich prezentacja to nie efektowna demonstracja modelu generującego SQL.
Wszyscy oni zakładają, że model powinien rozumować na podstawie zweryfikowanego znaczenia, a nie na podstawie kolumny, która przypadkowo znajduje się najbliżej słowa w pytaniu. Agenci danych w stylu Fabric, działające w magazynach, lakehouse’ach oraz modelach semantycznych Power BI, odzwierciedlają ten założenie. Podobnie postępują analitycy w stylu Cortex, którzy preferują podejście semantyczne zamiast surowego wyeksportowania schematu, a także widoki metryczne i katalogi, które podnoszą KPI do rangi obiektu platformy. ThoughtSpot od lat sprzedaje funkcję „zadaj pytanie danym” poprzez warstwę modelową, a reszta rynku zrozumiała jej sens, gdy oprogramowanie stało się możliwym narzędziem do zadawania pytań.
Strategia wyboru najmądrzejszego modelu i skierowania go na jezioro jest sprzeczna z kierunkiem rozwoju platform, za które już się płaci. Umieszczają warstwę interpretacyjną przed jeziorem, ponieważ modele stały się biegłe w SQL – płynność komunikacji zwiększyła koszt niezgody, nie eliminując jej. Kupno kolejnego asystenta nie definiuje klienta; tworzy jedynie więcej elementów, które mogą się nie zgadzać.
Protokół nie definiuje przychodów
MCP pojawia się w tych samych dyskusjach, a protokół ten bywa czasami mylony z strategią. Ma on jednak rzeczywistą wartość. Weźmy na przykład agenta danych Fabric udostępnianego jako serwer MCP, który w chwili ostatniego przeczytania dokumentacji był jeszcze w wersji wstępnej: pokazuje to, że miejsce, w którym wprowadza się pytanie, nie musi być tym samym miejscem, gdzie przechowywana jest logika. Qlik oraz inni dostawcy podążają tym samym kierunkiem, dostarczając zintegrowane rozwiązania analityczne asystentom, które nigdy nie uruchamiają oryginalnego narzędzia. Miejsce zadawania pytań i miejsce przetwarzania informacji mogą być oddzielone.
Mimo to łączenie protokołu z konkretnym rozwiązaniem jest nierozsądne, ponieważ protokoły są zastępowane. Trwałą zasadą jest to, że znaczenie stanowi usługę, a chatbot jest jej klientem.
Udostępnianie nieuporządkowanego pliku Power BI za pośrednictwem MCP jedynie przenosi ten bałagan w odległe miejsce. Agent w Claude, Copilot lub wewnętrznym systemie nadal będzie łączył się z [NS Adj LY %], jeśli to właśnie zostało udostępnione.
Bezgłowe systemy BI już przez to przechodziły. Zespoły tworzyły proste interfejsy SQL nad tymi samymi nieudokumentowanymi miarami, a potem obwiniały nowego klienta, gdy wartości się zmieniały. Protokół wykonywał swoją funkcję, ale to, co przenosił, to jedynie folklor w połączeniu z trasą sieciową.
Dlatego protokół pozostaje w ramach infrastruktury: znajdowanie narzędzi, przekazywanie kontekstu, komunikacja między procesami. Znaczenie jest obsługiwane oddzielnie, poprzez powiązanie miary, odrzucanie nieprawidłowych danych i stosowanie zabezpieczeń wierszy. Doskonała infrastruktura oparta na definicji, której nikt nie chciałby bronić przed działem finansowym, pozostaje nadal folklorem, tylko z adresem URL.
Dawna debata na temat BI dotyczyła wyboru narzędzia do standaryzacji. Gdy to agenci są użytkownikami, lepszym pytaniem jest to, gdzie znajduje się zaufany kontekst analityczny i którzy użytkownicy mogą do niego uzyskać dostęp. Raportowanie może pozostać w jednym produkcie, podczas gdy agenci korzystają z modelu zarządzanego, znajdującego się bliżej magazynu, lub odwrotnie. Nie może się to udać, jeśli każdy użytkownik będzie miał prywatną kopię danych finansowych, a potem będzie udawał zaskoczenie, gdy liczby się różnią.
Panel sterowania stały się jednym z wielu użytkowników
Kiedyś panel sterowania były jedynymi poważnymi użytkownikami, ale już tak nie jest. Ludzie długo zakładali, że model semantyczny należy do jednego narzędzia BI: modele Power BI służyły do tworzenia raportów w Power BI, a modele LookML do tworzenia raportów w Looks. Taka struktura była sensowna, gdy jedynymi odbiorcami byli ludzie, a raport stanowił sam produkt.
Dziś jeden kontrakt może służyć do tworzenia paneli kontrolnych, plików Excel, aplikacji operacyjnych, kopilotów, czatów, agentów oraz do obsługi zadań polegających na zgłaszaniu ticketów, gdy jakaś metryka wyjdzie poza ustalone zakresy. Panele kontrolne pozostają przydatne, ale nie stanowią już głównego celu modelu, ponieważ wykres jest jedynie jednym z klientów tej definicji.
To pożądana zmiana. Wykresy szybko się starzeją, podczas gdy definicje przychodów, marży, wskaźnika zajętości i rotacji klientów powinny zmieniać się powoli. Gdy te definicje są prawidłowo zarządzane, nowy kopilot w następnym kwartale nie musi ponownie uruchamiać procesu łączenia danych, a agent szukający anomalii może ponownie wykorzystać tę samą metrykę w cotygodniowych raportach. W tym ponownym wykorzystaniu tkwi rzeczywista korzyść. Ładny panel kontrolny, którego logika jest ukryta w miarze na poziomie wizualnym, nie prowadzi do żadnych rezultatów, ponieważ nie można skorzystać z elementu wizualnego.
Każda recenzja rodzi zarzut: skoro modele potrafią pisać SQL, po co nadal finansować odpowiednie rozwiązania, i dlaczego nie pozostawić tego agentom? Agenci coraz częściej są w stanie to robić. Z perspektywy biznesu jednak właśnie ta zdolność powoduje problemy. Dostęp do danych stał się tani, podczas gdy uzyskanie zgody na ich użycie pozostało drogie. Dziesięciu pracowników obserwujących jeden panel sterowania podziela się jedną liczbą, nawet jeśli jest błędna, natomiast dziesięciu agentów pracujących w magazynie tworzy dziesięć lokalnych „prawd”, z którymi każdy występuje z taką samą pewnością siebie.
Tania wersja tego eksperymentu to dobrzy przykład. Weźmy jeden magazyn, jedno pytanie oraz trzy konfiguracje agentów bez żadnej wspólnej miary – wynikiem są trzy wartości przychodów wraz z trzema wyjaśnieniami, dlaczego każda z nich jest „dorosła”. Jeden z nich użył rezerwacji, ponieważ nazwa tabeli zawierała order. Inny podwoił liczbę zestawów, myląc strukturę wierszy z nagłówkami. Jeszcze inny zbliżył się do standardów finansowych, używając daty faktury, ale nadal uwzględniał sprzedaż hurtową. Każdy z tych przykładów opublikowany w temacie dla wiceprezesów oznaczałby tydzień spędzony na spieraniu się o chatbot, a nie o definicje.
Tanie dostęp bez umowy umożliwia większej liczbie osób, a teraz także agentom, tworzenie własnych, prywatnych „prawd”. To tłumaczy, dlaczego modelowanie stało się ważniejsze, a nie mniej, szczególnie wraz z rozwojem narzędzi do generowania zapytań SQL.
Jednego zestawu nie wystarcza
Następną pułapką, na którą trzeba uważać, jest semantyczny poziom pamiątek: certyfikacja w jednym narzędziu, a folklor we wszystkich innych. Zespół może spędzić rok na tworzeniu doskonałego modelu w produkcie BI, który wszyscy chwalą, a potem połączyć agenta bezpośrednio z magazynem pod pretekstem, że to magazyn jest źródłem prawdy. W rzeczywistości jedynie niejednoznaczność się przeniosła – panel analityczny pokazuje uznaną przychód, agent raportuje wartość net_amt, a dział finansowy zachowuje swój arkusz kalkulacyjny. Organizacja zyskała kolejny „dialekt”, ale bez żadnej dodatkowej jasności.
Kontrola jest prosta: gdy definicja metryki nie przenosi się z magazynu do narzędzia BI, a następnie do agenta, zmieniono jedynie nazwę etykiety, a spór wciąż trwa.
Portowalność nie wymaga czwartej platformy. Warunkiem jest to, aby użytkownik spoza oryginalnego pliku mógł wykonać tę samą operację i otrzymać ten sam wynik. Takim narzędziem może być obiekt metryk dostępny natywnie w magazynie, akceptowany przez każdy silnik, usługa metryk bez interfejsu graficznego lub ściśle kontrolowany model semantyczny dostępny za pośrednictwem API do wyszukiwania lub adaptera MCP. Prosty test rozstrzyga tę kwestię: edytuj definicję raz i sprawdź, czy wszyscy użytkownicy ją przestrzegają. To, co pozostaje bez zmian, to kopia.
Metryki dostępne natywnie w magazynie wydają się atrakcyjne, gdy większość danych znajduje się na jednej platformie, ale istnieje tu znane ograniczenie. Definicja jest zatwierdzona tylko w tym konkretnym miejscu, więc agent działający w innym magazynie lub replika nigdy jej nie napotka. Podejścia federacyjne próbują utrzymać jednoznaczne znaczenie w różnych silnikach, ale zawodzą, gdy tak zwana warstwa uniwersalna staje się kolejną kopią z lepszym formatem YAML.
Nieco brzydki model przenośny w systemie metrycznym jest lepszy od pięknego modelu uwięzionego w pliku, którego mogą skompilować tylko trzej programiści, ponieważ agenci nie będą czekać na ten plik – będą szukać alternatyw.
Jak wygląda model gotowy do użycia przez agenty
Większość modeli, które są dziedziczone, została stworzona dla osoby, która już znała biurowe plotki. Programista rozumie, dlaczego określona wyrażenie analityczne pomija dany kanał; agent, który widzi tylko wynik, tego nie potrafi. Miara DAX o zabawnym nazwie może służyć jako prywatny sygnał, ale dla osoby próbującej ją wykorzystać brzmi jak szum. W jednym rzeczywistym pliku użyto [NS Adj LY %] na oznaczenie sprzedaży netto, skorygowanej, z zeszłego roku, w procentach, po odjęciu ceny hurtowej oraz kosztów związanych z sklepem tymczasowym. Trzy osoby potrafiły to odszyfrować, a czwarty czytelnik był agentem, który interpretował NS jako sprzedaż netto i nie szukał dalej.
Lista kontrolna nie jest niczym egzotycznym. To stara sztuka analityki biznesowej, przy której nieostrożność kosztuje więcej:
- Szczerze nazwane elementy. Wykorzystaj słownictwo, którego już używa firma, więc
recognized_revenuebędzie lepsze odNS_Adj. Jeśli dwa zespoły używają różnych terminów, wybierz jeden do modelu i zapisz drugi jako alias w opisie, zamiast ukrywać tę różnicę w skrócie. - Klauzule dotyczące zastosowania. Określ, w jakich sytuacjach metryka ma zastosowanie – na przykład zaznacz, że nadaje się do raportowania dla zarządu, nie jest odpowiednia dla danych szybkiego raportowania z poszczególnych sklepów i nie uwzględnia sprzedaży hurtowej. Kiedyś była to opcja, teraz ten akapit odróżnia pewne dane od domysłów.
- Deklarowane relacje. Klient, faktura i subskrypcja powinny być wyraźnie powiązane, aby agent nie musiał próbować łączyć danych, gdy dwa identyfikatory nazywają się oba
cust_id. - Niewielka powierzchnia. Każda widoczna kolumna techniczna to szansa na pominięcie danej miary. Należy ukryć surowe fakty, których osoby dzwoniące nie powinny ponownie agregować. Jest to trudne pod względem politycznym, ale warto to robić, ponieważ API, które ujawnia wszystkie prywatne pola, nie jest prawdziwym API.
- Właściciele i wersje. Należy oznaczyć, które miary są oficjalne, a które stanowią eksperymenty, kto je zmienia oraz co oznacza „v3”, skoro w liście zarządu z zeszłego kwartału użyto wersji v2.
- Bezpieczeństwo w ruchu. Agent nie powinien nigdy mieć możliwości dostępu do szerszego zestawu wierszy, niż ten, który jest widoczny w standardowym raporcie. Gdy zasady na poziomie wierszy istnieją tylko w usłudze BI, podczas gdy agent bezpośrednio łączy się z magazynem danych, skutkiem jest obejście zasad, a nie ich pomoc w działaniu.
Rozważmy recognized_revenue w sklepie detalicznym. Jego formuła to kwota z faktury po odliczeniu kredytów, przeliczona z waluty transakcji według kursu księgowego z dnia wystawienia faktury. Kluczowym elementem jest data faktury wraz z informacją o organizacji sprzedaży, a nie o miejscu dostawy. Nie obejmuje ona sklepów pracowniczych, sprzedaży hurtowej, zamówień testowych oraz sprzedaży międzyspółkowej. Podstawowe wymiary to organizacja sprzedaży, hierarchia produktów i kanał, określone na podstawie typu zamówienia, natomiast tabela ostatniego kliknięcia w marketingu jest niedostępna. Za ten wskaźnik odpowiada kierownik finansów, a aktualną wersją jest ta, która trafiła do zarządu w zeszły piątek.
Załóżmy, że agent prosi o „sprzedaż przez Instagram”. Ta wymiara nie istnieje w tej metryce, więc właściwą odpowiedzią jest odmowa lub przekazanie zadań innemu, certyfikowanemu narzędziu należącemu do działu marketingu. Osoba zajmująca się zbieraniem danych dodałaby tę informację do tabeli dotyczącej ostatniego kliknięcia i oznaczyłaby ją jako wniosek. Połączenie tych danych może być nawet technicznie poprawne, ale opisuje ono zupełnie inne przedsiębiorstwo.
Odmowa jest lepsza niż milczenie, a milczenie lepsze niż prywatna definicja. Zespoły nie lubią tworzyć odmów, ponieważ wtedy prezentacje wyglądają gorzej, ale prezentacje, które zawodzą, lepiej odzwierciedlają sposób funkcjonowania rzeczywistych firm.
Nie chodzi tu o żaden trik związany z LLM. Całą pracę wykonuje stara sztuka analityki biznesowej – ta sama, która kiedyś uzasadniała strukturę danych i regulowała modele analityczne. Zmienił się tylko odbiorca: dawniej niedbalstwo skutkowało błędnym dashboardem, który ktoś mógł zauważyć, a teraz skutkuje błędną decyzją w tempie maszyny.
Praca, która nie znika
Jeśli to zadziała, kolejka zleczeń rzeczywiście się skurczy. Prośba o podział wykresu według regionu może zostać obsłużona przez agenta, gdy region stanowi prawny wymiar danej miary. Prośba o dodanie danych z zeszłego roku to kwestia analityki czasowej, która została już wcześniej ujęta w modelach lub w ogóle nie została uwzględniona.
Błędem byłoby mówić zespołowi BI, że jego praca zniknęła, ponieważ praca ta tylko się przeniosła. Ktoś nadal musi decydować, co oznaczają poszczególne KPI oraz jaka jest oficjalna wersja danych. Ktoś musi określić, które zależności są poprawne, które źródła zasługują na zaufanie i jakie istnieją wyjątki. Ktoś również odpowiada za to, kto może widzieć konkretne wiersze danych, które modele uznaje się za autorytatywne, jak testuje się zmiany oraz w jaki sposób w procesie przeglądu uwidaczniają się informacje o pochodzeniu danych i odpowiedzialnościach.
Ta praca jest mniej przyjemna niż dopracowany wygląd wizualny, a większość tygodni bardziej kusi wysyłka wykresu. Mimo to wartość kumulatywna tego rodzaju pracy jest niska. Wizualizacje są jednorazowe, natomiast definicja, którą mogą używać zarówno osoby odpowiedzialne za zarządzanie, jak i agenci działający w nocy, stanowi cenny zasób.
Można się spodziewać mniej zapytań w stylu „proszę, stwórz interfejs graficzny” oraz więcej konfliktów typu „proszę, działaj jak organ ustawodawczy”. Osoby, które chciały tylko tworzyć wykresy, mogą uznać ten okres za degradację. Ci, którzy chcieli, aby liczby pozostawały poprawne po interakcji z oprogramowaniem, odkryją, że ta nieoceniona praca stała się głównym obowiązkiem.
Modele awarii, które się powtarzają
Ciągle trafiają one jako problemy związane z jakością modelu, więc przed zamianą modelu należy sprawdzić jego jakość.
- Zbieracz kolumn. Agent pobiera pierwsze pole, którego nazwa zawiera
rev. Żadna metryka nie jest wywoływana, mimo że ślad wygląda na aktywny. - Prywatne dane. Każdy użytkownik wybiera własną datę i każdy jest przekonany, że poprawnie odpowiedział „w zeszłym miesiącu”.
- Umowa z Wiki. Rzeczywista zasada jest zapisana na stronie Confluence, do której nikt nie zaglądał od czasu reorganizacji, a sam model ma jedynie komentarz kolumny z napisem „sprzedaż”.
- Pamiątka z stacku. Jedyna certyfikowana metryka znajduje się w pliku BI, a agent komunikuje się z magazynem, ponieważ to była najprostsza ścieżka demonstracyjna.
selling_org. Tablica kontrolna z poniedziałku, której zwykle używał ten kierownik, odrzuciłaby takie zapytanie. Agent wydawał się bardziej skuteczny, ponieważ ominął jedyną kontrolę, która miała znaczenie.Jeśli dwa z tych przypadków brzmią znajomo, ocena chatbotów nie powinna być pierwszym krokiem. Najpierw należy określić metrykę i zdefiniować jej poziom szczegółowości w modelu, następnie wymagać od agenta, aby ją wywoływał, a dopiero potem zacząć dokonywać pomiarów.
Szybki test dla recenzji: poproś o dane dotyczące przychodów z zeszłego miesiąca, a następnie sprawdź szczegóły. Która kolumna z datami została wybrana? Jakie wykluczenia zostały uwzględnione? Czy uwzględniono zakupy pracowników? Agent, który musi wymyślać odpowiedzi, to w rzeczywistości generator SQL, który przypadkowo ma dostęp do tych danych.
Drugi test polega na edycji oficjalnej listy wykluczeń, na przykład poprzez ostateczne usunięcie zakupów pracowników z uznanych przychodów, a następnie sprawdzenie, kto dokonuje aktualizacji tego samego dnia. Gdy panel sterowania się zmienia, a agent pozostaje bez zmian, okazuje się, że prawdziwym API jest ręcznie skompilowany plik, a agent jest jedynie turystą.
Uważaj także na „przydatnego” agenta, który potajemnie dodaje wymiar, gdy certyfikowana metryka nie ma go. W tym momencie umowa przestaje obowiązywać. Prawidłowe postępowanie polega na stwierdzeniu, że ten wymiar nie występuje w danej metryce. Menedżerom produktów nie podoba się to stwierdzenie, ale jest lepsze od listu do zarządu, który trzeba później wycofać.
Nie zaczynaj od chatbota
Większość programów rozpoczyna się od widocznych narzędzi: który model, jaka baza wektorowa, czy używać MCP, które miejsca dla copilota nabyć. Jeśli celem są wiarygodne odpowiedzi dotyczące konkretnej firmy, lepszy będzie bardziej bezpośredni punkt wyjścia.
Gdzie definiuje się przychody w oprogramowaniu do tworzenia formularzy? Która klasa klientów jest uznawana za autorytatywną? Gdzie obecnie znajduje się logika marży brutto: w widoku SQL, miarze DAX, wyrażeniu Qlik, notatniku czy w pamięci jednej osoby? Odpowiedź „kilka z tych opcji” oznacza, że głównym problemem nie jest generowanie danych. Interfejs, z którym ma mieć do czynienia oprogramowanie, nigdy nie został stworzony.
Praktyczna sekwencja działań wygląda następująco:
- Znajdź punkt konfliktu. Wybierz jedną miarę, co do której już kłócą się dwa zespoły, bez konieczności tworzenia rozbudowanej ontologii.
- Napisz umowę: wzór, szczegółowość, wykluczenia, osoba odpowiedzialna oraz wymagane wymiary.
- Dostarczaj dane przez jeden zabezpieczony ścieżkę zapytań, którą mogą używać zarówno raporty, jak i agenci.
- Dodaj osobę wywołującą zapytanie, a dopiero w tym momencie wprowadź asystenta lub agenta do obsługi tej miary.
Bez odniesienia do oficjalnej procedury księgowania przychodów, chatbot reklamuje problem semantyczny, którego nikt jeszcze nie nazwał.
Jeden z zespołów musiał kiedyś dostarczyć asystenta planowania przed następnym komitetem sterującym, ale przez pierwsze dwa tygodnie celowo odkładał jego użycie. Prace trafiły do zmiennej available_to_promise, a jej zasady zapisano na jednej stronie. Zignorowano towary znajdujące się w kontroli jakości oraz uszkodzone klatki. Ilości przeznaczone do pakowania liczyły się tylko w przypadku zamówień hurtowych, a jednostki w transporcie – dopiero po otrzymaniu ASN. Te zasady trafiły do modelu, którego już używał magazyn, a przy pytaniach dotyczących zapasów asystent mógł korzystać wyłącznie z tej miary. Pierwsza prezentacja przebiegła spokojniej. Do drugiego tygodnia nikt już nie podawał trzeciej liczby podczas spotkań standup, co było sukcesem, a dostawca modelu pozostał niezmieniony.
Panel sterowania pozostają. Dobrze zaprojektowana wizualizacja nadal lepiej przedstawia tygodniowy obraz niż bańka czatu. Po prostu przestały być jedynym celem, a ten sam kontekst musi teraz być spójny, gdy jest używany przez osobę, raport lub zautomatyzowany proces, który nie zauważy, gdy dane są błędne.
Interfejs, który już istnieje
Spotkania typu standup z dwoma oficjalnymi liczbami wyjaśniają całą sytuację. Modele nie były w żaden interesujący sposób mylące. Mylona była organizacja, a pracownicy przenosili tę dezorientację do zdań, które brzmiały jak wiedza.
Gdy oprogramowanie zaczyna wykorzystywać certyfikowaną opisę sposobu, w jaki firma postrzega swoje dane, tabele przestają być interfejsem, a zastępują je określone metryki.
Prośba o ostrożność pracownika przy obsłudze przychodów szybko znika. To, co pozostaje, to model, który nigdy nie pozwala na ad hoc odbudowę danych dotyczących przychodów.
To, co zostanie opublikowane, to właśnie to, co nazwie agent. Jeśli ujawni się surowe tabele, staje się to źródłem dochodu; jeśli ujawni się nazwana operacja, może w końcu wybrać tę, którą już przyjęli analitycy.
Nowoczesne narzędzia nadal mają swoją atrakcyjność: copilot, który ściga anomalie o 6 rano, lub agent, który otwiera zgłoszenie, gdy poziom dostępności spada poniżej określonego progu. Są one uczciwe tylko w odniesieniu do tych samych operacji, co do których już doszli do porozumienia ludzie.
Zacznij od metryki, która już wywołuje spory, i sformułuj wobec niej cztery kluczowe pytania. Skieruj jeden panel sterowania i jednego agenta na ten obiekt, a resztę „jeziora danych” pozostaw nietkniętą, dopóki oba narzędzia nie uzgodnią swoich decyzji przez miesiąc. Następnie rozszerz katalog.
Literatura pokrewna
- Co naprawdę napędza sieć neuronową: kompilatory AI działające pod Pythonem — Prześledź model od wyrażenia w Pythonie przez grafy obliczeniowe, fuzję operatorów, reprezentacje w stylu MLIR oraz przekształcenie ich w kod dla CPU, GPU i akceleratorów.
- Szukanie semantyczne w PostgreSQL za pomocą pgvector i Node.js – bez potrzeby LLM — Stwórz system wyszukiwania oparty na znaczeniach w PostgreSQL przy użyciu pgvector, embeddingów MiniLM i Node.js: tokeny, fragmenty, wektory, indeks IVFFlat, operatorzy odległości oraz sposoby odczytywania wyników.