Duet AI czyli Twój nowy asystent od zapytań SQL w BigQuery

›

Generatywna sztuczna Inteligencja przeszła testowo przez analityczne bramy Google Cloud i rozpycha się łokciami aby asystować analityków i inżynierów danych w codziennych zadaniach w BigQuery.

I choć na razie kolos ma raczej gliniane nogi to jego duże serce i ocean potencjału implementacyjnego pozwalają spojrzeć optymistycznie na to jak w przyszłości może on zdefiniować na nowo rolę analityków i inżynierów danych w organizacji.

Mowa tutaj o Duet AI, nowej technologii od Google, która dotarła w wersji testowej do różnych zakamarków Google Cloud tj. Hurtownia Danych BigQuery, Looker czy Dataplex i jest gotowa by asystować użytkowników w ich codziennej pracy z czyszczeniem danych, przygotowywaniem ich do analizy, odpowiadaniu na pytanie biznesowe i przewidywaniu trendów.

To oczywiście w teorii. Ja w dzisiejszym wpisie skupiając się na możliwościach Duet AI w BigQuery będę starał się odpowiedzieć na pytanie – jak to wygląda w praktyce.

W czym ma pomagać Duet AI w BigQuery?

Zgodnie z dokumentacją od Google podstawowymi obszarami, w których pomóc nam może Duet AI w BigQuery mają być:

I choć ta lista obecnie jest dość krótka, jak się zapewne domyśla każdy pracujący na co dzień z językiem SQL w BigQuery, potencjał teoretycznie jest ogromny.

W praktyce oznacza to, że właśnie do Twojej firmy został zatrudniony Twój osobisty asystent do tworzenia zapytań, tabel, widoków, funkcji, modeli analitycznych, który zawsze znajdzie dla Ciebie czas a jedyne co potrzebujesz to potrafić się z nim dogadać.

Ale jak z nim zagadać?

Aby nawiązać relację z naszym asystentem musimy zrobić pierwszy krok. W naszym przypadku będzie to włączenie Duet Ai w BigQUery, oraz wybranie funkcji z, których chcemy korzystać.

Wybieramy Auto Completion and Auto Generation i właśnie te dwie funkcjonalności będziemy dzisiaj testować i opisywać.

Z Duet Ai rozmawiamy obecnie tylko w języku angielskim a tekst wpisujemy tam gdzie domyślnie wpisywaliśmy kod SQL. Nasz “prompt” może mieć wiele linijek, ale każda z nich powinna być rozpoczęta od znaku #.

Testowy prompt przekopiowany z dokumentacji Google powinien zwrócić nam wynik pokazujący średnią długość podróży rowerem przez każdego subskrybenta z publicznego zbioru danych:

Po kliknięciu Spacji lub klawisza Enter, Duet Ai tworzy dla nas rekomendacje zapytań, z których możemy wybrać te odpowiadające najbardziej naszej potrzebie a następnie zatwierdzić je klawiszem TAB.

Egzekucja danego zapytania zwraca poniższą tabelę.

Test jak najbardziej udany, i choć format rezultatu końcowego idealny nie jest, zapytanie zwraca oczekiwany przez nas rezultat.

Zgodnie z dokumentacją struktura naszego prompta wygląda mniej więcej tak:

				
					# Using `bigquery-public-data.austin_bikeshare.bikeshare_trips`, calculate the
# average trip length by subscriber type.

W pierwszej kolejności przekazujemy nazwę tabeli oraz zbioru danych, w którym się znajdują nasze dane a w drugiej logiczno biznesową formułę, którą nasz asystent powinien zamienić na język SQL.

Teraz spójrzmy na nazwy pól i ich opisy aby zrozumieć jak model wnioskuje, na podstawie których pól powinien liczyć naszego subskrybenta i średni czas podróży.

Nasze zapytanie Select używa pól: subscriber_type i duration_minutes podczas gdy w prompcie przekazujemy mu prośbę o policzenie average trip length by subscriber type

Aby wyświetlić wszystkie kolumny w zbiorze danych wraz z opisami użyję poniższego zapytania:

Dzięki niemu mogę zobaczyć jaką wartość zawierają oba te pola w opisie naszych metadanych.

Jak widzimy model najprawdopodobniej użył wskazówki zawartej w opisie danej kolumny. Nazwa kolumny to “duration_minutes”, a nazwa opisu to “Time of Trip in minutes” co dość jasno precyzuje, że to właśnie tej konkretnej kolumny użyć powinniśmy do wyliczenia średniego czasu podróży w podziale na typ subskrybenta.

Potencjalny wniosek, który nasuwa się nam już na tym etapie, jest taki, że dokładność naszego asystenta będzie tym większa im lepszą robotę zrobią data stewardzi w naszej hurtowni danych odpowiedzialni za katalogowanie i opisywanie metadanych biznesowych. Chodzi tutaj głównie o sytuację, w której człowiek nie znający języka SQL oraz schematów naszych danych będzie chciał uzyskać odpowiedź na pytanie zadane przy pomocy języka biznesowego.

Sprowadźmy naszego kompana na głębsze wody…

Dla odmiany teraz popracuję z datasetem nie zawierającym opisów kolumn więc Duet Ai będzie zmuszony domyślać się o co mi chodzi tylko i wyłącznie na podstawie nazw kolumn.

Dla jeszcze większego utrudnienia nie wskażę mu konkretnej tabeli, z której powinien pobierać dane a odwołam go do tylko do datasetu.

Mój prompt wygląda następująco:

				
					# Using `primal-monument-358918.thelook_ecommerce`  calculate the
# total number of orders and total revenue  broken down by day of the order

Zauważcie, że staram się inicjować użytkownika biznesowego, nie podając mu ani tabel ani kolumn, na podstawie, których te dane powinien wyliczyć.

Duet Ai daje mi trzy, nie różniąco się od siebie rekomendacje. Jak się jednak mogłem domyślić nie są one w pełni poprawne, choć przyznać muszę, że i tak jestem miło zaskoczony jego logiką rozumowania.

Najbliższe prawdy zapytanie wygląda następująco:

				
					SELECT
  DATE(_PARTITIONTIME) AS date,
  COUNT(*) AS num_orders,
  SUM(sale_price) AS total_revenue
FROM
  `primal-monument-358918.thelook_ecommerce.order_items`
GROUP BY
  date

Zapytanie zawiera dwa znaczące błędy. Po pierwsze Tabela nie jest partycjonowana po polu daty więc zwraca błąd Unrecognized name: _PARTITIONTIME at [4:8], po drugie count(*) z tabeli order_items policzy nam wszystkie zamówione przedmioty a nie zamówienia. Przychód policzył najbardziej poprawnie.

Nie jestem jednak zły na mojego asystenta. Wręcz przeciwnie przybijam mu wysoką pionę i dziękuję, że w niespełna jedną minutę nie znając zawartości tabel i danych pomógł mi zlokalizować nie tylko tabelę, w której znajdują się interesujące mnie dane ale i stworzył poprawną składnię zapytania, którą mi pozostaje tylko lekko edytować aby otrzymać zadowalający mnie rezultat.

Wniosek z tego taki, że na przyszłość zadając mu pytanie do niechlujnie opisanej tabeli trzeba być bardziej precyzyjnym.

Dialog Idealny… nie istnieje

Na sam koniec poszedłem po rozum do głowy, przemyślałem moje błędy i postanowiłem wrócić z lepiej zdefiniowaną prośbą do mojego asystenta próbując być tak konkretnym jak to tylko możliwe podczas zlecania mu danego zadania.

Moim celem było stworzenie raportu podsumowującego liczbę produktów zamówionych oraz ich wartość sprzedaży w podziale na dzień, nazwę produktu, numer zamówienia, imię oraz adres email naszego użytkownika.

Finalnie mój prompt wyglądał jak poniżej:

				
					# Using `primal-monument-358918.thelook_ecommerce.orders` and `primal-monument-358918.thelook_ecommerce.order_items` and `primal-monument-358918.thelook_ecommerce.products` and #`primal-monument-358918.thelook_ecommerce.users`,
# create following table: Dimensions: Day, Product Name,Order ID, Users Name and Surname, User Email, Metrics : Count of Products ordered, Revenue Of Products ordered
# For Day use created_at field from `primal-monument-358918.thelook_ecommerce.order_items` Table,
# For Order ID use order_id field from `primal-monument-358918.thelook_ecommerce.order_items` Table,  
# For Product Name use name field FROM `primal-monument-358918.thelook_ecommerce.products` Table
# For User Name use first_name field FROM `primal-monument-358918.thelook_ecommerce.users` Table,
# For User Email use email field FROM `primal-monument-358918.thelook_ecommerce.users` Table,
# For Count of Products Ordered use Product_Id FROM `primal-monument-358918.thelook_ecommerce.order_items` Table,
# For Revenue use Product_Id FROM `primal-monument-358918.thelook_ecommerce.order_items` Table

Jak widzicie prompt z języka biznesowego został napisany nieco bardziej technicznie przekazując mu pełną listę tabel, z których powinien skorzystać oraz pola, na podstawie których powinien wyliczyć interesujący nas rezultat.

Mój kompan dość szybko zwrócił mi następujące zapytanie:

				
					SELECT 

DATE(T1.created_at),     
T2.NAME,     
T3.FIRST_NAME,     
T3.LAST_NAME,     
T3.EMAIL,     
CAST(count(*) as BIGNUMERIC),     
sum(T1.SALE_PRICE) 
  
FROM     `primal-monument-358918.thelook_ecommerce.order_items` AS T1     
INNER JOIN 
`primal-monument-358918.thelook_ecommerce.products` AS T2 
ON T1.PRODUCT_ID = T2.ID     
INNER JOIN 
`primal-monument-358918.thelook_ecommerce.users` AS T3 
ON T1.USER_ID = T3.ID  

GROUP BY 1, 2, 3, 4, 5

A jego egzekucja zwróciła następującą tabelę:

Świetna robota asystencie!

Co prawda, zjadłeś po drodze Order_ID, o które również Cię poprosiłem, ale nie mam Ci tego za złe bo dopiero się uczysz, a błądzić to nie tylko rzecz ludzka ale i robociarska.

Pierwsze wnioski

Duet AI nie jest pierwszym narzędziem na rynku, pomagającym generować nam zapytania SQL.

Podobny rezultat mogliśmy już wcześniej uzyskać przy pomocy Barda czy ChatGPT. Subtelna aczkolwiek zasadnicza różnica jest taka, że Duet AI ma bezpośredni dostęp do naszych projektów, zbiorów danych, i tabel co pozwala zaoszczędzić wiele czasu na przekazywanie schematów tabel w innych programach typu Generative AI.

Dodatkowo, zakładając poprawne opisy w naszych tabelach może okazać się świetnym narzędziem w przypadku gdy pracujemy na zupełnie nowym zbiorze danych zawierającym wiele tabel bez odpowiedniej dokumentacji. Nawet jeśli za pierwszym podejściem nie napisze naszego zapytania w pełni poprawnie może znacznie nam ułatwić analizę schematu naszych danych.

Wydaje się, że największym wyzwaniem jest inżynieria naszego prompta. Google na chwilę obecną nie pokazuje jak w idealnym świecie powinien on wyglądać co pozostawia duże pole do eksperymentów. Osobiście, mnie to nie dziwi bo sam Sundar Pichai przyznał w wywiadzie dla FOX News, że nie do końca wiedzą jak działa ich AI 😉

Dla mnie najważniejsze jest to, że w ogóle działa.
Nie będę ukrywał, nie Cierpię pisać zapytań SQL. Od dawna czekałem aż będę mógł tworzyć gotowe widoki pisząc lub idealnie, mówiąc do maszyny, która zrobi to za mnie tak abym ja mógł się skupić na analizie, wizualizacji i wyciąganiu wniosków z moich danych biznesowych.

Arkady Zagdan

Analityk z 15 letnim doświadczeniem w branżach usługowych, e-commerce oraz SaaS. W Bigglo odpowiedzialny za strategię i wizję produktów typu Business Intelligence.