W obliczu rosnących wydatków na sztuczną inteligencję najczęstszą odpowiedzią jest ograniczenie jej użycia: limity zużycia, liczba stanowisk i zatwierdzenia przed uruchomieniem agentów. Jednakże, jak wynika z analizy, te nieróżnicujące ograniczenia mogą hamować przydatne zastosowania i mierzyć niewłaściwy wskaźnik.
Koszt na token (jednostkę tekstu przetwarzaną przez model językowy) mierzy zużycie, a nie wyniki. Część wydatków odpowiada za marnotrawstwo, jak ponowne uruchamianie zapytań czy niekontrolowane pętle, podczas gdy inna część reprezentuje rzeczywistą pracę dostarczania oprogramowania. Licznik nie pozwala ich odróżnić, podobnie jak limit wydatków.
Mierzenie dostarczonego oprogramowania
Bardziej trafnym wskaźnikiem byłby koszt na zaakceptowane żądanie scalenia, czyli całkowity koszt rozwoju wspomaganego przez AI podzielony przez liczbę zmian, które przechodzą recenzję i są integrowane z kodem, zwanych w żargonie « pull request ». Należy równolegle śledzić poprawki i defekty, aby tańsze zmiany nie maskowały spadku jakości.
Jeśli ten koszt spada, podczas gdy użycie rośnie, bez pogorszenia jakości, oznacza to, że deweloperzy przekształcają większą część zużycia w przydatne oprogramowanie. Pytanie nie brzmi więc, ile tokenów zostało użytych, ale jaką ilość wykonanej pracy produkuje inwestycja. Aby poprawić tę równowagę, wskazuje się na dwie dźwignie: zarezerwowanie kosztowej inferencji dla zadań, które jej potrzebują, oraz obniżenie kosztu rutynowej pracy.
Dopasowanie modelu do zadania
Rozwój agentowy, w którym agent autonomicznie pisze i modyfikuje kod, nie wymaga najpotężniejszego modelu na każdym etapie. Model najwyższej klasy lub model flagowy hostowany lokalnie, gdy wymaga tego polityka firmy, może być zarezerwowany dla złożonego planowania i nowatorskiego rozumowania. Prostszych zadań, jak generowanie kodu, tworzenie testów czy powtarzalne refaktoryzacje, można powierzyć modelom o otwartych wagach (« open-weight »), eksploatowanym bezpośrednio przez przedsiębiorstwo.
Brama (« gateway ») może kierować każde żądanie w zależności od jego złożoności, wrażliwości danych, kosztu i opóźnienia. Pierwszy model jest więc używany tylko wtedy, gdy sytuacja to uzasadnia. Jak podsumowuje autor: « Meter the exception, not the workload », czyli: mierz wyjątek, a nie obciążenie pracą.
Modele o otwartych wagach sprawiają, że ten podział staje się coraz bardziej wykonalny. Według przytoczonych benchmarków inżynierii oprogramowania, najlepsze z nich mogą zbliżać się do osiągów modeli najwyższej klasy w niektórych zadaniach. To spostrzeżenie nie gwarantuje jednak równoważności na wszystkich repozytoriach kodu ani we wszystkich przepływach pracy. Dlatego zaleca się ocenę kandydatów na własnym kodzie, własnych testach i własnych kryteriach akceptacji przed powierzeniem im pracy produkcyjnej.
Zmiana ekonomiki powtarzalnych zastosowań
Pozostaje kwestia, kto posiada moc obliczeniową. Przy wynajmowanej inferencji każde wywołanie dodaje się do rachunku. Przy posiadanej mocy zasadniczy koszt jest ponoszony z góry, więc każde dodatkowe wywołanie staje się tańsze w miarę wzrostu użycia.
