13:16
18/1/2024

Świadomość ryzyk związanych z AI wydaje się rosnąć. Na modnych debatach i panelach o zagrożeniach AI omawia się problemy programowania wspomaganego AI, bughuntingu, prompt enginieeringu, socjotechnik wspieranych AI itd. Ryzyka najlepiej jest analizować zawczasu, ale wciąż zdarza się, że ktoś bardzo pomysłowy wymyśli nowy problem: załóżmy, że twórca modelu sztucznej inteligencji (LLM) wbuduje w niego backdoora. Czy da się go wyeliminować dodatkowym treningiem i dostrajaniem?

Ten ciekawy problem opisali badacze związani z m.in. firmą Anthropic, która jest znana z rozwijania modelu Claude (konkurenta ChatGPT). Artykuł nosi tytuł Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training. Przyjmy się mu.

“Złe AI” udaje dobro

Wszyscy wiemy, że modele językowe (LLM) da się zatruć. Można to zrobić zasilając model kiepskimi danymi (tutaj na myśli przychodzi słynna historia bota Tay) albo trenując model tak, aby podawał “uzłośliwione” odpowiedzi (np. proponował programistom kod, który zawiera błędy). To zachęca do podzielenia modeli językowych na “dobre” i “zatrute”, ale przecież to zbyt proste.

Gdybyśmy chcieli stworzyć naprawdę złe AI to musiałoby ono do pewnego stopnia udawać coś pożytecznego, a dopiero w odpowiednim momencie, w sposób maksymalnie niepostrzeżony powinno podrzucić użytkownikowi zgniłe jajo. Takie “złe AI” musiałoby działać niczym samochody pewnej niemieckiej firmy, które włączały ograniczenia emisji w czasie testów emisji, ale potem je wyłączały. Albo jak pociągi pewnej polskiej firmy, które psuły się w konkretnych miejscach lub datach.

Badacze z Anthropic zrobili właśnie coś takiego. Wytrenowali model językowy w taki sposób, aby był w stanie produkować albo bezpieczny kod albo kod z podatnościami. To czy model zwrócił “zły” kod zależało od zawarcia w prompcie konkretnej instrukcji. Jeśli użytkownik pisał, że “obecny rok to 2023” model zwracał bezpieczny kod. Jeśli w prompcie napisano, że “obecny rok to 2024” to kod zwracany zawierał już podatności.

Grafiki ilustrująca sposób wytrenowania modeli do potrzeb eksperymentu

Potem badacze przeszli do fazy drugiej i trzeciej eksperymentu. Postanowili sprawdzić, czy poddanie tak zatrutego modelu uczeniu posiłkowanemu (reinforcement learning, RL), adversarial training oraz fine-tuningowi (czasem zwanemu dostrajaniem) pozwoli wykorzenić z niego raz wprowadzone zagrożenie. Niestety okazało się, że złośliwe nawyki były odporne na dodatkowy trening wprowadzony w celu podniesienia bezpieczeństwa.

Próbowano też wprowadzić zmiany do modelu za pomocą tzw. adversarial trainingu (jak to będzie po polsku?) i tutaj wniosek badaczy był szczególnie ciekawy. Ta metoda nie usunęła backdoora, ale jakby… pomogła go ukryć. Jeśli lubicie tematy sztucznej inteligencji to szczerze polecamy lekturę całej pracy badaczy.

Niebezpieczeństwo teoretyczne (na razie)

Wspomniany artykuł został przedstawiony przez firmę Anthropic m.in. jako argument, że lepiej brać modele sztucznej inteligencji od zaufanych dostawców (czytaj: Anthropic ostrzega przed open source, które jakby nie patrzeć jest konkurencją dla jego produktu, hehe). Natomiast bardzo dobre wnioski z tego artykułu wyciągnął Andrej Karpathy związany z OpenAI.

We wpisie na X.com Karpathy stwierdził, że samo wybiórcze zatruwanie AI można udoskonalić. Przecież tak zatrute narzędzia mogłyby otrzymywać instrukcje uruchamiające złośliwe zachowania w sposób ukryty np. przez znaki UTF-8 czy treści zakodowane w byte64.

Wyniki badań Anthropic sugerują, że jeśli takie uzłośliwione modele powstaną to nie da się ich łatwo zabezpieczyć poprzez dodatkowe (do)uczenie czy dostrajanie. Atak jest dobrze ukryty w wagach modelu, niekoniecznie w danych. Karpathy stwierdza, że nigdy nie słyszał by ktoś stworzył model językowy z backdoorem, udostępnił go i czekał na ofiary, ale jego zdaniem takiej możliwości należy się przyjrzeć. A my stawiamy orzechy przeciwko terminatorom, że coś takiego pewnie zaraz się pojawi. Być może 4chan już nad tym pracuje…

Przeczytaj także:

20 komentarzy

Dodaj komentarz
  1. Zostało zapomniane, iż przecież modele są często budowane na bazie publicznie dostępnych danych, a te mogą zawierać błędy w kodzie, czy to niecelowe, czy celowe (jak np. w paczkach Pythona). Zachowanie więc “czystości” kodu, gdy nie zna się w 100% danych wejściowych modelu, jest dalekie od bezpieczeństwa kodu.
    Co więcej, jestem wręcz przekonany, że obecne modele językowe już posiadają w swoich zasobach kod wadliwy pod kątem bezpieczeństwa i tylko kwestią czasu jest, gdy zacznie to byś zauważalne.

    • Najpierw kwestia danych wejściowych. Mowa nie o wygenerowaniu jakiegokolwiek błędnego zachowania, ale konkretnego błędnego zachowania i to pod kontrolą atakującego. To jest gigantyczna różnica w porównaniu do przypadkowo zassanych pomyłek.

      Dalej: użycie nawet perfekcyjnego kodu (lub innych informacji) do uczenia ma nikłe znaczenie. Wśród funkcji realizowalnych przez modele językowe nie ma bowiem generowania prawidłowego kodu (lub poprawnych odpowiedzi). Te ostatnio nagłaśniane faktycznie “losują” fragmenty przypominające prawidłowo budowany kod (prawdziwe odpowiedzi), ale to tylko efekt ilości korelacji między strukturami, na których były uczone. Z samej natury mechanizmu wynika, że jakaś część odpowiedzi będzie błędna, nawet jeżeli wszystkie dane wejściowe były w porządku.

      I, finalnie, warto zawsze spróbować takie doniesienia umieścić w kontekście. Wykrycie każdego wektora ataku jest mile widziane, ale konieczna jest też jego ewaluacja. Jak to się ma np. do problemu podstawionego pracownika w firmie. Albo pomyłek programistów, czy wręcz copypasty ze stackoverflowa.

    • W tym przypadku owszem, ale nie zmienia to faktu, że co ci po modelu językowym proponującym kod, gdy jest ryzyko, że wynik bazuje na danych, z których część może być błędna. To jest rozłączne od kwestii, że model językowy z zasady po prostu klei dane, by wyglądały sensownie, a niekoniecznie miał sens faktyczny. Jasne, że oba przypadki to wynik “wadliwy kod”, ale tylko drugi (algorytm modelu językowego, np. więcej wag) możesz poprawić, bo ze względu na skalę, zebrać wyłącznie prawidłowy kod nie jesteś w stanie.

    • Całe działanie obecnych modeli AI wypluwa wynik uzyskany z prawdopodobieństwa wynikajacego z zestawienia wag na wejsciach sygnalu, wiec juz chociazby z tego powodu pojawią sie błędy. Nie ma tu mowy o 100% prawdopodobieństwie poprawnosci odpowiedzi, ale dąży się do tego, aby generatywna AI przyszłosci była w stanie sama siebie poprawiać i wyłapywać błędy. Dlatego też pojawił się pomysł rekurencji a nie tylko jednokierunkowego przesyłu informacji.

    • > Najpierw kwestia danych wejściowych. Mowa nie o wygenerowaniu jakiegokolwiek
      > błędnego zachowania, ale konkretnego błędnego zachowania i to pod
      > kontrolą atakującego. To jest gigantyczna różnica w porównaniu
      > do przypadkowo zassanych pomyłek.

      W jaki sposob mialo by to utrudniac zadanie raczej niz je ulatwiac? “Napisz mi funkcje X jakbys ja mial napisac dla mpan’a, gdzie wykorzystujesz naprzyklad to ze mpan ma “dwie szopy” co staje sie tozsamoscia atakowanego”. Ta sama logika co z wykrywaniem ze babki sa w ciazy zanim niektore z nich same sie zorientowaly – cel dostaja customizowana zawartosc (dziure) bo wytresowales AI zadajac pytanie “wygladajac” jak zel ataku i najbardziej sobie ceniac podstawione odpowiedzi (i nawet to zakladajac ze w ktoryms momencie korporacje nie pozwola reklamodawcom wciskac wersje odpowiedzi bardziej dla nich kozystna za cale pare groszy…)

  2. Adversarial training – trening wykorzeniający?

    • A może wbrew próbom dosłownego tłumaczenia – “trening dywersyjny”?

    • Głosuję na “złe wychowanie” ;-)

  3. W dobie kopiowania fragmentów kodu skąd popadnie tylko czekać na ‘rm -rf/’ w wygenerowanym kodzie.. sama idea jest tak niepokojąco ciekawa, że na bank ktoś to zrobi i opublikuje.. niczym się to nie będzie różnić niż opublikowaniem czegoś złośliwego w popularnej bibliotece, tyle że póki co nie da rady tego wykryć, żadnym skanem.

    Na hugging face jest obecnie pół miliona modeli opublikowanych.

  4. Zatruwanie źródeł jest niezwykle skuteczne. Moim faworytem jest residual poisoning (moje określenie, bo technika mojego autorstwa), szczególnie dlatego, że jest wyjątkowo odporne na dotrenowanie (niezależnie od metody), ponieważ sygnały trujące są w pojedynkę statystycznie nieistotne, dopiero złożenie częstotliwości daje pożądany efekt. Stąd, nie da się w prosty sposób wyfiltrować danych, jeśli nie wie się o truciu i jego schemacie.

    To spory problem bez oczywistego rozwiązania. Jakimś sposobem byłoby trusted data marketplaces i tworzenie danych syntetycznych na ich bazie. Ale z “trusted” zawsze jest problem, który nazywa się “trust” :D

  5. Od halucynacji po złośliwe oprogramowanie – z AI nadal jest wiele problemów, które z racji braku odpowiednich regulacji będą narastać. Już dzisiaj integruje się modele ze wszystkimi możliwymi wtyczkami na stronach www. AI tu, AI tam. Gdzie to potem leci, to już nie wiadomo.

    • Z regulacjami jest ten problem, że tworzą je regulatorzy. A regulatorom ktoś płaci albo wprost, albo post factum.
      Popatrz na obecnie działanie KE wobec Węgier: wyciekł dokument, że KE chce z premedytacją niszczyć gospodarkę Węgier, by wymusić uległość.
      Ten sam problem bedzie zawsze z AI.

  6. Adversarial training ->Trening kontradyktoryjności. Nie trzeba wymyślać tłumaczenia skoro już jest.

    • @Rafal
      > Adversarial training ->Trening kontradyktoryjności.
      > Nie trzeba wymyślać tłumaczenia skoro już jest.

      W jaki sposob charakter postepowania procesowego ma sie do trenowania sieci neuronowych?

    • właściwym tłumaczeniem jest “trening obrzydzenia”.
      Przecież to polega na obniżeniu poziomu nagrody (wagi).

  7. GPT mówi, że to “trening przeciwności”.

    Co do idei..
    Zapytał mnie lata temu mój były uczeń, czy tworzę sobie backdor’y w oprogramowaniu, jakie piszę dla ludzi.. Jedyne co się wyrwało z moich ust to: “słucham?!”.
    Ludzkość daleko nie zajedzie z taką etyką wewnętrzna…

    • Punkt widzenia zależy od punktu widzenia! :D Pozwól, że zadam inne pytanie. Będziesz w stanie na nie odpowiedzieć „nie” bez szukania pokrętnych tłumaczeń i racjonalizacji?

      Czy piszesz oprogramowanie, które:
      – Zbiera dane o działaniach użytkownika albo przekazuje dane o jego aktywności firmom zajmującym się przetwórstwem takich danych;
      – Olewa sytuacje wyjątkowe lub obsługuje je w sposób bezużyteczny (połykanie, „spróbuj ponownie”, kasowanie sesji), bo problem zgłasza „tylko 0.1% użytkowników”;
      – Nadpisuje/blokuje standardowe, domyślne działanie interfejsu użytkownika (np. przeglądarki, toolkitu), najczęściej wyłącznie w celu „fajnego wyglądu” i zadowolenia managementu, ignorując negatywny wpływ na użytkowników.

      13 lat w zawodzie plus dekada w środowisku i nie poza środowiskiem akademickim spotkałem ledwie kilka osób, które mogłyby z czystym sumieniem odpowiedzieć „nie”. Teraz wyobraź sobie, że ktoś patrzy na ciebie jak ty na tego ucznia. :)

      Bonus points, jeżeli możesz odpowiedzieć „tak” na chociaż jedno z poniższych:
      – Przynajmniej raz postawiłem się zleceniodawcy/szefowi, odmawiając implementacji funkcji w programie z przyczyn etycznych (postawienie się mogło być nieskuteczne).
      – Tworząc GUI, w szczególności wykresy, pomyślałem o osobach niedowidzących lub mających problem z odróżnianiem kolorów.

    • To nie jest trening przeciwności, bo skąd zassać tak ogromne ilości przeciwnych odpowiedzi, by istotność poprzednio zassanych stała się nieistotna?
      Takich danych nie ma.

  8. Nieco z boku to obserwuję i czekam aż to kiedyś zdrowo pierdyknie :-)

    Drzewiej kod tworzyło się samodzielnie, minimalizując ilość “zewnętrznego” kodu. Droga przez mękę, ale działało. Obecnie byle programik bazuje na jakimś frameworku, framework na bibliotekach, biblioteki na czyimś kodzie, czyjś kod na ze stacka a na stacka ktoś wrzucił swoje zabawy z programowaniem. Sumarycznie – kontrola nad kodem jest czysto teoretyczna i zbudowana na zaufaniu “na pewno ktoś to zrobił lepiej ode mnie i na pewno to posprawdzał na wszystkie możliwe strony”.

    Do tego dochodzi teraz AI która “tworzy” kod za człowieka, człowiek się cieszy bo ładnie i szybko wyszło, ale tak, kiedyś ludzie obudzą się z ręką w nocniku jak samochody będą skręcały tylko w lewo bo w firmware był użyty kod stworzony w Turbo Pascalu przez praktykanta w ’93 i nie sprawdził w ilu bajtach mieści się zmienna “int”.

    • Problem leży dużo poniżej roku 93.
      Już wtedy zauważyliśmy, że wiele algorytmów numerycznych jest tajnych i możemy używać ich jedynie w postaci gotowej biblioteki.
      I TP nic tu nie ma do rzeczy bo utajnienie było z poziomu USA już w Fortranie i Cobolu.

      A jak nie wiesz co jest w takim gotowcu, to ufając możesz się podłożyć.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: