Evalovi: od AI eksperimenata do pouzdane produkcije

• Iako su temeljni modeli napredovali, stvarni pomak koji omogućuje pouzdanu produkcijsku primjenu rezultat je discipliniranih postupaka evaluacije

• Dobro osmišljene evaluacije pomažu voditeljima proizvoda, voditeljima upravljanja umjetnom inteligencijom i tehničkim direktorima da sigurno i masovno uvedu AI agente, pretvarajući umjetnu inteligenciju iz izolirane igračke u konkurentsku prednost.

• Takvo povjerenje proizlazi iz evaluacije ponašanja AI agenata na temelju stvarnih korisničkih upita, rubnih slučajeva i scenarija specifičnih za domenu koji odražavaju vaš stvarni poslovni kontekst, a ne iz javnog referentnog testa koji tvrdi: „ovaj je model najbolji”

• Cilj je opravdati to povjerenje mjerljivim rezultatima. Uspjeh znači konkretno i mjerljivo definirati što je „dobro”, u skladu s poslovnim potrebama i prihvatljivom razinom rizika — bilo da je riječ o činjeničnoj točnosti, primjerenom tonu, brzini ili troškovnoj učinkovitosti.

• Ugradnjom evaluacije u cijeli sustav (instrumentacija, bilježenje, A/B testiranje, zaštitne mjere) te usklađivanjem temeljitosti i učinkovitosti timovi mogu brže i pouzdanije uvoditi rješenja.

Većini poduzeća prihvatljivo je da se njihovi zaposlenici poigravaju alatima ChatGPT ili Gemini. No primjena LLM-ova u procesima ili okruženjima s visokim ulozima pokazala se mnogo rjeđom.

Razlozi su često bili opravdani: kvaliteta je bila neujednačena, a rizik od halucinacija ili neželjenog ponašanja nadmašivao je potencijalne prednosti tehnologije.

Taj se odnos rizika i koristi znatno promijenio tijekom protekle godine. Dio toga može se pripisati poboljšanju izvedbe temeljnih modela, ali velik dio proizlazi iz sve discipliniranijeg pristupa evaluaciji (odnosno „evalovima”). Evalovi nama i našim klijentima daju sigurnost da u samo nekoliko tjedana uvedemo agente velikih razmjera namijenjene klijentima.

Ovaj vodič objašnjava temeljne elemente evalova te kako ih osmisliti, implementirati i primjenjivati u produkcijskim slučajevima upotrebe.

Cilj evaluacije nije pronaći savršen model, nego steći opravdano povjerenje da se vaš model ponaša u skladu s poslovnim potrebama, očekivanjima korisnika i prihvatljivom razinom rizika vaše organizacije.

U temelju svake strategije evaluacije jednostavno je pitanje: Kako izgleda „dobro”? Odgovor treba biti konkretan. Za jednu organizaciju „dobro” može značiti činjeničnu točnost unutar strogih tolerancija, dok druga može dati prednost brzini, troškovnoj učinkovitosti ili prepoznatljivom tonu komunikacije. Svako ograničenje vašeg poslovanja, od dopuštenih podataka do primjenjivih regulatornih obveza, oblikuje tu definiciju.

Ključno je da se „dobro” sastoji od elemenata koje doista možete mjeriti. Ako uspjeh znači pružanje korisnih financijskih smjernica, korisnost treba izraziti svojstvima poput činjenične točnosti, primjerenih odricanja od odgovornosti, personaliziranog rasuđivanja i sigurnih granica. Nakon što se „dobro” definira mjerljivim pojmovima, sljedeće je pitanje kako ćete analizirati i tumačiti rezultate. Postupanje na temelju tih rezultata pretvara evaluaciju u metodu, umjesto da se sve svodi na pojedinačne prosudbe.

Svaki proces evaluacije počiva na trima povezanim stupovima:

1. Ulazni podaci/referentni testovi: reprezentativni primjeri iz stvarnog svijeta za opću izvedbu i pomno odabrani interni skupovi podataka za provjeru primjenjivosti u domeni.

2. Ponašanje modela: način pozivanja modela (generiranje potpomognuto dohvaćanjem, sažimanje, strukturirano dohvaćanje informacija, upotreba alata).

3. Metrike: način mjerenja i tumačenja izvedbe.

Ulazni podaci moraju predstavljati okruženje s kojim će se sustav susretati. Najvrjedniji uvidi proizlaze iz stvarnih primjera: upita vaših klijenata, financijskih scenarija ili slučajeva specifičnih za industriju. Samo testiranjem na takvim primjerima možete utvrditi razumije li model doista nijanse koje su korisnicima potrebne i ispunjava li poslovnu potrebu.

Ponašanje modela — način zadavanja uputa, orkestracije dohvaćanja ili upotrebe alata te pružanja konteksta — jednako je važno kao i sam model. Dva jednaka modela mogu se ponašati vrlo različito ovisno o načinu uvođenja. Stoga i taj sloj morate uključiti u dizajn evaluacije.

Naposljetku, tu su metrike. Brojke same rijetko otkrivaju cijelu priču, ali dobro odabrane metrike omogućuju tumačenje ponašanja sustava. Latencija, točnost, sigurnost, koherentnost, pristranost, trošak i zadovoljstvo korisnika zajedno daju višedimenzionalnu sliku sustava u produkciji. Umijeće je odabrati metrike usklađene s ključnim pokazateljima uspješnosti projekta ili poslovanja koje rasvjetljavaju svojstva najvažnija korisnicima. Jednostavnije metrike često su točnije i jeftinije, dok loš odabir metrika može navesti timove na pogrešan zaključak. Ovako treba razmišljati o odabiru metrika:

Primjeri dobro odabranih metrika:

• Chatbot za korisničku podršku: stopa rješavanja pri prvom kontaktu (je li problem korisnika riješen bez eskalacije?), prosječno vrijeme obrade, ocjena zadovoljstva korisnika, stopa eskalacije ljudskim agentima

• Alat za financijska istraživanja: točnost citiranja (% tvrdnji s pravilno navedenim izvorom), činjenična preciznost potvrđena prema referentnim podacima, relevantnost dohvaćanja (je li pronašao prave dokumente?), koherentnost rasuđivanja koju ocjenjuju stručnjaci za domenu

• Asistent za generiranje koda: sintaktička ispravnost, stopa prolaska testova, broj sigurnosnih ranjivosti, vrijeme do funkcionalnog rješenja

Primjeri loše odabranih metrika:

• Upotreba samo duljine odgovora kao pokazatelja kvalitete (dulje ≠ bolje)

• Mjerenje brzine bez razmatranja kompromisa u pogledu točnosti

• Praćenje ocjena pouzdanosti modela bez provjere njihove stvarne točnosti

• Oslanjanje isključivo na internu perpleksnost modela bez provjere među korisnicima

Uobičajene zamke pri odabiru metrika:

• Proturječne metrike: istodobna optimizacija brzine i sveobuhvatnosti bez priznavanja kompromisa

• Pretjerana prilagodba referentnim testovima: postizanje 95 % na testnom skupu uz neuspjeh u produkciji jer se stvarni korisnici ponašaju drukčije

Za jednog klijenta iz strogo reguliranog sektora financijskih usluga točnost rješenja za dubinsko istraživanje bila je najvažnija. Osmislili smo skupove podataka s pitanjima i odgovorima koje su izradili stručnjaci te ih spojili sa skupovima generiranima alatima. Tako smo mogli procijeniti preciznost, odabir odgovarajućih alata i dohvaćanje pravih informacija te steći uravnotežen uvid u točnost i kvalitetu rasuđivanja. Ključno je bilo mjeriti više dimenzija: činjeničnu točnost (stručna provjera), kvalitetu dohvaćanja (preciznost/odziv relevantnih dokumenata) i koherentnost rasuđivanja (strukturirana evaluacija logičkog slijeda).

Kada upotrijebiti LLM kao ocjenjivača za nijansiranu procjenu kvalitete

LLM kao ocjenjivač koristi drugi AI model za evaluaciju, zamjenjujući ljudski pregled skalabilnim, automatiziranim ocjenjivanjem kvalitete. LLM kao ocjenjivač često se nepotrebno upotrebljava kada jednostavnije metrike mogu pružiti potrebnu točnost. Može biti koristan kada determinističke provjere ne mogu obuhvatiti kvalitetu, primjerice kada je metrika semantička (korisnost, utemeljenost, kvaliteta rasuđivanja, ton, tumačenje pravila) i determinističko ocjenjivanje nije moguće. Možda će vam trebati skalabilne povratne informacije za brojne varijante upita/modela te jasno definirana rubrika i shema strukturiranog izlaza. Da biste ga uspješno primijenili, slijedite ove korake:

• Izričito definirajte dimenzije rubrike: ispravnost, utemeljenost, usklađenost s pravilima, provedivost i ton.

• Za odgovore ocjenjivača upotrebljavajte strukturirane izlaze (JSON shemu).

• Bilježite i binarne prolazne ocjene i dijagnostički tekst za analizu pogrešaka.

• U svakom ciklusu izdavanja kalibrirajte rezultate ocjenjivača prema uzorcima koje su označili ljudi.

• Za domene s visokim ulozima koristite dva ocjenjivača ili povremene provjere konsenzusa.

• Pratite odstupanje ocjenjivača i stopu neslaganja tijekom vremena.

Skup podataka za referentno testiranje fiksan je i pomno odabran skup testnih primjera s poznatim odgovorima koji služi za dosljednu evaluaciju modela i poštenu usporedbu rezultata među verzijama. Obično sadržava ulazne podatke (npr. korisničke upite), očekivane izlaze ili referentne prosudbe te kriterije/oznake za ocjenjivanje. Javni referentni testovi služe za usporedbu izvedbe najsuvremenijih modela i mogu biti koristan početni pokazatelj pri projektiranju sustava i odabiru prikladnog modela.

Međutim, za vlastiti sustav ne možete te testove smatrati zamjenom za mjerenje izvedbe u svojem poslovnom kontekstu jer imaju poznate nedostatke:

• Kontaminacija: modeli su možda obučeni na podacima referentnog testa; evaluacija na istom skupu nalikuje ocjenjivanju uz šalabahter.

• Zasićenost: svi vodeći modeli već postižu gotovo najviše ocjene, pa je poboljšanje ili pogoršanje ograničeno na nekoliko postotnih bodova i često ostaje unutar prirodne varijabilnosti rezultata testa.

• Uzak opseg: podaci referentnih testova ne odražavaju vaše stvarne zadatke jer su strogo odabrani i pročišćeni. Neke čak generiraju LLM-ovi pa ne odražavaju složenost i rubne slučajeve u vašim podacima (tipografske pogreške, neobične izraze, slike sa smetnjama).

Učenik od aplikacije traži pomoć pri rješavanju tekstualnih zadataka.

Primjer javnog referentnog testa koji možete upotrijebiti: GSM8K (matematičko rasuđivanje za osnovnu školu)

• Neobvezni teži skup: MATH.

Zašto je ovaj referentni test koristan:

• Brzo uspoređuje koji je model bolji u općem matematičkom rasuđivanju,

• Dobar je početni filtar prije ulaganja u potpune evalove proizvoda.

Zašto vam ipak treba vlastiti skup podataka:

Vaša aplikacija ima zahtjeve koje GSM8K ne testira:

• Terminologiju i redoslijed tema u vašem kurikulumu,

• Stil objašnjavanja primjeren vašoj dobnoj skupini,

• Postupanje s dvosmislenim učeničkim pitanjima ili pitanjima punima pogrešaka,

• Pravila postupanja (npr. kada dati natuknicu, a kada cijeli odgovor).

Učinkovita provjera ovisi o izradi evaluacijskih referentnih testova prilagođenih vašoj aplikaciji. Ti skupovi podataka trebaju obuhvatiti stvarne interakcije, uobičajene rubne slučajeve i vjerojatne načine pogreške. To može biti zahtjevan zadatak pri implementaciji novog proizvoda ili procesa. Ipak, podatke je u većini slučajeva moguće prikupiti iz postojećeg proizvoda ili što ranije, čak i tijekom početne faze testiranja. Nakon razvoja aplikacije ti se referentni testovi trebaju razvijati usporedno s proizvodom te s vremenom postajati bogatiji i reprezentativniji.

Veza između referentnog testa prilagođenog aplikaciji i odabira modela ključna je. Referentni test ne otkriva samo radi li rješenje, nego i koja kombinacija veličine modela i tehnika naknadnog uvježbavanja pruža potrebnu izvedbu uz najniži trošak. Najveća poboljšanja unaprijed obučenih modela („PT” u nazivu ChatGPT) ne proizlaze iz ponovnog obučavanja, nego iz metoda „naknadnog uvježbavanja”.

Te su metode usmjerene na oblikovanje informacija kojima model može pristupiti, njihove strukture te načina usmjeravanja i orkestracije modela tijekom zaključivanja. Tehnike naknadnog uvježbavanja uključuju:

• Zadavanje upita s lancem razmišljanja i dinamičku dodjelu računalnih resursa (više razmišljanja za teže probleme)

• Samodosljednost, pri kojoj se generira više izlaza i odabire najbolji

• Izgradnju i orkestraciju konteksta, kao što su generiranje potpomognuto dohvaćanjem (RAG), učenje s malim brojem primjera i agentski radni procesi

• Upotrebu alata i pristup vanjskom znanju, što modelu omogućuje djelovanje izvan njegovih internih parametara

• Strategije predstavljanja i pohrane znanja osmišljene za učinkovito dohvaćanje i rasuđivanje nad strukturiranim i nestrukturiranim podacima

Iako te tehnike naknadnog uvježbavanja mogu znatno poboljšati izvedbu sustava, donose i kompromise. Svaki dodatni sloj orkestracije, dohvaćanja ili rasuđivanja povećava složenost sustava, vrijeme zaključivanja i operativne troškove. Međutim, promišljena kombinacija tehnika naknadnog uvježbavanja često omogućuje upotrebu manjih, bržih i jeftinijih modela uz ispunjavanje zahtjeva izvedbe. Umjesto povećavanjem modela, izvedba se postiže boljim dizajnom sustava.

Pronalaženje te ravnoteže ovisi o konkretnoj aplikaciji, a optimalnu kombinaciju tehnika treba odrediti evalovima prilagođenima aplikaciji. Oni omogućuju prepoznavanje točke nakon koje dodatna orkestracija više ne donosi znatna poboljšanja, pa timovi mogu odabrati najmanju složenost naknadnog uvježbavanja potrebnu za ciljanu izvedbu.

AI rješenje treba promatrati kao cjelovit sustav: baze podataka, API-je, korisnička sučelja, orkestracijske slojeve, infrastrukturu za praćenje i drugo. Evaluacija stoga mora obuhvatiti cijeli tehnološki sklop. Trebate pratiti ključne dijelove sustava kako biste zadržali uvid u moguće probleme i odgovorno ubrzali razvoj.

Praćenje ključnih dijelova sustava podrazumijeva:

• Instrumentiranje procesa radi dobivanja mjerljivih rezultata.

• Bilježenje eksperimenata kako biste vidjeli učinak svake izmjene.

• Primjenu jednostavnih A/B usporedbi prije uvođenja većih promjena radi provjere mogućih regresija.

Iterativni razvoj temeljen na podacima skraćuje put od prototipa do produkcije bez slijepih točaka. Bilježenje i praćenje važni su i za razumijevanje stvarne upotrebe aplikacije. Evo primjera za osiguravanje opservabilnosti:

• 1. korak: korisnički zahtjev ulazi s vrijednostima request_id, user_segment i intent.

• 2. korak: praćenje bilježi verziju modela, verziju upita, dohvaćene dokumente i pozive alata.

• 3. korak: LLM ocjenjivač ocjenjuje odgovor (ispravnost, utemeljenost, policy_risk).

• 4. korak: mehanizam pravila procjenjuje pragove.

• 5. korak: ako je prag prekršen, pokreće se upozorenje i preusmjeravanje na pričuvno rješenje/ljudski pregled.

• 6. korak: pogreška se dodaje u red za trijažu, a zatim u popis zadataka za referentni test.

Stvarni korisnici rijetko se ponašaju točno onako kako dizajneri očekuju. Neki će pogrešno razumjeti upute. Drugi će namjerno ispitivati slabe točke. Ti rubni slučajevi nisu anomalije, nego iznimno vrijedni signali. Dobro implementiran proces evaluacije bilježi ih, analizira i uključuje u buduće testove. Brzo iteriranje bez slijepih točaka moguće je samo kada je evaluacija ugrađena u sustav, a ne naknadno dodana nakon razvoja.

Preporučujemo ugradnju zaštitnih mjera i praćenja od prvog dana:

• Redovito pratite metrike i regresije modela pomoću referentnog testa prilagođenog aplikaciji.

• Bilježite i pregledavajte rubne slučajeve ili suparničke ulazne podatke te ih dodajte u skup podataka referentnog testa prilagođenog aplikaciji.

• Pobrinite se da te evaluacijske metrike budu usklađene s vašim ključnim pokazateljima uspješnosti.

• Redovito preispitujte skup podataka i referentni test kako biste bili sigurni da ne zanemarujete nove rizike niti podliježete pristranostima.

• Uvedite automatizirana upozorenja za pogoršanje metrika (npr. ako točnost padne ispod 85 %, pokrenite pregled).

• Zadržite postupak ljudskog pregleda odluka s visokim ulozima (pravni savjeti, medicinske smjernice, financijske transakcije).

Svako pokretanje referentnog testa troši računalne resurse i energiju. Svaki suvišan eksperiment povećava troškove. Odgovorna evaluacija treba uskladiti temeljitost i učinkovitost.

Energiju i troškove možete držati pod nadzorom ovim praktičnim koracima:

• Kad god je moguće, koristite manje modele: početne eksperimente provodite na jeftinijim modelima, a opseg povećajte tek nakon potvrde pristupa.

• Predmemorirajte upite i API pozive.

• Primjenjujte energetski osviješteno raspoređivanje (skupna obrada, spot instance, prilagodljivi prioritet).

• Pratite upotrebu računalnih resursa usporedno s izvedbom.

Jednako tako, pratite nove propise o umjetnoj inteligenciji. Čak i kada ne postoji poseban zakon, i dalje se primjenjuju postojeći okviri i potrebni koraci, primjerice:

Zaštita podataka:

• Pobrinite se da skupovi podataka referentnih testova ne sadržavaju osobne podatke bez odgovarajuće privole

• Uvedite pravila čuvanja podataka za zabilježene upite

• Omogućite mehanizme za podnošenje zahtjeva za brisanje podataka

Ravnopravnost i pristranost:

• Testirajte izvedbu među različitim demografskim skupinama

• Pri izradi referentnog testa uključite raznoliku zastupljenost

Ljudska prava i transparentnost:

• Korisnicima jasno dokumentirajte ograničenja modela

• Pružite objašnjenja odluka s visokim ulozima

• Omogućite ljudski nadzor kritičnih aplikacija

Evaluacija nije jednokratan događaj, nego sustav koji se razvija. U području koje se brzo mijenja vaša prednost ovisi o tome koliko brzo možete testirati, učiti i prilagođavati se kako biste učinkovitije uvodili modele i nova rješenja.

Ugradnjom evaluacije kao temeljne aktivnosti inženjerstva i upravljanja proizvodima timovi mogu inovirati brže i sigurnije. Najprije definirajte što znači „dobro” u kontekstu vaše AI aplikacije, uspostavite platformu za evaluaciju i razvijajte je kako biste dobili referentni test prilagođen aplikaciji koji sa svakom iteracijom potvrđuje spremnost za produkciju.