Projekt pilotażowy AI: jak określić cel, próbę i decyzję końcową

Projekt pilotażowy służy udzieleniu odpowiedzi na pytanie, a nie udowodnieniu, że sztuczna inteligencja działa. Różnica widoczna jest na końcu: jeśli kryteria zostały spisane wcześniej, wynik jest decyzją; jeśli spisuje się je później, jest interpretacją, a wygrywa ten, kto lepiej mówi na spotkaniu.

Ten poradnik dotyczy tego, jak organizuje się test: co się w nim uwzględnia, co się mierzy, kto go nadzoruje i jak podejmuje się decyzję na koniec.

Pierwsza sprawa: pytanie, na które odpowiada pilotaż

«Zobaczmy, czy AI może nam pomóc» to nie jest pytanie, ponieważ nie istnieje odpowiedź, która by je zamykała. Użyteczne pytanie ma czynność, podmiot i warunek możliwy do zweryfikowania.

• Jeśli system przygotowuje pierwsze odpowiedzi na zgłoszenia do wsparcia, czy dział jest w stanie zamknąć w ciągu dnia sprawy z danego dnia?
• Jeśli dokumenty dostawców są odczytywane automatycznie, ile z nich mimo to trafia do rąk pracownika?
• Jeśli powtarzalne wyceny są przygotowywane z pomocą asystenta, czy czas przygotowania się skraca, a liczba błędów w kwotach nie rośnie?

Na każde z tych pytań można odpowiedzieć przecząco, i o to właśnie chodzi. Pilotaż, który nie może zakończyć się wynikiem negatywnym, nie jest testem: jest prezentacją.

Zakres: co wchodzi, a co zostaje na zewnątrz

To część, którą zwykle pozostawia się zbyt szeroką, i to właśnie ten błąd sprawia, że wyniki stają się nieczytelne. Im szerszy zakres, tym trudniej zrozumieć, czemu przypisać to, co się dzieje.

• Czynność: jedna i wyraźnie ograniczona. Nie «obsługa klienta», lecz «zapytania o status zamówienia napływające pocztą elektroniczną».
• Użytkownicy: wąska grupa, wskazana imiennie, gotowa zgłaszać problemy zamiast po cichu je omijać.
• Dane: jakie źródła, z jakimi uprawnieniami, i czego nie wolno używać.
• Wyraźne wyłączenia: przypadki, których system nie powinien obsługiwać i które trzeba od razu przekazać pracownikowi, na przykład reklamacje, sprawy umowne, klientów w sporze.

Okres należy wybrać tak, aby zmieściła się w nim liczba przypadków wystarczająca, by coś powiedzieć, oraz przynajmniej jeden typowy dla firmy cykl: jeśli miesięczne zamknięcie zmienia sposób pracy, pilotaż musi przez nie przejść.

Sytuację wyjściową rejestruje się wcześniej

Bez punktu wyjścia nie ma porównania, a odtworzenie go na końcu zawsze prowadzi do wygodnych liczb. Zanim cokolwiek zostanie uruchomione, powinni Państwo zmierzyć, jak wygląda praca dzisiaj: ile czasu wymaga dana czynność, ile przypadków się obsługuje, ile błędów lub poprawek się zdarza, ile trzeba czekać.

Jeśli jakiś pomiar nie istnieje, trzeba go stworzyć ręcznie przez kilka tygodni: dwie osoby zapisujące czasy i przypadki na kartce dają bardziej użyteczny punkt odniesienia niż szacunek z pamięci. To prawdziwa praca i trzeba ją ująć w planie, a nie dodać niespodziewanie.

Karta pilotażu

Mieści się na jednej stronie. Przykład ma charakter poglądowy i dotyczy automatycznego odczytu przychodzących dokumentów.

Dwa wiersze wypełniane najgorzej to niemal zawsze «poza zakresem» i «kryteria akceptacji»: pierwszy dlatego, że wydaje się ograniczający, drugi dlatego, że zmusza do wcześniejszego określenia, co uznaje się za sukces. To dokładnie te dwa punkty, które sprawiają, że test daje się rozstrzygnąć.

Nadzór i nieprawidłowości w trakcie testu

W trakcie pilotażu ktoś musi obserwować, a nie tylko korzystać. Potrzebny jest stały moment — cotygodniowy jest odpowiedni — w którym czyta się przypadki, które nie wyszły, i decyduje, czy da się je poprawić, czy mówią o czymś głębszym.

• Każdy wynik pozostaje zweryfikowany przez pracownika: pilotaż to nie moment na rezygnację z kontroli.
• Nieprawidłowości zbiera się na jednej wspólnej liście, z dołączonym konkretnym przypadkiem: bez rzeczywistego przykładu niczego się nie poprawi.
• Trzeba wcześniej określić, co powoduje przerwanie testu: błąd, który dotarł do klienta, dana, która wyszła stamtąd, skąd nie powinna, nakład poprawek przewyższający zaoszczędzoną pracę.
• Zmiany wprowadzone w trakcie testu trzeba odnotowywać z datą, w przeciwnym razie na koniec nie będzie wiadomo, do której wersji odnoszą się wyniki.

Decyzja: rozszerzyć, poprawić, przerwać

Spotkanie końcowe trzeba ustalić już na początku, z osobami decyzyjnymi wcześniej zarezerwowanymi. Możliwe są trzy wyjścia i żadne z nich nie jest porażką.

1. Rozszerzyć: kryteria zostały spełnione. Przechodzi się do określenia, kto utrzymuje system, kto odpowiada, gdy się myli, i co się dzieje, gdy zmienia się źródło danych.
2. Poprawić i powtórzyć: wynik jest bliski, ale konkretny przypadek nie wytrzymuje próby. Powtarza się test tylko raz, w tym samym zakresie i z jawnie zadeklarowaną zmianą.
3. Przerwać: korzyść nie występuje albo koszt przewyższa pracę ręczną. Zapisuje się powód, tak aby za rok nikt nie zaproponował tego samego testu, nie wiedząc, jak wypadł poprzednio.

W rachunku trzeba uwzględnić cały koszt, nie tylko budowę: utrzymanie, weryfikacje wykonywane przez pracowników, czas osoby poprawiającej. System, który oszczędza pół godziny, a wymaga dwudziestu minut kontroli, ma wąski margines, i trzeba to powiedzieć, zanim ktoś odkryje to samodzielnie.

Czego nie obejmuje ten poradnik

Tu omawiana jest organizacja testu. Wybór, którą czynność poddać pilotażowi — jak porównuje się między sobą kandydatów i według jakich kryteriów ustala się ich kolejność — to wcześniejszy etap, mający swój własny poradnik. Także weryfikacja asystenta konwersacyjnego przed udostępnieniem go klientom przebiega według dedykowanej metody.