@Koncereyra wylistowałem w drzewka pod json odwołania w pętli wnioskowania modeli odnośnie tych wzorków-pułapek w rozwinięciach zagnieżdżeń; dalej nie jest to poprawione (niszowy problem); Ale przynajmniej da się wykryć gdzie się gubi i wstecznie przeprowadza analizę jak już ustawię focus;
Wysypane są biasy - modele robią atak numeryczny i analityczny (math) odpalając sobie simpla z pytongiem i wychodzi im we wuchtę iteracji więc odcięcie. Na focus po jednostkach brakuje (niska waga, predyktor jest zwalony, pętla logiczna zaczyna od ataku analitycznego na cyferki zamiast po szkolnemu rozpisać wzorek, sprawdzić jednostki) i nawet w deep thinku wpada w tę pętlę (każdy model dokładnie tak samo) i się wykłada na króliczej norze cyferek.
Wygląda na bardzo gruby bias w samym treningu papugi. Selector i focus do ataku na problem jest z dupy.
Chodzi o to, że bias na ataki numeryczne jest kosmiczny (nie rzucę kamieniem pierwszy, bo rzeczywiście tak robimy w większości zagadnień; z lenistwa) i nie starcza wątku na inne ataki.
To znaczy, że model treningowy jest jaki jest, ale nie działa suwak z adaptacją ile wątków skierować na który atak. Bo ten suwak tam jest, tylko nigdy nie zdąży się odpalić. Predyktor jest zwalony na danych treningowych.
Dopiero jak się ręcznie rozgrzebie jsona z drzewkiem predykcyjnym i dropami wątków to można wymusić refocus i supresować rozgałęzienia - wtedy mu starcza i po kilku iteracjach (i tak próbuje skręcać w stronę ataku numerycznego) udaje się wyekstrahować ścieżkę, która wcale nie jest tak zagnieżdżona, po prostu z danych treningowych wynika bias, że na pewno to nie będzie takie proste.
Znaczy się… modele treningowe mają bias na podchwytliwe i przekombinowane pytania, a osłabioną zdolność do standardowej pracy przy rozwiązywaniu problemów.
w sensie podczas treningu? No to jest pewien meta-problem (tak mówił kolega co niby się zna, patrząc po jego pensji to zna się bardzo).
Wyobraźmy sobie że trenujemy model językowy tylko na poprawnym (w 80%) kodzie, na jakieś historii git repo. Wtedy nie potrzeba tryliona parametrów, dużo mniej wystarczy, a i tak najprawdopodobnie skończy się to overfittingiem. A to dopiero pierwszy problem. Drugi jest taki, że model wytrenowany na poprawnym kodzie najchętniej będzie się z tobą porozumiewał tym kodem. Czyli napisz mu prompta w ocamu a on to przeimplementuje do haskela. Rozwiazanie przydatne jakby cały dział sprzedaży składał się z samy matematyków. W sensie idea LLMów w programowaniu jest taka, że ty mu opisujesz problem po angielsku, a on to tłumaczy na precyzyjną abstrakcję języka programowania. Tzn model musi być wytrenowany nie tylko na source code ale i na dialogach humanoidów by zrozumieć cały kontekst języka naturalnego.
Więc trenujemy modele na dużych zbiorach danych prozy, a najchętniej na całym internecie. Tyle, że wtedy stosunek signal/noise jest naprawdę znikomy. Co nam daje jedną zaletę: model nie overfittuje, bo naprawdę ciężko jest overfittować do danych z sieci, które w większość są losowe. Tam się potem próbuje taki model korygować finetuningiem na poprawnych danych, ale to wtedy wracamy do początku tej historii: poprawnego kodu jest bardzo mało, łatwo go nauczyć się na pamięć
W teorii modele typu “reasoning” powinny być trenowane tak by bardziej wątpiły w swoje zdanie i same siebie wewnętrzne odpytywały. Co na razie przekłada się na niedeterministyczny i pionowy wzrost kosztów obsługi takiego modelu, przy niewielkiej poprawie wskaźników.
Na ten temat mam też dobrą historię. Potrzebowałem odczytać dane klimatyczne z Europy, format .nc/xarray (NetCDF najnowszy). Biblioteki były tylko pythona, ale poprosiłem LLM by zaimplementował taki reader w C# i Ocaml - nie ma szans. Spoko, poprosiłem o snippet w pythone: działa. Tyle że ja chce przekonwertować całe dane klimatyczne 1950-2025, a nie mały podzbiór. No i nie da się. Tzn naturalny flow jest: nc → xarray → dataframe → cleanup/filtering → aggegacja → dysk. Tyle że danych jest tak dużo, że potrzebowałbym tak 1TB RAM by to zrobić. Bo nc/xarray jest bardo wydajnie skompresowanym formatem, a dla omiany pandas.dataframe wprost przeciwnie.
No i mu mówię: mam mało ramu, za wolno działa zrób coś. Mieli mieli: tak samo.
Więc się wkurzyłem i sam zrobiłem to ratami robiąć xarray->cleanup->aggretate->dataframe->parquet. Na 64GB RAM zmieścił síę mały zbiór danych. Parę iteracji i przetworzyłem całość.
No i tłumacze LLMowi: zrób to tak, że wczytywaj dane po kawałku i zapisz na dysk po kawałku. LLM: ok ok, świetny pomysł. I co zrobił? to samo. Wczytuje wszystkie dane do dataframe, out of memory. Jak go jeszcze przycisnałem to robi lookup pojedynczych komórek w xarray i zrzuca na dysk. Tych komórek jest kilkaset milionów. Linear search. Ludzkość wyginie zanim to zrobi.
Dlaczego tak robi? Bo to jest poprawny model zachowania. Xarray jest nieefektywne w operacjach selekcji i agregacji a dataframe jest. Pewnie 99% kodu treningowego robi to tak. Nawet jak mu się palcem pokarze co ma robić robi źle.
Ale udało mi się nagiąć LLM do swojej woli. Po prostu ukryłem przed nim cel zadania. Kazałem mu krok po kroku implementować swoje rozwiązanie:
a) zrzuć dane z jednego roku. O jakie super rozwiązanie
b) zagreguj jest teraz i zapisz do pliku mistrz!
c) możesz zrobić to w pętli wow!
d) a teraz połącz pliki .parquet w jedno
Czułem się jak przysłowiowa blondynka co robi z siebie kretynkę po to by chłopak naprawił jej rower.
Tzn ostatecznie kod działa, ale LLM jest cały czas przekonany, że to jest zły kod;)
tak
wg mnie jest odwrotnie. Albo mówiąc precyzyjnie: modele mają bias na dane treningowe. Dane treningowe biorą się z problemów z którymi ludzie się męczyli. Takie problemy z natury są nieco przekombinowane.
Poza tym LLMy są mega leniwe i kłamią nałogowo (tzn mówią że coś zrobiły a widzę że plik jest nawet nietknięty)
Mógłby jeśli książka byłaby opowiednio krótka (2-3 strony). To kolejne problemy:
a) jak kontekst jest długi to trudno mu wyłuskać z niego wartościowe informacje
b) im dłużej LLM myśli/iteruje z użytkownikiem problem tym jest głupszy. Tzn odwrotnie niż ludzie (Repetitio est mater studiorum) LLMy najsprytniejsze są jak “robią to pierwszy raz”. Potem kontekst staje się za długi i zapominają co ważne a co nie.
Tak, takie objaśnienie problemu dostałem, że te dane wywołują overfitting w rozwiązywaniu problemów. Mają odwróconą krzywą po prawej - problemy proste (edu) i zaawansowane (publikacje scientologiczne/sience^^), po drodze jest co kot napłakał głownie do zdawania egzaminów.
Tak, i niszowe zagadnienia (prawy ogon) są z tego punktu widzenia szumem. I masz overfitting na atakach numerycznych, bo takich danych wielkie mnóstwo.
Przy czym piszemy o problemie czystej matmy - wzorek, fiza, podstawienia.
To model uczynił perfekcyjnie - miał wątpliwości (ze 40 gałęzi zebranych do kupy) czy ja dobrze stawiam pytanie, czy wzór jest poprawny, czy pytanie nie jest podchwytliwe, czy nie jest fałszywe. etc…
Tak, model musiałby gadać sam ze sobą. Wtedy odkrywa, że ma w predyktorze potencjalne infinite loop i porzuca gałąź.
Baczować^^
Wirtualny ram na hdd wchodzi
Bias - bo taki kod jest najpowszechniejszy w git i overflow
Czyli ma lewy ogon rozkładu jako najpowszechniej stosowany.
Jak mu wczytasz co już masz i że jest advanced to przesunie biasa, ale wtedy trafi na pustkę rozwiązań pośrednich.
Brawo! Z LLM jak z dzieckiem - okłamać to zrobi.
Tak. Opiekun do AI.
Bez znaczenia są opinie tostera. Muszyn swoje zrobił.
Albo edu, albo scjentologia. No właśnie…
A to tak, ale można mu wyrzucić drzewko na wierzch.
akurat w drzewku widać, że potrafi agregować cały akapit do pojedynczego abstraktu, pod spodem ma na przykład podsumowanie akapitu “user request: arraypooling; vec div (odchyłki od wektora abstraktu czyli kontekst)”;
Tak, bo zbacza w drzewkach na coraz powszechniejsze biasy, ale da się przywracać, jeśli po poprzednim drzewku mu zrobisz cofkę, refocus i poprowadzisz za łapkę, wtedy robi się bystrzejszy i mam mniej na outpucie, drzewka się skracają i ma więcej mocy przydzielone na właściwe zadanie; bo LLM w pamięci stara się przechować cały kontekst, więc w pewnym momencie zachowuje się jak człowiek powtarzający w pamięci długą liczbę, żeby nie zapomnieć i włazi z dziobem na drzewo - zaatakowało z Nienacka przesuwając trawnik na chodnik^^
Gamers Nexus opublikował niedawno spory (3h filmu!) dokument, z którego wynika że zakazy zakazami, a rynek nieoficjalny kwitnie. Karty nie tylko są hurtowo przerzucane nieoficjalnie, ale czajniki robią im nawet upgrade RAMu, więc sa lepsze niż te oficjalnie dostępne na zapadzie (wiadomo, to są karty bardziej giercowe niż stricte AI, ale zawsze)
Swoją drogą, rzadki przypadek dobrego dziennikarstwa.
Jak wynika z pisaniny powyżej - najważniejszy jest operator :>
Ściganie się na teraflopsy jest jak mierzenie gospodarki Pekabem
Nie. One nie bez powodu mają tyle ramu ile mają. Więcej nie znaczy, że karta jest lepsza. To nie o to chodzi w upgrade.
Nie. Po zmianie uops (sposobie przyporządkowania pamięci) to one się do gierczenia nadają tak na poziomie karty sprzed dekady.
Pmięć gpu jest porządkowana w dość specyficzny sposób - jest średnio dynamiczna (w porównaniu z RAM) i ma konstrukcję bufora. Po zmianie uopsów (kilku) są inne, dość sztywne przydziały pamięci na serializowane unsigned integer 8. W normalnym użyciu do giercowania masz zapas w buforze na signed float “16” (naprawdę to tak 15 bo przydział jest dynamiczny) “32” (prawda jest też nieco niżej) i ewentualnie na “64” (high precision). W buforze obrazu masz unsigned “float” pod bias podzielnika 256, a bufor tekstur (matrix) jest sztywny jak kij, i możesz najwyżej mu wydać długość (ile bitów ma brać ze sztywnych wyborów, max jest 4*32). Do tego masz kawałek pamięci na mat 3x3 i mat4x4 potrzebnych do serializacji. No i przy przerabianiu karty pod ejaja z przyczyn oczywistych mat i tex są na chama dociskane do minimum (bo i tak liczysz te rzeczy przez cuda), a reszta idzie po uint8 / 16 zależne do czegoi garść pozostałych na wskaźniki.
Niby to wszystko można sobie softem ustawiać przez cuda, ale ma ograniczenia (więc są one zmieniane) i do tego karty będą pracować w dość chamskich warunkach (na pełnej) więc za każdym razem jak się potok porwie to karta by próbowała wstawać z ustawieniami “safe” i przełączenie jej w tryb pracy wymagałoby długiej (względem oczekiwań) komunikacji z cpu “za jakie zwierzę mam się przebrać?”.
Samo wstawanie karty i robienie tam porządków w runtime to jest skaranie jeśli chodzi o czas. Więc niech już ona sobie wstaje zawsze gotowa do procesu i nic tam nie zmieniać
To jest przemysłowe zastosowanie karty do czegoś innego niż normalnie w domu.
Do gier ilość RAMu nie ma szczególnego znaczenia - tekstury i tak lecą po atlasie i swapach z okazjonalnym flushem na przeczyszczenie. Więc jeden rdzeń se cały czas gada z kartą w sprawie co tam wykreślić krok po kroku z tablic, i czym nadpisać tak żeby klocki nie zmieniały rozmiarów i pozycji (czyli brak resizingu). A do wierzchołków to z reguły ustawiana jest serializacja froze/destroy bo się tego nie zmienia w locie. Łatwiej jest przekształcić output z danego vertex buffera, więc większość aplikacji 2d jedzie na jednym używanym do czego popadnie po przekształceniu. No i masz jeszcze surface aplikacji i pozostałe surface - w gierkach potrzebne krytycznie, w ejaju - na wuj to w ogóle dali? Przecież karta się nie komunikuje w tę stronę przy tej robocie
No to wyślę kalkulator na pole minowe, jak na BOFHa przystało. Jak pomyślałem tak zrobiłem.
Założyłem grube rękawice żeby się jakim syfem nie zarazić i zapytałem ową nadzieję ludzkości o funkcję uuid_to_bin() w bazie danych maria DB.
Odpowiedzi ejaja:
The UUID_TO_BIN function in MariaDB converts a UUID string into a binary format, which is more efficient for storage and indexing. This function is particularly useful for improving performance when working with UUIDs in large databases.
oraz
The UUID_TO_BIN function is available in MariaDB starting from version 10.0 and is also compatible with MySQL 8.0 and later versions.
Rzeczywistość wygląda zdeczka inaczej:
zaledwie 7 lat temu pojawiła się prośba o (m. in.) zaimplementowanie funkcji uuid_to_bin() w marii DB. Ostatni komentarz w tickecie brzmi:
It’s not exactly clear whether we want this.
i pochodzi z marca tego roku. Ostatnia stabilna wersja marii db to aktualnie 12.2.0, funkcja “uuid_to_bin” nie jest w niej zaimplementowana.
idi w choj z takim ejajem. Nie zna się & kłamie jak polityk: wystarczy że dzioba otworzy.
Co z resztą doskonale opisuje co AI umie: Umie czytać i streścić tekst ze zrozumieniem (czyli więcej niż 80% absolwentów szkół:))
Bo to trochę prawda. W techu panowało przynajmniej od 2020 strukturalne nadzadrudnienie, bo sie wszyscy spodziewali niewiadomo jakich wzrostów. AI daje pretekst (a nie powód!) do redukcji zatrudnienia i oczekiwań. Plus pęknięcie bańki zmusi do optymalizacji kosztów. Więc owszem skutek będzie taki jak mówią, ale będzie to wyglądać zupełnie inaczej (w sumie jak z komunizmem:))
Jeden z powyższych stanów logicznych jest fałszywy.
Kot Schrödingera wprowadza do logiki Boole’a szum czyniący logikę Boole’a bezużyteczną. Uwalenie logiki Boole’a przez tzw. ejaja w jego dzisiejszej wersji cofa nas technologicznie do czasów sprzed pierwszej maszyny parowej bo jej zawory w najprymitywniejszej wersji też opierają się o pozycje “zamknięty” i “otwarty”. Które to pozycje są rozłączne.
Albo zbiory zaworów otwartych oraz zaworów zamkniętych pozostaną rozłączne albo wracamy do wyciągania wody ze studni wiadrem.
Czyli należy trzymać tego kota od logiki Boole’a i zbudowanego na niej świata z daleka.
Działająca AI bierze jeden, marginalny, zagrzebany w ticketsystemie u producenta bazy danych wpis dotyczący stanu implementacji funkcji (najpierw rozpoznając że akurat ta strona internetowa jest ticketsystemem u producenta kodu źródłowego bazy danych) czyli przydaje komentarzowi w tickecie wagę “godmode” po czym na podstawie ustawionej wagi “godmode” uwala pierwszą połowę odpowiedzi z paragrafu “internet pieprzy bo internet się nie zna”.
I to jest warunek konieczny żeby ejaja w jego dzisiejszej implementacji zacząć traktować poważnie. Jak ejej opanuje logikę Boole’a możemy rozmawiać dalej. Inaczej nawet do ciągnięcia wody ze studni się ten ejaj nie nadaje bo jak ma podjąć decyzję czy wiadro wyciągać tzn czy woda w wiadrze jest ? Internet raz stwierdzi że tak, potem że nie.
Ale AI tego nie wie. Wie że widzi w internecie dwa artykuły. Jeden mówi że UUID_TO_BIN jest a drugi że UUID_TO_BIN nie ma. I streszcza oba. Może nawet wysnuć konkluzje że “nie ma wystarczającej informacji”. I tyle. Nie wie jak jest naprawdę, bo jedyne co widzi to artykuły w internecie.
W ograniczonym stopniu można dodać empiryczny feedback loop do werifikacji tez. Ale nie jest to takie proste do zaimplementowania. W sensie ten scenariusz jest do zrobienia, ale przynajmniej na razie jest tool-by-tool basis:
Ale to bez problemu można mu przykazać, tylko co z tego. Problemem nie jest błędne myślenie ale upośledzone receptory:
No własnie, więc próbujemy to obejść implementując jakieś efektory typu pętla zwrotna z kompilatorem. Testowałem to z GitHub Copilot i językami Pony/Zig (które są w wíększości nowe). I AI napisał kod który nie działał. Ale miał wbudowaną pętle z CLI, więc próbował próbował, zaczął czytać kod stdlib i w końcu za jakiś czas się zorienotwał i naprawił (to akurat był prosty kejs). No ale było to możliwe, bo ktoś zrobił link do CLI z jednej a z drugiej kompilator i biblioteka były dostępne ze źródeł
