Transkrypcja: Dlaczego duże modele językowe nie mogą naprawdę budować oprogramowania Autor: Conrad Irwin Spędziłem dużo czasu na przeprowadzaniu rozmów kwalifikacyjnych z inżynierami oprogramowania. To oczywiście trudne zadanie, nie mogę powiedzieć, że mam na to jakąś tajną metodę; ale to doświadczenie dało mi czas na refleksję nad tym, co naprawdę robi efektywny inżynier oprogramowania. Podstawowa pętla inżynierii oprogramowania Kiedy obserwujesz prawdziwego fachowca, zauważysz, że zawsze wykonuje następujące kroki w pętli: * Buduje mentalny model wymagań. * Pisze (miejmy nadzieję?!) kod, który spełnia te wymagania. * Buduje mentalny model rzeczywistego zachowania kodu. * Odkrywa różnice między tymi dwoma modelami, a następnie aktualizuje kod (lub wymagania). Istnieje wiele sposobów na wykonanie tych kroków, ale wyjątkowość efektywnych inżynierów polega na tym, że potrafią budować i utrzymywać jasne mentalne modele. Jak radzą sobie duże modele językowe? Szczerze mówiąc, duże modele językowe są całkiem dobre w pisaniu kodu. Kiedy wskazujesz problem, dobrze radzą sobie z aktualizowaniem kodu. Potrafią robić wszystko, co robią prawdziwi inżynierowie: czytać kod, pisać i uruchamiać testy, dodawać logi oraz (prawdopodobnie) korzystać z debuggera. Jednak nie potrafią utrzymać jasnego mentalnego modelu. Duże modele językowe wpadają w niekończące się zamieszanie: zakładają, że kod, który napisały, naprawdę działa; gdy testy zawodzą, mogą tylko zgadywać, czy powinny naprawić kod, czy test; gdy czują frustrację, po prostu usuwają wszystko i zaczynają od nowa. To jest dokładnie przeciwieństwo cech, których oczekuję od inżyniera. Inżynierowie oprogramowania testują podczas pracy. Gdy testy zawodzą, mogą porównać swoje mentalne modele, aby zdecydować, czy naprawić kod, czy test, lub zebrać więcej informacji przed podjęciem decyzji. Gdy czują frustrację, mogą szukać pomocy, rozmawiając z innymi. Chociaż czasami również usuwają wszystko i zaczynają od nowa, robią to dopiero po uzyskaniu jaśniejszego zrozumienia problemu. Ale to szybko się zmieni, prawda? Czy sytuacja zmieni się, gdy modele będą coraz silniejsze? Może tak?? Ale myślę, że wymagałoby to fundamentalnej zmiany w sposobie budowania i optymalizacji modeli. Model, którego potrzebuje inżynieria oprogramowania, to coś więcej niż tylko generowanie kodu. Kiedy człowiek napotyka problem, potrafi tymczasowo odłożyć cały kontekst na bok, skupić się na rozwiązaniu bieżącego problemu, a następnie wrócić do wcześniejszych myśli i większego problemu. Potrafią również swobodnie przełączać się między makro a mikro perspektywą, tymczasowo ignorując szczegóły, aby skupić się na całości, a w razie potrzeby zagłębiając się w detale. Nie staniemy się bardziej efektywni tylko dlatego, że wpychamy więcej słów do naszego "okna kontekstowego"; to tylko doprowadzi nas do szaleństwa. Nawet jeśli potrafimy radzić sobie z ogromnym kontekstem, wiemy, że obecne modele generatywne mają kilka poważnych problemów, które bezpośrednio wpływają na ich zdolność do utrzymania jasnych mentalnych modeli: * Pominięcie kontekstu: modele nie radzą sobie z odkrywaniem pominiętych informacji kontekstowych. * Bias nowości: mają poważny problem z biasem nowości podczas przetwarzania okna kontekstowego. * Halucynacje: często "halucynują" szczegóły, które nie powinny istnieć. Te problemy mogą nie być nie do pokonania, a badacze pracują nad dodaniem pamięci do modeli, aby mogły stosować podobne techniki myślenia jak my. Niestety, na chwilę obecną (po przekroczeniu pewnej złożoności) nie są w stanie zrozumieć, co się dzieje. Nie potrafią budować oprogramowania, ponieważ nie mogą jednocześnie utrzymać dwóch podobnych "mentalnych modeli", znaleźć różnice między nimi i zdecydować, czy zaktualizować kod, czy wymagania. Co teraz zrobić? Oczywiście, duże modele językowe są bardzo przydatne dla inżynierów oprogramowania. Potrafią szybko generować kod i doskonale radzą sobie z integrowaniem wymagań i dokumentacji. Dla niektórych zadań to już wystarczy: wymagania są wystarczająco jasne, a problem wystarczająco prosty, aby mogły to zrobić za jednym razem. Mówiąc to, w przypadku jakiegokolwiek zadania o pewnym stopniu złożoności, nie potrafią wystarczająco precyzyjnie utrzymać wystarczającego kontekstu, aby poprzez iterację ostatecznie wyprodukować wykonalne rozwiązanie. Ty, jako inżynier oprogramowania, nadal musisz być odpowiedzialny za zapewnienie jasności wymagań i upewnienie się, że kod rzeczywiście realizuje deklarowane funkcje. W Zed wierzymy, że w przyszłości ludzie i inteligencje AI mogą współpracować w budowaniu oprogramowania. Jednak jesteśmy przekonani (przynajmniej na chwilę obecną), że to ty jesteś kierowcą trzymającym kierownicę, a duże modele językowe to tylko kolejne narzędzie w twoim zasięgu.