Ko IMDA LLM testavimo pradinis rinkinys moko mus apie AI užtikrinimą

Neseniai turėjau galimybę peržiūrėti IMDA pradinį rinkinį, skirtą LLM pagrįstų programų saugos ir patikimumo testavimui. Kaip žmogui, kuris daugiau nei 14 metų praleido kokybės užtikrinimo srityje, man buvo smalsu sužinoti, kaip nustatyti testavimo principai pritaikomi sprendžiant unikalius didelių kalbų modelių (LLM) keliamus iššūkius.


Tikėjausi labai techninio vadovo, kuriame daugiausia dėmesio skiriama AI modeliams ir algoritmams. Vietoj to radau praktinę sistemą, kuri atrodė stebėtinai pažįstama iš QA perspektyvos. Nors technologija gali sparčiai vystytis, pagrindinis tikslas išlieka nepakitęs: stiprinti pasitikėjimą, kad sistema veikia saugiai, patikimai ir taip, kaip numatyta.
Vienas teiginys iš dokumento puikiai atspindėjo šią mintį:
“Testavimas ir užtikrinimas atlieka svarbų vaidmenį patikimoje AI ekosistemoje.
Ši žinutė perteikiama visame vadove ir daugeliu atžvilgių atspindi, kaip šiandien keičiasi kokybiškų specialistų vaidmuo.
Kokybės rizika pasikeitė, o bandymų poreikis nepasikeitė
Vienas iš pirmųjų dalykų, kurie išsiskyrė, buvo tai, kaip dokumente suskirstyta dažniausiai su LLM pagrįstomis programomis susijusi rizika:
· Haliucinacijos ir netikslumas
· Šališkumas priimant sprendimus
· Nepageidaujamas turinys
· Duomenų nutekėjimas
· Pažeidžiamumas priešpriešinių raginimų atžvilgiu
Iš pirmo žvilgsnio tai gali pasirodyti visiškai nauji iššūkiai. Tačiau skaitydamas paaiškinimus ir pavyzdžius pastebėjau, kad brėžiu paraleles su rizika, kurią kokybės užtikrinimo komandos visada valdydavo.
Visada stengėmės užkirsti kelią neteisingam sistemos veikimui. Šiandien AI pristato haliucinacijų ir išgalvotų atsakymų galimybę.
Mes visada svarstėme saugumo ir netinkamo naudojimo scenarijus. Dabar greita injekcija ir priešiškos atakos tampa grėsmės kraštovaizdžio dalimi.
Mums visada rūpėjo atitiktis ir privatumas. Duomenų nutekėjimas per AI sugeneruotus atsakymus yra tiesiog modernus šio susirūpinimo išplėtimas.
Terminologija gali keistis, tačiau rizikos nustatymo, įvertinimo ir mažinimo disciplina išlieka kokybės užtikrinimo pagrindas.
Gera bandymo strategija prasideda dar ilgai prieš atliekant testą
Kitas man patikęs aspektas buvo dėmesys pasiruošimui prieš pradedant bandymus.
Vadove daug laiko praleidžiama aptariant, kaip organizacijos turėtų nustatyti atitinkamą riziką, apibrėžti testavimo tikslus, pasirinkti reprezentatyvius duomenų rinkinius ir nustatyti reikšmingas ribas prieš atlikdamos vertinimus.


Kaip kokybės užtikrinimo profesionalai, žinome, kad testavimo sėkmė dažnai nustatoma dar gerokai prieš pradedant vykdyti. Blogai apibrėžti tikslai, silpni bandymų duomenys arba neaiškūs priėmimo kriterijai gali pakenkti net griežčiausiam bandymo ciklams.
Man ypač patiko „gero“ bandymo duomenų rinkinio charakteristikos. Dokumente pabrėžiama, kad duomenų rinkiniai turėtų atspindėti programos paskirtį, apimti realias vartotojo sąveikas ir apimti pakankamai plataus ir gilumo, kad būtų atskleistos reikšmingos problemos.
Tai atspindi tuos pačius principus, kuriuos taikome kurdami veiksmingą tradicinių programų bandymo aprėptį.
Kitas vertingas dalykas buvo rekomendacija nustatyti slenksčius prieš pradedant bandymą. Dokumente pabrėžiama, kaip svarbu vengti „judinti vartų stulpus“ po to, kai žinomi rezultatai – tai principas, kuris stipriai atsiliepia visiems, kurie dirbo kokybės valdymo srityje.
Kai vien tikslumas nepasako visos istorijos
Skyriai, kuriuose aptariamos metrikos ir vertintojai, buvo ypač įdomūs, nes jie ginčija bendrą prielaidą, kad vien tikslumas apibrėžia kokybę.
Vadove paaiškinama, kad metrika turi atitikti ne tik techninius, bet ir verslo bei politikos tikslus. Atsižvelgiant į naudojimo atvejį, organizacijos gali teikti pirmenybę tikslumui, sąžiningumui, saugai, tikslumui, atšaukimui ar kitoms priemonėms.
Tai svarbus priminimas, kad kokybė priklauso nuo konteksto.
Taip pat vertinu subalansuotą diskusiją tarp vertintojų. Dokumente lyginami taisyklėmis pagrįsti metodai su LLM kaip teisėjo metodais ir atvirai pripažįstamos kiekvieno iš jų privalumai ir trūkumai.
Viena pastaba, su kuria aš tvirtai sutikau, buvo rekomendacija, kad automatiniai vertinimai turėtų papildyti, o ne pakeisti žmogaus sprendimą, ypač didelės rizikos aplinkoje.
Kaip testavimo profesionalai, mes visada pasitikėjome įrankiais, kad padidintume efektyvumą, tačiau galiausiai atsakomybė tenka žmonėms. Čia galioja tas pats principas.
Nežinomo išbandymas: kodėl svarbu „Red Teaming“.
Iš visų skyrių diskusija apie raudonųjų komandų sudarymą bene labiausiai verčia susimąstyti.
Dokumente aiškiai atskiriama lyginamoji analizė ir „raudonųjų komandų sudarymas“. Lyginamoji analizė padeda patvirtinti žinomus scenarijus, o raudonoji komanda padeda atskleisti akląsias vietas, kraštutinius atvejus ir netikėtą elgesį.
Skaitydamas šį skyrių negalėjau negalvoti apie tiriamąjį testavimą.
Tradiciniai bandymo atvejai patvirtina laukiamus rezultatus. Tiriamieji bandymai padeda atskleisti problemas, kurių nemanėme dokumentuoti.
Panašu, kad AI sistemose raudonoji komanda atlieka panašų vaidmenį.
Vadove aptariami priešingi raginimai, kelių posūkių sąveika, socialinės inžinerijos metodai ir kiti metodai, galintys atskleisti AI elgesio trūkumus. Taip pat pabrėžiama, kad svarbu įtraukti įvairius dalyvius ir srities ekspertus, kad padidėtų rizika, kuri kitu atveju liktų paslėpta.
Į dokumentą įtraukti praktiniai pavyzdžiai padėjo suprasti, kodėl struktūrinis raudonųjų komandų sudarymas tampa svarbiu įprastų testavimo metodų papildymu.


Nuo defektų prevencijos iki pasitikėjimo patvirtinimo
Galbūt tai yra didžiausias mano ištrauka iš dokumento AI testavimas nėra tik dar viena testavimo specializacija.
Daugelis aprašytų veiklų – rizikos prioritetų nustatymas, slenksčių nustatymas, valdymo sprendimai, žmogaus priežiūra ir rezultatų interpretavimas – neapsiriboja inžinierių komandomis.
Jiems reikalingas verslo suinteresuotųjų šalių, produktų savininkų, atitikties komandų, saugos specialistų ir kokybės specialistų bendradarbiavimas.
Čia matau įdomią galimybę patyrusiems kokybės užtikrinimo specialistams.
Daugelį metų mūsų dėmesys buvo skiriamas defektų prevencijai ir reikalavimų patvirtinimui. Taip pat vis dažniau mūsų prašoma padėti organizacijoms suprasti riziką, sukurti pasitikėjimą ir nustatyti, ar sistemomis galima pasitikėti.
Šis pokytis ne toks kaip įrankių pasikeitimas, o labiau kaip pačios profesijos raida.
Paskutinės mintys: ne tik bandymai, AI užtikrinimo link
Viena stipriausių žinučių, kurias pasiėmiau iš IMDA pradinio rinkinio, yra ta, kad AI užtikrinimas greitai tampa verslo galimybe, o ne tik testavimo veikla.
Organizacijoms priėmus LLM pagrįstas programas, sėkmė nebebus matuojama vien tik funkcijų pristatymu ar modelio našumu. Tai vis labiau priklausys nuo to, kaip užtikrintai organizacijos gali paaiškinti, valdyti, stebėti ir pasitikėti AI grindžiamais sprendimais.
„Spritle“ mano, kad šis pokytis reikalauja, kad kokybės užtikrinimo komandos taptų strateginiais partneriais diegiant AI. Kokybės ateitis slypi ne tik patvirtinant rezultatus, bet ir suprantant sistemos elgesį, anksti identifikuojant riziką ir padedant sukurti apsauginius turėklus, kurie įgalintų atsakingas naujoves.
Tokios sistemos kaip IMDA suteikia puikų pagrindą, tačiau tikroji jų vertė atsiranda juos naudojant įmonės aplinkoje. Tai reiškia inžinerinės disciplinos, srities kompetencijos, valdymo praktikos ir nuolatinio užtikrinimo derinimą į pakartojamą metodą.
Kai dirbtinio intelekto sistemos tampa vis pajėgesnės, organizacijos užduos klausimą ne tikAr tai veikia?“
Tai bus:“Ar galime juo pasitikėti dideliu mastu?“
Padėti atsakyti į šį klausimą yra tai, kur matome kokybės inžinerijos ateitį ir kryptį, į kurią aktyviai investuojame „Spritle“.



Post Comment
Tik prisijungę vartotojai gali komentuoti.