Dobry post od @balajis na temat "luki weryfikacyjnej". Można to postrzegać jako dwa tryby tworzenia. Zapożyczenie terminologii GAN: 1) wytwarzanie i 2) Dyskryminacja. Np. malowanie - wykonujesz pociągnięcie pędzlem (1), a następnie przez chwilę patrzysz, czy poprawiłeś obraz (2). Te dwa etapy przeplatają się praktycznie we wszystkich pracach twórczych. Punkt drugi. Dyskryminacja może być bardzo trudna obliczeniowo. - Obrazy są zdecydowanie najłatwiejsze. Na przykład zespoły zajmujące się generowaniem obrazów mogą tworzyć gigantyczne siatki wyników, aby zdecydować, czy jeden obraz jest lepszy od drugiego. dziękuję gigantycznemu procesorowi graficznemu w twoim mózgu, zbudowanemu do bardzo szybkiego przetwarzania obrazów. - Tekst jest znacznie trudniejszy. Jest to skimbagble, ale trzeba czytać, jest semantyczne, dyskretne i precyzyjne, więc trzeba też rozumować (zwłaszcza w kodzie). - Audio jest może jeszcze trudniejsze IMO, bo wymusza oś czasu, więc nie da się go nawet skimmować. Jesteś zmuszony do wydawania obliczeń szeregowych i nie możesz ich w ogóle zrównoleglić. Można powiedzieć, że w kodowaniu LLM zwinęły się (1) do ~instant, ale zrobiły bardzo niewiele, aby rozwiązać (2). Człowiek nadal musi wpatrywać się w wyniki i rozróżniać, czy są one dobre. Jest to moja główna krytyka kodowania LLM, ponieważ od niechcenia wypluwają *znacznie* za dużo kodu na zapytanie o dowolnej złożoności, udając, że nie ma etapu 2. Pobieranie takiej ilości kodu jest złe i przerażające. Zamiast tego LLM musi aktywnie współpracować z Tobą, aby podzielić problemy na małe kroki przyrostowe, z których każdy jest łatwiejszy do zweryfikowania. Musi przewidywać pracę obliczeniową (2) i redukować ją tak bardzo, jak to możliwe. Musi naprawdę dbać. To prowadzi mnie do prawdopodobnie największego nieporozumienia, jakie mają nie-programiści na temat kodowania. Uważają, że kodowanie polega na pisaniu kodu (1). Nie jest. Chodzi o wpatrywanie się w kod (2). Wczytywanie tego wszystkiego do pamięci roboczej. Chodzenie tam i z powrotem. Przemyślenie wszystkich skrajnych przypadków. Jeśli złapiesz mnie w losowym momencie, gdy "programuję", prawdopodobnie po prostu wpatruję się w ekran i, jeśli ktoś mi przerwie, naprawdę się wściekam, ponieważ jest to tak męczące obliczeniowo. Jeśli uzyskamy tylko znacznie szybsze 1, ale nie zmniejszymy również 2 (co zdarza się w większości przypadków!), to oczywiście ogólna szybkość kodowania nie poprawi się (patrz prawo Amdahla).