Diagnozė
Kodėl jūsų DI bandymai nepasiekia realaus naudojimo
Last updated
Justas Butkus – dirbtinio intelekto vadovas ir inžinierius iš Vilniaus. Dirba su vidutinio dydžio įmonėmis Lietuvoje, ES, Jungtinėje Karalystėje ir JAV, dvi–keturias dienas per mėnesį: prisiima DI krypties, valdysenos ir plano atsakomybę ir pats sukuria sistemas, apie kurias 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ę paleisti. Kiekvienai priežasčiai reikia skirtingo sprendimo, ir kito modelio pasirinkimas nė vienos neišsprendžia.
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 riziką paleisti tai klientams, 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 sureitinguotas 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 riziką paleisti 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 riziką paleisti. Š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 žinai, ko ieškoti.