Hogyan teszteljük az MI-t?
Komoly gondot jelent, hogy nincs elegendő szakember, aki az MI hibákat — amit a szakmában hibakeresésnek (red teaming) neveznek — profi módon vizsgálja. Bár egyre több startup alkalmaz belső vagy szerződéses tesztelőket, a szakértők szerint szükség lenne arra is, hogy hétköznapi felhasználók, újságírók, kutatók és etikus hackerek is hozzáférhessenek a rendszerekhez. Sok esetben a modellek olyan hibákat generálnak, amelyek felismeréséhez jogi, orvosi vagy tudományos végzettségre van szükség; egy átlagos felhasználó gyakran nem tudja eldönteni, hogy tényleg hibáról van-e szó.
Az MI hibák standardizált jelentése, az információk megosztása, sőt, az ilyen hibák megtalálásáért járó jutalmak bevezetése hatékonyabbá tenné a védelmet. Ez a megközelítés más IT-biztonsági területeken már bevált.
Ipágarági példák: Holdraszállás projekt (Project Moonshot)
A Holdraszállás projekt (Project Moonshot) nevű kezdeményezés Szingapúrban indult, és a nagyvállalatok – például az IBM – is csatlakoztak hozzá. Az eszköztár célja, hogy átfogóan tesztelje az MI-rendszereket: szabványos összehasonlításokat, hibakeresést, gyorsteszteket kínál, ráadásul bárki kipróbálhatja, vagyis nem zárják ki a külső tesztelőket sem. A program bevezetését vegyesen fogadták, de a startupok többsége már most is használja. A jövőben iparágra szabott, többnyelvű és kulturálisan érzékeny tesztelési lehetőségeket terveznek, amelyek tovább növelik a biztonságot.
Miért kell gyógyszergyári szintű tesztelés?
A jelenlegi gyakorlattal szemben, ahol a tech cégek megfelelő előzetes ellenőrzés nélkül teszik elérhetővé az új MI-modelleket, egy vezető statisztikai professzor szerint szigorú, gyógyszeripari szintű jóváhagyási eljárásra lenne szükség. Egy új gyógyszert vagy repülőgépet csak több hónapos komoly tesztelés után lehet forgalomba hozni, ezzel szemben az MI-modellekkel szemben nincsenek ilyen elvárások.
A jövőben érdemesebb lehet olyan MI-rendszereket fejleszteni, amelyek konkrét feladatokra készülnek, nem pedig mindenhez „is” értenek — hiszen minél általánosabb egy modell, annál több hibalehetőséget kell előre látni, ami szinte lehetetlen.
A cégeknek nem szabad túl magabiztosnak lenniük a védelmi rendszereikkel kapcsolatban, hiszen a nagy, általános modelleknél szinte lehetetlen meghatározni, hogy pontosan mi számít biztonságosnak vagy veszélyesnek.
