Trzydzieści pięć zadań AI zamiast jednego asystenta

Dlaczego to nie jest jeden prompt

Typowy system oparty o AI ma jeden prompt systemowy i kilka przełączników. Broni się, dopóki wszystkie zadania są do siebie podobne. Przestaje w momencie, w którym jedno zadanie musi być tanie i masowe, a drugie ostrożne i drogie.

Tutaj każde wywołanie modelu przechodzi przez jedną funkcję i trafia do jednego rejestru. Za tą funkcją stoi trzydzieści pięć osobnych zadań: pisanie odpowiedzi do klienta, wyciąganie faktów z wątku, klasyfikacja nadawcy, składanie propozycji menu, rozpoznanie, że klient nawiązuje do współpracy sprzed roku, profilowanie klienta po zakończonej realizacji, audytor szukający błędów w danych i kolejne dwadzieścia osiem.

Każde ma własny prompt, własny model domyślny, własny próg eskalacji i własny wiersz w audycie. Administrator widzi na jednym ekranie treść instrukcji każdego zadania, model, którym jest obsługiwane, liczbę wywołań i koszt. Prompty są widoczne, bo mają być rozliczalne.

Decyzje o ryzyku podejmuje kod, nie model

Instrukcja w prompcie to prośba. Sprawdzenie na wyjściu to gwarancja. Cała architektura stoi na tym rozróżnieniu.

Zbudowaliśmy dwadzieścia dwa niezależne mechanizmy, które pracują dopiero po tym, jak model coś napisał. Cytat, na który powołuje się ekstrakcja faktu, jest normalizowany i sprawdzany w treści wiadomości. Jeśli go tam nie ma, wartość pola może zostać przyjęta, ale cytat jest kasowany. Niezweryfikowany cytat nigdy nie pokaże się operatorce jako dowód.

Pole poprawione ręcznie jest zablokowane. Model nie ma fizycznej możliwości go nadpisać, niezależnie od tego, co odczyta w kolejnej wiadomości.

Osobny kontroler skanuje każdą wychodzącą wiadomość marketingową pod kątem czterech rzeczy: niewypełnionego miejsca na imię, błędnej formy gramatycznej pod podpisem, kwoty w treści i myślnika użytego jako łącznik. Te reguły nie powstały z domysłu. Powstały po przebadaniu sześciuset siedemdziesięciu jeden wcześniej wygenerowanych wiadomości i policzeniu, ile razy każdy z tych błędów faktycznie wystąpił. Kontroler blokuje wysyłkę, a nie ostrzega.

Pamięć warstwowa zamiast wielkiego kontekstu

Wiedza o kliencie nie jest jednym blokiem tekstu wrzuconym do promptu. Jest destylowana warstwami.

Po każdej zamkniętej realizacji rusza skan pojedynczego zdarzenia: co klient pokochał, jakie szczegóły zapamiętał, co budziło zastrzeżenia. Takich skanów powstało ponad tysiąc. Nad nimi stoi druga warstwa, która bierze do dwudziestu skanów jednego klienta razem z uwagami operatorki i syntetyzuje jeden profil: kim jest, jak się zachowuje, po co wraca, czego unikać. Profili jest ponad pięćset.

Ma to konsekwencję kosztową. Synteza czyta dane już zdestylowane, nie surowe wątki, więc koszt profilu nie rośnie liniowo z liczbą zamówień klienta.

Funkcja zbierająca pamięć klienta jest jedna i ma trzech odbiorców: prompt, który pisze odpowiedź, blok raportu dla operatorki i panel w interfejsie. Trzy miejsca liczące po swojemu, co wiadomo o kliencie, rozjechałyby się w ciągu miesiąca.

Tania szyna i droga szyna

Wybór modelu idzie po tożsamości modelu, nie po nazwie zadania. Sama nazwa decyduje, na którą szynę trafi wywołanie, więc w jednym systemie mieszamy tanią pracę wsadową z drogą jakością bez zmiany choćby jednej linii tam, gdzie wywołanie faktycznie się odbywa.

Łańcuch awaryjny jest warstwowy: dostawca podstawowy, potem kolejni skonfigurowani, na końcu szyna płatna. Wejście na tę ostatnią ma wąską listę uprawnionych: pisanie odpowiedzi do klienta, raport sytuacyjny, asystent wewnętrzny, strategia na żądanie, audyt sprawy i pętla opinii. Sześć zadań z trzydziestu pięciu.

Powód jest zapisany w kodzie obok samej reguły, żeby nie mógł się z nią rozjechać. Awaria taniego dostawcy nie ma prawa przełożyć się na masowy rachunek za zadania wsadowe, ale nigdy nie zostawi operatorki bez gotowej odpowiedzi do klienta.

Osobno wykrywamy pustą odpowiedź. Model potrafi zwrócić kod sukcesu i zero treści, bo cały budżet tokenów poszedł na rozumowanie. W audycie wyglądałoby to jak poprawne wykonanie, więc dostało własny status i własne ponowienie.

System, który audytuje sam siebie

Trzynaście warunków logicznych jest sprawdzanych na żywo. Czy automatyczne reguły są włączone. Czy pokrycie raportami jest pełne. Czy ekstrakcja nie ugrzęzła. Czy nie ma spraw założonych na własny adres firmy. Czy każda sprawa oznaczona jako odrzucona ma strukturalny powód. Przy każdym warunku stoi przycisk naprawy.

Nad tym pracuje pętla, która czyta wszystkie sprawy jednego klienta i szuka sześciu rodzajów rozjazdu: rozbicia jednej sprawy na kilka, duplikatu, błędnej klasyfikacji, sprzeczności w ustaleniach, sprawy martwej i dryfu treści. Przy wysokiej pewności i spełnionym dodatkowym warunku deterministycznym akcja wykonuje się sama. W każdym innym przypadku trafia do kolejki człowieka razem z uzasadnieniem i cytatami.

Każda automatyczna zmiana zapisuje pełny stan sprzed zmiany i cofa się jednym kliknięciem. W rejestrze jest blisko sześćset takich wpisów.