Inżynieria kontekstu dla agenta badawczego Quant: poziomy dowodów i magazyny danych

Decydowanie o tym, czemu może ufać agent

Wyobraź sobie środowisko badawcze zarządzane przez sztuczną inteligencję, stworzone dla konkursu quantowego WorldQuant BRAIN. Zanim pojawią się jakiekolwiek specjalistyczne agenty, sprawdzania całego cyklu życia lub autonomiczne pętle, istnieje prostszy problem projektowy: jakie stwierdzenia system może traktować jako prawdziwe? Surowiec przybywa w czterech formach, które niewiele ze sobą mają wspólnego.

Pierwszym elementem są oficjalne dokumentacje platformy i turnieju, które wyjaśniają, w jaki sposób działa język wyrażeń, jakie operatorzy i zbiory danych są dostępne oraz jakie ustawienia symulacji są dozwolone. Drugim elementem jest metodologia – trzy książki Marcosa López de Prado dostarczają narzędzi do analizy statystyk backtestów, ryzyka strategii, testowania wielokrotnego, struktury portfela oraz problemu fałszywych wyników, natomiast książka Igora Tulchinsky’ego „Finding Alphas” przedstawia w praktyczny sposób kwestie związane z budową strategii, rotacją pozycji, korelacją, nadfittingiem, stronniczością i trwałością rozwiązań. Trzecim elementem jest zbiór artykułów i notatek z pogłębionych badań na temat anomalii gospodarczych, uczestników rynku oraz przepływu informacji, które można uporządkować w postaci grafu łączącego aksjomaty, teorie, anomalie, mechanizmy i sposoby implementacji. Czwartym elementem są wszystkie dane wytwarzane przez projekt w trakcie jego działania: wyniki symulacji, codzienne wykresy zysków i strat, korelacje portfeli, statystyki odporności, sprawdzenia platformy, historie eksperymentów, wydarzenia operacyjne, nieudane próby kompilacji oraz wnioski wyciągnięte z nich.

Każdy z tych elementów stanowi kontekst, jednak mają one różny stopień wiarygodności, a żaden z nich nie pasuje idealnie do jednego polecenia, jednego formatu dokumentu ani jednej bazy danych. Dlatego projektowanie kontekstu w tym przypadku zaczyna się gdzie indziej niż od limitów tokenów – zaczyna się od określenia poziomów dowodów oraz systemów danych, które zapewniają zachowanie integralności każdego z tych poziomów.

Po lewej znajduje się prosty, początkowy projekt, w którym zasady, książki, artykuły naukowe oraz wyniki samego systemu są łączone w jeden prompt, przy czym wszystkie mają równą wagę. Po prawej każde twierdzenie zachowuje swój poziom. Zasady stanowią „ściany”, przekonania proponują testy, obserwacje dostosowują przekonania, a nic wewnątrz tych „ścian” nie może ich edytować.

Trzy poziomy dowodów

„Dowód” ma praktyczne znaczenie. W przypadku każdego twierdzenia należy zastanowić się, jaki dowód jest wystarczający, kto jest za niego odpowiedzialny oraz co może go obalić. Te pytania są rozpatrywane na trzech poziomach.

L1 odzwierciedla to, co platforma określa jako gry, korzystając z oficjalnych materiałów platformy i turniejów. Gdy agent musi wiedzieć, jakie ustawienia istnieją, co robi operator, jakie testy musi przejść kandydat lub jak turniej oblicza swoje wyniki, to właśnie tutaj szuka odpowiedzi. Lokalna kopia może ulegać starzeniu, ale żaden nieoczekiwany eksperyment nie może zmienić zasad.

L2 odzwierciedla to, co system faktycznie zaobserwował. Tutaj znajdują się wyniki symulacji, codzienne serie PnL, dzisiejszy portfel, sprawdzenia platformy, wydarzenia operacyjne oraz najnowszy stan tabeli liderów. Każda pomiar jest oznaczona datą jej dokonania. Ponowne uruchomienie niczego nie nadpisuje – tworzy nową obserwację, więc historia nigdy nie jest później uporządkowywana.

L3 obejmuje to, co system obecnie uważa za przydatne. W tej warstwie znajdują się książki, artykuły, teorie ekonomiczne, specyfikacje, analizy grafów wiedzy, zapisane lekcje oraz elementy służące do zwalczania błędnych założeń. One kierują kolejnymi działaniami i pozostają otwarte na zmianę.

Kolejność ta nie jest sztywna – L1 zawsze ma pierwszeństwo przed L2, a L2 przed L3. Każdy poziom odpowiada na inny rodzaj pytania. W przypadku sporu faktycznego pomiędzy źródłami przeważa to najmocniejsze i najbezpośredniejsze źródło, więc oficjalna zasada ma większą wagę niż parafraza zawarta w instrukcji dla agenta, a umiarkowana odpowiedź przewyższa to, czego można się spodziewać na podstawie książki. Jednak jeśli chodzi o decyzję o tym, co spróbować dalej, zasady i metryki nie dostarczają odpowiedzi. Wtedy potrzebny jest L3, aby podjąć uzasadnioną decyzję.

W tym wykresie odnotowano trzy koncepcje. Zjawisko odchylenia po publikacji wyników nie zostało wyeliminowane przez narzędzie służące do jego wykrywania, które zamiast tego zidentyfikowało błąd w strukturze, dzięki czemu koncepcja została odbudowana na podstawie korekt dokonanych przez analityków i złożono dwie wersje. Koncepcja oparta na zestawieniu spółek z tej samej kategorii rozpoczęła się jako czysta przekonanie bez żadnych dowodów, a mimo to przeszła weryfikację. Koncepcja związana z „zegarem dywidend” nie sprawdziła się we wszystkich dziesięciu strukturach, więc wnioski z tych doświadczeń sprowadziły się do uwzględniania wyłącznie dat wypłaty dywidend. Zielone kwadraty oznaczają koncepcje, które przeszły wszystkie sprawdzenia platformy, czerwone – te, które nie przeszły, szare – te, dla których nie ma żadnych zapisanych sprawdzeń, a te z obwódką – te, które zostały złożone.

Jedna baza danych może zawierać zarówno wartość pomiaru (L2), jak i jego odczyt przez konkretną osobę (L3), co oznacza, że poziom odnosi się do samego twierdzenia, a nie do miejsca jego przechowywania. W związku z tym rekord kontekstowy jest bogatszy niż zwykły tekst. Powinien zawierać samo twierdzenie, jego poziom epistemiczny, źródło, właściciela, zakres, czas obserwacji lub przeglądu, stopień niepewności, stabilny identyfikator oraz wszelkie dowody, które mogą je zmienić. W przypadku faktów, które zmieniają się z upływem czasu, pomocne są pary chronologii: kiedy coś było prawdą oraz kiedy system to odkrył. API, które odpowiadają z opóźnieniem i uzupełniają dane historyczne, sprawiają, że ta luka staje się istotna.

Kontekst to w rzeczywistości mała platforma danych

Każdy sklep jest kreowany na podstawie jego zachowania. Rejestr gromadzi dowody warstwami, a przez nie przechodzi jedna łańcuchowa struktura; stare wydarzenia zanikają, a graf stanowi parę tabel, która w pamięci przekształca się w wielograf. Pliki są grupowane według cyklu życia. Stabilne identyfikatory utrzymują wszystko razem. Codzienne zyski i straty nadal znajdują się w miejscu, które według własnych specyfikacji projektu powinny już tam nie być.

Gdy istnieją poziomy dowodów, staje się oczywiste kolejne zagadnienie: kontekst nie stanowi pojedynczego korpusu. Zachowuje się jak niewielka platforma danych. Największą jego część stanowi rejestar badawczy, który na sprawdzanej stacji roboczej jest bazą danych typu SQLite służącą do przechowywania transakcji. Określanie go jako tabeli eksperymentalnej to niedocenienie jego roli, ponieważ pełni funkcję rejestru dowodów zawierającego kilka grup zapisów. Jedna z tych grup dotyczy intencji badawczych, czyli mechanizmów, hipotez, przewidywań oraz historii implementacji. Kolejna grupa obejmuje dane pomiarowe, w których przechowywane są odpowiedzi platformy, statystyki z próby, wyniki sprawdzeń, codzienne wyniki PnL oraz metryki testów obciążeniowych. Trzecia grupa dotyczy interpretacji, zawierającej przypisy, wnioski oraz elementy służące do falsyfikacji hipotez. Czwarta grupa obejmuje aspekty zarządzania, obejmujące śledzenie rozważanych decyzji, zatwierdzeń oraz tego, co wydarzyło się w momencie składania wniosków. Ostatnią z nich jest analiza materializowana: delty portfela, wykresy korelacji, bufory wzorców oraz podsumowania testów obciążeniowych, z których wszystkie można odtworzyć na podstawie kanonicznych danych wejściowych.

Przeprowadzone audyt wykazały niezgodność. Dokument projektowy stanowi, że codzienne wyniki PnL zostały przeniesione do plików Parquet, ale baza danych nadal przechowuje każdy wiersz. Dokument to przekonanie (L3), natomiast baza danych to obserwacja (L2), a w przypadku konfliktu przeważa obserwacja.

Następnie znajduje się magazyn zdarzeń operacyjnych, przechowywany jako odrębna baza danych SQLite. Zdarzenia te mogą zawierać identyfikatory cyklu, partii, kandydata, hipotezy, agenta oraz procesu wraz z zawartością w formacie JSON z wersją. Może być kuszące połączenie ich z księgą rachunkową, ale wymagania dotyczące przechowywania są różne. Dowody badawcze są kanoniczne i muszą przetrwać. Wyniki debugowania, zdarzenia wysyłane, przejścia w kolejce oraz tymczasowe interwencje szybko się mnożą i mogą być skompresowane lub usunięte po upływie określonego czasu. Dzięki oddzieleniu tych elementów nagły wzrost ilości danych związanych z obserwowalnością nie może powodować przepełnienia ani blokowania naukowych zapisów.

Następnie mamy graf wiedzy – graf właściwości transakcyjny o celowo prostym kształcie fizycznym: tabelę węzłów, tabelę krawędzi oraz atrybuty w formacie JSON zawierające dane specyficzne dla każdego typu, wszystko to ładowane do grafu pamięciowego w celu przeszukiwania. Warstwa transakcyjna unika problemów z uszkodzeniami danych i konkurencją typowymi dla jednego ogromnego pliku YAML, natomiast forma pamięciowa ułatwia przeprowadzanie rozumowań.

System plików również stanowi system danych. Repozytorium przechowuje niezmienne dokumenty platformy, książki, artykuły naukowe oraz powstałe na ich podstawie raporty, a przeniesienie ich wszystkich do pamięci byłoby błędem, ponieważ ich cykle życia się różnią. Dokumenty platformy nigdy się nie zmieniają. Specyfikacje znajdują się pod kontrolą wersji jako elementy projektu. Raporty to wyniki obliczeń, które wymagają zapisanych danych wejściowych oraz sposobu na ich ponowne utworzenie. Pliki pamięci to krótkie, czytelne wskaźniki do ponownego wykorzystania uzyskanych informacji. Pliki kolejki, cache’y i logi to tymczasowe dane operacyjne, natomiast binarne pliki modeli, wyeksportowane dane PnL oraz duże zrzuty stanu to artefakty, które lepiej przechowywać w systemach przechowywania obiektów zamiast w Git.

Historie niepowodzeń są wymowne. Jeden z najlepiej radzących sobie algorytmów alpha niemal został odrzucony, ponieważ księga rachunkowa wskazywała, że wszystkie sprawdzenia przeszły pomyślnie, podczas gdy skrypt analizował plik z wynikami, który pokazywał wartość Sharpe 0. Jeden z wczesnych zwycięzców w ogóle nie miał żadnych zapisów decyzji, dopóki sześć tygodni później proces synchronizacji nie dostarczył tych danych. Decyzja o obstawianiu przeciwko algorytmowi beta istniała jedynie w pliku pamięci w formacie Markdown, więc sama księga rachunkowa nic nie zrobiła, by zapobiec ponownej próbie.

Wynika z tego system kontekstowy wielorakiego typu, mimo że prawie całość nadal działa na jednym laptopie. SQLite obsługuje transakcje, grafy reprezentują relacje, Parquet jest planowanym formatem dla dużych serii czasowych, Markdown przechowuje informacje, które ludzie mogą przejrzeć, a pliki tymczasowe koordynują lokalne procesy.

Tutaj przedstawiono jeden rzeczywisty mechanizm bez podania jego nazwy. Po lewej stronie widać jego pochodzenie w grafie wiedzy, a po prawej – każdą hipotezę, eksperyment oraz kandydata, który sprawdził go w praktyce. Niektóre niepowodzenia występowały we wszystkich wersjach, podczas gdy inne były specyficzne dla danej implementacji. Obie części nie mają nic wspólnego poza identyfikatorem umieszczonym wzdłuż styku, a ten jeden klucz wystarcza, by połączyć je w spójny pakiet kontekstowy.

Mechanizmy pełnią rolę łącznika pomiędzy tymi dwoma magazynami. W grafie pojawiają się one jako koncepcje ekonomiczne wraz z ich źródłami, natomiast w księdze rachunkowej jako tagi przy każdej hipotezie oraz kandydacie, który je wykorzystał. Podsumowania empiryczne mogą być powiązane z węzłami grafu w celu ułatwienia nawigacji, ale są to jedynie odbicia rzeczywistości – prawdziwe dane znajdują się w bazie danych eksperymentów. Dlatego też dobry pakiet kontekstowy jest tworzony poprzez łączenie informacji z różnych systemów. Zawiera on małą okolicę grafu, informacje o pochodzeniu źródeł, aktualne podsumowania empiryczne, najnowsze niepowodzenia oraz ograniczenia platformy, które obowiązują. Model nie potrzebuje całego grafu ani każdej wiersza dotyczącego zysków i strat. Kluczowe jest najkrótsze ścieżki dowodowe prowadzące do danej decyzji.

Gdy graf i księga rachunkowa dzielą ten sam identyfikator mechanizmu, można razem zobaczyć cały gałąź: teorię, eksperymenty, wszystkich kandydatów oraz podsumowanie na węźle grafu, który odzwierciedla księgę rachunkową. Pomysł autoryzacji odkupu pochodził bezpośrednio z artykułu z 1995 roku, jednak nigdy nie został dołączony do gałęzi dotyczącej wspólnych odkupów, więc żadne z jego wyników nie jest dostępnych z grafu.

Kilka umów dotyczących danych warto uczynić bardziej rygorystycznymi. Obiekty przenoszone między magazynami powinny zawierać wyraźną wersję schematu JSON. Każda pochodna miara powinna wskazywać wersję kodu, zrzut stanu źródła oraz wersję metody, która ją wygenerowała. Każdy eksperyment wymaga manifestu z adresowaniem treści w celu zapewnienia powtarzalności, zawierającego informacje o komitcie kodu, podsumowaniu środowiska, ustawieniach platformy oraz identyfikatory hipotezy i implementacji. Ponadto procesy synchronizacji powinny być testowane tak jak każdy inny problem związany z jakością danych, a nie traktowane jako bezpieczne procedury techniczne.

Podsumowując podejście projektowe, wykres jest kontekstem, księga rachunkowa jest kontekstem, a połączenie między nimi również jest kontekstem. To połączenie wymaga takiej samej staranności inżynieryjnej jak kod modelu.

Gdzie to łączy się z inżynierią harness

Żadna prośba nie jest przekazywana w całości do sklepów. Każdy sklep dostarcza niewielki fragment do typowanego pakietu, a każdy specjalista otrzymuje dokładnie to, czego potrzebuje. Wyniki są przekazywane z powrotem do odpowiednich miejsc według typu, reguły nigdy nie są do nich zapisywane, a dwa pętle uzupełniają następny pakiet z różną szybkością.

To wyznacza granicę pomiędzy inżynierią kontekstu a inżynierią narzędzi. Zarządzanie kontekstem odpowiada za poziomy od L1 do L3: przechowuje źródła, pomiary, informacje wstępne, informacje o pochodzeniu, daty i godziny, zakres oraz stabilne identyfikatory. L4, czyli narzędzie agentowe, decyduje, jakie dowody mają zostać pobraane, ile danych jest dozwolone po przekroczeniu granicy etapu, który specjalista ma je otrzymać oraz jakie wnioski są uzasadnione. Poniżej znajdują się kod źródłowy (L5), lokalna infrastruktura (L6) oraz infrastruktura rozproszona (L7). Te warstwy będą bezbłędnie realizować błędne decyzje, ale nie mają wpływu na to, czy dane wejściowe stanowią regułę, obserwację czy przekonanie.

Wcześniejsza wersja zatraciła tę różnicę. Główny plik z instrukcjami rozrósł się do wiki składającego się z 627 wierszy, łączącego zasady turnieju, aktualny stan, metody oraz lekcje z poprzedniego dnia. Po jego skróceniu do niewielkiego routera, informacje docierały do agenta przez cztery ścieżki. Krótka warstwa pozostaje załadowana przez cały czas. Pakiet startowy przekazuje nowe lekcje i ostrzeżenia. Zasady specyficzne dla danej obszaru są włączane tylko wtedy, gdy zadanie dotyczy tego obszaru, a specjalistyczne role wraz z ich pamięciami są pobierane w razie potrzeby.

Jedna prośba, śledzona krok po kroku

Rozważmy pytanie „Co należy spróbować dalej?”. System zaczyna od utworzenia pakietu wstępnego. Z poziomu L1 pobiera odpowiednie wyrażenia, ustawienia oraz ograniczenia dotyczące oceny. Z poziomu L2 pochodzą aktualny portfel rozwiązań, najnowsze pomiary, informacje o tym, jak duża część przestrzeni poszukiwań została objęta, oraz wyniki, które wciąż nie zostały rozwiązane. Z poziomu L3 bierze się najbardziej istotną gałąź grafu, teoretyczne źródła informacji, narzędzia służące do weryfikacji, specyfikacje badań oraz wnioski empiryczne.

Następnie wchodzą w grę podagenty. Specjalista od hipotez pracuje na podstawie tego pakietu, proponując kilka perspektyw ekonomicznych, nie ukrywając słabych uzasadnień stojących za formułami. Po wyborze jednej z perspektyw specjalista od modelowania bierze zarejestrowaną hipotezę i tworzy implementacje, które rzeczywiście różnią się od siebie. Specjalista od eksperymentów otrzymuje drzewo implementacji oraz ograniczenia platformy, a następnie rejestruje to, co jest mierzonych.

Każdy etap ma swój własny cel. Moduł L2 księgi rachunkowej otrzymuje surowe wyniki platformy oraz znormalizowane pomiary. Zdarzenia operacyjne, takie jak rozpoczęcie procesów, wywołania narzędzi, próby ponowne oraz ruch koordynacyjny, trafiają do magazynu zdarzeń. Gdy jakiś wynik dostarcza wskazówek lub informacji o błędach, jest przechowywany w modułu L3. Zestawienia graficzne powstają w wyniku porównania z danymi z księgi rachunkowej i nigdy nie są edytowane ręcznie, natomiast duże serie danych dotyczące zysków i strat, wykresy oraz dostosowane modele stają się elementami, do których odnoszą się inne zapisy.

Oba przesłane warianty alfa wykorzystywały już paczki zawierające dane dowodowe. Jedna z grup wcześniej ulepszyła swoją ofertę, a druga idea wykorzystała już istniejącą wersję, która dała wcześniej niepowiązane wyniki alfa. Pomysł zmiany oceny również otrzymał paczkę danych, nieprzetestowaną pozycję na mapie możliwości oraz poprzedniego zwycięzcę do naśladowania, ale wszystkie 18 jego wariantów i tak zawiodły.

Etapowanie infrastruktury

Przenoszenie wszystkiego naraz byłoby błędem. Każda ścieżka zmienia się we własnej fazie, a brama otwiera się tylko wtedy, gdy istnieje mierzalny powód tego wymagający. Po prawej stronie przedstawiono jedyną godną zaufania ścieżkę zapisu (commit, outbox, exporter, projection), w przeciwieństwie do podwójnego zapisu, który tworzy dwie sprzeczne wersje prawdy.

Obecna lokalna pila może robić więcej, niż się wydaje. SQLite to doskonały wybór domyślny dla pojedynczego badacza – oferuje prawdziwe transakcje, proste kopie zapasowe, szybkie zapytania lokalne i praktycznie żadnych dodatkowych kosztów operacyjnych. Jednak pojawiają się pewne ograniczenia. Baza danych o wielkości kilku gigabajtów zawiera dziesiątki milionów wierszy z seriami czasowymi, kilka procesorów może konkurować o możliwość zapisu lokalnego, zdarzenia w trakcie działania aplikacji stale się mnożą, a artefakty i zrzuty stanu są przymocowane do jednej maszyny. Odtworzenie wyniku gdzie indziej wymaga znacznie większej ilości ukrytego stanu, niż ktokolwiek by chciał. Pięciofazowa ewolucja wydaje się więc sensowna.

Faza 0 polega na dostosowaniu projektu do rzeczywistości: należy albo dokończyć nieukończoną migrację wyników finansowych, albo świadomie ją cofnąć, a następnie zautomatyzować audyt porównujący dokumentację z danymi przechowywanymi w produkcji. Faza 1 przenosi duże pliki poza system, tak aby codzienne wyniki finansowe, wykresy, pliki modeli, obszerne raporty oraz zrzuty bazy danych trafiały do magazynu obiektów kompatybilnego z S3; wyniki finansowe są dzielone na skompresowane partycje w formacie Parquet, wspierane przez niezmienne pliki manifestu, sumy kontrolne oraz reguły zarządzania żywotnością danych. Faza 2 przenosi metadane tylko wtedy, gdy konieczność jednoczesnej pracy zmusza do tego sytuację. Gdy pracownicy zdalni, kilka maszyn lub współpracownicy muszą pisać jednocześnie, księga rachunkowa oraz magazyn zdarzeń przechodzą do zarządzanego PostgreSQL, jako odrębne bazy danych lub przynajmniej odrębne schematy z własnymi politykami przechowywania. Faza 3 wprowadza elementy MLOps jako narzędzie pomocnicze, a nie jako źródło prawdy, dzięki czemu narzędzia takie jak Weights & Biases lub MLflow mogą być przydatne bez konieczności zastępowania księgi rachunkowej lub struktury grafu. Faza 4 oddziela orkiestrację od stanu: pracownicy badawczy działają w kontenerach z niezmienialnymi manifestami zadań, podczas gdy kolejka lub silnik przepływu pracy przydziela zadania idempotentne wraz z mechanizmami wynajmu, ponawiania prób i czasów wygaśnięcia. Faza 5 zapewnia bardziej zaawansowaną analizę tylko wtedy, gdy obciążenie pracy na to pozwala. Format tabel w stylu lakehouse, dedykowana baza danych grafowych lub platforma strumieniowa mogą ostatecznie przynieść korzyści, ale tylko wtedy, gdy konkretne zapytania zaczynają stanowić problem, np. skanowanie miliardów obserwacji, liczne jednoczesne przemierzanie grafów, ewolucja schematu w dużych zbiorach w formacie Parquet lub konsumenci zdarzeń o niskiej opóźnieniu.

Nie można przypisać tej architekturze żadnego dokładnego wzrostu wydajności, ponieważ jej wpływ nigdy nie został wyizolowany. Jej rzeczywisty wkład polega na umożliwieniu systemowi uczciwego sprzeczania się samemu z sobą. Jeden artykuł to sugeruje, symulacja się nie zgadza, narzędzie do falsyfikacji zawęża zakres przekonań, a zasady turnieju pozostają niezmienne.