Ewaluacja LLM: metryki, testy i bramki wdrożeniowe

Ewaluacja LLM sprawdza, czy system wykonuje konkretne zadanie wystarczająco dobrze i bezpiecznie. Ranking ogólnego modelu nie odpowie, czy firmowy asystent poprawnie cytuje procedury, nie ujawnia danych i odmawia niebezpiecznych działań.

NIST podkreśla, że testy powinny być związane z kontekstem użycia, ograniczeniami i mierzalnym wpływem. Najważniejszą jednostką oceny jest cały system, nie sam endpoint modelu.

Zbuduj reprezentatywny zestaw

Zbieraj rzeczywiste, zanonimizowane przypadki oraz scenariusze rzadkie, ale wysokiego ryzyka. Podziel dane na zestaw rozwojowy i utrzymywany poza zespołem zestaw bramkowy. Usuń duplikaty oraz oznacz język, trudność, kategorię i oczekiwane zachowanie.

Nie optymalizuj promptu na wszystkich przykładach, bo wynik przestanie przewidywać produkcję. Regularnie dodawaj nowe przypadki z błędów i incydentów.

Mierz kilka wymiarów

Jedna średnia ukrywa awarie. Oceniaj:

poprawność i kompletność zadania;
oparcie odpowiedzi na źródłach oraz trafność cytowań;
ujawnienie danych i odporność na prompt injection;
prawidłowe odmowy oraz nadmierne odmowy;
użycie narzędzi, argumenty i skutki działania;
opóźnienie, koszt i zużycie tokenów;
różnice między językami oraz grupami użytkowników.

Dla systemu RAG mierz retrieval oddzielnie od generacji. Model nie odpowie na podstawie dokumentu, którego retriever nie dostarczył.

Automatyczne oceny wymagają kalibracji

Reguły deterministyczne są najlepsze dla formatu, cytowań, schematu i zakazanych danych. LLM-as-a-judge skaluje ocenę semantyczną, ale sam ma bias, zmienność i ograniczenia.

Porównaj sędziego z ocenami ekspertów na reprezentatywnej próbce. Mierz zgodność i analizuj klasy błędów. Nie używaj tej samej rodziny modelu jako jedynego sędziego własnych odpowiedzi w krytycznej bramce.

Red teaming i testy przeciwnika

Dodaj ataki wielojęzyczne, zakodowane, wieloetapowe i osadzone w dokumentach. Testuj wyciek promptu, omijanie polityki, zatrucie RAG, nadmierną autonomię i niebezpieczne parametry narzędzi.

Scenariusze powinny wynikać z modelu zagrożeń aplikacji LLM. Udany atak staje się testem regresji z oczekiwanym bezpiecznym wynikiem.

Bramki i budżety błędów

Ustal minimalny wynik dla krytycznych klas, maksymalny odsetek wycieków, limit regresji względem wersji produkcyjnej oraz budżet kosztu i opóźnienia. Średnia poprawa nie może przykryć nowej krytycznej ścieżki ataku.

Każda zmiana modelu, promptu, retrievera, narzędzia lub polityki uruchamia właściwą część zestawu. Wysokiego ryzyka zmiana wymaga pełnej ewaluacji i zatwierdzenia ownera.

Monitoring po wdrożeniu

Produkcja dostarcza sygnałów o drifcie, nowych typach żądań, kosztach, odmowach i korektach użytkowników. Próbkuj dane zgodnie z prywatnością i twórz z nich testy. Wykrycie regresji powinno umożliwiać szybki rollback wersji modelu lub promptu.

Minimalny raport ewaluacji

Wersja całego systemu i data testu.
Przypadek użycia, populacja i ograniczenia.
Zestawy danych oraz ochrona przed contamination.
Wyniki per kategoria, nie tylko średnia.
Testy bezpieczeństwa i nierozwiązane ryzyka.
Koszt, opóźnienie i porównanie z baseline.
Decyzja, owner i data kolejnego przeglądu.

Ewaluacja jest mechanizmem podejmowania decyzji. Jeśli raport nie określa, czy system może wejść na produkcję i pod jakimi warunkami, pozostaje eksperymentem bez bramki.

Zestaw testowy, który nie przecieka

Oddziel przypadki rozwojowe od zamkniętego zestawu bramkowego. Wersjonuj dane, kryteria, prompt systemowy, model i parametry, a wyniki oceniane przez ludzi kalibruj na wspólnych przykładach. Jeżeli te same przypadki są wielokrotnie używane do strojenia, przestają mierzyć generalizację.

Metryka średnia ukrywa rzadkie, kosztowne błędy. Raportuj osobno klasy danych, języki, grupy użytkowników, odmowy, fałszywe pozytywy i działania narzędzi. Bramka powinna obejmować limit najgorszej kategorii, a nie tylko poprawę średniej. Po wdrożeniu porównuj drift wejść i wyniku z bazą, zachowując możliwość bezpiecznego rollbacku.

Źródła: NIST TEVV, NIST CAISI, NIST GenAI Profile.