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.

Planeta – reaktywacja

Po nieco ponad kwartale od zatrzymania Planety Joggera, dojrzałem do jej przywrócenia. Nie jest to ta sama planeta, co wcześniej. Główna zmiana to silnik. Skręciłem w stronę o której pisałem czyli prosta planeta, gdzie będą tylko tytuły i daty wpisów. Może tekstowy fragment opisu, bez formatowania HTML.

Zmiana silnika spowodowała też parę zmian. Jest też kilka niedoróbek:

  • Lista blogów w stopce jest generowana dynamicznie. Tylko jeśli uda się pobrać feed, to blog się pojawi na liście źródeł. Wynika z pewnego uproszczenia działania po stronie silnika, może kiedyś zmienię. Albo może i nie zmienię, bo po co oszukiwać, że wpisy z danego źródła są pobierane, skoro nie są?
  • W przeciwieństwie do poprzedniej wersji nie są prezentowane pełne wpisy, a jedynie zajawki. Czyli wykorzystuję pole description z feedu. Powodów jest wiele, ale w sumie przy poprzedniej wersji była sugestia, żeby właśnie tylko zajawkę dawać i… wg mnie jest OK.
  • Nie będą pojawiały się obrazki/zdjęcia. Trochę jest to pokłosie punktu wyżej, a trochę ze względu na bezpieczeństwo.
  • Nie działa feed planety (choć jest linkowany). Nie zrobiłem na razie, ale będzie.

Z niewidocznych zmian: wylatuje kontener LXC, nie ma całego Planet Venus. Nie ma cache. Całość to obecnie jest jeden plik konfiguracyjny (YAML), dwa pliki template i jeden plik z kodem (Python). Uruchomić z crona, najlepiej z wykorzystaniem venv i… to wszystko. Działa szybciej. KISS

Jeśli chodzi o jak to jest zrobione, to silnik – albo raczej: silniczek – opublikuję wkrótce. Na razie przetestowałem działanie ręcznie, teraz uruchomiłem automatyczne odświeżanie z crona. Jeśli zauważycie błędy liczę na informację. Gdy wszystko będzie działało i dorobię generowanie feedu planety, wtedy publikacja kodu. Repo nanoplanet – chwilowo puste – już linkuję, żeby nie musieć aktualizować wpisu.

Dajcie znać jak się podoba i czy widzicie jakieś usterki.

abcc3.py

Wieki po projekciku, który robiłem w ramach projektu DSP2017, po którym chyba już nic w sieci nie zostało, doznałem natchnienia. Stwierdziłem, że teraz jest łatwo, można popytać LLMa, więc może łatwiej będzie znaleźć bibliotekę do ping pod Pythonem. Ostatnio opornie to szło…

Nie zawiodłem się, podał od ręki, wraz z kodem. Oczywiście przerobiłem, by bardziej pasowało. Przy okazji przy testowaniu (w zasadzie: testach uruchamiania) wynikło trochę błędów, które poprawiłem.

Po co to zrobiłem? Nie wiem. Chyba dla porządku. Drażnił mnie ten Python 2 w wymaganiach. A wyrzucić szkoda było. Chociaż raczej nikt nie używa. Choć IIRC ktoś się przymierzał, ale nie chciał poświęcić czasu, tylko „zrób mi”. Oczywiście za darmo. Trochę nie miałem czasu, weny i… to tak nie działa.

Warto po latach przypomnieć czym jest abcc? Na dzień dzisiejszy to rzeźbiarstwo figurowe – program do wybierania najlepszego łącza z kilku dostępny z wykorzystaniem zadanych wag, na podstawie strat i opóźnień. W sumie kiedyś, w czasach routerów na Linuksie miało to sens. Chociaż nic nie stoi na przeszkodzie by i dziś podpiąć dowolny skrypt i sterować np. przy pomocy SNMP routerem operatorskim. Istniało komercyjne rozwiązanie, które mniej więcej robiło to samo. Oczywiście z ładnym inferfejsem i opakowaniem.

Albo można użyć na jakimś OpenWrt do balansowania łącza czy też raczej wyboru lepszej ścieżki do danej sieci. Bez BGP, na podstawie wyżej wspomnianych metryk. Przy LTE itp. może być użyteczne.