Avatud probleemid AI komponentide valideerimisel

A. AI KOMPONENDI KINNITAMINE Nii auto- kui ka õhuruumid on reageerinud tehisintellektile, pidades seda „spetsialiseerunud tarkvaraks” sellistes standardites nagu ISO 8800 [14] ja [13]. Sellel lähenemisviisil on suur kasu, kuna see kasutab kogu varasemat tööd üldise mehaanilise ohutuse valdkonnas ja varasemat tööd tarkvara valideerimisel. Kuid nüüd tuleb lahendada küsimus, kuidas käsitleda tõsiasja, et meil on andmete genereeritud “kood” võrreldes tavapärase programmeerimiskoodiga. V&V maailmas väljendub see erinevus kolmes olulises aspektis: katvuse analüüs, koodiülevaatused ja versioonikontroll. TABEL III V&V tehnikatarkvara AI/ML Katvuse analüüs: Koodi struktuur annab katvuse aluse. Struktuur puudub Koodide ülevaated: Koodide allikate ekspertide teadmised Ülevaatamiseks mõeldud koodi pole Versioonikontroll Hoolikas ülesehitamine/väljalase Väga keeruline andmetega

Need erinevused tekitavad tohutu probleemi intelligentse testide genereerimisel ja mis tahes argumendi täielikkuse poole. See on aktiivse uurimistöö valdkond ja on tekkinud kaks lõime: 1) Treeningkomplekti valideerimine: kuna viimast viidatud komponenti on väga raske analüüsida, on üheks võimaluseks uurida treeningkomplekti ja ODD-d, et leida huvitavaid teste, mis võivad paljastada nendevahelised praod [16]. 2) Mürakindlus: kas simulatsiooni või formaalsete meetodite [17] abil on lähenemisviisiks erinevate kõrgema taseme omaduste kinnitamine ja nende kasutamine komponendi testimiseks. Objekti tuvastamise näide võib olla omaduse kinnitamine, et objekti tuleks ära tunda orientatsioonist sõltumatult. Üldiselt on tehisintellekti komponentide valideerimise tugevate meetodite väljatöötamine üsna aktiivne ja lahendamata “fikseeritud” funktsiooniga AI komponentide uurimisteema. See tähendab, AI komponendid, mille funktsioon muutub aktiivse versioonikontrolliga. Muidugi eelistavad paljud AI-rakendused mudelit, kus AI-komponent pidevalt moondub. Morfeerimise olukorra valideerimine on tulevaste uuringute teema.

B. AI SPETSIFIKATSIOON

Täpselt määratletud süsteemide puhul, kus on olemas süsteemitaseme abstraktsioonid, suurendavad AI/ML komponendid märkimisväärselt intelligentse testide genereerimise raskusi. Kuldse spetsifikatsiooniga saab jälgida struktureeritud protsessi, et teha valideerimisel olulisi edusamme ja isegi AI tulemusi tavapäraste kaitsemeetmetega siduda. Kahjuks on tehisintellekti üks mõjuvamaid kasutusviise selle kasutamine olukordades, kus süsteemi spetsifikatsioonid ei ole täpselt määratletud või ei ole tavapärase programmeerimise abil elujõulised. Nendes Specification Less /ML (SLML) olukordades pole huvitavate testide koostamine keeruline, vaid tulemuste õigsuse hindamine tekitab veelgi raskusi. Lisaks kuuluvad enamik autonoomsete sõidukite peamisi süsteeme (taju, asukohateenused, tee planeerimine jne) sellesse süsteemi funktsioonide ja tehisintellekti kasutamise kategooriasse. Praeguseks on spetsifikatsiooni puudumise probleemi lahendamiseks olnud kaks lähenemisviisi: Anti-Spec ja AI-Driver. 1) Anti-Spec Sellistes olukordades jääb üle vaid korrektsuse täpsustamine antispetsifikatsiooni abil. Lihtsaim anti-spec on õnnetuste vältimine. Inteli esialgsete tööde põhjal on olemas standard IEEE 2846 „Eeldused mudelitele ohutusega seotud automatiseeritud sõidukite käitumises” [18], mis loob raamistiku minimaalsete eelduste määratlemiseks seoses teiste liiklejate mõistlikult prognoositava käitumisega. Iga stsenaariumi jaoks täpsustab see eeldused teiste liiklejate kinemaatilisi omadusi, sealhulgas nende kiirust, kiirendust ja võimalikke manöövreid. Väljakutsed hõlmavad täielikkuse argumenti, standardile vastavuse kontrollimise masina spetsifikatsiooni ja seost vastutuse haldusraamistikuga. 2) AI-draiver Kui IEEE 2846 lähtub alt-üles tehnoloogia vaatenurgast, siis Koopman/Widen [19] on pakkunud välja tehisintellekti draiveri määratlemise kontseptsiooni, mis peab kordama kõiki inimjuhi pädevusi keerulises reaalses keskkonnas. Koopmani AI draiveri kontseptsiooni põhipunktid on järgmised:

a) Täielik sõiduvõime: tehisintellekti juht peab hakkama saama kogu sõiduülesandega, sealhulgas tajumisega (keskkonna tunnetamine), otsuste tegemisega (stsenaariumide planeerimine ja neile reageerimisega) ja juhtimisega (füüsiliste liigutuste, nagu roolimine ja pidurdamine), teostamine. Samuti peab see arvestama nüansse, nagu sotsiaalsed sõidunormid ja ootamatud sündmused. b) Ohutuse tagamine: Koopman rõhutab, et AV-d vajavad rangeid ohutusstandardeid, mis on sarnased sellistele tööstusharudele nagu lennundus. See hõlmab võimalike rikete tuvastamist, riskide juhtimist ja ohutu töö tagamist ka ettenägematute sündmuste korral. c) Inimekvivalentsus: tehisintellekti juht peab vastama pädeva inimjuhi jõudlusele või ületama selle. See hõlmab liiklusseaduste järgimist, äärmuslikele juhtumitele (haruldased või ebatavalised sõidustsenaariumid) reageerimist ja alati olukorrateadlikkuse säilitamist. d) Eetiline ja juriidiline vastutus: tehisintellekti juht peab tegutsema eetilistes ja juriidilistes raamistikes, sealhulgas käituma olukordades, mis hõlmavad moraalseid otsuseid või vastutust. e) Testimine ja valideerimine: Koopman rõhutab tugeva testimise, simulatsiooni ja teepealsete katsetuste tähtsust tehisintellekti draiverisüsteemide valideerimiseks. See hõlmab servajuhtude, pikaajaliste riskide katmist ja süsteemide üldistamise tagamist erinevates sõidutingimustes. Üldiselt on see väga ambitsioonikas ettevõtmine ja selle mõistliku draiveri spetsifikatsiooni väljatöötamisel on olulisi väljakutseid. Esiteks pole „mõistliku” juhi idee isegi inimlikul poolel hästi kodeeritud. Pigem on see “mõistlikkuse” määratlus üles ehitatud pika seadusliku destilleerimise ajaloo jooksul ja loomulikult on inimstandard üles ehitatud teiste inimeste arusaamadele inimestest. Teiseks oleks sellise standardi keerukus väga kõrge ja pole selge, kas see on teostatav. Lõpuks võib kuluda üsna palju aega seaduslikule destilleerimisele, et jõuda teatud tasemeni inimesel nagu “AI-Driver”. Praegu on nii ADAS-i kui ka AV spetsifikatsiooni tipptasemel suhteliselt kehv. ADAS-süsteemidel, mis on laialt levinud, on tohutud erinevused käitumises ja täielikkuses. Kui klient ostab ADAS-i, pole täiesti selge, mida ta saab. Tööstusrühmade, nagu AAA, tarbijaaruanded ja IIHS testid on näidanud olemasolevate lahenduste olulisi puudujääke [20]. 2024. aastal võttis IIHS kasutusele reitinguprogrammi, et hinnata osalise sõiduautomaatika süsteemide kaitsemehhanisme. 14 testitud süsteemist sai vastuvõetava hinnangu vaid üks, mis rõhutab vajadust täiustatud meetmete järele, et vältida väärkasutamist ja tagada juhi kaasamine [21]. Tänapäeval on turul ainult üks protsessile mitte orienteeritud regulatsioon ja see on NHTSA eeskirjad AEB ümber [22].