Co pilotaż AI musi wykazać, zanim sfinansujecie kolejny etap

Zapiszcie, jaką decyzję ma wesprzeć pilotaż

Wiele pilotaży dostaje zgodę z celem w rodzaju „sprawdzić, czy AI pomoże przy fakturach od dostawców”. Po dwunastu tygodniach zespół pokazuje demo, ankietę i rachunek za tokeny, a komitet sterujący nadal nie wie, czy wydać więcej.

Wskażcie, kto podejmuje tę decyzję, co sfinansowałby w następnej kolejności i jakie dowody zmieniłyby jego zdanie. Potem spiszcie kryteria, które nie zależą od żadnego produktu. Wytyczne Anthropic z 2024 roku dotyczące budowy agentów zalecają najprostsze działające rozwiązanie, czasem bez agenta. Kryteria niezależne od narzędzia pozwalają to sprawdzić, bo silnik reguł, pojedyncze wywołanie modelu i agent przechodzą przez te same przypadki i są oceniane na tym samym arkuszu.

Cztery rzeczy, które musi pokazać pilotaż procesu

• Jakość na waszych przypadkach. System obsługuje odłożony zestaw prawdziwych, zamkniętych spraw na uzgodnionym poziomie, a ocenia to właściciel procesu, a nie publiczny benchmark.
• Powtarzalność. System działa przy kolejnych uruchomieniach, a nie raz. Wytyczne Anthropic dotyczące ewaluacji odróżniają pass@k, czyli co najmniej jeden sukces w k próbach, od pass^k, czyli sukcesu we wszystkich k próbach. Gdyby każdy przebieg niezależnie miał 75 procent szans na poprawny wynik, wszystkie trzy z trzech przebiegów udałyby się tylko w około 42 procentach przypadków. Prawdziwe przebiegi często są ze sobą skorelowane, więc mierzcie powtórzenia zamiast je wyliczać.
• Koszt obsłużonej sprawy. FinOps Foundation opisuje przejście od kosztu tokena do miar opartych na wyniku, takich jak koszt rozwiązanej sprawy. Wliczcie koszty modelu i platformy, czas weryfikacji oraz poprawki i porównajcie sumę z tym, ile sprawa kosztuje dziś.
• Błędy, które da się wychwycić. Gdy system się myli, błąd zostaje oznaczony, przekazany człowiekowi albo zatrzymany przez kontrolę, zanim dotrze do klienta lub do księgowości. Zapiszcie, które błędy są dopuszczalne, a które nie.

Arkusz akceptacji dla hipotetycznego pilotażu faktur

Kryteria są przydatne, gdy dwie osoby oceniłyby ten sam wynik tak samo. Dokumentacja Anthropic wymaga kryteriów konkretnych, mierzalnych, osiągalnych i istotnych, zwykle w kilku wymiarach. Poniższy arkusz to hipotetyczny przykład dopasowywania faktur od dostawców do zamówień. Każda liczba to przykładowe założenie właściciela procesu, a nie benchmark.

1. 1

   Zestaw testowy

   400 faktur z dwóch ostatnich kwartałów ze znanym wynikiem, rozłożonych na typy dostawców, w tym korekty, dostawy częściowe i skany. Żadna z nich nie jest używana podczas pracy nad promptami.

2. 2

   Jakość

   Co najmniej 95 procent czystych dopasowań potwierdzonych poprawnie i każda rozbieżność powyżej 500 euro oznaczona. Przeoczona rozbieżność powyżej tej kwoty to błąd krytyczny, a dopuszczalna liczba błędów krytycznych wynosi zero. Zero błędów krytycznych w 400 przypadkach testowych nie oznacza zerowego ryzyka na produkcji, zwłaszcza przy rzadkich typach spraw, dlatego rozbieżności o dużej wartości nadal trafiają do człowieka.

3. 3

   Powtarzalność

   Każdy przypadek testowy jest uruchamiany trzy razy i zalicza się go tylko wtedy, gdy wszystkie trzy przebiegi zgadzają się ze znanym wynikiem.

4. 4

   Koszty

   Koszt obsłużonej faktury, łącznie z wywołaniami modelu, kosztami platformy i czasem weryfikacji przez księgowego, pozostaje poniżej wartości bazowej zmierzonej w obecnym procesie.

5. 5

   Kontrola i odpowiedzialność

   System nie zwalnia żadnej płatności. Każda oznaczona faktura trafia z uzasadnieniem do wskazanej kolejki, a osoba z działu finansów zgodziła się przejąć tę kolejkę, jeśli pilotaż będzie kontynuowany.

Arkusz pokazuje też, czego pilotaż nie sprawdza, na przykład wdrożenia w kilku krajach. To należy do kolejnego etapu, a zapisanie tego chroni pilotaż przed ocenianiem według tego kryterium.

Zmierzcie obecny proces przed pierwszym promptem

Kryteria kosztu i błędów potrzebują punktu odniesienia: ile dziś trwa sprawa, jak często coś idzie źle i ile kosztuje korekta. Rules of Machine Learning od Google stawiają metryki przed pierwszym modelem, między innymi dlatego, że niezapisanej historii nie da się odtworzyć. Tydzień mierzonej pracy ręcznej kosztuje mniej niż późniejszy spór o szacunki.

Traktujcie punkt odniesienia jako porównanie, a nie cel. Książka Google SRE przestrzega przed wyznaczaniem celów wyłącznie na podstawie obecnej wydajności, bo utrwala to dzisiejszy stan systemu. Cel powinien wynikać z potrzeb biznesu, na przykład z poziomu błędów akceptowalnego dla działu finansów.

Gdzie wyniki pilotażu wprowadzają w błąd

• Dostrajanie na zestawie testowym. Jeśli osoby piszące prompty widzą przypadki ewaluacyjne, wynik mierzy, jak dobrze te przypadki zostały wyuczone. Używajcie odłożonego zestawu tylko do oceny.
• Jedna średnia z różnych przypadków. Dobry wynik ogólny może ukryć typ sprawy, który zawodzi za każdym razem, dlatego raportujcie wyniki według typu sprawy.
• Wyniki, których nikt nie przeczytał. Anthropic zaleca czytanie zapisów wielu przebiegów, bo oceniający może odrzucić poprawną odpowiedź albo przyjąć błędną. Niech właściciel procesu przeczyta próbkę, zanim komitet sterujący zobaczy liczbę.

Ustalcie, co sfinansuje każdy wynik

Ustalcie z góry, do czego prowadzi każdy wynik. Jeśli wszystkie kryteria są spełnione, kolejny etap finansuje pracę, która zamienia pilotaż w usługę: monitoring, właściciela i ścieżkę wsparcia. Jeśli jakość się zgadza, a koszt nie, kolejny etap sprawdza tańszy projekt, na przykład mniejszy model albo węższy zakres. Jeśli jakość zawodzi w przypadkach, które mają znaczenie, zatrzymajcie projekt albo zmieńcie podejście i zachowajcie zestaw testowy na to, co przyjdzie potem.

Kryteria akceptacji dla każdej zmiany w oprogramowaniuKiedy projekt AI powinien się zatrzymać lub zmienić kierunekOd pilotażu do produkcji