Përgjigje e shkurtër: Për të vlerësuar mirë modelet e IA-së, filloni duke përcaktuar se si duket "e mirë" për përdoruesin real dhe vendimin në fjalë. Pastaj ndërtoni vlerësime të përsëritshme me të dhëna përfaqësuese, kontrolle të rrepta të rrjedhjeve dhe metrika të shumëfishta. Shtoni kontrolle të stresit, paragjykimeve dhe sigurisë, dhe sa herë që ndryshon diçka (të dhëna, kërkesa, politika), rifilloni programin dhe vazhdoni monitorimin pas lançimit.
Përmbledhjet kryesore:
Kriteret e suksesit : Përcaktoni përdoruesit, vendimet, kufizimet dhe dështimet më të këqija përpara se të zgjidhni metrikat.
Përsëritshmëria : Ndërtoni një sistem vlerësimi që përsërit teste të krahasueshme me çdo ndryshim.
Higjiena e të dhënave : Mbani ndarje të qëndrueshme, parandaloni dublikimet dhe bllokoni rrjedhjen e veçorive herët.
Kontrollet e besimit : Qëndrueshmëria e testeve të stresit, prerjet e drejtësisë dhe sjelljet e sigurisë së LLM me rubrika të qarta.
Disiplina e ciklit jetësor : Zbatohet në faza, monitorohen devijimet dhe incidentet, dhe dokumentohen boshllëqet e njohura.
Artikuj që mund t'ju pëlqejnë të lexoni pas këtij:
🔗 Çfarë është etika e inteligjencës artificiale
Eksploroni parimet që udhëheqin projektimin, përdorimin dhe qeverisjen e përgjegjshme të IA-së.
🔗 Çfarë është paragjykimi i inteligjencës artificiale
Mësoni se si të dhënat e anshme shtrembërojnë vendimet dhe rezultatet e inteligjencës artificiale.
🔗 Çfarë është shkallëzueshmëria e IA-së
Kuptoni shkallëzimin e sistemeve të IA-së për performancë, kosto dhe besueshmëri.
🔗 Çfarë është inteligjenca artificiale
Një pasqyrë e qartë e inteligjencës artificiale, llojeve dhe përdorimeve në botën reale.
1) Filloni me përkufizimin jo tërheqës të "mirë"
Përpara metrikave, para paneleve të kontrollit, para çdo ndryshimi në pikën e referimit - vendosni se si duket suksesi.
Sqaroni:
-
Përdoruesi: analist i brendshëm, klient, klinicist, shofer, një agjent mbështetës i lodhur në orën 16:00…
-
Vendimi: miratoni kredinë, raportoni mashtrimin, sugjeroni përmbajtje, përmbledhni shënimet
-
Dështimet që kanë më shumë rëndësi:
-
Pozitivë të rremë (bezdisës) kundrejt negativëve të rremë (të rrezikshëm)
-
-
Kufizimet: vonesa, kostoja për kërkesë, rregullat e privatësisë, kërkesat e shpjegueshmërisë, aksesueshmëria
Kjo është pjesa ku ekipet kalojnë në optimizimin për "metrikë mjaft të mirë" në vend të "rezultatit kuptimplotë". Ndodh shpesh. Si… shpesh.
Një mënyrë e mirë për ta mbajtur këtë të vetëdijshëm për rrezikun (dhe jo të bazuar në sinjale) është të strukturohet testimi rreth besueshmërisë dhe menaxhimit të rrezikut të ciklit jetësor, ashtu siç bën NIST në Kornizën e Menaxhimit të Riskut të IA-së (AI RMF 1.0) [1].
2) Çfarë e bën një version të mirë të “si të testohen modelet e IA-së” ✅
Një qasje e fortë testimi ka disa aspekte të panegociueshme:
-
Të dhëna përfaqësuese (jo vetëm të dhëna të pastra laboratorike)
-
Çarje të qarta me parandalim të rrjedhjeve (më shumë për këtë në një sekondë)
-
Vijat bazë (modele të thjeshta që duhet t’i tejkaloni - vlerësuesit artificialë ekzistojnë për një arsye [4])
-
Metrika të shumëfishta (sepse një numër të gënjen, me mirësjellje, në fytyrë)
-
Testet e stresit (raste të skajshme, të dhëna të pazakonta, skenarë të tipit kundërshtarë)
-
Cikle shqyrtimi njerëzor (veçanërisht për modelet gjeneruese)
-
Monitorimi pas lançimit (sepse bota ndryshon, kanalet prishen dhe përdoruesit janë… krijues [1])
Gjithashtu: një qasje e mirë përfshin dokumentimin e asaj që keni testuar, asaj që nuk e keni testuar dhe asaj për të cilën jeni nervoz. Seksioni "për çfarë jam nervoz" ndihet i çuditshëm - dhe është gjithashtu vendi ku fillon të grumbullohet besimi.
Dy modele dokumentimi që vazhdimisht i ndihmojnë ekipet të qëndrojnë të sinqertë:
-
Kartat e Modelit (për çfarë shërben modeli, si u vlerësua, ku dështon) [2]
-
Fletë të dhënash për grupet e të dhënave (çfarë janë të dhënat, si u mblodhën, për çfarë duhet/nuk duhet të përdoren) [3]
3) Realiteti i mjeteve: çfarë përdorin njerëzit në praktikë 🧰
Mjetet janë opsionale. Zakonet e mira të vlerësimit nuk janë.
Nëse dëshironi një konfigurim pragmatik, shumica e ekipeve përfundojnë me tre kova:
-
Gjurmimi i eksperimenteve (ekzekutimet, konfigurimet, artefaktet)
-
Pajisje vlerësimi (teste të përsëritshme jashtë linje + suita regresioni)
-
Monitorimi (sinjale të devijuara, sinjale të performancës, alarme për incidente)
Shembuj që do të shihni shumë në treg (jo miratime, dhe po - ndryshime në veçori/çmime): MLflow, Weights & Biases, Great Expectations, Evidently, Deepchecks, OpenAI Evals, TruLens, LangSmith.
Nëse zgjidhni vetëm një ide nga kjo pjesë: ndërtoni një sistem vlerësimi të përsëritshëm . Ju dëshironi "shtypni butonin → merrni rezultate të krahasueshme", jo "rihapni fletoren dhe lutuni".
4) Ndërtoni setin e duhur të testimit (dhe ndaloni rrjedhjen e të dhënave) 🚧
Një numër tronditës modelesh “të mrekullueshme” po mashtrojnë aksidentalisht.
Për ML standarde
Disa rregulla jo seksi që shpëtojnë karriera:
-
Mbajini e trajnimit/validimit/testit (dhe shkruani logjikën e ndarjes)
-
Parandaloni dublikimet nëpër ndarje (i njëjti përdorues, i njëjti dokument, i njëjti produkt, pothuajse dublikate)
-
Shikoni për rrjedhje të veçorive (informacion i ardhshëm që futet fshehurazi në veçoritë "aktuale")
-
Përdorni vija bazë (vlerësues artificialë) në mënyrë që të mos festoni fitoren… asgjë [4]
Përkufizimi i rrjedhjes (versioni i shpejtë): çdo gjë në trajnim/vlerësim që i jep modelit qasje në informacion që nuk do ta kishte në kohën e vendimmarrjes. Mund të jetë e dukshme ("etiketë e ardhshme") ose delikate ("kova e vulës kohore pas ngjarjes").
Për LLM dhe modele gjenerative
Po ndërtoni një sistem të shpejtë dhe të politikave , jo vetëm “një model”.
-
Krijo një grup të artë sugjerimesh (të vogla, me cilësi të lartë, të qëndrueshme)
-
Shtoni mostra të vërteta të kohëve të fundit (të anonimizuara + të sigurta për privatësinë)
-
Mbani një paketë me shkronja të mëdha dhe të mëdha : gabime shtypi, zhargon, formatim jo standard, hyrje boshe, surpriza shumëgjuhëshe 🌍
Një gjë praktike që e kam parë të ndodhë më shumë se një herë: një ekip del me një rezultat "të fortë" jashtë linje, pastaj mbështetja e klientëve thotë: "Shumë mirë. Po i mungon me bindje fjalia e vetme që ka rëndësi." Zgjidhja nuk ishte "model më i madh". Ishte kërkesa më të mira testimi , rubrika më të qarta dhe një suitë regresioni që ndëshkonte pikërisht atë mënyrë dështimi. E thjeshtë. Efektive.
5) Vlerësimi jashtë linje: metrika që kanë rëndësi 📏
Metrikat janë në rregull. Monokultura metrike jo.
Klasifikimi (spam, mashtrim, qëllim, triazh)
Përdorni më shumë sesa saktësi.
-
Precizion, kujtesë, F1
-
Akordimi i pragut (pragu juaj i paracaktuar rrallë është "i saktë" për kostot tuaja) [4]
-
Matricat e konfuzionit për segment (rajoni, lloji i pajisjes, grupi i përdoruesve)
Regresioni (parashikimi, çmimi, vënia e pikëve)
-
MAE / RMSE (zgjidhni bazuar në mënyrën se si dëshironi të ndëshkoni gabimet)
-
Kontrolle të tipit kalibrim kur rezultatet përdoren si "pikë" (a përputhen rezultatet me realitetin?)
Sistemet e renditjes/rekomandimit
-
NDCG, MAP, MRR
-
Prerje sipas llojit të pyetjes (koka kundrejt bishtit)
Vizioni kompjuterik
-
mAP, IoU
-
Performancë për klasë (klasat e rralla janë ato ku modelet të turpërojnë)
Modelet gjenerative (LLM)
Këtu njerëzit fillojnë… filozofikisht 😵💫
Opsione praktike që funksionojnë në ekipe reale:
-
Vlerësimi njerëzor (sinjali më i mirë, cikli më i ngadaltë)
-
Preferenca në çifte / shkalla e fitores (A vs B është më e lehtë sesa vlerësimi absolut i pikëve)
-
Metrika të automatizuara të tekstit (të dobishme për disa detyra, mashtruese për të tjerat)
-
Kontrollet e bazuara në detyra: “A nxori fushat e duhura?” “A e ndoqi politikën?” “A citoi burimet kur kërkohej?”
Nëse dëshironi një pikë referimi të strukturuar "multimetrike, me shumë skenarë", HELM është një spirancë e mirë: ai e shtyn në mënyrë të qartë vlerësimin përtej saktësisë në gjëra të tilla si kalibrimi, qëndrueshmëria, paragjykimi/toksiciteti dhe kompromiset e efikasitetit [5].
Një shmangie e vogël: metrikat e automatizuara për cilësinë e shkrimit ndonjëherë duken si të gjykosh një sanduiç duke e peshuar. Nuk është asgjë, por… hajde 🥪
6) Testimi i qëndrueshmërisë: bëjeni të djersitet pak 🥵🧪
Nëse modeli juaj funksionon vetëm me hyrje të rregullta, është në thelb një vazo qelqi. E bukur, e brishtë, e shtrenjtë.
Test:
-
Zhurmë: gabime shtypi, vlera që mungojnë, unikode jo standarde, probleme me formatimin
-
Ndryshimi i shpërndarjes: kategori të reja produktesh, zhargon i ri, sensorë të rinj
-
Vlera ekstreme: numra jashtë diapazonit, ngarkesa gjigante, vargje boshe
-
Të dhëna "kontradiktore" që nuk duken si grupi juaj i trajnimit, por duken si përdorues
Për LLM-të, përfshini:
-
Përpjekje të shpejta për injeksion (udhëzime të fshehura brenda përmbajtjes së përdoruesit)
-
Modelet "Injoroni udhëzimet e mëparshme"
-
Rastet e përdorimit të mjetit (URL të gabuara, afate kohore, rezultate të pjesshme)
Qëndrueshmëria është një nga ato veti të besueshmërisë që tingëllon abstrakte derisa të keni incidente. Pastaj bëhet… shumë e prekshme [1].
7) Paragjykimi, drejtësia dhe për kë funksionon ⚖️
Një model mund të jetë “i saktë” në përgjithësi, ndërkohë që mund të jetë vazhdimisht më i keq për grupe specifike. Ky nuk është një defekt i vogël. Është një problem produkti dhe besimi.
Hapat praktikë:
-
Vlerësoni performancën sipas segmenteve kuptimplote (ligjërisht/etikisht të përshtatshme për t'u matur)
-
Krahasoni shkallët e gabimeve dhe kalibrimin midis grupeve
-
Testoni për veçoritë e ndërmjetësit (kodi postar, lloji i pajisjes, gjuha) që mund të kodojnë veçori të ndjeshme
Nëse nuk po e dokumentoni këtë diku, në thelb po i kërkoni të ardhmes suaj të debugoni një krizë besimi pa një hartë. Kartat Model janë një vend i fortë për ta vendosur atë [2], dhe korniza e besueshmërisë e NIST ju jep një listë të fortë kontrolli se çfarë duhet të përfshijë "e mira" [1].
8) Testimi i sigurisë dhe mbrojtjes (veçanërisht për LLM-të) 🛡️
Nëse modeli juaj mund të gjenerojë përmbajtje, ju po testoni më shumë sesa saktësi. Ju po testoni sjelljen.
Përfshi teste për:
-
Gjenerimi i përmbajtjes nuk lejohet (shkelje të politikave)
-
Rrjedhje e privatësisë (a pasqyron sekrete?)
-
Halucinacione në fusha me rrezik të lartë
-
Refuzim i tepërt (modeli refuzon kërkesat normale)
-
Rezultatet e toksicitetit dhe ngacmimit
-
Përpjekjet për nxjerrjen e të dhënave nëpërmjet injektimit të shpejtë
Një qasje e bazuar është: përcaktoni rregullat e politikave → ndërtoni kërkesa testimi → vlerësoni rezultatet me kontrolle njerëzore + automatike → ekzekutojeni sa herë që ndryshon diçka. Ajo pjesë "çdo herë" është qiraja.
Kjo përshtatet shumë mirë në një mentalitet rreziku të ciklit jetësor: qeveris, hartëzo kontekstin, mat, menaxho, përsërit [1].
9) Testimi online: shpërndarje në faza (ku jeton e vërteta) 🚀
Testet jashtë linje janë të nevojshme. Ekspozimi online është vendi ku realiteti shfaqet i veshur me këpucë me baltë.
Nuk ke pse të jesh i/e zbukuruar. Thjesht duhet të jesh i/e disiplinuar:
-
Ekzekutohet në modalitetin e hijes (modeli ekzekutohet, nuk ndikon te përdoruesit)
-
Zbatim gradual (fillimisht trafik i vogël, zgjerim nëse është i mirë)
-
Ndiqni rezultatet dhe incidentet (ankesat, përshkallëzimet, dështimet e politikave)
Edhe nëse nuk mund të merrni etiketa të menjëhershme, mund të monitoroni sinjalet e ndërmjetësit dhe gjendjen operative (latencën, shkallën e dështimeve, koston). Pika kryesore: ju dëshironi një mënyrë të kontrolluar për të zbuluar dështimet përpara se ta bëjë e gjithë baza juaj e përdoruesve [1].
10) Monitorimi pas vendosjes: devijim, prishje dhe dështim i qetë 📉👀
Modeli që testuat nuk është modeli me të cilin jetoni në fund. Të dhënat ndryshojnë. Përdoruesit ndryshojnë. Bota ndryshon. Tubacioni prishet në orën 2 të mëngjesit. E dini si është…
Monitor:
-
Zhvendosja e të dhënave hyrëse (ndryshime skemash, mungesa, zhvendosje shpërndarjeje)
-
Zhvendosja e prodhimit (zhvendosjet e balancës së klasës, zhvendosjet e rezultateve)
-
Përparësitë e performancës (sepse vonesat në etiketë janë reale)
-
Sinjalet e reagimit (gishtin e madh poshtë, ri-redaktimet, përshkallëzimet)
-
Regresionet në nivel segmenti (vrasësit e heshtur)
Dhe vendosni pragje alarmi që nuk janë shumë të dridhura. Një monitor që bërtet vazhdimisht injorohet - si një alarm makine në një qytet.
Ky cikël "monitorim + përmirësim me kalimin e kohës" nuk është opsional nëse ju intereson besueshmëria [1].
11) Një rrjedhë pune praktike që mund ta kopjoni 🧩
Ja një lak i thjeshtë që shkallëzohet:
-
Përcaktoni mënyrat e suksesit + dështimit (përfshini koston/latencën/sigurinë) [1]
-
Krijo grupe të dhënash:
-
set i artë
-
pako me mbulesë anësore
-
mostra të vërteta të kohëve të fundit (të sigurta për privatësinë)
-
-
Zgjidhni metrika:
-
metrika të detyrave (F1, MAE, shkalla e fitores) [4][5]
-
metrika të sigurisë (shkalla e kalueshmërisë së politikave) [1][5]
-
metrika operative (latenca, kostoja)
-
-
Ndërtoni një instalim vlerësimi (funksionon në çdo model/ndryshim të shpejtë) [4][5]
-
Shtoni teste stresi + teste me pak a shumë kundërshtare [1][5]
-
Rishikimi njerëzor për një mostër (veçanërisht për rezultatet e LLM) [5]
-
Dërgim nëpërmjet hijes + shpërndarje në faza [1]
-
Monitorim + alarm + ritrajnim me disiplinë [1]
-
Dokumenti rezulton në një përshkrim në stilin e një karte modeli [2][3]
Trajnimi është magjepsës. Testimi është i kotë.
12) Shënime përmbyllëse + përmbledhje e shpejtë 🧠✨
Nëse mbani mend vetëm disa gjëra rreth mënyrës së testimit të modeleve të IA-së :
-
Përdorni të dhëna përfaqësuese të testimit dhe shmangni rrjedhjet [4]
-
Zgjidhni metrika të shumta të lidhura me rezultate reale [4][5]
-
Për LLM-të, mbështetuni në rishikimin njerëzor + krahasimet e stilit të përqindjes së fitoreve [5]
-
Testi i qëndrueshmërisë - të dhënat e pazakonta janë të dhëna normale të maskuara [1]
-
Rrotullojeni në mënyrë të sigurt dhe monitorojeni, sepse modelet lëvizin dhe tubacionet prishen [1]
-
Dokumentoni çfarë keni bërë dhe çfarë nuk keni testuar (e pakëndshme, por e fuqishme) [2][3]
Testimi nuk është thjesht "të vërtetosh se funksionon". Është "të gjesh se si dështon përpara se ta bëjnë përdoruesit e tu". Dhe po, kjo është më pak tërheqëse - por është pjesa që e mban sistemin tënd në këmbë kur gjërat bëhen të paqëndrueshme... 🧱🙂
Pyetje të shpeshta
Mënyra më e mirë për të testuar modelet e IA-së në mënyrë që të përputhen me nevojat reale të përdoruesit
Filloni duke përcaktuar "të mirë" në terma të përdoruesit real dhe vendimit që mbështet modeli, jo vetëm një metrikë renditjeje. Identifikoni mënyrat e dështimit me koston më të lartë (pozitive të rreme kundrejt negativeve të rreme) dhe përcaktoni kufizime të forta si vonesa, kostoja, privatësia dhe shpjegueshmëria. Pastaj zgjidhni metrika dhe raste testimi që pasqyrojnë ato rezultate. Kjo ju pengon të optimizoni një "metrikë të bukur" që nuk përkthehet kurrë në një produkt më të mirë.
Përcaktimi i kritereve të suksesit përpara zgjedhjes së metrikave të vlerësimit
Shkruani se kush është përdoruesi, çfarë vendimi synon të mbështesë modeli dhe si duket "dështimi në rastin më të keq" në prodhim. Shtoni kufizime operacionale si vonesa e pranueshme dhe kostoja për kërkesë, plus nevojat e qeverisjes si rregullat e privatësisë dhe politikat e sigurisë. Pasi këto të jenë të qarta, metrikat bëhen një mënyrë për të matur gjënë e duhur. Pa këtë kornizë, ekipet kanë tendencë të anojnë drejt optimizimit të çdo gjëje që është më e lehtë për t'u matur.
Parandalimi i rrjedhjes së të dhënave dhe mashtrimit aksidental në vlerësimin e modelit
Mbani të qëndrueshme ndarjet e trajnimit/validimit/testit dhe dokumentoni logjikën e ndarjes në mënyrë që rezultatet të mbeten të riprodhueshme. Bllokoni në mënyrë aktive dublikatat dhe pothuajse dublikatat nëpër ndarje (i njëjti përdorues, dokument, produkt ose modele të përsëritura). Kini kujdes për rrjedhje të veçorive aty ku informacioni "i ardhshëm" rrëshqet në të dhëna hyrëse përmes vulave kohore ose fushave pas ngjarjes. Një bazë e fortë (madje edhe vlerësues artificialë) ju ndihmon të vini re kur po festoni zhurmën.
Çfarë duhet të përfshijë një sistem vlerësimi në mënyrë që testet të mbeten të përsëritshme gjatë ndryshimeve
Një pajisje praktike rikryen teste të krahasueshme në çdo model, kërkesë ose ndryshim politikash duke përdorur të njëjtat grupe të dhënash dhe rregulla vlerësimi. Zakonisht përfshin një suitë regresioni, panele të qarta metrikash dhe konfigurime dhe artefakte të ruajtura për gjurmueshmëri. Për sistemet LLM, ajo gjithashtu ka nevojë për një "grup të artë" të qëndrueshëm kërkesash plus një paketë me kuti anësore. Qëllimi është "shtypni butonin → rezultate të krahasueshme", jo "rikryeni fletoren dhe lutuni"
Metrika për testimin e modeleve të IA-së përtej saktësisë
Përdorni metrika të shumëfishta, sepse një numër i vetëm mund të fshehë kompromise të rëndësishme. Për klasifikim, çiftoni precizitetin/kujtesën/F1 me matricat e akordimit të pragut dhe konfuzionit sipas segmentit. Për regresion, zgjidhni MAE ose RMSE bazuar në mënyrën se si dëshironi të penalizoni gabimet dhe shtoni kontrolle në stilin e kalibrimit kur rezultatet funksionojnë si rezultate. Për renditje, përdorni NDCG/MAP/MRR dhe ndani sipas pyetjeve kokë vs bisht për të kapur performancën e pabarabartë.
Vlerësimi i rezultateve të LLM kur metrikat e automatizuara nuk janë të mjaftueshme
Trajtojeni si një sistem të nxitjes dhe politikës dhe shënoni sjelljen, jo vetëm ngjashmërinë e tekstit. Shumë ekipe kombinojnë vlerësimin njerëzor me preferencën në çifte (shkalla e fitores A/B), plus kontrolle të bazuara në detyra si "a nxori fushat e duhura" ose "a ndoqi politikën". Metrikat automatike të tekstit mund të ndihmojnë në raste të ngushta, por shpesh nuk u interesojnë përdoruesve. Rubrikat e qarta dhe një suitë regresioni zakonisht kanë më shumë rëndësi sesa një pikëzim i vetëm.
Testet e qëndrueshmërisë duhet të ekzekutohen në mënyrë që modeli të mos prishet në hyrjet me zhurmë
Testoni modelin me gabime shtypi, vlera që mungojnë, formatim të çuditshëm dhe unikode jo-standarde, sepse përdoruesit e vërtetë rrallë janë të rregullt. Shtoni raste të ndërrimit të shpërndarjes si kategori të reja, zhargon, sensorë ose modele gjuhësore. Përfshini vlera ekstreme (vargje boshe, ngarkesa të mëdha, numra jashtë diapazonit) për të nxjerrë në pah sjelljen e brishtë. Për LLM-të, testoni gjithashtu modelet e injektimit të menjëhershëm dhe dështimet e përdorimit të mjeteve si skadimet e kohës ose daljet e pjesshme.
Kontrollimi i çështjeve të paragjykimit dhe drejtësisë pa u humbur në teori
Vlerësoni performancën në segmente kuptimplote dhe krahasoni shkallët e gabimeve dhe kalibrimin midis grupeve ku është ligjërisht dhe etikisht e përshtatshme të matet. Kërkoni karakteristika përfaqësuese (si kodi postar, lloji i pajisjes ose gjuha) që mund të kodojnë tipare të ndjeshme në mënyrë indirekte. Një model mund të duket "i saktë në përgjithësi", ndërsa dështon vazhdimisht për grupe specifike. Dokumentoni atë që keni matur dhe atë që nuk e keni matur, në mënyrë që ndryshimet e ardhshme të mos rifusin në heshtje regresionet.
Testet e sigurisë dhe mbrojtjes që duhen përfshirë për sistemet gjeneruese të IA-së dhe LLM-së
Testoni për gjenerimin e përmbajtjes së palejuar, rrjedhjen e privatësisë, halucinacionet në domene me rrezik të lartë dhe refuzimin e tepërt aty ku modeli bllokon kërkesat normale. Përfshini injektimin e menjëhershëm dhe përpjekjet për nxjerrjen e të dhënave, veçanërisht kur sistemi përdor mjete ose rikuperon përmbajtje. Një rrjedhë pune e bazuar është: përcaktoni rregullat e politikave, ndërtoni një grup pyetjesh testimi, vlerësoni me kontrolle njerëzore plus automatike dhe riekzekutoni atë sa herë që ndryshojnë pyetjet, të dhënat ose politikat. Konsistenca është qiraja që paguani.
Vendosja dhe monitorimi i modeleve të IA-së pas lançimit për të kapur devijimet dhe incidentet
Përdorni modele shpërndarjeje të graduara si modaliteti në hije dhe rampat graduale të trafikut për të gjetur dështimet përpara se ta bëjë e gjithë baza e përdoruesve tuaj. Monitoroni ndryshimin e të dhënave hyrëse (ndryshimet e skemës, mungesat, ndryshimet e shpërndarjes) dhe ndryshimin e të dhënave dalëse (ndryshimet e rezultateve, ndryshimet e balancës së klasës), plus gjendjen operative si vonesa dhe kostoja. Ndiqni sinjalet e reagimit si ndryshimet, përshkallëzimet dhe ankesat, dhe shikoni regresionet në nivel segmenti. Kur ndryshon diçka, riekzekutoni të njëjtën skemë dhe vazhdoni monitorimin vazhdimisht.
Referencat
[1] NIST - Korniza e Menaxhimit të Riskut të Inteligjencës Artificiale (AI RMF 1.0) (PDF)
[2] Mitchell et al. - “Kartat Model për Raportimin e Modeleve” (arXiv:1810.03993)
[3] Gebru et al. - “Fletë të Dhënash për Setet e të Dhënave” (arXiv:1803.09010)
[4] scikit-learn - Dokumentacioni “Përzgjedhja dhe vlerësimi i modeleve”
[5] Liang et al. - “Vlerësimi Holistik i Modeleve Gjuhësore” (arXiv:2211.09110)