Nic się nie wysypało, a kosztowało 1,8 miliona

Spotkanie 28 lipca i liczba, której nikt nie chciał

28 lipca starsi inżynierowie Amazona przedstawili współpracownikom, co stało się z zestawem wewnętrznych projektów AI. Financial Times opisał treść. Jeden z projektów używał Claude Sonnet od Anthropic do dopasowywania danych autorów do ofert w handlu elektronicznym. Wydał 1,8 miliona dolarów. Przekroczył budżet o 860 procent. Działał pięć miesięcy, zanim ktoś go wychwycił, i nigdy nie trafił na produkcję. Jeden z zespołów opisał ten wzorzec jako katastrofalnie kosztowny.

Doszły do tego dwa mniejsze przypadki. Narzędzie do audytu finansowego przekroczyło plan o około 541 tysięcy dolarów. Projekt logistyczny wyszedł jakieś 134 tysiące dolarów ponad plan. Starszy pracownik Amazona streścił problem u podstaw w rozmowie z FT jednym zdaniem: trudno ustalić, ile kosztuje cokolwiek związanego z AI. Amazon odpowiada, że eksperymentuje, uczy się i poprawia sposób korzystania z technologii, nazywa przykłady wybranymi wybiórczo i wprowadza obowiązkowe recenzje koleżeńskie oraz limity wydatków w projektach AI.

Zacznij od arytmetyki, bo nikt jej nie opublikował. Jeśli 1,8 miliona dolarów to przekroczenie o 860 procent, zatwierdzony budżet wynosił około 190 tysięcy dolarów. To jest liczba, której kontrola powinna była bronić.

Dwa miesiące wcześniej ten sam błąd nosił inny kostium

29 maja Amazon zamknął KiroRank, wewnętrzny ranking na firmowej platformie deweloperskiej Kiro, który układał pracowników według zużytych tokenów AI. Powstał, by napędzić adopcję. Napędził praktykę, którą załoga nazwała tokenmaxxingiem: kierowanie agentów na pracę, której nikt nie potrzebował, żeby pozycja się przesunęła. Dave Treadwell, starszy wiceprezes, napisał załodze w notatce, że ranking zbudowano w dobrych intencjach, i poprosił, by nie używać AI wyłącznie dla samego używania AI.

Przeczytaj obie historie jako jedną. W maju Amazon nagradzał zużycie i dostał zużycie. W lipcu odkrył zużycie, którego nikt nie zatwierdził i nikt nie odczytał. Ranking i rozbiegane zadanie to nie są osobne braki dyscypliny; to ta sama luka, czyli że licznik chodził, a nie było zwyczaju, by go odczytywać.

Instrukcja tkwi w zamienniku, nie w zamknięciu. Amazon nie tylko skasował ranking. Zastąpił miarę znormalizowanymi wdrożeniami, które liczą kod wspomagany przez AI faktycznie trafiający na produkcję.

Dlaczego rozliczana porażka pozostaje niewidoczna

Zwykłe oprogramowanie samo ogłasza swoje awarie. Wadliwa pętla wyczerpuje pamięć i proces ginie, strona przekracza limit czasu, odpala się alarm i ktoś zostaje wybudzony o trzeciej nad ranem. Źle skonfigurowane wywołanie modelu nie robi nic z tych rzeczy. Kończy się powodzeniem. Zwraca odpowiedź, nalicza tokeny i rusza w kolejne okrążenie. Nie ma awarii do wykrycia, bo z punktu widzenia platformy nic nie poszło źle, i to jest dokładnie ten warunek, w którym może minąć pięć miesięcy.

Potem trzy rzeczy rozciągają okno wykrycia. Rozliczenie jest miesięczne, więc finanse widzą kształt problemu tygodnie po wydatku i widzą go zbiorczo. Cena jest za token, więc koszt skaluje się z wolumenem, a nie z liczbą instancji, a to właśnie ta druga oś była podstawą większości monitoringu infrastruktury. I agenci zwielokrotniają tokeny, bo pętla agentowa wykonuje wiele wywołań modelu tam, gdzie interfejs czatu wykonuje jedno.

Dla europejskiego operatora skutek jest ten sam bez względu na region: licznik chodzi na koncie chmurowym, faktura przychodzi w rytmie miesięcznym, a nic pomiędzy nie mówi ci, że zadanie przestało być przydatne w marcu.

Kontrole istniały i nie były włączone

To jest niewygodna część tej historii i powód, dla którego należy ona do rubryki o decyzjach, a nie o technologii. Środki zaradcze były dostępne na platformie przez cały czas. AWS publikuje wnioskowanie wsadowe za połowę ceny za token względem trybu na żądanie, dla pracy niewymagającej natychmiastowej odpowiedzi, a to dokładnie profil pięciomiesięcznego dopasowywania w tle. Oferuje pamięć podręczną promptów, żeby powtarzalny kontekst nie był opłacany w pełnej stawce przy każdym wywołaniu. Oferuje tańsze poziomy modeli i przekierowanie między nimi. Nic z tego nie jest egzotyczne i nic nie wymagało negocjacji.

Zadanie, które działało pięć miesięcy bez pilnej potrzeby odpowiedzi, to podręcznikowe obciążenie wsadowe. Uruchomienie go na żądanie nie jest awarią techniczną, to decyzja, o którą nikogo nie poproszono, ponieważ osoba konfigurująca zadanie nie była osobą oglądającą fakturę.

Projektuj przeciwko temu rozdziałowi. Kto może uruchomić rozliczane zadanie, powinien widzieć jego bieżący koszt w tym samym interfejsie, w którym je uruchamia.

Cztery kontrole, zanim ruszy twój kolejny agent

Ustaw twardy limit na zadanie, nie na konto. Alarm budżetowy na poziomie konta mówi ci, że suma drgnęła; nie mówi, które zadanie ją poruszyło, a zanim budżet konta zadziała, te pięć miesięcy już minęło. Po drugie, wymagaj przy zatwierdzaniu wyraźnej odpowiedzi na jedno pytanie: czy to musi zostać rozstrzygnięte teraz? Jeśli odpowiedź brzmi nie, to obciążenie wsadowe i tak należy je wycenić.

Po trzecie, nadaj termin ważności każdemu długo działającemu zadaniu. Zadanie dopasowujące, które działa od marca, powinno było wymagać odnowienia przez człowieka w kwietniu. Po czwarte, mierz wynik. Jeśli oceną projektu jest praca wspomagana przez AI, która trafiła na produkcję, to wdrożenie, które nigdy tam nie trafiło, dostaje zero bez względu na zużyte tokeny, i ujawniłoby się przy pierwszym miesięcznym przeglądzie, a nie przy piątym.

Czytaj dalej: Amazon tnie zespół AGI w roku wartym 200 miliardów  |  Twoje sprawdzone dane już były w połowie maszyną