Modele językowe LLM podpowiadają, jak zbudować bombę – atak typu ArtPrompt

Niektórzy nie mogą już sobie wyobrazić życia bez “inteligentnych” pomocników. Duże modele językowe (LLM – Large Language Models) zyskały bardzo dużo zastosowań w ostatnich latach. Wykorzystywane są do obsługi klientów, generowania niewielkich snippetów kodu, w charakterze osobistych asystentów i nie tylko. Wciąż poprawiane, uczone na coraz większej ilości danych, modele te stają się każdorazowo lepsze w generowaniu odpowiedzi na zadane pytania bądź żądania. Nie wszyscy użytkownicy sieci mają jednak szczytne intencje lub po prostu generują zapytania związane z nielegalnymi treściami. Dlatego też twórcy poszukują metod filtrowania i ograniczania zakresu informacji udzielanych przez ich modele. 

Odpytując najpopularniejsze chatboty o tematy, np. uznane za nielegalne, można oczekiwać, że pytanie zostanie odrzucone. Złośliwi użytkownicy oraz badacze prześcigają się w pomysłach na obejście różnych metod, które mają za zadanie ograniczenia tematyki generowanych odpowiedzi przez LLMy. Przypomina to trochę grę w kotka i myszkę (co może być alegorią wielu gałęzi IT security). Badacze z uniwersytetów z Waszyngtonu oraz Chicago opublikowali bardzo ciekawą metodę obchodzenia filtrów treści w najpopularniejszych czatach z LLM takich jak GPT-3.5, GPT-4, Gemini, Claude czy Llama2. 

Zaskakujący jest jednak sposób tworzenia zapytań zaproponowany przez naukowców. Opracowali oni metodę “maskowania” słów w zapytaniach kierowanych do LLM przy pomocy… ASCII art, tak tak – technika tworzenia prostych obrazków przy pomocy znaków ASCII może być bardzo przydatna w obejściu zaawansowanych filtrów. Obecnie powszechnie stosuje się dwie metody zabezpieczeń promptów modeli językowych. Można je skategoryzować jako “opierające się na detekcji”, które bazują na filtrowaniu wejścia oraz wyjścia modelu i blokowania tych złośliwych. Innym podejściem jest parafrazowanie inputu oraz jego ponowna tokenizacja w celu ograniczenia skutków złośliwych promptów. 

Badacze opracowali benchmark pozwalający określić zdolność modeli do wykrywania pojedynczych i składających się z kilku liczb i cyfr ciągów, zbudowanych jako ASCII Art. Badanie wykazało, że obecnie wykorzystywane modele językowe mają trudności z rozpoznawaniem takich znaków. Dzieje się tak dlatego, że modele te są trenowane w oparciu o użycie semantyki do interpretacji znaków. 

Właśnie to zachowanie powoduje, że ArtPrompt jest tak skuteczny. Modele mają problem z zamianą obrazkowo przedstawionych napisów na tokeny, które mogłyby zostać wykryte na etapie filtrowania. Ponadto modele “skupiają” się na procesie rozpoznawania tekstu, co powoduje, że proces filtrowania może zostać przeoczony lub przeprowadzony w niedostateczny sposób. 

Atak ArtPrompt składa się z dwóch faz. Pierwszą z nich jest proces określony mianem “maskowania” i polega na generowaniu kolejnych zapytań, w których słowa promptu są po kolei z niego usuwane (szczególnie chodzi o słowa, które mogłyby doprowadzić do odrzucenia danego zapytania). W drugiej fazie “osłaniania” (ang. cloaking) generowane są zapytania, w których “wrażliwe” słowa są zastępowane przez napisy wygenerowane w formie ASCII art. Taki proces maskowania powoduje, że atakujący będzie musiał przeprowadzić tę fazę maksymalnie N razy (w stosunku do zapytania długości N). Oczywiście statystycznie będzie to z reguły znacznie mniej, ponadto można zoptymalizować ten proces przez odrzucenie zaimków, przedrostków itd. Jest to metoda dużo mniej złożona niż poprzednio zaproponowane ataki. 

Przeprowadzone eksperymenty wskazują, że atak ArtPrompt może zostać skutecznie przeprowadzony na wszystkich testowanych LLMach (rysunek 2).

Autorzy zaznaczają, że atak ten będzie wciąż skuteczny nawet w przypadku multimodalnych modeli językowych, które posiadają funkcję rozpoznawania obrazów. Dzieje się tak z powodu tego, że pomimo możliwości graficznej interpretacji ASCII Artów, są one traktowane jako tekstowy format, co dodatkowo oszukuje model. Dokładny schemat ataku zaprezentowano w formie schematu zawartym w pracy (rysnek 3). 

~fc