Dostępna do wyszukiwania długoterminowa pamięć dla agentów inżynierii danych

Agenty bez stanu dobrze rozwiązują problemy. Są słabe w pamiętaniu o tym, że je rozwiązali.

Problem amnezji

Wyobraź sobie agenta, który spędza prawie godzinę na błędzie NoClassDefFoundError w świeżo utworzonym notatniku Databricks. Przejrzał ścieżkę wywołań, znalazł brakującą bibliotekę w klastrze roboczym, zastosował poprawkę i potwierdził pomyślny przebieg. To solidne samodzielne debugowanie.

Tydzień później inna ścieżka przetwarzania napotyka ten sam błąd, a agent nie ma pojęcia, że go kiedykolwiek widział. Cała sesja debugowania powtarza się ponownie, przy pełnym koszcie tokenów, z realną szansą na zastosowanie innej poprawki tym razem.

To nie jest awaria modelu. Taki jest domyślny sposób zachowania agentów, a oni zapominają na trzy sposoby:

1. Gdy sesja się kończy, wszystko, czego się w niej nauczyli, znika.
2. Długie sesje są ostatecznie podsumowywane lub skracane, co zachowuje ogólny tok wydarzeń, ale często pomija istotne szczegóły implementacji.
3. W systemach wieloagentowych agenci robocze zazwyczaj zaczynają od czystego kontekstu, nie odziedziczają nic od poprzednich agentów i nie przechowują nic po zakończeniu swojego zadania.

Zespół zarządzający systemem wieloagentowym, który tworzy pipeline’y typu Databricks lakehouse, płacił tę „podatek amnezji” we wszystkich trzech aspektach. Ich rozwiązaniem była warstwa pamięci długoterminowej umożliwiająca wyszukiwanie.

Co oznacza „pamięć wyszukiwalna”

W systemach agentowych dwa różne elementy nazywane są pamięcią, dlatego terminy te wymagają precyzyjnego określenia.

Okno kontekstowe pełni rolę pamięci roboczej agenta. Wszystko, co się w nim znajduje, jest natychmiast dostępne dla modelu, ale tylko przez czas trwania sesji. Gdy informacje znikną, z punktu widzenia agenta są one nieobecne.

Pamięć długoterminowa to trwałe magazynowanie, które przetrwa sesje, zadania i agenty. Jednak samo przechowywanie informacji nie wystarcza. Informacje przechowywane stają się przydatną pamięcią tylko wtedy, gdy są automatycznie rejestrowane, można je skutecznie wyszukiwać i przywoływać do okna kontekstowego w razie potrzeby. To ostatni krok ma kluczowe znaczenie. Doskonała lekcja, której nigdy nie odzyskuje się, może być uważana za nieistniejącą, a lekcja odzyskana jest bezwartościowa, jeśli nie dotrze do agenta podejmującego decyzję.

Nauka kognitywna dostarcza taksonomię, która dobrze odpowiada systemom agentowym:

• Pamięć epizodyczna przechowuje zapisy konkretnych doświadczeń z przeszłości: archiwum transkrypcji sesji, wcześniejsze błędy wraz z ich rozwiązaniami, decyzje z poprzednich wersji.
• Pamięć semantyczna przechowuje ustrukturyzowane fakty, takie jak „zasada X należy do produktu danych Y” lub „to system źródłowy autoryzuje w ten sposób”, najlepiej z interwałami ważności, ponieważ fakty się zmieniają.
• Pamięć proceduralna to wiedza praktyczna: pliki z instrukcjami, umiejętności oraz konwencje, które są ładowane przy każdej sesji.

Dwa poziomy pamięci

Jedna decyzja znacznie uprościła sprawę: podział pamięci na dwa poziomy.

Poziom 1 – starannie wybrana pamięć. Mała, ręcznie utrzymywana zbiór reguł ładowany przy każdej sesji. Chodzi tu o standardy architektoniczne, wymagania bezpieczeństwa, konwencje nazewania oraz ograniczenia związane z zarządzaniem. Pamięć operacyjna jest kosztowna, dlatego ten poziom przeznaczony jest na to, co musi być zawsze dostępne.

Poziom 2, pamięć do wyszukiwania. Duży archiwum doświadczeń rejestrowanych automatycznie i dostępnych wyłącznie w razie potrzeby: zweryfikowane poprawki, ustalenia wynikające z rozwiązywania problemów, wnioski z implementacji oraz charakterystyki powtarzających się awarii. Domyślnie nie jest on widoczny w interfejsie.

Zasada ogólna:

Fakt, który musi być przestrzegany za każdym razem, powinien znajdować się w poziomie starannie przygotowanym. Fakt przydatny w sytuacjach podobnych powinien być umieszczony w poziomie do wyszukiwania.

Taki podział pozwala zachować wiedzę, nie przepełniając przy tym okna kontekstowego.

System wielu agentów, który tego potrzebował

Omawiany system obsługuje cały cykl życia inżynierii danych, przekształcając wymagania biznesowe w gotowe do użycia procesy i panele kontrolne. Orkiestrator koordynuje specjalistyczne agenty, z których każdy ma jedno zadanie oraz tylko te narzędzia, których potrzebuje:

• Specyfikacja funkcjonalna polega na przeczytaniu zgłoszenia wymagań, opracowaniu specyfikacji oraz uzyskaniu zatwierdzenia od osoby, która złożyła prośbę.
• Projekt techniczny przekształca zatwierdzoną specyfikację w plan kontraktów danych oraz mapowania od źródła do celu.
• Przyjmowanie, transformacja i integracja generują rzeczywisty kod pipeline’u. Oznacza to notatniki typu Bronze pobierające dane z Kafka, SAP, REST lub plików, notatniki typu Silver przekształcające dane oraz modele wymiarowe typu Gold, wszystkie zorganizowane według schematu medali.
• Walidacja to jedyny element, który może pracować w pobliżu aktywnego klastra. Sprawdza każdy utworzony notatnik na podstawie tymczasowych tabel i weryfikuje wyniki.
• Repozytorium zarządza gałęziami, komitami oraz prośbami o pull request.
• Monitorowanie obserwuje proces CI/CD po zintegrowaniu zmian.

Panel sterowania tworzy tablice analityczne na podstawie uzyskanych wyników.

Śledzenie kosztów pokazuje, ile to wszystko kosztuje.

Architektura jest celowo izolacjonistyczna. Procesory działają równolegle przy niezależnej własności plików, nie mogą ze sobą komunikować się i rozpoczynają każde zadanie w zupełnie czystym kontekście. Orkiestrator tworzy samodzielny opis zadania, procesor wykonywać określone zadanie, zwraca wynik i znika.

Izolacja sprawia, że system jest bezpieczny i możliwy do równoległego działania. Sprawia również, że amnezja jest gorsza niż w układzie z jednym agentem, ponieważ każdy procesor „urodził się” wczoraj, za każdym razem. Każda rola gromadzi swój własny rodzaj doświadczeń wartych zachowania, a żadne z nich nie przetrwa zakończenia zadania, chyba że coś poza kontekstem agentów je przechowuje.

Projektowanie pamięci dla wielu agentów

Cztery mechanizmy rozwiązują ten problem.

1. Automatyczne przechwytywanie

Haki w czasie działania agenta uruchamiają się w dwóch momentach: gdy sesja się zamyka oraz tuż przed skompresowaniem kontekstu. Każdy z nich odczytuje transkrypcję i przenosi przydatne informacje do pamięci. Nikt nie musi pamiętać o pisaniu dokumentacji ani aktualizowaniu bazy wiedzy.

Operacje pamięciowe również nie są blokujące. Jeśli infrastruktura pamięci przestanie działać, haki po prostu nic nie robią. Warstwa pamięci ma za zadanie pomagać; nie powinna stać się czymś, bez czego nie można kontynuować prawdziwej pracy.

2. Dostęp ograniczony zakresem

Orkiestrator posiada pełny zestaw narzędzi pamięciowych. Pracownicy mają tylko trzy uprawnienia: czytanie własnego dziennika, zapisywanie własnego dziennika oraz wyszukiwanie w bazie. To narzędzia egzekwują te zasady, a nie polecenia, co zapewnia jasną rozdzielenie obowiązków i uniemożliwia pracownikom modyfikację pamięci poza ich zakresem kompetencji.

3. Dzienniki specyficzne dla ról

Każdy pracownik ma swój prywatny przestrzeń nazw pamięci. Błędy w trakcie działania oraz sprawdzone rozwiązania gromadzą się w dzienniku agenta walidacyjnego, podczas gdy monitor CI/CD zbiera informacje o błędach oraz skutecznych metodach ich naprawy. Pozostałe agenty przechowują podobnie ograniczone zbiory danych.

Dzienniki nie stanowią kanałów komunikacji. Pracownicy nie przekazują wiadomości za pośrednictwem pamięci, a koordynacja odbywa się poprzez orkiestratora, który zapewnia spójność i aktualność każdego dziennika.

4. Przypominanie na poziomie kontekstu

Okazało się to najważniejszą decyzją. Pracownicy zaczynają od pustego kontekstu, więc pamięć pobrana z innego źródła jest przydatna dopiero wtedy, gdy zostanie włączona do tego kontekstu. Obowiązująca zasada brzmi:

Pamięć, która została pobrana, ale nie umieszczona w kontekście, nie istnieje dla pracownika.

Gdy znajdują się odpowiednie lekcje, koordynator zapisuje je bezpośrednio do kontekstu zadania przed przekazaniem pracy. Samo pobieranie danych nie wystarcza – aby lekcja mogła zostać zastosowana, musi być widoczna.

Budowa na MemPalace

Warstwa ta jest oparta na MemPalace, otwartym frameworku do przechowywania danych lokalnie. Sklep, embeddingi oraz indeks wyszukiwania działają wszystkie lokalnie, dzięki czemu żadne dane nie opuszczają środowiska, co jest ważne, gdy agenci pracują z danymi przedsiębiorstw i systemami produkcyjnymi.

MemPalace przechowuje informacje w postaci fragmentów tekstu wzbogaconych o metadane, takie jak agent, który je stworzył, kategoria oraz data i godzina, rozmieszczone w oddzielnych przestrzeniach nazw. Dzięki temu możliwe jest tworzenie dzienników specyficznych dla poszczególnych ról – każdy agent pisze w swojej własnej przestrzeni i stopniowo buduje swoją wiedzę.

Proces przechwytywania przebiega poprzez powyższe punkty życiowe. Pod koniec sesji lub przed kompresją transkrypt jest oczyszczany, przekształcany w lekcje nadające się do ponownego użycia, wzbogacany o lokalny model ONNX oraz indeksowany w celu późniejszego odzyskiwania. Wszystko to odbywa się w tle, dzięki czemu agenci nigdy nie czekają na operacje pamięciowe.

Proces odzyskiwania danych jest hybrydowy i łączy podobieństwo wektorowe z dopasowywaniem słów kluczowych. Pomaga to w inżynierii danych, gdzie niektóre sygnały mają charakter semantyczny, a inne to dokładne ciągi znaków. Nazwa błędu taka jak NoClassDefFoundError lub dokładna wersja środowiska Databricks musi pasować dosłownie, natomiast ten sam problem sformułowany inaczej powinien nadal zostać wykryty.

Agenci uzyskują dostęp do pamięci za pośrednictwem MCP. Orkiestrator widzi cały zestaw narzędzi, natomiast prace widzą jedynie funkcje diary_read, diary_write i search, przy czym granice są określane przez narzędzia, a nie przez polecenia.

MemPalace zostało wybrane, ponieważ stawia na lokalne rozwiązania, jest bezpłatne i łatwe do zintegrowania, ale architektura nie jest od niego zależna. Mem0, Zep lub Letta mogą pełnić tę samą rolę. Ważny nie jest framework, lecz pętla zwrotna: rejestrowanie doświadczeń, przechowywanie ich i udostępnianie w momencie ponownego wystąpienia tego samego problemu.

Co zmieniło się w praktyce

Pierwszą widoczną korzyścią była triaż błędów. Podstawowa zasada agenta walidacyjnego jest prosta: przy każdym błędzie najpierw należy przeprowadzić wyszukiwanie, zanim zacznie się debugowanie.

mempalace_search(query="NoClassDefFoundError DBR 14.3")

Gdy rozwiązanie jest ponownie dostępne, agent otrzymuje lekcję wyciągniętą z wcześniejszego udanego rozwiązania:

Notatnik Bronze dla zleceń uległ awarii w wersji DBR 14.3 z błędem NoClassDefFoundError związanym z deserializatorem Avro. Co to naprawiło: wyraźne określenie biblioteki serializatora w konfiguracji klastra zadań.

Różnica jest znaczna. Zamiast odkrywać rozwiązanie od zera, agent wychodzi od dowodów na to, co zadziałało. A wartość ta nie dotyczy tylko szybkości – chodzi o spójność. Bez pamięci dwa agenty rozwiązujący ten sam problem mogą wybrać różne, pozornie rozsądne rozwiązania. Dzięki pamięci system decyduje się na to, o którym wiadomo, że działa, i nadal je używa.

Podobne korzyści pojawiły się również w innych obszarach. Monitor CI/CD integruje teraz historyczne przypadki wystąpienia określonych błędów do swoich raportów diagnostycznych, mechanizmy uruchamiane przy rozpoczęciu sesji przywracają istotny, najnowszy kontekst, a specjalistyczne agenty zdobywają wiedzę z czasem, zamiast ciągle ją odbudowywać.

Nie wymaga to ponownego szkolenia. Cykl uczenia się odbywa się poza modelem: doświadczenie, wnioski, przechowywanie, wydobycie, zastosowanie.

Wnioski z produkcji

Bądź ostrożny z uzupełnianiem danych historycznych. Pierwsza próba sprowadzenia dużych ilości starych zapisów przyniosła rozczarowujące wyniki, ponieważ starsze materiały często przyćmiewały nowsze, lepsze wnioski i powodowały zakłócenia podczas wydobycia informacji. Zespół zrezygnował z masowego importu i zaczął od nowa od chwili, gdy zapisy zaczęły być generowane w czasie rzeczywistym. Nowość i jakość są ważniejsze od ilości.

Zapisuj wspomnienia prostym językiem. Framework oferuje zwięzłe formaty wpisów, które zespół przyjął. Pobieranie informacji przebiega najlepiej, gdy przechowywana lekcja zawiera dokładnie te same słowa, które zostaną użyte w późniejszym wyszukiwaniu: nazwy produktów, nazwy entytetów, komunikaty błędów oraz klasy wyjątków. W przechowalni wspomnień ważniejsza jest możliwość znalezienia informacji niż jej mała objętość.

Starannie wybieraj, co zapisywać. Nie wszystko, co się zobaczy, zasługuje na trwałe przechowanie. Warto zachować potwierdzone poprawki, zweryfikowane ustalenia oraz lekcje, które można ponownie wykorzystać. Należy pominąć rutynowe logi, chwilowe obserwacje, powtarzające się aktualizacje stanu oraz informacje poufne. Zła praktyka przechowywania informacji szybko się gromadzi i może przynieść większą szkodę niż jej brak.

Wnioсы

Każdy raz, gdy pracownicy wykonywają powtarzalną pracę, tworzą doświadczenia, które warto zachować. To, co sugeruje ten framework:

• Podziel pamięć na ręcznie dobierane zasady oraz możliwości wyszukiwania informacji.
• Automaticznie rejestruj wnioski, szczególnie przed kompresją kontekstu.
• Przyznawaj pracownikom wąskie uprawnienia zależne od ich roli.
• Wykorzystuj wcześniejsze informacje przy rozwiązywaniu problemów, jeśli istnieje szansa, że zostały one już rozwiązane.
• Włączaj przywołane informacje bezpośrednio do zapytania.
• Traktuj pamięć jako dowód, a nie jako niekwestionowaną prawdę.
• Stawiaj większy nacisk na jakość pamięci niż na jej objętość.

Najważniejszy wniosek dotyczy architektury. Dużo wysiłku wkłada się w uczynienie agentów mądrzejszymi, ale w praktyce długoterminowa wartość wynika z umiejętności systemów przypominania sobie informacji.

Literatura pokrewna

• Od modeli do agentów: przerobienie trzech linii obrony — Jak zasady zarządzania w MLOps odzwierciedlają się w systemach agentowych: co musi dodać każda z trzech linii, gdzie znajdują się luki oraz co wskazują regulacje UE, FDA i organy finansowe.
• Budowanie pamięci agenta, która przetrwa rozmowę bez gromadzenia danych — Projekt pamięci trzeciorzędowej dla agentów: pozwól stanowi sesji się zakończyć, utrzymuj długoterminowe notatki w małych rozmiarach i w formie edytowalnej, a także pobieraj aktualne dane. Dodatkowo omówiono problemy z przenoszeniem obowiązków między agentami.

Wyjaśnienie agentów: narzędzia, prompty systemowe i pętla myśl-działanie — Przewodnik dla początkujących po tym, jak działają agenci AI: dlaczego modele konwersacyjne zapominają, jak opisywać narzędzia dla LLM, prompty systemowe, ReAct, agenci kodujące oraz obserwacje.