Architektura sztucznej inteligencji dla agentów produkcyjnych: tryby awarii i warstwy kontroli

Dlaczego prototypy zawodzą

Systemy AI produkcyjne rzadko zawodzą z powodu słabych modeli. Zawodzą dlatego, że architektura otaczająca model nigdy nie zaakceptowała niedeterminizmu jako ograniczenia projektowego. Trzy sprzeczności kształtują niemal każdą późniejszą decyzję: możliwości wobec kontrolowalności, opóźnienia wobec dokładności oraz autonomia wobec możliwości audytu.

Dobrzy architekci pytają najpierw dlaczego, a dopiero potem co. Bez filozofii projektowej lista komponentów jest jedynie listą kontrolną. Z nią staje się ona ramowaniem, które obejmuje również problemy, z którymi nikt jeszcze nie miał do czynienia.

Ta filozofia odwraca powszechny założenie. Tradycyjna architektura oczekuje, że komponenty będą wykonywać dokładnie to, co przewidują ich specyfikacje, co pozostawia architektowi zadania związane z ukierunkowaniem ruchu, skalowalnością i tolerancją na błędy. Tutaj sam komponent jest źródłem niepewności, więc otaczający go system musi ją pochłaniać, mierzyć i ograniczać na każdym poziomie.

Jak faktycznie umierają systemy AI

Większość awarii w produkcji wynika z traktowania systemu probabilistycznego tak, jakby był deterministycznym API. Poniżej znajduje się przybliżona klasyfikacja sposobów, w jakie może dojść do błędu.

Hallucynacje jako problem wyszukiwania

Ludzie zazwyczaj zaliczają halucynacje do problemów związanych z jakością modelu. Z punktu widzenia architektury są to luka w procesie wyszukiwania informacji, błąd w zarządzaniu oknem kontekstowym lub niepowodzenie w kalibracji poziomu pewności. Gdy poprosimy model o przetworzenie 200-stronicowego dokumentu, do którego pasuje zaledwie 4 000 tokenów, nie będzie w stanie zidentyfikować brakujących danych, więc wymyśla resztę. Rozwiązanie leży w samym systemie: precyzyjne wyszukiwanie informacji, określony budżet na obsługę kontekstu oraz jasne uwzględnienie niepewności poprzez instrukcje systemowe i schemat wyjściowy.

Trzy rodzaje dewiacji

Zespoły często łączą w jedno trzy odrębne zjawiska. Drift modelu występuje, gdy dostawca aktualizuje podstawowy model i zmienia się jego zachowanie, mimo że po twojej stronie nic nie zostało wdrożone. Drift danych ma miejsce, gdy zmieniają się dane wejściowe – na przykład agent obsługi klienta, który był przyzwyczajony do wzorców zapytań sprzed 2024 roku, zaczyna mieć trudności z pytaniami dotyczącymi nowych produktów. Drift wiedzy pojawia się, gdy świat się rozwija, a to, czego nauczył się model, staje się przestarzałe. Każde z tych zjawisk wymaga swojego sposobu wykrywania i naprawy.

Błędy przekraczające granice agentów

Systemy wieloagentowe stwarzają bardziej subtelny problem. Agent A wytwarza nieco błędny wynik, agent B przyjmuje go za fakt, a agent C podejmuje nieodwracalną akcję na podstawie błędnego rozumowania B. Gdy błąd się ujawni, znalezienie jego źródła jest niemal niemożliwe. Pomagają trzy zabezpieczenia: agenci wymieniają się ocenami pewności, przekazy poniżej ustalonej granicy pewności uruchamiają mechanizm awaryjny, a każda granica agenta zapisuje dane do logu audytowego dostępnego wyłącznie do dodawania nowych informacji.

Zanieczyszczenie kontekstu

Długie rozmowy oraz mnóstwo historii wywołań narzędzi wypełniają okno kontekstowe materiałem, który pogarsza wydajność. Uwaga rozprzestrzenia się po coraz większej ilości informacji, a kluczowe instrukcje przesuwają się ku środkowi, gdzie uwaga jest najmniejsza. Projektanci potrzebują celowego cyklu życia kontekstu: mechanizmów uruchamiających podsumowywanie, strategii kompresji oraz wyraźnego rozdzielenia pamięci roboczej od pamięci długoterminowej.

Pętle ponawiania prób

Agenty wyposażone w narzędzia mogą popadać w patologiczne zachowania polegające na ciągłym ponawianiu prób. Wyszukiwanie zwraca niejednoznaczne wyniki, agent przepisuje zapytanie, nowe zapytanie jest równie niejednoznaczne, a cykl trwa, dopóki nie wyczerpie się kontekst lub nie zostanie osiągnięty limit częstotliwości. Jeśli warstwa orkiestracji nie posiada funkcji wykrywania pętli, budżetów kroków oraz warunków zakończenia, systemy oparte na agentach regularnie marnują tokeny, czas i pieniądze na podzadania, których nie da się rozwiązać.

Iniekcja poprzez treści zewnętrzne

Agent, który czyta e-maile, przetwarza dokumenty lub przegląda internet, może napotkać treści zawierające wrogie instrukcje mające na celu przejęcie kontroli nad nim. To nie jest kwestia bezpieczeństwa modelu. Jest to klasyczny atak typu injection na granicy między danymi zaufanymi a niesaufanymi. Obrony są strukturalne: wykonywanie w izolowanej środowisku, ścisłe oddzielenie warstwy instrukcji od warstwy danych oraz weryfikacja wyników według określonego schematu przed podjęciem jakichkolwiek działań.

Brak ciągłej oceny

Najczęstszym powodem powolnego degradowania się systemów jest brak warstwy ciągłej oceny. Zespół wypuszcza model, celebuje demo, a następnie traktuje go jak statyczną API. Każda aktualizacja dostawcy, każda zmiana schematu w korpusie RAG oraz każda zmiana w grupie użytkowników może coś zepsuć, a bez ocen pierwszym sygnałem jest skarga użytkownika.

Platforma jako zbiór komponentów

Pliatforma AI dla przedsiębiorstw nie jest monolitem. To zbiór systemów, z których każdy ma własne obowiązki, umowy interfejsowe oraz sposoby awarii. Projekt musi obejmować cały cykl życia żądania (przyjmowanie danych, budowa kontekstu, wywołanie modelu, uruchomienie narzędzia, walidacja odpowiedzi, możliwość obserwacji), zakładając przy tym, że każda warstwa może ulec awarii.

Pobieranie to proces ciągły

Generowanie wzbogacone o wyszukiwanie jest bardziej złożone, niż sugeruje nazwa. System produkcyjny to nie tylko umieszczanie dokumentów, wyszukiwanie wektorów i wklejanie kontekstu. To łańcuch przetwarzania składający się z co najmniej pięciu etapów, z których każdy może pójść nie tak: pobieranie i dzielenie na fragmenty, wybór modelu do embedowania oraz zarządzanie wersjami, budowa indeksu i częstotliwość jego aktualizacji, ranking wyników wyszukiwania przy użyciu hybrydy metod gęstych i rzadkich, oraz tworzenie kontekstu z uwzględnieniem progów istotności. Każdy etap wymaga własnych metryk, a zmiana w jednym może pogorszyć jakość pozostałych, bez że ktokolwiek by to zauważył.

Cztery poziomy pamięci agenta

Pamięć agenta powinna być podzielona na cztery poziomy:

• Pamięć robocza to okno kontekstowe w ramach danej sesji.
• Pamięć epizodyczna przechowuje streszczenia poprzednich rozmów, dostępne w ramach danej sesji.
• Pamięć semantyczna to wiedza przedsiębiorstwa, która stanowi warstwę RAG.

Pamięć proceduralna przechowuje nabyte wzorce używania narzędzi oraz heurystyki specyficzne dla danej dziedziny.

Zatracenie tego rozróżnienia jest częstą przyczyną zanieczyszczenia kontekstu oraz niespójnego zachowania agentów w kolejnych sesjach.

Systemy wieloagentowe i przekazywanie obowiązków

W niewielkich skali pojedynczy agent stanowi już rozwiązane zadanie. Projektowanie systemów wieloagentowych to trudny obszar, w którym problemy wynikają z kosztów koordynacji, konieczności zachowania spójności stanu wspólnego, propagacji błędów oraz zachowań emergentnych, których żaden pojedynczy agent nie wykazywałby.

Najbardziej zaniedbywanym elementem jest protokół przekazywania informacji, czyli umowa określająca, co jeden agent przekazuje drugiemu. Minimalna struktura zawiera stan zadania, wynik oceny pewności, zrealizowane kroki w celu usunięcia duplikatów, odniesienia do istotnego kontekstu (a nie całego kontekstu, co doprowadziłoby do przepełnienia pamięci) oraz wszelkie ograniczenia stwierdzone w trakcie przekazywania. Bez ustalonego schematu agenci przekazują informacje w formie swobodnego języka naturalnego, a odbiorca musi ponownie interpretować intencję, co stanowi główne źródło błędów i ich nasilenia.

Zespoły muszą również zdecydować, w jaki sposób agenci dzielą się pamięcią. Zachowanie prywatnej pamięci dla każdego agenta ułatwia jej analizę i audyt, ale powoduje duplikację operacji pobierania danych oraz może prowadzić do różnic w stanie między agentami. Wspólna tablica kontrolna wspiera koordynację, jednak wymaga kontroli równoczesności, wersjonowania oraz logiki unieważniania danych. Zalecanym standardem jest prywatna pamięć, przy której wyraźne zdarzenia publikacji w wersjonach przesyłają wyniki do wspólnego magazynu po zakończeniu zadania.

Zasady bezpieczeństwa to struktura

Zasady bezpieczeństwa nie są dodatkową funkcją montowaną w systemie sztucznej inteligencji produkcyjnej. Są to właściwości strukturalne. System pozbawiony warstwowych zasad bezpieczeństwa to nie tylko system sztucznej inteligencji bez funkcji ochronnych – to zupełnie inny typ systemu, który nie powinien znajdować się w środowisku przedsiębiorstwa.

Stopnieowane hamulce awaryjne

Każdy system produkcyjny potrzebuje czegoś więcej niż pojedynczego przycisku wyłączającego. Potrzebuje szeregu możliwych reakcji:

• Ograniczanie szybkości przetwarzania spowalnia działanie, ale nie zatrzymuje go całkowicie.
• Obniżenie funkcjonalności powoduje wyłączenie dostępu do narzędzi i przechodzenie w tryb służący wyłącznie do dostarczania informacji.
• Routowanie przez ludzi kieruje wszystkie żądania do agentów ludzkich.
• Zakończenie sesji kończy aktywne sesje agentów w sposób uporządkowany, zachowując jednocześnie stan audytowy.
• Całkowite zatrzymanie wyłącza wszystko w sposób nieodwracalny i przechowuje stan forensic.

Każda z tych funkcji musi być możliwa do przetestowania w środowisku produkcyjnym, ponieważ zatrzymanie awaryjne, którego nigdy nie przetestowano, takim nie jest.

Najważniejsza jest możliwość odwrócenia działań

Bезpieczeństwo treści przyciąga najwięcej uwagi, jednak ważniejszym pytaniem jest to, czy dany czynność można odwrócić. Jeśli agent wysyła niewłaściwy e-mail, usuwa wiersz z bazy danych, dokonuje płatności lub wdraża infrastrukturę, nic nie może tego cofnąć. Każde narzędzie powinno być ocenione pod kątem możliwości odwrócenia działań – im trudniejsze jest cofnięcie czynności, tym wyższy powinien być poziom pewności systemu przed podjęciem dalszych działań bez udziału człowieka.

Szczegóły oceny

Wiele projektów korporacyjnych teoretycznie spełnia „najlepsze praktyki”, ale w praktyce nie przynosi żadnych rezultatów. Kwartalna ludzka ocena 50 wybranych wyników to jedynie pozory bezpieczeństwa, a nie rzeczywista struktura oceny. Prawdziwa struktura funkcjonuje nieprzerwanie, automatycznie i jest połączona z systemem monitorowania.

Wykorzystanie modelu jako sędziego

Obecnie najskuteczniejszym sposobem na ciągłą kontrolę jakości jest używanie drugiego modelu językowego do oceny wyników pierwszego, co umożliwia ocenę odpowiedzi otwartych, których nie da się sprawdzić za pomocą dopasowywania ciągów znaków. Jednak metoda ta również niesie ze sobą określone problemy. Osoby dokonujące ocen wykazują uprzedzenia pozycyjne, faworyzując dłuższe lub wcześniejsze odpowiedzi. Ponadto wykazują samouprzedmiotowienie – na przykład Claude ocenia wyniki w stylu Claude jako wyższej jakości. Mogą również powodować kaskadowe halucynacje, deklarując, że dana odpowiedź jest faktograficzna, podczas gdy tak nie jest. Skuteczne implementacje wykorzystują zestawy testowe typu adwersarialny, regularnie kalibrują się na podstawie ocen ludzkich i dołączają wskaźniki niepewności do własnych werdyktów.

Oceny w ramach procesu wdrażania

Ocena nie powinna być jedynie sporadycznym dodatkowym zadaniem. Aktualizacje modeli, edycje promptów, odświeżanie korpusu danych oraz zmiany schematu narzędzi powinny uruchamiać automatyczne zestawy testów oceniających, a regresje w kluczowych metrykach powinny blokować wydanie produktu. Oznacza to ustalenie minimalnych progów dla każdej metryki, które stanowią część umowy serwisowej. Mikrosłużba, która nie przechodzi testów jednostkowych, nie może zostać wdrożona, podobnie jak system AI, który nie przejdzie testów oceniających.

Obserwowalność w przypadku otwartego przestrzeni stanów

Obserwowanie systemu AI różni się od obserwowania mikrosłużby pod jednym kluczowym względem: przestrzeń stanów nie ma granic. Mikrosłużba albo prawidłowo obsłużyła żądanie, albo nie. Odpowiedź systemu AI znajduje się gdzieś na ciągłej skali jakości, a to, czy była dobra, może zależeć od kryteriów, które można zmierzyć tylko poprzez kolejne wezwanie modelu. To wymaga zupełnie innego podejścia do projektowania obserwowalności.

Dla każdej prośby do LLM minimalny użyteczny zapis obejmuje:

• pełny prompt, po wygenerowaniu szablonu i przed skróceniem
• zdobyty kontekst wraz z jego źródłami
• dokładną odpowiedź modelu, przed postprocesowaniem
• szczegółowy rozkład użycia tokenów
• opóźnienie na każdym etapie (zdobywanie danych, model, postprocesowanie)
• wskaźniki oceny, jeśli zostały obliczone synchronicznie
• każde wezwanie narzędzia i jego odpowiedź
• sygnały pewności lub niepewności, gdy model je ujawnia
• pseudonimizowane identyfikatory sesji i użytkownika
• identyfikatory wersji dla każdego zaangażowanego elementu: modelu, szablonu promptu, indeksu oraz schematu narzędzia

Najważniejsze są identyfikatory wersji. Bez nich powiązanie regresji jakości z konkretną zmianą jest domysłem.

Trzy sygnały odchylenia

Rozpoznawanie odchylenia polega na obserwowaniu trzech sygnałów jednocześnie. W przypadku odchylenia w rozkładzie danych wejściowych pytanie brzmi, czy przychodzące żądania różnią się statystycznie od tych, na których dostosowano system – co odległość w przestrzeni embeddingów, np. podobieństwo kosinowe względem korpusu referencyjnego, może ujawnić przed spadkiem jakości. W przypadku odchylenia jakości wyników pytanie brzmi, czy oceny spadają, co wymaga ciągłej ewaluacji, a nie jedynie okresowych sprawdzeń. W przypadku odchylenia w zachowaniu modelu pytanie brzmi, czy dostawca potajemnie zmienił model – dlatego należy regularnie przeprowadzać testy z użyciem deterministycznego zestawu referencyjnego dla każdego modelu, wysyłając alerty, gdy różnica przekroczy określony próg.

Koszt to architektura

Koszt jest aspektem, który najczęściej pomija się w dyskusjach na temat architektury sztucznej inteligencji, i to właśnie on jako pierwszy ulega problemom w skali przedsiębiorstw. System, który spełnia wszystkie wymagania techniczne, ale kosztuje 4 dolary za zapytanie, nie przetrwa pierwszej oceny operacyjnej. Traktuj koszt jako ograniczenie architektoniczne, a nie kwestię finansową rozważaną później.

Przekierowywanie do najtańszego odpowiedniego modelu

Najważniejszym elementem jest inteligentne przekierowywanie modeli, które kieruje każde zapytanie do najtańszego modelu nadal spełniającego wymagania jakościowe. Wymaga to funkcji przekierowywania, która klasyfikuje poziom złożoności (prosta wyszukiwarka faktów, wieloetapowe rozumowanie lub generowanie kodu), przyporządkowuje każdą klasę do określonego poziomu modelu i zapewnia alternatywę w przypadku niepowodzenia przekierowania. Sam router może być małym, szybkim klasyfikatorem, a jego koszt zwykle zostaje zrekompensowany już przy pierwszym udanym wysłaniu zapytania do tańszego poziomu modelu.

Kasowanie semantyczne

Zwykłe cacheowanie sprawdza się słabo w aplikacjach opartych na LLM, ponieważ żądania o identycznym znaczeniu rzadko odpowiadają sobie jako ciągi znaków. Cacheowanie semantyczne indeksuje odpowiedzi na podstawie bliskości w przestrzeni embeddingów, a nie dokładnego tekstu, osiągając wskaźniki trafień od 30 do 60 procent przy dużym obciążeniu, pozostając jednocześnie niewidocznym dla warstwy aplikacji. Wymaga szybkiego, przybliżonego indeksu najbliższych sąsiadów, progu podobieństwa poniżej którego zmuszane jest wystąpienie błędu, oraz polityki TTL dostosowanej do tempa starzenia się wiedzy.

Budżety tokenów

W warunkach produkcyjnych około 60 do 80 procent zużycia tokenów pochodzi zazwyczaj od promptów systemowych, schematów narzędzi oraz pobranego kontekstu, a nie od wiadomości użytkowników czy odpowiedzi modelu. Dlatego zarządzanie budżetem powinno odbywać się na poziomie konfiguracji: należy dynamicznie dostosowywać prompty systemowe, tak aby uwzględniane były tylko te sekcje istotne dla danego typu zapytania, ładować schematy narzędzi w sposób opóźniony, tak aby wprowadzano tylko te wybrane przez planistę, oraz dzielić okno kontekstowe na poziomy, tak aby fragmenty o wysokiej istotności pozostawały w głównym kontekście, natomiast te o niższej istotności pojawiały się jako skompresowane streszczenia.

Zero trust dla agentów

Koncepcja zero trust została zaprojektowana dla użytkowników ludzkich i statycznych usług. Zastosowanie jej do agentów oznacza rozszerzenie tej koncepcji, aby obejmowała dynamiczne zestawy możliwości, zmieniający się poziom pewności oraz możliwość podejmowania działań w imieniu użytkowników bez konieczności wyraźnej zgody na każdą akcję.

Tożsamość dla każdego agenta

Każdy agent w procesie produkcyjnym potrzebuje własnej tożsamości kryptograficznej, odrębnej od użytkownika, dla którego pracuje, oraz od innych agentów. Dane uwierzytelniające powinny być powiązane z sesją i wygasać po jej zakończeniu. Powinny być ograniczone pod względem uprawnień, tak aby dane te kodowały to, co agent może robić, a nie tylko to, kim jest. Każde wydanie i cofnięcie uprawnień powinno być zapisywane w sposób niezmienialny. Dzięki temu ślad audytowy pozwala odpowiedzieć na pytanie, który agent, przy użyciu jakich uprawnień, podjął określoną czynność dla danego użytkownika i w jakim czasie – co ma kluczowe znaczenie podczas dochodzeń w sprawach incydentów.

Rozdzielone instrukcje od danych

Najważniejszą zasadą bezpieczeństwa w sztucznej inteligencji agentowej jest przechowywanie instrukcji i danych na oddzielnych poziomach. Niezaufane źródła nigdy nie mogą zanieczyścić poleceń systemu. W praktyce dane z zewnątrz przechodzą przez warstwę oczyszczania przed dotarciem do kontekstu, pobrany treść otrzymuje etykietę zaufania, a model jest instruowany, by traktować tekst o niskim poziomie zaufania jako materiał do analizy, a nie jako polecenia. Jest to analogiczne do zapytań SQL parametryzowanych: ta sama zasada, inna implementacja.

Zarządzanie zaprojektowane od podstaw

Zarządzanie sztuczną inteligencją to nie tylko pola do zaznaczenia w celu spełnienia wymogów. To ciągła dyscyplina operacyjna, która wymaga wsparcia architektonicznego. Organizacja nie może zarządzać systemem, którego nie może obserwować, nie może przeprowadzić audytu systemu, który nie rejestruje danych, ani nie może egzekwować zasad w systemie, który nie został stworzony do ich realizacji. Zarządzanie musi być wbudowane, a nie dodawane później.

Zasady jako kod

Zasady umieszczone w dokumentach prozowych nie mogą być zarządzane na dużą skalę. Potrzebne jest zasady w formie kodu: reguły czytelne dla maszyn, przechowywane w systemie kontroli wersji, poddawalne testom i ewaluowane przez bramkę AI w czasie wykonywania. Open Policy Agent z językiem Rego to dojrzała opcja – może on kodować reguły takie jak „żadne decyzje skierowane do klientów w UE nie mogą być podejmowane przez ten model, chyba że wynik zawiera flagę weryfikacji przez człowieka” lub „ten agent nie może używać narzędzia do płatności na danych sklasyfikowanych jako PII”. Ewaluacja w bramce tworzy jeden punkt egzekwowania oraz kompletny rejestr audytowy, co zastępuje rozproszone, niespójne i niewymagane do egzekwowania zasady typowe obecnie w korporacyjnych systemach AI.

Prawo do wyjaśnienia

Rozporządzenia takie jak akt UE dotyczący sztucznej inteligencji, w połączeniu z zarządzaniem ryzykiem w przedsiębiorstwach, coraz częściej wymagają, aby decyzje podejmowane przy użyciu sztucznej inteligencji były zrozumiałe dla osób, na których wpływają. Jest to wymóg architektury, a nie kwestia możliwości modelu. Nawet model, który nie potrafi wyjaśnić swoich rozumowań, może uczestniczyć w systemie umożliwiającym wyjaśnienia, jeśli architektura rejestruje informacje otrzymane przez model, narzędzia, których użył, opcje, które rozważył, oraz stopień pewności co do wyniku. Ślad audytowy musi być zaprojektowany tak, aby umożliwić udzielenie wyjaśnienia podczas przeprowadzania audytu, a nie być odtwarzany później na podstawie dostępnych logów.

Architektura jest produktem

System AI gotowy do produkcji nie jest definiowany jakością jego modelu językowego. Jest definiowany stopniem zaawansowania architektury otaczającej ten model. Model jest komponentem – potężnym, cennym i trudnym do zastąpienia – ale nadal tylko komponentem.

Architektura AI to sztuka budowania systemów, które pozostają niezawodne, poddawalne kontroli i podlegające ulepszeniom w miejscu, gdzie nieokreśloność AI spotyka się z deterministycznymi zasadami oprogramowania korporacyjnego. Każda warstwa odpowiada na jedno pytanie:

• Jak zapobiec złym wynikom? Za pomocą zasad bezpieczeństwa.
• Jak zauważyć spadek jakości? Poprzez oceny oraz możliwość obserwacji.
• Jak koordynować kilka komponentów AI? Za pomocą topologii wielu agentów i protokołów przekazywania zadań.
• Jak zapobiec wzrostowi kosztów? Poprzez budżety tokenów i kierowanie modelem.

Jak upewnić się, że odbywają się tylko uprawnione działania? Dzięki zasadzie zerowego zaufania oraz uprawnieniom narzędzi.

Jak zadowolić organy regulacyjne i audytorów? Dzięki architekturze zarządzania.

Każdy, kto dopiero zaczyna pracę w tej dziedzinie, powinien zrozumieć, że architektura AI to nie jest po prostu gałąź architektury oprogramowania. To odrębna dyscyplina, posiadająca własne elementy bazowe i modele myślowe, która traktuje niepewność jako główną ograniczającą czynnik projektowy, a nie jako przypadek szczególny. Projektujmy z myślą o zmienności, a nie o oczekiwanym wyniku. Patrzmy na rozkład, a nie na średnią. System, który dobrze radzi sobie z najgorszymi 5 procentami przypadków, to ten, który zasługuje na to, by obsługiwać pozostałe 95 procent w środowisku produkcyjnym.

Literatura pokrewna

• Budowa harnessa dla DeepAgents: uprawnienia, podagenty i zatwierdzenie przez człowieka — Praktyczne kroki budowy narzędzia do projektowania systemów z wykorzystaniem DeepAgents: serwery plikowe, reguły uprawnień, podagenty, mechanizmy zatwierdzenia, umiejętności i MCP, a także sytuacje, gdy ocena modelu nadal zawodzi.
• Wykorzystanie narzędzi produkcyjnych przez agenty: pochodzenie danych, próby ponowne i możliwości obserwacji — Agent banku niewłaściwie wywołał płatną API i wymyślił numer telefonu. Poznaj minimalne zestawy narzędzi, źródła parametrów, trójpoziomowe próby ponowne oraz metryki dla poszczególnych narzędzi.