OpenAI wprowadziło w ChatGPT Work agenta danych, który pozwala pracownikom zadawać pytania dotyczące danych firmowych, badać zmiany, tworzyć pulpity oraz rekomendować lub wykonywać kolejne działania w języku naturalnym. Ogłoszenie jest istotne, ponieważ przenosi coraz bardziej znaną obietnicę AI do mniej efektownego wąskiego gardła: analityki biznesowej, która jest technicznie dostępna, ale trudna w użyciu dla zwykłych pracowników.

Abstrakcyjny panel analityki biznesowej z wykresami, definicjami metryk, kontrolą uprawnień i ścieżką audytu

Produkt może łączyć się między innymi z Amazon Redshift, Datadog, Google BigQuery, ClickHouse, Databricks, MongoDB i Snowflake. Może też korzystać z plików i dokumentów z Google Drive oraz SharePoint, pracować z definicjami biznesowymi dostarczanymi przez warstwy semantyczne, a także współdziałać z narzędziami takimi jak Tableau, Power BI, Sigma i ThoughtSpot. OpenAI podaje, że administratorzy wybierają dostępne połączenia i role, a zapytania respektują istniejące uprawnienia podłączonego konta. OpenAI opisuje produkt i obsługiwane połączenia tutaj.

Brzmi to jak nowy interfejs do analityki. Tak właśnie jest, ale użyteczniejsza interpretacja jest węższa: agent danych może obniżyć koszt zadania pierwszego pytania. Nie usuwa jednak potrzeby ustalenia, co to pytanie oznacza, czy dane źródłowe się do niego nadają ani jaką rangę powinna mieć odpowiedź w firmie.

Dla zespołów rozważających ten produkt właściwym punktem wyjścia nie jest zbiór efektownych promptów. Lepiej zacząć od kontrolowanego pilotażu dotyczącego jednego procesu decyzyjnego, z nazwanymi metrykami, ograniczonym dostępem do danych, niezależnymi kontrolami oraz wyraźną granicą między analizą a działaniem.

Co właściwie dodaje OpenAI

Tradycyjne narzędzia analityki biznesowej już obsługują pulpity, zapytania SQL, raporty cykliczne i zarządzane metryki. Nową warstwą jest konwersacyjne badanie danych. Użytkownik może zapytać, dlaczego zmieniła się tygodniowa liczba aktywnych użytkowników, porównać okresy, wskazać prawdopodobne czynniki, poprosić o wykres, zapytać o zastrzeżenia, a następnie przekształcić wynik w pulpit do udostępnienia — bez poznawania składni hurtowni ani struktury aplikacji BI.

OpenAI podaje, że agent może korzystać z firmowych terminów, definicji metryk, własnych obliczeń i relacji między źródłami danych. Definicje te mogą pochodzić z warstw semantycznych oraz z zaufanych systemów, takich jak dbt, Databricks Genie Ontology, GitHub, Snowflake Horizon i istniejące pulpity BI. To ważny szczegół. Pytanie w języku naturalnym jest tak wiarygodne, jak definicje dostępne za jego interfejsem.

Weźmy pytanie: dlaczego w zeszłym kwartale spadła retencja brutto? Retencja brutto może mieć kilka uzasadnionych znaczeń. Sposób obliczenia może różnić się zależnie od produktu, segmentu klientów, sposobu traktowania walut, statusu umowy, okna odnowienia oraz uwzględniania rozszerzeń lub obniżeń zakresu. Model może stworzyć przekonujące wyjaśnienie dla niewłaściwej definicji. Podłączenie warstwy semantycznej zwiększa szansę, że agent zinterpretuje pytanie zgodnie z intencją, ale nie sprawia, że definicja staje się oczywista sama z siebie.

Produkt wykracza też poza odpowiedź tylko do odczytu. OpenAI twierdzi, że użytkownicy mogą prosić agenta o rekomendowanie kolejnych kroków, wskazanie osób, które powinny zostać zaangażowane, udostępnianie ustaleń przez Slacka lub e-mail, a także wykonywanie zatwierdzonych działań za pomocą podłączonych narzędzi. W tym momencie zmienia się profil ryzyka. Błędny wykres jest problemem do weryfikacji. Błędna wiadomość, aktualizacja zgłoszenia, korekta prognozy lub uruchomienie przepływu pracy może stać się incydentem operacyjnym.

W ogłoszeniu przedstawiono agenta danych jako dostępnego przez katalog wtyczek ChatGPT Work. Administratorzy mogą zainstalować wtyczkę Data, włączyć odpowiednie wtyczki źródeł danych, zarządzać dostępem, a następnie pozwolić użytkownikom rozpocząć rozmowę za pomocą @Data. Początkowa konfiguracja nie sprowadza się więc do wyboru chatbota przez pracownika. To decyzja dotycząca ustawień obszaru roboczego, obejmująca właścicieli danych, administratorów tożsamości, zespoły bezpieczeństwa oraz osoby odpowiedzialne za definicje raportów.

Jaki praktyczny problem może rozwiązać

Wiele próśb analitycznych nie jest trudnych dlatego, że SQL jest skomplikowany. Trudność polega na tym, że prośba musi przejść przez kilka kolejek. Menedżer zauważa zmianę konwersji, pyta analityka o wyjaśnienie, czeka, aż analityk znajdzie odpowiednie tabele, doprecyzowuje definicję, ponownie czeka na wykres, a potem odkrywa, że drugi zespół używa innego mianownika. Opóźnienie może być dłuższe niż sama analiza.

Agent konwersacyjny może obniżyć koszt pierwszego podejścia. Menedżer sprzedaży może zbadać zmianę w lejku, zanim poprosi zespół revenue operations o formalny raport. Lider wsparcia może porównać liczbę zgłoszeń z obsadą i danymi o poziomie usług. Zespół produktu może przeanalizować zmianę retencji i przygotować listę hipotez do kolejnego eksperymentu. Finanse mogą użyć narzędzia do znalezienia anomalii w wydatkach, zanim zdecydują, czy potrzebny jest pogłębiony przegląd.

Wartość nie polega na tym, że każdy pracownik zostanie data scientistą. Chodzi o to, że więcej pytań można wstępnie obsłużyć blisko chwili, w której się pojawiają. Na łatwe pytania można odpowiedzieć bezpośrednio. Niejednoznaczności mogą zostać ujawnione wcześniej. Analitycy mogą poświęcać mniej czasu na tworzenie powtarzalnych pierwszych wersji i więcej na sprawdzanie definicji, projektowanie pomiarów oraz decyzje wymagające osądu.

OpenAI podaje, że z agentów danych w ChatGPT Work korzysta niemal cały jego zespół produktowy oraz ponad dwie trzecie organizacji go-to-market. Wymienia również organizacje uczestniczące w programie alfa, w tym NTT DATA, Thermo Fisher, ServiceTitan, Zipline, Empower, Piston i inne. Przykłady te są użytecznymi sygnałami dotyczących zakładanego sposobu pracy, ale pozostają raportowanymi przez dostawcę przykładami klientów, a nie niezależnym dowodem ogólnej skuteczności. Nabywca powinien traktować je jako odniesienia do wdrożenia, nie jako prognozę zwrotu z inwestycji.

Dobry pilotaż powinien mierzyć mniej widowiskowe wyniki: czas od pytania do sprawdzonej pierwszej odpowiedzi, odsetek odpowiedzi wymagających korekty, liczbę powielonych próśb o raport, wykorzystanie przez zamierzoną grupę użytkowników, koszt zapytań oraz liczbę sytuacji, w których użytkownik źle zrozumiał metrykę mimo płynnego wyjaśnienia. Takie pomiary pokazują, czy agent usprawnia proces decyzyjny, a nie tylko produkuje atrakcyjne artefakty.

Dlaczego warstwa semantyczna jest ważniejsza od promptu

Określenie „analityka w języku naturalnym” może sugerować, że główną innowacją jest interfejs. W praktyce ważniejszy jest model danych znajdujący się za interfejsem. Warstwa semantyczna zapewnia systemowi wspólne nazwy, relacje, obliczenia i reguły. Bez niej agent musi odgadywać znaczenie biznesowe na podstawie nazw tabel, nazw kolumn, opisów, przykładowych wartości i kontekstu rozmowy. Może to wystarczyć do eksploracji. Jest słabą podstawą regularnego raportowania dla kadry kierowniczej.

Przed rozpoczęciem pilotażu zespół powinien spisać definicje metryk, o które użytkownicy prawdopodobnie będą pytać. Każda definicja powinna zawierać tabele źródłowe, strefę czasową, przedział czasu, reguły filtrowania, zasady włączania i wyłączania rekordów, sposób traktowania zwrotów lub anulowań, przeliczanie walut oraz właściciela uprawnionego do zatwierdzenia zmiany. Lista nie musi obejmować całej hurtowni. Powinna obejmować decyzję, którą ma wspierać pilotaż.

Zespół powinien też udokumentować, które źródło ma pierwszeństwo, gdy systemy się różnią. CRM może zawierać etap szansy sprzedażowej, system rozliczeniowy status faktury, a baza produktu rzeczywiste wykorzystanie. Wszystkie trzy informacje mogą być poprawne w swoich kontekstach. Agent potrzebuje reguły odpowiadania na konkretne pytanie biznesowe, a nie po prostu dostępu do wszystkich trzech systemów.

Podział odpowiedzialności może wyglądać tak:

  • Agent tłumaczy pytanie na badanie, pobiera istotne informacje, porównuje okresy, przygotowuje wizualizację i wskazuje możliwe czynniki.
  • Właściciel danych definiuje metrykę, priorytet źródeł, dopuszczalne filtry i wymóg aktualności.
  • Analityk lub ekspert dziedzinowy testuje wynik, sprawdza dowody i decyduje, czy wystarcza on do podjęcia decyzji biznesowej.
  • Właściciel decyzji ustala, jakie działanie nastąpi i czy dowody spełniają standard organizacji.

Agent może skrócić drogę między tymi osobami. Nie może prawidłowo przejąć odpowiedzialności za wszystkie cztery role.

Uprawnienia są konieczne, ale nie tworzą całego systemu kontroli

OpenAI podaje, że administratorzy organizacji mogą wybierać dostępne połączenia i role, a zapytania respektują uprawnienia podłączonego konta, w tym ograniczenia na poziomie tabel, wierszy i kolumn. To podstawowy wymóg projektowy. Interfejs AI nie powinien stawać się bocznym wejściem omijającym model autoryzacji, który już chroni hurtownię.

Nie wystarczy jednak usłyszeć, że uprawnienia są respektowane. Implementację trzeba przetestować na reprezentatywnych tożsamościach. Pilotaż powinien obejmować użytkownika, który widzi zbiór danych dla jednego regionu, ale nie dla innego; użytkownika, który może zobaczyć zagregowane wynagrodzenia, lecz nie pojedyncze pensje; oraz użytkownika, który może przeglądać aktywność klientów bez dostępu do identyfikatorów osobowych. Zespół powinien testować zarówno pytania bezpośrednie, jak i pytania pośrednie, które mogłyby ujawnić ograniczone informacje przez sumy, porównania lub serię powtarzanych zapytań.

Dokumentacja Google BigQuery pokazuje, dlaczego takie testy są ważne. BigQuery obsługuje kontrolę dostępu na poziomie projektu, zbioru danych i tabeli, a także bezpieczeństwo na poziomie wierszy i kolumn. Zasady dotyczące wierszy filtrują rekordy widoczne dla określonego podmiotu; zasady dotyczące kolumn mogą ograniczać dostęp do wrażliwych pól i łączyć się z maskowaniem. Google ostrzega również, że źle zaprojektowane wzorce dostępu mogą ujawniać informacje przez kanały boczne, takie jak zachowanie zapytań lub czas ich wykonania. Dokumentacja BigQuery wyjaśnia współdziałanie kontroli wierszy i kolumn.

Wniosek wykracza poza BigQuery. Model nie musi wydrukować chronionej wartości, aby ujawnić coś na jej temat. Prompt w rodzaju „który pracownik z małego europejskiego zespołu miał największy wzrost wynagrodzenia?” może stać się wrażliwy, nawet jeśli tabela nie udostępnia bezpośrednio kolumny z pensją. Progi agregacji, małe grupy, rzadkie kategorie i powtarzane porównania wymagają wyraźnego traktowania.

Minimalny przegląd uprawnień powinien odpowiedzieć na pięć pytań:

  1. Które tożsamości mogą uruchamiać agenta?
  2. Z jakich połączeń może korzystać każda z tych tożsamości?
  3. Czy system źródłowy stosuje te same ograniczenia wierszy i kolumn do zapytań tworzonych przez agenta, co do zwykłych zapytań?
  4. Co dzieje się, gdy agent łączy dane ze źródeł o różnych zasadach dostępu?
  5. Które logi pokazują użytkownika, pytanie, wygenerowane zapytanie lub operację, użyte źródła danych, miejsce docelowe wyniku i ewentualne później zatwierdzone działanie?

Jeśli odpowiedź na ostatnie pytanie jest niejasna, pilotaż nie jest gotowy na dane wrażliwe.

Deklaracje dotyczące prywatności trzeba odnieść do konkretnego produktu i umowy

Polityka OpenAI dotycząca danych biznesowych mówi, że domyślnie dane wejściowe i wyjściowe z ChatGPT Enterprise, ChatGPT Business, ChatGPT Edu, ChatGPT for Healthcare oraz platformy API nie są używane do trenowania ani ulepszania modeli. Opisuje także szyfrowanie podczas przesyłania i w spoczynku, kontrolę opartą na rolach, opcje przechowywania dla kwalifikujących się organizacji oraz wybór regionu przechowywania danych dla uprawnionych usług. Strona OpenAI dotycząca danych biznesowych wymienia te zobowiązania i ich zakres.

Zobowiązania te odpowiadają na ważne pytania, ale nie na wszystkie, które powinien zadać zespół danych. Przegląd musi obejmować dokładną edycję ChatGPT Work, podłączone wtyczki, dostawców danych, konfigurację przechowywania, dostęp pomocniczy, przetwarzanie regionalne, zachowanie podczas eksportu i usuwania danych oraz warunki dotyczące każdej usługi partnerskiej. Obietnica, że model nie jest trenowany na danych biznesowych, nie jest równoznaczna z obietnicą, że żaden podłączony system nie przechowuje logów zapytań, skopiowanych wyciągów, artefaktów pulpitów ani zapisów działań.

Architektura agenta danych wprowadza także pytanie o lokalizację danych. OpenAI podaje, że produkt może łączyć się ze źródłami firmowymi, a w ogłoszonym tego samego dnia produkcie dla usług finansowych opisuje wbudowane dane od dostawców, które są indeksowane i przechowywane w infrastrukturze OpenAI. Oferta dla usług finansowych jest odrębnym produktem, ale pokazuje, dlaczego klienci powinni odróżniać konektor, który odpytuje ich system, od usługi, która kopiuje, indeksuje, buforuje lub wzbogaca dane w innym miejscu. Ogłoszenie OpenAI dotyczące usług finansowych opisuje tę różnicę dla swojej oferty kierowanej do tego sektora.

Przegląd bezpieczeństwa powinien wymagać diagramu przepływu danych, a nie tylko podsumowania bezpieczeństwa. Diagram powinien pokazać drogę promptu, wygenerowanego zapytania, pobranych wierszy, plików pośrednich, wyniku pulpitu, rekordu audytowego i każdej wiadomości wychodzącej. Powinien wskazywać, które elementy obsługują OpenAI, hurtownia, narzędzie BI, konektor i system działań. Organizacja powinna wiedzieć, który komponent odpowiada za usuwanie danych i który za egzekwowanie dostępu na każdym etapie.

Przegląd dowodów odróżnia analizę od pozorów automatyzacji

Stwierdzenie, że sprzedaż spadła z powodu słabszego popytu ze strony przedsiębiorstw, może być wiarygodne, a mimo to błędne. Przydatne pytania brzmią: jakie dane wspierają ten wniosek, jakie porównanie wykonano, które alternatywne wyjaśnienia sprawdzono i czego nadal nie wiadomo?

OpenAI podaje, że użytkownicy mogą przeglądać dowody stojące za ustaleniami i zadawać pytania uzupełniające. Powinno to stać się obowiązkowym zwyczajem pracy. Pulpit bez widocznej definicji i ścieżki źródłowej nie jest ukończoną analizą. Jest wskazówką do dalszego badania.

Praktyczny szablon kontroli może wymagać od agenta zwrotu:

  • dokładnej użytej definicji metryki;
  • zakresu dat i okresu porównawczego;
  • tabel, widoków, dokumentów lub pulpitów, z których skorzystano;
  • zastosowanych filtrów i złączeń;
  • liczby uwzględnionych rekordów lub grup;
  • informacji o aktualności danych i ostrzeżeń o brakach;
  • najmocniejszych dowodów na rzecz każdego wniosku;
  • wiarygodnych alternatywnych wyjaśnień;
  • testów, które mogłyby obalić główne wyjaśnienie;
  • rekomendowanego następnego kroku, który nie zakłada, że wniosek jest prawdziwy.

Ten format jest celowo mniej efektowny niż pewna siebie narracja. Łatwiej go kontrolować. Uczy też użytkowników, że wygenerowane wyjaśnienie jest hipotezą popartą dowodami, a nie odpowiedzią dla zarządu tylko dlatego, że zostało jasno napisane.

Zespoły powinny utrzymywać niewielki zestaw ewaluacyjny złożony z rzeczywistych pytań, znanych odpowiedzi i znanych pułapek. Może on obejmować metrykę, której definicja się zmieniła, tabelę z opóźnionym odświeżaniem, zduplikowany rekord klienta, region objęty ograniczeniem uprawnień oraz pytanie, na które prawidłową odpowiedzią jest brak wystarczających danych. Zestaw należy uruchomić przed startem oraz po każdej istotnej zmianie warstwy semantycznej, konektora, modelu lub uprawnień.

Szczególnej uwagi wymaga przypadek „brak wystarczających dowodów”. System, który zawsze wskazuje czynnik, jest bardziej niebezpieczny niż taki, który czasem się zatrzymuje. Użyteczny agent powinien umieć powiedzieć, że dostępne dane wskazują na korelację, ale nie na przyczynowość; że źródło jest nieaktualne; że dwa systemy są ze sobą sprzeczne; albo że próba jest zbyt mała, by wskazać wiarygodny wzorzec.

Koszty to nie tylko opłata za subskrypcję

Ogłoszenie OpenAI nie podaje uniwersalnej, publicznej ceny agenta danych. Przedwczesne byłoby więc wyliczanie prostego zwrotu na użytkownika. Model kosztów będzie prawdopodobnie zależał od ustaleń dotyczących ChatGPT Work, wykorzystania modeli, podłączonych systemów, opłat za zapytania w hurtowni, licencji BI, umów z dostawcami danych, przechowywania oraz narzędzi wykonujących działania. Potencjalni nabywcy powinni pytać o ceny i limity wykorzystania właściwe dla ich obszaru roboczego, zamiast wyciągać wnioski z planów konsumenckiego ChatGPT lub zwykłych kosztów bazy danych.

Po uruchomieniu pojawiają się także koszty operacyjne. Zapytania skanujące duże tabele mogą zużywać zasoby hurtowni. Użytkownik, który wielokrotnie prosi o odświeżenie pulpitu, może generować zbędne obciążenie. Eksploracja w języku naturalnym może zwiększyć liczbę próśb, bo łatwo zadawać pytania uzupełniające. Niektóre systemy pobierają opłaty za przeskanowane dane, wywołania API, odświeżenia pulpitów lub płatne konektory.

Odpowiedzialny pilotaż powinien ustalić budżety i je obserwować. W miarę możliwości należy zacząć od zarządzanych widoków lub tabel podsumowujących. Warto dodać limity czasu zapytań i skanowania. Koszt trzeba rejestrować według zespołu i przepływu pracy. Aktualność danych powinna być jawna, aby użytkownicy nie odświeżali stale źródła, które aktualizuje się tylko raz dziennie. Należy też ustalić, czy pulpit wygenerowany przez agenta może odświeżać się automatycznie, czy tylko na żądanie.

Kontrola kosztów jest również kwestią modelu danych. Źle zaprojektowana hurtownia zmusza agenta do wielokrotnego opłacania pracy, którą można było przygotować raz. Dobrze zaprojektowana warstwa semantyczna, tabela agregująca lub zarządzany widok mogą jednocześnie poprawić szybkość, wiarygodność i koszty.

Gdzie użyć produktu najpierw, a gdzie nie

Najlepsze pierwsze przypadki użycia mają jasno określonego właściciela, umiarkowaną wrażliwość, powtarzalne pytania i człowieka, który może szybko sprawdzić wynik. Przykłady obejmują badanie wykorzystania produktu, przygotowanie wewnętrznego przeglądu operacyjnego, znajdowanie niespójności w raportach, analizę popytu na wsparcie, porównywanie wyników kampanii oraz przygotowanie listy pytań dla analityka.

Pierwszym przypadkiem użycia nie powinien być najważniejszy politycznie raport w firmie. Nie należy zaczynać od wynagrodzeń, regulowanych decyzji dotyczących klientów, wniosków medycznych, decyzji kredytowych, rozstrzygnięć prawnych ani automatycznego przepływu, który zmienia rekordy dotyczące wielu osób. Te obszary mogą w przyszłości skorzystać z tego samego interfejsu, ale wymagają silniejszych kontroli, bardziej formalnej walidacji i jasnego podziału odpowiedzialności.

Małe firmy nie powinny zakładać, że potrzebują dużej hurtowni. Niewielka organizacja może zyskać, podłączając zaufany zbiór danych sprzedażowych lub dotyczących wsparcia i wykorzystując agenta do odpowiedzi na wąskie pytanie operacyjne. Może też odkryć, że jej rzeczywistym problemem są brakujące definicje, a nie brak oprogramowania analitycznego. To również wartościowy wynik.

Duże firmy nie powinny zakładać, że szerokie wdrożenie będzie automatycznie efektywne. Globalna hurtownia może zawierać lata wyjątków, przejęcia, przemianowane produkty, powielone potoki oraz zespoły używające tego samego terminu w różny sposób. Agent ułatwi dostęp do tej niejednoznaczności. Nie sprawi, że niejednoznaczność zniknie.

Zespoły powinny na razie pominąć produkt, jeśli nie potrafią wskazać właściciela źródła, przetestować uprawnień, zapewnić ścieżki audytu lub wyznaczyć osoby do sprawdzania wyników. W takiej sytuacji agent może zwiększyć szybkość, z jaką organizacja tworzy rozbieżności.

Czterotygodniowy pilotaż, który dostarcza użytecznych dowodów

Rozsądny pilotaż można przeprowadzić w czterech etapach. Ważniejszy od kalendarza jest podział między nimi i warunki przejścia dalej.

Tydzień pierwszy: wybierz decyzję, nie technologię

Wybierz jedną powtarzalną decyzję, na przykład wyjaśnianie cotygodniowych zmian aktywacji albo przygotowanie przeglądu zdolności zespołu wsparcia. Wskaż grupę użytkowników, właściciela decyzji, właściciela danych, analityka dokonującego przeglądu, akceptowalny czas odpowiedzi i maksymalny poziom wrażliwości. Zapisz pięć do dziesięciu pytań, które zespół rzeczywiście zadaje dziś. Uwzględnij co najmniej jedno pytanie, na które odpowiedzią powinno być ostrzeżenie o niepewności.

Zrób inwentaryzację odpowiednich źródeł i wskaż system będący właścicielem każdego pola. Przygotuj niewielki słownik z definicjami metryk, oczekiwaniami dotyczącymi aktualności i znanymi wyłączeniami. Jeśli zespół nie potrafi uzgodnić definicji, zapisz rozbieżność zamiast prosić agenta o jej rozstrzygnięcie.

Tydzień drugi: przygotuj widoki i uprawnienia

Preferuj zarządzane widoki lub wyselekcjonowane zbiory danych zamiast nieograniczonego dostępu do całej produkcyjnej hurtowni. Oddziel dane eksploracyjne od systemów zawierających bezpośrednie identyfikatory, dane uwierzytelniające, informacje o zdrowiu, szczegóły płacowe lub inne pola wysokiego ryzyka. Utwórz konta testowe odpowiadające osobom, które będą korzystać z pilotażu.

Skonfiguruj logowanie, przechowywanie danych i alerty budżetowe, zanim użytkownicy rozpoczną pracę. Potwierdź, czy podłączone narzędzia przechowują kopie promptów, zapytań, plików, pulpitów lub wyników. Przejrzyj warunki dostawcy i konektora dla dokładnie tych usług, które obejmuje pilotaż.

Tydzień trzeci: sprawdź dokładność i zachowanie w sytuacjach awaryjnych

Uruchom zestaw ewaluacyjny. Porównaj wyniki wygenerowane przez agenta z niezależnie przygotowaną odpowiedzią analityka. Śledź nie tylko poprawność liczbową, ale też poprawność definicji, wybór źródła, zachowanie uprawnień, jakość odwołań do dowodów, ostrzeżenia o aktualności oraz zdolność do odmowy lub zastrzeżenia odpowiedzi.

Poproś użytkowników o zadawanie zwykłych pytań i pozornie prostych pytań testujących granice. Prośba „pokaż mi pełną listę klientów” może szybciej ujawnić problem z polityką dostępu niż złożony prompt analityczny. Testuj małe grupy i wrażliwe segmenty. Testuj nieaktualne źródło. Testuj metrykę, której definicja niedawno się zmieniła.

Tydzień czwarty: zmierz wpływ na przepływ pracy

Pozwól docelowym użytkownikom pracować na rzeczywistych pytaniach o niskim ryzyku. Mierz czas do sprawdzonej odpowiedzi, odsetek korekt, czas przeglądu analityka, koszt hurtowni, liczbę porzuconych sesji oraz to, czy użytkownicy potrafią wyjaśnić dowody stojące za swoimi wnioskami. Porozmawiaj z analitykami dokonującymi przeglądów. Często ujawniają oni, czy agent ograniczył powtarzalną pracę, czy tylko przeniósł sprzątanie na późniejszy etap.

Dopiero po tym etapie zespół powinien zdecydować, czy rozszerzyć dostęp do danych, dodać uprawnienia do wykonywania działań lub podłączyć kolejne jednostki biznesowe. Rozszerzenie powinno wynikać z wykazanych kontroli, a nie z liczby interesujących wykresów powstałych podczas próby.

Alternatywą nie zawsze jest kolejny produkt AI

Firma oceniająca agenta danych powinna porównać go z usprawnieniami, które mogą być mniej widoczne, ale bardziej trwałe. Katalog metryk, zarządzana warstwa semantyczna, lepsze modele hurtowni, program szkoleniowy z samoobsługowego BI, dobrze zaprojektowany zestaw pulpitów albo dyżur analityczny mogą rozwiązać podstawowy problem bardziej bezpośrednio.

W niektórych zespołach właściwa kolejność polega na naprawieniu modelu danych, a dopiero potem dodaniu interfejsu konwersacyjnego. W innych definicje są już poprawne, ale ukryte za narzędziami dla specjalistów, dzięki czemu warstwa języka naturalnego może być naprawdę użyteczna. Można to sprawdzić. Zadaj użytkownikom to samo pytanie przez istniejący interfejs BI i przez agenta. Jeśli agent jest szybszy, ale mniej dokładny, popraw definicje i powtórz test. Jeśli w granicach pilotażu jest jednocześnie szybszy i dokładny, rozszerzaj go ostrożnie.

Wybór zależy także od uzależnienia od dostawcy. Warstwa semantyczna przenośna między silnikami zapytań i narzędziami BI pozwala zachować elastyczność. Przepływ pracy zależny od własnościowych konektorów, zachowania modelu, ukrytej logiki transformacji lub nieudokumentowanych konwencji promptów może być trudny do przeniesienia. Definicje metryk, przypadki ewaluacyjne, reguły dostępu i specyfikacje pulpitów należy przechowywać w systemach, które organizacja może samodzielnie przeglądać i utrzymywać, niezależnie od interfejsu konwersacyjnego.

Decyzja dla zespołów na dziś

Agent danych OpenAI jest najbardziej przekonujący jako wejście do zarządzanych danych, a nie jako zastępstwo zarządzania danymi. Może udostępnić badanie osobom, które znają problem biznesowy, ale nie znają schematu hurtowni. Może przygotować użyteczną pierwszą wersję analizy, ujawnić pytania uzupełniające i przekształcić wynik w artefakt do udostępnienia. To istotne usprawnienia, gdy kolejki raportowe są długie, a definicje już uporządkowane.

Jego główne ograniczenie jest równie praktyczne. Płynna odpowiedź może ukrywać słabą metrykę, niepełne złączenie, nieaktualne dane, nieuprawniony wniosek albo niepopartą dowodami opowieść o przyczynowości. Im sprawniej działa system, tym ważniejsze staje się uwidocznienie dowodów, uprawnień i niepewności.

Zespoły powinny go wypróbować, gdy mają wąski proces decyzyjny, zaufane dane źródłowe, jasne definicje, testowalne uprawnienia oraz osoby odpowiedzialne za przegląd. Powinny odłożyć wdrożenie, jeśli liczą na to, że chatbot rozstrzygnie nierozwiązane kwestie własności danych albo zrekompensuje brak kontroli.

Użyteczne pytanie nie brzmi: czy pracownik może zadać bazie danych pytanie zwykłym językiem? Ta możliwość pojawia się już w kilku formach. Ważniejsze jest to, czy organizacja potrafi sprawić, by odpowiedź była możliwa do prześledzenia, właściwie ograniczona, przystępna kosztowo i wystarczająco bezpieczna, aby wpłynąć na rzeczywistą decyzję. W przypadku agenta danych właśnie ta granica oddziela wygodną analitykę od pracy, na której można polegać.

Źródła