Zaawansowane rozwiązania agentowe

W tej pętli tkwi cała różnica. Klasyczna automatyzacja nie poradzi sobie z danymi wejściowymi, pod które jej nie zaprojektowano. Agent może spróbować, co jest realnie przydatne i jednocześnie stanowi powód, dla którego potrzebuje granic, jakich sztywny workflow nigdy nie wymagał.

Dobrym przykładem jest pisanie opisu produktu. Przy prostym akcesorium wystarczy karta katalogowa. Przy produkcie technicznym sensowny opis potrzebuje modeli porównywalnych, informacji o kompatybilności, czasem dokumentacji serwisowej, a to, które z tych rzeczy mają znaczenie, zmienia się od produktu do produktu. Da się to zapisać jako drzewo decyzyjne, tylko utrzymanie takiego drzewa jest udręką. Agent sam ustala, czego potrzebuje przy konkretnym produkcie.

To samo dotyczy analizy, w której ciekawe pytanie zależy od tego, co pokazują dane, oraz pilnowania spraw operacyjnych, gdzie właściwy następny ruch zależy od tego, co już się wydarzyło. Tam, gdzie ścieżka jest naprawdę stała, agent jest złym narzędziem i zarekomendujemy zwykłą automatyzację.

Definiujemy to jako jawną listę: te źródła danych może czytać, te działania może wykonać, tych nie może wykonać nigdy bez akceptacji człowieka. Agent e-commerce może swobodnie edytować roboczy opis, zaproponować zmianę kategorii do przeglądu i nie mieć żadnej możliwości zmiany ceny. Agent wsparcia może czytać całą historię zgłoszeń i nigdy nie realizować zwrotu pieniędzy.

Niewygodna wersja tego pytania brzmi: co się stanie, gdy agent będzie pewny siebie i jednocześnie w błędzie, bo prędzej czy później tak się zdarzy. Projektowanie pod ten scenariusz to nie pesymizm, tylko różnica między systemem, który można zostawić bez nadzoru, a takim, przy którym ktoś musi siedzieć.

Praktyczna zasada, którą stosujemy: dzielimy działania na odwracalne i nieodwracalne. Poprawiony draft, przeliczona analiza czy zaproponowana zmiana kategorii to rzeczy, które da się cofnąć bez konsekwencji, więc mogą działać swobodnie. Wysłany mail do klienta, opublikowany opis, zmieniona cena i wszystko, co dotyka pieniędzy, wymaga potwierdzenia. Ten podział jest łatwiejszy do obrony w rozmowie z zespołem niż lista wyjątków budowana przypadek po przypadku.

Dostajesz wtedy liczbę, do której możesz się odnieść przy zmianie promptu, podmianie modelu czy dodaniu narzędzia, a to ma większe znaczenie, niż brzmi. Bez tego strojenie agenta jest zgadywanką i bardzo łatwo wprowadzić zmianę, która poprawia przypadek akurat oglądany i po cichu psuje trzy inne.

Na produkcji zapisujemy też przebieg każdego uruchomienia. Gdy wynik jest zły, zapis pokazuje, który krok zawiódł, a to zwykle da się naprawić w opisie narzędzia albo w brakującym kontekście, zamiast wynikać z czegoś fundamentalnego w samym modelu.

To właśnie ten materiał powinien decydować o samodzielności. Po kilku tygodniach zwykle okazuje się, że część typów działań agent obsługuje lepiej, niż zakładano, a jeden czy dwa myli konsekwentnie i w konkretny sposób. Pierwszej grupie zdejmujesz obowiązek akceptacji, drugą albo naprawiasz, albo na stałe zostawiasz pod akceptacją człowieka. To wolniejsze niż włączenie wszystkiego naraz i dlatego taki system działa jeszcze pół roku później.