Trzecia edycja Supervision Hack organizowanego przez Komisję Nadzoru Finansowego to Warszawskie 24-godzinne kodowanie rozwiązań opartych o Sztuczną Inteligencję. W poprzedniej edycji udało nam się zdobyć 2 miejsce w wyzwaniu FakeJobsHunter, dlatego też byliśmy bardzo zmotywowani jadąc na miejsce w sobotni poranek. Nasz pięcioosobowy zespół liczył na którekolwiek miejsce podium – taki był główny cel.
W skład zespołu weszli:
Jacek Jackowski (President – Leadership) 
Adrian Kordas (VP – Lead Data Scientist)
Milena Kustroń (Data Science, Analiza Sentymentu, praca nad wymaganiami)
Filip Dzięcioł (VP – Streamlit Dev + Wsparcie Zespołu)
Jakub Melzacki (Python Dev, Webscrapping)
Opis Wyzwania
Do wyboru były 2 zadania:
- Depo Predator – zadanie polegające na wykrywaniu problemów z płynnością dowolnego banku na bazie informacji zawartych na stronach instytucji.
- SFCRacker – Raport o wypłacalności i kondycji finansowej instytucji ubezpieczeniowych, czyli wykrywanie niepoprawnych i niespójnych informacji w raportach instytucji ubezpieczeniowych.
W początkowej fazie SupervisionHack rozważaliśmy dwa wyzwania: zaawansowaną analizę szeregów czasowych i głęboką pracę z złożonymi danymi. Chociaż pierwsza opcja była technologicznie intrygująca, wybraliśmy drugie wyzwanie, które wydawało się równie zaawansowaną propozycją, lecz bliższą naszym zainteresowaniom. To wyzwanie, choć skomplikowane, umożliwiło nam pełne wykorzystanie naszej kreatywności i umiejętności tworzenia wartościowych wniosków z pozornie chaotycznych informacji, co pozwoliło na stworzenie narzędzia o szerokim zastosowaniu.
Nasze podejście
Rano w sobotę wzięliśmy kawę, bardzo dużo puszek coli zero i rozpoczęliśmy analizę wyzwania nr 2 – SF Cracker. Podział w zespole był dosyć prosty – Jacek jako Lider/PM, Adrian i Milena od Data Science oraz Filip z Jakubem ze strony czystego Pythona, i zaczytywania danych do aplikacji.
Pierwsza kwestia to rozpisanie wymagań. Była to bardzo ciężka praca, której podjęli się Jacek oraz Milena (która swoją drogą była głównym gościem u mentorów rozwiązania 🙂) i zrobili świetną robotę biorąc pod uwagę na ich nieprecyzyjność.
Sprawdziliśmy czego potrzebujemy:
- Problem Klienta – pobieranie danych ze stron instytucji – webscrapping
- Wydobywanie prostych metryk dotyczących jakości dokumentów – ich samych, ale też w porównaniu między instytucjami oraz latami – przetwarzanie plików PDF na prostsze struktury, tj. pliki CSV, tabele, opisy, ujednolicanie plików pdf, aby nasze rozwiązanie było uniwersalne – zabawka Adriana na 24 godziny, ostatecznie zdziałał cuda 🙂
- Wydobywanie dodatkowych metryk z dokumentów, tj. analiza sentymentu w opiniach biegłych, czy proste metryki spójności i jakości pobranych PDFów.
- Zgrabna aplikacja dla użytkownika, która nadzoruje cały przepływ danych, ich aktualizacje przez użytkownika oraz wizualizacje.
Pierwsza dyskusja – Frontend na JS/React, czy może prościej Streamlit? Zdecydowaliśmy się na Streamlit, aby przypadkiem nie wywołać zjawiska wąskiego gardła dla projektu, gdyby coś nie wypaliło,, ponieważ tylko Jakub dysponował wystarczającymi umiejętnościami w dziedzinie frontendu.
I, co ciekawe, to właściwie tyle, ponieważ reszta łatwo odnalazła się w swoich zakresach specjalizacji.
Produkt
Pierwszą częścią rozwiązania to webscrapper pobierający PDFy, które następnie były przetwarzane lwią część procesowania ze strony AI – bibliotekę SpaCy oraz model BERT (analiza sentymentu).
Ostatecznie całość była zrzucana do plików CSV, któe można było wyświetlić w aplikacji Streamlit, która pozwalała na sprawdzanie i edycję informacji o instytucjach, wgrywanie oraz pobieranie plików (webscrapper), a także analizę końcowych danych.
Ze względu na wiele struktur danych całość była trzymana w lokalnym systemie plików, jednak zdecydowana rekomendacja byłaby w stronę obiektowych baz danych, tj. Azure Blob Storage.
Całe przeprocesowanie pojedynczego pliku PDF zajmowało do kilkunastu sekund, a więc w przypadku pobrania kilkudziesięciu raportów i ich opinii mogłoby to zająć dobrą przerwę kawową 🙂 Aplikacja była gotowa do przeglądu przez Jury, mając w głowie usprawnienia na kilka takich 24-godzinnych sesji.
Wyzwania i Problemy
Bezbłędnie zidentyfikowaliśmy jedno wiecznie powtarzające się wyzwanie w AI: jakość danych.
Dokumenty miały różne nazwy, różne formaty – PDF, ZIP z PDFami, a nawet PDF z PDFami 😀, miały kompletnie nieustandaryzowane struktury oraz sposoby opisów tych samych informacji i faktycznie analiza tego przez człowieka musi być bardzo ciężki wyzwaniem.
Drugą rzeczą, z którą mieliśmy problem to zrozumienie wymagań. Trzeba przyznać, że były dość życiowe, czyli niejasne i bez konkretnych metryk mówiących o tym jak sprawdzić, czy jest ono spełnione. Z drugiej strony dawało to duże możliwości interpretacji, dodawania własnych pomysłów, oraz pokazania się mentorom pod kątem pytań, o co świetnie zadbała Milena.
Ostatecznie standardowe problemy programistyczne, z wydajnością i jakością AI, a także zespołowe pod kątem komunikacji. Nie pierwszy nie ostatni raz, ale ważne, że całość udało się dowieźć i świetnie zaprezentować (Jacek jak zwykle na propsie).
Wnioski
Nasz produkt, jak i wszystkie pozostałe to 24 godziny wielu prób i błędów, rozwiązywania prawdziwych wyzwań. Mamy nadzieję, że nie tylko aplikacje, ale przede wszystkim pomysły i rekomendacje zostaną wzięte pod uwagę przez KNF, aby usprawnić pracę analityków, dać im trochę wytchnienia oraz zwiększyć jakość dokumentów udostępnianych przez organizacje.
Zakończenie
Cel minimum to wejście do finału, po prezentacji wszystkich rozwiązań byliśmy niemal pewni podium, a może nawet zwycięstwa. Ostatecznie udało nam się zająć 2 miejsce, z którego jesteśmy bardzo zadowoleni, a informacja zwrotna od jury była taka, że powstały produkt jest świetny i różnica między 1 a 2 miejscem była bardzo niewielka.
Świetne wydarzenie i czekamy na kolejną edycję, gdzie liczymy na kolejne podium!
