Ukryty koszt przepływów probabilistycznych
Faktura, której nikt nie zauważył w pilocie
Pilot wyglądał na tani. To był pierwszy problem. Zespół podłączył krok oparty na sztucznej inteligencji do znanego przepływu pracy: przychodzące dokumenty były klasyfikowane, generowano krótkie streszczenie, wybierano zalecaną ścieżkę, a człowiek dokonujący przeglądu zatwierdzał ją lub zmieniał. Demo było zgrabne. Model sprawiał wrażenie kompetentnego. Rachunek za tokeny był niższy niż budżet na lunch, co u wszystkich wzbudziło poczucie finansowej dojrzałości. Ktoś wypowiedział słowo skalowalny i na chwilę w sali zrobiło się niebezpiecznie.
Trzy miesiące później rozmowa o kosztach się zmieniła. Rachunek za tokeny nadal nie był dramatyczny. Ukryte koszty leżały gdzie indziej. Osoby dokonujące przeglądu spędzały dodatkowe minuty na sprawdzaniu wyników granicznych. Pojawiały się ponowne uruchomienia, bo ten sam wkład czasem dawał odpowiedź na tyle inną, że wymagała ponownego przetworzenia. Kolejki wyjątków rosły. Zespoły danych badały, dlaczego jeden typ dokumentów mylił klasyfikator. Operacje dodały próbkowanie. Dział prawny poprosił o dowody w spornych przypadkach. Menedżerowie pytali, dlaczego czas cyklu stał się mniej przewidywalny. Inżynierowie dodawali podpowiedzi, potem zabezpieczenia, potem mechanizmy awaryjne, potem monitoring, a na końcu arkusz kalkulacyjny, którego nikt nie lubił, ale który wszyscy otwierali. Przepływ pracy nie eksplodował. Zyskał zmienność.
To jest ukryty koszt przepływów pracy opartych na modelach probabilistycznych. Wywołanie modelu to widoczna jednostka zużycia, ale koszt operacyjny niosą niepewności wokół tego wywołania. Komponent probabilistyczny może być użyteczny, wydajny i ekonomicznie sensowny. Może też przenosić koszt na przegląd, uzgadnianie, dowody, wsparcie, projektowanie kolejek, analizę incydentów, pomiar jakości i uwagę ludzi. Jeśli te koszty nie zostaną zaprojektowane w przepływie pracy, i tak się pojawią, zwykle z mniejszą cierpliwością.
Tradycyjne systemy przepływów pracy nie są doskonałe. Zawodzą, dryfują i zaskakują ludzi na swój własny, nudny sposób. Często mają jednak użyteczną właściwość: ten sam wkład, stan i reguła zwykle dają ten sam wynik. Systemy probabilistyczne osłabiają to założenie. Czasem o to właśnie chodzi. Radzą sobie z niejednoznacznością, językiem, obrazami, nieuporządkowanymi dokumentami i rozmytymi intencjami. Dobrze. Ceną jest to, że operacje muszą przestać udawać, że niepewność to szczegół pokazowy. To pełnoprawny wkład do modelu kosztów.
Zmienność to nie szczegół implementacji
Komponenty probabilistyczne wprowadzają zmienność w kilku miejscach. Model może generować nieco inne sformułowania. Klasyfikator może umieścić przypadek graniczny po jednej lub drugiej stronie progu. Wyszukiwarka może zwrócić inny zestaw źródeł po aktualizacji indeksu. Streszczacz może pominąć szczegół, który miał znaczenie dla późniejszego recenzenta. Agent korzystający z narzędzi może wybrać inną sekwencję wywołań. Żadne z tych zachowań nie jest automatycznie błędem. To po prostu inny materiał niż kod deterministyczny. Traktowanie tego jak zwykłego kodu tylko dlatego, że ma interfejs API, to błąd kategoryzacji, za który przychodzą rachunki.
Zmienność ma konsekwencje operacyjne. Zwiększa potrzebę próbkowania i przeglądu. Komplikuje odtwarzanie incydentów. Utrudnia pomiar wydajności, ponieważ średnia jakość może maskować niestabilność na krańcach rozkładu. Prowadzi do niezgodności między użytkownikami, którzy widzieli różne wyniki. Może czynić systemy downstream kruche, gdy oczekują one stabilnej struktury. Może zamienić prostą umowę poziomu usług w rozmowę o rozkładach prawdopodobieństwa, co jest świetnym sposobem na odkrycie, kto w zespole naprawdę lubi matematykę.
Pierwszy koszt to tarcie decyzyjne. Gdy wyniki się różnią, ludzie spędzają czas na ustalaniu, czy różnica ma znaczenie. Szkic wiadomości e-mail, który mówi to samo innymi słowami, może być akceptowalny. Podsumowanie medyczne, które pomija lek, nie jest. Klasyfikator wsparcia, który inaczej kieruje jedno zgłoszenie, może być w porządku. Wyjaśnienie kwalifikowalności do świadczeń, które zmienia swoje uzasadnienie, nie jest. Proces wymaga modelu tolerancji: jaka zmienność jest nieszkodliwa, jaka wymaga przeglądu, a jaka jest zabroniona.
Drugi koszt to odtwarzalność. Jeśli klient, obywatel, audytor lub inżynier zapyta, dlaczego podjęto daną decyzję, organizacja musi odtworzyć istotny kontekst: wersję modelu, prompt, zestaw wyników wyszukiwania, dane wejściowe, politykę, parametry, wyniki narzędzi i działania człowieka. Bez takiego zapisu dochodzenie staje się teatrem. Ktoś uruchamia prompt ponownie, otrzymuje inną odpowiedź i wszyscy uczą się na własnej skórze, że ponowienie próby nie jest dowodem.
Ponowienie próby nie jest darmowe tylko dlatego, że jest zautomatyzowane
Ponowienia prób wyglądają na tanie z perspektywy kodu. Jeśli model daje słabą odpowiedź, wywołaj go ponownie. Jeśli klasyfikator jest niepewny, poproś o kolejną próbkę. Jeśli odpowiedź JSON jest nieprawidłowa, napraw ją. Jeśli wywołanie narzędzia się nie powiedzie, spróbuj innej ścieżki. Maszyna wykonuje pracę, więc naturalnym odruchem jest traktowanie ponowień jako kleju inżynieryjnego. W przepływie probabilistycznym ponowienia są polityką. Decydują o tym, ile zmienności system może ukryć, zanim zobaczy ją człowiek.
Istnieją dobre powody, aby ponawiać próby. Przejściowa awaria nie powinna zatrzymywać procesu. Nieprawidłowo sformułowaną odpowiedź często można poprawić. Poproszenie o drugie podejście może poprawić jakość. Ale ponowienia tworzą również koszty i niejednoznaczność. Który wynik jest zapisem. Czy zachowujemy wszystkie próby. Czy późniejsze próby nadpisują wcześniejsze. Czy pokazujemy recenzentowi niestabilność. Czy ponowienia faworyzują odpowiedzi brzmiące bardziej pewnie. Czy ponawiamy tylko tanie przypadki, przez co ważne przypadki są przypadkowo wolniejsze. Czy liczymy ponowienia w budżetach kosztów i opóźnień. Pokorne ponowienie ma wiele opinii, gdy tylko zaprosisz je do produkcji.
Ponowienia zmieniają również zachęty. Jeśli zespoły wiedzą, że system będzie próbował dalej, aż wynik dopasuje się do oczekiwanego kształtu, mogą zaniedbać jakość danych wejściowych, projekt schematu, ograniczenia promptu czy deterministyczne przetwarzanie wstępne. Ponowienie staje się mopem. Mopy są przydatne. Strategia budowlana oparta na mopowaniu robi mniejsze wrażenie.
Lepszym wzorcem jest klasyfikowanie przyczyn ponowień. Przejściowa awaria infrastruktury to jedna kategoria. Naprawa formatowania to druga. Niska pewność to trzecia. Konflikt polityk to czwarta. Konflikt źródeł to piąta. Każda kategoria potrzebuje limitów, rejestrów i zasad eskalacji. Ponowienie, które ukrywa niepewność przed użytkownikiem, powinno być traktowane inaczej niż ponowienie, które jedynie odzyskuje sprawność po chwilowym problemie z siecią. Koszt to nie tylko moc obliczeniowa. To koszt decyzji, którą niepewność organizacja jest gotowa ukryć.
Kolejka wyjątków to prawdziwy diagram architektury
Każdy probabilistyczny przepływ pracy w końcu ujawnia swój prawdziwy projekt przez kolejkę wyjątków. Nie przez ścieżkę szczęśliwą. Ścieżka szczęśliwa to miejsce, gdzie diagramy idą, aby wyglądać na zatrudnialne. Kolejka wyjątków pokazuje, których przypadków system nie rozumie, które dane wejściowe są zanieczyszczone, które polityki są ze sobą sprzeczne, którzy użytkownicy potrzebują wsparcia, które progi są błędne i które obietnice zostały złożone zbyt wcześnie.
Jeśli kolejka wyjątków jest dobrze zaprojektowana, staje się powierzchnią uczenia się. Przypadki są kategoryzowane, próbkowane, przeglądane przez właściwe role, powiązywane z poprawkami danych źródłowych, łączone ze zmianami polityk i wracają do ewaluacji. Jeśli jest zaprojektowana źle, staje się bagnem. Trudne przypadki leżą w zaległościach. Osoby przeglądające wypracowują lokalne nawyki. Menedżerowie widzą tylko wolumen. Inżynierowie widzą tylko zagregowane awarie. Użytkownicy widzą opóźnienia. Model pozostaje tajemniczy, ponieważ organizacja ukryła swoje najlepsze dowody w operacyjnym szlamie.
Koszt wyjątków to nie tylko liczba przypadków. To ich kształt. Dziesięcioprocentowy wskaźnik wyjątków może być do opanowania, jeśli przypadki są szybkie, niskiego ryzyka i łatwe do skierowania. Dwuprocentowy wskaźnik wyjątków może być kosztowny, jeśli każdy przypadek wymaga interpretacji prawnej, przeglądu dziedzinowego, kontaktu z klientem i rekonstrukcji dowodów. Średni wskaźnik automatyzacji jest zatem podejrzaną metryką. Mówi ci, ile przeszło przez maszynę, a nie ile kosztów maszyna wyeliminowała.
Projektowanie wyjątków powinno być jawne. Zdefiniuj pasma pewności. Zdefiniuj wstrzymanie się od odpowiedzi. Zdefiniuj, które konflikty wstrzymują przepływ pracy. Zdefiniuj, które role mogą rozwiązywać które klasy. Zdefiniuj maksymalny wiek kolejki. Zdefiniuj przegląd próbkowy przypadków zaakceptowanych, nie tylko odrzuconych. Zdefiniuj, co jest naprawiane, gdy wyjątek się powtarza. W przeciwnym razie organizacja nie zautomatyzowała pracy. Zautomatyzowała tworzenie drugiej, mniej widocznej pracy.
Wynik probabilistyczny sprawia, że systemy niższego szczebla negocjują
Systemy informatyczne preferują kontrakty. Pole to data. Status ma dozwolone wartości. Kwota ma precyzję. Reguła ma gałąź. Wyniki probabilistyczne często pojawiają się jako język, ranking, poziom ufności lub częściowo ustrukturyzowane przypuszczenia. Systemy niższego poziomu muszą wtedy negocjować. Parsują. Walidują. Naprawiają. Pytają ponownie. Mapują nieostre etykiety na dokładne stany. Tworzą mechanizmy awaryjne. Każda negocjacja to niewielki koszt. Wystarczająca liczba niewielkich kosztów staje się architekturą.
Ustrukturyzowane wyjście pomaga, ale nie usuwa niepewności. Model może wygenerować poprawny JSON i nadal wybrać niewłaściwą kategorię. Może wypełnić wszystkie pola i nadal pominąć warunek. Może zacytować źródło i nadal je błędnie zinterpretować. Schemat wyłapuje błędy kształtu. Nie dowodzi znaczenia. To częsta pułapka, ponieważ błędy kształtu są widoczne dla maszyn, a błędy znaczenia dla ludzi. Zgadnij, który rodzaj jest naprawiany pierwszy.
Negocjacje na niższych poziomach zmieniają też odpowiedzialność. Jeśli sprawa zostanie źle przekierowana, bo wynik modelu był niejednoznaczny, a warstwa integracyjna zgadywała, kto odpowiada za błąd. Zespół modelu. Zespół platformy. Właściciel procesu. Recenzent. Zespół danych. Każdy może przedstawić sensowny argument, co oznacza, że brakuje modelu operacyjnego. Workflowy probabilistyczne potrzebują jasno przypisanej odpowiedzialności na granicy, gdzie niepewność staje się stanem systemu.
Jedną z praktycznych metod jest rozdzielenie ufności, kompletności i konsekwencji. Ufność mówi, jak prawdopodobny jest wynik. Kompletność mówi, czy wymagane dowody są obecne. Konsekwencja mówi, jak dużą szkodę może wyrządzić błędne działanie. Wynik o wysokiej ufności z brakującymi dowodami może nadal wymagać przeglądu. Wynik o niskiej ufności i niskiej konsekwencji może być szybko przekierowany. Wynik o średniej ufności i wysokiej konsekwencji może wymagać eskalacji. Workflow nie powinien traktować całej niepewności jako jednego odcienia żółtego.
Ewaluacja to powtarzalny koszt operacyjny
Wiele zespołów traktuje ewaluację jak fazę projektu. Przed uruchomieniem przygotowują zestaw testowy, uruchamiają prompty, porównują wyniki, być może oceniają jakość i ogłaszają gotowość. Potem pojawia się rzeczywistość z nowymi dokumentami, nowymi użytkownikami, nowymi przypadkami brzegowymi, nowym językiem, nową polityką i nowymi wersjami modeli. Zestaw ewaluacyjny zaczyna się starzeć. Jak ser, tylko mniej smaczny i bardziej skłonny do wywołania spotkania.
Workflowy probabilistyczne wymagają powtarzalnej ewaluacji. To znaczy starannie dobranych przypadków, przypadków kontradyktoryjnych, świeżych próbek produkcyjnych, zestawów regresyjnych, przeglądu domenowego, kontroli uczciwości tam, gdzie ma to znaczenie, śledzenia kosztów i opóźnień oraz testów uruchamianych przy zmianie promptów, modeli, indeksów wyszukiwania, polityk lub danych źródłowych. Ewaluacja to nie jednorazowa bramka. To budżet operacyjny na wiedzę, czy workflow nadal zasługuje na ruch.
Ten koszt zaskakuje ludzi, ponieważ pilotaż go ukrywa. Podczas pilotażu eksperci są blisko systemu. Zauważają problemy nieformalnie. Zakres danych wejściowych jest ograniczony. Stawka jest kontrolowana. W produkcji system staje się na tyle nudny, że eksperci przestają sprawdzać każde wyjście, co jest dokładnie momentem, w którym formalna ewaluacja musi przejąć kontrolę. System probabilistyczny bez powtarzalnej ewaluacji to maszyna, która powoli wydaje zaufanie, jednocześnie raportując czas działania.
Ewaluacja musi być też powiązana z decyzjami. Jeśli jakość spada, kto może wstrzymać. Jeśli rosną opóźnienia, kto decyduje, czy zmniejszyć rozmiar modelu, ograniczyć ponowne próby czy dodać zdolność przeglądu. Jeśli nowy model poprawia średni wynik, ale pogarsza wyniki w krytycznej podgrupie, kto odrzuca aktualizację. Jeśli koszty rosną, bo zwiększa się liczba wyjątków, kto odpowiada za naprawę. Pulpit nawigacyjny pokazujący spadek bez uprawnień do działania to tylko droga prognoza pogody.
Przegląd ludzki ma rachunek z teorii kolejek
Przegląd ludzki bywa dodawany jako uspokajające sformułowanie. Człowiek pozostanie w pętli. Cudownie. Który człowiek, z jaką kolejką, jakim kontekstem, jaką władzą, jakim czasem docelowym, jaką ścieżką eskalacji, jakim modelem zmęczenia i jakim zabezpieczeniem, gdy system wyśle zbyt wiele przypadków granicznych w piątek o 16:45. Pętla ma logistykę. Logistyka ma koszty. Koszty mają uroczy zwyczaj pojawiania się po slajdzie z architekturą.
Przepustowość przeglądu nie jest liniowa. Niewielki wzrost liczby przypadków niepewnych może wywołać duży wzrost czasu oczekiwania, gdy zespół przeglądowy jest blisko granicy wydajności. Teoria kolejek jest okrutna, ale sprawiedliwa. Jeśli napływ zgłoszeń staje się bardziej zmienny, a czas obsługi również, opóźnienia mogą rosnąć szybko. Przepływy pracy probabilistyczne często zwiększają oba te czynniki: bardziej nierówną trudność przypadków i bardziej zmienny czas przeglądu. Organizacja może wierzyć, że zautomatyzowała osiemdziesiąt procent pracy, podczas gdy pozostałe dwadzieścia procent po cichu kontroluje umowę o poziomie usług.
Jakość przeglądu zależy też od kontekstu. Jeśli recenzenci widzą tylko końcową odpowiedź, muszą rekonstruować, dlaczego się pojawiła. Jeśli widzą źródła, pewność, politykę, wcześniejsze próby i znane niepewności, mogą działać szybciej i lepiej. Jeśli mierzy się ich wyłącznie przepustowością, nauczą się albo zbytnio ufać maszynie, albo zbyt mało z nią walczyć. Przegląd ludzki to nie magiczny rozpuszczalnik wylewany na niepewność. To wykwalifikowana praca, która wymaga projektu.
Ukrytym kosztem jest uwaga. Ludzie nie mogą w nieskończoność przeglądać nieograniczonej niejednoznaczności. Zmęczenie zmienia standardy. Pojawiają się lokalne nawyki. Niektórzy recenzenci stają się surowi, inni pragmatyczni, jeszcze inni zrezygnowani. Przepływ pracy zaczyna dawać różne wyniki w zależności od tego, kto trafił na przypadek. Potem system probabilistyczny obwinia się o niespójność, którą organizacja wzmocniła w projekcie przeglądu. Maszyna dostarczyła wariancję. Ludzie dostarczyli dynamikę kolejek. Świetny duet, jeśli celem jest ból w audycie.
Rachunek kosztów musi obejmować niepewność
Użyteczny model kosztów dla przepływów pracy probabilistycznych obejmuje więcej niż wywołania modelu. Obejmuje przygotowanie danych wejściowych, wyszukiwanie, ponowne próby, walidację, czas przeglądu, obsługę wyjątków, ocenę, przechowywanie dowodów, analizę incydentów, monitorowanie, wsparcie użytkowników, utrzymanie promptów i polityk, korektę danych oraz naprawy w dalszej części procesu. Obejmuje też opcjonalność: koszt zmiany modelu, dostawcy, promptu, indeksu lub przepływu pracy, gdy obecna konfiguracja przestaje pasować.
To nie znaczy, że przepływy probabilistyczne są złe. To znaczy, że są realne. Wiele z nich jest wartych swojej ceny. System, który ogranicza powtarzalne czytanie, a jednocześnie wyłapuje ryzykowne przypadki, może być doskonały. Klasyfikator, który lepiej niż reguły radzi sobie z nieuporządkowanym językiem, może oszczędzić czas. Streszczacz, który daje ekspertom dobry pierwszy szkic, może poprawić jakość obsługi. Nie chodzi o to, by unikać prawdopodobieństwa. Chodzi o to, by przestać ukrywać jego koszty operacyjne w cudzych kalendarzach.
Jedną z użytecznych metod rozliczania jest wycena według klasy przypadku. Przypadki przetwarzane w pełni automatycznie generują koszty modelu, walidacji i próbkowania. Przypadki wspomagane wymagają czasu recenzenta. Przypadki wyjątkowe generują koszty segregacji, specjalistycznego przeglądu i gromadzenia dowodów. Przypadki sporne generują koszty odtworzenia, komunikacji i ewentualnej korekty. Przypadki doskonalące generują koszty utrzymania danych lub promptów. To przekształca wskaźnik automatyzacji w pełniejszy obraz: nie tylko ile przypadków dotknęła sztuczna inteligencja, ale jak niepewność zmieniła nakład pracy i ryzyko.
Inną metodą jest śledzenie budżetu wariancji. Ile zmienności wyników jest dopuszczalne dla danego zadania. Jak często ponowne uruchomienia mogą dawać różne wyniki. Ile wyjątków dziennie może wchłonąć kolejka. Ile czasu na przegląd przypada na jeden przypadek. Ile dowodów trzeba przechowywać. Jak szybko trzeba odtwarzać sporne wyniki. Te liczby nie eliminują niepewności. Sprawiają, że można nią zarządzać.
Determinizm wciąż ma swoje zadanie
Rozwój systemów probabilistycznych nie czyni inżynierii deterministycznej staromodną. Sprawia, że granice deterministyczne są cenniejsze. Stosuj deterministyczne parsowanie tam, gdzie dostępna jest struktura. Stosuj jawne reguły tam, gdzie polityka jest precyzyjna. Stosuj stabilne wyszukiwanie tam, gdzie źródła muszą być odtwarzalne. Stosuj schematy, walidatory, skończone stany, wersjonowane prompty, stałe zestawy ewaluacyjne i rejestrowane parametry. Używaj prawdopodobieństwa w tej części zadania, która naprawdę wymaga osądu wobec niejednoznaczności, a nie w tej, która wymagała jedynie napisania nudnego kodu.
To nie jest puryzm. To kontrola kosztów. Każda granica deterministyczna eliminuje jedno miejsce, w którym wariancja może się przedostać. Przepływ, który używa modelu do czytania nieuporządkowanego tekstu, potem deterministycznej walidacji do sprawdzania wymaganych pól, potem reguł do stosowania znanej polityki, a na końcu przeglądu ludzkiego dla niepewności o wysokich konsekwencjach, zwykle będzie łatwiejszy w obsłudze niż przepływ, który każe modelowi robić wszystko, a potem udaje zdziwienie, że wszystko obejmuje kilka opinii.
Determinizm poprawia też gromadzenie dowodów. Jeśli zadziałała reguła, zarejestruj tę regułę. Jeśli parser wyodrębnił pole, zarejestruj lokalizację źródła. Jeśli wyszukiwanie uszeregowało dokumenty, zarejestruj wersję indeksu i wyniki. Jeśli model wygenerował streszczenie, zarejestruj prompt, zestaw źródeł, wersję modelu i decyzję recenzenta. Celem nie jest zamiana każdego przepływu w salę sądową. Celem jest sprawienie, by późniejsze pytania były rozstrzygalne bez zwoływania całego zespołu inżynierów na spotkanie nazwane szybką synchronizacją.
Granica między pracą deterministyczną a probabilistyczną powinna być jawna na diagramach i w budżetach. Który krok może się zmieniać. Który krok nie może. Który krok można ponowić. Który krok trzeba odtworzyć dokładnie. Który krok można wyjaśnić statystycznie. Który krok wymaga rejestru. Jeśli zespół nie potrafi wytyczyć tej granicy, nie może uczciwie oszacować kosztów.
Wniosek
Ukryty koszt pracy probabilistycznej nie jest powodem, by jej unikać. Jest powodem, by uczciwie go rozliczyć. Koszt pojawia się w ponownych próbach, przeglądach, wyjątkach, dowodach, ocenie, kolejkach, wsparciu oraz w wolniejszej pracy polegającej na ustalaniu, jaka zmienność jest do przyjęcia. Jeśli workflow oszczędza czas na ścieżce szczęśliwej, ale oddaje go w sporach i operacyjnej mgle, biznesowy argument był napisany tylko w połowie.
Dobre operacje probabilistyczne zaczynają się od traktowania niepewności jak materiału. Nazwij miejsce, w którym wchodzi do procesu. Ogranicz, gdzie może się zmieniać. Zapisuj wystarczająco dużo kontekstu, by móc odtworzyć decyzje. Projektuj kolejki wyjątków jako powierzchnie do nauki. Daj recenzentom uprawnienia i czas. Oceniaj w sposób ciągły. Utrzymuj deterministyczne granice tam, gdzie obniżają koszt. Wyceń wyjście i zmianę. Większość tego nie jest efektowna. To znak, że może przetrwać w produkcji.
Wywołanie modelu to łatwa pozycja w budżecie. Prawdziwe pytanie brzmi, co organizacja musi zrobić przed tym wywołaniem i po nim, aby wynik można było zaufać, zakwestionować, naprawić i ulepszyć. Probabilistyka może uczynić workflow bardziej wydajnym. Może też uczynić go mniej przewidywalnym. Różnica nie jest magią. To operacje, czyli miejsce, w którym imponujące dema stają się albo użyteczne, albo kosztowne.