Co zostaje, a co odchodzi: mapowanie wiedzy o testowaniu internetu na nowy świat dużych modeli językowych
Przykładowa aplikacja
W tej serii artykułów przykładową aplikacją jest ThemeBuilder. Narzędzie ThemeBuilder generuje obiekt JSON zawierający wygenerowane przez LLM motto i paletę kolorów.
- Motto i paleta muszą pasować do podanej nazwy marki, opisu, odbiorców i tonu.
- Motto nie może być obraźliwe i musi być krótkie (maksymalnie 6 słów).
- Kontrast palety kolorów musi być zgodny z wytycznymi WCAG dotyczącymi minimalnego współczynnika kontrastu, czyli 4, 5:1.
Oceny obiektywne i subiektywne
Jak sprawdzić, czy narzędzie ThemeBuilder działa zgodnie z zamierzeniami?
Oceny oparte na regułach (czasami nazywane dokładnymi ocenami) to obiektywne testy z odpowiedzią binarną: prawidłową lub nieprawidłową. Najlepiej nadają się do pytań o format danych, współczynnik kontrastu lub innych, na które można udzielić jednoznacznej odpowiedzi. Możesz przeprowadzać te testy za pomocą zwykłego kodu programowego.
Niektóre weryfikacje są obiektywne i mają binarną odpowiedź: prawidłowa lub nieprawidłowa. Są one najlepsze w przypadku pytań dotyczących formatu danych, współczynnika kontrastu lub innych kwestii, na które można udzielić jednoznacznej odpowiedzi. Możesz je przeprowadzać za pomocą zwykłego kodu programowego. Są one nazywane ocenami opartymi na regułach lub ocenami dokładnymi.
Na przykład:
// Example rule-based eval: data format
function evaluateFormat(appOutput) {
// Check if JSON is valid, colors are hex, no empty strings, motto is 6 words or fewer
// Use deterministic tools like zod for schema validation
return "PASS"; // or "FAIL"
}
Inne sprawdzenia są subiektywne, np. dopasowanie marki i odbiorców do motta i palety kolorów. Wykrywanie toksyczności jest zadaniem klasyfikacyjnym, ale ma też charakter subiektywny, ponieważ wymaga oceny.
Testy subiektywne również obejmują klasyfikację, ale zakres tego, co jest poprawne i niepoprawne, może się znacznie różnić. Na przykład ocena zgodności marki i odbiorców z mottem i paletą kolorów. Wykrywanie toksyczności też jest subiektywne.
Ocena subiektywnych cech może się wydawać czymś, co może zrobić tylko człowiek, ale możesz zautomatyzować te testy na dużą skalę za pomocą metody LLM-as-a-judge.
[Modele LLM] są szybkie, łatwe w użyciu i stosunkowo tanie. [...] Stały się jedną z najpopularniejszych, jeśli nie najpopularniejszą, metodą oceny modeli AI w środowisku produkcyjnym.
– AI Engineering, Chip Huyen
Na przykład:
// Example LLM-as-a-judge eval for a subjective quality like brand fit
async function evalBrandFit(userInput, appOutput) {
const brandPrompt = `You are an expert brand strategist. Evaluate the
following generated motto for the company whose target audience is
${userInput.audience}, and who describes itself as
${userInput.companyDescription}: ${appOutput.motto}`
// Call the LLM judge
const evalResult = evalWithLLM(brandPrompt);
// Return the consolidated results
return {
mottoBrandFit: evalResult,
};
}
// Helper that communicates with the LLM API
async function evalWithLLM(prompt) {
// ... Call LLM with the prompt ...
// ... Parse the resulting judgement ("PASS" or "FAIL") + rationale
return {
status: "PASS",
rationale: "This motto perfectly captures the brand and tone, because..."
};
}
Model naśladuje ludzkie osądy, więc musisz dokładnie określić, czego szukasz. Możesz to zrobić, oferując sędziemu ocenę cząstkową.
Ocena cząstkowa to uporządkowany zestaw kryteriów lub wytycznych dotyczących oceniania, których sędzia (człowiek lub AI) używa do oceny wyniku. Zapewnia spójne ramy oceny subiektywnych cech w każdej ocenie.
Inne typy ocen
Możesz użyć ocen opartych na odniesieniu lub ocen par.
Oparte na źródłach
Mierzą one podobieństwo do odpowiedzi opartej na danych podstawowych. Używaj ich do zadań takich jak tłumaczenie czy podawanie faktów technicznych, w przypadku których istnieje znana dobra odpowiedź.
Parami
Sędzia może przyznać PASS punktów dwóm różnym wersjom, nawet jeśli jedna jest lepsza od drugiej. Oceny parami rozwiązują ten problem, ponieważ dają oceniającemu 2 wyniki (A i B) dla tych samych danych wejściowych i instruują go, aby wybrał zwycięzcę.
Załóżmy na przykład, że oceniasz motto przytulnej kawiarni:
Input: "Friendly cafe"
Pointwise evaluation:
Output A: "Come get coffee." // PASS
Output B: "Your morning smile in a cup." // PASS
2 PASS. Unconclusive!
Pairwise evaluation:
Output B wins. It captures the "friendly" tone more effectively than the generic Output A.
Użyj oceny parami, aby wybrać wersję modelu, którą chcesz wdrożyć, lub porównać 2 różne prompty.
Standardowe testy w internecie a oceny AI
Zakładamy, że czytelnik tego kursu wie już, jak testować strony i aplikacje internetowe. Gdy dodajesz AI, musisz zmienić dotychczasowy model myślowy. Korzystając z oceny AI, możesz wykonywać te czynności:
- Przeprowadź testy regresji: czy po zmianie promptu lub modelu aplikacja przestała działać? Czy otrzymujesz uszkodzone palety kolorów lub toksyczne motta? W przeciwieństwie do aplikacji internetowej, w której przerwa jest funkcją oprogramowania, w tym przypadku sprawdzasz, czy dane wyjściowe modelu LLM są wysokiej jakości i bezpieczne. Wymaga to subiektywnej oceny.
- Optymalizacja aplikacji: czy Twoja aplikacja staje się lepsza? Czy poprawiasz wybrane przez siebie dane, np. czy uzyskujesz więcej haseł zgodnych z marką bez zwiększania toksyczności?
- Wybierz odpowiedni model: czy istnieje lepszy model dla Twojego przypadku użycia? Przed erą AI wybierasz stos internetowy tylko raz. W przypadku AI należy regularnie porównywać modele, aby znajdować możliwości przejścia na lepszy (i potencjalnie tańszy) model.
Warstwowe testy
Zdrowa baza kodu powinna mieć wiele warstw testów: testy jednostkowe, testy regresji i integracji oraz testy kompleksowe. Ocena powinna być też wielopoziomowa.
- Używaj ocen opartych na regułach w połączeniu z ocenami LLM jako sędziego, aby w pełni zautomatyzować testy aplikacji AI. Dzięki temu możesz wykrywać problemy w codziennym procesie tworzenia oprogramowania i CI/CD oraz sprawdzać, czy wersje kandydujące spełniają Twoje wymagania jakościowe.
- Przeprowadzaj testy integracji i regresji, aby weryfikować jakość na dużą skalę.
- Przeprowadź ręczne oceny przez osoby jako test akceptacyjny.
Oprócz ocen przeprowadzanych w czasie kompilacji monitoruj ruch produkcyjny za pomocą ocen przeprowadzanych w czasie działania. Pomagają one wykrywać problemy z jakością lub bezpieczeństwem w przypadku danych z rzeczywistego świata.
Stale ulepszaj oceny
Wartości ewaluacji powinny rosnąć wraz z aplikacją. Gdy Twoje modele staną się bardziej zaawansowane, zaktualizuj stare oceny.
Regularnie dodawaj do zbiorów danych testowych trudne przykłady, takie jak nowe przypadki brzegowe lub zaskakujące dane wejściowe użytkowników, które znajdziesz w środowisku produkcyjnym.
Co mierzą Twoje oceny?
Zanim zaczniesz projektować oceny, musisz wiedzieć, jak oceniać dane wyjściowe. Musisz znać kilka terminów.
Kryteria to reguły, czyli wymiary, które należy przetestować. Na przykład dopasowanie do marki, toksyczność i dostępność.
Każde kryterium oceny jest mierzone za pomocą wskaźnika. Metryka to pojedynczy, konkretny wynik, który mierzy dane wyjściowe modelu w odniesieniu do kryterium. Może to być wartość binarna lub wartość z zakresu, która określa, jak bardzo wynik jest zgodny z oczekiwaniami oceniającego.
To samo kryterium można mierzyć za pomocą różnych typów danych. Na przykład w przypadku dopasowania do marki:
- „Czy to motto jest zgodne z marką?” Wartość to
PASSlubFAIL. - „W skali od 1 do 5, gdzie 5 to ocena najlepsza, jak dobrze motto pasuje do marki?” Wartość tego parametru to liczba całkowita z zakresu od 1 do 5.
Oceniający to kod lub model, który ocenia kryterium. Oceniający określają dane.