Frá óvissu til árangurs í þróun gervigreindarlausna

Gervigreindarlausnir snúast í eðli sínu um að leysa hið ófyrirséða. Hvernig breytir það nálgun okkar á þróun þeirra?  

Sigurður Óli Árnason, vöruþróunarstjóri, fjallar um hvernig óvissa er ekki galli í gervigreindarlausnum heldur eðlislægur fylgifiskur þeirra og það sé okkar að hafa stjórn á henni. 

Við hjá DataLab höfum síðan 2016 þróað gervigreindarlausnir fyrir íslenska aðila. Umhverfið hefur á þessum tíma breyst mikið. Þar til nýlega var oft litið á slík verkefni sem gæluverkefni sem skiptu ekki grundvallarmáli í starfseminni. Í dag eru slík verkefni og lausnir að verða að mikilvægum stoðum í starfsemi fyrirtækja og stofnana. Þegar lausnirnar verða mikilvægari aukast kröfurnar og við færumst frá því að fikra okkur áfram með frumútgáfur yfir í það að vera með lausnir í framleiðslu. 

Það er ofboðslega margt öðruvísi við að koma lausn í framleiðslu (production) en að setja upp frumútgáfu (pilot). Þessi munur er annars vegar tæknilegur en einnig er mikill munur á því hvernig nálgast þarf verkefnið út frá sjónarhorni verkefnis- og vörustýringar. Rannsóknir sýna að meirihluti gervigreindarverkefna komast ekki í framleiðslu. Í tilfelli hinnar nýju spunagreindartækni er hlutfallið ótrúlega hátt sem endar ekki með að skapa virði, enda ýmsir aðilar að prófa sig áfram með fjölbreytt viðfangsefni. 

Af hverju klikka gervigreindarverkefni? 

Nokkrar meginástæður eru oft nefndar fyrir því þegar þróun gervigreindarlausnar telst illa heppnuð: 

• Ekki rétt vandamál valið til að leysa eða illa skilgreint 
• Ófullkomin gögn og gagnainnviðir 
• Tæknin hentar ekki verkefninu eða er ekki nógu þroskuð 
• Menning, stjórnun, regluvarsla 

Þetta eru hins vegar almenn atriði sem eiga líka við um þróun almennra tæknilausna. Samkvæmt rannsóknum klikka gervigreindarverkefni töluvert oftar en önnur hugbúnaðarverkefni og dreg ég þá ályktun að það sé einhver eðlismunur á þeim og öðrum hugbúnaðarverkefnum. 

Ég tel að þessi eðlismunur felist í þeirri staðreynd að gervigreindarverkefni þurfi að kljást við óvissu sem klassískari hugbúnaðarverkefni þurfa ekki að kljást við. Gervigreindarverkefni snúast nefnilega í eðli sínu um að leysa hið ófyrirséða. 

Óvissa 

Hér er kannski mikilvægt að greina sundur tvo meginflokka lausna sem við höfum verið að þróa, og byggja á gervigreind; spunagreind og spálíkön. Þær eru mismunandi eðlis en eiga þó sameiginlegt að hugsa þarf um þær á annan hátt en venjulegar hugbúnaðarlausnir því  óvissa fylgir óhjákvæmilega þróun þeirra. 

Spálíkön 

Helsta óvissan í þróun spálíkans liggur í gæðum og eðli gagnanna. Erfitt er að vita fyrirfram hversu vel er yfir höfuð hægt að spá fyrir um útkomurnar út frá gögnunum. Ef ekki eru næg gögn eða nógu góð gögn er sama hversu gott líkan er þróað, útkoman verður aldrei góð. Hins vegar er einnig mögulegt að aðgengi að hágæðagögnum mörg ár aftur í tímann sé heldur ekki nægjanlegt vegna þess að gögnin segja einfaldlega ekki nóg um það sem spá á fyrir um. 

Stundum eru spálíkön notuð til að stýra birtingu atriða í grafísku viðmóti, t.d. meðmælakerfi á sölusíðu. Þá liggur óvissan í því hversu erfitt er að skilgreina vænta hegðun (e. expected behavior). Það er ómögulegt að skilgreina með nákvæmum hætti hvaða vörur eiga að koma upp sem meðmæli fyrir hvern notanda. Ef það væri hægt þyrfti ekki að þróa spálíkan til að búa til meðmælin. Því getur verið erfitt að setja upp góðar sjálfvirkar prófanir og hafa góða heildarsýn yfir hvernig fítusinn er að virka. Vissulega eru til alls konar aðferðir við að gefa tölulegar mælingar til að meta gæði slíkra líkana en það getur verið erfitt fyrir hagaðila verkefnis að átta sig á þeim og setja þá í samhengi við hegðun lausnar.  

Það má bera þetta saman við þá staðreynd að leitarfítusar á íslenskum síðum hafa lengi verið fremur lélegir. Ég tel að ástæðan fyrir því sé vegna þess að leitarvirknin krefst annarrar nálgunar í prófun og hönnun en klassískari viðmót. Vegna þess hefur þessi fítus verið skilinn útundan. 

Spunagreind 

Spunagreindarlausnir, eins og við nálgumst þær hjá DataLab, eru hugbúnaðarlausnir sem notast við risamállíkön til að hugsa. Oft eru þær settar fram í spjallviðmóti (eins og t.d.  ChatGPT) en þó ekki alltaf. Hægt er t.d. að þróa spunagreindarlausnir sem leysa verkefni sjálfvirkt í bakgrunni með því að kalla í risamállíkan til að hjálpa sér að taka ákvarðanir. Spjallviðmótið er þó algengasta viðmótið og hefur það í för með sér fjölbreytta óvissu. Tvö meginatriði flækja málið sérstaklega.  

Annars vegar er það erfiðleikinn við að skilgreina umfang lausnarinnar. Dæmi um óvissu tengdu umfangsmati spunagreindarlausnar eru: 

• Hvaða spurningum á spunagreindarlausn að geta svarað? 
• Hvaða gögn þarf til að svara þeim og hvaða gögn eru í boði? 
• Hvenær telst lausnin hafa svarað spurningu nægjanlega vel? 
• Hvernig munu notendur spyrja lausnina? 
• Hvaða módel, tól og uppsetning eru nauðsynleg fyrir verkefnið? 

Hitt meginatriðið er sú staðreynd að útkoma risamállíkana er háð líkum og getur lítil breyting í fyrirspurn haft mikil áhrif á útkomuna. Sama fyrirspurnin getur jafnvel gefið mismunandi svör. Risamállíkönin eru nefnilega brigðgengur (non-deterministic) hugbúnaður. Það er erfitt og tímafrekt að setja upp góðar sjálfvirkar prófanir til að skilgreina verkefnið og styðja við þróun. Klassísk hugbúnaðarþróun byggir hins vegar á því að hægt sé að skilgreina vænta hegðun. Mikil gróska er þó í kringum það hvernig er best að setja upp “evals” sem eru nokkurs konar einingapróf (e. unit test) fyrir spunagreindarlausnir. Þetta er eitthvað sem við höfum verið að vinna okkur áfram með og rannsaka hvernig er best að útfæra. Mögulega er það efni í sérstakt blogg síðar meir.  

Sveigjanlegt hugarfar 

Upp úr aldamótum skipti hugbúnaðargeirinn úr waterfall verkefnastýringu yfir í agile. Í waterfall fyrirkomulaginu er greining og hönnun kláruð alveg áður en farið er í þróun og síðan koma prófanir í lokin eftir að þróun er lokið. Í agile fyrirkomulaginu er hins vegar unnið í ítrunum vegna þess að það er viðurkennd staðreynd að ómögulegt er að klára greiningu og hönnun hugbúnaðarlausna áður en farið er í þróun. Það sé vegna þess hversu mikið lærist um þarfirnar meðfram þróun. Það eru flestir sammála um að þetta hafi verið mikið heillaskref. Agile snýst hins vegar ekki bara um að vinna í sprettum heldur var upphaflega pælingin að leggja áherslu á að þróunin byggi á góðum samskiptum, samstarfi og sveigjanleika.  

Ég leyfi mér að fullyrða að enn meiri þörf sé á þessu hugarfari þegar þróa þarf lausn sem byggir á gervigreind. Þegar verið er að þróa grafísk viðmót er hægt að teikna upp wireframe sem tengja saman takka og flæði aðgerða og lýsa væntri hegðun kerfisins nákvæmlega. Þegar lausn byggir virkni sína á gervigreind er hún hins vegar í eðli sínu hönnuð til að takast á við hið ófyrirsjáanlega og því mjög erfitt að skrifa greinargóða kröfulýsingu fyrirfram. 

Samtal við notendur 

Þrátt fyrir að vera ófullkomin er besta leiðin til að útfæra kröfulýsingu fyrir spunagreindarlausnir að gefa dæmi um notkun (evals). Hér lendum við þó í hring erfiðleika vegna þeirra vandamála sem búið er að fara yfir. Það er erfitt að skilgreina lausnina án dæma en ef við þróum bara út frá dæmum endar þróunin í eins konar “whack-a-mole" debugging. Við viljum finna almennar leiðir til að bæta lausnina þannig að hún geti svarað spurningunum sem gefnar eru en ekki laga lítil atriði þannig að hún geti svarað akkúrat dæmunum sem eru gefin. Ef við festum okkur í dæmunum endum við því ekki með góða heildarlausn.  

Til að vega upp gallana við það að prófa lausnina út frá fyrirframgefnum dæmum þarf að þróa lausnina í nánu samstarfi og prófunum með verðandi notendum. Viðskiptavinur sem prófar og gefur skýra endurgjöf reglulega er besti viðskiptavinurinn. 

Galli eða eiginleiki 

Óvissa er ekki galli í gervigreindarlausnum heldur eðlislægur fylgifiskur þeirra. Vel heppnuð verkefni byggja ekki á að reyna að útrýma óvissunni, heldur að hafa stjórn á henni með sveigjanleika, ítrun og nánu samstarfi við notendur.