Małe, ale skuteczne – czyli jak modele encoder-decoder sprawdzają się w specjalistycznych zastosowaniach
04.11.2024 | Bartłomiej Orlik
Z artykułu dowiesz się
- czym charakteryzują się architektury modeli językowych - poznasz różnice między modelami Encoder, Decoder oraz Encoder-Decoder
- jak modele Decoder-Only oraz Encoder-Decoder realizują tłumaczenie tekstu i jakie są między nimi różnice
- zobaczysz wyniki porównania modeli Opus-mt-pl-en, Llama 3.1-8B-Instruct i Bielik 2.3-Instruct pod względem jakości tłumaczenia i efektywności
- poznasz najczęstsze przyczyny błędów w tłumaczeniach generowanych przez modele językowe oraz sposoby ich ograniczania
Wstęp
W ostatnich latach modele językowe ogólnego zastosowania o architekturze decoder-only zyskały ogromną popularność w dziedzinie przetwarzania języka naturalnego (NLP). Komercyjne rozwiązania, takie jak OpenAI GPT-4 czy Google Gemini pokazują, że tego typu modele potrafią sprostać szerokiemu spektrum zadań. Również modele open source, których przykładem może być Llama przygotowana przez firmę Meta czy polski Bielik opracowany przez zespół SpeakLeash we współpracy z ACK Cyfronet AGH, charakteryzują się wysoką skutecznością.
W kontraście do tych modeli można również postawić na mniej popularne, specjalistyczne rozwiązania oparte o architekturę encoder-decoder. Modele te doskonale sprawdzają się w realizacji potrzeb biznesowych, które skupiają się na realizacji jednego, konkretnego zadania przy zastosowaniu relatywnie niewielkich zasobów obliczeniowych. W ninejszym artykule przedstawię zalety architektury encoder-decoder na podstawie zadania tłumaczenia tekstu.
Czym charakteryzują się architektury modeli językowych?
W świecie przetwarzania języka naturalnego istnieje kilka kluczowych architektur modeli, które różnią się sposobem przetwarzania tekstu i generowania informacji. Zrozumienie tych różnic jest kluczowe, aby dostrzec, dlaczego niektóre modele sprawdzają się lepiej w określonych zadaniach. Przyjrzyjmy się zatem trzem głównym typom architektur: encoder, decoder oraz ich połączeniu encoder-decoder.
Architektura Encoder
Architektura typu encoder skupia się na przekształceniu tekstu wejściowego w zwięzłą reprezentację, zwaną często embeddingiem. Można to porównać do tłumaczenia zdania na uniwersalny język maszynowy, który model może łatwo analizować i wykorzystywać. Takie podejście jest szczególnie użyteczne w zadaniach wymagających pełnego zrozumienia tekstu, takich jak analiza wydźwięku, klasyfikacja dokumentów, a nawet budowanie zaawansowanych wyszukiwarek opierających się o zapytania w języku naturalnym. Modele te nie są jednak w stanie generować tekstu.
W tym artykule nie będziemy się skupiać na encoderach. Jeżeli chcesz dowiedzieć się więcej o tym, jak te modele rozumieją język naturalny, zapraszam do mojego poprzedniego artykułu: W jaki sposób AI rozumie język naturalny? Modele typu Text Embedding, w którym omawiam szerzej to zagadnienie.
Architektura Decoder
Modele o architekturze decoder koncentrują się na generowaniu tekstu na podstawie pewnego stanu początkowego lub sekwencji wejściowej. W praktyce oznacza to, że model przewiduje kolejne słowa (bazując na wcześniej wygenerowanych), bez bezpośredniego odniesienia do pełnego kontekstu wejściowego. Tego typu architektura jest fundamentem dużych modeli językowych, które potrafią tworzyć płynne i spójne teksty na zadany temat.
Warto zauważyć, że istnieją dwa główne rodzaje modeli decoder-only: modele bazowe oraz modele typu instruct. Modele bazowe są trenowane na ogromnych zbiorach danych tekstowych w celu przewidywania kolejnych słów w sekwencji. Natomiast modele typu instruct są dodatkowo dotrenowane (ang. fine-tuned), aby lepiej rozumieć i wykonywać instrukcje użytkownika. Dzięki temu są w stanie precyzyjnie odpowiadać na pytania, czy też realizować złożone polecenia.
Co więcej, modele decoder-only ogólnego zastosowania są zazwyczaj ogromne pod względem liczby parametrów, co pozwala im na uchwycenie złożonych zależności językowych i generowanie wysokiej jakości tekstu. Dla przykładu:
- GPT-3-5 (OpenAI) posiada 175 miliardów parametrów.
- Llama 3.1 (Meta) dostępna jest w wersjach zawierających 8, 70 oraz 405 miliardów parametrów.
- Bielik 2.3 (SpeakLeash oraz ACK Cyfronet AGH) to polski model posiadający 11 miliardów parametrów.
Tak duża liczba parametrów umożliwia modelom generowanie tekstu o wysokiej jakości, ale jednocześnie wiąże się z dużymi wymaganiami obliczeniowymi oraz zasobami pamięciowymi potrzebnymi do ich trenowania i wdrażania.
Modele decoder-only są niezwykle efektywne w zadaniach, gdzie istotne jest tworzenie nowego tekstu na podstawie krótkiej wskazówki lub zapytania. Ich zdolność do przewidywania kolejnych słów sprawia, że są niezastąpione w zastosowaniach takich jak autouzupełnianie, tworzenie kreatywnych treści czy generowanie odpowiedzi w chatbotach.
Architektura Encoder-Decoder
Architektura encoder-decoder łączy w sobie najlepsze cechy obu poprzednich podejść. W pierwszym kroku encoder przetwarza tekst wejściowy, zamieniając go na wewnętrzną reprezentację, która uchwytuje znaczenie i kontekst zdania. Następnie decoder wykorzystuje tę reprezentację do wygenerowania odpowiedzi. Rozdzielenie odpowiedzialności poprzez zastosowanie dwóch funkcjonalnych części w ramach jednego modelu pozwala na precyzyjne odwzorowanie informacji zawartych w tekście źródłowym.
Takie podejście jest szczególnie efektywne w zadaniach wymagających zarówno precyzyjnego zrozumienia tekstu wejściowego oraz wygenerowania spójnej odpowiedzi, jak na przykład tłumaczenie maszynowe czy tworzenie podsumowań. W przypadku zadania tłumaczenia, model musi dokładnie zrozumieć tekst w języku źródłowym, aby móc poprawnie przełożyć go na język docelowy, zachowując przy tym sens, styl i niuanse oryginału.
Co więcej, jedną z kluczowych zalet modeli encoder-decoder jest to, że mogą być one mniejsze pod względem liczby parametrów w porównaniu z dużymi modelami decoder-only. Ze względu na to, że są zazwyczaj projektowane i trenowane do realizacji jednego konkretnego zadania, nie potrzebują ogromnej liczby parametrów do uchwycenia ogólnych zależności językowych. Zamiast tego skupiają się na specyficznych wzorcach i strukturach potrzebnych do efektywnego wykonania danego zadania.
Przykładem takiego modelu jest Opus-mt-pl-en utworzony przez grupę badawczą z Uniwersytetu w Helsinkach, który służy do tłumaczenia tekstu z języka polskiego na angielski. Mimo stosunkowo małego rozmiaru (około 77.6 milionów parametrów, wykres 1), potrafi osiągać wysoką jakość tłumaczeń, często porównywalną lub nawet przewyższającą większe modele decoder-only ogólnego zastosowania. Dzięki mniejszej liczbie parametrów modele encoder-decoder są również bardziej efektywne obliczeniowo, co ułatwia ich trenowanie i wdrażanie w środowiskach o ograniczonych zasobach.
Wykres 1: Liczba parametrów dla wybranych modeli
Realizacja translacji z wykorzystaniem modeli językowych
Tłumaczenie tekstu przy użyciu modeli językowych może odbywać się na różne sposoby, w zależności od zastosowanej architektury. Przyjrzyjmy się, jak to wygląda w przypadku modeli decoder-only oraz encoder-decoder.
Tłumaczenie z wykorzystaniem modeli Decoder-Only
Modele decoder-only typu Instruct, nie zostały stworzone z myślą o tłumaczeniu tekstu. Ich głównym zadaniem jest generowanie kolejnych słów na podstawie instrukcji. Aby skłonić taki model do przetłumaczenia tekstu, musimy przygotować odpowiedni prompt systemowy, czyli specjalną komendę, która jasno określi, co model ma zrobić z tekstem dostarczonym przez użytkownika (tzw. prompt użytkownika).
Schemat 1: Schemat działania modelu LLM w kontekście tłumaczenia tekstu
Jak może wyglądać prompt systemowy? Na przykład:
"Przetłumacz tekst użytkownika z języka polskiego na język angielski. Podaj tylko przetłumaczony tekst."
Taka komenda nakierowuje model na przetłumaczenie tekstu podanego przez użytkownika i dostarczenie wyłącznie tłumaczenia.
Tłumaczenie z wykorzystaniem modeli Encoder-Decoder
Modele o architekturze encoder-decoder, specjalnie zaprojektowane do zadań takich jak tłumaczenie maszynowe, są prostsze w użyciu z punktu widzenia użytkownika. Wystarczy, że użytkownik dostarczy tekst w języku źródłowym, a model bezpośrednio go przetłumaczy. Wewnątrz modelu proces przebiega następująco: najpierw encoder przetwarza cały tekst wejściowy, zamieniając go na wewnętrzną reprezentację, która wychwytuje znaczenie i kontekst zdania. Następnie decoder wykorzystuje tę reprezentację do generowania tekstu w języku docelowym token po tokenie. Dzięki mechanizmowi cross-attention decoder "zwraca uwagę" na odpowiednie części tekstu wejściowego podczas generowania każdego słowa w tłumaczeniu. Proces generowania trwa do momentu napotkania tokenu stopu, który sygnalizuje zakończenie tłumaczenia. W rezultacie użytkownik nie musi przygotowywać skomplikowanych instrukcji czy promptów - wystarczy, że poda tekst do przetłumaczenia, a model samodzielnie wygeneruje odpowiedź w języku docelowym.
Porównanie jakości tłumaczenia dla wybranych modeli
Aby ocenić jakość tłumaczeń generowanych przez różne modele językowe, przeprowadziłem porównanie trzech z nich. Wykorzystałem do tego zbiór danych Tatoeba, który zawiera ręcznie przetłumaczone pary tekstów polsko-angielskich. Zbiór ten składa się z 5000 obserwacji, na których modele nie były trenowane. Analiza tłumaczeń wygenerowanych przez modele, pozwoli ocenić ich orientacyjną jakość w tym zadaniu.
Testowane modele to:
- Opus-mt-pl-en: model typu encoder-decoder, specjalnie zaprojektowany do tłumaczenia z języka polskiego na angielski.
- Llama 3.1-8B-Instruct: duży model decoder-only, dostrojony do wykonywania instrukcji użytkownika.
- Bielik 2.3-Instruct: polski model decoder-only, również dostrojony pod kątem interpretacji instrukcji.
Do oceny jakości tłumaczeń zastosowano metrykę BLEU (Bilingual Evaluation Understudy), która jest powszechnie stosowanym narzędziem do automatycznej oceny jakości tłumaczeń maszynowych. Metryka BLEU porównuje wygenerowane tłumaczenie z jednym lub kilkoma tłumaczeniami referencyjnymi, analizując zgodność na poziomie słów i fraz. Wynik BLEU wyrażany jest w skali od 0 do 1, gdzie wyższa wartość wskazuje na lepszą jakość tłumaczenia.
Wykres 2: Ocena jakości tłumaczenia - wyniki BLEU dla wybranych modeli językowych
Wykres skrzynkowy 2 (boxplot) przedstawia wartości metryki BLEU dla poszczególnych modeli. Analiza median oraz kwartyli wskazuje, że model Opus-mt-pl-en osiągnął najwyższe wyniki, nieznacznie przewyższając Bielik 2.3-Instruct. Wykorzystanie Llama 3.1-8B-Instruct poskutkowało niższymi wartościami metryki BLEU, ale model nadal wykazał zdolność do generowania poprawnych tłumaczeń. Warto zwrócić uwagę, że wyniki dla modeli decoder-only należy interpretować orientacyjnie, ponieważ jakość tłumaczenia zależy bezpośrednio od jakości zastosowanego promptu systemowego. W przypadku sformułowania lepszego promptu można potencjalnie zwiększyć wartości metryki BLEU dla tych modeli.
Dodatkowo, ważnym aspektem oceny jest czas przetwarzania zbioru danych. Poszczególne modele różnią się pod względem szybkości generowania tłumaczeń, co zostało przedstawione na wykresie 3. Analiza wyników pozwala zauważyć wyraźne różnice w wydajności. Czas przetwarzania może mieć istotne znaczenie w praktycznych zastosowaniach, gdzie szybkość uzyskania tłumaczenia jest kluczowa.
Wykres 3: Czas translacji zbioru danych dla każdego modelu
W celu porównania wydajności modeli, zmierzono czas tłumaczenia zbioru, gdzie tłumaczenie wykonywane było jedno po drugim (sekwencyjnie) przy użyciu GPU. Ze względu na ograniczoną ilość pamięci VRAM, model Bielik 2.3-Instruct nie umożliwiał przetwarzania tekstów w sposób batchowy. Zrównoleglenie procesu tłumaczenia pozwala modelowi Opus-mt-pl-en na jeszcze szybsze przetworzenie danych. Różnica w czasie procesu tłumaczenia została przedstawiona na wykresie 4.
Wykres 4: Czas translacji zbioru danych - batchowo vs sekwencyjnie
Z czego wynikają błędy przy tłumaczeniu tekstu?
Na podstawie uzyskanych wyników możemy stwierdzić, że modele językowe mimo wysokiej skuteczności nie są stuprocentowo dokładne. Część z tych niedokładności wynika z możliwości przetłumaczenia tego samego fragmentu tekstu w różny sposób. Jednak istnieją sytuacje kiedy tłumaczenia są po prostu niepoprawne. Z czego to może wynikać? Przyczyn jest wiele i są one związane zarówno z ograniczeniami samych modeli, jak i złożonością języka naturalnego. Warto przyjrzeć się najczęstszym problemom, wśród których wyróżnić możemy:
- Zbyt wczesne przewidzenie tokenu stopu: Model kończy generowanie tłumaczenia przedwcześnie, co prowadzi do niepełnego przekładu.
- Brak zrozumienia kontekstu: Model nieprawidłowo interpretuje kontekst wypowiedzi lub słów, co skutkuje błędami w tłumaczeniu.
- Błędy wynikające z nieprecyzyjnego promptu systemowego: Jakość tłumaczenia w dużej mierze zależy od precyzji promptu systemowego. Niejasny lub niewystarczająco szczegółowy prompt może prowadzić do błędów w tłumaczeniu.
- Halucynacje: Model dodaje informacje, które nie występują w oryginalnym tekście, zmieniając lub zniekształcając jego znaczenie. Jest to szczególnie częste w modelach decoder-only, które podczas generowania mogą "wymyślać" treści niezwiązane z tekstem źródłowym.
Warto zauważyć, że punkt 3 oraz 4 dotyczy głównie modeli decoder-only. W przypadku modeli translacyjnych encoder-decoder prompt systemowy nie występuje, a halucynacje są ograniczone poprzez mechanizm cross-attention.
Aby lepiej zilustrować wybrane trudności, poniżej znajduje się analiza wybranych błędów na podstawie kilku przykładów z przetworzonego zbioru.
Tabela 1: Wybrane błędne tłumaczenia
W pierwszym przykładzie model Bielik dodał frazę „Przetłumaczone zdanie:” oraz znak nowej linii, mimo że systemowy prompt został skonstruowany tak, aby model produkował wyłącznie przetłumaczony tekst. Sytuacje takie wskazują, że instrukcja bywa przez model ignorowana
W drugim przykładzie pytanie „Od czego to skrót – EC?” zostało potraktowane jako instrukcja. Model Llama nie tylko przetłumaczył to pytanie, ale również udzielił na nie odpowiedzi. Z kolei Bielik zignorował prompt systemowy i bezpośrednio odpowiedział na pytanie zamiast je przetłumaczyć.
Analogiczna sytuacja wystąpiła w trzecim przykładzie. Choć Bielik poprawnie przetłumaczył pytanie, Llama postanowiła na nie odpowiedzieć, ale zrobiła to w języku polskim.
W ostatnim przykładzie model Opus-mt-pl-en przetłumaczył jedynie pierwsze zdanie, pomijając drugie. Spowodowane to było zbyt wczesnym przewidzeniem tokenu stopu, czego skutkiem jest niekompletne tłumaczenie.
Podsumowanie
W erze rosnącej popularności modeli decoder-only, warto pamiętać o tym, że ich zastosowanie do konkretnych zadań może nie być najefektywniejszym wyborem. Wymagają one znacznych zasobów obliczeniowych i często nie osiągają optymalnych wyników w jednym, konkretnym zadaniu. W takich przypadkach lepiej sprawdzają się modele encoder-decoder, które są zoptymalizowane pod kątem konkretnych aplikacji. Dlatego, w przypadku zadań takich jak tłumaczenie tekstu, warto rozważyć wykorzystanie modeli encoder-decoder, jeżeli jest taka możliwość.
© 2024 ING Bank Śląski S.A. Wszelkie prawa zastrzeżone. Ustawienia cookie | Polityka cookie