Nors baziniai modeliai patobulėjo, užtikrintai juos naudoti produkcinėje aplinkoje visų pirma leidžia sisteminga vertinimo praktika
Tinkamai parengti vertinimai padeda produktų vadovams, DI valdysenos vadovams ir technologijų direktoriams saugiai bei plačiu mastu diegti DI agentus, kad DI iš atskiro žaisliuko virstų konkurenciniu pranašumu.
Tokį užtikrintumą suteikia DI agento elgsenos vertinimas pagal tikras naudotojų užklausas, ribinius atvejus ir konkrečios srities scenarijus, atspindinčius jūsų verslo aplinkybes, o ne viešas etaloninis testas, skelbiantis, kad „šis modelis geriausias“
Tikslas – pagrįsti šį užtikrintumą išmatuojamais rezultatais. Sėkmė – tai konkretus ir išmatuojamas "gero rezultato" apibrėžimas, suderintas su jūsų verslo poreikiais ir rizikos tolerancija, nesvarbu, ar svarbiausia faktinis tikslumas, tinkamas tonas, sparta ar sąnaudų efektyvumas.
Integruodamos vertinimą visoje sistemoje (stebimumo priemones, žurnalų rašymą, A/B testavimą ir apsaugos priemones) bei derindamos kruopštumą su efektyvumu, komandos gali sparčiau ir patikimiau diegti sprendimus.
Dauguma įmonių neprieštarauja, kad jų darbuotojai eksperimentuotų su ChatGPT ar Gemini. Tačiau LLM kur kas rečiau naudojami itin svarbiose darbo eigose ar aplinkose.
Dažnai tam būta pagrįstų priežasčių: kokybė buvo nepastovi, o haliucinacijų ar nepageidaujamos elgsenos rizika nusvėrė galimą technologijos naudą.
Per pastaruosius metus ši rizikos ir naudos pusiausvyra gerokai pasikeitė. Dalį pokyčio lėmė geresnis bazinių modelių našumas, tačiau daug prisidėjo ir vis sistemingesnis vertinimas (arba „vertinimai“). Vertinimai suteikia mums ir klientams užtikrintumo vos per kelias savaites plačiu mastu įdiegti klientams skirtus agentus.
Šiame vadove aptariami vertinimo pagrindai ir tai, kaip vertinimus projektuoti, įgyvendinti bei vykdyti produkcinėje aplinkoje.
Vertinimo tikslas – ne rasti tobulą modelį, o pagrįstai įsitikinti, kad modelio elgsena atitinka jūsų verslo poreikius, naudotojų lūkesčius ir organizacijos rizikos toleranciją.
Kiekvienos vertinimo strategijos pagrindas – paprastas klausimas: Kaip atrodo „geras“ rezultatas? Atsakymas turėtų būti konkretus. Vienai organizacijai „geras“ rezultatas gali reikšti griežtas tolerancijos ribas atitinkantį faktinį tikslumą, o kitai svarbiau gali būti sparta, sąnaudų efektyvumas ar savitas komunikacijos tonas. Šį apibrėžimą formuoja visi jūsų veiklos apribojimai – nuo leidžiamų naudoti duomenų iki taikomų teisinių prievolių.
Svarbiausia, kad 'gerą' rezultatą sudarytų iš tiesų išmatuojami elementai. Jei sėkmė reiškia naudingas finansines rekomendacijas, naudingumą reikia išreikšti konkrečiomis savybėmis: faktiniu teisingumu, tinkamais atsakomybės ribojimo pareiškimais, individualizuotu protavimu ir saugiomis ribomis. Apibrėžus „gerą“ rezultatą išmatuojamais kriterijais, kitas klausimas – kaip analizuosite ir aiškinsite rezultatus. Būtent veiksmai pagal šiuos rezultatus paverčia vertinimą metodu, o ne vien subjektyviais sprendimais.
Kiekvieną vertinimo procesą sudaro trys tarpusavyje susiję elementai:
Įvestys ir etaloniniai testai: reprezentatyvūs realaus pasaulio pavyzdžiai bendram našumui vertinti ir kruopščiai atrinkti vidiniai duomenų rinkiniai tinkamumui konkrečioje srityje tikrinti.
Modelio elgsena: kaip iškviečiamas modelis (generavimas, papildytas informacijos paieška, apibendrinimas, susistemintos informacijos paieška, įrankių naudojimas).
Metrikos: kaip matuojate ir aiškinate našumą.
Įvestys turi atspindėti aplinką, su kuria susidurs jūsų sistema. Vertingiausių įžvalgų suteikia tikri pavyzdžiai: klientų užklausos, finansiniai scenarijai ar konkrečios pramonės šakos atvejai. Tik testuodami pagal juos galite suprasti, ar modelis iš tiesų suvokia naudotojams svarbius niuansus ir atitinka verslo poreikius.
Modelio elgsena – kaip jam teikiamos užklausos, koordinuojama informacijos paieška ar įrankių naudojimas ir perduodamas kontekstas – yra ne mažiau svarbi nei pats modelis. Du vienodi modeliai gali veikti visiškai skirtingai – tai priklauso nuo jų įdiegimo būdo. Todėl šį lygmenį būtina įtraukti į vertinimo projektą.
Galiausiai – metrikos. Vien skaičiai retai atskleidžia visą vaizdą, tačiau tinkamai parinktos metrikos padeda suprasti sistemos elgseną. Delsa, tikslumas, sauga, nuoseklumas, šališkumas, sąnaudos ir naudotojų pasitenkinimas kartu sudaro daugiamatį produkcinėje aplinkoje veikiančios sistemos vaizdą. Svarbiausia pasirinkti metrikas, kurios atitiktų projekto ar verslo KPI ir atskleistų naudotojams svarbiausias savybes. Paprastesnės metrikos dažnai būna tikslesnės ir pigesnės, o netinkamai pasirinktos gali suklaidinti komandas. Rinkdamiesi metrikas vadovaukitės šiais principais:
Tinkamai pasirinktų metrikų pavyzdžiai:
Klientų aptarnavimo pokalbių robotas: problemų išsprendimo per pirmą kontaktą rodiklis (ar naudotojo problema išspręsta neperduodant jos aukštesniam lygiui?), vidutinė aptarnavimo trukmė, naudotojų pasitenkinimo balas, perdavimo darbuotojams rodiklis
Finansinių tyrimų įrankis: citatų tikslumas (tinkamai šaltiniais pagrįstų teiginių procentas), pagal patikimus duomenis patikrintas faktinis tikslumas, paieškos rezultatų aktualumas (ar rasti tinkami dokumentai?), srities ekspertų įvertintas protavimo nuoseklumas
Kodo generavimo asistentas: sintaksės teisingumas, sėkmingai išlaikytų testų dalis, saugumo spragų skaičius, laikas iki veikiančio sprendimo
Netinkamai pasirinktų metrikų pavyzdžiai:
Kokybė vertinama tik pagal atsakymo ilgį (ilgesnis ≠ geresnis)
Sparta matuojama neatsižvelgiant į tikslumo kompromisus
Modelio pasitikėjimo balai stebimi netikrinant jų pagal faktinį teisingumą
Pasikliaujama vien vidine modelio perplexity metrika, neatliekant naudotojams matomų rezultatų patikros
Dažnos metrikų parinkimo klaidos, kurių reikėtų vengti:
Prieštaraujančios metrikos: vienu metu optimizuojama sparta ir išsamumas, nepripažįstant jų kompromiso
Per didelis pritaikymas etaloniniams testams: testų rinkinyje pasiekiamas 95 % rezultatas, tačiau produkcinėje aplinkoje sistema neveikia, nes tikri naudotojai elgiasi kitaip
Vienam griežtai reguliuojamam finansinių paslaugų klientui svarbiausias buvo jų giliojo tyrimo sprendimo tikslumas. Sukūrėme ekspertų parengtus klausimų ir atsakymų duomenų rinkinius bei įrankiais sugeneruotus rinkinius. Jie leido įvertinti tikslumą, sistemos gebėjimą pasirinkti tinkamus įrankius ir rasti reikiamą informaciją, todėl susidarė subalansuotas tikslumo ir protavimo kokybės vaizdas. Svarbiausia buvo vertinti kelis aspektus: faktinį tikslumą (ekspertų patikrą), paieškos kokybę (aktualių dokumentų preciziškumą ir atkūrimą) bei protavimo nuoseklumą (struktūrinį loginės eigos vertinimą).
Kada niuansuotai kokybei vertinti naudoti LLM kaip vertintoją
Taikant LLM kaip vertintoją, vertina antrasis DI modelis: žmogaus atliekamą peržiūrą pakeičia keičiamo masto automatinis kokybės įvertinimas. LLM kaip vertintojas dažnai naudojamas be reikalo, kai reikiamą tikslumą užtikrintų paprastesnės metrikos. Jis gali būti naudingas, kai deterministinėmis patikromis kokybės nustatyti neįmanoma, pavyzdžiui, kai metrika yra semantinė (naudingumas, pagrįstumas, protavimo kokybė, tonas ar politikos aiškinimas). Gali prireikti keičiamo masto grįžtamojo ryšio apie daugybę užklausos ir modelio variantų, taip pat aiškios vertinimo skalės bei susistemintos išvesties schemos. Kad šis metodas būtų veiksmingas, atlikite šiuos veiksmus:
Aiškiai apibrėžkite vertinimo skalės aspektus: teisingumą, pagrįstumą, politikos laikymąsi, praktinį pritaikomumą ir toną.
Vertintojo atsakymams naudokite susistemintas išvestis (JSON schemą).
Fiksuokite ir dvejetainius slenkstinių patikrų balus, ir diagnostinį tekstą, skirtą trikčių analizei.
Per kiekvieną leidimo ciklą kalibruokite vertintojo išvestis pagal žmonių sužymėtus pavyzdžius.
Itin svarbiose srityse naudokite du vertintojus arba periodiškai tikrinkite jų sutarimą.
Stebėkite vertintojo nuokrypį ir nesutarimų dažnį laikui bėgant.
Etaloninio testo duomenų rinkinys – fiksuotas, kruopščiai atrinktas testinių pavyzdžių su žinomais atsakymais rinkinys, naudojamas nuosekliai vertinti modelius ir objektyviai lyginti skirtingų versijų rezultatus. Paprastai jį sudaro įvestys (pvz., naudotojų užklausos), tikėtinos išvestys arba etaloniniai vertinimai ir vertinimo kriterijai ar žymos balams skirti. Vieši etaloniniai testai naudojami pažangiausių modelių našumui lyginti. Projektuojant sistemą jie gali būti pradinis orientyras renkantis tinkamą modelį.
Tačiau vertindami savo sistemą negalite šiais testais pasikliauti kaip našumo jūsų verslo aplinkybėmis pakaitalu, nes jie turi žinomų trūkumų:
Užterštumas: modeliai gali būti mokyti naudojant etaloninio testo duomenis, todėl vertinimas pagal tą patį rinkinį primena pažymio rašymą leidus naudotis paruoštukais.
Prisotinimas: visi geriausi modeliai jau pasiekia beveik aukščiausius balus, todėl našumo pagerėjimą ar pablogėjimą tesudaro keli procentiniai punktai, dažnai patenkantys į natūralios testų rezultatų variacijos ribas.
Siaura aprėptis: etaloninių testų duomenys neatspindi tikrųjų jūsų užduočių, nes yra itin kruopščiai atrinkti ir išvalyti. Kai kurie net sugeneruoti LLM, todėl neatspindi jūsų duomenims būdingo sudėtingumo ir ribinių atvejų (rašybos klaidų, neįprastų formuluočių ar triukšmingų vaizdų).
Mokinys prašo programos padėti išspręsti tekstinius uždavinius.
Tinkamo viešo etaloninio testo pavyzdys: GSM8K (pradinių klasių matematinis protavimas)
Pasirenkamas sudėtingesnis rinkinys: MATH.
Kuo šis etaloninis testas naudingas:
Galima greitai palyginti, kuris modelis geriau atlieka bendrojo matematinio protavimo užduotis,
Tai geras pradinis filtras prieš investuojant į visapusį produkto vertinimą.
Kodėl vis tiek reikia savo duomenų rinkinio:
Jūsų programai taikomi reikalavimai, kurių GSM8K netikrina:
Jūsų mokymo programos formuluotės ir temų eiliškumas,
Jūsų amžiaus grupei tinkamas aiškinimo stilius,
Kaip elgtis su dviprasmiškais ar rašybos klaidų kupinais mokinių klausimais,
Taisyklės (pvz., kada pateikti užuominą, o kada – išsamų atsakymą).
Veiksmingai patikrai būtini konkrečiai jūsų programai skirti vertinimo etaloniniai testai. Šiuos duomenų rinkinius turėtų sudaryti tikros sąveikos, įprasti ribiniai atvejai ir tikėtini trikčių scenarijai. Kuriant naują produktą ar procesą tai gali būti sudėtinga užduotis. Vis dėlto dažniausiai duomenis galima surinkti iš esamo produkto arba pradėti rinkti kuo anksčiau, net per pradinį testavimo etapą. Sukūrus programą, šie etaloniniai testai turėtų būti tobulinami kartu su produktu ir ilgainiui tapti išsamesni bei reprezentatyvesni.
Atvejo analizė: individualaus etaloninio testo kūrimas mažmeninės bankininkystės asistentui
Banko pokalbių robotas atsako į klausimus apie biudžetus, išlaidas ir operacijas. Vieši klausimų ir atsakymų bei teksto vertimo į SQL etaloniniai testai neaprėpė tokių esminių bankininkystės rizikų kaip SQL įterpimas, duomenų nutekėjimas ar konteksto perkėlimas per kelis pokalbio etapus. Sukūrėme individualų etaloninį testą, atkartojantį šio produkto agento procesą.
Individualaus etaloninio testo komponentai šioje kodų bazėje:
Raudonosios komandos kenkėjiškų užklausų rinkinys, skirtas SQL įterpimui, asmens identifikavimo informacijos išgavimui, užklausos instrukcijų pakeitimui ir duomenų nutekėjimui tarp seansų tikrinti
Visiškas saugos pažeidimų netoleravimas: bet koks SQL įterpimas, asmens identifikavimo informacijos išgavimas ar duomenų nutekėjimas tarp seansų turi būti atmestas.
Konteksto perkėlimo tikslumas: performuluotose užklausose turi būti išlaikytas naudotojo ketinimas ir esiniai.
Svarbiausia išvada: etaloninio testo kūrimą laikykite produkto funkcija. Dabartinė infrastruktūra patvirtina, kad ištisinis vertinimas prijungtas, tačiau aprėptį ir imčių dydį reikia didinti, kad būtų atspindėtos tikros bankininkystės rizikos (daugiatikslės atakos, apsaugos priemonių apėjimas ir nuo konteksto priklausančios užklausos). Etaloninis testas turėtų plėstis kartu su naujais agentais ir apsaugos priemonėmis.
Ryšys tarp konkrečiai jūsų programai skirto etaloninio testo ir modelio pasirinkimo yra itin svarbus. Etaloninis testas atskleidžia ne tik tai, ar sprendimas veikia, bet ir tai, kuris modelio dydžio bei papildomo mokymo metodų derinys ekonomiškiausiai užtikrina reikiamą našumą. Didžiausi iš anksto išmokytų modelių patobulinimai („PT“ santrumpoje ChatGPT) pasiekiami ne mokant juos iš naujo, o taikant "papildomo mokymo" metodus.
Šiais metodais formuojama, kokia informacija prieinama modeliui, kaip ji susisteminama ir kaip modelis valdomas bei koordinuojamas išvedimo metu. Papildomo mokymo metodai:
Užklausų teikimas taikant minčių grandinę ir dinamiškas skaičiavimo išteklių paskirstymas (sudėtingesnėms problemoms skiriama daugiau protavimo)
Savinuoseklumas, kai sugeneruojamos kelios išvestys ir pasirenkama geriausia
Konteksto kūrimas ir koordinavimas, pavyzdžiui, generavimas, papildytas informacijos paieška (RAG), užklausos naudojant kelis pavyzdžius ir agentinės darbo eigos
Įrankių ir išorinių žinių naudojimas, leidžiantis modeliui veikti neapsiribojant jo vidiniais parametrais
Žinių pateikimo ir saugojimo strategijos, skirtos veiksmingai paieškai ir struktūrinių bei nestruktūrinių duomenų protavimui
Nors šie papildomo mokymo metodai gali gerokai pagerinti sistemos našumą, jie taip pat verčia ieškoti kompromisų. Kiekvienas papildomas koordinavimo, paieškos ar protavimo lygmuo didina sistemos sudėtingumą, išvedimo trukmę ir veiklos sąnaudas. Tačiau apgalvotai parinkus tinkamą papildomo mokymo metodų derinį dažnai galima naudoti mažesnius, spartesnius ir pigesnius modelius, kartu išlaikant reikiamą našumą. Užuot didinus modelį, našumas pasiekiamas geriau suprojektuojant sistemą.
Tinkama pusiausvyra priklauso nuo konkrečios programos, todėl optimalų metodų derinį reikėtų nustatyti pagal konkrečiai jai skirtus vertinimus. Jie padės nustatyti ribą, nuo kurios papildomas koordinavimas nebesuteikia reikšmingos naudos, todėl komandos galės pasirinkti mažiausią papildomo mokymo sudėtingumą, būtiną norimam našumui pasiekti.
DI sprendimą reikia suvokti kaip visą sistemą: duomenų bazes, API, naudotojo sąsajas, koordinavimo lygmenis, stebėsenos infrastruktūrą ir kitus komponentus. Todėl vertinimas turi apimti visą technologijų rinkinį. Stebėkite svarbiausias sistemos dalis, kad laiku pastebėtumėte galimas problemas ir galėtumėte atsakingai spartinti plėtrą.
Svarbiausių sistemos dalių stebėsena apima:
Procesų papildymą priemonėmis, leidžiančiomis gauti išmatuojamus rezultatus.
Eksperimentų registravimą, kad matytumėte kiekvieno pakeitimo poveikį.
Paprastų A/B palyginimų atlikimą prieš diegiant esminius pakeitimus, siekiant nustatyti galimas regresijas.
Duomenimis grindžiamos iteracijos sutrumpina kelią nuo prototipo iki produkcinės aplinkos ir nepalieka nepastebėtų sričių. Žurnalų rašymas ir stebėsena taip pat svarbūs norint suprasti, kaip programa naudojama realiame pasaulyje. Štai stebimumą užtikrinantis pavyzdys:
1 veiksmas. Gaunama naudotojo užklausa su request_id, user_segment ir intent.
2 veiksmas. Sekimo žurnale įrašoma modelio versija, užklausos versija, paieškos dokumentai ir įrankių iškvietimai.
3 veiksmas. LLM vertintojas įvertina atsakymą (teisingumą, pagrįstumą, policy_risk).
4 veiksmas. Taisyklių modulis patikrina slenkstines vertes.
5 veiksmas. Jei slenkstinė vertė pažeista, siunčiamas įspėjimas ir užklausa nukreipiama atsarginiam sprendimui arba žmogaus peržiūrai.
6 veiksmas. Triktis įtraukiama į pirminio vertinimo eilę, o tada – į etaloninių testų užduočių sąrašą.
Tikri naudotojai retai elgiasi tiksliai taip, kaip tikisi kūrėjai. Vieni neteisingai supras instrukcijas. Kiti tyčia ieškos silpnųjų vietų. Šie ribiniai atvejai – ne anomalijos, o itin vertingi signalai. Tinkamai įgyvendintas vertinimo procesas juos užfiksuoja, išanalizuoja ir įtraukia į būsimus testus. Sparti iteracija be nepastebėtų sričių įmanoma tik tada, kai vertinimas nuo pradžių integruotas į sistemą, o ne prijungtas užbaigus kūrimą.
Rekomenduojame apsaugos priemones ir stebėseną integruoti nuo pat pirmos dienos:
Reguliariai stebėkite modelio metrikas ir regresijas pagal konkrečiai programai skirtą etaloninį testą.
Fiksuokite ir peržiūrėkite ribinius atvejus ar priešiškas įvestis ir įtraukite juos į konkrečiai programai skirto etaloninio testo duomenų rinkinį.
Užtikrinkite, kad šios vertinimo metrikos atitiktų pagrindinius jūsų KPI.
Reguliariai kritiškai tikrinkite duomenų rinkinį ir etaloninį testą, kad nepraleistumėte naujų rizikų ir išvengtumėte šališkumo.
Įdiekite automatinius įspėjimus apie metrikų prastėjimą (pvz., jei tikslumas nukrinta žemiau 85 %, inicijuokite peržiūrą).
Itin svarbiems sprendimams (teisinėms konsultacijoms, medicininėms rekomendacijoms, finansinėms operacijoms) taikykite žmogaus atliekamą peržiūrą.
Kiekvienam etaloninio testo vykdymui reikia skaičiavimo išteklių ir energijos. Kiekvienas perteklinis eksperimentas didina sąnaudas. Atsakingai vertinant kruopštumas turi būti derinamas su efektyvumu.
Energijos naudojimą ir sąnaudas galima suvaldyti keliais praktiniais veiksmais:
Kai įmanoma, naudokite mažesnius modelius: pirmuosius eksperimentus vykdykite su pigesniais modeliais, o mastą didinkite tik patvirtinę metodo tinkamumą.
Talpykloje saugokite užklausas ir API iškvietimus.
Planuokite užduotis atsižvelgdami į energijos naudojimą (paketinis apdorojimas, spot egzemplioriai, lankstusis prioritetas).
Kartu su našumu stebėkite skaičiavimo išteklių naudojimą.
Taip pat sekite naujus DI reglamentus. Net jei specialaus įstatymo nėra, vis tiek taikomos esamos sistemos ir būtinos priemonės, pavyzdžiui:
Duomenų apsauga:
Užtikrinkite, kad etaloninių testų duomenų rinkiniuose nebūtų asmens identifikavimo informacijos, kuriai naudoti negautas tinkamas sutikimas
Įgyvendinkite registruojamų užklausų duomenų saugojimo politiką
Suteikite galimybę pateikti prašymus ištrinti duomenis
Lygybė ir šališkumas:
Tikrinkite našumą skirtingose demografinėse grupėse
Kurdami etaloninį testą užtikrinkite įvairių grupių reprezentavimą
Žmogaus teisės ir skaidrumas:
Aiškiai informuokite naudotojus apie modelio apribojimus
Paaiškinkite itin svarbius sprendimus
Sudarykite sąlygas žmogui prižiūrėti kritinės svarbos programas
Vertinimas – ne vienkartinis įvykis, o nuolat tobulėjanti sistema. Sparčiai kintančioje srityje jūsų pranašumą lemia gebėjimas greitai išbandyti, mokytis ir prisitaikyti, kad modelius ir naujus sprendimus diegtumėte veiksmingiau.
Vertinimą pavertus pagrindine inžinerijos ir produktų valdymo veikla, komandos gali diegti naujoves greičiau ir saugiau. Pirmiausia apibrėžkite, kaip konkrečiame jūsų DI sprendimo kontekste atrodo geras rezultatas, sukurkite vertinimo platformą ir ją tobulinkite, kad turėtumėte konkrečiai programai skirtą etaloninį testą, kuris po kiekvienos iteracijos suteiktų užtikrintumo dėl pasirengimo produkcinei aplinkai.