Pierwsza poważna faktura za API modelu językowego kończy fazę zachwytu szybciej niż jakikolwiek audyt. Znam ten schemat z własnego podwórka: buduję workflowy, które codziennie wywołują modele językowe (piszą artykuły, klasyfikują zgłoszenia, generują posty) i od początku każę im liczyć zużyte tokeny. Z tej praktyki mam dwa wnioski. Bez pomiaru na poziomie pojedynczego wywołania nie wiadomo, która funkcja zjada budżet. A zmiana promptu bez testu regresyjnego to wdrażanie na ślepo. Na oba problemy stosuję ten sam duet: Langfuse do mierzenia i Jenkins do pilnowania.
Zwykłe logi nie pokazują, ile kosztowało wywołanie
Standardowy monitoring (ELK, Datadog) zapisze treść requestu i odpowiedzi. Przy aplikacji opartej o LLM to za mało, bo pytania są inne: ile tokenów zużył konkretny krok łańcucha, ile trwało odpytanie bazy wektorowej, ile kosztowało jedno użycie funkcji u jednego klienta. Langfuse odpowiada na nie trace’ami: każde wywołanie zapisuje jako drzewo kroków, z liczbą tokenów, latencją i kosztem w dolarach przy każdym węźle.
Taka struktura zmienia sposób szukania problemów. Gdy odpowiedź trwa sześć sekund, trace pokazuje, że cztery z nich zjada wyszukiwanie w bazie wektorowej (RAG), a sam model generuje tekst w niecałe dwie. Optymalizuję wtedy indeks, a nie prompt, bez trace’a poprawiałbym nie to, co trzeba.
Koszt przypisany do funkcji, nie do faktury
Największą wartość biznesową daje tagowanie. Każdy trace oznaczam identyfikatorem funkcji, użytkownika albo projektu i po tygodniu mam rozkład kosztów: „podsumuj dokument” kosztuje średnio 5 centów za użycie, „wygeneruj e-mail”, ułamek centa. Z takich liczb wynikają decyzje, których łączna kwota na fakturze nie podpowie: gdzie podmienić model na tańszy, jak wycenić funkcję w cenniku, który klient generuje koszty wyższe niż jego abonament.
Jenkins zatrzymuje drogie regresje promptów
Pomiar to połowa roboty. Druga połowa to blokowanie zmian, które psują jakość albo podbijają koszt. Prompty regresują jak kod: poprawka jednego zdania w prompcie systemowym potrafi ulepszyć 90 procent odpowiedzi i równocześnie wywołać halucynacje w pozostałych 10. Po siedmiu latach w QA traktuję prompt jak każdy inny artefakt w repozytorium, zmiana przechodzi przez pipeline albo nie wchodzi na produkcję.
Pipeline w Jenkinsie dla aplikacji LLM układam z czterech etapów:
- Trigger: commit zmieniający prompt albo konfigurację modelu.
- Ewaluacja: skrypt (u mnie pytest plus SDK Langfuse) uruchamia nowy prompt na złotym zbiorze danych: kilkudziesięciu przykładach wejść ze znanym, dobrym wynikiem.
- Ocena: odpowiedzi punktuje drugi, tańszy model (LLM-as-a-judge) albo metryki deterministyczne, np. obecność wymaganych fraz. Wyniki trafiają do Langfuse jako scores.
- Bramka: Jenkins odpytuje API Langfuse o zagregowane wyniki tego przebiegu. Średni score poniżej progu albo koszt suity wyższy od bazowego o 20 procent oznacza build FAILED.
Sama bramka to kilka linijek Pythona na końcu skryptu testowego:
wyniki = langfuse.get_scores(batch_id=przebieg)
if wyniki.avg_score < 0.85 or wyniki.total_cost > koszt_bazowy * 1.2:
sys.exit(1) # Jenkins oznaczy build jako FAILEDCo ta pętla daje w praktyce
Z połączenia danych z Langfuse i bramek w Jenkinsie wychodzą optymalizacje, które da się wdrożyć bez strachu o produkcję:
- Cache semantyczny: gdy trace’y pokazują, że jedna trzecia zapytań jest semantycznie bliska wcześniejszym, warstwa cache przed modelem tnie koszt od razu. Testy w pipelinie sprawdzają, czy odpowiedzi z cache’a trzymają jakość.
- Routing modeli: proste zadania rzadko potrzebują najdroższego modelu. Z zestawem testów regresyjnych podmieniam model na tańszy dla wybranych ścieżek; jeśli jakość spadnie poniżej progu, bramka nie przepuści zmiany.
Od czego zacząć
Pomiar ustawiam pierwszego dnia projektu, bo dopisywanie obserwowalności do działającego systemu kosztuje kilka razy więcej pracy. Jeśli dopiero planujesz modele językowe u siebie, szerszy plan takiego startu opisuję w tekście o wdrożeniu AI w firmie. A jeśli celem jest własny asystent AI dla firmy, granularne liczenie kosztów rozstrzyga, czy jego rentowność w ogóle się spina.
Jak pomagam w QA Sensei
Jestem Paweł Szewczyk, od 20 lat pracuję w IT, od siedmiu jako inżynier jakości. Workflowy z modelami językowymi buduję na własne potrzeby i dla klientów, każdy z licznikiem tokenów, bo przestałem wierzyć w „to będzie tanie” bez liczb. Pomagam ustawić obserwowalność wywołań LLM, zbudować złoty zbiór danych i wpiąć ewaluacje w istniejący pipeline CI/CD, żeby zmiany promptów przechodziły przez tę samą bramkę co kod. Pracuję zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta.