Formalus patikrinimas: vienintelis būdas patenkinti AI reguliuotojus
Pokalbis, kuris niekada nesiklosto gerai
Įsivaizduokite šią sceną. Ji vyksta kiekvieną savaitę valdybų posėdžių salėse visoje Europoje, FDA peržiūros susitikimuose, draudimo rizikos vertinimo biuruose. Dirbtinio intelekto inžinierius pristato savo naujausią sistemą reguliuotojams, teisininkams ar rizikos vertintojams.
"Mūsų autonominis insulino pompa pasiekė 99,97 % tikslumą per 50 milijonų testų scenarijų", - išdidžiai praneša inžinierius, spustelėdamas skaidrę, pilną įspūdingų rodiklių. "Tai pažangiausia technologija. Geriau nei bet kuris žmogus endokrinologas."
Kambaryje pasidaro tylu. Reguliatorius pasilenkia į priekį.
"Tai jūs man sakote," ji lėtai taria, "kad iš kiekvienų 10 000 insulino dozių, kurias suleidžia šis prietaisas... trys gali būti neteisingos?"
Inžinierius neramiai pasisuka. „Na, statistiškai kalbant..."
"Vien Vokietijoje maždaug 7 milijonai žmonių serga cukriniu diabetu, kuriam reikia insulino terapijos. Jei kiekvienas žmogus gautų tik keturias dozes per dieną, tai būtų 28 milijonai kasdienių injekcijų. Esant jūsų 0,03 % klaidų dažniui..." Ji atlieka skaičiavimus savo užrašų knygelėje. "Tai 8 400 galimų dozavimo klaidų. Kiekvieną dieną."
"Bet dauguma jų nebūtų kliniškai reikšmingi..."
„Ar galėtumėte pasakyti, kurie iš jų būtų?"
Tyla.
"Ar galite pasakyti, kada įvyks kitas gedimas? Ar galite pasakyti, kodėl jis įvyks?"
Daugiau tylos.
"Tuomet bijau, kad negalime patvirtinti šio įrenginio."
Šis pokalbis, įvairiomis formomis, nuolat vyksta, kai dirbtinis intelektas keliauja iš tyrimų laboratorijų į fizinį pasaulį. Ir jis atskleidžia esminį epistemologinį atotrūkį tarp to, kaip DI inžinieriai galvoja apie saugą, ir to, kaip apie ją galvoja reguliuotojai, teisininkai ir teismai.
Kalbos barjeras, kuris nėra apie kalbą
Kai dirbtinio intelekto inžinierius sako „99,97 % tikslumas", jis nuoširdžiai tiki apibūdinąs kažką įspūdingo ir saugaus. Mašininio mokymosi etalonų pasaulyje toks skaičius būtų švenčiamas. Būtų skelbiami moksliniai darbai. Investuotojai džiūgautų.
Tačiau reguliuotojas išgirsta ką nors visiškai kitokio. Jis išgirsta: „Yra nedidelė, bet ne nulinė tikimybė, kad ši sistema katastrofiškai suges, ir mes neturime jokio supratimo, kada, kur ar kodėl tai įvyks."
Tai ne komunikacijos problema. Ne tai, kad inžinieriams reikia geresnių pristatymo įgūdžių ar kad reguliuotojams reikia techninio išsilavinimo. Tai esminis dviejų skirtingų sampratų susidūrimas, ką iš tikrųjų reiškia „žinoti, kad kažkas veikia".
Vartotojų programinėje įrangoje tikimybiniai metodai yra visiškai priimtini. Jei „Netflix" rekomenduoja filmą, kurio nekenčiate, niekas nemiršta. Jei „Spotify" pasiūlo dainą, neatitinkančią jūsų skonio, blogiausiu atveju šiek tiek susierzinsite. Šios sistemos gali sau leisti kartais klysti, nes gedimo kaina yra nereikšminga.
Tačiau dirbtinis intelektas sparčiai peržengia vartotojų rekomendacijų ribas ir keliauja į sritis, kuriose gedimai turi fizinių, teisinių ir moralinių pasekmių: autonominės transporto priemonės, per sekundės dalį priimančios sprendimus dėl pėsčiųjų, medicinos prietaisai, apskaičiuojantys vaistų dozes, pramoniniai robotai, dirbantys greta žmonių, finansų sistemos, patvirtinančios arba atmetančios kreditą, nuo kurio priklauso, ar šeimos galės įsigyti būstą.
Šiose srityse „gana tikėtina, kad veikia" nėra pakankama. Teismai nepriima tikimybių skirstinių kaip įrodymų. Draudimo aktuarijai negali įkainoti polisų nežinomiems gedimų režimams. Reguliuotojai negali patvirtinti prietaisų, kurie gali žudyti žmones dėl priežasčių, kurių niekas negali paaiškinti.
Kodėl testavimas, kad ir koks išsamus, negali užtikrinti saugumo
Šiandien dominuojanti dirbtinio intelekto vertinimo paradigma yra empirinis testavimas su atidėtais duomenų rinkiniais. Treniruojate modelį su A duomenų rinkiniu, o vertinate su B duomenų rinkiniu. Jei jis gerai veikia su B, darote prielaidą, kad „išmoko" pagrindinę užduotį ir apibendrins žinias realiam diegimui.
Šis metodas turi tris esmines problemas, kurių neišspręs joks testavimo kiekis.
Pirma problema: begalinė įvesties erdvė
Testavimas gali tik parodyti klaidų buvimą, niekada jų nebuvimą. Kad ir kiek testų atliktumėte, imate pavyzdžius iš begalinės įvesties erdvės. Sistema, valdanti medicinos prietaisą, turi susidoroti ne tik su įsivaizduotais testų scenarijais, bet ir su kiekvienu įmanomu pacientų fiziologijų, aplinkos sąlygų, jutiklių rodmenų ir kraštinių atvejų deriniu, kurį realus pasaulis anksčiau ar vėliau pateiks.
Įsivaizduokite, kad bandote įrodyti, jog šieno kupetoje nėra adatų, atsitiktinai imdami po šieno saują. Išnagrinėję milijoną saujų ir neradę nė vienos adatos, negalite daryti išvados, kad kupeta yra be adatų. Galite tik pasakyti, kad dar neradote nė vienos. Testavimas veikia taip pat. Kad ir kiek scenarijų praeitų, kitas gali žlugti.
Antra problema: pažeidžiamumas priešiškoms atakoms
Gilieji neuroniniai tinklai yra ypač pažeidžiami priešiškų įvesties duomenų. Tai kruopščiai sukurti trikdžiai, dėl kurių modeliai katastrofiškai žlunga, nors žmogaus akiai atrodo normalūs.
Modelis gali teisingai atpažinti STOP ženklus 99,99 % atvejų, tačiau mažas lipdukas, padėtas konkrečioje vietoje, gali lemti, kad modelis užtikrintai palaikys ženklą greičio ribojimo ženklu. Modelis gali tiksliai nustatyti ligas tūkstančiuose rentgeno nuotraukų, tačiau konkretus triukšmo raštas, nematomas žmogaus radiologams, gali lemti, kad modelis nepastebės akivaizdžių navikų.
Tai ne vien teoriniai nuogąstavimai. Mokslininkai įrodė priešiškų atakų veiksmingumą prieš kiekvieną pagrindinę neuroninių tinklų architektūrų klasę. Be to, tokias atakas tampa vis lengviau parengti, o apsaugos priemonės lieka neišsamios.
Testavimas negali apsaugoti nuo priešiškų pažeidžiamumų, nes atakų erdvė yra begalinė. Reikėtų išbandyti ne tik įprastus duomenis, bet ir kiekvieną galimą kiekvieno įprasto duomenų elemento modifikaciją. Tai matematiškai neįmanoma.
Trečia problema: pasiskirstymo poslinkis
Realus pasaulis nestovi vietoje. Duomenų pasiskirstymas, pagal kurį buvo apmokytas jūsų modelis, laikui bėgant kinta. Keičiasi pacientų populiacijos. Eismo sąlygos evoliucionuoja. Gamybos procesai varijuoja. Jutikliai sensta.
Modelis, kuris puikiai veikia su šiandienos duomenimis, gali tyliai suklysti, kai rytojaus duomenys nukrypsta už jo mokymo pasiskirstymo ribų. Ir, skirtingai nei aiškios klaidos, kurios sukelia programų gedimus, tokie nesklandumai dažnai pateikia užtikrintus, tikėtinus, tačiau neteisingus rezultatus.
Testavimas su šiandienos duomenimis nieko nepasako apie rytojaus veikimą. Kol pastebite gedimą gamybinėje aplinkoje, žala jau būna padaryta.
Formalusis patikrinimas: matematika kaip universali saugos kalba
Formalusis patikrinimas siūlo visiškai kitokį požiūrį. Vietoj klausimo „ar sistema veikė šiais testų atvejais?" jis klausia „ar galime matematiškai įrodyti, kad sistema tenkins savybę visiems įmanomiems įvesties duomenims?"
Skirtumas yra esminis. Testai ima mėginius iš įvesties erdvės. Patikrinimas išsamiai samprotauja apie visą erdvę.
Apsvarstykite robotinę ranką, dirbančią kartu su žmonėmis gamykloje. Norime garantuoti saugos savybę: „ranka niekada neturi viršyti 2 metrų per sekundę, kai žmogus aptinkamas per 1 metro atstumą."
Testavimo metodas paleidžia ranką per tūkstančius scenarijų su imituotais žmonėmis įvairiose padėtyse ir greičiuose, matuodamas, ar saugos riba kada nors pažeidžiama. Jei pažeidimų nepastebima, sistema paskelbiama „saugia". Tačiau kitas scenarijus, tas, kuris nebuvo išbandytas, gali būti būtent tas, kuris sužeidžia darbuotoją.
Patikrinimo metodas yra iš esmės kitoks. Paimame valdymo sistemos matematinį modelį, įskaitant neuroninį tinklą, kuris apdoroja jutiklių duomenis, ir valdiklį, kuris generuoja variklio komandas. Saugos savybę išreiškiame kaip formalų apribojimą. Tada naudojame specializuotus algoritmus, vadinamus SMT (Satisfiability Modulo Theories) sprendikliais, kad atsakytume į tikslų klausimą: „ar egzistuoja KOKIA nors įvesties konfigūracija, galiojančiame veikimo diapazone, kuriai išvesties greitis viršija 2 m/s, kai aptinkamas žmogaus artumas?"
Sprendiklis netikrina atsitiktinių taškų. Jis analizuoja visos sistemos matematinę struktūrą. Jis samprotauja apie funkcijų erdvės geometriją. Jei jis grąžina „UNSAT" (neįvykdoma), turime matematinį įrodymą, kad tokia pažeidžianti įvestis neegzistuoja. Saugos savybė galioja ne tik tiems atvejams, kuriuos išbandėme, bet ir kiekvienam įmanomam atvejui, kuris kada nors galėtų įvykti.
Tai skirtumas tarp „patikrinau daug tiltų ir nė vienas nesugriuvo" ir „šių medžiagų fizika matematiškai garantuoja, kad šis tiltas negali sugriūti esant šiai apkrovai". Vienas yra empirinis stebėjimas, kurį galima peržiūrėti. Kitas yra loginė tikrumas.
Kodėl šiuolaikinis dirbtinis intelektas priešinasi patikrinimui
Jei formalusis patikrinimas toks galingas, kodėl jo visi nenaudoja? Kodėl įmonės remiasi „raudonosios komandos" metodu (žmonės bando sulaužyti modelį) vietoj matematinių įrodymų?
Atsakymas slypi architektūriniuose sprendimuose, kuriuos padarė pramonė. Šiuolaikiniai didieji kalbos modeliai ir gilieji neuroniniai tinklai sukurti išraiškingumui, o ne patikrinamumui. Jie optimizuoti generuoti kūrybinius rezultatus, o ne būti matematiškai analizuojami.
Tipinis transformerių modelis turi milijardus ar trilijonus parametrų. Jis naudoja sudėtingas netiesines aktyvavimo funkcijas, tokias kaip GeLU ar Swish. Tokios sistemos patikrinimo matematinis sudėtingumas auga eksponentiškai su neuronų skaičiumi ir tinklo gyliu.
Įrodyti savybę transformeriui su milijardu parametrų yra skaičiavimo požiūriu neįmanoma. Visata pasiektų šiluminę mirtį, kol sprendiklis baigtų tyrinėti visas matematines šakas. Pramonė sukūrė tokias sudėtingas sistemas, kad net jų kūrėjai negali jų visiškai išanalizuoti.
Tai dizaino sprendimas, o ne neišvengiamybė. Pramonė optimizavo įspūdingas demonstracijas ir etalonų rezultatus, neatsižvelgdama į tai, ar tokios sistemos kada nors galėtų būti saugiai diegiamos reguliuojamoje aplinkoje.
„Dweve" architektūra: patikrinama pagal dizainą
„Dweve" priėmėme kitokius architektūrinius sprendimus. Sistemos nuo pat pradžių kūrėme taip, kad jos būtų patikrinamos, nes supratome, kad įmonių ir pramonės klientams anksčiau ar vėliau teks tenkinti reguliuotojų reikalavimus, o ne tik juos sužavėti.
Mūsų metodas sujungia dvi pagrindines naujoves, dėl kurių patikrinimas tampa įmanomas.
Dvejetainių apribojimų atradimas: paprasta matematika
Vietoj didžiulių slankiojo kablelio neuroninių tinklų su milijardais nuolatinių parametrų, „Dweve" sistemos naudoja dvejetainių apribojimų atradimą. Žinios pateikiamos kaip diskretūs loginiai apribojimai, o ne išmokti nuolatiniai svoriai.
Mūsų „Dweve Core" bibliotekoje yra aparatine įranga optimizuoti algoritmai, pagrįsti dvejetainėmis operacijomis: XNOR, AND, OR, POPCNT. Šiandien tai šimtai tūkstančių rankomis suderintų branduolių 2 900+ operacijų per 76 kategorijas. Šios operacijos turi paprastas, gerai suprantamas matematines savybes. Dvejetainis apribojimas arba galioja, arba ne. Čia nėra tikimybinio neapibrėžtumo.
Apribodami matematiką paprastais tiesiniais ryšiais ir Bulio logika, drastiškai sumažiname patikrinimo paieškos erdvę. Problemos, kurios ištisiniams neuroniniams tinklams būtų neišsprendžiamos, mūsų dvejetainių apribojimų sistemoms tampa išsprendžiamos. Patikrinimo problema virsta iš neįmanomo netiesinio optimizavimo į išsprendžiamą mišraus sveikojo skaičiaus tiesinio programavimo (MILP) arba SAT uždavinį.
Tai vis dar skaičiavimo požiūriu sudėtingos problemos, tačiau sistemų, kurias diegiame saugai kritinėse programose, dydžiui šiuolaikiniai sprendikliai jas gali išspręsti per sekundes ar minutes, o ne per šimtmečius.
Šešių sluoksnių riboto savarankiškumo architektūra
Mes nesistengiame patikrinti kiekvieno dirbtinio intelekto suvokimo aspekto. Pripažįstame, kad „pikselių tinklelis vaizduoja žmogų" iš esmės yra neaiškus, tikimybinis sprendimas. Negalite formaliai įrodyti, kad modelių atpažinimas visada teisingas, nes teisingumas priklauso nuo subjektyvių apibrėžimų.
Vietoj to diegiame daugiasluoksnę saugos architektūrą, kurioje tikimybiniai dirbtinio intelekto komponentai yra apriboti formaliai patikrintais loginiais apribojimais. Dirbtinis intelektas gali siūlyti veiksmus, tačiau prieš vykdymą šie pasiūlymai turi praeiti patikrintus saugos vartus.
„Dweve Nexus" įgyvendina šešis saugos užtikrinimo sluoksnius:
- Ketinimų patikra: patvirtina, kad dirbtinio intelekto veiksmai atitinka deklaruotus tikslus
- Ribotas savarankiškumas: griežtos ribos, kokie veiksmai yra leistini, neatsižvelgiant į dirbtinio intelekto pasiūlymus
- Turinio moderavimas: filtruoja išvestis pagal saugą ir tinkamumą
- Etikos užtikrinimas: garantuoja atitiktį apibrėžtiems etikos apribojimams
- Anomalijų aptikimas: nustato, kada dirbtinio intelekto elgsena nukrypsta nuo numatytų modelių
- Veikimo laiko stebėjimas: nuolatinis patikrinimas, kad saugos invariantai būtų išlaikyti
Svarbiausia įžvalga yra ta, kad mums reikia formaliai patikrinti tik saugos sluoksnius, o ne visą dirbtinio intelekto sistemą. Net jei pagrindinis dirbtinis intelektas padaro klaidą, riboto savarankiškumo sluoksnis matematiškai garantuoja, kad pavojingos komandos niekada nepasieks vykdymo mechanizmų.
Reguliavimo matematika: kodėl patikra kuria verslo vertę
Mūsų klientams formalioji patikra nėra akademinis pratimas. Tai konkurencinis pranašumas, kuris tiesiogiai virsta verslo rezultatais.
Greitesnis reguliavimo patvirtinimas
Kai medicinos prietaisų gamintojas kreipiasi į FDA ar EMA su dirbtinio intelekto sistema, reguliuotojai pagrįstai elgiasi atsargiai. Jie žino, kad DI gali būti nenuspėjamas. Standartiniai patvirtinimo procesai reikalauja metų klinikinių tyrimų, kad saugumas būtų įrodytas statistiškai.
Tačiau gamintojas, naudojantis formaliai patikrintus Dweve komponentus, gali pakeisti pokalbio eigą. Vietoj bandymų rezultatų, rodančių, kad „dar nepastebėjome gedimų", jie gali pateikti matematinius įrodymus, kad „gedimai šiose ribose neįmanomi".
„Mes ne tik manome, kad šis insulino pompa neperdozuos pacientų. Štai formalus įrodymas, kad išvesties dozė matematiškai apribota paciento svorio ir gliukozės kiekio apribojimais. Pažeidimas nėra tik mažai tikėtinas. Jis logiškai neįmanomas."
Tai įgalina pagreitintą peržiūros kelią. Reguliuotojai gali savarankiškai patikrinti įrodymą. Jiems nereikia pasitikėti bandymų procesu; jie gali tiesiogiai išnagrinėti matematiką.
Mažesnės draudimo įmokos
Draudimo aktuarai susiduria su neįmanoma problema, kai kalbama apie tradicines DI sistemas. Kaip įkainoti riziką dėl gedimų, kurių negalite numatyti ar paaiškinti? Rezultatas yra arba itin didelės įmokos nežinomai rizikai padengti, arba išimčių sąlygos, dėl kurių draudimas tampa praktiškai nenaudingas.
Patikrintos sistemos keičia aktuarinių skaičiavimų pobūdį. Jei matematinis įrodymas garantuoja, kad tam tikros rūšies gedimai negali įvykti, tie gedimų scenarijai gali būti pašalinti iš rizikos modelio. Likusi rizika yra įvertinama kiekybiškai. Įmokos atitinkamai mažėja.
Teisinė gynyba
Kai DI sistemos padaro žalą, seka teisminiai ginčai. Tradiciniuose DI diegimuose ginti sistemą beveik neįmanoma. „Kaip jūsų sistema priėmė šį sprendimą?" „Mes tiksliai nežinome, tai neuroninis tinklas su milijardais parametrų..." Toks atsakymas netenkina nei teisėjo, nei prisiekusiųjų.
Patikrintos sistemos siūlo kitokią gynybą: „Štai saugos apribojimas. Štai matematinis įrodymas, kad apribojimo pažeisti negalima. Žala įvyko už patikrintos ribos, o tai rodo išorinius veiksnius, o ne sistemos gedimą."
Tai ne apie atsakomybės vengimą. Tai apie galimybę tiksliai parodyti, kokios garantijos buvo suteiktos ir ar jos buvo įvykdytos. Teismai supranta formaliąją logiką. Jie supranta matematinius įrodymus. Jie nesupranta tikimybinių pasikliautinųjų intervalų.
ES Dirbtinio intelekto aktas: patikra tampa privaloma
Teoriniai formalaus patikrinimo pranašumai tampa praktiniais reikalavimais. ES Dirbtinio intelekto aktas, įsigaliojęs 2024 m. su laipsnišku įgyvendinimu iki 2027 m., iš esmės keičia tai, kas teisiškai reikalaujama diegiant dirbtinį intelektą Europoje.
„Didelės rizikos“ dirbtinio intelekto sistemoms, įskaitant medicinos prietaisus, sprendimus dėl įdarbinimo, kreditingumo vertinimus ir daugelį pramoninių programų, reglamentas reikalauja:
- Rizikos valdymo sistemos, kurios nustato ir mažina numatomą riziką
- Aukštos kokybės mokymo duomenys su dokumentuota kilme
- Žurnalų įrašymo galimybės, leidžiančios atsekti sistemos veikimą
- Skaidrumas naudotojams dėl dirbtinio intelekto priimtų sprendimų
- Žmogaus priežiūros mechanizmai, leidžiantys įsikišti
- Tikslumas, patikimumas ir kibernetinis saugumas, atitinkantys programos paskirtį
Atkreipkite dėmesį į kalbą: „numatomi pavojai“, „atsekamas elgesys“, „taikymui tinkamas tikslumas“. Tai ne migloti siekiai. Tai teisiniai reikalavimai su vykdymo užtikrinimo priemonėmis, įskaitant baudas iki 35 milijonų eurų arba 7 % pasaulinės apyvartos.
Kaip įrodyti, kad nustatėte ir sušvelninote „numatomą riziką“ neuroniniam tinklui, turinčiam milijardus parametrų, kurio sprendimų procesas nesuprantamas net jo kūrėjams? Kaip parodyti, kad elgsena yra „atsekama“, kai sistema sukuria rezultatus per nesuprantamas matricų daugybas?
Tradicinės dirbtinio intelekto architektūros negali patenkinti šių reikalavimų vien dokumentacija ir testavimu. Tačiau patikrintos sistemos gali. Įrodymas yra dokumentacija. Matematinė garantija yra rizikos mažinimas. Loginiai apribojimai yra atsekamumas.
„528“ srities specialistai: patikrinamas mastas
Dažnas prieštaravimas patvirtintam dirbtiniam intelektui yra tas, kad patvirtinimas nėra mastelio keičiamas. Paprastoms sistemoms su keliomis taisyklėmis, taip, patvirtinimas veikia. Tačiau realaus pasaulio dirbtinis intelektas turi apdoroti sudėtingą suvokimą ir samprotavimą. Kaip patvirtinimas gali veikti mastelio lygmeniu?
Dweve Loom įrodo, kad patikrinimas ir galimybės nėra vienas kitą paneigiantys dalykai. Mūsų pagrindinis modelis naudoja 528 specializuotus apribojimų rinkinius, kurių kiekvienas turi 64-128MB dvejetainių apribojimų. Tačiau bet kuriai užklausai suaktyvinami tik 4-8 srities specialistai.
Ši architektūra, kurią vadiname itin retu aktyvavimu, reiškia, kad tikrinimo pastangos auga kartu su aktyviuoju poaibiu, o ne su visu modeliu. Mums nereikia vienu metu tikrinti visų 528 srities specialistų derinių. Tikriname maršruto parinkimo logiką, kuri atrenka srities specialistus, ir kiekvieno srities specialisto apribojimų rinkinį tikriname atskirai.
Permutuoto susitarimo popcount (PAP) maršruto parinkimo sistema naudoja struktūrinį šablonų aptikimą, kad parinktų atitinkamus srities specialistus. Šis maršruto parinkimo sluoksnis pats savaime yra formaliai patikrinamas, nes veikia su atskiromis dvejetainėmis operacijomis, turinčiomis aiškiai apibrėžtas matematines savybes.
Rezultatas - sistema, galinti atlikti sudėtingas realaus pasaulio užduotis, išlaikydama patikrinimo įmanomumą. Gauname ekspertų mišinio architektūrų galimybių naudą ir formalaus patikrinimo saugumo naudą.
Įgyvendinimas: kaip iš tikrųjų atrodo patikra
Organizacijoms, svarstančioms patvirtintą dirbtinio intelekto diegimą, praktinis procesas apima kelis etapus.
1 etapas: nuosavybės specifikacija
Prieš pradedant patikrą, turite apibrėžti, kokios savybės turi būti tikrinamos. Tai dažnai yra sunkiausias žingsnis, reikalaujantis glaudaus bendradarbiavimo tarp srities ekspertų, inžinierių ir teisės/atitikties komandų.
Savybės turi būti tikslios ir matematiškai išreiškiamos. „Sistema turi būti saugi“ nėra patikrinama savybė. „Variklio greičio komanda neturi viršyti V_max, kai artumo jutiklis rodo mažesnį nei D_min atstumą“ yra patikrinama.
„Dweve“ padedame klientams šiame specifikacijos procese naudodami „Spindle“ - mūsų įmonės žinių valdymo platformą. 32 agentų hierarchijoje yra reguliavimo atitikties specialistų, kurie padeda teisinius reikalavimus paversti formaliais apribojimais.
2 etapas: architektūros žemėlapis
Dirbtinio intelekto sistemos architektūra turi būti susieta su formaliu modeliu, kurį gali analizuoti tikrinimo įrankiai. „Dweve“ sistemoms šis susiejimas yra paprastas, nes mūsų dvejetainė apribojimų architektūra buvo sukurta siekiant patikrinamumo.
Organizacijoms, kurios jau diegia neuroninius tinklus, šis etapas gali reikalauti architektūros pakeitimų. Prie esamų modelių pridedant ribotos autonomijos sluoksnius, saugos apribojimus įgyvendinant kaip patvirtintus apvalkalus arba kai kuriais atvejais nepatikrinamus komponentus pakeičiant Dweve atitikmenimis.
3 etapas: patikros vykdymas
Šiuolaikiniai SMT sprendėjai ir formalaus tikrinimo įrankiai analizuoja sistemos modelį, kad arba įrodytų nurodytas savybes, arba nustatytų kontrpavyzdžius. Kontrpavyzdžiai yra neįkainojami, nes jie tiksliai atskleidžia, kurie įvesties duomenys galėtų pažeisti saugos apribojimus, todėl galima atlikti tikslinius pataisymus.
Dweve sistemų atveju patikra paprastai atliekama per kelias minutes ar valandas, priklausomai nuo apribojimų sudėtingumo.
4 etapas: Sertifikavimas ir dokumentacija
Patvirtintos savybės generuoja įrodymų artefaktus, kurie tarnauja kaip sertifikavimo įrodymai. Šie įrodymai yra mašiniškai patikrinami, o tai reiškia, kad reguliavimo institucijos gali juos savarankiškai patikrinti naudodamos standartinius įrodymų tikrinimo įrankius, nepasikliaudamos pirminiu patikros procesu.
Dweve automatiškai generuoja atitikties dokumentaciją iš patikros rezultatų ir suteikia galimybę ją pasiekti per Fabric portalą ir API. Tie patys įrodymai, kurie tenkina sprendiklį, tampa įrodymų paketu reguliavimo pateikimui.
Ateitis: patvirtintas DI kaip įprasta praktika
Esame lūžio taške diegiant dirbtinį intelektą. „Veik greitai ir laužyk dalykus“ era aukštos rizikos programoms baigiasi. Reguliavimo aplinka griežtėja. Atsakomybės rizika didėja. Draudimo iššūkiai kaupiasi.
Organizacijos, diegiančios dirbtinį intelektą reguliuojamose pramonės šakose, susiduria su pasirinkimu. Jos gali tęsti darbą su tradicinėmis architektūromis ir susidurti su vis didesne trintimi: ilgesniais patvirtinimo procesais, didesnėmis draudimo išlaidomis, didesne teisine rizika, galimu pašalinimu iš rinkos, kai reglamentai įsigalios.
Arba jie gali perimti patvirtintas architektūras, kurios reguliuotojus tenkina matematiniu tikrumu, o ne statistinėmis viltimis.
Verifikacijos revoliucija nėra apie tai, kad dirbtinis intelektas taptų mažiau pajėgus. Ji yra apie tai, kad dirbtinis intelektas taptų patikimas tais būdais, kurie svarbūs visiems už tyrimų laboratorijos ribų: pacientams, operatoriams, draudikams, reguliuotojams ir teismams. Ji yra apie tai, kad būtų kuriamas dirbtinis intelektas, kurį žmonės iš tikrųjų galėtų diegti su pasitikėjimu.
„Dweve“ - tikime, kad ateitis priklauso dirbtinio intelekto sistemoms, kurios gali įrodyti savo saugumą, o ne tik jį žadėti. Mūsų architektūra - nuo patvirtintų algoritmų „Core“ iki šešių lygių riboto autonomiškumo „Nexus“ ir 528 srities specialistų apribojimų rinkinių „Loom“ - nuo pat pradžių sukurta būtent šiai ateičiai.
Matematika, kuria grindžiamas tikrumas, nėra dirbtinio intelekto pažangos suvaržymas. Tai pamatas, ant kurio kuriamas plataus masto dirbtinio intelekto diegimas.
Pasiruošę diegti dirbtinį intelektą, kurį gali patvirtinti reguliavimo institucijos? „Dweve“ formaliai patvirtinta architektūra suteikia matematines garantijas, kurios reguliavimo kliūtis paverčia konkurenciniu pranašumu. Susisiekite su mumis, kad aptartume, kaip patvirtinimas gali pagreitinti jūsų kelią į rinką ir kartu sumažinti jūsų atsakomybės riziką.