Evalvacije: od poskusov z UI do zanesljive produkcije

• Čeprav so se temeljni modeli izboljšali, samozavestno produkcijsko uporabo dejansko omogočajo disciplinirani postopki evalvacije.

• Dobro zasnovane evalvacije produktnim vodjem, vodjem upravljanja UI in tehničnim direktorjem pomagajo varno in obsežno uvajati agente UI ter UI iz izolirane igrače spreminjajo v konkurenčno prednost.

• To zaupanje temelji na evalvaciji vedenja agentov UI z dejanskimi poizvedbami uporabnikov, robnimi primeri in domensko specifičnimi scenariji, ki odražajo vaš poslovni kontekst, ne pa na javnem primerjalnem preizkusu, ki trdi: »Ta model je najboljši.«

• Cilj je to zaupanje utemeljiti z merljivimi rezultati. Uspeh pomeni, da »dobro« opredelite konkretno in merljivo ter skladno s poslovnimi potrebami in toleranco do tveganja, naj gre za stvarno točnost, ustrezen ton, hitrost ali stroškovno učinkovitost.

• Z vključitvijo evalvacije v celoten sistem (instrumentacijo, beleženje, testiranje A/B in varovala) ter uravnoteženjem temeljitosti in učinkovitosti lahko ekipe dosežejo hitrejše uvajanje in večjo robustnost.

Večina podjetij nima zadržkov, če se zaposleni poigravajo s ChatGPT ali Gemini. Precej redkeje pa velike jezikovne modele uporabljajo v delovnih tokovih ali okoljih, kjer je veliko na kocki.

Razlogi so bili pogosto upravičeni: kakovost je nihala, tveganje halucinacij ali neželenega vedenja pa je odtehtalo morebitne koristi tehnologije.

Razmerje med tveganjem in koristmi se je v zadnjem letu občutno spremenilo. Deloma je to mogoče pripisati boljši zmogljivosti temeljnih modelov, v veliki meri pa vse bolj discipliniranemu pristopu k evalvaciji (oziroma »evalom«). Evalvacije nam in našim strankam dajejo zaupanje, da lahko v nekaj tednih obsežno uvedemo agente za neposredno delo s strankami.

V tem vodniku bomo pojasnili temelje evalvacij ter njihovo zasnovo, izvedbo in uporabo v produkcijskih primerih.

Cilj evalvacije ni najti popoln model, temveč pridobiti utemeljeno zaupanje, da se model vede skladno z vašimi poslovnimi potrebami, pričakovanji uporabnikov in toleranco organizacije do tveganja.

Vsaka strategija evalvacije temelji na preprostem vprašanju: Kaj pomeni »dobro«? Odgovor mora biti konkreten. Za eno organizacijo lahko »dobro« pomeni stvarno točnost znotraj strogih toleranc, druga pa lahko daje prednost hitrosti, stroškovni učinkovitosti ali značilnemu tonu komunikacije. To opredelitev oblikujejo vse omejitve vašega delovanja, od dovoljenih podatkov do veljavnih regulativnih obveznosti.

Ključno je, da »dobro« sestavljajo dejansko merljive komponente. Če uspeh pomeni zagotavljanje koristnih finančnih smernic, je treba koristnost izraziti z lastnostmi: stvarno pravilnostjo, ustreznimi omejitvami odgovornosti, prilagojenim sklepanjem in varnimi mejami. Ko »dobro« opredelite merljivo, se morate vprašati še, kako boste rezultate analizirali in razlagali. Prav ukrepanje na podlagi teh rezultatov evalvacijo spremeni v metodo, namesto da bi šlo le za subjektivne presoje.

Vsak postopek evalvacije temelji na treh povezanih stebrih:

1. Vhodi/referenčni nabori: reprezentativni primeri iz resničnega sveta za splošno zmogljivost in skrbno pripravljeni interni nabori podatkov za preverjanje uporabnosti na določenem področju.

2. Vedenje modela: kako se model kliče (generiranje z razširjenim pridobivanjem podatkov, povzemanje, strukturirano pridobivanje informacij, uporaba orodij).

3. Metrike: kako merite in razlagate zmogljivost.

Vhodi morajo predstavljati svet, s katerim se bo srečeval vaš sistem. Najdragocenejša spoznanja izhajajo iz resničnih primerov: poizvedb vaših strank, finančnih scenarijev ali panožno specifičnih primerov. Le s takšnim preizkušanjem lahko ugotovite, ali model res razume nianse, ki jih potrebujejo uporabniki, in izpolnjuje poslovne potrebe.

Vedenje modela – denimo način oblikovanja pozivov, usklajevanja pridobivanja podatkov ali uporabe orodij ter podajanja konteksta – je enako pomembno kot sam model. Dva enaka modela se lahko vedeta zelo različno, odvisno od načina uvedbe. Zato morate v zasnovo evalvacije vključiti tudi to raven.

Nazadnje so tu še metrike. Številke same redko povedo celotno zgodbo, vendar dobro izbrane metrike omogočajo razumevanje vedenja sistema. Zakasnitev, točnost, varnost, koherentnost, pristranskost, stroški in zadovoljstvo uporabnikov skupaj ustvarijo večdimenzionalno sliko produkcijskega sistema. Ključno je izbrati metrike, ki so usklajene s ključnimi kazalniki uspešnosti projekta ali podjetja ter osvetlijo lastnosti, najpomembnejše uporabnikom. Preprostejše metrike so pogosto točnejše in cenejše, slaba izbira metrik pa lahko ekipe zavede. Pri izbiri metrik upoštevajte naslednje:

Primeri dobre izbire metrik:

• Klepetalni robot za podporo strankam: delež rešitev ob prvem stiku (ali je bila uporabnikova težava rešena brez predaje naprej?), povprečni čas obravnave, ocena zadovoljstva uporabnikov, delež predaj človeškim agentom

• Orodje za finančne raziskave: točnost navedb virov (delež trditev z ustreznim virom), stvarna natančnost glede na referenčno resnico, ustreznost pridobivanja (ali je našlo prave dokumente?), koherentnost sklepanja po oceni področnih strokovnjakov

• Pomočnik za ustvarjanje kode: skladenjska pravilnost, delež uspešnih testov, število varnostnih ranljivosti, čas do delujoče rešitve

Primeri slabe izbire metrik:

• Uporaba zgolj dolžine odgovora kot približka kakovosti (daljše ≠ boljše)

• Merjenje hitrosti brez upoštevanja kompromisov glede točnosti

• Spremljanje ocen zaupanja modela brez preverjanja njihove dejanske pravilnosti

• Zanašanje zgolj na notranjo perplexity modela brez preverjanja pri uporabnikih

Pogoste pasti pri metrikah, ki se jim velja izogniti:

• Nasprotujoče si metrike: hkratna optimizacija hitrosti in celovitosti brez upoštevanja kompromisa

• Prekomerno prilagajanje referenčnim preizkusom: 95-odstotna uspešnost na testnem naboru, vendar neuspeh v produkciji, ker se resnični uporabniki vedejo drugače

Za eno od naših strank iz strogo reguliranega sektorja finančnih storitev je bila pri rešitvi za poglobljeno raziskovanje najpomembnejša točnost. Zasnovali smo nabore vprašanj in odgovorov, ki so jih pripravili strokovnjaki, ter jih združili z nabori, ustvarjenimi z orodji. Tako smo lahko ocenili natančnost, izbiro pravih orodij in pridobivanje pravih informacij ter dobili uravnotežen pogled na točnost in kakovost sklepanja. Ključno je bilo merjenje več razsežnosti: stvarne točnosti (strokovno preverjanje), kakovosti pridobivanja (natančnost/priklic ustreznih dokumentov) in koherentnosti sklepanja (strukturirana evalvacija logičnega toka).

Kdaj za ocenjevanje niansirane kakovosti uporabiti veliki jezikovni model

Pri ocenjevanju z velikim jezikovnim modelom vlogo ocenjevalca prevzame drugi model UI, zato človeški pregled nadomesti razširljivo, avtomatizirano ocenjevanje kakovosti. Veliki jezikovni model se kot ocenjevalec pogosto uporablja po nepotrebnem, čeprav bi zahtevano točnost zagotovile preprostejše metrike. Uporaben je lahko, kadar deterministična preverjanja ne zajamejo kakovosti, na primer pri semantičnih metrikah (koristnost, utemeljenost, kakovost sklepanja, ton, razlaga pravilnikov), kjer deterministično ocenjevanje ni mogoče. Morda potrebujete razširljive povratne informacije za številne različice pozivov in modelov ter jasno ocenjevalno lestvico in shemo strukturiranih izhodov. Za učinkovito uporabo upoštevajte naslednje korake:

• Izrecno opredelite razsežnosti ocenjevalne lestvice: pravilnost, utemeljenost, skladnost s pravilniki, izvedljivost in ton.

• Za odgovore ocenjevalca uporabite strukturirane izhode (shemo JSON).

• Za analizo napak zajemite tako binarne izločitvene ocene kot diagnostično besedilo.

• V vsakem ciklu izdaje rezultate ocenjevalca umerite glede na vzorce, ki so jih označili ljudje.

• Na področjih, kjer je veliko na kocki, uporabite dva ocenjevalca ali redna preverjanja soglasja.

• Sčasoma spremljajte odmik ocenjevalca in stopnjo nestrinjanja.

Referenčni nabor podatkov je nespremenljiv, skrbno pripravljen nabor testnih primerov z znanimi odgovori, ki omogoča dosledno evalvacijo modelov in pošteno primerjavo rezultatov med različicami. Običajno vključuje vhode (npr. uporabniške poizvedbe), pričakovane izhode ali referenčne presoje ter evalvacijska merila oziroma oznake za ocenjevanje. Javni primerjalni preizkusi se uporabljajo za primerjavo zmogljivosti najsodobnejših modelov in so lahko uporabno začetno vodilo pri izbiri modela za vaš sistem.

Pri lastnem sistemu pa se nanje ne morete zanašati kot na približek zmogljivosti v svojem poslovnem kontekstu, saj imajo znane pomanjkljivosti:

• Kontaminacija: modeli so bili morda učeni na podatkih referenčnega preizkusa; evalvacija na istem naboru je zato podobna ocenjevanju z goljufivim listkom.

• Zasičenost: vsi najboljši modeli že dosegajo najvišje rezultate, zato je izboljšanje ali poslabšanje omejeno na nekaj odstotnih točk in pogosto znotraj naravne spremenljivosti rezultatov preizkusa.

• Ozek obseg: podatki referenčnih preizkusov ne odražajo vaših dejanskih nalog, saj so skrbno izbrani in očiščeni. Nekatere celo ustvarijo veliki jezikovni modeli, zato ne odražajo zapletenosti in robnih primerov v vaših podatkih (tipkarskih napak, nenavadnih besednih zvez, slik s šumom).

Učenec aplikacijo prosi za pomoč pri reševanju besedilnih nalog.

Primer uporabnega javnega referenčnega preizkusa: GSM8K (matematično sklepanje na osnovnošolski ravni)

• Izbirni zahtevnejši nabor: MATH.

Zakaj je ta referenčni preizkus uporaben:

• Omogoča hitro primerjavo modelov pri splošnem matematičnem sklepanju.

• Je dober prvi filter pred vlaganjem v celovite evalvacije izdelka.

Zakaj še vedno potrebujete lasten nabor podatkov:

Vaša aplikacija ima zahteve, ki jih GSM8K ne preverja:

• Besedišče vašega učnega načrta in zaporedje tem.

• Slog razlage, prilagojen vaši starostni skupini.

• Obravnava dvoumnih vprašanj učencev ali vprašanj s številnimi tipkarskimi napakami.

• Pravila pravilnika (npr. kdaj ponuditi namig in kdaj celoten odgovor).

Učinkovito preverjanje temelji na oblikovanju evalvacijskih referenčnih naborov za vašo aplikacijo. Ti nabori podatkov morajo izhajati iz resničnih interakcij, značilnih robnih primerov in verjetnih načinov odpovedi. Pri uvajanju novega izdelka ali postopka je to lahko zahtevna naloga. Vendar je podatke večinoma mogoče zbrati iz obstoječega izdelka ali čim prej, tudi že med začetno fazo preizkušanja. Po razvoju aplikacije se morajo ti referenčni nabori razvijati skupaj z izdelkom ter sčasoma postajati bogatejši in bolj reprezentativni.

Povezava med referenčnim naborom za vašo aplikacijo in izbiro modela je ključna. Referenčni nabor ne pokaže le, ali rešitev deluje, temveč tudi, katera kombinacija velikosti modela in tehnik naknadnega učenja najstroškovneje zagotovi zahtevano zmogljivost. Največje izboljšave predhodno učenih modelov (»PT« v ChatGPT) ne izhajajo iz ponovnega učenja, temveč iz metod »naknadnega učenja«.

Te metode določajo, do katerih informacij lahko model dostopa, kako so te strukturirane ter kako se model med sklepanjem usmerja in orkestrira. Tehnike naknadnega učenja vključujejo:

• Pozivanje z verigo sklepanja in dinamično dodeljevanje računskih virov (več razmišljanja za težje probleme).

• Samokonsistentnost, pri kateri se ustvari več izhodov in izbere najboljši.

• Oblikovanje in orkestracijo konteksta, kot so generiranje z razširjenim pridobivanjem podatkov (RAG), primeri za učenje iz malo primerov in agentski delovni tokovi.

• Uporabo orodij in dostop do zunanjega znanja, kar modelu omogoča delovanje zunaj njegovih notranjih parametrov.

• Strategije predstavitve in shranjevanja znanja za učinkovito pridobivanje ter sklepanje na podlagi strukturiranih in nestrukturiranih podatkov.

Te tehnike naknadnega učenja lahko bistveno izboljšajo zmogljivost sistema, vendar prinašajo tudi kompromise. Vsaka dodatna plast orkestracije, pridobivanja ali sklepanja poveča zapletenost sistema, čas sklepanja in operativne stroške. Ob premišljeni uporabi pa prava kombinacija tehnik naknadnega učenja pogosto omogoči uporabo manjših, hitrejših in cenejših modelov, ki še vedno izpolnjujejo zahteve glede zmogljivosti. Namesto s povečevanjem modela dosežemo zmogljivost z boljšo zasnovo sistema.

Iskanje tega ravnovesja je odvisno od posamezne aplikacije, zato je treba optimalno kombinacijo tehnik določiti z evalvacijami za svojo aplikacijo. Z njimi lahko ugotovite, kdaj dodatna orkestracija ne prinaša več pomembnih izboljšav, in izberete najmanjšo zahtevano raven zapletenosti naknadnega učenja za doseganje ciljne zmogljivosti.

Rešitev UI je treba obravnavati kot celoten sistem: podatkovne zbirke, vmesnike API, uporabniške vmesnike, orkestracijske plasti, infrastrukturo za spremljanje in drugo. Evalvacija mora zato zajeti celoten tehnološki sklad. Spremljajte ključne dele sistema, da ohranite pregled nad morebitnimi težavami in odgovorno pospešite razvoj.

Spremljanje ključnih delov sistema pomeni:

• Instrumentiranje postopkov za pridobivanje merljivih rezultatov.

• Beleženje poskusov, da lahko vidite učinek vsake spremembe.

• Uporabo preprostih primerjav A/B pred uvedbo večjih sprememb za preverjanje morebitnega nazadovanja.

Izpopolnjevanje na podlagi podatkov skrajša pot od prototipa do produkcije in odpravi slepe pege. Beleženje in spremljanje sta pomembna tudi za razumevanje dejanske uporabe aplikacije. Primer zagotavljanja opazljivosti:

• 1. korak: uporabniška zahteva vstopi s podatki request_id, user_segment in intent.

• 2. korak: sled zabeleži različico modela, različico poziva, pridobljene dokumente in klice orodij.

• 3. korak: veliki jezikovni model kot ocenjevalec oceni odgovor (correctness, groundedness, policy_risk).

• 4. korak: mehanizem pravil ovrednoti pragove.

• 5. korak: če je prag kršen, sproži opozorilo in preusmeri zahtevo na nadomestno rešitev ali človeški pregled.

• 6. korak: napaka se doda v čakalno vrsto za triažo in nato med čakajoče primere referenčnega nabora.

Resnični uporabniki se redko vedejo povsem tako, kot pričakujejo snovalci. Nekateri bodo navodila razumeli napačno. Drugi bodo namerno preizkušali šibke točke. Ti robni primeri niso anomalije, temveč neprecenljivi signali. Dobro izveden postopek evalvacije jih zajame, analizira in vključi v prihodnje preizkuse. Hitro izpopolnjevanje brez slepih peg je mogoče le, če je evalvacija vgrajena v sistem in ni dodana šele po razvoju.

Priporočamo, da varovala in spremljanje vključite že od prvega dne:

• Z referenčnim naborom za svojo aplikacijo redno spremljajte metrike modela in nazadovanja.

• Zajemajte in pregledujte robne primere ali sovražne vhode ter jih dodajajte v referenčni nabor podatkov za svojo aplikacijo.

• Poskrbite, da so te evalvacijske metrike usklajene z vašimi ključnimi kazalniki uspešnosti.

• Redno preverjajte svoj nabor podatkov in referenčni preizkus, da ne spregledate novih tveganj ali pristranskosti.

• Uvedite samodejna opozorila za poslabšanje metrik (če na primer točnost pade pod 85 %, sprožite pregled).

• Za odločitve z velikimi posledicami ohranite postopek človeškega pregleda (pravni nasveti, zdravstvene smernice, finančne transakcije).

Vsak zagon referenčnega preizkusa porabi računske vire in energijo. Vsak odvečen poskus poveča stroške. Odgovorna evalvacija mora uravnotežiti temeljitost in učinkovitost.

Da poraba energije in stroški ne uidejo izpod nadzora, lahko izvedete nekaj praktičnih ukrepov:

• Kadar je mogoče, uporabljajte manjše modele: začetne poskuse izvajajte na cenejših modelih, zmogljivost pa povečajte šele po potrditvi pristopa.

• Predpomnite pozive in klice API.

• Uporabite energijsko ozaveščeno razporejanje (paketno obdelavo, primerke spot, prilagodljivo prednostno obravnavo).

• Poleg zmogljivosti spremljajte tudi porabo računskih virov.

Prav tako pozorno spremljajte nastajajočo zakonodajo o UI. Tudi kjer posebnega zakona ni, še vedno veljajo obstoječi okviri in potrebni ukrepi, kot so:

Varstvo podatkov:

• Poskrbite, da referenčni nabori podatkov brez ustreznega soglasja ne vsebujejo osebno določljivih podatkov.

• Uvedite pravilnike hrambe podatkov za zabeležene poizvedbe.

• Zagotovite mehanizme za zahteve za izbris podatkov.

Enakost in pristranskost:

• Preizkusite zmogljivost pri različnih demografskih skupinah.

• Pri ustvarjanju referenčnega nabora zagotovite raznoliko zastopanost.

Človekove pravice in preglednost:

• Uporabnikom jasno dokumentirajte omejitve modela.

• Zagotovite pojasnila za odločitve z velikimi posledicami.

• Pri kritičnih aplikacijah omogočite človeški nadzor.

Evalvacija ni enkraten dogodek, temveč sistem, ki se razvija. Na hitro razvijajočem se področju je vaša prednost v tem, kako hitro lahko preizkušate, se učite in prilagajate ter tako učinkoviteje uvajate modele in nove rešitve.

Če evalvacijo vključijo kot osrednjo dejavnost inženirstva in produktnega vodenja, lahko ekipe inovirajo hitreje in varneje. Najprej opredelite, kaj pomeni »dobro« v kontekstu vaše aplikacije UI, vzpostavite platformo za evalvacijo in jo razvijajte. Tako boste dobili referenčni nabor za svojo aplikacijo, ki bo ob vsaki ponovitvi vlival zaupanje v pripravljenost na produkcijo.