Jak mierzyć i ograniczać koszty systemów agentowych: koszt per pytanie, routing modeli, cache, budżety zespołów, obserwowalność i pułapki map-reduce

 output_cost = call.output_tokens / 1_000_000 * call.model.output_price
cost_query = cost_query + input_cost + output_cost

for embedding_batch in embeddings_used_online:
cost_query = cost_query + embedding_batch.tokens / 1_000_000 * embedding_price

cost_query = cost_query + reranker_cost + tool_costs

record({
„agent”: agent_name,
„team”: team_id,
„route”: route_name,
„cost”: cost_query,
„latency_ms”: latency,
„quality_score”: optional_score
})

W prozie wygląda to tak: proste pytanie do bazy wiedzy ma jedno wyszukiwanie i jedną odpowiedź. Kosztuje ułamki grosza albo kilka groszy, zależnie od modelu i kontekstu. Pytanie z HyDE dodaje małe wywołanie do wygenerowania hipotetycznej odpowiedzi. Multi-query dokłada kilka wariantów i większy kontekst. Map-reduce czyta wiele paczek dokumentów, więc koszt rośnie wraz z liczbą paczek, nie z liczbą znaków w pytaniu użytkownika. Samowalidacja dorzuca drugie czytanie odpowiedzi i źródeł. To trzeba pokazać biznesowi na konkretnych liczbach, nie na metaforach.

W jednej konfiguracji dla działu leasingu zwykłe pytanie kosztowało średnio 0,012 zł. Pytanie z multi-query około 0,041 zł. Tryb pełnego audytu od 0,80 zł do 4,70 zł, zależnie od zakresu dokumentów. Ta sama aplikacja. Ten sam interfejs. Zupełnie inny profil kosztowy. Bez etykiety ścieżki użytkownik nie rozumiałby, dlaczego jedno pytanie jest „prawie darmowe”, a inne ma sens tylko jako świadomie uruchamiana analiza.

Tani model do brudnej roboty

Najprostsza oszczędność polega na tym, żeby nie używać najdroższego modelu do każdej czynności. Drogi model zostawiam do finalnej odpowiedzi, zwłaszcza gdy wymaga rozumienia kontekstu, języka prawniczego albo ostrożnej syntezy. Do zadań pomocniczych używam tańszych modeli: przepisywanie zapytań, klasyfikacja intencji, generowanie wariantów multi-query, wstępne map-reduce, etykietowanie dokumentów, czasem walidacja formalna.

To nie zawsze działa. Tani model potrafi źle przepisać zapytanie i zepsuć retrieval. Potrafi usunąć numer faktury, bo uzna go za detal. Potrafi uprościć pytanie prawnika do ogólnego hasła. Dlatego każdą zamianę modelu testuję na zestawie pytań produkcyjnych. W jednym wdrożeniu przenieśliśmy klasyfikację intencji z drogiego modelu na mały model i koszt tej warstwy spadł o 82%. Jakość decyzji spadła z 94% do 91% na naszym zbiorze. Akceptowalne. Przy przepisywaniu zapytań ta sama zamiana rozwaliła wyniki dla numerów umów. Wycofaliśmy ją po jednym dniu.

Routing tani-drogi jest kolejnym krokiem. Prosty klasyfikator decyduje, czy pytanie idzie szybką ścieżką, czy do droższego modelu. Jeśli użytkownik pyta „jaki jest termin zgłoszenia szkody?”, nie potrzebujemy armaty. Jeśli pyta „porównaj odpowiedzialność dostawcy w pięciu umowach i wskaż wyjątki”, potrzebujemy cięższej ścieżki i prawdopodobnie większego modelu. Domyślnie tanio, głęboko po sygnałach. Ta zasada brzmi nudno, ale ratuje budżety.

Cache nie jest oszustwem

W firmowych systemach pytania się powtarzają. Ludzie pytają o pracę zdalną, limity delegacji, terminy wypowiedzenia, zasady obiegu faktur. Jeśli za każdym razem uruchamiasz pełny pipeline, płacisz za brak pamięci. Cache odpowiedzi na powtarzalne pytania potrafi dać dużą oszczędność, ale trzeba go zrobić ostrożnie.

Nie cache’uję odpowiedzi bez kontekstu uprawnień. Ten sam tekst pytania od pracownika działu sprzedaży i prawnika może mieć inny zakres dokumentów. Cache musi uwzględniać tenant, zespół, wersję indeksu, wersję promptu, wersję modelu i czas ważności. Przy pytaniach o polityki HR cache może żyć kilka dni. Przy danych finansowych albo statusach spraw czasem tylko kilka minut. Przy pytaniach zawierających dane osobowe wolę cache wyłączyć albo cache’ować tylko wynik po anonimizacji, jeśli proces na to pozwala.

W jednym intranetowym asystencie cache zmniejszył koszt generowania odpowiedzi o 23% w drugim miesiącu. Bez agresywnych sztuczek. Po prostu najpopularniejsze pytania wracały. Największa korzyść była jednak w czasie odpowiedzi: z 4–6 sekund do mniej niż sekundy dla trafień cache. Użytkownicy nazwali to poprawą jakości, choć merytorycznie odpowiedź była ta sama.

Budżety i alerty muszą być bliżej zespołów

Centralny budżet „na AI” szybko staje się mgłą. Wolę budżety per zespół i per agent. Dział prawny ma inne potrzeby niż HR. Finanse mogą akceptować droższe audyty, jeśli zastępują ręczną pracę. Marketing może generować dużo tekstu, ale na tańszych modelach. Jeśli wszystko wrzucimy do jednego worka, najgłośniejszy zespół wygra, a najdroższy agent ukryje się w średniej.

Alerty ustawiam nie tylko na kwotę miesięczną. Patrzę na anomalię: koszt per pytanie nagle rośnie, liczba rund agenta skacze, map-reduce odpala się częściej niż zwykle, cache hit rate spada po reindeksacji. Raz złapaliśmy błąd w promptcie, bo średnia liczba tokenów wyjściowych wzrosła z 900 do 2400. Model zaczął drukować zbyt długie uzasadnienia, bo ktoś dopisał „wyjaśnij szczegółowo”. Brzmiało niewinnie. Koszt odpowiedzi wzrósł o kilkadziesiąt procent.

Pomaga też prosty zwyczaj: każda większa zmiana promptu albo routingu dostaje przewidywany wpływ na koszt. Nie wielką analizę finansową, tylko krótką notatkę w zadaniu: więcej kontekstu, dodatkowa walidacja, spodziewany wzrost o 20–30%. Dzięki temu product owner nie dowiaduje się po fakcie, że poprawka jakości była tak naprawdę nową usługą w przebraniu.

Obserwowalność: timeline zamiast jednej liczby

Dobry dashboard kosztów pokazuje timeline wykonania pytania. Najpierw klasyfikacja: 300 tokenów. Potem HyDE: 700. Potem retrieval i re-ranking: koszt X. Potem odpowiedź finalna: 12 tysięcy tokenów wejściowych, 1100 wyjściowych. Potem walidacja: 9 tysięcy wejściowych. Jeśli widzę tylko sumę, nie wiem, co ciąć. Jeśli widzę ścieżkę, decyzje są prostsze.

Wspomniany agent audytowy, który przepalał budżet, miał problem architektoniczny. Czytał duży zbiór dokumentów przy każdym pytaniu. Rozwiązanie nie polegało na obniżeniu temperatury ani skróceniu odpowiedzi. Przenieśliśmy część pracy do indeksacji: ekstrakcja faktów raz, przy ingestii dokumentu. Z umów wyciągaliśmy daty, strony, limity odpowiedzialności, zapisy o podwykonawcach i cesji. Potem pytanie audytowe szło najpierw po ustrukturyzowanych faktach, a dopiero przy sporach dociągało fragmenty źródłowe. Koszt typowego audytu spadł z zakresu 0,80–4,70 zł do 0,18–0,90 zł. Czas odpowiedzi też spadł. To była jedna z tych zmian, po których człowiek żałuje, że nie zrobił jej wcześniej.

Kiedy oszczędzać, a kiedy zapłacić

  • Oszczędzaj na krokach pomocniczych: klasyfikacja, przepisywanie zapytań, wstępne streszczenia i walidacje często nie wymagają najlepszego modelu.
  • Płać za finalną odpowiedź, gdy użytkownik podejmuje decyzję prawną, finansową albo operacyjną i potrzebuje dobrej syntezy ze źródeł.
  • Nie uruchamiaj map-reduce bez limitu, jeśli pytanie można obsłużyć filtrem metadanych, ustrukturyzowanymi faktami albo zwykłym retrieval.
  • Cache’uj ostrożnie, szczególnie tam, gdzie działają uprawnienia, RODO i wersjonowanie dokumentów.

Najtańszy system, który daje złe odpowiedzi, jest drogi. Najdroższy system, który robi pełny audyt przy każdym pytaniu, też jest drogi. FinOps dla LLM polega na dobraniu ilości pracy do ryzyka pytania. Nie na ślepym cięciu kosztów.

Moja rada dla zespołu po pierwszym pilotażu

Po dwóch tygodniach pilotażu wyeksportujcie 200 sesji i policzcie koszt per zapytanie, per agent, per ścieżka. Oznaczcie 20 najdroższych. Przeczytajcie je ręcznie. Prawie zawsze znajdziecie coś banalnego: za szeroki top-K, walidację odpaloną dwa razy, map-reduce dla pytań punktowych, drogi model w klasyfikatorze albo brak cache dla pytania, które pada codziennie. To nie jest efektowna praca. To higiena.

Najbardziej lubię moment, gdy FinOps przestaje być rozmową o zakazach, a staje się rozmową o projektowaniu. Które pytania zasługują na droższą ścieżkę? Które można obsłużyć taniej? Co policzyć przy indeksacji, żeby nie płacić za to przy każdej rozmowie? Jeśli masz już agenta w firmie, otwórz logi kosztowe i znajdź jednego pożeracza. Chętnie porównałbym takie historie na LinkedIn, bo prawdziwe oszczędności rzadko siedzą tam, gdzie marketing dostawców każe ich szukać.