Trumpas atsakymas: norint gerai įvertinti dirbtinio intelekto modelius, pirmiausia reikia apibrėžti, kas „geras“ atrodo realiam vartotojui ir priimant sprendimą. Tada sukurkite pasikartojančius vertinimus su reprezentatyviais duomenimis, griežta duomenų nutekėjimo kontrole ir keliais rodikliais. Pridėkite streso, šališkumo ir saugos patikrinimus, o kai kas nors pasikeičia (duomenys, raginimai, politika), iš naujo paleiskite testavimą ir tęskite stebėjimą po paleidimo.
Svarbiausios išvados:
Sėkmės kriterijai : prieš pasirinkdami metriką, apibrėžkite vartotojus, sprendimus, apribojimus ir blogiausio atvejo nesėkmes.
Pakartojamumas : sukurkite vertinimo sistemą, kuri pakartotinai atliktų palyginamus testus su kiekvienu pakeitimu.
Duomenų higiena : išlaikykite stabilius skaidymus, venkite dublikatų ir anksti užblokuokite funkcijų nutekėjimą.
Pasitikėjimo patikrinimai : streso testo patikimumas, teisingumo vertinimas ir LLM saugos elgsena su aiškiomis rubrikomis.
Gyvavimo ciklo disciplina : diegti etapais, stebėti nukrypimus ir incidentus bei dokumentuoti žinomus trūkumus.
Straipsniai, kuriuos galbūt norėsite perskaityti po šio:
🔗 Kas yra dirbtinio intelekto etika?
Išnagrinėkite principus, kuriais vadovaujamasi atsakingu dirbtinio intelekto projektavimu, naudojimu ir valdymu.
🔗 Kas yra dirbtinio intelekto šališkumas?
Sužinokite, kaip šališki duomenys iškreipia dirbtinio intelekto sprendimus ir rezultatus.
🔗 Kas yra dirbtinio intelekto mastelio keitimas?
Supraskite dirbtinio intelekto sistemų mastelio keitimą atsižvelgiant į našumą, kainą ir patikimumą.
🔗 Kas yra dirbtinis intelektas
Aiški dirbtinio intelekto, tipų ir realaus pasaulio panaudojimo apžvalga.
1) Pradėkite nuo nepatrauklaus „gero“ apibrėžimo
Prieš metrikų nustatymą, prieš ataskaitų suvestines, prieš bet kokį lyginamųjų rodiklių keitimą – nuspręskite, kaip atrodo sėkmė.
Paaiškinkite:
-
Vartotojas: vidaus analitikas, klientas, klinikinis specialistas, vairuotojas, pavargęs pagalbos agentas 16 val.…
-
Sprendimas: patvirtinti paskolą, pažymėti sukčiavimo atvejus, pasiūlyti turinį, apibendrinti pastabas
-
Svarbiausios nesėkmės:
-
Klaidingai teigiami (erzinantys) ir klaidingai neigiami (pavojingi) rezultatai
-
-
Apribojimai: delsa, kaina už užklausą, privatumo taisyklės, paaiškinamumo reikalavimai, prieinamumas
Tai yra tas etapas, kai komandos pradeda optimizuoti pagal „gražų rodiklį“, o ne pagal „reikšmingą rezultatą“. Tai nutinka dažnai. Tikrai... dažnai.
Tvirtas būdas išlaikyti šį rizikos suvokimą (o ne pagrįstą nuojauta) yra testavimą susieti su patikimumu ir gyvavimo ciklo rizikos valdymu, kaip tai daro NIST dirbtinio intelekto rizikos valdymo sistemoje (AI RMF 1.0) [1].
2) Kas daro gerą „kaip testuoti dirbtinio intelekto modelius“ versiją ✅
Tvirtas testavimo metodas turi keletą neginčijamų dalykų:
-
Reprezentatyvūs duomenys (ne tik švarūs laboratoriniai duomenys)
-
Aiškūs plyšiai su apsauga nuo nuotėkio (apie tai po akimirkos)
-
Baziniai modeliai (paprasti modeliai, kuriuos turėtumėte įveikti – fiktyvūs įverčiai egzistuoja ne be reikalo [4])
-
Keli rodikliai (nes vienas skaičius mandagiai meluoja jums į akis)
-
Stresiniai testai (kraštutiniai atvejai, neįprasti įvesties duomenys, prieštaringi scenarijai)
-
Žmonių atliekami peržiūros ciklai (ypač generatyviniams modeliams)
-
Stebėjimas po paleidimo (nes pasaulis keičiasi, kanalai nutrūksta, o vartotojai yra… kūrybingi [1])
Taip pat: geras metodas apima dokumentavimą, ką išbandėte, ko nebandėte ir dėl ko nerimaujate. Ta dalis „dėl ko nerimauju“ atrodo nejaukiai – ir būtent čia pradeda kauptis pasitikėjimas.
Du dokumentacijos modeliai, kurie nuolat padeda komandoms išlikti atviroms:
-
Modelių kortelės (kam skirtas modelis, kaip jis buvo įvertintas, kur jis neatitinka lūkesčių) [2]
-
Duomenų rinkinių duomenų lapai (kas yra duomenys, kaip jie buvo surinkti, kam jie turėtų / neturėtų būti naudojami) [3]
3) Įrankių realybė: ką žmonės naudoja praktiškai 🧰
Įrankiai yra neprivalomi. Geri vertinimo įpročiai – ne.
Jei norite pragmatiškos konfigūracijos, dauguma komandų gauna tris grupes:
-
Eksperimento stebėjimas (vykdymai, konfigūracijos, artefaktai)
-
Vertinimo paketai (pakartojami neprisijungus atliekami testai + regresiniai rinkiniai)
-
Stebėjimas (dreifo tipo signalai, našumo tarpiniai įrenginiai, incidentų įspėjimai)
Pavyzdžių, kuriuos pamatysite daug realiame gyvenime (ne rekomendacijos, ir taip – funkcijų / kainų pokyčiai): „MLflow“, „Weights & Biases“, „Great Expectations“, „Evidently“, „Deepchecks“, „OpenAI Evals“, „TruLens“, „LangSmith“.
iš šio skyriaus pasirinksite tik vieną idėją sukurkite pasikartojančią vertinimo sistemą . Norite „paspausti mygtuką → gauti palyginamus rezultatus“, o ne „iš naujo paleisti užrašų knygelę ir melstis“.
4) Sukurkite tinkamą testų rinkinį (ir sustabdykite duomenų nutekėjimą) 🚧
Šokiruojantis skaičius „nuostabių“ modelių netyčia sukčiauja.
Standartiniam ML
Kelios neseksualios taisyklės, kurios gelbsti karjerą:
-
Užtikrinkite traukinio / patvirtinimo / bandymo padalijimo stabilumą (ir užrašykite padalijimo logiką)
-
Išvengti dublikatų skirtinguose padaliniuose (tas pats vartotojas, tas pats dokumentas, tas pats produktas, beveik dublikatai)
-
Stebėkite funkcijų nutekėjimą (būsima informacija prasmuks į „dabartines“ funkcijas)
-
Naudokite bazinius rodiklius (fiktyvius įverčius), kad nešvęstumėte pralaimėjimo... nieko [4]
Nuotėkio apibrėžimas (greitasis variantas): bet kas mokymo/vertinimo procese, kas suteikia modeliui prieigą prie informacijos, kurios jis neturėtų priimdamas sprendimą. Tai gali būti akivaizdu („būsimoji žyma“) arba subtilu („laiko žymos po įvykio segmentas“).
LLM ir generatyviniams modeliams
Kuriate raginimų ir politikos sistemą , o ne tik „modelį“.
-
Sukurkite auksinį raginimų rinkinį (mažą, aukštos kokybės, stabilų)
-
Pridėti naujausius tikrus pavyzdžius (anonimizuotus ir nepažeidžiant privatumo)
-
Turėkite kraštutinių atvejų rinkinį : rašybos klaidos, slengas, nestandartinis formatavimas, tuščios įvesties vietos, daugiakalbiai netikėtumai 🌍
Praktinis dalykas, kurį mačiau ne kartą: komanda pateikia užklausą su „geru“ neprisijungus įvertinimu, o tada klientų aptarnavimo tarnyba sako: „Šaunu. Užtikrintai praleidžiamas vienas svarbus sakinys.“ Pataisymas nebuvo „didesnis modelis“. Tai buvo geresnės testavimo užduotys , aiškesnės vertinimo kriterijai ir regresinis rinkinys, kuris nubaudė būtent už tą gedimo režimą. Paprasta. Efektyvu.
5) Vertinimas neprisijungus: reikšmingi rodikliai 📏
Metrika yra gerai. Metrinė monokultūra – ne.
Klasifikavimas (šlamštas, sukčiavimas, ketinimas, triažas)
Naudokite daugiau nei tikslumą.
-
Tikslumas, atkūrimas, F1
-
Slenksčio reguliavimas (jūsų numatytoji riba retai kada yra „teisinga“ atsižvelgiant į jūsų išlaidas) [4]
-
Painiavos matricos pagal segmentą (regionas, įrenginio tipas, naudotojų kohorta)
Regresija (prognozavimas, kainodara, vertinimas)
-
MAE / RMSE (rinkitės pagal tai, kaip norite bausti už klaidas)
-
Kalibravimo tipo patikrinimai, kai rezultatai naudojami kaip „balai“ (ar balai atitinka realybę?)
Reitingavimo / rekomendavimo sistemos
-
NDCG, MAP, MRR
-
Pjaustymas pagal užklausos tipą (antraštė ir uodega)
Kompiuterinė rega
-
mAP, IoU
-
Kiekvienos klasės pasirodymas (retos klasės yra tos, kuriose modeliai jus gėdina)
Generatyviniai modeliai (LLM)
Štai čia žmonės ima... filosofuoti 😵💫
Praktiniai variantai, kurie veikia realiose komandose:
-
Žmogaus vertinimas (geriausias signalas, lėčiausia kilpa)
-
Porinis pasirinkimas / laimėjimo rodiklis (A prieš B lengviau nei absoliutus taškų skaičiavimas)
-
Automatiniai teksto rodikliai (patogūs kai kurioms užduotims, klaidinantys kitoms)
-
Užduotimis pagrįsti patikrinimai: „Ar buvo ištraukti tinkami laukai?“ „Ar buvo laikomasi politikos?“ „Ar buvo nurodyti šaltiniai, kai to reikėjo?“
Jei norite struktūrizuoto „daugiametrinio, daugelio scenarijų“ atskaitos taško, HELM yra geras ramstis: jis aiškiai perkelia vertinimą ne tik į tikslumą, bet ir į tokius dalykus kaip kalibravimas, patikimumas, šališkumas / toksiškumas ir efektyvumo kompromisai [5].
Mažas nukrypimas nuo temos: automatizuoti rašymo kokybės rodikliai kartais atrodo kaip sumuštinio vertinimas jį sveriant. Tai nėra niekas, bet... na, štai 🥪
6) Tvirtumo testavimas: šiek tiek paprakaituokite 🥵🧪
Jei jūsų modelis veikia tik su tvarkingais įvesties duomenimis, tai iš esmės yra stiklinė vaza. Graži, trapi, brangi.
Testas:
-
Triukšmas: rašybos klaidos, trūkstamos reikšmės, nestandartinis unikodas, formatavimo trikdžiai
-
Platinimo pokytis: naujos produktų kategorijos, naujas slengas, nauji jutikliai
-
Ekstremalios vertės: skaičiai, esantys už diapazono ribų, milžiniški naudingieji krūviai, tuščios eilutės
-
„Priešiškos“ įvesties duomenys, kurie neatrodo kaip jūsų mokymo rinkinys, bet atrodo kaip naudotojai
LLM studijų atveju įtraukite:
-
Greiti injekcijos bandymai (instrukcijos paslėptos naudotojo turinyje)
-
„Ignoruoti ankstesnes instrukcijas“ šablonai
-
Įrankių naudojimo kraštutiniai atvejai (neteisingi URL, skirtojo laiko apribojimai, daliniai rezultatai)
Tvirtumas yra viena iš tų patikimumo savybių, kurios skamba abstrakčiai, kol neįvyksta incidentai. Tada jos tampa... labai apčiuopiamos [1].
7) Šališkumas, sąžiningumas ir kam tai tinka ⚖️
Modelis gali būti „tikslus“ apskritai, tačiau nuosekliai blogesnis konkrečioms grupėms. Tai ne maža klaida. Tai produkto ir pasitikėjimo problema.
Praktiniai žingsniai:
-
Įvertinkite veiklos rezultatus pagal reikšmingus segmentus (teisiškai / etiškai tinkama juos matuoti)
-
Palyginkite klaidų dažnius ir kalibravimą tarp grupių
-
Testuokite tarpinio serverio funkcijas (pašto kodą, įrenginio tipą, kalbą), kurios gali užkoduoti jautrius požymius
Jei to niekur nedokumentuojate, iš esmės prašote ateities savęs išspręsti pasitikėjimo krizę be žemėlapio. Modelių kortelės yra tinkama vieta tai pateikti [2], o NIST patikimumo vertinimo sistema pateikia jums išsamų sąrašą, ką apskritai turėtų apimti „geras“ [1].
8) Saugos ir apsaugos testavimas (ypač LLM studentams) 🛡️
Jei jūsų modelis gali generuoti turinį, jūs testuojate ne tik tikslumą. Jūs testuojate elgseną.
Įtraukite testus, skirtus:
-
Neleidžiamas turinio generavimas (politikos pažeidimai)
-
Privatumo nutekėjimas (ar tai atkartoja paslaptis?)
-
Haliucinacijos didelės rizikos srityse
-
Per didelis atsisakymas (modelis atmeta įprastus prašymus)
-
Toksiškumo ir priekabiavimo rezultatai
-
Duomenis bandoma išfiltruoti naudojant greitą injekciją
Pagrįstas metodas yra toks: apibrėši politikos taisykles → sukurs testų užklausas → įvertins rezultatus atlikdami žmonių ir automatinius patikrinimus → paleisk jį kiekvieną kartą, kai kas nors pasikeičia. Ta „kiekvieną kartą“ dalis yra nuoma.
Tai puikiai atitinka gyvavimo ciklo rizikos mąstyseną: valdyti, nustatyti kontekstą, matuoti, valdyti, kartoti [1].
9) Testavimas internetu: etapais vykdomas diegimas (ten, kur slypi tiesa) 🚀
Neinternetiniai testai yra būtini. Internetinė patirtis yra ta vieta, kur realybė išryškėja avint purvinus batus.
Nereikia būti išgalvotam. Tiesiog reikia būti drausmingam:
-
Paleisti šešėliniu režimu (modelis veikia, neturi įtakos vartotojams)
-
Laipsniškas diegimas (pirmiausia mažas srautas, plėskite, jei didelis)
-
Stebėti rezultatus ir incidentus (skundus, eskalacijas, politikos trūkumus)
Net jei negalite gauti tiesioginių etikečių, galite stebėti tarpinio serverio signalus ir veikimo būklę (vėlavimą, gedimų dažnį, kainą). Svarbiausia: jums reikia kontroliuojamo būdo aptikti gedimus anksčiau, nei tai padarys visa jūsų vartotojų bazė [1].
10) Stebėjimas po diegimo: dreifas, gedimas ir tylus gedimas 📉👀
Modelis, kurį išbandėte, nėra tas, su kuriuo galiausiai gyvensite. Duomenys keičiasi. Vartotojai keičiasi. Pasaulis keičiasi. Vamzdynas nutrūksta 2 val. nakties. Žinote, kaip būna..
Monitorius:
-
Įvesties duomenų poslinkis (schemos pakeitimai, trūkumai, pasiskirstymo poslinkiai)
-
Rezultatų poslinkis (klasės balanso pokyčiai, balų pokyčiai)
-
Našumo rodikliai (nes etikečių vėlavimai yra realūs)
-
Atsiliepimų signalai (nepageidaujamas įvertinimas, pakartotiniai redagavimai, eskalavimas)
-
Segmentų lygio regresijos (tylieji žudikai)
Ir nustatykite pernelyg nejautrias pavojaus ribas. Nuolat rėkiantis monitorius yra ignoruojamas – kaip automobilio signalizacija mieste.
Šis „stebėti + tobulinti laikui bėgant“ ciklas nėra pasirenkamas, jei jums rūpi patikimumas [1].
11) Praktiškas darbo eigos pavyzdys, kurį galite nukopijuoti 🧩
Štai paprastas ciklas, kuris keičia mastelį:
-
Apibrėžkite sėkmės ir nesėkmės režimus (įskaitant kainą / vėlavimą / saugumą) [1]
-
Sukurkite duomenų rinkinius:
-
auksinis rinkinys
-
krašto dėklo pakuotė
-
naujausi realūs pavyzdžiai (saugant privatumą)
-
-
Pasirinkite metriką:
-
užduočių metrikos (F1, MAE, laimėjimo rodiklis) [4][5]
-
saugos rodikliai (politikos priėmimo rodiklis) [1][5]
-
veiklos rodikliai (vėlavimas, kaina)
-
-
Sukurkite vertinimo sistemą (veikiančią su kiekvienu modelio / raginimo pakeitimu) [4][5]
-
Pridėti streso testus + priešiškumo testus [1][5]
-
Žmogaus atliekamas imties vertinimas (ypač LLM rezultatų) [5]
-
Siuntimas per šešėlinį + etapinį diegimą [1]
-
Stebėjimas + perspėjimas + perkvalifikavimas su drausme [1]
-
Dokumento rezultatai pateikiami modelio kortelės stiliaus aprašyme [2][3]
Mokymai žavūs. Testavimas pelningas.
12) Baigiamosios pastabos + trumpa santrauka 🧠✨
Jei prisimenate tik kelis dalykus apie kaip testuoti dirbtinio intelekto modelius :
-
Naudokite reprezentatyvius bandymų duomenis ir venkite nuotėkio [4]
-
Pasirinkite kelis su realiais rezultatais susietus rodiklius [4][5]
-
Teisės magistro (LLM) studentams remkitės žmonių vertinimu ir laimėjimo rodiklio palyginimais [5]
-
Testo patikimumas – neįprasti įvesties duomenys yra užmaskuoti įprasti įvesties duomenys [1]
-
Saugiai išriedėkite ir stebėkite, nes modeliai dreifuoja ir trūkinėja vamzdynai [1]
-
Dokumentuokite, ką atlikote ir ko nebandėte (nepatogu, bet veiksminga) [2][3]
Testavimas nėra tik „įrodyti, kad veikia“. Tai „sužinoti, kodėl sistema neveikia, kol to nepadarė jūsų vartotojai“. Ir taip, tai nėra taip patrauklu, bet tai yra ta dalis, kuri padeda sistemai išlikti, kai viskas sustoja... 🧱🙂
DUK
Geriausias būdas išbandyti dirbtinio intelekto modelius, kad jie atitiktų realius vartotojų poreikius
Pradėkite apibrėždami „gerą“ pagal realų vartotoją ir sprendimą, kurį palaiko modelis, o ne tik pagal lyderių lentelės rodiklį. Nustatykite brangiausius gedimo režimus (klaidingai teigiami ir klaidingai neigiami rezultatai) ir aiškiai apibrėžkite griežtus apribojimus, tokius kaip delsa, kaina, privatumas ir paaiškinamumas. Tada pasirinkite rodiklius ir testų atvejus, kurie atspindėtų šiuos rezultatus. Tai neleis optimizuoti „gražaus rodiklio“, kuris niekada nevirsta geresniu produktu.
Sėkmės kriterijų apibrėžimas prieš pasirenkant vertinimo metrikas
Užsirašykite, kas yra vartotojas, kokį sprendimą modelis turėtų paremti ir kaip atrodo „blogiausio atvejo gedimas“ gamybinėje aplinkoje. Pridėkite operacinius apribojimus, tokius kaip priimtina delsa ir kaina už užklausą, bei valdymo poreikius, tokius kaip privatumo taisyklės ir saugos politika. Kai tai bus aišku, metrikos taps būdu įvertinti teisingus dalykus. Be šio rėmo komandos linkusios optimizuoti tai, ką lengviausia išmatuoti.
Duomenų nutekėjimo ir atsitiktinio sukčiavimo prevencija vertinant modelį
Užtikrinkite stabilius mokymo/patvirtinimo/testavimo padalijimus ir dokumentuokite padalijimo logiką, kad rezultatus būtų galima atkartoti. Aktyviai blokuokite pasikartojančius ir beveik pasikartojančius duomenis skirtinguose padalijimuose (tas pats vartotojas, dokumentas, produktas ar pasikartojantys modeliai). Stebėkite funkcijų nutekėjimą, kai „būsima“ informacija patenka į įvestis per laiko žymas arba laukus po įvykio. Tvirtas pradinis lygis (net ir fiktyvūs įverčiai) padeda pastebėti, kada pastebite triukšmą.
Ką turėtų apimti vertinimo sistema, kad testus būtų galima kartoti atliekant pakeitimus
Praktinis rinkinys pakartotinai atlieka palyginamus testus su kiekvienu modeliu, raginimu ar politikos pakeitimu, naudodamas tuos pačius duomenų rinkinius ir vertinimo taisykles. Paprastai jį sudaro regresijos rinkinys, aiškios metrikų ataskaitų suvestinės ir saugomos konfigūracijos bei artefaktai atsekamumui. LLM sistemoms taip pat reikalingas stabilus raginimų „auksinis rinkinys“ ir kraštutinių atvejų paketas. Tikslas yra „paspausti mygtuką → palyginami rezultatai“, o ne „iš naujo paleisti užrašų knygutę ir melstis“
Metrikos, skirtos dirbtinio intelekto modelių testavimui ne tik tikslumu
Naudokite kelis rodiklius, nes vienas skaičius gali nuslėpti svarbius kompromisus. Klasifikavimui derinkite tikslumo / atkūrimo / F1 su slenksčio derinimo ir painiavos matricomis pagal segmentus. Regresijai pasirinkite MAE arba RMSE, atsižvelgdami į tai, kaip norite bausti klaidas, ir pridėkite kalibravimo stiliaus patikrinimus, kai išvestys veikia kaip balai. Reitingavimui naudokite NDCG / MAP / MRR ir pjūvio pagal pagrindines ir uodegines užklausas, kad nustatytumėte netolygų našumą.
LLM rezultatų vertinimas, kai automatizuoti rodikliai neatitinka lūkesčių
Traktuokite tai kaip raginimų ir politikos sistemą ir įvertinkite elgseną, o ne tik teksto panašumą. Daugelis komandų derina žmonių vertinimą su poriniu pasirinkimu (A/B laimėjimo rodiklis), taip pat užduotimis pagrįstus patikrinimus, tokius kaip „ar buvo išskirtas tinkamas laukas“ arba „ar buvo laikomasi politikos“. Automatinės teksto metrikos gali padėti siaurais atvejais, tačiau jos dažnai nepastebi to, kas rūpi vartotojams. Aiškios rubrikos ir regresinis rinkinys paprastai yra svarbesni nei vienas balas.
Tvirtumo testai, kuriuos reikia atlikti, kad modelis nesugestų esant triukšmingiems įvesties duomenims
Atlikite modelio testavimą su rašybos klaidomis, trūkstamomis reikšmėmis, keistu formatavimu ir nestandartiniu unikodu, nes realūs vartotojai retai būna tvarkingi. Pridėkite paskirstymo poslinkio atvejus, pvz., naujas kategorijas, slengą, jutiklius ar kalbos modelius. Įtraukite kraštutines reikšmes (tuščias eilutes, didelius naudingus krūvius, skaičius, kurie neatitinka diapazono), kad būtų parodytas trapus elgesys. LLM atveju taip pat patikrinkite raginimų injekcijos modelius ir įrankių naudojimo gedimus, pvz., skirtą laiką ar dalinius rezultatus.
Šališkumo ir sąžiningumo problemų tikrinimas nepasiklystant teorijoje
Įvertinkite reikšmingų pjūvių našumą ir palyginkite klaidų dažnį bei kalibravimą tarp grupių, kuriose tai teisiškai ir etiškai tinkama matuoti. Ieškokite tarpinių funkcijų (pvz., pašto kodo, įrenginio tipo ar kalbos), kurios gali netiesiogiai koduoti jautrius požymius. Modelis gali atrodyti „apskritai tikslus“, tačiau konkrečioms kohortoms nuolat neatitikti lūkesčių. Dokumentuokite, ką išmatavote, o ko ne, kad būsimi pakeitimai tyliai iš naujo neįvestų regresijų.
Saugos ir apsaugos bandymai, skirti generatyvinio dirbtinio intelekto ir LLM sistemoms
Patikrinkite neleistino turinio generavimą, privatumo nutekėjimą, haliucinacijas svarbiose srityse ir per didelį atsisakymą, kai modelis blokuoja įprastas užklausas. Įtraukite greito įterpimo ir duomenų išgavimo bandymus, ypač kai sistema naudoja įrankius arba nuskaito turinį. Pagrįstas darbo eiga yra tokia: apibrėžkite politikos taisykles, sukurkite bandymų raginimų rinkinį, įvertinkite jį atlikdami žmonių ir automatizuotus patikrinimus ir paleiskite jį iš naujo, kai pasikeičia raginimai, duomenys ar politikos. Nuoseklumas yra jūsų mokama nuoma.
Dirbtinio intelekto modelių diegimas ir stebėjimas po paleidimo, siekiant aptikti nukrypimus ir incidentus
Naudokite etapinio diegimo modelius, tokius kaip šešėlinis režimas ir laipsniškas srauto didinimas, kad aptiktumėte gedimus anksčiau, nei tai padarys visa jūsų naudotojų bazė. Stebėkite įvesties poslinkį (schemos pakeitimus, trūkumus, paskirstymo poslinkius) ir išvesties poslinkį (balų poslinkius, klasių balanso poslinkius), taip pat veiklos būklę, pvz., delsą ir kainą. Stebėkite grįžtamojo ryšio signalus, tokius kaip redagavimai, eskalavimai ir skundai, ir stebėkite segmentų lygio regresijas. Kai kas nors pasikeičia, iš naujo paleiskite tą patį diegimą ir nuolat stebėkite.
Nuorodos
[1] NIST – Dirbtinio intelekto rizikos valdymo sistema (AI RMF 1.0) (PDF)
[2] Mitchell ir kt. – „Modelių kortelės modelių ataskaitoms“ (arXiv:1810.03993)
[3] Gebru ir kt. – „Duomenų rinkinių duomenų lapai“ (arXiv:1803.09010)
[4] scikit-learn – „Modelių parinkimo ir vertinimo“ dokumentacija
[5] Liang ir kt. – „Holistinis kalbos modelių vertinimas“ (arXiv:2211.09110)