Agent, który reguluje sam siebie
Większość pracy nad bezpieczeństwem agentów dotyczy świata zewnętrznego: czego agentowi wolno dotknąć, jakie narzędzia może wywołać, czyjej zgody potrzebuje. To ważne — i omija zmienną, która naprawdę zapowiada kłopoty: własne zachowanie agenta. Agent, który zauważa spadek swojej trafności i sam zawęża zakres, jest bezpieczniejszy niż taki trzymany w ryzach dłuższą listą reguł, bo reguły pokrywają tylko awarie, które ktoś już sobie wyobraził.
Cztery zmienne warte obserwowania
Koszt. Tokeny, wywołania, czas na zegarze. To nie jest przede wszystkim kwestia budżetu: zadanie, które nagle kosztuje pięć razy więcej niż zwykle, jest zadaniem, które poszło źle — a koszt to najtańszy wczesny sygnał, jaki dostaniesz.
Pewność skalibrowana na wynikach. Nie deklarowana pewność modelu, która sama w sobie jest bliska bezużyteczności, tylko historyczna skuteczność dla tej klasy decyzji. Jeśli propozycje tego rodzaju były przyjmowane dziewiętnaście razy na dwadzieścia, to jest liczba, wobec której da się regulować.
Wskaźnik poprawek. Jak często poprawiasz albo odrzucasz to, co wyprodukował, w podziale na typ zadania. Rosnący wskaźnik poprawek w jednej klasie pracy jest najczystszym sygnałem, że coś się zmieniło wyżej — nowy format dokumentu, przesunięty proces, aktualizacja modelu.
Faktycznie używana autonomia. Ile agent robi bez pytania w porównaniu z tym, ile mu wolno. Powolne pełzanie w stronę sufitu zasługuje na uwagę nawet wtedy, gdy nic złego się jeszcze nie stało.
Reakcja musi być automatyczna
Mierzenie to łatwiejsza połowa. Liczy się to, co dzieje się, gdy zmienna wychodzi z zakresu — a odpowiedź musi brzmieć: agent reaguje, zanim zrobisz to Ty.
Wskaźnik poprawek przy ekstrakcji faktur się podwaja: to zadanie wraca do trybu wyłącznie propozycji, a Ty dostajesz o tym informację. Koszt zadania skacze: agent zatrzymuje się i pyta, zamiast wydawać. Pewność w klasie decyzji spada poniżej punktu nastawy: granica dla tej klasy zawęża się automatycznie. Coś wygląda anomalnie w sposób, którego agent nie umie zaklasyfikować: robi najmniejszą odwracalną rzecz i eskaluje.
To jest wzorzec homeostatu — system zmieniający własną konfigurację, żeby wrócić zmienną w zakres. Zastosowany do agenta, zmienianą konfiguracją jest to, ile wolności właśnie sobie bierze, czyli dokładnie właściwe pokrętło.
Dlaczego to bije dłuższy regulamin
Odruchem po incydencie jest dopisanie kolejnej reguły. To pokrywa przypadek, który właśnie zobaczyłeś, i nic więcej — a po dwóch latach regulamin jest zobowiązaniem, którego nikt w pełni nie rozumie.
Samoregulacja to odwraca. Zamiast wyliczać zakazane akcje, deklarujesz niewielką liczbę rzeczy, które muszą pozostać prawdziwe o wydajności samego agenta. Wewnątrz tej obwiedni jest wolny, na jej krawędziach koryguje się sam. Regulamin przestaje rosnąć, bo granicę wyznaczają wyniki, a nie coraz dłuższa lista przewidzianych awarii.
Degraduje się też we właściwą stronę. System regułowy, który spotyka nieprzewidzianą sytuację, albo blokuje coś niegroźnego, albo przepuszcza coś, czego nie powinien. Samoregulujący się robi się cichszy i ostrożniejszy — czyli dokładnie tak, jak ma się psuć oprogramowanie działające w Twoim imieniu.
Części niewygodne
Homeostat reguluje tylko to, co potrafi zmierzyć. Wybór zmiennych jest najważniejszą decyzją projektową w całym systemie, a cokolwiek nieoprzyrządowane może dryfować swobodnie.
Jest też realne napięcie z użytecznością. Agent nastrojony zbyt ciasno wycofuje się do trybu propozycji przy pierwszym zachwianiu i staje się wolniejszym sposobem na robienie swojej roboty samemu. Punkty nastawy są decyzją produktową, a nie polem do odhaczenia w bezpieczeństwie — i powinny być widoczne oraz przestawialne, a nie zakopane.
Co jest ostatnim argumentem za open source w tym projekcie: regulator, którego nie możesz obejrzeć, jest po prostu kolejną rzeczą do zaufania. A o to właśnie chodzi, żeby nie musieć.
- homeostat
- samoregulacja
- autonomia
- niezawodność