Koszt zadania i czas odpowiedzi to decyzje produktowe

W klasycznym oprogramowaniu koszt obsłużenia kolejnego użycia funkcji jest bliski zeru, a szybkość odpowiedzi to sprawa inżynierii z celem, co do którego wszyscy się zgadzają. Nikt na przeglądzie produktu nie pyta, ile kosztuje wyrenderowanie strony.

Funkcje AI łamią oba założenia. Każde żądanie ma widoczną cenę, która rośnie z użyciem, a czas odpowiedzi wynika z wyborów — który model, ile kontekstu, ile kroków sprawdzających — ustawiających zarazem jakość. To trzy pokrętła jednej maszyny i ktoś nimi kręci. Zwykle ten, kto pisał kod, w dniu, w którym go pisał.

Trzy pokrętła, jedna maszyna

Jakość kosztuje pieniądze i sekundy. Większy model, więcej kontekstu z wyszukiwania, drugi przebieg sprawdzający pierwszy: każde z nich zwykle poprawia odpowiedzi i każde dokłada kosztu i czekania. Poprawa jest realna i mierzalna. Czy jest warta swojej ceny, zależy od zadania — a to czyni ją oceną produktową, nie inżynierską.

Koszt rośnie razem z sukcesem. Funkcja tania przy wolumenie pilotażu może stać się jedną z większych pozycji budżetu, gdy ludzie ją polubią. Ekonomię jednostkową trzeba znać, zanim adopcja ruszy, a nie odczytać ją z pierwszej dużej faktury.

Opóźnienie zmienia to, czym jest produkt. Odpowiedź po sekundzie jest częścią rozmowy. Odpowiedź po dwudziestu sekundach to zlecenie, na które się czeka — a czekając, człowiek przełącza się na inną kartę. Ten sam wynik przy innej szybkości to inny produkt i inny projekt.

Pytania, na które musi odpowiedzieć produkt

Ile jest warte jedno zadanie? Nie jedno żądanie — jedna skończona jednostka pracy: zamknięte zgłoszenie, napisana odpowiedź, sprawdzona faktura. Koszt zadania zestawiony z jego wartością to jedyne porównanie, które cokolwiek znaczy, a jego spisanie bywa pierwszym momentem, w którym ktoś w ogóle wycenił to zadanie.

Ile człowiek może tu czekać? Podpowiedzi w trakcie pisania, czat, szkic przygotowywany w tle i nocne przetwarzanie wsadowe mają różną tolerancję, a projekt potrafi przesunąć zadanie z jednego miejsca w drugie. Wolna odpowiedź, która przychodzi jako gotowy szkic, często jest lepsza od szybkiej, która przerywa pracę.

Gdzie warto płacić za jakość? Rzadko wszędzie. Zwykle z drogiej ścieżki korzysta mniejszość trudnych przypadków, a reszta nie zauważy różnicy. Kierowanie ruchu między nimi to zadanie inżynierii; rozstrzygnięcie, co jest trudnym przypadkiem, już nie.

Gdzie jest sufit? Koszt zadania, powyżej którego funkcję się przeprojektowuje, a nie stroi — wpisany do specyfikacji jak każde inne wymaganie.

Infografika

Ścieżka dopasowana do zadania

Wysoka wartośćNiska wartość

Kierować i przygotowaćSzybka ścieżka domyślna, droga dla trudnych, praca wykonana zawczasu.

Płacić za jakośćWiększy model i dodatkowe kontrole, wynik jako gotowy szkic.

Mały i szybkiNajtańszy model, który przechodzi próg. Wszystko ponad to jest stratą.

WsadowoHurtem, poza szczytem, przy najniższym koszcie zadania.

Potrzebne od razuMoże poczekać

Kto odpowiada za które liczby

Inżynieria powinna pokazywać koszt i opóźnienia per funkcja i per zadanie oraz znać dźwignie: mniejsze modele do łatwej pracy, cache, grupowanie żądań, krótsze prompty. Produkt powinien odpowiadać za cele — sufit kosztu, akceptowalny czas czekania, próg jakości — i za rozstrzygnięcie, gdy się ze sobą zderzają.

Gdy jedna osoba odpowiada za jedno i drugie albo nikt nie odpowiada za cele, kompromis i tak zapada. Zapada domyślnie, w kodzie, i jest odkrywany na nowo przy każdej fakturze albo reklamacji.

Ceny też się ruszają. Dostawcy zmieniają cenniki i wypuszczają mniejsze, tańsze modele, więc funkcja, której ekonomia w zeszłym kwartale była na granicy, dziś może spinać się bez trudu — i odwrotnie. Gdy sufit i zmierzony koszt zadania leżą obok siebie, sprawdzenie tego to ponowne uruchomienie ewaluacji, a nie nowy projekt.

Działający układ to trzymanie progu jakości, sufitu kosztu i celu czasu odpowiedzi w tym samym wierszu specyfikacji, tak żeby zmiana ruszająca jedno z nich była oceniana względem dwóch pozostałych. „Przejście na większy model podnosi wynik na trudnych przypadkach i podnosi koszt zadania” to decyzja, przy której stoi czyjeś nazwisko. Nie powinna przychodzić jako pull request.

Jak nad tym pracujemy

W inżynierii aplikacji AI-native koszt i opóźnienia mierzymy na żądanie i na zadanie od pierwszego tygodnia, z liczbami widocznymi per funkcja, żeby decyzja produktowa mogła je uwzględnić, i z dźwigniami udokumentowanymi, zamiast odkrywanych przy pierwszej dużej fakturze. Duże rachunki zwykle okazują się skutkiem jednej niezbadanej ścieżki w kodzie, a nie tego, że produkt jest drogi.