Ewaluacja LLM online vs offline: co wybrać (i kiedy)

Ewaluacja LLM online vs offline: co wybrać (i kiedy)

Ewaluacja LLM online vs offline to jedna decyzja, nie dwie, i nasz zestaw testów promptfoo udowodnił to w zeszły wtorek: jeden przepisany prompt systemowy, 47 przypadków testowych, spadek wierności z 0,91 do 0,74 w około 90 sekund czasu CI. Kontrola offline wyłapała tę regresję przed mergem; monitoring produkcyjny spotkałby ją później, przebraną za wątek w supporcie. Offline czy online, werdykt jest ten sam: dwa pasy ruchu, różne zadania.

Ewaluacja offline LLM uruchamia model na stałym zbiorze danych przed wdrożeniem i udowadnia, że zmiana nie zepsuła mierzonej jakości. Ewaluacja online ocenia żywy ruch produkcyjny po wdrożeniu i ujawnia to, czego zbiór danych nigdy nie zawierał. Większość zespołów potrzebuje obu, w odpowiedniej kolejności: offline blokuje wdrożenie, online wyłapuje dryf.

Najważniejsze wnioski

• Ewaluacja offline działa na stałym zbiorze danych przed wdrożeniem; ewaluacja online ocenia żywy ruch po wdrożeniu.
• Większość zespołów potrzebuje obu: offline blokuje wdrożenia, online wyłapuje to, co przeoczył zbiór danych.
• Offline wyłapuje regresje promptów i błędy formatu; online wyłapuje dryf, opóźnienia pod obciążeniem i kaprysy integracji.
• Wepnij ewaluacje offline jako bramkę merge w CI; strumieniuj wyniki online z trace'ów produkcyjnych do swojego zestawu ewaluacyjnego.

Czym właściwie różni się ewaluacja online od offline? (9 wymiarów)

Oba tryby różnią się na dziewięciu osiach, ale decydująca jest jedna: źródło danych. Ewaluacja offline ocenia stały, wersjonowany zbiór danych przed wdrożeniem, natomiast ewaluacja online ocenia żywy ruch po wdrożeniu. Każda inna różnica (koszt, opóźnienia, ryzyko, ład) wynika z tego podziału.

Centrum wiedzy Label Studio przedstawia tę parę jako tryby uzupełniające się, a nie rywalizujące, i zgadzamy się z tym. Poniższa tabela rozwija to ujęcie o metryki specyficzne dla LLM, których ich generyczna wersja ML nie obejmuje.

Nasza interpretacja: kolumna offline odpowiada na pytanie „czy ta zmiana coś zepsuła?", a kolumna online na pytanie „czy produkcja oddala się od tego, co przetestowaliśmy?". Wiersz typów metryk to miejsce, gdzie oba tryby rozjeżdżają się najmocniej; nasz przewodnik po metrykach ewaluacji LLM omawia każdą z osobna.

Co łapie każdy z trybów, a co umyka obu?

Każdy tryb ma prywatną klasę błędów, której drugi nie widzi. Offline łapie zmiany, które Ty wprowadziłeś; online łapie zmiany, które świat wprowadził wokół Ciebie. Kosztowne awarie, te, które przeżywają obie siatki, potrzebują człowieka-recenzenta. Ta taksonomia to nasza synteza tego, co raportuje każdy z trybów, a nie opublikowany standard.

Ćwiartka „tylko offline" to miejsce, gdzie bramki CI zarabiają na siebie: przepisany prompt, który po cichu obniża zgodność formatu z 99% do 91%, jest niewidoczny w code review, a oczywisty w zestawie 47 przypadków. Ćwiartka „tylko online" jest bardziej podstępna. Prawdziwi użytkownicy formułują pytania, których Twój złoty zbiór nigdy nie zawierał, zewnętrzne API zrywają połączenia w godzinach, których staging nigdy nie trafia, a ktoś na pewno nakarmi Twojego chatbota promptem na 40 000 znaków, tylko żeby zobaczyć, co się stanie. Tej stronie poświęcony jest nasz przewodnik po ewaluacji agentów na produkcji, który obejmuje ocenę trajektorii wieloetapowych, a nie tylko pojedynczych odpowiedzi.

Dolny wiersz to ten, który zespoły pomijają, i ten, który je parzy. Błędy, które kosztują Cię użytkowników, to te, których żaden tryb nie łapie w pojedynkę. Potrzebują człowieka w pętli.

Jak wpiąć ewaluacje offline w bramkę CI? (Konfiguracja, której nikt nie pokazuje)

Dodaj runner ewaluacyjny jako wymagany status check przy każdym pull requeście, który dotyka promptu, modelu lub konfiguracji retrievera. Postaw asercję na próg. Zablokuj merge poniżej niego. Dokumentacja promptfoo opisuje dokładnie ten wzorzec CI i to jest ten, który stosujemy.

Krok w GitHub Actions

Odchudzona wersja bramki, której dziś używamy:

name: llm-eval-gate

on:
  pull_request:
    paths: ["prompts/**", "evals/**", "src/rag/**"]

jobs:
  faithfulness-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Run offline evals, fail the PR on regression
        run: npx promptfoo@latest eval --config evals/support-agent.yaml
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}  # LLM-as-judge

Konfiguracja YAML deklaruje przypadki testowe i asercje; eval kończy się kodem niezerowym, gdy zestaw spada poniżej progu, GitHub oznacza wymagany check jako nieudany, a przycisk merge robi się szary. Filtr paths ma znaczenie: poprawka w README nie powinna przepalać tokenów sędziego.

Co tak naprawdę łapie bramka

Wersja produkcyjna ocenia nasz łańcuch RAG agenta wsparcia na 47 złotych przypadkach przy każdym PR wpływającym na prompt. Pełny przebieg zajmuje około 90 sekund czasu CI, a merge jest automatycznie blokowany, gdy wierność spada poniżej 0,82. W ciągu trzech miesięcy bramka wyłapała dwie regresje, które w innym razie trafiłyby na produkcję: przepisanie promptu systemowego, które zbiło wierność z 0,91 do 0,74, oraz zmianę retrievera, która podwoiła długość kontekstu i ściągnęła trafność odpowiedzi poniżej progu. Żadna z nich nie wyglądała groźnie w review.

Bramka wierności w CI kosztuje 90 sekund na PR. Regresja wierności na produkcji kosztuje Cię wątek w supporcie i rollback.

Runnery, które można podpiąć pod ten wzorzec (promptfoo, DeepEval i resztę), porównaliśmy w naszym rankingu narzędzi do ewaluacji LLM.

Które narzędzia obsługują który tryb? (Macierz narzędzi i trybów)

Żadne pojedyncze narzędzie nie obsługuje czysto obu pasów. promptfoo i DeepEval to runnery offline-first, które potrafią oceniać wyeksportowane dane produkcyjne według harmonogramu; Langfuse i LangSmith to magazyny trace'y online-first, które dokładają scorery LLM-as-a-judge do wczytanych trace'ów. Macierz jest naszym odczytaniem dokumentacji każdego dostawcy: interpretacją, nie wyrocznią.

Wybierz promptfoo albo DeepEval, jeśli Twoją pierwszą potrzebą jest bramka merge blokująca złe prompty w CI. Wybierz Langfuse albo LangSmith, jeśli Twoją pierwszą potrzebą jest ocena żywego ruchu, a nasze porównanie Langfuse vs LangSmith szczegółowo omawia ten wybór. OpenAI Evals pozostaje outsiderem: runner offline w stylu rejestru, bez strony produkcyjnej.

promptfoo blokuje Twoje PR-y. Langfuse ocenia Twoje trace'y produkcyjne. Żaden nie zastępuje drugiego.

Jak pętla sprzężenia zwrotnego zamienia błędy online w testy offline?

Próbkuj nisko ocenione trace'y produkcyjne, oznaczaj je i commituj do offline'owego zestawu ewaluacyjnego. Zestaw regresji rośnie wtedy z każdą niespodzianką, jaką sprawia Ci produkcja, a kolejne wdrożenie jest bramkowane na rozszerzonym zestawie. Ujęcie koła zamachowego jest nasze; to ta część, której większość zespołów nigdy nie buduje.

Cykl w naszym wykonaniu:

1. Scorery online flagują trace'y z oceną sędziego poniżej 0,7.
2. Tygodniowo próbkujemy 20–30 oflagowanych trace'ów.
3. Człowiek oznacza każdy z nich: oczekiwana odpowiedź plus klasa błędu.
4. Oznaczone przypadki dołączają do offline'owego zestawu jako nowe złote przykłady.
5. Następny PR uruchamia się na rozszerzonym zestawie i pętla zaczyna się od nowa.

Próbkowanie zaczyna się w warstwie obserwowalności LLM, bo trace'y są surowcem. Co do rytmu: cotygodniowy bije comiesięczny, bo dryf się kumuluje. Oznaczamy 10–15 przypadków tygodniowo, a zestaw jest „wystarczająco duży", gdy nowe etykiety przestają ruszać wskaźnik zdawalności; dla wąskiego agenta wsparcia to około 150–250 przypadków. Granica między trybami coraz bardziej się zaciera: Deepchecks donosi, że inżynierowie Union.ai harmonogramują swoje „offline'owe" ewaluacje co kilka minut, faktycznie zamieniając je w kontrolę bliską czasowi rzeczywistemu.

Twój zestaw ewaluacyjny nie jest stałym artefaktem. Rośnie co tydzień, ilekroć produkcja Cię zaskoczy.

Kiedy potrzebujesz obu? (Ewaluacja LLM online vs offline na poszczególnych etapach)

Obu potrzebujesz od tygodnia wdrożenia wzwyż, ale równowaga przesuwa się zależnie od etapu: offline samodzielnie niesie pracę przedwdrożeniową, tydzień wdrożenia dokłada scoring shadow lub canary, stan ustalony opiera się na monitoringu online z okresowymi przebiegami offline, a alert o dryfie powinien zakończyć się odtworzonym testem offline i większym zestawem ewaluacyjnym.

Przed wdrożeniem najtaniej jest być surowym: zablokowany merge kosztuje minuty, a zła wersja kosztuje zaufanie. Tydzień wdrożenia to moment, w którym zespoły inwestują za mało, choć scoring shadow na małym wycinku ruchu kosztuje niewiele, a pokazuje, czy złoty zbiór kłamał. W stanie ustalonym wkrada się samozadowolenie, więc wpisz reewaluację do kalendarza.

A co z EU AI Act?

Obowiązki dla systemów wysokiego ryzyka z EU AI Act wchodzą etapami do sierpnia 2026, a pełny harmonogram terminów opublikowano w EUR-Lex; wzorzec zgodności czysto przekłada się na oba tryby. Udokumentowane dowody offline pokazują, że system spełnił cele jakościowe przed wydaniem; ciągły monitoring online pokazuje, że spełnia je nadal po wdrożeniu. Naszym zdaniem ścieżka audytu wymaga obu artefaktów, bo same logi offline nie dowodzą, że system pozostał zgodny, a same dashboardy nie dowodzą, że był zgodny w chwili wdrożenia. To interpretacja, nie porada prawna; nasz filar o pipeline ewaluacji LLM mapuje pełny zestaw wymagań.

Ewaluacja offline to Twój materiał dowodowy. Ewaluacja online to Twój system wczesnego ostrzegania. Regulatorzy chcą obu.

O autorze: Mert Batur jest współzałożycielem Techsy.io, gdzie jego zespół dostarcza agentów AI, systemy automatyzacji i pipeline'y głosowe/SDR dla klientów B2B. Pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa na produkcji. Połącz się na LinkedIn.

Często zadawane pytania

Czym jest ewaluacja offline LLM?

Ewaluacja offline LLM uruchamia model lub prompt na stałym, wersjonowanym zbiorze danych przed wdrożeniem. Typowe kontrole obejmują wierność wobec pobranego kontekstu, trafność odpowiedzi, zgodność formatu i wyniki benchmarków. Ponieważ zbiór danych nie zmienia się w trakcie przebiegu, wyniki są powtarzalne i porównywalne, i dokładnie dlatego zestawy offline sprawdzają się jako bramki merge w CI.

Czym jest ewaluacja online LLM?

Ewaluacja online LLM ocenia żywy ruch produkcyjny po wdrożeniu. Scorer LLM-as-a-judge ocenia próbkowane trace'y pod kątem halucynacji, tonu lub poprawności wywołań narzędzi, a wyniki płyną na dashboard. Przechwytuje też sygnały, których testy offline nie widzą: opóźnienia pod obciążeniem, feedback użytkowników i to, jak prawdziwe zapytania różnią się od Twojego złotego zbioru.

Kiedy stosować ewaluację offline, a kiedy online?

Stosuj ewaluację offline do bramkowania wdrożeń: każda zmiana promptu, modelu lub retrievera powinna przejść zestaw przed mergem. Stosuj ewaluację online do monitorowania tego, co zostało wdrożone. Większość zespołów układa oba tryby w sekwencję, zamiast wybierać jeden: najpierw offline, online od tygodnia wdrożenia wzwyż, a błędy produkcyjne spływają z powrotem do zbioru offline.

Jaki jest przykład ewaluacji online vs offline LLM?

Przykład offline: zestaw promptfoo uruchamia 200 złotych pytań wsparcia przy każdym pull requeście i blokuje merge, gdy wierność spada poniżej 0,82. Przykład online: Langfuse ocenia 10% żywych trace'y kontrolą halucynacji LLM-as-a-judge i alarmuje, gdy tygodniowa średnia się obsuwa. Ta sama rubryka, inne źródło danych.

Jak human-in-the-loop wpisuje się w ewaluację LLM?

Ludzie domykają lukę, której nie pokrywa żaden tryb: nowe przypadki brzegowe, subiektywne oceny jakości i dryf głosu marki. Praktyczny rytm to oznaczanie 10–20 próbkowanych, nisko ocenionych trace'ów tygodniowo i commitowanie oznaczonych przypadków do offline'owego zestawu ewaluacyjnego. Kolejka recenzji jest wejściem pipeline'u, nie projektem pobocznym.

Jak działają ewaluacje Langfuse w scoringu online?

Langfuse przechwytuje trace'y z Twojej aplikacji, a następnie dołącza ewaluatory LLM-as-a-judge, które oceniają każdy trace według rubryki: halucynacje, trafność, toksyczność albo własny prompt. Wyniki trafiają na dashboard powiązany z sesjami i użytkownikami. Zespoły eksportują trwale nisko ocenione trace'y do offline'owego zbioru danych do testów regresji. Nasz ranking platform obserwowalności porównuje magazyny trace'ów zasilające ten wzorzec.

Jak dodać ewaluacje offline do pipeline'u CI/CD?

Dodaj runner ewaluacyjny jako wymagany status check przy pull requestach, które dotykają promptów, modeli lub konfiguracji retrievera. Zarówno promptfoo, jak i DeepEval działają bez interfejsu i kończą się kodem niezerowym przy niepowodzeniu asercji, co automatycznie blokuje merge. Bramka YAML z wcześniejszej części tego wpisu to działający szablon; zacznij od 30–50 przypadków.

Czy EU AI Act wymaga ewaluacji offline, czy online?

W praktyce obu. Dla systemów wysokiego ryzyka akt oczekuje udokumentowanych dowodów, że cele jakościowe zostały osiągnięte przed wydaniem, co oznacza artefakty offline, oraz ciągłego monitoringu po wdrożeniu, co oznacza telemetrię online. Jego etapowe terminy biegną do sierpnia 2026 zgodnie z EUR-Lex. To nasza interpretacja wzorca zgodności, nie porada prawna.

Czy LLM-as-a-judge może działać w obu trybach, offline i online?

Tak, i powinien, bo rubryka się przenosi. Offline sędzia ocenia wsadowo każde wyjście zestawu ewaluacyjnego podczas CI. Online ten sam prompt sędziowski ocenia próbkowane trace'y produkcyjne w czasie bliskim rzeczywistemu. Utrzymanie jednej rubryki w obu trybach sprawia, że Twoja offline'owa baza jest porównywalna z Twoim online'owym sygnałem dryfu.

Które metryki różnią się między ewaluacją offline i online?

Metryki offline mierzą jakość wyjścia względem prawdy podstawowej: wierność, trafność odpowiedzi, zgodność formatu, wyniki benchmarków. Metryki online dokładają sygnały operacyjne i behawioralne: opóźnienie p95, wskaźnik błędów, wskaźnik halucynacji na żywym ruchu, wskaźnik dryfu i satysfakcję użytkowników. Lista offline pyta „czy jest dobrze?", a lista online pyta „czy nadal jest dobrze?".

W skrócie

• Ewaluacja offline i online to uzupełniające się pasy, a nie wybór „albo-albo": jedna bramkuje to, co wdrażasz, druga pilnuje tego, co już wdrożyłeś.
• Zacznij od bramki CI w tym tygodniu, dodaj scoring trace'ów online przy wdrożeniu i wepnij pętlę sprzężenia zwrotnego, zanim Twój zestaw ewaluacyjny się zestarzeje.
• Pętla jest systemem. Statyczny złoty zbiór gnije; rosnący procentuje.

Jeśli chcesz, żeby ktoś drugi rzucił okiem na Twój pipeline ewaluacyjny, umów się na bezpłatną konsultację.