Homeostat: dlaczego autonomia potrzebuje punktu nastawy

Agent z celami i bez punktu nastawy nie pozostaje autonomiczny długo; dryfuje, a ktoś musi przyjść i go skorygować. Pojęcie, które to naprawia, ma siedemdziesiąt lat i jest niemal nieobecne we współczesnych architekturach agentowych: homeostat Rossa Ashby’ego, maszyna, której całym zadaniem było utrzymanie zestawu zmiennych w dopuszczalnych granicach przez zmienianie własnego zachowania, aż tam wrócą.

Różnica między celem a punktem nastawy

Cel to miejsce docelowe: skrócić czas dostawy, podnieść marżę, wyczyścić zaległości. Cele są tym, czym ludzie się nawzajem brefują, i są prawie bezużyteczne jako jedyna instrukcja dla systemu autonomicznego, bo każdy cel gnany wystarczająco daleko zaczyna zjadać coś innego.

Punkt nastawy to zakres, w którym zmienna musi pozostać. Gotówka powyżej tego. Wykorzystanie zasobów między tym a tym. Czas dostawy poniżej tego. Poziom błędów pod tym. Pojedynczo wyglądają skromnie. Razem opisują obwiednię, w której firma nadal jest tą firmą.

System autonomiczny potrzebuje obu. Cele mówią mu, w którą stronę pchać. Punkty nastawy mówią, czego po drodze nie wolno złamać — i to ta druga lista, nie pierwsza, pozwala zostawić system włączony na noc.

Co Ashby faktycznie zbudował

Homeostat to były cztery jednostki, każda ze swoją zmienną, każda podłączona do pozostałych i każda zdolna zmienić własną konfigurację, gdy jej zmienna wyszła poza zakres. Nie wiedział, jaka konfiguracja jest właściwa. Szukał, dopóki wszystkie zmienne nie wróciły w granice — a potem przestawał szukać.

Liczą się tu dwie właściwości. Był samokorygujący bez instrukcji jak — nie potrzebował modelu zakłócenia, tylko sposobu na zauważenie, że jest poza zakresem. I był ograniczony z konstrukcji: dopuszczalny zakres był definicją sukcesu maszyny, a nie refleksją po fakcie.

Ta druga właściwość jest tym, czego brakuje większości systemów agentowych. Mają cele i narzędzia; nie mają definicji „wciąż w normie”, którą sam system stale sprawdza.

Jak to wygląda w systemie biznesowym

Konkretnie: homeostat w systemie operacyjnym firmy to niewielki zestaw zmiennych, które system obserwuje bez proszenia, każda z zakresem i reakcją.

Gotówka poniżej progu: wstrzymaj zobowiązania uznaniowe, eskaluj. Czas realizacji zamówień powyżej pułapu: przealokuj, zanim ktokolwiek poprosi. Spada pewność modelu w jakiejś klasie decyzji: automatycznie zawęź zakres agenta i oddaj więcej ludziom. Rośnie poziom błędów przy automatycznych księgowaniach: cofnij ten proces do trybu wyłącznie propozycji.

Dwa ostatnie są najciekawsze, bo regulowaną zmienną jest własne zachowanie systemu. Agent, który obniża swoją autonomię, gdy jego trafność spada, robi dokładnie to, co homeostat — zmienia konfigurację, żeby wrócić zmienną w zakres.

Dlaczego to bije dłuższą listę reguł

Odruchem, gdy system autonomiczny się rozjedzie, jest dopisanie reguły. To działa na przypadek, który właśnie zobaczyłeś, nie robi nic dla następnego, a po dwóch latach regulamin jest zobowiązaniem, którego nikt w pełni nie rozumie.

Homeostat to odwraca. Zamiast wyliczać zakazane akcje, deklarujesz niewielką liczbę rzeczy, które muszą pozostać prawdziwe. System jest wolny w tej przestrzeni i samokorygujący się na jej krawędziach. Regulamin przestaje rosnąć, bo granicę definiują wyniki, a nie coraz dłuższa lista przewidzianych awarii.

Uczciwe ograniczenia

Homeostat reguluje tylko to, co potrafi zmierzyć. Zmienna, której nikt nie oprzyrządował, może dryfować swobodnie — a to znaczy, że wybór punktów nastawy jest decyzją biznesową i najważniejszą w całym projekcie.

Nie zastępuje też ludzkiego osądu co do tego, która obwiednia jest właściwa. Maszyna Ashby’ego trzymała swoje zmienne w zakresie; nie miała zdania, czy ten zakres jest dobry dla świata na zewnątrz. Nasza też nie ma. To pytanie zostaje tam, gdzie jego miejsce — u ludzi, którzy są właścicielami firmy.