Evalovi: od AI eksperimenata do pouzdane produkcije

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

• Dobro osmišljene evaluacije pomažu produkt-menadžerima, rukovodiocima zaduženim za upravljanje AI-jem i tehničkim direktorima da sigurno i u velikom obimu uvedu AI agente, pretvarajući AI iz izolirane igračke u konkurentsku prednost.

• To pouzdanje proizlazi iz evaluacije ponašanja AI agenta na osnovu 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 model je najbolji“

• Cilj je opravdati to pouzdanje mjerljivim rezultatima. Uspjeh znači konkretno i mjerljivo definirati šta je "dobro", u skladu s vašim poslovnim potrebama i tolerancijom na rizik — bilo da je riječ o činjeničnoj tačnosti, primjerenom tonu, brzini ili troškovnoj efikasnosti.

• Ugrađivanjem evaluacije u cijeli sistem (instrumentacija, evidentiranje, A/B testiranje i zaštitne mjere) te usklađivanjem temeljitosti i efikasnosti timovi će brže uvoditi rješenja i postići veću robusnost.

Većini kompanija prihvatljivo je da se njihovi zaposlenici poigravaju s alatima ChatGPT ili Gemini. Međutim, primjena LLM-ova u procesima ili okruženjima s visokim ulozima mnogo je rjeđa.

Razlozi za to često su bili opravdani: kvalitet je bio neujednačen, a rizik od halucinacija ili neželjenog ponašanja nadmašivao je potencijalne prednosti tehnologije.

Odnos rizika i koristi značajno se promijenio tokom prošle godine. Iako se dio toga može pripisati boljim performansama temeljnih modela, mnogo toga proizlazi iz sve discipliniranijeg pristupa evaluaciji (ili „evalovima“). Evalovi nama i našim klijentima pružaju pouzdanje da za nekoliko sedmica možemo uvesti agente velikog obima koji izravno rade s klijentima.

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

Cilj evaluacije nije pronaći savršen model, nego steći opravdano pouzdanje da se vaš model ponaša u skladu s poslovnim potrebama, očekivanjima korisnika i tolerancijom vaše organizacije na rizik.

U osnovi svake strategije evaluacije jednostavno je pitanje: Kako izgleda ono što je „dobro“? Odgovor treba biti konkretan. Za jednu organizaciju „dobro“ može značiti činjeničnu tačnost unutar strogih granica, dok druga može dati prednost brzini, troškovnoj efikasnosti ili prepoznatljivom tonu komunikacije. Svako ograničenje u kojem poslujete, od podataka koje smijete koristiti do regulatornih obaveza koje se primjenjuju, oblikuje ovu definiciju.

Najvažnije je da se 'dobro' sastoji od elemenata koje zaista možete mjeriti. Ako uspjeh znači pružanje korisnih finansijskih smjernica, korisnost treba izraziti kroz osobine kao što su činjenična tačnost, odgovarajuća odricanja od odgovornosti, personalizirano rezonovanje i sigurne granice. Nakon što se „dobro“ definira mjerljivim pojmovima, sljedeće pitanje je kako ćete analizirati i tumačiti rezultate. Postupanje na osnovu tih rezultata pretvara evaluaciju u metodu, umjesto da se sve svodi na subjektivne procjene.

Svaki proces evaluacije počiva na tri međusobno povezana stuba:

1. Ulazni podaci/referentni testovi: reprezentativni primjeri iz stvarnog svijeta za opće performanse i pažljivo odabrani interni skupovi podataka za provjeru primjenjivosti u domeni.

2. Ponašanje modela: način pozivanja modela (generiranje prošireno dohvaćanjem, sažimanje, strukturirano pronalaženje informacija i korištenje alata).

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

Ulazni podaci moraju predstavljati svijet s kojim će se vaš sistem susretati. Najkorisniji uvidi dolaze iz stvarnih primjera: upita vaših klijenata, finansijskih scenarija ili slučajeva specifičnih za industriju. Samo testiranjem na tim primjerima možete utvrditi razumije li model zaista nijanse koje korisnici zahtijevaju i ispunjava li poslovne potrebe.

Ponašanje modela — način postavljanja upita, orkestriranja dohvaćanja i korištenja alata te prosljeđivanja konteksta — jednako je važno kao i sam model. Dva identična modela mogu se ponašati sasvim različito, zavisno od načina njihove primjene. Zato ovaj sloj mora biti obuhvaćen dizajnom evaluacije.

Na kraju dolaze metrike. Sami brojevi rijetko daju cijelu sliku, ali dobro odabrane metrike omogućavaju tumačenje ponašanja sistema. Latencija, tačnost, sigurnost, koherentnost, pristranost, trošak i zadovoljstvo korisnika zajedno daju višedimenzionalnu sliku produkcijskog sistema. Umijeće je odabrati metrike usklađene s KPI-jevima projekta ili kompanije koje osvjetljavaju osobine najvažnije vašim korisnicima. Jednostavnije metrike često su preciznije i jeftinije, dok loš izbor metrika može navesti timove na pogrešne zaključke. Ovako treba razmišljati o izboru metrika:

Primjeri dobrog izbora 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 i stopa eskalacije ljudskim agentima

• Alat za finansijsko istraživanje: tačnost citata (% tvrdnji s odgovarajućim izvorom), činjenična preciznost potvrđena prema referentnim podacima, relevantnost dohvaćanja (je li pronašao prave dokumente?) i koherentnost rezonovanja koju ocjenjuju stručnjaci za domenu

• Asistent za generiranje koda: ispravnost sintakse, stopa uspješnog prolaska testova, broj sigurnosnih ranjivosti i vrijeme potrebno do funkcionalnog rješenja

Primjeri lošeg izbora metrika:

• Korištenje samo dužine odgovora kao pokazatelja kvaliteta (duže ≠ bolje)

• Mjerenje brzine bez razmatranja kompromisa u pogledu tačnosti

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

• Oslanjanje isključivo na internu mjeru perplexity modela, bez validacije usmjerene na korisnike

Uobičajene zamke pri izboru metrika:

• Suprotstavljene metrike: istovremena optimizacija brzine i sveobuhvatnosti bez uvažavanja kompromisa

• Pretjerano prilagođavanje referentnim testovima: postizanje 95% na testnom skupu, ali neuspjeh u produkciji jer se stvarni korisnici ponašaju drugačije

Za jednog klijenta iz strogo reguliranog sektora finansijskih usluga, tačnost rješenja za duboko istraživanje bila je najvažnija. Osmislili smo skupove podataka s pitanjima i odgovorima koje su izradili stručnjaci te ih spojili sa skupovima generiranim alatima. Tako smo mogli procijeniti preciznost, sposobnost sistema da izabere odgovarajuće alate i pronađe prave informacije, što nam je dalo uravnoteženu sliku tačnosti i kvaliteta rezonovanja. Ključno je bilo mjeriti više dimenzija: činjeničnu tačnost (stručna validacija), kvalitet dohvaćanja (preciznost/odziv relevantnih dokumenata) i koherentnost rezonovanja (strukturirana evaluacija logičkog toka).

Kada koristiti LLM kao ocjenjivača za nijansiranu procjenu kvaliteta

Pristup LLM-a kao ocjenjivača koristi drugi AI model za evaluaciju, zamjenjujući ljudski pregled skalabilnim, automatiziranim ocjenjivanjem kvaliteta. LLM kao ocjenjivač često se zloupotrebljava kada jednostavnije metrike mogu pružiti potrebnu tačnost. Može biti koristan kada determinističke provjere ne mogu obuhvatiti kvalitet, primjerice kada je metrika semantička (korisnost, utemeljenost, kvalitet rezonovanja, ton ili tumačenje pravila), a determinističko ocjenjivanje nije moguće. Možda će vam trebati skalabilne povratne informacije za brojne varijante upita i modela te jasno definirana rubrika i šema strukturiranog izlaza. Da bi vam ovaj pristup koristio, slijedite ove korake:

• Izričito definirajte dimenzije rubrike: tačnost, utemeljenost, usklađenost s pravilima, primjenjivost i ton.

• Za odgovore ocjenjivača koristite strukturirane izlaze (JSON šemu).

• Bilježite i binarne prolazne ocjene i dijagnostički tekst za analizu neuspjeha.

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

• Za domene s visokim ulozima koristite dva ocjenjivača ili periodične provjere saglasnosti.

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

Skup podataka za referentni test fiksan je, pažljivo odabran skup testnih primjera s poznatim odgovorima koji se koristi za dosljednu evaluaciju modela i pravedno poređenje rezultata različitih verzija. Obično obuhvata ulazne podatke (npr. korisničke upite), očekivane izlaze ili referentne procjene te kriterije/oznake za ocjenjivanje. Javni referentni testovi koriste se za poređenje performansi najnaprednijih modela i mogu poslužiti kao početna smjernica pri projektiranju sistema i izboru odgovarajućeg modela.

Ipak, za vlastiti sistem ne možete se oslanjati na te testove kao pokazatelj performansi u svom poslovnom kontekstu jer imaju poznate nedostatke:

• Kontaminacija: Modeli su možda obučeni na podacima referentnog testa; evaluacija na istom skupu podataka može biti poput ocjenjivanja uz šalabahter.

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

• Uzak obuhvat: Podaci referentnog testa ne odražavaju vaše stvarne zadatke jer su vrlo pažljivo odabrani i očišćeni. Neke čak generira LLM pa ne odražavaju složenost i rubne slučajeve u vašim podacima (tipografske greške, neuobičajene izraze i slike sa smetnjama).

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

Primjer javnog referentnog testa koji možete koristiti: GSM8K (matematičko rezonovanje za osnovnu školu)

• Opcionalni teži skup: MATH.

Zašto je ovaj referentni test koristan:

• Brzo poređenje modela prema sposobnosti općeg matematičkog rezonovanja,

• Dobar prvi filter prije ulaganja u potpunu evaluaciju proizvoda.

Zašto vam ipak treba vlastiti skup podataka:

Vaša aplikacija ima zahtjeve koje GSM8K ne testira:

• Formulacije i redoslijed tema u vašem nastavnom planu,

• Stil objašnjenja prilagođen vašoj dobnoj grupi,

• Postupanje s nejasnim učeničkim pitanjima ili pitanjima punim grešaka,

• Pravila (npr. kada dati naznake, a kada potpune odgovore).

Učinkovita validacija zavisi od izrade evaluacijskih referentnih testova prilagođenih vašoj aplikaciji. Ti skupovi podataka trebaju se zasnivati na stvarnim interakcijama, tipičnim rubnim slučajevima i vjerovatnim načinima neuspjeha. To može biti zahtjevan zadatak pri uvođenju novog proizvoda ili procesa. Ipak, podatke je najčešće moguće prikupiti iz postojećeg proizvoda ili što ranije, čak i tokom početne faze testiranja. Nakon razvoja aplikacije ti referentni testovi trebaju se razvijati zajedno s proizvodom te s vremenom postajati bogatiji i reprezentativniji.

Veza između referentnog testa prilagođenog aplikaciji i izbora modela od presudne je važnosti. Referentni test ne otkriva samo radi li rješenje nego i koja kombinacija veličine modela i tehnika naknadne obuke pruža potrebne performanse uz najniže troškove. Najveća poboljšanja unaprijed obučenih modela („PT“ u nazivu ChatGPT) ne dolaze iz ponovne obuke, nego iz metoda "naknadne obuke".

Te metode oblikuju informacije kojima model može pristupiti, način njihove strukturiranosti te način usmjeravanja i orkestriranja modela tokom izvođenja. Tehnike naknadne obuke uključuju:

• Postavljanje upita za lanac razmišljanja i dinamičku dodjelu računarskih resursa (više razmišljanja za teže probleme)

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

• Izgradnju i orkestraciju konteksta, kao što su generiranje prošireno dohvaćanjem (RAG), primjeri učenja s malim brojem primjera i agentski tokovi rada

• Korištenje alata i pristup vanjskom znanju, što modelu omogućava djelovanje izvan njegovih internih parametara

• Strategije predstavljanja i pohrane znanja, osmišljene za efikasno dohvaćanje i rezonovanje nad strukturiranim i nestrukturiranim podacima

Iako ove tehnike naknadne obuke mogu znatno poboljšati performanse sistema, one uvode i određene kompromise. Svaki dodatni sloj orkestracije, dohvaćanja ili rezonovanja povećava složenost sistema, vrijeme izvođenja i operativne troškove. Međutim, uz promišljenu primjenu odgovarajuća kombinacija tehnika naknadne obuke često omogućava korištenje manjih, bržih i jeftinijih modela koji i dalje ispunjavaju zahtjeve performansi. Umjesto povećanjem modela, performanse se postižu boljim dizajnom sistema.

Pronalaženje te ravnoteže uvijek zavisi od konkretne aplikacije i treba se oslanjati na evalove prilagođene aplikaciji kako bi se odredila optimalna kombinacija tehnika. Oni vam omogućavaju da utvrdite tačku nakon koje dodatna orkestracija više ne donosi značajna poboljšanja, pa timovi mogu odabrati najmanju složenost naknadne obuke potrebnu za ciljne performanse.

AI rješenje treba posmatrati kao cjelovit sistem: baze podataka, API-je, korisnička sučelja, slojeve orkestracije, infrastrukturu za nadzor i drugo. Evaluacija zato mora obuhvatiti cijeli tehnološki stog. Trebate nadzirati ključne dijelove sistema kako biste zadržali uvid u moguće probleme i odgovorno ubrzali razvoj.

Nadziranje ključnih dijelova sistema podrazumijeva:

• Uvođenje instrumentacije u procese radi mjerenja rezultata.

• Evidentiranje eksperimenata kako biste vidjeli učinak svake izmjene.

• Korištenje jednostavnih A/B poređenja prije uvođenja velikih promjena radi testiranja mogućih regresija.

Iterativni razvoj zasnovan na podacima skraćuje put od prototipa do produkcije, bez slijepih tačaka. Evidentiranje i nadzor važni su i za razumijevanje načina korištenja aplikacije u stvarnom svijetu. Evo primjera kako osigurati opservabilnost:

• Korak 1: Korisnički zahtjev ulazi s request_id, user_segment i intent.

• Korak 2: Zapis praćenja bilježi verziju modela, verziju upita, dohvaćene dokumente i pozive alata.

• Korak 3: LLM ocjenjivač ocjenjuje odgovor (tačnost, utemeljenost, policy_risk).

• Korak 4: Mehanizam pravila procjenjuje pragove.

• Korak 5: Ako je prag prekoračen, aktivira se upozorenje + preusmjeravanje na rezervno rješenje/ljudski pregled.

• Korak 6: Neuspjeh se dodaje u red za trijažu, a zatim u listu zadataka za referentni test.

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

Preporučujemo da zaštitne mjere i nadzor ugrađujete od prvog dana:

• Redovno pratite metrike modela i regresije pomoću referentnog testa prilagođenog vašoj aplikaciji.

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

• Osigurajte usklađenost ovih evaluacijskih metrika s ključnim KPI-jevima.

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

• Uvedite automatska upozorenja na pogoršanje metrika (npr. ako tačnost padne ispod 85%, pokrenite pregled).

• Održavajte postupak ljudskog pregleda odluka s visokim ulozima (pravni savjeti, medicinske smjernice i finansijske transakcije).

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

Određeni praktični koraci mogu spriječiti nekontroliran rast potrošnje energije i troškova:

• Kad god je moguće, koristite manje modele: početne eksperimente pokrećite na jeftinijim modelima, a kapacitete povećavajte tek nakon potvrde pristupa.

• Keširajte upite i API pozive.

• Primjenjujte energetski osviješteno raspoređivanje (grupna obrada, spot instance i fleksibilni prioritet).

• Pratite korištenje računarskih resursa zajedno s performansama.

Jednako tako, pratite nove propise o AI-ju. Čak i kada ne postoji poseban zakon, postojeći okviri i potrebni koraci i dalje se primjenjuju, uključujući:

Zaštita podataka:

• Osigurajte da skupovi podataka referentnih testova ne sadrže lične podatke bez odgovarajućeg pristanka

• Uvedite pravila čuvanja podataka za evidentirane upite

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

Jednakost i pristranost:

• Testirajte performanse u različitim demografskim grupama

• Pri izradi referentnog testa uključite raznoliku zastupljenost

Ljudska prava i transparentnost:

• Korisnicima jasno dokumentirajte ograničenja modela

• Pružite objašnjenja za odluke s visokim ulozima

• Omogućite ljudski nadzor kritičnih aplikacija

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

Ugrađivanjem evaluacije kao ključne aktivnosti inženjeringa i upravljanja proizvodima timovi mogu inovirati brže i sigurnije. Najprije definirajte šta 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 pri svakoj iteraciji potvrđuje spremnost za produkciju.