MLOps dla aplikacji LLM: od prototypu do produkcji

Pilot działał przez trzy tygodnie bez większego problemu. Asystent odpowiadał w okolicach 1-2 sekund, klienci się nie skarżyli, wyniki z golden setu wyglądały zachęcająco. Potem ktoś zaproponował „drobną" aktualizację modelu u dostawcy i zmianę kilku zdań w prompcie systemowym. Wdrożenie poszło w piątek po południu. W poniedziałek rano okazało się, że odsetek zapytań eskalowanych do konsultantów wzrósł z 8 do 23 procent, a koszt tokenów skoczył o 40 procent. Nikt nie wiedział, która zmiana to spowodowała, bo obie weszły razem bez rozdzielenia.

To jest klasyczny scenariusz, który widzimy w Cashcrown regularnie. LLMOps, czyli warstwa operacyjna dla aplikacji LLM, istnieje dokładnie po to, żeby takich piątków już nie było.

W prototypie model jest głównym bohaterem. Sprawdzasz, czy w ogóle da się odpowiedzieć na interesujące cię pytania, testujesz kilkanaście promptów, zachwycasz się wynikami. W produkcji model staje się jednym z elementów systemu, który musi działać stabilnie przez miesiące, obsługiwać niespodziewane zapytania i kosztować tyle, ile zaplanowałeś.

Różnica nie leży w jakości modelu. Leży w warstwie, która nim zarządza.

Każdy z tych wymiarów można pominąć na etapie pilota. W produkcji każdy pominięty oznacza ryzyko. Szczegółowo różnicę między pilotem a produkcją rozwijamy w artykule od pilota AI do produkcji.

Największy błąd, który obserwujemy, to wersjonowanie prompta osobno od modelu. Jeśli prompt zmienił się o dwa zdania, a model poszedł z gpt-4o-2024-05-13 na nowszy identyfikator, masz de facto dwie zmiany jednocześnie. Gdy coś się posypie, nie wiesz, co cofać.

Rozwiązanie jest proste: cała konfiguracja dostaje jeden numer wersji. Zmieniasz cokolwiek w środku, to nowa wersja, nowe uruchomienie bramki, nowa ludzka decyzja. Artefakt wersji zawiera:

• pełny tekst promptu systemowego i szablonów (nie link do pliku, tylko treść)
• dokładny identyfikator modelu (nie latest, nie nazwa generyczna)
• parametry generacji: temperatura, top-p, limit tokenów
• schemat wyjścia, jeśli używasz structured output
• wersję bazy wiedzy lub indeksu RAG, z którą działa system
• reguły routingu, jeśli model dobierany jest dynamicznie przez inference router

Każda odpowiedź w logach produkcyjnych nosi ten numer wersji. To pozwala w ciągu minut odpowiedzieć na pytanie „czy degradacja zaczęła się przed, czy po danym deployowaniu". Bez tego pytanie zamienia się w kilkugodzinne śledztwo. Wzorzec szczegółowo opisujemy w tekście o wersjonowaniu promptów i modeli.

Golden set to zbiór reprezentatywnych zapytań z oznaczonymi kryteriami dobrej odpowiedzi. Bramka regresji to reguła: żaden artefakt wersji nie trafia na produkcję, dopóki nie przejdzie przez ten zbiór z wynikiem nie gorszym od poprzedniej wersji.

Budowę golden setu zaczynamy od 80-150 realnych przypadków z logów, nie od wymyślonych przykładów. Ważne, żeby w zbiorze były przypadki trudne, graniczne i te, które historycznie sprawiały kłopot. To one regresują najpierw po zmianie promptu.

Dla każdego przypadku definiujemy kryteria akceptacji. Rzadko jest to dokładne dopasowanie tekstu, częściej zestaw faktów, które muszą wystąpić, format, którego trzeba się trzymać, albo lista rzeczy, których nie powinno być w odpowiedzi. Automatyczna ocena działa na schemacie, regex albo LLM-as-judge skalibrowanym na ludzkich ocenach.

Wyniki bramki nie są tylko liczbą ogólną. Raport pokazuje wynik per kategoria zapytań, przykłady, które się pogorszyły względem poprzedniej wersji, i delta względem linii bazowej. Spadek o 3-4 punkty procentowe w jednej kategorii potrafi wskazywać na realne pogorszenie dla klientów z tej grupy, nawet gdy ogólny wynik wygląda stabilnie.

Metodę budowy golden setu i doboru metryk szerzej opisujemy w artykule o tym, jak ewaluować system RAG. Zasady są identyczne dla systemów agentowych.

Ludzka decyzja jest obowiązkowa na tym etapie. Bramka automatyczna mówi „wyniki nie spadły", ale nie ocenia, czy zmiany merytoryczne w prompcie są zgodne z intencją produktową. To jest decyzja człowieka, nie reguły.

Test regresji offline jest konieczny, ale niewystarczający. Realny ruch ma rozkłady, których golden set nie odwzorowuje w pełni. Dlatego duże zmiany, czyli aktualizacja modelu lub przebudowa struktury promptu, idą przez shadow albo canary.

Shadow to uruchamianie nowej wersji równolegle do starej na realnym ruchu. Klient dostaje odpowiedź ze starej wersji, nowa generuje wynik tylko do porównania. Zero ekspozycji, pełne dane o zachowaniu na prawdziwych zapytaniach. Shadow zostawiamy przez co najmniej 500-1000 zapytań albo kilka dni, zależnie od wolumenu ruchu.

Canary kieruje część ruchu na nową wersję, zwykle 5-10 procent, i porównuje metryki jakości oraz biznesowe na obu grupach. Progi przejścia definiujemy z góry: nowa wersja przejmuje cały ruch tylko wtedy, gdy nie pogarsza kluczowych metryk w ciągu zdefiniowanego okna czasowego. Decyzja należy do człowieka, nie do skryptu.

Obie metody kosztują, bo generujesz wywołania podwójnie. Dla małych poprawek promptu sam test regresji offline zwykle wystarcza; shadow i canary rezerwujemy na zmiany, gdzie ryzyko cichej degradacji jest realne. Ta sama logika dotyczy guardrails: zmiany w regułach bezpieczeństwa też powinny przejść shadow przed pełnym wdrożeniem, bo skutki uboczne są trudne do przewidzenia offline.

Po deployowaniu zaczyna się stały nadzór. Trzy wymiary, które mierzysz razem, bo każdy z osobna jest niekompletny.

Jakość to odsetek odpowiedzi, który spełnia kryteria ze złotego setu przeniesione na próbkę produkcyjną, plus sygnały pośrednie: wskaźnik eskalacji do człowieka, odsetek zapytań, na które system odpowiedział „nie wiem", i oceny użytkowników tam, gdzie je zbierasz. Wzrost wskaźnika eskalacji o kilka punktów procentowych to zwykle pierwszy sygnał dryfu, zanim cokolwiek innego wskaże problem.

Koszt mierzysz per obsłużone zdarzenie, nie jako zagregowany rachunek miesięczny. Rachunek miesięczny rośnie z ruchem i nie powie ci, że jeden kanał zaczął generować dwa razy droższe odpowiedzi bez wzrostu wartości. Koszt per zdarzenie to jest liczba, przy której natychmiast widać anomalie. Szczegółowe podejście do optymalizacji kosztów LLM opisujemy w artykule o monitoringu kosztów LLM.

Latencja to rozkład p50 i p95, nie średnia. Średnia ukrywa ogon powolnych odpowiedzi, które psują doświadczenie klientów z trudnymi pytaniami. Observability w systemie LLM oznacza logowanie każdego wywołania ze znacznikiem czasu, modelem, liczbą tokenów wejścia i wyjścia oraz numerem wersji artefaktu.

Jak wybrać metryki i progi alertów, żeby nie tonąć w fałszywych alarmach, opisujemy w osobnym tekście o monitoringu jakości agenta AI.

Rollback nie jest planem awaryjnym. Jest obowiązkowym elementem każdego deployowowania. Zanim nowa wersja idzie na produkcję, masz gotową odpowiedź na pytanie: „Co robimy, jeśli za godzinę metryki spadną poniżej progu?".

Odpowiedź jest prosta, bo artefakt wersji jest jedną paczką. Cofnięcie to przestawienie wskaźnika na poprzednią wersję, nie przepisywanie promptu z pamięci. Zajmuje mniej niż minutę. Poprzednia wersja musi być gotowa do uruchomienia, nie tylko zachowana w historii git.

Trzy sygnały wyzwalające rollback definiujemy z góry:

• wskaźnik eskalacji przekracza próg o więcej niż N punktów procentowych przez M minut
• koszt per zdarzenie rośnie powyżej limitu przez zdefiniowane okno
• latencja p95 przekracza próg SLA przez ciągły czas

Kiedy któryś sygnał się zapali, decyzja o rollbacku należy do człowieka, ale mechanizm jest gotowy. Nie ma cichych zamian modeli, nie ma deployowań bez bramki, nie ma „zobaczymy jak pójdzie". Każda zmiana ma właściciela i ścieżkę powrotu.

Klasyczny DevOps pilnuje poprawności kodu: testy jednostkowe, testy integracyjne, code review. MLOps dla LLM pilnuje poprawności zachowania modelu, która nie wynika bezpośrednio z kodu. Prompt jest poprawny składniowo, a mimo to może zachowywać się inaczej po zmianie jednego zdania. Dlatego obok testów kodu potrzebujesz bramki ewaluacyjnej na golden secie, shadow i canary zamiast prostego deploy, i ciągłego monitoringu jakości na ruchu produkcyjnym.

Zaczynamy od 80-150 przypadków z realnych logów lub zgłoszeń, nie z wymyślonych przykładów. Ważniejsza od liczby jest reprezentatywność: zbiór ma pokrywać główne klasy pytań, przypadki graniczne i te, które historycznie sprawiały kłopot. Każdy nowy incydent na produkcji to kandydat do dopisania do golden setu. Zbiór rośnie razem z systemem.

Tak. Podstawowa wersja to wersjonowanie artefaktów w git lub prostym rejestrze, skrypt testowy na golden secie w CI, logi wywołań w Postgresie lub pliku JSONL i dashboard z kilkoma wykresami. Komercyjne platformy MLOps przyspieszają, ale nie są warunkiem koniecznym. Kluczowa jest dyscyplina procesu: bramka przed deployowaniem, ludzka decyzja, gotowy rollback.

Pinuj dokładny identyfikator wersji modelu zamiast nazwy generycznej albo etykiety latest. Jeśli dostawca nie udostępnia identyfikatora, uruchamiaj golden set periodycznie nawet bez zmian po swojej stronie. Cichy dryft od strony dostawcy to jeden z najczęstszych źródeł regresji, których nikt nie wychwytuje przez tygodnie.

Dla drobnych zmian promptu, gdzie modyfikujesz format lub ton, test regresji offline na golden secie zwykle wystarczy. Shadow i canary rezerwujemy na zmianę modelu, przebudowę struktury promptu lub aktualizację bazy wiedzy o dużej skali. Reguła: im większy zakres zmiany i im trudniej przewidzieć efekty uboczne, tym bardziej uzasadnione jest kosztowne shadow zamiast prostej bramki offline.