Most mutatta be az OpenAI, hogy olyan mesterséges intelligenciát alkottak, ami képes kirakni egy robotkézben tartva egy Rubik kockát.Youtube videó itt. Blogbejegyzés itt.Azt hiszem, hogy egy kicsit fontos értelmeznem ezt a hírt, mert lehet, hogy nem olyan egyszerű megérteni, miért is olyan fontos ez és amúgy is, mennyire is fontos.
Solving Rubik’s Cube with a Robot Hand
Először is, messze nem ez az első robot, ami képes kirakni a Rubik kockát, itt van pl. ez, amely sokkal gyorsabban csinálja, ráadásul ez mindig képes kirakni, az OpenAI megoldása meg nem mindig.A két megoldás között az a különbség, hogy az első megoldás sokkal általánosabbnak tűnő módszerekkel készült, mint a második. Mindkét megoldáshoz elég sok ember kellett, meg néhány év kemény munka, viszont elvileg az első megoldás nagyon sok hasonló feladatra alkalmazható módszereket dolgozott ki, míg a második módszerben inkább az emberek fejlődtek sokat a probléma megértésében és számítógépes modellezésben. Ha mindkét esetben elküldjük az embereket vakációzni és új csapattal szeretnénk megoldani azt a feladatot, hogy egy kéz valamilyen gömb alakú tárgyon gombokat nyomogasson valamilyen sorrendben, akkor az első módszerrel csak annyit kell tenni, hogy készítünk a feladatról egy virtuális modellt és írunk egy kis programocskát, ami nagyjából ki tudja értékelni a megnyomott gombok sorrendjét, hogy mennyire felel meg az elvártnak, utána pedig rengeteg számítógépet rátenni, hogy szimulálják ezt a feladatot és addíg próbálkozzanak a megoldásokkal, amíg elfogadható az eredmény. A második módszerrel mindent előlről kell kezedeni, tehát kell tervezni egy olyan robotot, ami képes egy gömböt megtartani, megforgatni, felismerni rajta a gombokat, megnyomni azokat és utána a helyes forgató és megnyomó műveleteket végrehajtani, a jó sorrendben. Egyébként, ha kevés számítógép áll rendelkezésünkre, még mindig lehet, hogy ez a gyorsabb módszer, az első ugyanis rengeteg számítási kapacitást igényel egyelőre, de jelenleg erről az az általános vélekedés, hogy nem jelent gondot, mert egyrészt az algoritmusokat is tudjuk gyorsítani és a számítógépek is gyorsulnak még, bár már egyre nehezebb kihozni belőlük az optimális teljesítményt.Ez lehet, hogy még zavarosabb mint eddig volt. A lényeg az, hogy a tanuló algoritmusokon alapuló problémamegoldás most nagyon népszerű, mert úgy gondoljuk, hogy bármeddig képesek vagyunk javítani a teljesítményüket, csak elég idő és energiát kell rá szánni. Erről biztos fogok még írni.Ami számomra igazán érdekes, az az, hogy hogyan oldották meg a szimulációban tanult mozgás való világba való átültetését. Az utóbbi pár évben jelent meg ez a technika, amit domain randomizationnak nevezük, ami nagyjából azt jelenti, hogy véletlenszerűsítjük a szimuláció egyes paramétereit és ezzel kényszerítjük a tanuló rendszert arra, hogy ne csak a képben található apró jeleket tanulgassa, hanem próbálja megérteni azokat az összefüggéseket, amelyek mindig igazak, a pixelek színétől függetlenül. Persze, ha véletlenszerűséget alkalmazunk, akkor (szinte) mindig lassabb lesz az algoritmusunk, hiszen sok esetet ki kell próbáljon. Viszont most úgy tűnik, hogy ez egy jó módszer arra, hogy robusztus eredményeket érjünk el, szóval a szimlációban tanultak a való világban is alkalmazhatóak legyenek, ahol sosem lehet tudni, hogy egy zsiráf mikor zavar be a képbe.Ez a módszer jelenleg az egyetlen olyan módszer, ami engem egy kicsit is meggyőz, hogy valamikor önvezető autókat fogunk tudni készíteni, hiszen ha egy véletlenszerűsített világban el fog tudni vezetni az autónk, akkor a való világban sem lehet neki gondja. Az egyetlen gond csak az, hogy elég nehéz egy bonyolultabb véletlenszerűsített világot szimulálni, ugyanis azt még relatív egyszerű, hogy mindenféle állat átvonulhasson az autó előtt, de hogyan fogjuk szimulálni a különböző alkoholszinttel rendelkező többi söfört szimulálni? Egy megoldás lehet az, hogy szép lassan haladunk a véletlenszerűsítéssel, először csak kicsit rángatják a kormányt, aztán jobban, stb. de nehéz kérdés az, hogy konvergál-e ez valaha. Meglátjuk, remélem azért nem olyan sok idő múlva.Miért fontos ez az eredmény? Szerintem egy fontos lépés ez azon az úton, hogy komolyabban kezdjenek sokan az olyan robotok fejlesztésén dolgozni, amelyeknek fontos lesz az, hogy kezük legyen, szóval vagy emberekkel kell együttműködjenek, vagy nagyon általános feladatokat kell megoldjanak, amelyekhez nagyon hasznos ez az architektúra, vagy mindkettő.Persze, a tanuló algoritmus skálázása is fontos lesz, de ezt az OpenAI is tudja, az ő robotkezük sem tud feldobni egy labdát és elkapni azt. Azt sem tudja, hogy szóban közöljük vele ezt a feladatot. És ők is tisztában vannak azzal, hogy ennyi tanítási idő (valahol 10000 óra körüli szimulációs időt láttam, talán a cikkben szerepel ez, én nem olvastam el, annyira nem érdekel ez a feladat :)) nem elfogadható egy ilyen feladat megoldásához, szóval jobb ha nekifognak kidolgozni valami módszert, amivel faktorizálni (felosztani) tudják a feladatot egy általános és egy specifikus részre, amelyből az általánost jó lenne csak egyszer betanulni. Ez egyébként a mesterséges intelligencia egyik legnagyobb rákfenéje mostanság, szóval pont jó lesz ebben az esetben is tanulmányozni.
Solving Rubik’s Cube with a Robot Hand
Először is, messze nem ez az első robot, ami képes kirakni a Rubik kockát, itt van pl. ez, amely sokkal gyorsabban csinálja, ráadásul ez mindig képes kirakni, az OpenAI megoldása meg nem mindig.A két megoldás között az a különbség, hogy az első megoldás sokkal általánosabbnak tűnő módszerekkel készült, mint a második. Mindkét megoldáshoz elég sok ember kellett, meg néhány év kemény munka, viszont elvileg az első megoldás nagyon sok hasonló feladatra alkalmazható módszereket dolgozott ki, míg a második módszerben inkább az emberek fejlődtek sokat a probléma megértésében és számítógépes modellezésben. Ha mindkét esetben elküldjük az embereket vakációzni és új csapattal szeretnénk megoldani azt a feladatot, hogy egy kéz valamilyen gömb alakú tárgyon gombokat nyomogasson valamilyen sorrendben, akkor az első módszerrel csak annyit kell tenni, hogy készítünk a feladatról egy virtuális modellt és írunk egy kis programocskát, ami nagyjából ki tudja értékelni a megnyomott gombok sorrendjét, hogy mennyire felel meg az elvártnak, utána pedig rengeteg számítógépet rátenni, hogy szimulálják ezt a feladatot és addíg próbálkozzanak a megoldásokkal, amíg elfogadható az eredmény. A második módszerrel mindent előlről kell kezedeni, tehát kell tervezni egy olyan robotot, ami képes egy gömböt megtartani, megforgatni, felismerni rajta a gombokat, megnyomni azokat és utána a helyes forgató és megnyomó műveleteket végrehajtani, a jó sorrendben. Egyébként, ha kevés számítógép áll rendelkezésünkre, még mindig lehet, hogy ez a gyorsabb módszer, az első ugyanis rengeteg számítási kapacitást igényel egyelőre, de jelenleg erről az az általános vélekedés, hogy nem jelent gondot, mert egyrészt az algoritmusokat is tudjuk gyorsítani és a számítógépek is gyorsulnak még, bár már egyre nehezebb kihozni belőlük az optimális teljesítményt.Ez lehet, hogy még zavarosabb mint eddig volt. A lényeg az, hogy a tanuló algoritmusokon alapuló problémamegoldás most nagyon népszerű, mert úgy gondoljuk, hogy bármeddig képesek vagyunk javítani a teljesítményüket, csak elég idő és energiát kell rá szánni. Erről biztos fogok még írni.Ami számomra igazán érdekes, az az, hogy hogyan oldották meg a szimulációban tanult mozgás való világba való átültetését. Az utóbbi pár évben jelent meg ez a technika, amit domain randomizationnak nevezük, ami nagyjából azt jelenti, hogy véletlenszerűsítjük a szimuláció egyes paramétereit és ezzel kényszerítjük a tanuló rendszert arra, hogy ne csak a képben található apró jeleket tanulgassa, hanem próbálja megérteni azokat az összefüggéseket, amelyek mindig igazak, a pixelek színétől függetlenül. Persze, ha véletlenszerűséget alkalmazunk, akkor (szinte) mindig lassabb lesz az algoritmusunk, hiszen sok esetet ki kell próbáljon. Viszont most úgy tűnik, hogy ez egy jó módszer arra, hogy robusztus eredményeket érjünk el, szóval a szimlációban tanultak a való világban is alkalmazhatóak legyenek, ahol sosem lehet tudni, hogy egy zsiráf mikor zavar be a képbe.Ez a módszer jelenleg az egyetlen olyan módszer, ami engem egy kicsit is meggyőz, hogy valamikor önvezető autókat fogunk tudni készíteni, hiszen ha egy véletlenszerűsített világban el fog tudni vezetni az autónk, akkor a való világban sem lehet neki gondja. Az egyetlen gond csak az, hogy elég nehéz egy bonyolultabb véletlenszerűsített világot szimulálni, ugyanis azt még relatív egyszerű, hogy mindenféle állat átvonulhasson az autó előtt, de hogyan fogjuk szimulálni a különböző alkoholszinttel rendelkező többi söfört szimulálni? Egy megoldás lehet az, hogy szép lassan haladunk a véletlenszerűsítéssel, először csak kicsit rángatják a kormányt, aztán jobban, stb. de nehéz kérdés az, hogy konvergál-e ez valaha. Meglátjuk, remélem azért nem olyan sok idő múlva.Miért fontos ez az eredmény? Szerintem egy fontos lépés ez azon az úton, hogy komolyabban kezdjenek sokan az olyan robotok fejlesztésén dolgozni, amelyeknek fontos lesz az, hogy kezük legyen, szóval vagy emberekkel kell együttműködjenek, vagy nagyon általános feladatokat kell megoldjanak, amelyekhez nagyon hasznos ez az architektúra, vagy mindkettő.Persze, a tanuló algoritmus skálázása is fontos lesz, de ezt az OpenAI is tudja, az ő robotkezük sem tud feldobni egy labdát és elkapni azt. Azt sem tudja, hogy szóban közöljük vele ezt a feladatot. És ők is tisztában vannak azzal, hogy ennyi tanítási idő (valahol 10000 óra körüli szimulációs időt láttam, talán a cikkben szerepel ez, én nem olvastam el, annyira nem érdekel ez a feladat :)) nem elfogadható egy ilyen feladat megoldásához, szóval jobb ha nekifognak kidolgozni valami módszert, amivel faktorizálni (felosztani) tudják a feladatot egy általános és egy specifikus részre, amelyből az általánost jó lenne csak egyszer betanulni. Ez egyébként a mesterséges intelligencia egyik legnagyobb rákfenéje mostanság, szóval pont jó lesz ebben az esetben is tanulmányozni.
Nincsenek megjegyzések:
Megjegyzés küldése