Pagkatapos ng isang seryosong near-miss, hindi lang hinihiling ng isang imbestigador mula sa National Transportation Safety Board sa airline na mag-file ng pribadong tala at magpatuloy. Pumapasok ang pangyayari sa isang sistema. Isinusulat ang mga findings para mabago ng mga designer, trainer, at regulator ang kanilang pag-uugali. Ang pasaherong hindi kailanman narinig ang kuwento ay lumilipad pa rin sa loob ng update. Bahagi ng malaking dahilan kung bakit naging ligtas ang commercial flying ang shared memory na ito.
Ang AI incident reporting ay ang pagtatangkang bigyan ang larangang ito ng parehong ugali: sistematikong pagtatala, pagbabahagi, at pagsisiyasat ng mga kaso kung saan nagdudulot ng pinsala o malapit nang magdulot ng pinsala ang mga sistema. Kapag nabigo ang isang model sa deployment, nalusutan ang guardrails nito sa misuse, o nagpakita ng mapanganib na behavior sa testing, wala pa ring pare-parehong tungkulin na itala ito, walang shared na lugar na dapat tumanggap nito, at walang standard na landas ng pagsisiyasat. Ang mga aral na maaaring makapagprotekta sa lahat ay nananatili sa loob ng isang kumpanya, o nawawala.
Simple lang ang proposal sa papel: tukuyin ang mga kategorya ng pinsala at near-miss, kailanganin ang pag-uulat sa isang shared system, at hayaang matuto ang field nang sabay-sabay.
Ang makuha ng isang mabuting sistema
Ang kapaki-pakinabang na bersyon ay mas malawak kaysa sa headline na mga sakuna.
- Mga pinsalang na-deploy, kung saan nagdulot ng pinsala o malubhang malfunction ang isang sistema sa totoong mundo.
- Near-misses, kung saan may nangyaring mali at halos maiwasan ang pinsala. Tinatrato ng aviation ang mga ito na kasing-informatibo ng mga pagbagsak.
- Mapanganib na mga pag-uugali na natagpuan sa pagsusuri, kasama ang mga pagkabigo na lumitaw dahil sa red teaming at evaluations, kaya umabot sa iba ang hazard warning ng isang lab.
- Mga security events, tulad ng mga pagtatangka na magnakaw ng model weights o lampasan ang mga safeguards.
Kailangang structured ang pag-uulat, at kung kinakailangan, protektado. Mas tapat na nag-uulat ang mga organisasyon kapag hiwalay ang safety investigation sa blame theater. Natutunan ito ng aviation para sa isang dahilan. Kung wala ito, ang makatwirang hakbang ay ang katahimikan.
Bakit ito sulit gawin
Pinapayagan ng shared incident data ang larangan na makita ang mga pattern na hindi makikita ng isang organisasyon. Nakakakuha ang mga regulator ng base ng ebidensya na nakabatay sa aktwal na nangyayari kaysa sa haka-haka. Nagiging babala ng lahat ang failure mode ng isang lab sa linggo na natuklasan ito. Sa paglipas ng panahon, nakakakuha ang industriya ng institutional memory na wala pa rito. Sa mga ASI governance measures, ito ang mura, malawakang tinatanggap, at overdue na. Gusto itong gawing mandatory ng Foundation.
Ang kilalang pagtutol, pinangalanan
Ayon sa optimistic version, napatunayan ng aviation ang pamamaraan: patuloy na mag-ulat, mag-imbestiga, at bababa ang catastrophic risk tulad ng pagbaba ng hull-loss rates. Sa pananaw na ito, ang incident systems ang pangunahing safety engine, at ang anticipatory limits ay distraction hanggang sa mayroon tayong mas maraming crash data.
Pansinin ang tense na pinatatakbo ng engine. Retrospective ang incident reporting. Natututo ito mula sa mga pinsalang nangyari na. Gumagana ito kapag survivable ang mga failure, gaano man kalungkot, sa antas ng industriya, kaya’t bawat isa ay maaaring magturo sa fleet. Nagpapabuti ang sistema sa bawat event.
Nabibigo ang lohika na iyan sa mga panganib na pinakamahalaga sa Foundation. Isang sakuna na pagkabigo ng superintelligent system ay hindi board na tinatawag pagkatapos. Ang pangunahing claim ng existential risk ay ang pinakamalalang kabiguan ay maaaring ang walang pagbawi at samakatuwid walang aral. Ang incident reporting ay mahusay sa paghawak ng mga pinsalang naipon at nalalagpasan. Sa disenyo nito ay hindi nito kayang harapin ang hindi na maibabalik.
Ang pag-aaral mula sa mga pagkabigo ay ipinapalagay na mabubuhay ka rito. Sa mga pagkabigo na pinakamahalaga, ang palagay na iyon mismo ang problema.
Saan ito naroroon
Buuin ang sistema. Iutos ito. Protektahan ang tapat na pagbubunyag. Pagkatapos ay ilayo ito sa tuktok ng toolkit. Dapat itong tumabi sa anticipatory limits at verification na nakasaad sa aming plano, na eksaktong umiiral dahil may mga kabiguan na hindi na kayang hawakan pagkatapos mangyari.