Agent przyjmuje reklamację, sprawdza zamówienie i zleca zwrot pieniędzy. Operator płatności wykonuje operację, ale odpowiedź ginie po drodze. Agent widzi przekroczony czas oczekiwania. Próbuje ponownie.
W tym hipotetycznym przykładzie o drugim zwrocie decydują zasady ponawiania operacji, identyfikatory żądań i zapis stanu. Nawet model, który poprawnie zrozumiał całą rozmowę, potrzebuje interfejsu pozwalającego ustalić, co już się wydarzyło. To jeden z powodów, dla których warto wrócić do Designing Data-Intensive Applications przy projektowaniu systemu AI.
Drugie wydanie książki Martina Kleppmanna i Chrisa Riccominiego ukazało się według O’Reilly w lutym 2026 roku. Spis treści obejmuje m.in. transakcje, replikację, przetwarzanie strumieniowe, embeddingi wektorowe oraz trwałe wykonywanie workflow. Dzik z okładki pozostał dobrym znakiem rozpoznawczym książki o tym, co dzieje się z danymi poza pojedynczą funkcją. Wydawca i spis treści.
Poniżej odnosimy te zagadnienia do aplikacji AI i kilku znanych punktów odniesienia w dyskusji o ich architekturze. To komentarz Lazarus Systems oparty na publicznych materiałach, bez oceny wszystkich rozdziałów książki.
Model dostaje narzędzia, zespół dostaje więcej zależności
W tekście The Shift from Models to Compound AI Systems z 18 lutego 2024 roku Matei Zaharia i współautorzy opisali systemy łączące modele z wyszukiwaniem, narzędziami i kolejnymi wywołaniami. Nazwa „compound AI” porządkuje coś, co łatwo przeoczyć w demonstracji: wynik zależy od współpracy kilku komponentów. BAIR.
W naszym przykładzie model interpretuje reklamację, wyszukiwarka znajduje regulamin, baza przechowuje zamówienie, a operator płatności realizuje zwrot. Każdy komponent ma inny stan i może przestać odpowiadać w innym momencie. Ocena samej odpowiedzi językowej obejmuje tylko fragment takiego procesu.
Z tego wyciągamy praktyczny wniosek: przed wyborem kolejnego modelu warto rozpisać drogę jednej operacji i wskazać właściciela każdego zapisu. Gdzie powstaje ostateczna informacja o zwrocie? Które kopie służą wyłącznie do wyszukiwania? Kto naprawia rozbieżność? Bez tych odpowiedzi trudno nawet ustalić, który komponent zawinił.
Podejście compound AI nie uzasadnia dokładania komponentów bez końca. Osobny model oceniający, kolejka czy baza wektorowa oznaczają dodatkowy koszt utrzymania. W ocenie Lazarus Systems każdy taki element powinien rozwiązywać nazwany problem i mieć test pokazujący, że robi to lepiej od prostszego wariantu.
RAG może przywołać nieaktualny regulamin
Praca Patricka Lewisa i współautorów z 2020 roku połączyła generowanie tekstu z pobieraniem informacji z zewnętrznego indeksu. To źródłowy punkt odniesienia dla RAG, czyli generowania odpowiedzi z pomocą wyszukanych materiałów. Publikacja RAG.
W firmowym wdrożeniu trzeba jeszcze zaprojektować drogę od dokumentu do odpowiedzi. Załóżmy, że zmieniono termin przyjmowania reklamacji. Nowy regulamin jest już w CMS, lecz proces indeksujący utknął. Asystent znajduje starą wersję i poprawnie ją streszcza. Samo sprawdzenie, czy odpowiedź wynika z dostarczonego fragmentu, może uznać ją za poprawną.
Traktowanie indeksu jako danych pochodnych pomaga nazwać problem. Dokument źródłowy, jego fragmenty, embeddingi i zapisane odpowiedzi mają własny cykl aktualizacji. Proponujemy zachować identyfikator dokumentu i jego wersję przy każdym fragmencie, mierzyć opóźnienie indeksowania oraz ustalić, co aplikacja robi po przekroczeniu dopuszczalnego opóźnienia. Może pobrać dokument bezpośrednio, poinformować o braku aktualnego źródła albo przekazać sprawę człowiekowi.
Podobnie wygląda cofnięcie dostępu. Usunięcie pliku z katalogu źródłowego pozostawia pytanie o indeks, cache i wcześniejsze konwersacje. Uprawnienia trzeba egzekwować przy pobieraniu danych, zanim trafią do kontekstu modelu. Proces usuwania kopii powinien obejmować również dane pochodne, zgodnie z przyjętymi zasadami retencji. Polecenie w prompcie, by model nie ujawniał sekretów, nie zapewnia takiej kontroli.
Nasza ocena RAG jest więc warunkowa: daje zespołowi możliwość aktualizacji wiedzy poza treningiem modelu, ale wymaga utrzymywania tej ścieżki aktualizacji. W teście odbiorowym chcielibyśmy zobaczyć zmianę dokumentu, opóźniony indeks i cofnięcie uprawnień, a następnie odpowiedź systemu w każdej z tych sytuacji.
Zwrot pieniędzy po utracie odpowiedzi
Wróćmy do reklamacji. Jeśli ponowione żądanie otrzyma nowy identyfikator, operator płatności może potraktować je jako kolejny zwrot. W projekcie takiego narzędzia proponujemy stały klucz idempotencji dla tej samej operacji biznesowej. Idempotencja oznacza tutaj, że ponowienie tej operacji nie tworzy kolejnego skutku. Klucz musi rozpoznawać odbiorca żądania, a system powinien uwzględniać jego okres przechowywania i zasady obsługi konfliktów.
Sam zapis „zakończone” w bazie aplikacji nie obejmuje automatycznie zewnętrznej płatności. Może powstać przerwa między wykonaniem zwrotu a zapisaniem jego wyniku. Dlatego potrzebny jest stan pozwalający oznaczyć wynik jako nieznany, odpytać operatora po identyfikatorze i uzgodnić oba zapisy. Ponowienie bez tej wiedzy bywa kolejną operacją finansową.
To zastosowanie tematów transakcji i awarii częściowych do agenta AI, a nie obietnica, że jeden wzorzec rozwiąże każdą integrację. Jeżeli zewnętrzne API nie oferuje deduplikacji ani sprawdzenia wyniku, zakres bezpiecznej automatyzacji będzie mniejszy. Zespół może wtedy zatrzymywać niejednoznaczne sprawy do ręcznego rozstrzygnięcia.
Agenci, workflow i trwała pamięć
W Building effective agents z 19 grudnia 2024 roku Anthropic odróżnia zaplanowany w kodzie przebieg workflow od agenta, któremu model wyznacza kolejne kroki. Autorzy zalecają zwiększać złożoność dopiero wtedy, gdy poprawia wynik. Strona zawiera dziś także zastrzeżenie, że narzędzia zmieniły się od publikacji. Anthropic, 2024.
Dla obsługi reklamacji przyjęlibyśmy stałe reguły kontroli uprawnień i wykonywania zwrotu. Model mógłby interpretować opis problemu, wyszukiwać brakujące informacje i przygotowywać odpowiedź. Swoboda wyboru kolejnego kroku powinna wynikać z trudności zadania. Limit kwoty i prawo do wykonania operacji da się sprawdzić w kodzie, niezależnie od tego, jak przekonująco model opisze swoją decyzję.
Związek z projektowaniem danych widać jeszcze wyraźniej w opisie Managed Agents z 8 kwietnia 2026 roku. Anthropic przedstawia oddzielne interfejsy dla dziennika sesji, pętli sterującej agentem i środowiska wykonawczego. Trwały dziennik pozwala wznowić pracę po awarii procesu sterującego. Anthropic, 2026.
W naszej ocenie warto przenieść tę zasadę do projektu nawet bez korzystania z tej usługi: proces agenta powinien móc zniknąć bez utraty informacji o wykonanych działaniach. Historia rozmowy pomaga modelowi kontynuować zadanie. Rejestr operacji musi dodatkowo umożliwiać ustalenie, czy narzędzie wykonało żądanie. Streszczenie konwersacji może pominąć szczegół potrzebny do takiej weryfikacji.
Trwały zapis też ma cenę. Może zawierać dane klientów, wyniki narzędzi i poufne dokumenty. Trzeba określić zakres zapisu, dostęp i retencję. Nie proponujemy archiwizowania wszystkiego bez ograniczeń.
Co dopisać do kryteriów odbioru systemu AI
DDIA daje język do rozmowy o stanie, opóźnieniach i awariach. W projekcie AI dochodzi ocena poprawności znaczeniowej: czy model zrozumiał intencję, oparł odpowiedź na właściwym źródle i wybrał dopuszczalne działanie. Poprawny zapis w bazie nie dowodzi poprawności tej decyzji. Potrzebne są oba rodzaje sprawdzeń.
Zamiast kończyć pilotaż na kilku udanych rozmowach, proponujemy przeprowadzić pięć prób:
- Zmienić dokument źródłowy i sprawdzić, kiedy nowa wersja pojawia się w odpowiedziach.
- Cofnąć użytkownikowi dostęp i ponowić pytanie o wcześniej dostępny dokument.
- Przerwać połączenie po wykonaniu operacji i sprawdzić, czy ponowienie nie powiela skutku.
- Zatrzymać proces agenta w połowie zadania i wznowić go na podstawie trwałego stanu.
- Porównać prosty workflow i agenta na tych samych zadaniach, uwzględniając jakość, koszt całej sprawy, czas zakończenia i interwencje człowieka.
To propozycja testów Lazarus Systems, bez deklaracji uzyskanych wyników. Dla każdego testu należy wcześniej określić oczekiwane zachowanie i warunek zatrzymania. Do przeglądu architektury warto przynieść zapis jednej takiej awarii wraz z dowodem, że system potrafił ustalić stan operacji i bezpiecznie dokończyć sprawę.