O wydarzeniu
Była to już dziewiąta edycja HackYeah, która trwała przez dwa dni. Organizatorzy we współpracy z licznymi partnerami takimi jak Ministerstwo Finansów, jednostki samorządów terytorialnych czy Komisja Nadzoru Finansowego (z którymi mieliśmy okazję już wcześniej współpracować przy SuperVision_Hack 😉 ) przygotowali dla uczestników aż 19 wyzwań z dziedziny finansów, cyberbezpieczeństwa czy edukacji. Wszystkie rozwiązania, które wyróżniły się spośród innych, miały szansę na praktyczne zastosowanie w rzeczywistym świecie. Wizja tego, że nasze rozwiązanie mogłoby się przydać i ujrzeć światło dzienne była niezwykle motywująca.
Hackathon rozpoczął się oficjalnym otwarciem, na którym wystąpili Tomasz Rożek oraz Mateusz Chrobok. Od samego początku uczestnicy mogli cieszyć się świetnie zorganizowanym wydarzeniem. Zapewniono ciepłe posiłki, napoje oraz strefę chillout, co znacznie pomogło uczestnikom w realizacji swoich projektów. Oczywiście nie mogło zabraknąć pizzy, która jest niemal stałym elementem każdego wydarzenia programistycznego. Na arenie byli również wystawcy reprezentujący firmy, z którymi można było rozmawiać na temat potencjalnych ofert pracy oraz otrzymać od nich ekskluzywne upominki dla uczestników.
Wyzwanie „#Talk To Your Data”
W skład naszego zespołu wchodzili Jacek Jackowski, Filip Dzięcioł, Adrian Kordas, Igor Winek oraz Patryk Owczarz – zaprzyjaźniony z Kołem programista, architekt oprogramowania i nie tylko! Spośród wszystkich wyzwań najbardziej zainteresował nas konkurs „Talk To Your Data”, którego organizatorem było Ministerstwo Finansów oraz Krajowa Administracja Skarbowa. Może dlatego, że nazwa była bardzo chwytliwa, a temat był bezpośrednio związany z AI, szybko zdecydowaliśmy zabrać się do pracy. Celem projektu było stworzenie narzędzia umożliwiającego generowanie zapytań bazodanowych na podstawie dostarczonych schematów baz danych. Brzmi to stosunkowo łatwo, lecz esencją tego wyzwania było przetwarzanie jak najbardziej precyzyjnych zapytań tworzonych na podstawie naturalnego języka, wpisanego przez urzędników nie znających dialektu SQL’a. Organizatorzy wyzwania dostarczyli szczegółowe instrukcje dotyczące wyglądu rozwiązania oraz zestaw zapytań do bazy danych w celu przetestowania naszej propozycji. Takie rozwiązanie miało potencjał poprawienia efektywności pracy urzędników skarbowych oraz zwiększenia ich wydajności. Dzięki odpowiednio wytrenowanemu modelowi NLP pracownicy urzędów nie musieliby prosić o tego typu dane „bazodanowców” – a kto by chciał z nimi gadać (pozdrawiamy Filipa ];->)
On-Prem Or Die
Bardzo istotnym wymaganiem w naszym zadaniu było to, aby rozwiązanie było wykonane w modelu On-Premise. To jednak z perspektywy dużych, strategicznych podmiotów na rynku (w tym administracyjnych), chcących skorzystać z tego typu rozwiązania, było dość trafnym życzeniem – istotnym jest, aby dane polskich podatników nie trafiały do czarnej skrzynki gdzieś w chmurze. Mimo iż przetwarzanie języka naturalnego (NLP) nie było przedmiotem naszego wcześniejszego zainteresowania, skorzystaliśmy z dobrodziejstw napojów energetycznych i podjęliśmy rękawice…
Podział Zadań i Struktura Aplikacji
Nasza praca rozpoczęła się od znalezienia odpowiedniego podejścia do zadania oraz zrozumienia jego istoty. Stwierdziliśmy, że najlepszym podejściem będzie wykorzystanie gotowego modelu językowego, przekazanie mu wyekstrahowanej struktury bazy danych oraz w szerokim ujęciu spreparowanie go, tak aby generował zapytania w języku SQL na podstawie podanego przez nas uproszczonego schematu bazy danych. Jeszcze przed udostępnieniem pełnych treści wyzwań, Patryk i Filip stworzyli nasze środowisko pracy w postaci repozytoriów na każdy filar naszego projektu (model, backend oraz frontend aplikacji) wraz z Dockerowo-Azurowym środowiskiem. Strukturą aplikacji webowej, będącej interfejsem do komunikacji człowieka z naszym modelem w głównej mierze zajął się Patryk. Przygotował on stronę internetową, całe środowisko, które uruchamiało się po prostu za jednym kliknięciem pliku wsadowego, jak również[MK1] interfejs do komunikacji jego aplikacji webowej z częścią chłopaków od NLP. Wspomniana aplikacja webowa zawierała dwa pola tekstowe, z których jedno przyjmowało tekst w języku naturalnym, a drugie zwracało zapytanie SQL. Obok znajdował się przycisk, którego kliknięcie skutkowało odpytaniem bazy danych wynikowym zapytaniem i wyświetleniem wyniku w tabeli po prawej stronie ekranu. Dodatkowo aplikacja ta zawierała „admin panel”, w którym można było wysłać schemat bazy danych do części MLowej. Kwestiami dokumentacji DevOps zajął się Filip. Jak każdy z nas był oczywiście człowiekiem orkiestrą, podobnie jak Jacek po świeżo wykonanej artroskopii, w temblaku i z piękną, pomarańczową od substancji antyseptycznej ręce, zajął się wymaganiami technicznymi oraz rozpisaniem zadań do kanbana. Jak mógłby powiedzieć ktoś nieuprzejmy – przecież aby wskazywać palcem wystarczy jedna ręka J. Do tego dbał o wysokie morale naszej zgrai pilnując, aby nie zabrakło ciastek, kawy i dobrego humoru. Igor i Adrian jako główne zadanie dostali samo mięso – reaserch dotyczący konwersji tekstu naturalnego na język SQL i prace nad modelem. W pierwszej kolejności przeszukiwali dostępne modele LLM, które mogłyby efektywnie przekształcać język naturalny na oczekiwany rezultat. Wysoką barierą, którą musieliśmy przeskoczyć była złożoność modeli NLP, które uruchamialiśmy na swoich laptopach. Bezcennym obrazem było obserwować Adriana, speca DSC od machine learningu, jednak bardziej w obszarze computer vision. Jego wypisane na twarzy zadowolenie z demokratycznych i pragmatycznych wyborów wyzwania czy też podziału ról było warte pokonania dystansu do Krakowa już wtedy 😀
Ostatecznie udało się znaleźć całkiem wydajny, na odpowiedniej licencji i lekki model bazujący na architekturze LLaMa2, który spełnił nasze oczekiwania, jeśli chodzi o zwracane dane i korzystanie z podanego kontekstu. Adrian przygotował backend części ML’owej, przygotowując końcówki REST API, aby zestawić komunikację między platformą Patryka, a modelem naszych speców od Data Science. Ta część została napisana we Flasku i obsługiwała również zmianę rozważanej struktury bazy danych – dostosowując przy tym model do zmiany. Igor znalazł komercyjne rozwiązanie, które było wyspecjalizowane w konwersji języka naturalnego na SQL. Ten też został dodany do naszego rozwiązania w intencji wskazania możliwych alternatyw. Następnie obaj próbowali dostroić model zmieniając jego hiperparametry, aby ten zwracał jeszcze lepsze wyniki. Adrian dopracowywał część ML’ową, aby dostarczyć możliwość komunikacji z modelem przy utrzymywaniu kontekstu rozmowy w pamięci.
Na końcu, dosłownie 15 minut przed zakończeniem wyzwania (a mieliśmy przed sobą ogromny zegar wskazujący ilość pozostałego czasu) Adrian i Igor przeprowadzili testy na podanych przez organizatorów zapytaniach i ocenili jakość zwracanych modeli. Model On-Prem został przetestowany na dwa sposoby – przy zachowywaniu kontekstu i przy resetowaniu kontekstu przy każdym zapytaniu. Wyniki okazały się być lepsze przy zachowywaniu kontekstu niż bez jego zachowywania, a rozwiązanie komercyjne (cloudowe) szybsze i nieco lepsze. Byliśmy zadowoleni z wyników. Miało być tak pięknie!
Co zostało wspomniane, nie byliśmy przygotowani na obszar NLP – nie wyposażyliśmy się wcześniej w modele, które bądź co bądź potrafią zajmować kilkadziesiąt gigabajtów pamięci. Mimo dostępnej sieci internetowej obciążenie było bardzo duże przez co prace nad testowaniem modeli i jego finalnym wyborem mocno się przedłużały. Dodatkowo, mieliśmy mały problem wynikający z zastosowania Macbooka – Jacek nie posiadał nawet złącza Ethernet, a przy blisko 5000 osób na stadionie, Wi-Fi nie bywa łaskawe.
Kilka godzin przed zakończeniem wyzwania pojawiły się małe problemy dotyczące środowiska Dockerowego. Patryk dzielnie walczył z problemem, chociaż waga problemu rosła proporcjonalnie do upływu czasu. Dosłownie chwilę przed zakończeniem wyzwania podniósł ręce w górę w geście zwycięstwa i wszystko zaczęło działać. Nie odszedł ani na moment od komputera, aby dowieźć temat do końca. Chapeau bas!
Przez zastosowanie modelu NLP, który składał się blisko z 7 miliardów parametrów, uruchomienie go i oczekiwanie na wyniki zajmowało od 3 do 7 minut w zależności od długości zapytania i samego podanego kontekstu.
Wyniki oraz Zakończenie Wydarzenia
Cały zespół pracował nad naszym zadaniem z krótkimi przerwami aż do ostatnich sekund. Po upływie 24 godzin naszego programistycznego maratonu wszyscy byli zadowoleni z pracy jaką włożyliśmy w projekt. Teraz pozostało czekać na ostateczną decyzję sędziów, którzy wybierali projekty do wielkiego finału. W tym czasie uczestnicy mieli okazję odpocząć. Patryk i Adrian, którzy nie zmrużyli oka nawet na minutę zyskali drugi oddech i „ożyli”, gdy pojawiła się euforia spowodowana zakończeniem projektu. Po kilku godzinach oczekiwania jury wróciło z werdyktem i tym razem nasz zespół nie dostał się do finału, aby przedstawić rozwiązanie. Nie zawsze się wygrywa, chociaż warto zauważyć, że nie wiemy z jakimi rozwiązaniami przegraliśmy. Na HackYeah wyłącznie osoby zaproszone do finału miały okazje poznać rozwiązania innych zespołów. Z naszych doświadczeń jest to rzadka praktyka i odbiera wiele z tego co hackathon może zaoferować. Nie ma lepszej nauki niż nauka na błędach, a to można wyciągnąć właśnie z prezentacji wyników najlepszych rozwiązań. Całe wydarzenie oraz czas spędzony na wydarzeniu na szczęście przyniósł wiele korzyści rozwojowych dla każdego z uczestników, jest to zawsze możliwość do odnalezienia się w nieco innych realiach, więc nie wykluczamy wielkiego coming-back w przyszłym roku!
