Īsa atbilde: Lai labi novērtētu mākslīgā intelekta modeļus, vispirms definējiet, kā “labs” izskatās reālajam lietotājam un attiecīgajam lēmumam. Pēc tam izveidojiet atkārtojamus novērtējumus ar reprezentatīviem datiem, stingru noplūdes kontroli un vairākiem rādītājiem. Pievienojiet stresa, neobjektivitātes un drošības pārbaudes, un ikreiz, kad kaut kas mainās (dati, uzvednes, politika), atkārtoti palaidiet iejūgu un turpiniet uzraudzību pēc palaišanas.
Galvenie secinājumi:
Veiksmes kritēriji : pirms metriku izvēles definējiet lietotājus, lēmumus, ierobežojumus un sliktākā gadījuma kļūmes.
Atkārtojamība : Izveidojiet novērtēšanas sistēmu, kas atkārtoti veic salīdzināmus testus ar katru izmaiņu.
Datu higiēna : saglabājiet stabilus sadalījumus, novērsiet dublikātus un bloķējiet funkciju noplūdi agrīnā stadijā.
Uzticības pārbaudes : stresa testu stabilitāte, taisnīguma šķēles un LLM drošības uzvedība ar skaidrām rubrikām.
Dzīves cikla disciplīna : Ieviest pakāpeniski, uzraudzīt novirzes un incidentus, kā arī dokumentēt zināmās nepilnības.
Raksti, kurus jūs varētu vēlēties izlasīt pēc šī raksta:
🔗 Kas ir mākslīgā intelekta ētika?
Izpētiet principus, kas vada atbildīgu mākslīgā intelekta izstrādi, izmantošanu un pārvaldību.
🔗 Kas ir mākslīgā intelekta aizspriedumi
Uzziniet, kā neobjektīvi dati ietekmē mākslīgā intelekta lēmumus un rezultātus.
🔗 Kas ir mākslīgā intelekta mērogojamība
Izprotiet mākslīgā intelekta sistēmu mērogošanu veiktspējas, izmaksu un uzticamības ziņā.
🔗 Kas ir mākslīgais intelekts
Skaidrs pārskats par mākslīgo intelektu, tā veidiem un pielietojumu reālajā pasaulē.
1) Sāciet ar nepievilcīgu “labā” definīciju
Pirms metrikas, pirms informācijas paneļiem, pirms jebkādas etalonu maiņas — izlemiet, kā izskatās panākumi.
Precizēt:
-
Lietotājs: iekšējais analītiķis, klients, klīnicists, autovadītājs, noguris atbalsta dienesta darbinieks pulksten 16:00…
-
Lēmums: apstiprināt aizdevumu, atzīmēt krāpšanu, ieteikt saturu, apkopot piezīmes
-
Svarīgākās neveiksmes:
-
Viltus pozitīvi (kaitinoši) pret viltus negatīviem (bīstamiem)
-
-
Ierobežojumi: latentums, izmaksas par pieprasījumu, privātuma noteikumi, izskaidrojamības prasības, pieejamība
Šajā posmā komandas sāk optimizēties, lai sasniegtu “skaistas metrikas”, nevis “jēgpilnu rezultātu”. Tas notiek bieži. Patiesībā… ļoti bieži.
Stabils veids, kā apzināties riskus (nevis balstīties uz sajūtām), ir veidot testēšanas pamatu uzticamībai un dzīves cikla risku pārvaldībai, tāpat kā NIST to dara mākslīgā intelekta risku pārvaldības ietvarā (AI RMF 1.0) [1].
2) Kas veido labu versiju par tēmu “kā testēt mākslīgā intelekta modeļus” ✅
Stabilai testēšanas pieejai ir daži neapspriežami aspekti:
-
Reprezentatīvi dati (ne tikai tīras laboratorijas dati)
-
Skaidras spraugas ar noplūdes novēršanu (vairāk par to pēc sekundes)
-
Bāzes līnijas (vienkārši modeļi, kurus vajadzētu pārspēt — fiktīvi novērtējumi pastāv kāda iemesla dēļ [4])
-
Vairāki rādītāji (jo viens skaitlis jums melo, pieklājīgi, jūsu acīs)
-
Stresa testi (problēmas gadījumi, neparasti ievades dati, pretrunīgi scenāriji)
-
Cilvēka pārskatīšanas cikli (īpaši ģeneratīvajiem modeļiem)
-
Uzraudzība pēc palaišanas (jo pasaule mainās, cauruļvadi pārtrūkst un lietotāji ir… radoši [1])
Tāpat: laba pieeja ietver testētās informācijas, netestētās informācijas un uztraukuma dokumentēšanu. Sadaļa “par ko es uztraucos” šķiet neveikla, un tieši tur sāk veidoties uzticēšanās.
Divi dokumentācijas modeļi, kas pastāvīgi palīdz komandām saglabāt atklātību:
-
Modeļu kartītes (kam paredzēts modelis, kā tas tika novērtēts, kur tas neizdodas) [2]
-
Datu kopu datu lapas (kas ir dati, kā tie tika apkopoti, kam tie jāizmanto/nevajadzētu tikt izmantoti) [3]
3) Rīku realitāte: ko cilvēki izmanto praksē 🧰
Rīki ir izvēles. Labi vērtēšanas paradumi nav.
Ja vēlaties pragmatisku iestatījumu, lielākajai daļai komandu ir trīs segmenti:
-
Eksperimentu izsekošana (izpildes, konfigurācijas, artefakti)
-
Novērtēšanas ietvars (atkārtojami bezsaistes testi + regresijas komplekti)
-
Uzraudzība (dreifējoši signāli, veiktspējas starpniekserveri, incidentu brīdinājumi)
Piemēri, ko jūs daudz redzēsiet dabā (nevis ieteikumi, un jā - funkciju/cenu izmaiņas): MLflow, Weights & Biases, Great Expectations, Evidently, Deepchecks, OpenAI Evals, TruLens, LangSmith.
no šīs sadaļas izvēlaties tikai vienu ideju izveidojiet atkārtojamu novērtēšanas sistēmu . Jūs vēlaties “nospiest pogu → iegūt salīdzināmus rezultātus”, nevis “atkārtoti palaist piezīmju grāmatiņu un lūgties”.
4) Izveidojiet pareizo testu komplektu (un apturiet datu noplūdi) 🚧
Šokējoši daudz "apbrīnojamu" modeļu nejauši krāpjas.
Standarta ML
Daži neseksīgi noteikumi, kas glābj karjeru:
-
Saglabājiet vilciena/validācijas/testa sadalījumu stabilitāti (un pierakstiet sadalījuma loģiku)
-
Novērst dublikātus dažādos sadalījumos (tas pats lietotājs, tas pats dokuments, tas pats produkts, gandrīz dublikāti)
-
Uzmanieties no funkciju noplūdes (nākotnes informācija iekļūst “pašreizējās” funkcijās)
-
Izmantojiet bāzes līnijas (fiktīvus novērtējumus), lai nesvinētu uzvaru… neko [4]
Noplūdes definīcija (īsā versija): jebkas apmācības/novērtēšanas procesā, kas modelim dod piekļuvi informācijai, kuras tam nebūtu lēmuma pieņemšanas brīdī. Tas var būt acīmredzams (“nākotnes etiķete”) vai nemanāms (“pēcnotikuma laika zīmoga intervāls”).
LLM un ģeneratīvajiem modeļiem
Jūs veidojat norādījumu un politikas sistēmu , nevis tikai “modeli”.
-
Izveidojiet zelta uzdevumu komplektu (mazu, augstas kvalitātes, stabilu)
-
Pievienot nesenus reālus paraugus (anonimizētus + privātuma ziņā drošus)
-
Saglabājiet āķīgu sarakstu : drukas kļūdas, slengs, nestandarta formatējums, tukšas ievades vietas, daudzvalodu pārsteigumi 🌍
Praktiska lieta, ko esmu novērojis vairāk nekā vienu reizi: komanda nosūta pieteikumu ar “spēcīgu” bezsaistes vērtējumu, pēc tam klientu atbalsta dienests saka: “Forši. Tajā pārliecinoši trūkst viena svarīga teikuma.” Labojums nebija “lielāks modelis”. Tā bija labākas testa uzvednes , skaidrākas rubrikas un regresijas komplekts, kas sodīja tieši šo kļūmes veidu. Vienkārši. Efektīvi.
5) Bezsaistes novērtēšana: metrikas, kurām ir nozīme 📏
Metrika ir pieņemama. Metriskā monokultūra nav pieņemama.
Klasifikācija (surogātpasts, krāpšana, nodoms, triāža)
Izmantojiet vairāk nekā tikai precizitāti.
-
Precizitāte, atcerēšanās, F1
-
Sliekšņa regulēšana (jūsu noklusējuma slieksnis reti kad ir “pareizs” jūsu izmaksām) [4]
-
Apjukuma matricas pa segmentiem (reģions, ierīces tips, lietotāju kohorta)
Regresija (prognozēšana, cenu noteikšana, vērtēšana)
-
MAE / RMSE (izvēlieties, pamatojoties uz to, kā vēlaties sodīt kļūdas)
-
Kalibrēšanas pārbaudes, kad rezultāti tiek izmantoti kā “rādītāji” (vai rādītāji atbilst realitātei?)
Ranžēšanas/ieteikšanas sistēmas
-
NDCG, MAP, MRR
-
Sagriezt pēc vaicājuma veida (galva vai aste)
Datorredze
-
mAP, IoU
-
Veiktspēja katrā klasē (retās klasēs modeļi jūs samulsina)
Ģeneratīvie modeļi (LLM)
Šeit cilvēki sāk… filozofēt 😵💫
Praktiskas iespējas, kas darbojas reālās komandās:
-
Cilvēka vērtējums (labākais signāls, lēnākā cilpa)
-
Pāru preference/uzvaras koeficients (A pret B ir vieglāk nekā absolūtā punktu skaitīšana)
-
Automatizēta teksta metrika (noderīga dažiem uzdevumiem, maldinoša citiem)
-
Uzdevumos balstītas pārbaudes: “Vai tika iegūti pareizie lauki?” “Vai tika ievērota politika?” “Vai tika citēti avoti, kad tas bija nepieciešams?”
Ja vēlaties strukturētu “daudzmetrisku, daudzscenāriju” atskaites punktu, HELM ir labs enkurs: tas nepārprotami virza novērtēšanu tālāk par precizitāti uz tādām lietām kā kalibrēšana, robustums, neobjektivitāte/toksicitāte un efektivitātes kompromisi [5].
Neliela atkāpe: automatizēti rakstīšanas kvalitātes rādītāji dažreiz šķiet kā sviestmaizes vērtēšana, to nosverot. Tā jau nekas nav, bet... nudien 🥪
6) Izturības pārbaude: nedaudz jāpacenšas 🥵🧪
Ja jūsu modelis darbojas tikai ar sakārtotiem ievades datiem, tā būtībā ir stikla vāze. Skaista, trausla, dārga.
Tests:
-
Troksnis: drukas kļūdas, trūkstošas vērtības, nestandarta unikods, formatēšanas kļūmes
-
Izplatīšanas maiņa: jaunas produktu kategorijas, jauns slengs, jauni sensori
-
Ekstrēmās vērtības: skaitļi ārpus diapazona, milzīgas lietderīgās slodzes, tukšas virknes
-
“Pretinieciskas” ievades, kas neizskatās pēc jūsu apmācības kopas, bet izskatās pēc lietotājiem
LLM grāda iegūšanai iekļaujiet:
-
Ātras injekcijas mēģinājumi (instrukcijas paslēptas lietotāja saturā)
-
“Ignorēt iepriekšējos norādījumus” modeļi
-
Rīku lietošanas robežgadījumi (nederīgi URL, taimauti, daļēja izvade)
Stabilitāte ir viena no tām uzticamības īpašībām, kas izklausās abstrakta, līdz rodas incidenti. Tad tā kļūst… ļoti taustāma [1].
7) Aizspriedumi, taisnīgums un kam tas der ⚖️
Modelis kopumā var būt “precīzs”, bet noteiktām grupām pastāvīgi sliktāks. Tā nav maza kļūda. Tā ir produkta un uzticēšanās problēma.
Praktiski soļi:
-
Novērtēt sniegumu pa nozīmīgiem segmentiem (juridiski/ētiski atbilstoši mērīšanai)
-
Salīdziniet kļūdu līmeni un kalibrēšanu dažādās grupās
-
Pārbaudiet starpniekservera funkcijas (pasta indeksu, ierīces tipu, valodu), kas var kodēt sensitīvas pazīmes
Ja jūs to kaut kur nedokumentējat, jūs būtībā lūdzat nākotnes jums novērst uzticības krīzi bez kartes. Modeļu kartes ir labs veids, kā to ievietot [2], un NIST uzticamības ietvars sniedz jums stabilu kontrolsarakstu par to, kas vispār jāiekļauj “labā” jēdzienā [1].
8) Drošības un aizsardzības testi (īpaši LLM studentiem) 🛡️
Ja jūsu modelis var ģenerēt saturu, jūs testējat ne tikai precizitāti. Jūs testējat uzvedību.
Iekļaut testus:
-
Neatļauta satura ģenerēšana (politikas pārkāpumi)
-
Privātuma noplūde (vai tā atspoguļo noslēpumus?)
-
Halucinācijas augsta riska jomās
-
Pārmērīga atteikšanās (modelis noraida parastus pieprasījumus)
-
Toksicitātes un uzmākšanās rezultāti
-
Datu eksfiltrācijas mēģinājumi, izmantojot tūlītēju injekciju
Pamatota pieeja ir šāda: definēt politikas noteikumus → veidot testa uzvednes → novērtēt rezultātus ar cilvēku un automatizētām pārbaudēm → palaist to katru reizi, kad kaut kas mainās. Šī “katras reizes” daļa ir īres maksa.
Tas lieliski iederas dzīves cikla riska domāšanas veidā: pārvaldīt, kartēt kontekstu, mērīt, pārvaldīt, atkārtot [1].
9) Tiešsaistes testēšana: pakāpeniska ieviešana (tur, kur mīt patiesība) 🚀
Bezsaistes testi ir nepieciešami. Tiešsaistes iedarbība ir vieta, kur realitāte parādās dubļainās kurpēs.
Tev nav jābūt izdomīgam. Tev tikai jābūt disciplinētam:
-
Palaist ēnu režīmā (modelis darbojas, neietekmē lietotājus)
-
Pakāpeniska ieviešana (vispirms neliela datplūsma, paplašiniet, ja tā ir aktīva)
-
Izsekojiet rezultātus un incidentus (sūdzības, eskalācijas, politikas nepilnības)
Pat ja nevarat iegūt tūlītējas etiķetes, varat uzraudzīt starpniekservera signālus un darbības stāvokli (latentumu, kļūmju līmeni, izmaksas). Galvenais: jums ir nepieciešams kontrolēts veids, kā atklāt kļūmes, pirms to dara visa jūsu lietotāju bāze [1].
10) Uzraudzība pēc izvietošanas: nobīde, sabrukšana un klusa kļūme 📉👀
Modelis, kuru testējāt, nav tas modelis, ar kuru galu galā dzīvosiet. Dati mainās. Lietotāji mainās. Pasaule mainās. Cauruļvads pārstāj darboties pulksten 2 naktī. Jūs zināt, kā tas ir…
Monitors:
-
Ievades datu novirze (shēmas izmaiņas, trūkums, sadalījuma nobīdes)
-
Rezultātu novirzes (klases bilances nobīdes, rezultātu nobīdes)
-
Veiktspējas starpniekserveri (jo etiķešu kavējumi ir reāli)
-
Atsauksmju signāli (nepatīk, atkārtota rediģēšana, eskalācija)
-
Segmentu līmeņa regresijas (klusie slepkavas)
Un iestatiet trauksmes sliekšņus, kas nav pārāk saraustīti. Monitors, kas pastāvīgi kliedz, tiek ignorēts — kā automašīnas signalizācija pilsētā.
Šis “uzraudzības + uzlabošanas” cikls nav obligāts, ja jums rūp uzticamība [1].
11) Praktiska darbplūsma, ko varat kopēt 🧩
Šeit ir vienkārša cilpa, kas mērogojas:
-
Definēt veiksmes un neveiksmes režīmus (ietverot izmaksas/latentumu/drošību) [1]
-
Izveidojiet datu kopas:
-
zelta komplekts
-
malas soma
-
nesen reāli paraugi (droši privātuma aizsardzībai)
-
-
Izvēlieties rādītājus:
-
uzdevumu metrikas (F1, MAE, uzvaru procents) [4][5]
-
drošības rādītāji (politikas pieņemšanas līmenis) [1][5]
-
darbības rādītāji (latentums, izmaksas)
-
-
Izveidojiet novērtēšanas sistēmu (darbojas katrā modeļa/uzvednes maiņā) [4][5]
-
Pievienot stresa testus + pretinieku testus [1][5]
-
Cilvēka veikta parauga pārskatīšana (īpaši LLM rezultātu gadījumā) [5]
-
Piegāde, izmantojot ēnu versiju + pakāpeniska ieviešana [1]
-
Uzraudzība + brīdināšana + pārkvalificēšana ar disciplīnu [1]
-
Dokumenta rezultāti tiek apkopoti modeļa kartes stila aprakstā [2][3]
Apmācība ir glauns. Testēšana ir dārga.
12) Noslēguma piezīmes + īss kopsavilkums 🧠✨
Ja atceraties tikai dažas lietas par mākslīgā intelekta modeļu testēšanu :
-
Izmantojiet reprezentatīvus testa datus un izvairieties no noplūdēm [4]
-
Izvēlieties vairākus rādītājus, kas saistīti ar reāliem rezultātiem [4][5]
-
LLM studentiem jāizmanto cilvēku veikta pārbaude un salīdzinājumi, kas balstīti uz uzvaru procentuālo daļu [5].
-
Testa robustums — neparastas ievades vērtības ir maskētas normālas ievades vērtības [1]
-
Droši izrullējiet un uzraugiet, jo modeļi dreifē un cauruļvadi pārtrūkst [1]
-
Dokumentējiet, ko testējāt un ko nepārbaudījāt (neērti, bet efektīvi) [2][3]
Testēšana nav tikai "pierādīt, ka tas darbojas". Tā ir "noskaidrot, kāpēc tas neizdodas, pirms to dara jūsu lietotāji". Un jā, tas nav tik pievilcīgi, bet tā ir tā daļa, kas notur jūsu sistēmu stāvoklī, kad lietas kļūst nestabilas... 🧱🙂
Bieži uzdotie jautājumi
Labākais veids, kā testēt mākslīgā intelekta modeļus, lai tie atbilstu reālajām lietotāju vajadzībām
Sāciet, definējot “labu” attiecībā uz reālo lietotāju un lēmumu, ko modelis atbalsta, nevis tikai uz līderu saraksta metriku. Nosakiet visdārgākos kļūmes režīmus (viltus pozitīvi pret viltus negatīviem) un precizējiet stingrus ierobežojumus, piemēram, latentumu, izmaksas, privātumu un izskaidrojamību. Pēc tam izvēlieties metrikas un testa gadījumus, kas atspoguļo šos rezultātus. Tas neļauj optimizēt “skaistu metriku”, kas nekad nepārvēršas labākā produktā.
Veiksmes kritēriju definēšana pirms novērtēšanas rādītāju izvēles
Pierakstiet, kas ir lietotājs, kādu lēmumu modelim ir paredzēts atbalstīt un kā izskatās “sliktākā gadījuma kļūme” ražošanas vidē. Pievienojiet darbības ierobežojumus, piemēram, pieņemamu latentumu un izmaksas par pieprasījumu, kā arī pārvaldības vajadzības, piemēram, privātuma noteikumus un drošības politikas. Kad tie ir skaidri, metrika kļūst par veidu, kā izmērīt pareizo lietu. Bez šīs struktūras komandas mēdz virzīties uz to, lai optimizētu to, ko ir visvieglāk izmērīt.
Datu noplūdes un nejaušas krāpšanās novēršana modeļu novērtēšanā
Saglabājiet apmācības/validācijas/testēšanas sadalījumu stabilitāti un dokumentējiet sadalījuma loģiku, lai rezultāti būtu reproducējami. Aktīvi bloķējiet dublikātus un gandrīz dublikātus dažādos sadalījumos (tas pats lietotājs, dokuments, produkts vai atkārtoti modeļi). Pievērsiet uzmanību funkciju noplūdei, kur “nākotnes” informācija ieslīd ievaddatos, izmantojot laika zīmogus vai notikuma laukus. Spēcīga bāzes līnija (pat fiktīvi novērtējumi) palīdz pamanīt, kad jūs atzīmējat troksni.
Kas jāiekļauj novērtēšanas sistēmā, lai testi būtu atkārtojami pēc izmaiņām
Praktiska sistēma atkārtoti veic salīdzināmus testus katram modelim, uzvednei vai politikas izmaiņām, izmantojot tos pašus datu kopumus un vērtēšanas noteikumus. Tā parasti ietver regresijas komplektu, skaidrus metriku informācijas paneļus un saglabātas konfigurācijas un artefaktus izsekojamības nodrošināšanai. LLM sistēmām ir nepieciešams arī stabils uzvedņu “zelta komplekts”, kā arī perifēro gadījumu pakotne. Mērķis ir “nospiest pogu → salīdzināmi rezultāti”, nevis “atkārtoti palaist piezīmju grāmatiņu un lūgties”
Mākslīgā intelekta modeļu testēšanas rādītāji, kas pārsniedz precizitāti
Izmantojiet vairākus rādītājus, jo viens skaitlis var slēpt svarīgus kompromisus. Klasifikācijai apvienojiet precizitātes/atgādināšanas/F1 ar sliekšņa regulēšanas un apjukuma matricām pa segmentiem. Regresijai izvēlieties MAE vai RMSE, pamatojoties uz to, kā vēlaties sodīt kļūdas, un pievienojiet kalibrēšanas stila pārbaudes, ja izvades dati darbojas kā rezultāti. Ranžēšanai izmantojiet NDCG/MAP/MRR un šķēles pēc sākuma un beigu vaicājumiem, lai noteiktu nevienmērīgu veiktspēju.
LLM rezultātu novērtēšana, ja automatizētie rādītāji ir nepietiekami
Uztveriet to kā uzvedņu un politikas sistēmu un novērtējiet uzvedību, ne tikai teksta līdzību. Daudzas komandas apvieno cilvēka novērtējumu ar pāru preferenci (A/B uzvaru īpatsvars), kā arī uz uzdevumiem balstītas pārbaudes, piemēram, "vai tas izvilka pareizos laukus" vai "vai tas atbilda politikai". Automatizētas teksta metrikas var palīdzēt šauros gadījumos, taču tās bieži vien nepamana to, kas lietotājiem rūp. Skaidras rubrikas un regresijas komplekts parasti ir svarīgāki par vienu vērtējumu.
Robustuma testi, kas jāveic, lai modelis nesabojātos trokšņainu ievades datu gadījumā
Veiciet modeļa stresa pārbaudi ar drukas kļūdām, trūkstošām vērtībām, dīvainu formatējumu un nestandarta unikodu, jo reāli lietotāji reti kad ir kārtīgi. Pievienojiet sadalījuma nobīdes gadījumus, piemēram, jaunas kategorijas, slengu, sensorus vai valodas modeļus. Iekļaujiet ekstremālas vērtības (tukšas virknes, milzīgas vērtības, ārpus diapazona esoši skaitļi), lai parādītu trauslo uzvedību. LLM gadījumā pārbaudiet arī uzvednes injekcijas modeļus un rīku lietošanas kļūmes, piemēram, taimautus vai daļēju izvadi.
Neobjektivitātes un taisnīguma problēmu pārbaude, neapmaldoties teorijā
Novērtējiet veiktspēju jēgpilnās šķēlēs un salīdziniet kļūdu līmeni un kalibrēšanu grupās, kurās to mērīšana ir juridiski un ētiski pamatota. Meklējiet starpniekservera funkcijas (piemēram, pasta indeksu, ierīces tipu vai valodu), kas var netieši kodēt sensitīvas pazīmes. Modelis var šķist "kopumā precīzs", bet noteiktām kohortām pastāvīgi neizdoties. Dokumentējiet, ko jūs mērījāt un ko ne, lai turpmākās izmaiņas nemanāmi neatkārtotu regresijas.
Ģeneratīvā mākslīgā intelekta un tiesību zinātņu vadības (LLM) sistēmām iekļaujamie drošības un aizsardzības testi
Pārbaudiet neatļautas satura ģenerēšanas, privātuma noplūdes, halucinācijas augsta riska jomās un pārmērīgu atteikumu, ja modelis bloķē parastus pieprasījumus. Iekļaujiet tūlītēju injekciju un datu eksfiltrācijas mēģinājumus, īpaši, ja sistēma izmanto rīkus vai izgūst saturu. Pamatota darbplūsma ir: definējiet politikas noteikumus, izveidojiet testa uzvedņu kopu, novērtējiet ar cilvēku un automatizētām pārbaudēm un atkārtojiet to ikreiz, kad mainās uzvednes, dati vai politikas. Konsekvence ir jūsu maksātā īre.
AI modeļu ieviešana un uzraudzība pēc palaišanas, lai pamanītu novirzes un incidentus
Izmantojiet pakāpeniskas ieviešanas modeļus, piemēram, ēnu režīmu un pakāpenisku datplūsmas palielināšanu, lai atrastu kļūmes, pirms to dara visa lietotāju bāze. Uzraugiet ievades novirzes (shēmas izmaiņas, trūkumus, sadalījuma novirzes) un izvades novirzes (rezultātu novirzes, klases līdzsvara novirzes), kā arī darbības stāvokli, piemēram, latentumu un izmaksas. Izsekojiet atgriezeniskās saites signālus, piemēram, labojumus, eskalācijas un sūdzības, un vērojiet segmentu līmeņa regresijas. Ja kaut kas mainās, atkārtoti palaidiet to pašu komplektu un nepārtraukti turpiniet uzraudzību.
Atsauces
[1] NIST — Mākslīgā intelekta riska pārvaldības ietvars (AI RMF 1.0) (PDF)
[2] Mitchell et al. — “Modeļu kartes modeļu ziņošanai” (arXiv:1810.03993)
[3] Gebru et al. — “Datu lapas datu kopām” (arXiv:1803.09010)
[4] scikit-learn — dokumentācija “Modeļu atlase un novērtēšana”
[5] Liang et al. — “Valodu modeļu holistiskā novērtēšana” (arXiv:2211.09110)