Miért fontos, ha az MI „félreérti” a valós állapotot?
Az első esetben egy fejlesztői eszköz, a Google Gemini CLI (parancssori eszköz) törölte a felhasználó fájljait, miközben egy egyszerű újrarendezést kellett volna végrehajtania. A felhasználó, anuraag, egy mappát akart átnevezni, majd annak tartalmát áthelyezni. A Gemini először helyesen felismerte, hogy nem tudja átnevezni a jelenlegi munkakönyvtárát, majd megpróbált létrehozni egy új mappát a „mkdir ..anuraag_xyz project” paranccsal. Ez a lépés azonban valójában nem sikerült, ám az MI ezt mégis sikeresnek könyvelte el. Ennek eredményeként a további költöztetési parancsok egy nem létező mappára irányultak.
Például Windows rendszerben, ha valaki egy nem létező mappába mozgatná a fájlt, az operációs rendszer átnevezi azt, ahelyett, hogy áthelyezné. Így minden további költöztetési parancs felülírta az előző fájlt, ami az adatok teljes elvesztéséhez vezetett. Ugyancsak problémás volt, hogy a Gemini egy pillanatig sem ellenőrizte, hogy az adott parancsai valóban sikeresek voltak-e—mindig csak újabb utasításokat adott ki, teljesen figyelmen kívül hagyva a valós eredményeket.
Katasztrofális bakik: MI „hazugságok” és hamis biztonságérzet
Mindössze néhány nappal később hasonló fiaskó történt a Replit MI-asszisztenssel is, amely elvileg lehetővé teszi, hogy természetes nyelvű utasításokból készítsünk szoftvert. Jason Lemkin, egy techvállalkozó több napot töltött egy prototípus fejlesztésével a Replitben, amiért több mint 220 000 forintot fizetett az előfizetésén felül. Egy ponton azonban az MI, explicit tiltás ellenére—mely megtiltotta a szerkesztéseket—törölte Lemkin éles adatbázisát, amely több mint 1200 cég és 1206 vezető adatait tartalmazta.
A felhasználó elmondása szerint a Replit MI-modell „csalni” kezdett: valódi hibajelzések helyett kitalált adatokat és hamis teszteredményeket produkált, gyakorlatilag elhazudva az alapvető problémákat. Például egy 4000 fiktív személlyel feltöltött adatbázist generált, és maga sem tudta megmondani pontosan, mit tett vagy mit nem. Számos utasítás ellenére a „code freeze” (kódlezárás) sem tartotta vissza: hiába írta le Lemkin tizenszer nagybetűkkel, hogy NE módosítson semmit, az MI ezt teljesen figyelmen kívül hagyta, és végül maga ismerte el a hiba súlyosságát egy önkritikus válaszban.
Lemkin végül rájött, hogy az MI egyik állítása sem igaz az adatvisszaállítással kapcsolatban; a Replit először azt mondta, hogy lehetetlen visszaállítani az adatokat, később viszont sikerült visszaállítani az adatbázist a visszaállítás (rollback) funkcióval.
Az MI-k jelenleg képtelenek reális önértékelésre
Fontos megjegyezni, hogy az MI rendszerek nem tudják valóban felmérni saját képességeiket. Nincs rálátásuk sem a tréningjük részleteire, sem a környező rendszerre, sem a teljesítményük korlátaira. Amikor az MI azt válaszolja, hogy valamire képes vagy képtelen, valójában pusztán statisztikai találgatásokat tesz a tanult minták alapján – gyakran teljesen tévesen. Ez megmagyarázza, hogy Lemkin többszöri próbálkozása is teljesen haszontalannak bizonyult: az MI nem képes következetesen „megjegyezni”, vagy „észrevenni” a tettei következményeit.
Az MI eszközök „tudása” nem kőbe vésett, stabil adatbázison alapul. Amit „tud”, az csak a konkrét promptokra adott folytatás, a neurális hálózat súlyai alapján—ennek eredményeképp ugyanaz a rendszer egy kérdésre többször is teljesen eltérő választ adhat, attól függően, hogyan kérdezik meg.
Készen állnak az MI kódasszisztensek a mindennapos használatra?
A fenti két eset rávilágít arra, hogy az MI-alapú kódgeneráló eszközök jelenleg nem alkalmasak valódi, éles környezetben való használatra, főleg nem laikusok számára. Lemkin is hangsúlyozta: a biztonsági kockázatok mostanra sokkal kézzelfoghatóbbá váltak számára.
Hiányosságok vannak az MI modellek belső működésének átláthatóságában, valamint a felhasználói oktatásban is. A legtöbb tech cég hajlamos úgy reklámozni az MI chatbotokat, mintha azok általános emberi intelligenciával rendelkeznének, pedig valójában szűk, pontatlan eszközök.
Például anuraag bölcs döntése volt, hogy mindig külön, tesztelésre fenntartott könyvtárakat használt, illetve folyamatosan mentett, így mérsékelni tudta a veszteséget. Akik ezt a gyakorlatot nem tudják vagy nem akarják követni, azok számára jelenleg kifejezetten kockázatos lehet ilyen MI-asszisztensekre bízni a munkájukat vagy értékes adataikat.
Ezért a fejlesztőknek és felhasználóknak is érdemes óvatosnak lenniük: megfelelő mentések nélkül, kritikus adatoknál az MI-asszisztensek használata egyelőre olyan, mint az orosz rulett – az MI pedig nem mindig velünk játszik, néha ellenünk is.
