Piotr Rybak i Łukasz Kobyliński o konkursach w Data Science (PolEval i KLEJ Benchmark)

Cześć, w dzisiejszym odcinku podcastu Stacja IT chciałbym porozmawiać o różnego rodzaju konkursach, z którymi mamy do czynienia w IT, a dokładniej: w obszarze data science czy uczenia maszynowego. Pewnie wielu z Was zna taki konkurs jak Kaggle, w którym różnego rodzaju zespoły, czy to naukowe, czy pochodzące z jakichś firm, mogą zgłaszać swoje rozwiązania zadań na problemy zgłaszane z kolei przez inne firmy – problemy typu klasyfikacja dokumentów czy przewidywanie pogody. W tym konkursie, w którym są ustalone zasady porównywania takich zgłoszeń, uczestniczy wiele ośrodków i na podstawie listy rankingowej wybierane są te najlepsze, czyli zwycięzcy.

Takie konkursy mają bardzo wiele zadań. Z jednej strony propagują wiedzę o uczeniu maszynowym, o data science, skłaniają uczestników do tego, żeby stale szukali rozwiązań. Uczestnicy tych konkursów faktycznie przyczyniają się do rozwiązywania trudnych problemów i ich rozwiązania mogą być wykorzystane w praktyce. Służą to też pewnie temu, żeby łączyć ze sobą zdolnych adeptów sztuki data science z potencjalnymi pracodawcami, bo zawsze można się pochwalić tym, że było się zwycięzcą lub chociażby wysoko w rankingu takiego konkursu, co zdecydowanie podwyższa atrakcyjność na rynku pracy.

Ale dzisiaj chciałbym porozmawiać o konkursach, z którymi mamy do czynienia na naszym polskim podwórku, konkursach, w które – po pierwsze – sam jestem zaangażowany, a po drugie – w które zaangażowany jest nasz dzisiejszy gość, z którym rozmowa odbędzie się w drugiej części podcastu.

Pierwszy z tych konkursów to PolEval, który dotyczy przetwarzania języka polskiego i który troszkę na wzór Kaggle stawia przed zespołami uczestniczącymi w konkursie zadania związane z przetwarzaniem języka polskiego. W związku z przetwarzaniem języka polskiego są różnego rodzaju zadania, czasem chodzi nam o klasyfikacje dokumentów, czasem o analizę wydźwięku, czasem o rozpoznawanie jakichś jednostek nazewniczych – nazw własnych w dokumentach, tak żeby można było stwierdzić, czy w danym miejscu tego tekstu pojawia się nazwa ulicy, osoby czy firmy. I te zadania to takie typowe wyzwania, z którymi mamy do czynienia w przypadku przetwarzania języka naturalnego, które później w praktycznych zastosowaniach też są potrzebne.

PolEval to konkurs, o którym myśleliśmy w Instytucie Podstaw Informatyki PAN jako o miejscu, w którym mogą rywalizować różnego rodzaju metody związane z rozwiazywaniem tego typu zadań, ale które łatwo będzie porównywać. Czyli właśnie kluczowy jest ten aspekt znany z Kaggle, co oznacza, że te zadania są bardzo dobrze opracowane, wiadomo, jaka jest informacja wejściowa i oczekiwana informacja wyjściowa, jakie jest kryterium ewaluacji, jakie są zasady rangowania poszczególnych metod, tak żeby wszyscy mieli równe szanse i żeby można było obiektywnie oceniać poszczególne metody.

I motywacja do tego, żeby zrobić taki konkurs dla języka polskiego, była wieloraka. Po pierwsze, język polski wydaje się obiektywnie trudniejszy w przetwarzaniu automatycznym niż np. angielski. O tym mówiłem na różnego rodzaju konferencjach czy meetupach. Chciałbym tu tylko podkreślić, że głównym problemem w przetwarzaniu języka polskiego jest niejednoznaczność na wielu poziomach. W języku polskim, który jest przykładem języka fleksyjnego, a więc ma końcówki fleksyjne do poszczególnych słów, ta niejednoznaczność jest jeszcze większa niż w innych językach, niejednoznaczność związana z odmianą, chociażby przez przypadki, ze znaczeniem słów. I jeśli te niejednoznaczności się kumulują, to zyskujemy dużo większe spektrum możliwych rozwiązań, które te metody automatyczne muszą analizować, niż w przypadku np. języka angielskiego. Takim bezpośrednim przykładem tej złożoności jest znakowanie morfosyntaktyczne – to zadanie, w którym staramy się przypisać coś w rodzaju znanych nam ze szkoły klas gramatycznych do poszczególnych słów. Znamy ze szkoły czasowniki, rzeczowniki i przymiotniki. To w takim bardzo podstawowym podejściu jest zadaniem dosyć prostym, natomiast jeśli przeanalizujemy całą złożoność języka, to okaże się, że takich możliwych znaczników morfosyntaktycznych, które opisują zachowanie słów w języku polskim, jest teoretycznie ponad dwa tysiące. Mówimy tu nie tylko o klasach gramatycznych, ale też ich możliwych odmianach, jak np. przypadek, rodzaj czy osoba. I te wszystkie możliwości przemnożone przez siebie dają właśnie teoretyczne dwa tysiące możliwości, podczas gdy dla języka angielskiego jest ich między 40 a 200. Czyli mamy albo jeden, albo dwa rzędy wielkości; trudniejszy problem w przypadku języka polskiego niż angielskiego pokazuje tę złożoność obliczeniową.

Język polski jest, po pierwsze, trudniejszy w przetwarzaniu i dokładność metod, które były dostępne kilka lat temu – i nadal są dla współczesnych metod przetwarzania języka polskiego – zwykle dają gorsze efekty niż w przypadku przetwarzania języka angielskiego. To była nasza pierwsza obserwacja bieżącej sytuacji; mimo że rozwój NLP trwa od wielu lat, ma on miejsce w Polsce, prace dalej są kontynuowane. Po drugie, dane treningowe, dostępne dla języka polskiego, są mniej liczne. Po prostu mniej zostało ich zgromadzonych, mniej ma otwarte licencje, z których można korzystać, jest też mniej użytkowników języka polskiego, więc mniej tych danych w ogóle produkujemy, mniej ich jest dostępnych w internecie w porównaniu z językiem angielskim czy chińskim, czy nawet hiszpańskim. A jak wiadomo, współczesne metody przetwarzania języka naturalnego opierają się na uczeniu maszynowym, tak jak i w innych zadaniach, z którymi mamy do czynienia w tych obszarach, jak np. analiza obrazu czy dźwięku, więc najczęściej korzystamy z uczenia maszynowego, a zatem potrzebujemy dobrych danych treningowych i to w dużych ilościach, a tych też wciąż nie mamy wystarczająco dużo.

Badaczy zajmujących się przetwarzaniem języka polskiego jest niewielu. Wynika to z tego, że mamy mniej użytkowników tego języka oraz mniejsze są nakłady na badania naukowe, dotychczas mniejsze też było zainteresowanie komercyjne firm badaniami rozwojowymi w tym obszarze. I wreszcie nie mamy wystarczającej wymiany wiedzy pomiędzy badaczami a biznesem, a także między samymi badaczami z różnych ośrodków. Dostrzegliśmy problemy związane z trudnością przetwarzania języka, z trudnością w dostępności danych do uczenia maszynowego, niewielką liczbę badaczy, którzy się tym zajmują, i tu problemy z wymianą informacji pomiędzy nimi. Stąd postanowiliśmy zrobić taki konkurs jak Kaggle dla języka polskiego, który odpowiada na te problemy w ten sposób, że motywuje do pracy nad językiem polskim, nad metodami jego przetwarzania, ponieważ mamy tu formę konkursu, który z jednej strony przyznaje nagrody zwycięzcom, a z drugiej, niezależnie od tych nagród, wszyscy uczestnicy, a w szczególności zwycięzcy mogą liczyć na prestiż i na możliwość prezentowania swojego rozwiązania na konferencji wieńczącej konkurs PolEval. Mamy zatem narzędzie promocji samego zagadnienia i tego, że warto nad tymi zagadnieniami pracować. Poza tym przygotowanie tych zadań, w których uczestniczą poszczególne zespoły, jako pewien efekt uboczny powoduje przygotowanie zbiorów treningowych i testowych, na których te metody muszą być uczone i ewaluowane. A zatem przy okazji przygotowywania zadań powstają nowe dane dla języka polskiego, które, jak już powiedzieliśmy, do tej pory były trudno dostępne.

Odpowiadamy też na problem braku wymiany wiedzy i komunikacji między poszczególnymi zespołami, ponieważ tutaj jakby wszem i wobec ogłaszamy, jakie zespoły nad tymi problemami pracują, jakie efekty osiągnęły. I w ten sposób zachęcamy do wzajemnego komunikowania się i uzyskiwania informacji, co się sprawdziło w danym przypadku, a co nie. Do tego konferencja, o której wspomniałem, AI NLP Day, która jest takim „świętem”, w trakcie którego wszyscy uczestnicy mogą zaprezentować rozwiązania, w bezpośredni sposób powoduje, że uczestnicy spotykają się i rozmawiają w kuluarach czy właśnie słuchają wzajemnie swoich prezentacji.

Podsumowując, mamy konkurs z nagrodami wzorowany na Kaggle, w ramach którego wypracowujemy ustalone procedury ewaluacji systemów rozwiązujących poszczególne zadania w NLP. Czyli mamy ściśle określone zadania z procedurami ewaluacyjnymi, tak żeby te porównania były obiektywne. Wytwarzamy anotowane zbiory danych, które mogą być wykorzystane do uczenia i ewaluacji systemów, więc znowu tutaj dokładamy się do tego, żeby te dane były w ogóle dostępne dla języka polskiego, a po drugie – żeby wszyscy uczestnicy korzystali z tych samych danych i żeby były one porównywalne. Dążymy do tego, żeby systemy były maksymalnie obiektywnie porównywalne, czyli żeby były porównywane wg tych samych schematów i na tych samych danych. W zależności od typu zadania dopuszcza się dane zewnętrzne. Zbliżamy również do siebie środowiska badaczy i środowiska naukowe. Chcemy, żeby dzielili się wiedzą. Przy okazji popularyzujemy zagadnienia NLP w kontekście języka polskiego.

Konkurs powstał w 2017 r. Mieliśmy wtedy tylko dwa zadania związane z przetwarzaniem języka polskiego: było to znakowanie morfosyntaktyczne i analiza dźwięku, którą być może znacie pod angielską nazwą sentiment analysis. Czasami jest to tłumaczone jako analiza sentymentu, my tu preferujemy nomenklaturę pt. analiza wydźwięku. Chodzi nam o to, żeby określić, czy dana wypowiedź lub zdanie w zależności od sformułowania problemu niesie ze sobą wydźwięk pozytywny lub negatywny, co jest częste w recenzjach produktów.

Kiedy w 2017 r. mieliśmy te dwa zadania i otrzymaliśmy 16 zgłoszeń od dziewięciu różnych zespołów, wydawało nam się, że to sukces. Myśleliśmy, że nad językiem polskim tak naprawdę pracuje tyle zespołów, że na palcach jednej ręki się je policzy. Okazało się, że jest ich zdecydowanie więcej i przy minimalnej promocji konkursu od dziewięciu zespołów wpłynęło 16 zgłoszeń. I co najciekawsze, zgłoszenia, które wpłynęły na konkurs, faktycznie przebiły wszystkie istniejące do tej pory metody. Metoda, która wygrała, osiągnęła dokładność o ok. 5 punktów procentowych lepszą niż ta, która była znana do tej pory. Więc było to właśnie to bezpośrednie zrealizowanie celu, który sobie stawialiśmy, a więc zaangażowanie większej liczby zespołów w pracę nad tymi problemami, tak żeby spojrzeć na to z innej strony i rzeczywiście poprawić istniejący stan rzeczy w tych zadaniach.

W 2018 r. zorganizowaliśmy kolejną edycję PolEvalu. Znalazły się w niej takie zadania jak parsowanie zależnościowe, a więc rozkład gramatyczny zdania czy rozpoznawanie jednostek nazewniczych i modelowanie języka, gdzie otrzymaliśmy 24 zgłoszenia od 14 zespołów. Dokładność tych metod znów została poprawiona poprzez te zgłoszenia, więc był to kolejny udany rok. W kolejnym roku, w związku z rosnącym zainteresowaniem zespołów, które chciały ogłosić swoje zadania, mieliśmy tych zadań już sześć. Dotyczyły one normalizacji i rozpoznawania wrażeń temporalnych, lematyzacji nazw własnych i jednostek wielowyrazowych, łączenia nazw z ich definicjami, tłumaczenie maszynowe. Pojawiło się też rozpoznawanie głosu – mowy, a także rozpoznawanie mowy nienawiści w internecie, które przyciągnęło najwięcej zgłoszeń. Było bardzo na czasie. Wiele zespołów chciało spróbować w nim swoich sił. Obok tłumaczenia maszynowego czy rozpoznawania mowy stanowiło jedne z najbardziej praktycznych zadań; inne były bardziej elementami wykorzystywanymi w całościowych rozwiązaniach.

Na przestrzeni lat naprawdę wiele ośrodków wzięło udział w konkursie. Były to zarówno ośrodki naukowe, jak i firmy, co wszystkim dało korzyści, pomogło pokazać się w środowisku, że te i te zespoły nad tym językiem pracują, i znaleźć pole do współpracy. W szczególności pogłębiła się współpraca Instytutu Podstaw Informatyki z firmami, które miały tu zespoły NLP. Po tych konkursach wydane też zostały tzw. proceedingsy, czyli zbiory artykułów naukowych, które podsumowywały zgłoszenia na konkurs, w szczególności zwycięskich zespołów.

Wielkimi bohaterami PolEvalu są oczywiście twórcy zadań. Największą pracą, która musi być wykonana w poszczególnych latach, jest przygotowanie zadań. Na tę heroiczną pracę składa się przygotowanie koncepcji zadania, tego, co warto mierzyć, gdzie warto zbierać zgłoszenia rywalizujących zespołów, opisanie tych zadań, przygotowanie zbiorów treningowych i testowych, opracowanie metody ewaluacji, która będzie obiektywna i sprawiedliwa. Wielkim wyzwaniem jest tu dobre przygotowanie zadań. I w tym miejscu bardzo serdecznie dziękuję wszystkim osobom, które przygotowywały te zadania. Zapraszam też kolejnych śmiałków do zgłaszania swoich propozycji zadań lub chęci samodzielnego ich przygotowania.

W kolejnych latach planujemy rozbudowanie PolEvalu chociażby w ujęciu technicznym. Obecnie PolEval komunikuje się ze światem za pomocą statycznej strony, na której prezentowane są zadania i wyniki zgłoszeń, które są ewaluowane po zakończeniu konkursu. Natomiast chcemy doprowadzić do większej interakcji i do możliwości śledzenia przebiegu konkursu na żywo. Więc chcielibyśmy mieć tu bardziej interaktywną, automatycznie liczoną tablicę wyników, gdzie zgłoszenia byłyby przysyłane nieustannie przez cały rok, i na tej podstawie te wyniki byłyby aktualizowane. Planujemy też w szerszy i łatwiejszy sposób udostępnić wszystkie te zasoby, które powstają w kontekście PolEvalu, a więc metody czy dane, które przy okazji są anotowane, tak żeby większa liczba osób, zespołów mogła do nich dotrzeć.

W tym roku konkurs PolEval również się odbędzie. Zgłoszenia można przesyłać na przełomie lipca i sierpnia. Mamy w tym roku cztery tematy, które dotyczą poprawiania wyników metody rozpoznawania mowy, znakowania morfosyntaktycznego tekstów historycznych – też bardzo ciekawe zadanie, w którym trzeba zwrócić uwagę na czas powstania danego tekstu i na kwestie językowe. Mamy więc do czynienia z językiem polskim siedemnasto- czy osiemnastowiecznym, co jest też ciekawe chociażby, żeby zobaczyć, jak ten język wyglądał. I informacje o czasie powstania języka musimy uwzględnić w naszych metodach rozwiązujących ten problem. Mamy też zadanie związane z ujednoznacznieniem sensu słów i zadanie ekstrakcji informacji z dokumentów, gdzie musimy np. zidentyfikować osoby, które występują w raportach giełdowych, nazwy firm albo daty, które tam się pojawiają. Więc takie znowu bardziej praktyczne zadanie, z którym wiele firm być może się mierzy.

Zwieńczenie naszego konkursu to konferencja AI NLP Day, która odbędzie się pod koniec września. I tam oprócz prezentacji związanych z PolEvalem znajdą się też prezentacje dotyczące przetwarzania języka naturalnego, uczenia maszynowego czy analizy obrazów. Konferencja w tym roku będzie dwudniowa. Pierwszy dzień będzie prezentacyjny, a drugi – warsztatowy, podczas którego z prowadzącym można rozpocząć pracę w jakimś obszarze czy z osobą doświadczoną w danym temacie podjąć jakieś zagadnienie i od niej nauczyć się poszczególnych technik.

Bardzo serdecznie dziękuję wszystkim dotychczasowym uczestnikom tego konkursu, zespołom i osobom, które przygotowywały zadania. Zapraszam wszystkich do uczestnictwa w konkursie, który jak wspomniałem, nadal trwa, i jest możliwość dołączenia do tegorocznej edycji.

A teraz przejdźmy do rozmowy z Piotrem Rybakiem z Allegro, który wraz ze swoim zespołem przygotował coś zbliżonego do konkursu, o jakim mówiliśmy, natomiast bardziej w formie rankingu modeli językowych dla języka polskiego. Zapraszam do tej rozmowy.

Cześć, Piotr. Przedstaw się, proszę, naszym słuchaczom i powiedz kilka słów o sobie.

Cześć, Łukasz. Dzięki za zaproszenie. Nazywam się Piotr Rybak. Aktualnie jestem senior research engineerem w Allegro w zespole Machine Learning Research, w którym zajmuję się szeroko pojętym uczeniem maszynowym, a tak naprawdę głównie przetwarzaniem języka naturalnego. I tak naprawdę tym się zajmuję przez większość mojej kariery. Studiowałem matematykę, kognitywistykę, a potem pracowałem czy to jako analityk, czy jako machine learningowiec w wielu różnych firmach, głównie startupach. Budowałem różnego rodzaju produkty oparte o uczenie maszynowe.

Jak rozumiem, język naturalny najbardziej ci się spodobał ze wszystkich dziedzin.

Zdecydowanie tak. Już podczas studiowania matematyki moja praca dyplomowa dotyczyła przetwarzania języka naturalnego. I potem zawsze starałem się w tę stronę iść. Oczywiście nie tylko, często zajmowałem się innymi rzeczami, bo akurat takie były projekty do zrealizowania. Więc język naturalny zawsze gdzieś tam z tyłu głowy istniał i mnie kusił, czy to w kontekście poszukiwania nowej pracy, czy różnego rodzaju konkursów czy zainteresowań naukowych.

Jakie to były języki w twoim przypadku: język polski czy bardziej angielski?

Ponieważ mieszkam i pracuję w Polsce, to był to język polski, ale ponieważ angielski jest zdecydowanie dominujący w kontekście przetwarzania, to również język angielski. Chociaż zdarzyło mi się budować też rozwiązania dla innych języków. W jednej z poprzednich firm, w której pracowałem, 70% danych było po angielsku, ale mieliśmy także dużo danych po hiszpańsku, włosku i niemiecku. Były też ciekawe wyzwania, jak wykorzystać te dane wielojęzykowe, wybudować jeden model, który działa na wielu językach naraz. Było tu oczywiście wiele ciekawych wyzwań i problemów do rozwiązania, np. czy budować wiele osobnych modeli, czy tłumaczyć te dane na angielski automatycznie, czy budować jeden model, który radzi sobie ze wszystkimi językami.

Dzisiaj mówimy o konkursach w ramach data science czy uczenia maszynowego. I chciałem porozmawiać z tobą w szczególności o KLEJ-u, a dokładniej: KLEJ Benchmark. Jesteś współautorem publikacji na temat KLEJ Benchmark i samego benchmarku. Co to w zasadzie jest KLEJ Benchmark?

Zacznę od takiego wprowadzenia o przetwarzaniu języka naturalnego. W tej chwili zmienia się paradygmat tego, jak buduje się modele do przetwarzania języka. Do tej pory świat działał tak, że dostawaliśmy jakiś problem do rozwiązania i budowaliśmy model ściśle dostosowany do jego rozwiązania, np. gdy dotyczył analizy wydźwięku, to budowaliśmy model do analizy wydźwięku; gdy do parsowania, to model do parsowania. W tej chwili trochę korzystając z wiedzy z przetwarzania obrazu, w środowisku NLP została wykorzystywana idea transfer learningu. Czyli najpierw budujemy bardzo duży model, który po prostu zna język i go rozumie. Następnie ten bardzo duży model chcemy zastosować do rozwiązania konkretnego problemu, np. analizy wydźwięku, parsowania czy klasyfikacji tekstu. KLEJ Benchmark z naszego punktu widzenia to taki standardowy sposób do ewaluowania dużego modelu języka na bardzo wielu różnych zadaniach. KLEJ Benchmark składa się aktualnie z dziewięciu zadań, możliwie różnorodnych, możliwie z różnych dziedzin, rozwiązujący różne problemy. To, co chcemy zrobić, to wziąć ten duży model języka i sprawdzić, jak dobrze on sobie radzi, tak żeby móc porównać go z modelami stworzonymi przez inne osoby, firmy. Żeby to zrobić, musimy go potrenować do rozwiązywania tych dziewięciu tasków, zadań z KLEJ Benchmarku.

W jaki sposób te modele ogólne języka radzą sobie z tymi zadaniami w porównaniu z takimi specjalizowanymi modelami czy metodami? Czy to jest rzeczywiście tak, że tylko takie ogólne modele warto obecnie porównywać czy też mieliście takie porównania albo myślicie o tym, żeby zrobić to dla modeli dedykowanych dla konkretnego zadania?

W tej chwili sytuacja wygląda tak, że oczywiście to zależy. Jeżeli patrzymy na czystą skuteczność, jak model sobie radzi, jak mało popełnia błędów, to tak naprawdę te modele ogólne, dostosowane tylko do konkretnych zadań są właściwie bezkonkurencyjne. Ta cała masa wiedzy, która weszła do wytrenowania dużego, ogólnego modelu języka, tak bardzo przeważa wszystkie inne czynniki, że ten model po prostu radzi sobie świetnie i popełnia dużo mniej błędów niż jakiekolwiek inne modele przygotowane ściśle pod rozwiązywanie tego konkretnego modelu. Natomiast to niepełna historia, bo tak naprawdę nie zawsze opłaca się korzystać z tych dużych modeli, głównie z powodu ich wielkości. I jeżeli mamy czysto biznesowe wymagania, żeby ten model był dostatecznie szybki albo zajmował dostatecznie mało pamięci, żeby można go było łatwo serwować, to często okazuje się, że lepiej zbudować customowy model pod rozwiązanie konkretnego problemu, oczywiście on będzie trochę mniej skuteczny, ale wielokrotnie szybszy, a wdrożenie go i wytrenowanie stanie się wielokrotnie łatwiejsze i tańsze. Bardzo dużo zależy od tego, jakie mamy wymagania z jednej strony po stronie skuteczności, z drugiej – czasu predykcji czy czasu treningu samego modelu. A też często dużo problemów jest dosyć prostych, przykładowo: klasyfikacja tekstów, newsów, gdzie mamy duży fragment tekstu, i tak naprawdę większość analizy opiera się na wykryciu słów kluczowych. Tak naprawdę ten duży, ogólny model języka nie jest wcale wykorzystywany w pełni. Równie dobrze można użyć prostych metod opartych nawet o worki słów czy o zanurzenia słów, z tym radzimy sobie równie dobrze, a model jest dużo szybszy i dużo prostszy w używaniu.

Żeby przejść do motywacji, dzięki której przygotowaliście taki sposób porównania tych metod, to dla tych osób, które nie miały jeszcze do czynienia z takimi modelami czy ogólnie zajmują się przetwarzaniem języka naturalnego, podsumujmy, kiedy warto korzystać z takich dużych, dedykowanych modeli. Czy można zatem powiedzieć, że są gotowe modele językowe, zajmujące dużo pamięci, ale radzące sobie bardzo dobrze w wielu zadaniach i warto jest z nich korzystać wtedy, kiedy takich ograniczeń wydajnościowych nie mamy? Natomiast jeśli mamy zadania bardziej związane z urządzeniami przenośnymi czy czasu rzeczywistego, to wtedy pewnie skorzystamy z czegoś dedykowanego? Czy tak byś to też podsumował?

Dokładnie tak. Dodałbym tu jeszcze jeden czynnik, mianowicie często te nowe, ogólne modele z jednej strony mają lepszą skuteczność, ale często też dużo łatwiej jest ich użyć, bo dużo ludzi nad nimi pracuje, dbając, by one były łatwe do użycia w wielu różnych zastosowaniach. Więc tak naprawdę jest już dużo napisanego kodu, dużo bibliotek, które ułatwiają pracę z nimi, ale może się okazać, że tak naprawdę łatwiej jest użyć tego dużego, skomplikowanego modelu, tak czysto programistycznie, czysto jako użytkownik, bo ludzie już dużo czasu spędzili, żeby dane były łatwe do użycia. Ale jeżeli piszemy swój model od zera, to tak naprawdę zajmie nam to często więcej czasu.

Czy można by jakoś porównać to podejście od strony kwestii dostępnych danych treningowych? Jeśli mam jakieś zadanie, do którego chciałbym użyć jednego lub drugiego typu metody, to jakie kwestie różnicujące można tu znaleźć, kiedy tych danych potrzebuję więcej a kiedy mniej?

To bardzo słuszna uwaga. Zdecydowanie jeszcze jedną przewagą tych modeli ogólnych jest fakt, że nie wymagają aż tak dużo danych. Bezpośrednio wynika on z samego założenia, że my już dostarczamy model, który dobrze rozumie język, w związku z tym, żeby go tylko dostosować do rozwiązywania konkretnego zadania, nie potrzebujemy aż tak dużo tych dodatkowych danych treningowych. Bo my nie musimy nauczyć na podstawie tych danych rozumienia języka, tylko rozumienia tego jednego konkretnego problemu, rozwiązywania tego jednego zagadnienia. Natomiast jeżeli budujemy model od zera, to w dużo mniejszym stopniu wykorzystujemy tę wiedzę na temat rozumienia języka, pozyskaną wcześniej, bo często jej nie pozyskujemy w żaden sposób lub w stopniu minimalnym, np. wykorzystując zanurzenia słów. Więc jeśli budujemy model od zera, potrzebujemy tych danych wielokrotnie więcej, bo model na tych danych musi dodatkowo nauczyć się rozumieć język, a nie tylko rozwiązywać dane zagadnienie. Oczywiście dane w uczeniu maszynowym to najważniejsza rzecz i często najbardziej kosztowna do pozyskania. Czas treningu modeli czy czas inżynierów budujących te modele tak naprawdę w ostatecznym rozrachunku nie jest aż tak drogi, a przygotowanie zbiorów danych zaanotowanych jest tak naprawdę najdroższe, bo wymaga najwięcej pracy manualnej i zazwyczaj potrzebujemy tych danych bardzo dużo.

Czyli mamy te duże modele, wytrenowane już na dużych zbiorach danych, więc problem konieczności samodzielnego przygotowania tych danych częściowo nam odchodzi. Możemy zastosować te modele w różnych zadaniach i zastanawiamy się, który model wykorzystać. I jak rozumiem, tutaj wchodzicie wy z waszym benchmarkiem. Co nam pokazuje spojrzenie na ten benchmark i co porównuje? Jeśli mamy jakieś konkretne zadanie, to w jaki sposób mam odczytywać tę tabelę, żeby wiedzieć, z której metody skorzystać?

Tak naprawdę możemy spojrzeć na ten benchmark na dwa sposoby. Po pierwsze, jako taki ogólny ranking, jak dobrze poszczególne modele sobie radzą. Wtedy patrzymy na uśrednioną skuteczność danego modelu i w bardzo uproszczony sposób odczytujemy, że „ten model jest najlepszy”, „ten model zajął drugie miejsce”, „ten model zajął trzecie miejsce”, w związku z tym skorzystamy z modelu, który zajął pierwsze miejsce. To jest bardzo uproszczone podejście, które sprawdza się w sytuacjach konkursowych, natomiast nie w praktyce. W praktyce mamy rzeczywiście konkretne zadanie do rozwiązania, więc to, co chcielibyśmy zrobić, to spojrzeć, czy w benchmarku nie ma zadania, które jest podobne. Na przykład jeżeli pracujemy nad analizą wydźwięku, to zobaczymy, że w KLEJ Benchmarku są zadania poświęcone analizie wydźwięku, zamiast patrzeć na model, który średnio jest najlepszy, wybierzmy model, który jest najlepszy na tym konkretnym zadaniu. Jeżeli przykładowo mamy dane treningowe z jednej domeny, a będziemy się ewaluować na danych z innej domeny, to również w KLEJ Benchmarku mamy zamodelowane takie zjawisko, więc możemy zobaczyć, które modele najlepiej generalizują pomiędzy domenami. W związku z tym patrzymy też od strony innych zadań.

Więc generalnie sam KLEJ Benchmark pełni też trzecią funkcję – motywująca i propagującą te duże modele językowe, zbierając w jednym miejscu wszystkie te modele. Do tej pory było tak, że jak jakaś grupa badawcza, firma buduje taki model, wydaje duże pieniądze, żeby go wytrenować, publikuje na swojej stronie, to tak naprawdę mało kto o tym wie. Inna grupa publikuje swój model i też mało osób o tym wie. To jest rozproszone i w bardzo wielu miejscach. I jednym z celów KLEJ Benchmarku jest to, żeby te wszystkie modele zebrać w jedno miejsce i oczywiście z jednej strony je porównać, ale tak naprawdę zaprezentować w jednym miejscu, tak żeby końcowy użytkownik łatwo znaleźć wszystkie czy większość modeli, nawet przetestować wszystkie z nich na swoim zadaniu. Modeli nie ma aż tak dużo. W tej chwili jest ich kilkanaście, więc tak naprawdę można przetestować wszystkie i zobaczyć, który jest najlepszy na naszym zadaniu. Natomiast jest to ułatwione, bo znajduje się po prostu w jednym miejscu.

To bardzo fajna inicjatywa. Skąd wziął się na to pomysł? Wspomniałem już o motywacji, gdybyś mógł powiedzieć o tym kilka słów. Czy to wynikało z twoich potrzeb zawodowych czy prywatnych? Jak to wyglądało w twoim przypadku?

Potrzeba była absolutnie pragmatyczna. W sierpniu zeszłego roku w Allegro postanowiliśmy wytrenować taki ogólny model do przetwarzania języka naturalnego. Rok temu właściwie nie było żadnego dedykowanego modelu wyłącznie dla języka polskiego. Stwierdziliśmy, że coś takiego jest konieczne z jednej strony dla rozwoju nauki w Polsce, z drugiej – dla nas: Allegro. Okazało się, że żeby wytrenować taki model, musimy podjąć bardzo dużo różnorodnych decyzji. Musimy dużo pokręteł wstawić w odpowiedni sposób, żeby ten model faktycznie działał sensownie. I szybko zderzyliśmy się ze ścianą, bo nie wiedzieliśmy, jak go ewaluować. Oczywiście mieliśmy nasze wewnętrzne zadania, na których chcieliśmy radzić sobie dobrze, ale one były bardzo specyficzne w naszej domenie, a my potrzebowaliśmy wytrenować model ogólny dla języka polskiego.

W związku z tym zaczęliśmy szukać w internecie, w artykułach naukowych, jakie zadania są popularne, jakie są wykorzystywane, na jakich zadaniach ludzie się porównują. Zaczęliśmy je czysto wewnętrznie zbierać, czyścić te data sety i zrobiliśmy taki wewnętrzny KLEJ Benchmark. Był to początkowo czysto wewnętrzny projekt, dosłownie na naszej firmowej Wikipedii, gdzie za każdym razem, jak trenowaliśmy nowy model, to liczyliśmy skuteczność na tych zadaniach, patrzyliśmy, jak nowa wersja modelu sobie radzi. I jak już ten benchmark dojrzał i się w miarę ustalił, to stwierdziliśmy, że właściwie jest to świetna rzecz, żeby to wypromować i pokazać na zewnątrz, tak naprawdę ważniejsza niż ten model języka, który przy okazji wytrenowaliśmy. Szczególnie, że w międzyczasie wiele grup badawczych zaczęło takie modele trenować. Tak naprawdę ciężko nam było stwierdzić, czy warto kontynuować pracę nad naszym modelem czy może wykorzystać któryś opublikowany przez inną firmą, inny zespół. Publikując benchmark, właśnie umożliwiliśmy to porównanie, tak naprawdę widzimy w tym większą wartość niż nawet opublikowanie modelu, co przy okazji też zrobiliśmy. Tak naprawdę ten benchmark okazał się kluczowym elementem. I oczywiście cały czas z niego korzystamy. Dzisiaj rano kolega wysłał mi wyniki najlepszego wariantu modelu, jak sobie dobrze radzi, jest cały czas używany wewnętrznie.

Skąd wzięła się nazwa „KLEJ”?

Byliśmy mocno zainspirowani benchmarkiem do języka angielskiego. Nie wymyśleliśmy wszystkiego od zera sami. Do języka angielskiego jest popularny GLUE benchmark (General Language Understanding Evaluation). Idea jest bardzo podobna. Analogicznie jest dziewięć zadań, na których ewaluujemy ogólne modele języka tylko dla angielskiego. Byliśmy mocno zainspirowani samym kształtem, konstrukcją benchmarku. Zainspirowaliśmy się też nazwą. Nazwaliśmy nasz benchmark „KLEJ”, co oznacza: Kompleksowa Lista Ewaluacji Językowych, właśnie żeby pokazać, że ważna jest dla nas ta kompleksowość. My chcemy ewaluować modele na bardzo różnorodnych zadaniach, tekstach z różnorodnych domen, żeby promować modele, które po prostu radzą sobie dobrze. Niezależnie od tego, jakie zadanie mamy do rozwiązania, to modele powinny radzić sobie równie dobrze, a nie być wyspecjalizowane w jednym konkretnym zadaniu, w jednej konkretnej domenie.

Jakie dokładnie zadania są w tym benchmarku i w jaki sposób ta obiektywność ewaluacji jest zapewniana? Innymi słowy: na jakich zbiorach ewaluowane są te metody w poszczególnych zadaniach?

Te zbiory danych, które otworzyliśmy, pochodzą zazwyczaj od już ustalonych zbiorów danych opublikowanych wcześniej przez wielu badaczy. I z jednej strony są tu zadania od strony analizy wydźwięku – temat bardzo popularny i ważny – czyli żeby stwierdzić, czy dany tekst jest nacechowany pozytywnie, negatywnie czy neutralnie. Tu korzystamy z dwóch zbiorów danych PolEmo 2.0 i ze zbioru, który my wypuściliśmy, czyli Allegro Reviews. Są to zbiory recenzji on-line różnego rodzaju produktów itd. W szczególności na jednym z nich ewaluujemy, jak model dobrze generalizuje pomiędzy domenami, tak więc trenujemy modele na recenzjach z jednej domeny, a ewaluujemy na recenzjach z innej. Zadanie dokładnie to samo, ale zbiór treningowy istotnie różni się od testowego. Założeniem jest to, że jeżeli ten ogólny model języka uczy się, co to znaczy, że recenzja jest pozytywna albo negatywna, nie powinno mieć znaczenia, czy ocenia aktualnie pralki czy hotele. Tak jak człowiek. Jeżeli człowiekowi pokażemy recenzje hoteli, powiemy: „Te recenzje są dobre, a te złe”, potem zapytamy go o recenzje pralek, to on równie dobrze powinien powiedzieć, że są one dobre albo nie. Więc analiza wydźwięku to jednak grupa.

Kolejne zadanie to wykrywanie nazw własnych: również takie standardowe zadanie w przetwarzaniu języka. Przy czym my delikatnie je zmodyfikowaliśmy. Celem, który przyświecał też przy konstrukcji tego benchmarku, była łatwość jego wykorzystania. I tutaj skupiliśmy się na tym – zresztą jak w benchmarku GLUE – żeby zawsze dokonywać klasyfikacji bądź regresji, ale zwracać jedną wartość na danej obserwacji. Czyli jeżeli mamy recenzję on-line, to chcemy powiedzieć, czy ona jest nacechowana pozytywnie czy negatywnie, gdy jest jedna konkretna wartość dla całej obserwacji, dla całej recenzji. I tutaj chcieliśmy również zamodelować wykrywanie nazw własnych, które w takim tradycyjnym ujęciu jest kompletnie inaczej sformułowane. Tam dla każdego słowa musimy przewidzieć, czy jest nazwa własna czy nie. Jeżeli jest nazwa własna, to jakiego typu. To już nam zaburzyło koncepcję spójnego, prostego interfejsu dla wszystkich zadań, w związku z tym przeformułowaliśmy na nieco prostsze, ale w zupełności analogiczne, tzn. musimy wykryć, czy w danym zdaniu jest nazwa własna czy nie. Już nie wymagamy od modelu, żeby znalazł konkretne miejsce, ale żeby po prostu nam powiedział, czy dana nazwa własna tam występuje czy nie, a jeżeli tak, to jakiego jest typu. Tutaj wierzymy, że jest to porównywalna trudność modelu, jak tę nazwę własną musi znaleźć. Wystarczy, że nam powie, że ona jest, bez wskazywania w którym miejscu. Więc to jest drugie standardowe zadanie NLP.

Kolejna grupa zadań to parafrazy i rozpoznawanie, czy dwie sekwencje są podobne albo nie. Z jednej strony korzystamy ze zbioru streszczeń artykułów newsowych i model musi nauczyć się rozpoznawać, czy dwa streszczenia streszczają ten sam artykuł czy nie. To bardzo ciekawe zadanie pod względem tego, że te dwa fragmenty tekstu są bardzo długie, w związku z tym model musi sobie radzić nie tylko na krótkich, jednozdaniowych sekwencjach, ale też dłuższych dokumentach, które zawierają kilkanaście zdań. I z drugiej strony korzystamy ze zbiorów danych, które operują właśnie na pojedynczych zdaniach. Trzeba zdecydować, czy para zdań mówi o tym samym czy nie, czy jedno zdanie wynika z drugiego albo jest zaprzeczeniem drugiego.

Kolejna grupa parafraz, trochę podobny tematem to questions answering, czyli odpowiadanie na pytania. Jest to zadanie, które ciężko sprowadzić do wspólnego interfejsu, w tym sensie, że jeżeli zadamy jakieś pytanie, chcemy wygenerować odpowiedź, albo w innym ujęciu: we większym fragmencie tekstu znaleźć odpowiedź. My tutaj przeformułowaliśmy zadania odpowiadania na pytania, tak aby model wskazywał, czy dana para: pytanie – odpowiedź jest poprawna czy nie, czyli czy ta zaproponowana odpowiedź jest poprawna. Tego typu pytania są zazwyczaj bardzo proste, bo to od razu widać, ponieważ jeżeli mamy negatywne, nieprawidłowe odpowiedzi, to one często są kompletnie różne od tych pytań, które zadajemy. Więc to, co zrobiliśmy, żeby istotnie utrudnić to zadanie, to wykorzystaliśmy już dostępne dane z systemu do odpowiadania na pytania, gdzie te negatywne przykłady to są odpowiedzi zwrócone przez system do odpowiadania na pytania, gdzie już jakiś model stwierdził, że one mogą być odpowiedzią na pytanie. A dodatkowo jeszcze z tych negatywnych odpowiedzi jako negatywy wybraliśmy te przykłady, które mają największą część wspólną z pytaniem. Czyli to są takie odpowiedzi, które wyglądają praktycznie jak pytanie. One po prostu świetnie pasują jako odpowiedź na dane pytanie. Oczywiście potem ręcznie je zalokowaliśmy, żeby mieć pewność, że to nie są jednak prawdziwe odpowiedzi, ale dzięki temu to zadanie jest bardzo trudne, bo model faktycznie musi zrozumieć, o co chodzi w tym pytaniu, faktycznie musi wiedzieć, jaka jest odpowiedź, bo dopiero wtedy będzie w stanie odpowiedzieć, czy dana odpowiedź pasuje do pytania. To jest też zadanie, które uważamy za najtrudniejsze w całym benchmarku, bo fizycznie nie da się wytrenować modelu wyłącznie na tych danych, żeby poprawnie je rozwiązywać. Po prostu ilość wiedzy zewnętrznej, która musi być zakodowana w modelu, jest tak duża, że nie da się tego tak łatwo nauczyć na podstawie samego zbioru treningowego. To musi być zewnętrzny, wytrenowany model treningowy, który już gdzieś widział te pytania i te odpowiedzi, już nauczył się kodować, co jest czym.

I ostatnim zadaniem jest wykrywanie w tweetach, czy tweet jest hejterski czy nie. To jest jedno z zadań z PolEvala, które wykorzystaliśmy bezpośrednio. Było bardzo fajne, kompletnie inne od zadań dotychczasowych. I ze względu na domeny, że to są tweety, czyli takie teksty pisane przez ludzi, często tam było dużo błędów, z drugiej strony samo zadanie też było ciekawe.

Co można powiedzieć o obecnym stanie tego rankingu? Jakie metody są tam w ten chwili uwzględnione? Co teraz dla języka polskiego się sprawdza i jakiego typu modele zostały uwzględnione w tym rankingu?

Teraz w rankingu na stronie internetowej głównie obecne są modele oparte o architekturę Transformer – taką nową architekturę służącą właśnie do tworzenia modeli i ogólnie języka polskiego, chociaż w naszym artykule również ewaluujemy modele dużo prostsze i generalnie pokazujemy, że radzą sobie dużo gorzej. Natomiast jeżeli chodzi o modele, które aktualnie są na stronie w rankingu oficjalnym, to jest tam tak naprawdę kilka ich grup. Z jednej strony są to modele wielojęzykowe, które wytrenowane zostały przez Google’a, Facebooka i nie zostały wytrenowane ściśle pod analizę języka polskiego, tylko ogólnie pod analizę kilkudziesięciu czy kilkuset różnych języków, tak żeby człowiek nie musiał myśleć, którego modelu użyć, tylko wziął gotowy i go użył.

Z drugiej strony są modele wytrenowane przez ośrodki naukowe, przez firmy z Polski. Ich jest kilka. Jest oczywiście też nasz, początkowo był najlepszy w tym rankingu. W momencie gdy ranking nie był jeszcze opublikowany, łatwo być najlepszym. Kiedy go opublikowaliśmy, okazało się, że równolegle pracuje nad tym dużo osób. I nagle spadliśmy na ósme czy 10. miejsce. Najlepszym polskim modelem, który został opublikowany, jest model przygotowany przez ośrodek przetwarzania informacji oparty o architekturę RoBERTa, i tutaj w szczególności bardzo długo oni byli na pierwszym miejscu rankingu, chociaż ostatnio zostali delikatnie przegonieni przez wielojęzykowy model opublikowany przez Facebooka, tzw. XLM-RoBERTa, również oparty o tę samą architekturę, tylko wytrenowany dla wielu języków, w tym dla polskiego. Sam w sobie nie był lepszy od wytrenowanego ścisłe na języku polskim, natomiast został dodatkowo dotrenowany jeszcze na korpusie polskich tekstów. Okazało się, że to wystarczyło, żeby przebić ten model trenowany tylko na języku polskim. Natomiast to też są rzeczy, które się zmieniają niemalże z tygodnia na tydzień. Ja sam jestem bardzo podekscytowany za każdym razem, jak wchodzę na stronę i widzę, że ktoś zgłosił, opublikował nowy model. Widać, że ludzi to kręci, że chcą opublikować i stworzyć coś nowego. Choć oczywiście nie zmienia się to aż tak dynamicznie z godziny na godzinę, z minuty na minutę, bo zbudowanie takiego modelu generalnie jest bardzo kosztowne i zabiera dużo czasu. Wiadomo, że to nie jest tak, że z minuty na minutę pojawi się coś nowego.

Jak to się odbywa technicznie? Jeśli ktoś zgłasza model, to sam dokonuje tej ewaluacji czy to wy jej dokonujecie, czy to się dzieje automatycznie? Jak zgłosić model do rankingu?

Generalnie nie chcieliśmy ograniczać użytkowników, jeżeli chodzi o samą konstrukcję modelu. Model może być dowolny, predykcja wykonywana dowolnie. W związku z tym technicznie jest to rozwiązane w ten sposób, że my jako właściciele benchmarku jako jedyni mamy dostęp do zbiorów testowych wszystkich zadań. Oczywiście, ponieważ część zadań jest bezpośrednio wzięta z zewnętrznych zbiorów danych, to te dane testowe gdzieś po internecie krążą. Jeżeli ktoś byłby bardzo ambitny, to mógłby je odtworzyć. Mam nadzieję, że nikt tego nie zrobi i zachowa uczciwość. Natomiast generalnie w samym KLEJ Benchmarku to my posiadamy ukryte zbiory testowe i to, czego oczekujemy od uczestników, to że przygotują zbiory z predykcjami do tego zbioru testowego. I te zbiory z predykcjami wrzucą na stronę i tam już na stronie automatycznie one się zewaluują i otrzymamy wyniki dla każdego zadania, które albo będziemy mogli opublikować na stronie, albo nie. Wtedy mamy możliwość, żeby te wyniki ukryć, bo oczywiście czasem ktoś zgłosi coś głupiego, pomyli się, nie chcemy zaśmiecać benchmarku. To jest jedna strona.

Druga strona jest taka, że oczywiście chcemy w możliwie najlepszy sposób wspierać używanie tego benchmarku, więc dla dosyć dużej popularnej grupy modeli czy właśnie transformerów opublikowaliśmy zestaw skryptów, które pozwalają wytrenować modele pod te konkretne zadania z KLEJ Benchmarku, tak żeby to było możliwie łatwe. Więc jeżeli ktoś korzysta z implementacji z biblioteki Transformer, co jest zdecydowanie wiodącym sposobem trenowania i przechowywania tych modeli, to tak naprawdę jedyne, co musi zrobić, to podać ścieżkę do swojego modelu i kliknąć Enter – te skrypty wytrenują poszczególne modele do rozwiązywania poszczególnych zadań, przygotują te zbiory predykcji, które już będzie można wrzucić na stronę i dostać ocenę wyników.

Jak ty się w ogóle zapatrujesz na kwestie rozwoju tego rodzaju metod językowych? Czy przewidujesz, że kolejne metody, które się pojawią, będą bardziej różnicowane trenowaniem na większej ilości danych, czy też nadal uwzględniane będą modyfikacje samego podejścia do tworzenia tego modelu, np. architektury sieci?

Wydaje mi się, że rozwój pójdzie w dwóch kierunkach. Najbardziej oczywisty jest taki, że te modele będą po prostu wyskalowywane od coraz to większych liczb parametrów, coraz większych zbiorów danych, coraz dłuższych treningów. Tak naprawdę to cały czas się dzieje i cały czas to obserwujemy. Zdecydowanie najprostszy sposób podbijania skuteczności modelu jest kosztowny, ale bardzo łatwy, tyle że jesteśmy w stanie wybrać setki czy tysiące dolarów i wytrenować lepszy i większy model. Zresztą widać, taki jest trend do języka angielskiego. Znana grupa badawcza OpenAI opublikowała właśnie taki model, wielokrotnie przebijając liczbę parametrów wszystkich poprzednich modeli – tu przykładowo standardowa architektura BERT ma 355 mln parametrów. Wytrenowali model, który ma ich 18 mld, jest to olbrzymi skok takiej skalowalności, jeżeli chodzi o trenowanie większych modeli. To na pewno stanowi dalszy kierunek rozwoju. Jest to prosty kierunek rozwoju. Tutaj nie ma tak naprawdę dużej innowacji, poza wyskalowywaniem się, co jest bardzo trudnym zadaniem inżynierskim, ale niespecjalnie innowacyjnym naukowo, natomiast przynoszącym duże rezultaty. To jest też rozwiązanie, które nie będzie działać dobrze w praktyce. Te modele potem nie będą mogły być wdrażane w praktyce, nie wspominając już o urządzeniach mobilnych. Byłyby zbyt kosztowne. W związku z tym na pewno będzie trend o tym, jak myśleć o lepszych modelach i architekturach i jak budować modele, które nie wymagają aż tak dużo parametrów, aż tak dużego treningu, aż tak potencjalnie dużych zbiorów danych, bo po prostu taka będzie konieczność. Ktoś w końcu wymyśli nową architekturę, która będzie działać lepiej. Tak samo było z Transformerem, który zaczął działać lepiej niż sieci LSTM, chociaż gdyby jeszcze kilka lat temu ktoś powiedział, jak się modeluje język, to wszyscy by stwierdzili, że tylko sieciami LSTM. Jeszcze wcześniej były to inne rozwiązania, więc tak naprawdę ten rozwój będzie szedł z buta.

A jeśli chodzi o wykorzystanie metod, które są w rankingu, czy oczekujecie, że te zgłaszane rezultaty będą pochodziły od modeli, które są opublikowane, dostępne dla każdego, albo może wyopensource’owane są same metody uzyskania tego modelu, czy też to jest dla was nieistotne i takie zamknięte metody również mogą być zgłaszane?

W tej chwili nie wprowadzamy żadnych ograniczeń. Generalnie bardzo byśmy chcieli, żeby te modele były dostępne publicznie, żeby każdy mógł z nich korzystać. Zdajemy sobie sprawę, że nie zawsze będzie to możliwe, więc tak naprawdę zaakceptujemy wszystko, do takiego momentu, w którym nie potwierdzimy, że ktoś nas nie oszukuje albo np. faktycznie wytrenował ten model, a nie np. ręcznie zaanotował dane i powiedział, że on stworzył świetny model, ale nie jest w stanie go opublikować, bo nie, ponieważ są pewnego rodzaju restrykcje prawne. Natomiast dopóki nikt nie zastosuje takiego wybiegu, żeby ukryć swoje oszustwo, jak najbardziej przyjmujemy i zapraszamy wszystkich do zgłaszania się do KLEJ Benchmarku.

Czy benchmark okazał się przydatny dla was wewnętrznie w firmie do tego, żeby wiedzieć, że jakiś model dobrze sobie radzi w zadaniu, które akurat musicie rozwiązać, czy okazało się, że z jakiegoś modelu możecie skorzystać samodzielnie we własnej pracy?

Zdecydowanie niemalże codziennie go używamy w firmie, przy rozwoju nowych modeli ogólnych dla języka polskiego, bo tym też generalnie się zajmujemy. Budujemy nowe, lepsze modele języka polskiego, które potem wykorzystujemy w konkretnych zadaniach praktycznych i komercyjnych. Więc jeżeli budujemy ogólny model języka polskiego, to po prostu korzystamy z KLEJ-u, żeby wiedzieć, czy idziemy w dobrym kierunku. Obecnie jeszcze nie korzystaliśmy z żadnych najnowszych modeli zewnętrznych, opublikowanych. Takich bardziej klasycznych, wielojęzykowych – tak, chociaż one działały nam dosyć słabo, stąd pomysł, żeby wytrenować swój własny model. Natomiast tutaj jesteśmy na tyle pewni, zadowoleni z naszych modeli, że obecnie korzystamy głównie z naszych. Jest to też kwestia specyfiki danych, bo nie tylko trenujemy modele ogólne do języka polskiego, ale też specyficznie dostosowane do naszej domeny. Okazuje się, że jeżeli mamy dostatecznie dużo danych ze specyficznej domeny, to warto wytrenować taki ogólny model językowy, ale dostosowany do specyficznej domeny. Wtedy daje on dużo lepszy wynik niż taki ogólny model. Natomiast tutaj już jest kwestia tego, że trzeba mieć naprawdę dużo danych, żeby ten specyficzny model wytrenować. Jeżeli nie mamy tych danych, to lepiej używać modelu ogólnego.

Na koniec zapytam cię jeszcze o kwestie wykorzystania praktycznego takich praktycznych modeli, bo, jak sam powiedziałeś, teraz jest wyścig na liczbę parametrów w tych modelach. Google, Facebook czy inne ośrodki proponują wielkie modele. Ty pracujesz w miejscu, które zapewne może sobie pozwolić na dużą infrastrukturę, ale czy nawet u was tak gigantyczne modele produkcyjnie mają sens czy też poszukujecie bardziej skompresowanych rozwiązań, które bardziej efektywnie wykorzystują te dane treningowe?

Poruszyłeś tu dwa aspekty: jeden: o to, czy jesteśmy w stanie wdrażać takie modele, jeżeli chodzi o czas predykcji, a drugi: o zbiory danych. Więc odpowiem z dwóch stron, zaczynając od zbiorów danych treningowych. Pod tym względem zdecydowanie korzystamy z tego typu modeli. Po prostu tych danych treningowych trzeba przygotować mniej. Oczywiście przygotowanie danych treningowych to duży koszt, więc jeżeli możemy go uniknąć, to zaanotujemy mniej danych, więcej czasu poświęcimy na przygotowanie lepszego modelu i lepszego produktu. Tu zdecydowanie korzystamy z modeli opartych o transformery.

Z drugiej strony pojawia się kwestia tego, czy faktycznie jesteśmy w stanie wdrożyć taki model, który będzie dostatecznie szybki. I odpowiedź ponownie brzmi: to zależy. Mamy takie projekty, w których przykładowo raz dziennie musimy dokonać jakiejś klasyfikacji tekstów. I wtedy nie ma żadnego problemu, używamy tych dużych, ogólnych modeli. A tak naprawdę to, że czas predykcji to jedna sekunda dla tekstu, nie ma dla nas żadnego problemu. My i tak raz dziennie musimy te dane przeliczyć, gdzieś przetrzymać predykcję. Więc spokojnie możemy używać tego typu modeli i cieszyć się z tego, że będziemy potrzebowali mniej danych treningowych i mieli dużo lepszą skuteczność predykcji. W kilku projektach dotyczących czysto klasyfikacji tekstów z tych modeli korzystamy. Natomiast są inne projekty, w których ten czas predykcji ma już znaczenie, np. chatboty, wyszukiwarka Allegro, gdzie musimy odpowiadać bardzo szybko. I zastosowanie tu tak dużego modelu nie byłoby praktyczne, bo czas predykcji np. ok. sekundy byłby już zdecydowanie zbyt duży. 

Teraz skupiamy się na analizie tego, jak duże modele skompresować do mniejszych – to kolejny, pojawiający się trend. Można oczywiście do tego problemu od zera trenować model specyficzny, który będzie szybki. Takie mamy w tej chwili rozwiązania. Natomiast konkurencyjnym trendem jest wytrenowanie ogólnego dużego modelu do przetwarzania języka, który będzie skuteczny, ale wolny. I skompresowanie go, tak żeby nie stracił za dużo na tej skuteczności, ale był nieporównywanie szybki i nieporównywalnie mniejszy. I pojawia się bardzo dużo naukowych publikacji z tego zakresu. Aktywnie je czytamy, obserwujemy nowe pomysły i je testujemy, żeby faktycznie móc wdrażać takie duże modele.

Bardzo dziękuję w takim razie za opowiedzenie nam o tym benchmarku, o historii powstania KLEJ Benchmark. I gratulacje za bardzo fajną inicjatywę, z której na pewno wszyscy w środowisku skorzystają, żeby wiedzieć, który z tych powstających modeli sprawdza się najlepiej. Dziękuję, że zgodziłeś się nam o tym opowiedzieć. I do usłyszenia.

Dziękuję za zaproszenie i zachęcam do korzystania, do kontaktu, gdybyście byli zainteresowani porozmawianiem albo usłyszeniem więcej szczegółów. Dzięki za wysłuchanie.

W notatkach do tego odcinka podcastu umieszony zostanie kontakt do ciebie i link do benchmarku, chociaż pewnie łatwo go znaleźć, wpisując „KLEJ Benchmark”.

Na koniec prośba: jeśli podobał ci się ten podcast, zostaw, proszę, recenzję w iTunes lub w innej aplikacji, z której korzystasz, słuchając tego podcastu. Na tej podstawie będę wiedział, który odcinek ci się podobał lub co w podcaście zmienić, żeby był jeszcze lepszy. W każdej chwili możesz zasubskrybować ten podcast, korzystając z tej samej aplikacji, dzięki czemu informacje o pojawieniu się najnowszego odcinka dostaniesz bezpośrednio pod postacią powiadomienia.

Dzięki i do usłyszenia w kolejnych odcinkach.