Instrukcje były niejasne

Czasem na LinkedIn, z którego coraz mniej korzystam, pojawi się ciekawa dyskusja[1]. Zaczęło się od LLMów i stwierdzenia, że AI nie umie dotrzymać tajemnicy, każdy model LLM w końcu ujawni coś, czego nie powinien. Trochę wzięło mnie na filozofowanie i szukanie analogii, efektem jest myśl, którą parę osób uznało za trafną/interesującą, więc, żeby nie zginęła, niech będzie i tu.

Generalnie większość ludzi jest zgodna, że faktycznie tak jest i LLMy „ciekną” sekrety. Trochę zeszło na no ale tu wyraźne instrukcje były, żeby tego nie robił. Czyli klasyczne, że nie LLMy się nie nadają do danego zastosowania, tylko, a może zły prompt, a może zły model, a może tory złe…

Widzę to nieco inaczej, a różnica jest fundamentalna. Podobnie jak w LLMy nie kłamią trzeba przestać traktować LLMy jak maszyny deterministyczn czy myślące. W zamian trzeba cały czas pamiętać, że pod spodem jest to jednak złożony, ale proces stochastyczny.

Dlatego instrukcje, które dajemy LLMom nie są przepisem na ciasto, który zostanie odtworzony przez człowieka. Nie są algorytmem/programem, który zostanie wykonany precyzyjnie w określony, zawsze taki sam sposób, jak ma to miejsce w tradycyjnych programach. Czyli nie są dla „odbiorcy”, czyli modelu LLM ścisłą instrukcją, choć wydaje nam się, że są.

Czym zatem są? Wydaje mi się, że najbliższą analogią, którą znamy z życia są… przykazania religijne. Wg twórcy są precyzyjne, nie ma problemu z ich przestrzeganiem i powinny być przestrzegane. W praktyce jest z tym różnie. Mogą być różnie zrozumiane, zinterpretowane, czy wreszcie po prostu zignorowane. Nawet jeśli większość wyznawców ich przestrzega, to znajdą się przypadki, gdy nie są przestrzegane. Analogicznie zachowują się LLMy. Co któreś uruchomienie, w odpowiednich okolicznościach, znajdzie się taka instancja LLMa, która „złamie”[2] otrzymane instrukcje. I według mnie należy to po prostu przyjąć jako cechę rozwiązań opartych o LLMy.

[1] Bo ważne jest, z kim się rozmawia, nie gdzie.
[2] Cudzysłów, bo złamanie oznaczałoby konieczność zrozumienia, co nie zachodzi.

LLMy nie kłamią

Sztuczna inteligencja, skrótowo zwana AI wciska się ostatnio wszędzie, czy sens jest, czy go nie ma. Tak naprawdę zaczęliśmy ostatnio określać tym mianem głównie LLMy, ale nie zawsze tak było. Ktoś pamięta takie rzeczy jak algorytmy genetyczne? Niemniej, obecnie jeśli ktoś mówi o AI, to najprawdopodobniej chodzi mu o LLM.

W każdym razie, jak bumerang w wypowiedziach powraca temat „uczłowieczania” AI. Często słyszymy zwrotu typu AI kłamie, AI się myli czy AI rozumie polecenia. Ostatnio spotkałem się z bardzo ciekawym moim zdaniem stanowiskiem, że LLMy nie mogą kłamać. Teraz pewnie wszyscy starają się przypomnieć sobie ostatni niezaprzeczalny dowód na kłamstwo LLMa. Jednak tak naprawdę chodzi o coś innego, niż błędna, niezgodna ze stanem faktycznym odpowiedź. Kwestia jest bardziej filozoficzna. Żeby kłamać, AI musiałoby wiedzieć, co jest prawdą i świadomie udzielić innej odpowiedzi. I podejście takie bardzo mi się podoba.

Tymczasem LLM nie wie, co to jest prawda, nie myśli, nie rozumie pytania. Na podstawie dostarczonych wcześniej danych, na których został wytrenowany, generuje tekst, który ma pasować do zadanego pytania. Czyli: weź wprowadzony tekst, przetwórz go na dane wejściowe, których umiesz używać. Następnie wygeneruj pasującą odpowiedź w swoich danych/języku, przetwórz ją na tekst. Tak w skrócie, bo jest jeszcze prompt, który – podobnie jak pytanie – jest danymi wejściowymi i potrafi wpływać na wynik. Ale znowu, nie w formie rozumienia go przez AI tak, jak my rozumiemy rozumienie. No i AI nie działa deterministycznie. Nawet, jeśli zwykle daje dość powtarzalne (najbardziej prawdopodobne) wyniki.

Łatwiej to wszystko chyba zrozumieć ludziom, którzy bawili się algorytmami genetycznymi czy łańcuchami Markowa tak z ćwierć wieku temu. A niestety odruchowo łatwo jest przypisywać cechy ludzkie czemuś, co zachowuje się podobnie do człowieka[1]. Nawet, jeśli zasada działania jest zupełnie inna.

Dlatego następnym razem, zamiast powiedzieć: LLM kłamie lepiej rzec LLM wygenerował odpowiedź, która nie ma pokrycia w rzeczywistości. Ale nie mam złudzeń, nikt tak mówić nie będzie. Lubimy uproszczenia.

[1] Pewnie nawet można pokusić się o twierdzenie, że mamy – jako gatunek – tendencję do zrównywania komunikacji z myśleniem czy inteligencją. Podobno często niesłyszący traktowani są jako upośledzeni intelektualnie. Przy LLMach byłoby odwrotnie: składa zdania, znaczy myśli.

Guetzli – lepsza kompresja JPEG

Przedwczoraj Google ogłosiło na blogu nowe narzędzie do kompresji JPEG o nazwie Guetzli, wydawane na wolnej licencji (Apache License). Ma dawać lepsze optycznie rezultaty przy mniejszym rozmiarze wynikowym (mowa nawet o 35% mniejszych plikach). Cena? Oczywiście czas kompresji.

Postanowiłem przetestować na szybko, co mogło by się zmienić, gdybym wykorzystał grafiki skompresowane przy pomocy Guetzli na blogu. W tym celu sięgnąłem po obrazki z backupu bloga i uruchomiłem program (domyślne opcje kompilacji, domyślne ustawienia jakości, czyli 90%) na moim laptopie (CPU: Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz). Zdziwiło mnie to, że aż przy 12 plikach nie udało się ukończyć działania – program zgłosił błąd:

Invalid input JPEG fileGuetzli processing failed

Udało się przetworzyć 66 plików, całość trwała prawie 17 minut (sic!). Czyli jest bardzo wolno. Kompresor wykorzystywał tylko jeden rdzeń CPU. Efekty są obiecujące, zarówno wizualne, jaki i objętościowe. Mimo, że algorytm jest zaprojektowany z myślą o działaniu na możliwie nieprzetworzonych obrazach wejściowych, a te na blogu raczej są już zoptymalizowane, to łączny rozmiar udało się zmniejszyć o 14% (z ok. 3,3 MB do ok. 2,8 MB).

Jeśli wezmą się za wykorzystanie i optymalizację duże firmy, a jest na to szansa po uwolnieniu programu, może to oznaczać mniej przesyłanych danych po sieci, czyli szybsze ładowanie się stron, widoczne zwłaszcza na komórkach. Chwilowo główną barierą jest czas działania, który wygląda na zależny bezpośrednio od wielkości pliku wejściowego.

Zrobiłem jeszcze jeden test – plik JPG bezpośrednio z aparatu, rozmiar 2560×1440, rozmiar wejściowy 1,2 MB. Po kompresji (trwającej kilka minut) brak zauważalnych zmian jakości, natomiast rozmiar zmniejszony aż o 50% (614 kB).