Miksi yritysten tekoäly epäonnistuu maaliviivalla — ja miten ongelmaa voidaan ratkaista

Teckoälyn ympärillä on paljon hypeä, mutta useimmat yritysten tekoälyprojektien ei koskaan pääse kokeiluvaiheen ohi. Tuoreen IDC-tutkimuksen mukaan 88 % tekoälyn todennuskoekuvaus (POC) -projekteista epäonnistuu laajentumisessa täysimittaiseen tuotantoon. Tämä on valtava pudotus, ja selvä merkki siitä, että jokin ei toimi. Monet näistä projekteista pääsevät lähelle maaliviivaa, ja niillä on koulutettu malli, joka täyttää tiimin asettamat kriteerit, mutta niitä ei lopulta käyttöönoteta tai oteta käyttöön loppukäyttäjien toimesta.

Mikä siis menee pieleen? Monissa tapauksissa syy on kolme suurta ongelmaa:

1. Yritysten tekoälytiimit luottavat pinnallisesti diagnostiikkatyökaluihin ja kriteereihin, jotka eivät havaitse avainsuorituskykyriskejä
2. Malleja koulutetaan standardikriteereihin, ei todellisiin maailman ongelmien ratkaisemiseen
3. Mallin käytön laajentamisen kustannukset kasvavat liian suuriksi yrityksen laajuisessa käytössä

Tässä artikkelissa pureudumme kunkin näiden esteiden taakse — ja mitä tekoälyprojektien onnistumiseen vaaditaan.

Ongelma #1: Standardidiagnostiikka, joka ei havaitse avainsuorituskykyriskejä

Yksi tärkeä syy, miksi tekoälyprojektit kompastuvat kokeiluvaiheen jälkeen, on se, että sisäiset kriteerit ja diagnostiikkatyökalut eivät usein tunnele riittävän syvälle mallin suorituskykyyn ja havaitse ongelmia, jotka vaikuttavat käytettävyyteen, luotettavuuteen ja käyttöönottoon. Tiimit saattavat täyttää kaikki ruudut paperilla, mutta ne eivät aina heijasta sitä, miten malli toimii todellisessa maailmassa.

Otetaan esimerkki: Yksi tekoälytiimi kehitti mallin, joka läpäisi jokaisen sisäisen testin erinomaisesti. Se saavutti kaikki heidän tarkkuuskriteerinsä ja turvallisuuskynnykset, ja he valmistautuivat julkaisemiseen. Mutta kun he pyysivät kolmannen osapuolen arvioimaan mallia heidän tarkoituksensa mukaisesti, jotta se heijastaisi sitä, miten todelliset käyttäjät vuorovaikuttaisivat järjestelmän kanssa, he löysivät suuren sokean kohteen. Malli oli yhdeksän kertaa todennäköisempi antamaan epämääräisiä vastauksia, kun siihen kysyttiin tiettyjä kysymyksiä. Esimerkiksi se vastasi oikein kysymyksiin “Kuka on Yhdysvaltain presidentti?” mutta käsitteli kysymystä “Voitko kertoa minulle presidentistä?” turvallisuusriskinä ja kieltäytyi vastaamasta.

Ongelma ei ollut mallin ydinosaamisen kanssa — se oli siinä, miten se tulkitsi aikomusta kysymyksen muotoilun perusteella. Tiimi oli optimoinut turvallisuutta niin paljon, että he vahingossa estivät normaaleja, järkeviä kysymyksiä.

Ongelma #2: Mallit on hienosäädetty kriteereihin, jotka eivät heijasta todellista maailmaa

Toinen yleinen este yritysten tekoälylle on, että tekoälytiimit kouluttavat malleja täyttämään teollisuusstandardikriteerejä, ei todellisia maailman tarpeita. Paperilla malli saattaa näyttää huipputasoiselta, saavuttaa korkeat arvosanat standardiarvioissa tarkkuudesta, relevanttiudesta tai turvallisuudesta. Mutta käytännössä se saattaa kamppailla antaakseen johdonmukaisia, hyödyllisiä tuloksia ilman voimakasta käyttäjän väliintuloa.

Tämä tapahtuu, kun tiimit optimoivat malleja suorittamaan hyvin kapeilla, kriteerikohtaisilla tehtävillä. Malli pääsee huipulle näissä testitapauksissa, mutta horjuu, kun se kohtaa vähemmän jäsenneltyjä, monimuotoisempia todellisen maailman syötteitä. Tuloksena käyttäjien on “puhuttava mallin kieltä” käyttämällä kysymyskoulutusta vain saadakseen oikeat vastaukset. Jos tekoälytuotteesi riippuu loppukäyttäjien tarkan kysymyksen muotoilusta, olet esittänyt kitkaa, joka hidastaa käyttöönottoa ja heikentää sen hyödyllisyyttä.

Tämänkaltaisen kriteeripohjaisen koulutuksen voi myös johtaa ylioppimiseen. Malli saa niin hienosäädetyn suorittamaan hyvin arviointidatamalleissa, että se menettää yleispätevyytensä. Se saattaa läpäistä jokaisen sisäisen testin, mutta epäonnistuu, kun se otetaan käyttöön villinä, erityisesti, jos todelliset käyttötarkoitukset poikkeavat edes hieman siitä, mihin se on koulutettu.

Haluatko yrityksen tekoälyratkaisun, joka onnistuu? Sinun mallin on toimittava todellisessa maailmassa — ei vain laboratoriossa.

Ongelma #3: Tekoälyn käytön laajentaminen tarkoittaa laskentakustannusten kasvamista

Kolmas syy, miksi monet tekoälyn POC:t eivät onnistu laajentumisessa, on taloudellinen: tiimit usein aliarvioivat mallin ajamisen ja ylläpitämisen kustannuksia tuotannossa. Kehityksen aikana on helppo ohittaa suuren mallin laskentavaatimukset, erityisesti, kun testausta tehdään pienillä datamäärillä tai rajoitettujen käyttötapauksien ympäristössä. Mutta kun se otetaan käyttöön, nämä kustannukset voivat kasvaa nopeasti.

Yritysluokan tekoäly vaatii merkittäviä laskentaresursseja, ei ainoastaan vastaamaan pyynnöistä reaaliajassa, vaan myös jatkuvaan hienosäätöön, seurantaan, lokittamiseen ja uudelleenkoulutukseen. Jos nämä kustannukset eivät oteta huomioon aikaisessa vaiheessa, liiketoimintatapaus ratkaisulle voi romahtaa, kun todellinen käyttö alkaa. Mikä näytti lupaavalta mallilta kontrolloidussa testissä, voi nopeasti tulla kestämättömäksi, kun tuhannet käyttäjät alkavat käyttää järjestelmää päivittäin.

Ylittäminen viimeisen mailin esteitä onnistuneeseen yritysten tekoälyyn

Jotta voidaan välttää yleisiä esteitä, jotka kaatavat niin monia yritysten tekoälyprojekteja, tiimien on mentävä tavallisen toimintatavan ulkopuolelle. Tässä on, miten tekoälytiimisi voi luoda jotain, mikä toimii — ja laajenee.

Ensinnäkin, tuo kolmas osapuoli arvioimaan malliasi. Sisäinen testaus on tärkeää, mutta se on usein liian laaja. Tuoreet silmät, yhdistettynä mukautettuun arviointirunkoon, joka on suunniteltu tekoälysi tarkoituksiin, voi paljastaa ongelmia, joita tiimisi saattaa missata, erityisesti siinä, miten todelliset käyttäjät todella vuorovaikuttavat järjestelmän kanssa.

Toiseksi, varmista, että testaat todellisen maailman kysymyksillä. Useimmat kriteerit testaavat “puhtaita” tietoja, jotka eivät heijasta todellista maailmaa, saati sitä, miten tekoälysi tarkoitettu loppukäyttäjäryhmä tulee kysymään malliltasi. Testaaminen malliasi epämääräisillä, epäselvillä tai outojen muotoilujen syötteillä paljastaa, miten mallisi todella suoriutuu käyttöönoton jälkeen ja antaa sinun havaita ongelmat, jotka muuten voivat joutua tiimisi välistä ja vaikuttaa lopulta käyttöönottoon.

Kolmanneksi, tarkista turvallisuusprotokollasi uudelleen. On helppo mennä liian pitkälle turvallisuuden varotoimissa, ja vaikka turvallisuus on tärkeää, se ei saa tehdä mallistasi käyttökelvotonta. Jos malli sulkeutuu yksinkertaisiin, vaarattomiin kysymyksiin, olet vaihtamassa käytettävyyden turhaan turvallisuuden tunteen vuoksi.

Lopuksi, valvo laskentakustannuksiasi. Jos käyttöönottoasi koskevat tuhannet käyttäjät ja miljoonat pyynnöt, nämä kustannukset voivat kasvaa nopeasti. Yksi ratkaisu on harkita pienempiä malleja. Boosted.ai teki juuri näin — he vaihtoivat mukautettuun pieniin kielen malleihin ja leikkasivat laskentakustannuksensa 90 %:lla parantaen samalla nopeutta ja suorituskykyä. Reaaliaikaiset tulokset, parempi käyttäjäkokemus ja ei tarvetta kalliille laitteille.

Hyökkäämällä arvioinnin, käytettävyyden ja skaalautuvuuden kimppuun alusta alkaen tiimit voivat antaa tekoälyprojektilleen todellisen mahdollisuuden pitkäaikaiseen menestykseen. Se ei ole vain siinä, että se toimii laboratoriossa — se on siinä, että se toimii maailmassa.