LLM evaluacije prije svakog izdanja

Evaluacija (eval) je automatski test za AI funkciju. Fiksni skup ulaza provučete kroz sistem, ocijenite rezultate i uporedite ih s prethodnom verzijom. Ovaj članak je za produktne i inženjerske timove koji isporučuju funkcije s jezičkim modelima (LLM) i žele mijenjati prompte, modele i pretragu bez nagađanja šta se pokvarilo.

Klasični unit testovi pretpostavljaju da isti ulaz daje isti izlaz. LLM sistemi su probabilistički, a male promjene imaju daleke posljedice. Izmjena prompta koja riješi jednu žalbu može tiho pokvariti dvadeset drugih slučajeva, a nova verzija modela može odjednom promijeniti ton, format i to kada odbija odgovor. Bez evaluacija je svaka nova verzija procjena napamet, na osnovu nekoliko ručno odabranih primjera.

Kada imate evaluacije, dobijate:

• Ocjenu kvaliteta koju možete pratiti kroz vrijeme.
• Provjeru prije izdanja koja zaustavi pad kvaliteta prije nego što ga korisnici vide.
• Sigurnost da zamijenite model ili smanjite trošak, jer efekat možete izmjeriti.
• Zajedničku definiciju "dobrog" rezultata za produkt, inženjering i stručnjake iz oblasti.

Najkorisniji skupovi testova dolaze iz stvarnog saobraćaja i stvarnog posla. Sintetička pitanja koja napiše tim obično su uredna i predvidiva, a stvarni korisnici pišu kratka, nejasna pitanja s greškama i ubace pola dokumenta. Sintetičke slučajeve koristite da popunite praznine, nakon stvarnih.

Dobri izvori slučajeva:

1. 01Logovi iz stvarne upotrebe, uzorkovani po vrstama korisnika i namjerama, bez ličnih podataka.
2. 02Tiketi podrške i eskalacije, posebno oni u kojima je AI pogriješio.
3. 03Primjeri stručnjaka iz oblasti za rijetke slučajeve koji su jako važni, na primjer odštetni zahtjev koji se mora odbiti.
4. 04Namjerno zlonamjerni slučajevi: pokušaji prompt injectiona, pitanja izvan obima i ulazi na drugim jezicima.

Počnite s 50 do 100 slučajeva i proširite ih na nekoliko stotina. Svaki slučaj označite po namjeri, težini i riziku, da vidite kada nova verzija poboljša jednostavna pitanja, a pogorša rizična. Svaka greška pronađena u stvarnoj upotrebi treba postati novi slučaj prije nego što je popravite.

Koristite najjeftiniju provjeru koja pouzdano uhvati grešku. Determinističke provjere su brze, besplatne i ponovljive. Provjere koje ocjenjuje model pokrivaju osobine koje kod ne može procijeniti, ali su sporije, koštaju i i same se moraju provjeriti.

U praksi ih kombinujemo. Provjere u kodu idu prve i brzo padaju. Model u ulozi sudije zatim ocjenjuje ostatak prema kratkoj rubrici (listi kriterija), uz referentni odgovor gdje postoji. Prije nego što povjerujete sudiji, ručno ocijenite pedesetak slučajeva i uporedite. Ako se sudija često ne slaže s vašim stručnjacima, popravite rubriku prije nego što na njoj zasnujete puštanje novih verzija. Naš članak o evaluaciji RAG-a detaljnije opisuje zamke sudija.

Evaluacije se isplate kada se pokreću automatski. Brzi skup testova pokrećemo na svakom pull requestu koji dira prompte, alate, pretragu ili konfiguraciju modela, a puni skup prije svakog izdanja. Minimalan runner izgleda ovako:

import json, statistics, time
from dataclasses import dataclass

@dataclass
class Case:
    id: str
    input: str
    must_include: list[str]
    must_not_include: list[str]

def run_suite(cases: list[Case], answer_fn, threshold: float = 0.92) -> None:
    passed, latencies = 0, []
    for case in cases:
        start = time.perf_counter()
        output = answer_fn(case.input).lower()
        latencies.append(time.perf_counter() - start)
        ok = all(s.lower() in output for s in case.must_include) and not any(
            s.lower() in output for s in case.must_not_include
        )
        passed += ok
        if not ok:
            print(json.dumps({"case": case.id, "output": output[:200]}))
    score = passed / len(cases)
    p95 = statistics.quantiles(latencies, n=20)[18]
    print(f"pass rate {score:.1%}, p95 latency {p95:.2f}s")
    if score < threshold:
        raise SystemExit(1)

Nekoliko pravila čini ovu provjeru pouzdanom:

• Poredite s osnovnom verzijom, uz apsolutni prag, da se pad s 96% na 93% vidi i kada 93% prolazi.
• Označite kritične slučajeve koji uvijek moraju proći, bez obzira na ukupnu ocjenu.
• Nedeterminističke slučajeve pokrenite više puta i uzmite većinski rezultat, da jedan nestabilan izlaz ne blokira novu verziju.
• Sačuvajte svako pokretanje s verzijom prompta, ID-jem modela i hashom commita, da možete pratiti svaku promjenu ocjene.

Verzija koja tačnost podigne za dva poena, a trošak po zahtjevu udvostruči, možda nije dobra verzija. Pri svakom pokretanju, uz ocjene kvaliteta, bilježite ulazne i izlazne tokene, trošak po slučaju i percentile vremena odziva. Promjena modela tada postaje kompromis o kojem razgovarate s brojkama. Novi model može, na primjer, imati bolje ocjene na rizičnim slučajevima, a biti sporiji i skuplji, a izvještaj evaluacija pokazuje za koliko.

Budžete postavite kao dio provjere, na primjer granicu za p95 vrijeme odziva i najveći trošak na 1.000 zahtjeva. Kada dokažete da kvalitet ostaje isti, jednostavne namjere često mogu preći na manji i jeftiniji model.

Evaluacije pokrivaju ono što ste predvidjeli. Stvarna upotreba pokaže sve ostalo. Uz automatske testove redovno vodite i mali ljudski pregled:

• Svake sedmice uzmite fiksan broj razgovora iz stvarne upotrebe, s naglaskom na slučajeve s niskom pouzdanošću, negativnim povratnim informacijama i visokim rizikom.
• Neka ih stručnjaci iz oblasti ocijene po istoj rubrici koju koristi sudija. Tako vidite i koliko se sudija slaže s ljudima.
• Svaku potvrđenu grešku pretvorite u novi slučaj u skupu testova.

Pregled ne oduzima mnogo vremena, a skup testova prati kako ljudi stvarno koriste proizvod.

1. 01Iz logova ili tiketa izvucite 50 stvarnih slučajeva i za svaki zapišite očekivani ishod.
2. 02Dodajte determinističke provjere za format, obavezna polja i zabranjeni sadržaj.
3. 03Dodajte jednu provjeru koju ocjenjuje model, s kratkom rubrikom, i uporedite je s ljudskim ocjenama.
4. 04Pokrećite testove u CI-ju pri promjenama prompta, modela i pretrage, s pragom i kritičnim slučajevima.
5. 05Bilježite trošak i vrijeme odziva pri svakom pokretanju.
6. 06Uvedite sedmični pregled uzorka i greške vraćajte u skup testova.

Evaluacije postavljamo na početku svakog AI projekta, prije nego što podesimo prvi prompt, jer ubrzavaju svaku kasniju odluku. Naš projekat asistenta za odštetne zahtjeve pokazuje kako izgledaju sedmične verzije uz provjeru evaluacijama, a kako radimo objašnjava gdje evaluacije stoje u našem procesu isporuke.