Powszechne przekonanie o projektowaniu systemów złożonych jest takie, że wymaga ono specjalisty, który przez tygodnie ręcznie koduje modele w dedykowanych językach, a potem iteruje przez dziesiątki wariantów, zanim otrzyma zachowanie zbliżone do zamierzonego. Rzeczywistość pracy z systemami opartymi na nieliniowych sprzężeniach zwrotnych jest jednak jeszcze trudniejsza – bo nawet doświadczony badacz nie zawsze potrafi przewidzieć, jakie emergentne zachowanie wyłoni się z danej struktury. CEDR to metoda, która zmienia punkt wyjścia: zamiast ręcznego modelowania proponuje autonomiczny proces oparty na agentach dużych modeli językowych, zdolny do odkrywania konfiguracji systemu spełniających z góry określone cele behawioralne.
Czym jest CEDR i jaki problem rozwiązuje?
Tradycyjne podejście do modelowania systemów złożonych – od dynamiki populacji po modele polityki ekonomicznej – od dekad opiera się na specjalistycznych językach takich jak DYNAMO czy STELLA. Narzędzia te są precyzyjne, ale wymagają zarówno głębokiej wiedzy dziedzinowej, jak i żmudnego, ręcznego definiowania równań i parametrów. Każda zmiana struktury modelu to kolejna iteracja pracy analityka, a cały proces może trwać znacznie dłużej niż okno decyzyjne, w którym wyniki byłyby użyteczne. W praktyce oznacza to, że modele gotowe do użycia pojawiają się nierzadko kilka tygodni po tym, gdy decyzja musiała już zapaść.
CEDR – skrót od Complex Emergent Discovery via Autonomous Reasoning – to autonomiczna metoda, która używa agentów opartych na dużych modelach językowych do odkrywania systemów złożonych spełniających zadane przez użytkownika cele behawioralne. Zamiast wymagać od użytkownika znajomości DYNAMO czy STELLA, CEDR reprezentuje systemy jako uruchamiany podzbiór Pythona z domenowymi prymitywami – gotowymi blokami budulcowymi właściwymi dla danej dziedziny. Takie podejście obniża próg wejścia i sprawia, że modyfikacja struktury systemu staje się operacją dostępną dla agenta językowego bez pośrednictwa człowieka na każdym kroku.
Pytanie, które natychmiast się nasuwa, brzmi: czy CEDR naprawdę potrafi sam projektować systemy złożone pod konkretny cel? Odpowiedź jest twierdząca, ale z ważnym zastrzeżeniem. Metoda nie działa jak wyrocznia – użytkownik nadal musi zdefiniować cel behawioralny (np. pożądany wzorzec oscylacji, stabilność populacji, określony profil wzrostu). To, co CEDR robi autonomicznie, to przeszukiwanie przestrzeni możliwych konfiguracji systemu i ocena każdego kandydata względem tego celu. Człowiek wyznacza kierunek, algorytm eksploruje teren.
Jak działa pętla przeszukiwania w CEDR?
Sercem metody jest formalizacja problemu jako wariantu Monte Carlo Tree Search – algorytmu przeszukiwania drzewa decyzyjnego dobrze znanego z zastosowań w grach i planowaniu. W klasycznym MCTS agent eksploruje drzewo możliwych stanów, balansując między eksploracją nieznanych gałęzi a eksploatacją tych, które dotychczas dawały dobre wyniki. CEDR adaptuje ten schemat do odkrywania systemów złożonych, gdzie każdy węzeł drzewa odpowiada konkretnej konfiguracji systemu, a przejścia między węzłami to modyfikacje tej konfiguracji. Liczba iteracji potrzebna do uzyskania konfiguracji spełniającej cel behawioralny zależy od złożoności przestrzeni prymitywów, jednak autorzy metody raportują zbieżność już po kilkudziesięciu krokach pętli w testowanych scenariuszach.
W każdym kroku pętli działają dwa wyspecjalizowane komponenty: LLM Judge oraz LLM Editor, które razem tworzą mechanizm oceny i ulepszania kandydatów. LLM Judge analizuje zachowanie emergentne wygenerowanego systemu i ocenia je względem celu zdefiniowanego przez użytkownika – pełni funkcję analogiczną do funkcji wartości w klasycznym uczeniu ze wzmocnieniem. LLM Editor na podstawie tej oceny proponuje zmodyfikowany wariant systemu, działając jak operator wariacji w obliczeniach ewolucyjnych. Oba komponenty są parametryzowane przez duże modele językowe, co oznacza, że zarówno funkcja przejścia, jak i funkcja wartości w drzewie MCTS są sterowane przez te modele.
LLM Judge w CEDR robi coś innego niż standardowa ewaluacja modelu językowego: uruchamia system jako kod Pythona, obserwuje jego dynamiczne zachowanie w czasie i dopiero wtedy wydaje ocenę – nie na podstawie tekstu, lecz na podstawie symulowanej trajektorii systemu. To ocena behawioralna, nie tekstowa. Pętla generuj-i-oceniaj (generate-and-evaluate loop) powtarza się iteracyjnie, a dzięki strukturze MCTS metoda zapamiętuje, które gałęzie przestrzeni rozwiązań były obiecujące, i wracając do nich, buduje coraz lepsze konfiguracje.
Co CEDR może odkrywać w praktyce?
Zakres zastosowań metody wyznacza sama natura systemów złożonych. Modele dynamiki populacji, systemy biologiczne z pętlami regulacyjnymi, modele decyzji ekonomicznych czy symulacje strategiczne to dziedziny, w których sprzężenia zwrotne prowadzą do trudnych do przewidzenia zachowań emergentnych. Poniżej wymieniono przykładowe klasy celów behawioralnych mieszczące się w logice działania CEDR:
- oscylacje o zadanej częstotliwości lub amplitudzie w modelach dynamicznych;
- stabilne stany równowagi przy zadanych warunkach brzegowych;
- bifurkacje – punkty, w których drobna zmiana parametru prowadzi do jakościowej zmiany zachowania systemu;
- chaotyczne trajektorie spełniające określone statystyki długoterminowe;
- wzorce wzrostu lub zaniku charakterystyczne dla konkretnych procesów biologicznych lub ekonomicznych.
Reprezentacja systemów jako uruchamialnego podzbioru Pythona z domenowymi prymitywami sprawia, że agent może bezpośrednio modyfikować strukturę modelu – bez potrzeby tłumaczenia zamiarów na specjalistyczny język modelowania. Podzbiór Pythona używany przez CEDR to celowo zawężona przestrzeń wyrażeń, która zapewnia, że generowane systemy są uruchamialne i interpretowalnie spójne. Domenowe prymitywy dostarczają gotowych bloków odpowiadających typowym elementom modeli w danej dziedzinie – takim jak równania wzrostu, mechanizmy konkurencji czy opóźnienia czasowe. Agent operuje na zestawie sprawdzonych elementów, co ogranicza liczbę błędnych konfiguracji i przyspiesza konwergencję.
Gdzie CEDR wypada lepiej od dotychczasowych metod?
Narzędzie czy współpracownik?
Porównując CEDR z klasycznymi podejściami do optymalizacji systemów złożonych, warto zacząć od tego, czego te podejścia nie potrafią. Metody gradientowe zakładają ciągłość i różniczkowalność przestrzeni rozwiązań – założenie, które w modelach z pętlami regulacyjnymi lub dyskretnymi przełącznikami po prostu nie zachodzi. Przeszukiwanie siatki parametrów (grid search) skaluje się wykładniczo z liczbą wymiarów i szybko staje się obliczeniowo nieopłacalne. Ręczna eksploracja przez eksperta jest dokładna, lecz powolna i zależna od intuicji, która w systemach nieliniowych regularnie zawodzi.
CEDR łączy to, czego brakuje każdemu z tych podejść osobno. Model językowy wnosi zdolność do semantycznego rozumienia struktury systemu i generowania modyfikacji, które mają sens domenowy – nie są losowymi perturbacjami, lecz hipotezami. MCTS wnosi pamięć o przestrzeni już przeszukanej i mechanizm równoważenia eksploracji z eksploatacją. Wyniki opisane przez autorów metody pokazują, że CEDR potrafi odtworzyć znane zachowania modelowe w ułamku czasu potrzebnego przy ręcznej kalibracji, a w niektórych przypadkach odkrywa konfiguracje nieoczekiwane nawet dla twórców modeli bazowych.
Granice metody
Ekspresywność reprezentacji jest jednocześnie zaletą i ograniczeniem. Uruchamiany podzbiór Pythona sprawdza się tam, gdzie domenowe prymitywy dobrze pokrywają przestrzeń możliwych modeli. Gdy system wymaga wyrażeń spoza tego zestawu, agent traci przewagę – wraca do prób, które nie dają się uruchomić lub są domenowo bezsensowne. Projektowanie biblioteki prymitywów to zatem praca, która poprzedza każde nowe zastosowanie CEDR i decyduje o jego skuteczności. Metody takie jak CEDR nie zastępują wiedzy eksperckiej – domenowe prymitywy musi zaprojektować człowiek, cel behawioralny musi sformułować badacz. Agent operuje w ramach, które ktoś wcześniej przemyślał, jednak w obrębie tych ram działa autonomicznie, generując i testując hipotezy szybciej, niż zdołałby to zrobić zespół analityków pracujący przez kilka dni.
Czy środowiska modelowania są gotowe na przesunięcie ciężaru pracy badacza – mniej czasu na ręczne strojenie parametrów, więcej na formułowanie pytań i interpretację wyników – i czy narzędzia wspierające ten tryb pracy powstaną wystarczająco szybko, by dotrzymać kroku możliwościom samych agentów?
Źródła: mast.stanford.edu, youtube.com, arxiv.org, dl.acm.org
