NVIDIA SIGGRAPH: fizinis DI mokosi simuliuoti realybę

fizinis DI yra DI naujiena, kurią verta skaityti ne dėl triukšmo, o dėl praktikos. Ką tai keičia darbe? Kur atsiranda laiko sutaupymas? Kur prasideda nauja rizika?

NVIDIA SIGGRAPH naujienose kalba apie agentinį ir fizinį DI, grafiką, realaus laiko simuliacijas ir robotiką. Skamba kaip konferencijų salės magija. Bet žemiškai tariant, DI mokosi ne tik rašyti tekstą. Jis mokosi tikrinti veiksmus simuliacijoje prieš paliesdamas realų pasaulį.

Atvirai? Man DI temose mažiausiai įdomūs blizgantys pažadai. Įdomu, kur žmogus rytoj ryte atsidarys kompiuterį ir realiai padarys darbą kitaip. Be fejerverkų. Be teatro.

KAS NUTIKO

SIGGRAPH kontekste NVIDIA akcentuoja atvirus modelius, realaus laiko simuliaciją, kūrybos įrankius ir robotikos scenarijus. Tai svarbu dėl vienos priežasties: fizinis pasaulis neatleidžia klaidų taip lengvai kaip tekstinis atsakymas naršyklėje.

Šaltinis čia svarbus. Ne gandas, ne perpasakotas LinkedIn sakinys, o pirminis įmonės tekstas. Tokiose temose detalės greitai pavirsta telefonu sugedusiu žaidimu: vienas pranešimas tampa pažadu, pažadas tampa reklama, o po savaitės visi ginčijasi dėl dalyko, kurio niekas tiksliai neperskaitė.

KODĖL TAI SVARBU

Kai DI parašo prastą pastraipą, ją pataisai. Kai robotas neteisingai supranta aplinką, pasekmės brangesnės. Todėl simuliacijos tampa lyg treniruočių salė. Pirmiau daug kartų nukrenti virtualiai, tada atsargiau eini į gamyklą, sandėlį ar kelią.

DI versle jau nebėra vien klausimas „kokį įrankį nusipirkti“. Dabar klausimas daug žemiškesnis: kur tas įrankis įsėda į procesą, ką jis gali matyti, ką gali keisti ir kas patikrina rezultatą. Be šitų atsakymų net geras modelis tampa dar vienu langeliu naršyklėje.

KUR TAI PRITAIKYTI

Pradėti verta nuo vienos vietos, kur darbas kartojasi ir visi tyliai kenčia. Žinot tą jausmą, kai komandoje niekas nebenori liesti tam tikros lentelės, bet visi žino, kad be jos nepajudėsi? Va ten dažnai ir prasideda DI vertė.

• Gamyba gali testuoti robotų veiksmus skaitmeniniame modelyje prieš stabdydama liniją.
• Kūrybos komandos gali greičiau kurti 3D scenas ir vizualinius prototipus.
• Autonominių sistemų kūrėjai gali simuliuoti retus, bet pavojingus scenarijus.

Gera taisyklė paprasta: jei darbą galima aprašyti trimis sakiniais ir patikrinti per kelias minutes, jis tinka pirmajam DI bandymui. Jei reikia dešimties išimčių ir „čia priklauso nuo situacijos“, pirmiausia susitvarkykite procesą.

KUR PASISLĖPUSI RIZIKA

Pavojus – patikėti, kad graži simuliacija lygi realybei. Realiame pasaulyje yra dulkės, prasta šviesa, žmonės, keisti kampai ir nuovargis. Modelis turi būti tikrinamas ten, kur jis dirbs.

Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiu sakiniu, tvarkinga struktūra ir tonu, kuris skamba užtikrintai. Čia smegenys ir užkimba: „atrodo gerai, vadinasi gerai“. Deja, versle taip neveikia.

KĄ DARYTI ŠIĄ SAVAITĘ

Jei turite fizinį procesą, pradėkite nuo vieno scenarijaus simuliacijos: kur klaida brangiausia ir kur ją galima saugiai pakartoti virtualiai.

Mano siūlymas: nebandykite laimėti viso DI žaidimo per vieną savaitę. Paimkite vieną procesą, vieną komandą, vieną matavimą. Tada žiūrėkite, ar žmogui realiai liko mažiau darbo, ar tiesiog atsirado nauja vieta tikrinti DI.

DUK

Ar fizinis DI aktualu mažam verslui?

Taip, jei verslas turi pasikartojančių informacijos darbų. Jei procesas vyksta kartą per metus, pasiruošimo kaina gali suvalgyti naudą.

Ar tam reikia programuotojų komandos?

Ne visada. Pirmam bandymui dažnai užtenka aiškaus proceso, gerų duomenų ir žmogaus, kuris moka patikrinti rezultatą. Techninė komanda reikalinga tada, kai DI jungiamas prie vidinių sistemų.

Kokia dažniausia klaida?

Pradėti nuo įrankio, o ne nuo problemos. Įrankių daug. Aiškiai suformuluotų problemų – mažiau.

Jei norite DI pritaikyti praktiškai, pradėkite nuo vieno proceso audito. MasterSprint programoje būtent taip ir žiūrime į DI: mažiau triukšmo, daugiau realių darbų. Daugiau rasite MasterSprint.

Šaltinis: NVIDIA.