Diagnozė
Kodėl jūsų DI bandymai nepasiekia realaus naudojimo
Atnaujinta
Justas Butkus – dirbtinio intelekto specialistas iš Vilniaus. Dirba su vidutinio dydžio įmonėmis Lietuvoje, ES, Jungtinėje Karalystėje ir JAV, nuo dviejų iki keturių dienų per mėnesį: prisiima DI krypties, valdysenos ir plano atsakomybę ir pats sukuria tas sistemas, dėl kurių konsultuoja.
Trumpai
DI bandymai stringa dėl trijų priežasčių ir technologija beveik niekada nėra viena iš jų: pasirinktas ne tas procesas, duomenys jo neatlaikė arba nėra žmogaus, kuris prisiimtų atsakomybę už paleidimą. Kiekvienai priežasčiai reikia skirtingo sprendimo ir kito modelio pasirinkimas nė vienos neišsprendžia.
Kokios yra trys priežastys pagal dažnumą?
Priežastys kartojasi ir konkreti naudojama technologija jose beveik nefigūruoja.
- Procesas pasirinktas todėl, kad buvo įdomus, o ne brangus. Kažkas parodė įspūdingą demonstraciją, o pagrindimas sugalvotas atbulai. Sistema veikia ir jos niekam netrūksta, kai sustoja.
- Duomenys neatlaikė. Ne todėl, kad jų trūksta, o todėl, kad tas pats laukas skirtingose sistemose reiškia skirtingus dalykus. Paaiškėja vėlai, nes visi mano, kad jų duomenys tvarkingi.
- Nebuvo kam nuspręsti paleisti. Bandymas pavyko. Paskui klausimas, kas prisiima paleidimo klientams riziką, liko be atsakymo ir viskas įstrigo bandymo būsenoje.
Kaip suprasti, kuri priežastis jūsų?
| Požymis | Tikėtina priežastis | Kas iš tikrųjų padeda |
|---|---|---|
| Veikia, bet niekas neprašo | Netinkamas procesas | Rinktis pagal kainą ir dažnį, ne pagal naujumą |
| Testuose tikslu, realybėje – ne | Skirtingos duomenų sąvokos | Suvienodinti apibrėžimus prieš liečiant modelį |
| Nesibaigiantys papildomi vertinimai | Nėra kam prisiimti rizikos | Paskirti atsakingą ir aprašyti grįžimą atgal |
| Kiekvienas skyrius daro savo | Nėra įmonės lygio įgaliojimo | Vienas pagal svarbą surikiuotas planas su pagrindimu |
| Sustabdė teisė ar atitiktis | Valdysena prisiminta per vėlai | Priežiūrą projektuoti iš karto |
Kodėl kitas modelis retai padeda?
Dažniausia reakcija į įstrigusį projektą – pabandyti geresnį modelį. Tai patrauklu, nes sprendžiama, ir beveik niekada nepašalina tikrosios kliūties.
Jei procesas nebuvo vertas automatizuoti, geresnis modelis pateiks geresnį sprendimą problemai, kurios niekas neturėjo. Jei duomenys nenuoseklūs, geresnis modelis tiksliau išmoks tą nenuoseklumą. Jei niekas neprisiima atsakomybės paleisti, modelio kokybė niekada ir nebuvo kliūtis.
Dažniausi klausimai
Kodėl dauguma DI projektų nepasiekia realaus naudojimo?
Retai dėl technologijų. Dažniausios priežastys – procesas pasirinktas dėl naujumo, o ne dėl kainos, vėlai paaiškėja, kad duomenų sąvokos skirtingose sistemose nesutampa, ir nėra žmogaus, pasirengusio prisiimti paleidimo riziką sistemą klientams.
Ar geresnis modelis išspręstų mūsų problemą?
Paprastai ne. Geresnis modelis sprendžia gebėjimų problemą, o dauguma įstrigimų yra atrankos, duomenų arba atsakomybės problemos.
Kaip pasirinkti pirmą DI projektą?
Rinkitės procesą, kuris yra brangus, dažnas ir pasikartojantis, o ne tą, kurį įspūdinga parodyti. Tinkamas pirmas projektas paprastai nuobodus, o jo vertė ateina iš kiekio, ne iš sudėtingumo.
Kas įmonėje turėtų atsakyti už DI diegimą?
Vienas įvardytas žmogus, turintis įgaliojimą nuspręsti, kas kuriama, ir prisiimti paleidimo riziką. Šios atsakomybės išskaidymas komitetui yra patikimiausias būdas gauti bandymus, kurie niekada nepaleidžiami.
Jei tai apibūdina paskutinius du jūsų projektus
Diagnozė paprastai greita, nes trys priežastys atrodo gana skirtingai, kai žinoma, ko ieškoti.