Najlepsza baza danych dla agenta programistycznego: PostgreSQL do zarządzania stanem, hybrydowe wyszukiwanie do odzyskiwania informacji.

Wybierz bazę danych dla agenta programistycznego, patrząc na to, co agent robi przez cały dzień, a nie na etykietę AI. Agent, który uruchamia polecenia w środowisku sandbox, wywołuje narzędzia, przesyła logi, tworzy pliki, próbuje ponownie zrealizować nieudane kroki i kontynuuje pracę po przerwach, głównie zajmuje się księgowością z dodatkowymi efektami ubocznymi. Do takiej księgowości solidnym standardem jest PostgreSQL. Magazyn wektorów, takie jak Weaviate, znajduje swoje zastosowanie później, jako odrębna warstwa, gdy produkt musi znaleźć podobne wcześniejsze błędy i rozwiązania na podstawie znaczenia.

Zacznij od jednego wywołania narzędzia

Śledź pojedyncze wywołanie narzędzia w całym systemie. Przed jego uruchomieniem platforma oznacza wywołanie jako rozpoczęte, łączy je z konkretnym procesem, rezerwuje klucz idempotencji, odnotowuje, które środowisko sandbox jest używane, oraz umieszcza kolejne zadania w kolejce. Po zakończeniu procesu platforma zapisuje status, metadane wyników oraz pliki powstałe w trakcie pracy, aktualizuje łączne statystyki wykorzystania i przesuwa główny proces dalej.

Te operacje stanowią jedną logiczną sekwencję. W przypadku transakcji albo są realizowane razem, albo wcale, a inne sesje nigdy nie widzą stanu w połowie ukończenia. Teraz rozważmy awarie. Proces przestaje działać pomiędzy etapami „narzędzie ukończone” a „wykonanie zaawansowane”, więc proces przywracania musi być deterministyczny. Próba wykonania operacji następuje dwukrotnie, a ograniczenie unikalności powinno odrzucić duplikat. Artefakt wskazuje na wykonywanie, którego nie ma, a klucz obcy powinien odrzucić tę wiersz. Nic tu nie jest egzotyczne. To są zwykłe zadania bazy danych, od których ciągle korzysta agent kodujący, dlatego przewyższają one wszelką reklamę opartą na „sztucznej inteligencji”.

Dane są relacyjne

Główne elementy agenta wykonawczego nie są tajemnicze i są ze sobą powiązane:

• Wykonania przechowują informacje o stanie cyklu życia, właścicielu, przestrzeni roboczej, modelu, datach, budżecie oraz ostatecznym wyniku.
• Kroki to zaplanowane lub zakończone jednostki pracy, pomiędzy którymi istnieją zależności.
• Wywołania narzędzi przechowują dane wejściowe, wyjściowe, status, opóźnienie, liczbę prób ponownych oraz klucze idempotencji.
• Wykonania w środowisku testowym opisują środowisko, metadane poleceń, kod wyjścia, zużycie zasobów oraz przyczynę zakończenia.
• Wydarzenia tworzą historię dostępną wyłącznie do dodawania nowych записów, służącą do debugowania, transmisji strumieniowej i odtwarzania.
• Artyfakty wskazują na pliki z poprawkami, raporty, utworzone pliki lub lokalizacje w chmurze obiektowej.
• Punkty kontrolne przechowują informacje niezbędne do wznowienia przepływu pracy.

Każdy element wymaga stabilnej tożsamości oraz wyraźnych powiązań z pozostałymi. Klucze pierwszorzędne, ograniczenia unikalności, ograniczenia sprawdzające oraz klucze obce utrudniają tworzenie nieważnych stanów, a szczególnie klucze obce gwarantują, że każde wezwanie narzędzia należy do rzeczywistego wykonywania i że każdy artefakt ma swojego producenta.

Pola niezbędne do koordynacji należy przechowywać w kolumnach typowanych z odpowiednimi indeksami: status, tenant, identyfikator wykonywania, daty i godziny, numer próby oraz klucz idempotencji. Są one podstawą do planowania, filtrowania, przechowywania danych oraz tworzenia paneli kontrolnych. Ukrywanie ich w jednym dużym, nierozróżnionym dokumencie JSON znacznie utrudnia egzekwowanie tych zasad.

Gdzie pasuje jsonb

Narzędzia szybko się zmieniają. Jedne zwracają diagnozy kompilatora, inne emitują wydarzenia przeglądarki, a jeszcze inne raportują metadane repozytorium. Stała kolumna dla każdego możliwego pola byłaby marnotrawstwem, natomiast jsonb nadaje się do przechowywania tych elementów, które się zmieniają: argumentów narzędzi, odpowiedzi dostawców, konfiguracji środowiska testowego oraz metadanych modeli. PostgreSQL umożliwia zapytania do danych w formacie JSON za pomocą operatorów i wyrażeń ścieżek, a także indeksowanie kluczy i wartości przy użyciu mechanizmu GIN; zalety i wady tego podejścia są opisane w oficjalnym podręczniku.

Skutecznym rozwiązaniem jest użycie typizowanego strukturyrelacyjnego kontenera wokół elastycznego treściowego pakietu. Wszystko, co jest potrzebne do zachowania integralności danych lub do wykonywania często używanych zapytań, znajduje się w kolumnach, natomiast dane rozszerzeń są przechowywane w formacie jsonb. Dzięki temu unika się dwóch skrajności: albo kolumn specyficznych dla każdego eksperymentu, które są kruche, albo nieprzejrzystego magazynu dokumentów, który pozostawia całą logikę relacji kodowi aplikacji.

Dostosuj przechowywanie do wzorca dostępu

Nie wszystko powinno znajdować się w głównej bazie danych. Krótkie fragmenty z stderr, znormalizowane szczegóły błędów, kody wyjścia oraz możliwe do wyszukiwania streszczenia pasują obok zapisu wykonania. Duże strumienie z konsoli, archiwa repozytoriów, pliki binarne, zrzuty ekranu oraz wyniki kompilacji zazwyczaj trafiają do przechowywania obiektów, przy czym PostgreSQL odwołuje się do nich za pomocą trwałych metadanych i sum kontrolnych.

Taki podział sprawia, że wiersze pozostają małe, zachowując jednocześnie informacje o pochodzeniu danych. Baza danych pozostaje źródłem autorytetowym dotyczącym tego, czy dany artefakt istnieje, który proces go wygenerował, gdzie się znajduje oraz jakie zasady przechowywania obowiązują, natomiast przechowywanie obiektów umożliwia tańsze przechowywanie dużych, niezmienialnych plików. Jedna rada: nigdy nie zakładaj, że przesłanie się udało, dopóki proces nie ma planu odzyskiwania w przypadku częściowego niepowodzenia.

Historia zdarzeń również jest przydatna. Zamiast wielokrotnie przepisywać jeden duży dokument z wynikami działania, zapisuj istotne przejścia pomiędzy stanami i przechowuj zwięzłą informację o aktualnym stanie w celu szybkiego odczytu. Historia służy do audytów i diagnozowania, projekcja zaś do interfejsu użytkownika produktu oraz planeru, a obie mogą znajdować się w PostgreSQL w ramach tych samych transakcji.

Protokół zapisu jest równie ważny jak silnik

W rzeczywistych warunkach pracy mogą wystąpić podwójne dostawy, awarie procesorów, przestoje sieciowe oraz wyniki działań narzędzi, których nikt nie może potwierdzić. Wybór bazy danych to tylko połowa rozwiązania. Skuteczny protokół wygląda następująco:

• Przypisz operacjom podlegającym ponownej próbie klucz identyfikacyjny zapewniający efekt idempotencji, wspierany przez ograniczenie unikalności.
• Modeluj zmiany w cyklu życia produktu jako nazwane przejścia pomiędzy stanami, a nie dowolne aktualizacje stanu.
• Zapisuj powiązane rekordy w jednej transakcji, gdyby częściowa widoczność danych była błędna.

Użyj skrzynki wyjściowej, gdy zatwierdzona zmiana musi uruchomić wiadomość lub zadanie indeksowania.

Zachowuj surowe zdarzenia w stanie niezmienionym tam, gdzie ważna jest audytowalność, a w razie potrzeby odbudowuj na ich podstawie projekcje.

Przechowuj czas wygaśnięcia oraz przypadki „nieznany wynik” oddzielnie od potwierdzonych błędów.

Ludzie szukający najlepszej bazy danych dla agenta programistycznego nie tylko przechowują wiadomości z czatu. Koordynują one efekty uboczne takie jak edycja plików, uruchamianie niepewnego kodu, wywoływanie płatnych API oraz publikowanie zmian. Warstwa stanu musi zapewnić, aby każda transformacja była sprawdzalna i możliwa do przywrócenia.

Kiedy warstwa pobierania się opłaca

PostgreSQL pozostaje główną rekomendacją. Należy dodać dedykowany magazyn do wyszukiwania, gdy produkt ma specyficzne potrzeby: wyszukiwanie w historii wcześniejszych wykonań według znaczenia oraz dokładnego tekstu. Typowe zapytania to „które wcześniejsze wykonywania zawiodły po aktualizacji zależności”, „jakie błędy zostały naprawione dzięki temu śladowi wywołań” oraz „która sekwencja narzędzi naprawiła niestabilny test”.

W takich zapytaniach nadal mają znaczenie dokładne tokeny: nazwy wyjątków, wersje pakietów, kody kompilatora, flagi, nazwy plików oraz hashe. Mimo to użytkownicy opisują ten sam błąd na różne sposoby. Czyste wyszukiwanie według słów kluczowych pomija powiązania koncepcyjne, natomiast czysta podobieństwo wektorowe może umniejszać wagę dosłownych ciągów znaków, na których polegają inżynierowie. Wyszukiwanie hybrydowe obejmuje oba te podejścia. Weaviate to jeden z silników, który jednocześnie przeprowadza wyszukiwanie wektorowe i według słów kluczowych BM25, a następnie łączy uzyskane wyniki w jeden ranking, dzięki czemu dosłowny kod taki jak ERR_MODULE_NOT_FOUND dostarcza dowodów opartych na słowach kluczowych, podczas gdy „czas wykonywania nie może rozwiązać problemu z zaimportowanym pakietem” dostarcza dowodów semantycznych.

Należy jasno określić granice. PostgreSQL kontroluje kanoniczne wykonywania zadań, wywołania narzędzi, uprawnienia oraz stan. Asynchroniczny pracownik odczytuje zapisane zmiany, tworzy dokument do wyszukiwania na podstawie wybranych pól i wprowadza go do indeksu wyszukiwania. Wyniki wyszukiwania zawierają ID z PostgreSQL, dzięki czemu aplikacja pobiera autorytatywną informację i ponownie sprawdza dostęp przed pokazaniem jakichkolwiek danych. Nawet jeśli indeksowanie się opóźnia lub musi zostać odbudowane, poprawność wykonywania zadań pozostaje nienaruszona.

Dodanie drugiego systemu ma sens tylko wtedy, gdy semantyczne odzyskiwanie informacji stanie się rzeczywistą funkcją. Do tego czasu wystarczy wyszukiwanie pełnego tekstu w PostgreSQL w połączeniu z dobrze zindeksowanymi zapytaniami strukturalnymi.

Struktura referencyjna składająca się z pięciu części

1. Autorytatywny stan w PostgreSQL. Wykonywania zadań, kroki, wywołania narzędzi, wyniki działania środowiska testowego, metadane artefaktów, punkty kontrolne oraz relacje dostępu.
2. Wielkie obciążenia w przechowaniu obiektów. PostgreSQL przechowuje lokalizacje, hashe, typy treści, właścicieli oraz dane dotyczące przechowywania.
3. Skrzynka wysyłkowa dla zatwierdzonych zmian. Procesory przesyłają aktualizacje interfejsu, planują dalsze zadania i tworzą projekcje do wyszukiwania, unikając konieczności obsługi niezatwierdzonych danych.
4. Pobieranie dokumentów z indeksu wektorowego lub hybrydowego w razie potrzeby. Zawierają one streszczenia, znormalizowane błędy, polecenia, wybrane fragmenty dzienników, opisy napraw oraz metadane poddawalne filtrowaniu.
5. Rozwiązywanie wyników wyszukiwania przy użyciu PostgreSQL. Indeks znajduje kandydatów, a baza danych pozostaje źródłem informacji o aktualnym stanie i uprawnieniach.

Usuwanie i przechowywanie danych stają się również łatwiejsze do zrozumienia. Proces usuwania lub modyfikacji rozpoczyna się w PostgreSQL, przechodzi przez skrzynkę wysyłkową, usuwa powiązane obiekty i aktualizuje projekcję wyszukiwania, dzięki czemu źródło prawdy nigdy nie jest niejednoznaczne.

Czego unikać na początku

• Bazy danych wektorowych tylko dlatego, że dostępny jest model językowy LLM. Wczesne pytania operacyjne są przeważnie strukturyzowane, takie jak wykonywania zadań dla jednego użytkownika w określonym stanie, kroki, które niedawno zawiodły, powolne wywołania narzędzi lub eksekucje powiązane z konkretnym commitem. Zwykłe indeksy umożliwiają na nie odpowiedź.
• Jeden obiekt JSON dla całego stanu agenta. Taka metoda oferuje krótkoterminową wygodę, ale powoduje słabe ograniczenia, trudne aktualizacje równoczesne oraz uciążliwe zapytania dotyczące cyklu życia danych. Elastyczne metadane są w porządku, ale niestrukturyzowany system przechowywania danych nie jest.

Wyszukiwanie wewnątrz krytycznej transakcji. Agent powinien zakończyć wywołanie narzędzia nawet wtedy, gdy indeksowanie semantyczne jest opóźnione. Skrzynka wyjściowa i projekcja asynchroniczna chronią tę granicę.

Lista kontrolna

Najpierw wybierz PostgreSQL, jeśli potrzebujesz:

• transakcji ACID obejmujących wiele wierszy zamiast rekordów wykonywania,
• zobowiązujących powiązań pomiędzy rundami, krokami, wywołaniami, użytkownikami i artefaktami,
• bezpiecznych prób ponownych wykonywań oraz kontroli współbieżności,
• prostego filtrowania według statusu, czasu, właściciela, kosztu lub wyniku,
• metadanych w formacie jsonb, które nadal można zapytywać,
• trwałych rekordów służących do odzyskiwania danych i audytu.

Dodaj hybrydowy silnik wyszukiwania, jeśli potrzebujesz również:

• wyszukiwania opartego na znaczeniu w historii wcześniejszych rund i wywołań narzędzi,
• rankingu uwzględniającego dokładne tokeny błędów oraz podobne sformułowania.
• znajdowanie powiązanych incydentów, rozwiązań oraz skutecznych procedur pracy,
• warstwa wyszukiwania, którą można odtworzyć na podstawie kanonicznych rekordów.

Szybkie odpowiedzi

Czy baza wektorowa powinna być głównym backendem? Zazwyczaj nie. Głównym obciążeniem jest praca z stanem transakcyjnym: uruchamianie procesów, wywoływanie narzędzi, wyniki, ponawianie prób oraz relacje między elementami. Baza wektorowa służy do zupełnie innej pracy z danymi – wyszukiwania.

Czy jsonb wystarcza do przechowywania metadanych agentów? Często tak, szczególnie przy zmieniających się treściach narzędzi oraz szczegółach specyficznych dla dostawców, pod warunkiem że kolumny typowane przechowują identyfikatory i pola dotyczące cyklu życia danych. Uzupełnia ono schemat, ale go nie zastępuje.

Dlaczego hybrydowe wyszukiwanie dla logów? Dane inżynieryjne łączą precyzyjne tokeny z językiem naturalnym. BM25 pokazuje dokładne kody, nazwy pakietów i plików, natomiast wyszukiwanie wektorowe łączy różnie sformułowane opisy tego samego błędu.

Najlepszy projekt to podział pracy, a nie konkurencja między systemami relacyjnymi a wektorowymi. PostgreSQL stanowi podstawę transakcyjną: obsługuje wykonywanie zadań, rejestrację działań, historię wywołań narzędzi, metadane, punkty kontrolne oraz artefakty. Gdy historia wykonywania zadań staje się zasobem wiedzy, dodana warstwa hybrydowego wyszukiwania poprawia możliwości odzyskiwania informacji. Postgres służy do przechowywania stanu, a indeks wyszukiwania do szybkiego odnajdywania danych.