Recurencyjne samodoskonalenie w agentach AI: co pokazują eksperymenty
Uważne przyjrzenie się maszynom Gödla, STOP, agentom Gödla, SICA, maszynie Gödla Darwina, SEAL i hyperagentom oraz sposobom oceny, czy agent samodzielnie modyfikujący się rzeczywiście się poprawia.
Źródła: Can Artificial Intelligence Design a Better Artificial Intelligence?
Zlecanie agencji programistycznej naprawy błędu w aplikacji stało się już czymś rutynowym: otwiera ona pliki, edytuje kilka wierszy i uruchamia zestaw testów. Jeśli zamiast tego polecimy jej „ulepszyć oprogramowanie, którego używa do wykonywania tej pracy”, celem staje się sama agencja – sposób, w jaki znajduje pliki, jakie narzędzia wykorzystuje, jak radzi sobie z nieudanymi próbami oraz czy powstała wersja może doprowadzić do dalszych ulepszeń. To właśnie dotyczy rekurencyjnego samoulepszania się (RSI). Ten artykuł odróżnia samomodyfikację od rzeczywistego samoulepszania, omawia główne eksperymenty i ich wyniki oraz dostarcza zestaw pytań oraz prosty schemat eksperymentu, który pozwoli Ci samodzielnie ocenić takie twierdzenia.
Samomodyfikacja, samoulepszanie i rekurencja
Zachęcanie modelu do ponownej weryfikacji swojej odpowiedzi może przynieść lepszą odpowiedź, ale nie czyni to modelu bardziej zdolnym do wykonywania kolejnych zadań. Zmienił się tylko ten jeden wynik. Aby jasno rozumieć RSI, trzeba odróżnić trzy poziomy:
- Samozmiana: jakaś część systemu ulega zmianie.
- Samoudoskonalenie: ta zmiana przynosi mierzalną korzyść.
- Recyrkulacyjne samoudoskonalenie: nowa zdolność wzmacnia właśnie te mechanizmy, które zapewniają dalsze ulepszenia.
Pomaga konkretny przykład. Jeśli agent lepiej radzi sobie z wyszukiwaniem plików, łatwiej kończy zadania; to jest samoudoskonalenie. Jeśli ta lepsza umiejętność wyszukiwania pomaga mu również zrozumieć własną bazę kodu, co sprawia, że lepiej potrafi edytować swój kod, to korzyść wraca do procesu udoskonalania; to jest element recyrkulacyjny.
Ważne jest również to, na co odnosi się „samego siebie”. Rozwijany system AI rzadko jest tylko modelem językowym. Model ten znajduje się wewnątrz narzędzi, pamięci, instrukcji operacyjnych oraz kodu orkiestracji, a otaczający go system może się znacznie zmieniać, podczas gdy wagi pozostają niezmienne. Ewolucja w tej zewnętrznej warstwie to nadal ewolucja, ale każde twierdzenie o samodoskonaleniu powinno wskazać, która warstwa uległa zmianie: wagi, kod agenta, polecenia, narzędzia czy sama procedura doskonalenia.
Maшина Gödla: udowodnij korzyść przed zmianą
Maшина Gödla, zaproponowana przez Jürgena Schmidhubera, stanowi klasyczne matematyczne ujęcie tego problemu. System może przepisać dowolną część swojego oprogramowania, włączając komponent odpowiedzialny za wyszukiwanie dowodów, ale tylko po tym, jak udowodni, że taka modyfikacja zwiększa oczekiwaną użyteczność zgodnie z jego zdefiniowanymi celami i założeniami.
To gwarancja jest węższa, niż się wydaje. Nie obiecuje ona, że każda zmiana przyniesie korzyść w rzeczywistym świecie przy każdych warunkach; obowiązuje jedynie w odniesieniu do wybranych aksjomatów, modelu środowiska oraz definicji użyteczności. Znalezienie formalnego dowodu na to, że dana modyfikacja jest korzystna, może również być bardzo trudne pod względem obliczeniowym.
Dlatego większość aktualnych eksperymentów obiera drogę empiryczną: zamiast z góry udowadniać, że zmiana jest korzystna, uruchamiają zmodyfikowany system i mierzą jego wydajność. To o wiele bardziej praktyczne, ale przenosi ciężar na proces oceny. Oczywistym pytaniem następnym jest to, czy to, co jest mierzone, faktycznie stanowi ten rodzaj rozwoju, który nas interesuje.
STOP: stosowanie ulepszacza na samym sobie
Samouczkowy optymalizator (STOP) wychodzi od „ulepszacza” – programu, który wykorzystuje model językowy do proponowania i oceniania ulepszeń w innych programach. Następnie „ulepszacz” jest skierowany na swój własny kod źródłowy, a zaktualizowana wersja jest używana w kolejnej rundzie w celu wprowadzenia dalszych ulepszeń.
Warto zauważyć, że pętla nie zachowuje się tak samo w różnych modelach. W przypadku GPT-4 średnia wydajność rosła z każdą iteracją, natomiast w przypadku GPT-3.5 i Mixtral spadała. Ponieważ podstawowy model językowy nigdy się nie zmienia, autorzy wyraźnie podkreślają, że ich praca nie stanowi pełnego RSI.
Lekcja dla praktyków jest prosta: iterowanie procesu nie gwarantuje postępu. Słaba metoda ulepszeń zastosowana do samego siebie może równie łatwo wzmacniać własne błędy przy każdej próbie.
Agent Gödel: przepisywanie własnej logiki agenta
Gödel Agent umożliwia modelowi językowemu modyfikację własnej logiki rozumowania oraz kodu zachowań agenta w trakcie wykonywania zadań. Jego skuteczność oceniana jest pod kątem rozumienia tekstu, matematyki oraz odpowiadania na pytania oparte na wiedzy; optymalizacja przeprowadzana jest na zbiorze walidacyjnym, a efektywność agenta mierzona na oddzielnym zbiorze testowym, co stanowi właściwy sposób uniknięcia dostosowywania się wyłącznie do warunków testu.
Liczby przedstawione w nagłówkach wymagają uważnego przeczytania, ponieważ różne warianty działają w odmiennych warunkach. W przypadku MGSM Meta Agent Search osiąga dokładność 53,4%, natomiast ograniczona wersja oparta na Gödelu – 64,2%, co stanowi porównanie równorzędnych warunków. Wersja nieograniczona, pozbawiona Gödela, osiąga 90,6%, lecz działa przy innych ograniczeniach i nie powinna być przedstawiana jako kolejny krok w tym samym porównaniu.
Technicznie najbardziej uderzająca nie jest tyle ocena, co wybór projektowy: metoda, której używa agent do rozwiązywania problemów, sama stała się oprogramowaniem, które można przeszukiwać i modyfikować.
SICA: agent kodujący, który edytuje własną bazę kodu
Self-Improving Coding Agent (SICA) konkretyzuje to pytanie. Agent modyfikuje swój własny kod, a każda nowa wersja jest oceniana pod kątem efektywności rozwiązywania zadań, czasu potrzebnego oraz kosztów.
W przypadku 50 losowo wybranych zadań, pozostawionych niezmienionymi z bazy SWE-bench Verified, wydajność wzrosła z 17% w pierwszej iteracji do maksimum 53% w 14. iteracji, a w ostatniej iteracji wyniosła 51%. Innymi słowy, poprawa nie była monotoniczna. Autorzy szacują, że 15 iteracji kosztowało około 7 000 dolarów ze względu na korzystanie z API.
Dwa czynniki wpływają na ocenę tego wyniku. Po pierwsze, autorzy wskazują, że pięciominutowy limit na zadanie mógł obniżyć początkową ocenę, a większość wczesnych ulepszeń wynikała z szybszych narzędzi do edycji plików, które umożliwiały agentowi ukończenie większej ilości pracy w ramach tego samego limitu. Po drugie, ulepszenia odkryte przez agenta przypominają zwykłe prace związane z narzędziami: precyzyjne operacje edycji zamiast przepisywania całych plików oraz znajdowanie funkcji i klas poprzez przeglądanie drzewa składniowego kodu zamiast wyszukiwania w tekście prostym.
Żadne z tych czynników nie sprawia, że wynik jest błahy, ale wzrost od 17% do 53% nie oznacza, że ogólna inteligencja systemu niemal potroiła się. Zmierzono wydajność w ramach jednego konkretnego zestawu zadań, przy jednym limicie czasowym, a większość tych ulepszeń to dokładnie to, co inżynier ludzki dodałby do zestawu narzędzi agenta programistycznego.
Maszyna Darwin Gödel: archiwum zamiast pojedynczej linijki
Maquina Darwin Gödel (DGM) odrzuca koncepcję pojedynczej łańcuchowej sekwencji wersji. Przechowuje archiwum wariantów agenta i umożliwia powstawanie nowych gałęzi z dowolnego z nich. Wariant, który obecnie uzyskuje niższe wyniki, może nadal być prekursorem późniejszej, bardziej przydatnej modyfikacji – to właśnie ten element otwartego rozwoju znajduje odzwierciedlenie w nazwie.
Zgodnie z artykułem wersji 3, odnotowane korzyści obejmują wzrost wyników odcinka SWE-bench z 20% na 50% oraz odcinka Polyglot w pełnej wersji z 14,2% na 30,7%. Badanie przeprowadza również eksperymenty przenoszenia wiedzy z innymi modelami i testami, których nie użyto podczas rozwoju. Wskazują one, że część tych korzyści ma zastosowanie poza zadaniami rozwojowymi, choć nie udaje im się wykazać powszechnego poprawienia we wszystkich dziedzinach. Podobnie jak w przypadku innych prac na poziomie agentów, modele podstawowe pozostają nieruchome; ewoluuje jedynie oprogramowanie agenta działające wokół nich.
Koszt również odgrywa ważną rolę. Autorzy szacują, że jedna runda DGM na SWE-bench kosztuje około 22 000 dolarów, podczas gdy każda runda bazowa kosztuje około 10 000 dolarów. Dlatego też eksperymenty izolujące wpływ poszczególnych komponentów nie dają pełnej odpowiedzi na to, czy DGM nadal wygrałby przy równym budżecie.
Najważniejszą wskazówką, którą można przenieść na inne przypadki, jest strategia poszukiwań: odrzucanie każdej wersji, która wygląda na regresję, może odciąć drogę do lepszego systemu, ponieważ dobre rozwiązania czasami przechodzą przez słabsze etapy pośrednie.
Gdy zmieniają się wagi lub narzędzie doskonalące
Eksperymenty z kodami agentów to nie całe to pole badań. SEAL (Self-Adapting Language Models) analizuje model, który sam generuje dane do drobnej optymalizacji oraz instrukcje aktualizacyjne, w tym wytyczne dotyczące sposobu przeprowadzenia adaptacji. Szkolenie na podstawie tych samogenerowanych instrukcji powoduje trwałe zmiany w wagach modelu, więc badania nad samodoskonaleniem wyraźnie nie ograniczają się tylko do budowy struktury agentów. Mimo to sama zmiana wag nic nie mówi o możliwościach nieograniczonych lub przyspieszających się postępów.
Hyperagents eliminuje inne ograniczenie. Łączy agent zadania z meta-agentem, który go edytuje, w jeden program dostępny do modyfikacji, dzięki czemu mechanizm zapewniający przyszłe ulepszenia może być sam zmieniany. Autorzy donoszą, że niektóre z tych ulepszeń na poziomie meta przenoszą się między różnymi domenami zadań i gromadzą się w trakcie kolejnych wykonywań. Razem te badania przenoszą dyskusję z pytania „Czy sztuczna inteligencja może edytować swój własny kod?” na „Jak daleko może ona udoskonalić proces swojego rozwoju?”
Cztery pytania dotyczące każdego twierdzenia o „lepszej wydajności”
Gdy krzywa samodoskonalenia rośnie, warto zastanowić się, co dokładnie wzrosło.
Lepsze pod jakim względem?
Dokładność może się poprawić, podczas gdy koszt i opóźnienie rosną wraz z nią. Takie kompromisy są przyjęte w celach badawczych, ale mogą być nie do przyjęcia w produktach, dlatego należy sprawdzić wszystkie wskaźniki, a nie tylko ten najważniejszy.
Lepsze w jakich zadaniach?
Postępy w zadaniach używanych wielokrotnie do wyboru następnej wersji są słabszym dowodem niż postępy w odrębnym teście końcowym, którego nikt nie modyfikował podczas rozwoju. Za każdym razem, gdy wynik testu wpływa na kolejną decyzję wyborczą, proces zaczyna dostosowywać się do wymogów tego testu.
Która wersja jest lepsza?
Archiwum przechowujące najlepszy wynik pokaże rosnącą linię „najlepsze dotychczas”, nawet jeśli większość nowych kandydatów jest gorsza. Sprawdź rozkład kandydatów, a nie tylko ich maksymalną wartość.
Czy poprawia się w procesie samodoskonalenia?
Rozwiązywanie większej liczby zadań może wskazywać na lepsze umiejętności samodoskonalenia, ale są to różne metryki. Silniejszy eksperyment sprawdza, czy nowa wersja tworzy lepsze wersje następne niż jej poprzednik, przy tym samym budżecie.
Te pytania nie mają na celu zaprzeczania postępowi. Służą do tego, aby precyzyjnie zdefiniować postęp i móc go rozpoznać.
Eksperyment z samodoskonaleniem, który możesz przeprowadzić
Rzeczywistym punktem wyjścia dla pojedynczego programisty lub małego zespołu nie jest otwarcie całego systemu na samowymianę, lecz wybór jednego wąsko skoncentrowanego narzędzia do rozwoju i jego ścisłe ograniczenie. Jako przykład weźmy narzędzie do generowania testów dla bazy kodu w Javie:
- Napraw to, co nie może ulec zmianie: narzędzie nie powinno modyfikować kodu aplikacji ani testów oceniających.
- Zdefiniuj to, co może ulec zmianie: tylko jego własna strategia skanowania plików, instrukcje oraz proces generowania testów.
Rozpatruj to jako projekt eksperymentalny, a nie obietnicę konkretnych wyników. Użycie modeli otwartych lub darmowych kwot może obniżyć koszty działania, ale tańsze wykonywania nie dowodzą, że wprowadzone zmiany są przydatne. Najpierw poszukaj wyraźnie mierzalnej korzyści, a dopiero potem rozszerz zakres projektu. Ta sama zasada oceny odnosi się do każdego agenta, który wdrażasz; nasz przewodnik po ograniczonych pętlach agentowych w TypeScript omawia aspekty związane z kontrolowaniem takich pętli podczas ich działania.
Lepsze agenci to nie eksplozja inteligencji
Czy zatem sztuczna inteligencja może projektować lepszą sztuczną inteligencję? W powyższych eksperymentach – tak, w określonym sensie: systemy AI pomogły stworzyć bardziej zdolne agenty, a kilka z nich zastosowało ten proces w swoim własnym oprogramowaniu. Nie pokazano jednak łańcucha ulepszeń, który przyspieszałby z każdą iteracją, generalizowałby się na różne dziedziny i funkcjonował niezależnie od ludzkich decyzji projektowych. Odrzucenie tych prac jako „zwykłego inżynierii promptów” sprawia, że przegapiamy rzeczywiste wyniki; nazywanie tego początkiem eksplozji inteligencji przesadza z ich oceną.
Główne wnioski
- Zawsze pytaj, która warstwa uległa zmianie: wagi, kod agenta, prompty, narzędzia czy sam mechanizm ulepszeń.
- Formalne gwarancje, takie jak te dotyczące Maszyny Gödla, obowiązują jedynie w odniesieniu do założeń, na których opierają się; podejścia empiryczne zamieniają dowody na ocenę, więc jakość tej oceny decyduje o wszystkim.
Prawdziwym problemem nie jest umożliwienie sztucznej inteligencji modyfikowania własnego kodu. Chodzi o wiarygodne udowodnienie, że dana modyfikacja stanowi rzeczywisty postęp, oraz przeniesienie tego postępu do kolejnej rundy ulepszeń.
Literatura pokrewna
- Co właściwie przewidują prawa skalowania LLM i dokąd pójdzie postęp — Dowiedz się, jak stosuje się prawa skalowania typu prawo potęgi w przypadku modeli LLM, dlaczego Chinchilla zmieniła budżety treningowe oraz dlaczego modele rozumowania otwierają nowy kierunek w skalowaniu mocy obliczeniowej.
- Weryfikacja działania agentów AI: uprawnienia, bramy zatwierdzenia i poziomy ryzyka — Dowiedz się, dlaczego agenty działające potrzebują podejścia opartego na weryfikacji, oraz jak zasada najmniejszych uprawnień, ludzkie zatwierdzenie i autonomia oparta na ryzyku pomagają ograniczyć ich błędy.