Milloin lisätä tekoälyominaisuuksia sovellukseesi — ja milloin jättää väliin

Juuri nyt jokaiseen tuotteen omistajaan kohdistuu hiljainen paine ruuvata tekoäly kiinni mihin tahansa rakennettavaan. Sijoittajat kyselevät siitä. Kilpailijat laittavat sen otsikoihinsa. Hallituksen jäsen välittää artikkelin. Ja niin täysin kelvolliseen sovellukseen ilmestyy pieni kimalteleva kuvake ja chat-ruutu, jota kukaan ei pyytänyt ja jota lähes kukaan ei käytä. Ominaisuus julkaistaan, tiedote lähtee, ja puoli vuotta myöhemmin käyttökäyrät ovat tasaiset. Kysymys ei koskaan ollut siitä, <em>voisitko</em> lisätä tekoälyn. Vaan siitä, kannattaako.

Rakennan elannokseni ohjelmistoja ja tekoälyominaisuuksia pienille ja keskisuurille yrityksille, mikä tarkoittaa, että minulla on taloudellinen syy kehottaa sinua lisäämään tekoälyä kaikkeen. Aion tehdä päinvastoin. Arvokkain asia, jonka voin tarjota, on tapa kertoa — ennen kuin sidot budjettia — kantaako tekoälyominaisuus hiljaa kortensa kekoon vai mätäneekö se hiljaa. Sillä epäonnistuminen täällä ei ole dramaattista. Tekoälyominaisuudet räjähtävät harvoin. Ne vain istuvat siellä, käyttämättöminä ja rakastamattomina, maksaen sinulle rahaa jokaisesta API-kutsusta ja hitusen uskottavuutta joka kerta, kun käyttäjä tökkii niitä ja kävelee pois.

Tämä opas on se viitekehys, jota oikeasti käytän noissa keskusteluissa. Ei muotisanoja, ei muodikkaita mallien nimiä, ei teeskentelyä, että kielimalli olisi vastaus kysymykseen, jota et ole vielä esittänyt. Vain käytännöllinen tapa päättää, mikä kuuluu sovellukseesi, mikä kuuluu tavalliseen koodiin ja mikä kuuluu roskakoriin.

Miksi useimmat päälle liimatut tekoälyominaisuudet epäonnistuvat hiljaa

Kun tekoälyominaisuus floppaa pienessä tuotteessa, se ei juuri koskaan floppaa siksi, ettei malli olisi ollut tarpeeksi älykäs. Se floppaa, koska ominaisuus valittiin vääristä syistä. Joku halusi omistaa tekoälyn sen sijaan, että olisi halunnut ratkaista tietyn, tuskallisen asian, joka sattui tarvitsemaan tekoälyä. Teknologia oli päämäärä ja käyttäjän ongelma jälkiajatus. Käyttäjät haistavat sen heti.

Toinen yleinen epäonnistuminen on hienovaraisempi: ominaisuus ratkaisee aidon ongelman, mutta ongelman, jonka tavallinen koodi olisi ratkaissut halvemmin ja luotettavammin. Painike, jossa lukee ”tekoälypohjainen” ja joka vain järjestää listan päivämäärän mukaan, on rasite, ei ominaisuus. Olet ottanut jotain deterministista, tehnyt siitä hitaampaa, kalliimpaa ja toisinaan väärää, ja sitten mainostanut heikennystä. Käyttäjät huomaavat senkin.

Kolmas epäonnistuminen on luottamus. Tekoälyominaisuudet ovat todennäköisyyspohjaisia — ne ovat oikeassa useimmiten ja itsevarmasti väärässä joskus. Jos pudotat sellaisen työnkulkuun, jossa väärä vastaus on kallis eikä käyttäjällä ole tapaa havaita sitä, et ole lisännyt ominaisuutta vaan miinan. Hyvä uutinen on, että kaikki kolme epäonnistumistapaa ovat ennustettavissa, mikä tarkoittaa, että ne ovat vältettävissä. Sinun pitää vain esittää oikeat kysymykset ennen aloittamista, ei julkaisun jälkeen.

Rehellinen testi: onko tämä oikeasti tekoälyongelma?

Tässä hyödyllisin tuntemani suodatin. Mille tahansa ominaisuudelle, jonka houkutut tekemään ”älykkääksi”, kysy: noudattaako tämä tehtävä kiinteitä sääntöjä, vai vaatiiko se sotkuisen, inhimillisen syötteen ymmärtämistä? Jos tehtävä noudattaa sääntöjä — järjestä tämän mukaan, laske tuo, lähetä muistutus kaksi tuntia ennen — haluat tavallista koodia. Se on halvempaa, nopeampaa, täysin ennustettavaa eikä koskaan hallusinoi. Sen kutsuminen tekoälyksi on vain kallista markkinointia.

Tekoäly ansaitsee paikkansa siellä, missä syöte on aidosti sotkuista ja inhimillisen muotoista: vapaata tekstiä, jota säännöt eivät osaa ennakoida, kuvia, puhetta, dokumentteja sadassa eri asettelussa, kieltä, joka pitää ymmärtää eikä vain täsmätä. Nämä ovat asioita, joita oli ennen täysin mahdotonta automatisoida. Jos ominaisuutesi asuu siellä, tekoäly ei ole kikka — se on ainoa käytännöllinen tapa rakentaa se. Taito on erottaa nämä kaksi kategoriaa rehellisesti, erityisesti kun on painetta kutsua kaikkea tekoälyksi.

Missä tekoäly aidosti kuuluu sovellukseen

Mennäänpä konkretiaan. Vuosien näiden rakentamisen jälkeen lyhyt lista kaavoja todistaa jatkuvasti arvonsa — ei siksi, että ne olisivat muodikkaita, vaan koska taustalla oleva tehtävä on aidosti jäsentämättömän syötteen ymmärtämistä. Nämä ovat ominaisuuksia, joiden pariin käyttäjät oikeasti palaavat.

• Vapaan tekstin muuttaminen jäsennellyksi dataksi — rönsyilevän asiakassähköpostin lukeminen ja tilauksen, osoitteen ja määräajan poimiminen.
• Ensimmäisen version luonnostelu — vastaus, tiivistelmä, kuvaus — jota ihminen sitten muokkaa, eikä tekoäly lähetä sitä valvomatta.
• Haku, joka ymmärtää merkityksen eikä vain avainsanoja, jotta käyttäjät löytävät oikean dokumentin, vaikka muotoilevat sen eri tavalla kuin sinä sen tallensit.
• Saapuvan tulvan luokittelu tai ohjaaminen — tukipyynnöt, sähköpostit, lähetykset — niin että oikea asia päätyy oikeaan paikkaan.
• Tiedon poiminta dokumenteista ja kuvista: laskut, kuitit, lomakkeet, kentältä otetut valokuvat.
• Keskusteleva apu omaan dataasi nojaten, jossa käyttäjä esittää tavallisen kysymyksen ja saa sisältöösi perustuvan vastauksen.

Huomaa kaava. Jokaisessa näistä syöte on arvaamaton ja inhimillinen, ja pieni määrä erehtymistä on siedettävää, koska ihminen on mukana silmukassa tai virheen hinta on matala. Tuo yhdistelmä — sotkuinen syöte, anteeksiantava panos — on tekoälyominaisuuden luonnollinen koti. Kun löydät tehtävän, joka sopii molempiin puolikkaisiin, olet luultavasti löytänyt rakentamisen arvoisen ominaisuuden.

Missä jättää tekoäly rauhaan

Yhtä tärkeää on tietää, missä ei kannata kurkottaa tekoälyyn, sillä väärä sijoitus ei vain tuhlaa rahaa — se aktiivisesti murentaa tuotteesi ansaitsemaa luottamusta. Jotkin tehtävät näyttävät houkuttelevilta ja osoittautuvat ansoiksi.

On myös hiljaisempi kustannus. Jokainen tekoälyominaisuus on jotain, mitä sinun pitää nyt valvoa, arvioida ja maksaa jokaisesta kutsusta. Kolme tekoälyominaisuutta, joihin käyttäjäsi luottavat, ovat arvokkaampia kuin kymmenen, jotka satunnaisesti nolaavat sinut. Malli, joka on väärässä asiakkaan edessä väärällä hetkellä, voi pyyhkiä pois vuoden huolellisesti rakennettua uskottavuutta. Pidättyväisyys ei tässä ole arkuutta — se on tuoteymmärrystä.

Nopea kartta: rakenna, jätä väliin vai tee myöhemmin

Tehdäkseni tästä vähemmän abstraktia, tässä miten kourallinen yleisiä ”lisätään tekoäly” -ideoita yleensä asettuu, kun ajat ne yllä olevan testin läpi. Pidä sitä järkevänä lähtöoletuksena, jonka kanssa voi väitellä, ei evankeliumina.

Taulukon muoto on opetus. Kyllät ryhmittyvät sinne, missä syöte on sotkuista ja panokset anteeksiantavia. Eit ryhmittyvät sinne, missä tehtävä on oikeasti sääntöpohjainen tai missä väärä vastaus sattuu eikä kukaan tarkista. Jos osaat sijoittaa ideasi tuolle ruudukolle rehellisesti, olet jo tehnyt suurimman osan päätöksestä.

Ajoitus: jopa hyvä tekoälyominaisuus voidaan lisätä liian aikaisin

Joskus ominaisuus sopii aidosti ja vastaus on silti ei vielä. Tekoälyominaisuuksilla on ovela ennakkoehto, jonka perustajat aliarvioivat: ne ovat vain niin hyviä kuin data ja työnkulku, joiden päällä ne istuvat. Semanttinen haku dokumentteihisi on ihana — kunhan dokumenttisi ovat oikeasti järjestyksessä. Avustaja, joka vastaa tuotettasi koskeviin kysymyksiin, on loistava — kunhan tuotesisältösi ei ole ristiriitainen sotku. Tekoäly vahvistaa kaikkea, minkä päälle se on rakennettu, kaaos mukaan lukien.

Joten ennen kuin lisäät näppärän kerroksen, varmista että tylsä kerros sen alla on vankka. Jos ydinsovelluksesi vielä hakee jalansijaa, insinöörityön kaataminen tekoälyominaisuuteen on yleensä lainaamista väärältä tililtä. Epäseksikäs totuus on, että paras aika lisätä tekoälyä on usein sen jälkeen, kun olet naulannut perusasiat — kun sinulla on oikeita käyttäjiä, oikeaa dataa ja selkeä, toistuva kipu, jonka poistamiseen tekoäly on poikkeuksellisen sopiva.

Miten lisätä tekoälyominaisuus ilman katumusta

Sanotaan, että olet löytänyt ominaisuuden, joka läpäisee testin: sotkuinen syöte, anteeksiantavat panokset, vankka pohja alla, oikea kipu poistettavaksi. Hyvä. Nyt se osa, jossa tiimit joko rakentavat jotain kestävää tai jotain, minkä ne hiljaa repivät irti ensi vuonna. Kohtele sitä huolellisena kokeena, ei julkaisuna.

1. 1
   Kirjoita tehtävä yhdellä lauseella

   ”Avustaja lukee saapuvan sähköpostin ja täyttää tilauslomakkeen, jonka ihminen vahvistaa.” Jos et osaa kirjoittaa tuota lausetta, ominaisuus ei ole valmis — olet edelleen rakastunut teknologiaan, et tehtävään.
2. 2
   Pidä ihminen mukana silmukassa aluksi

   Anna tekoälyn luonnostella, ehdottaa tai esitäyttää — ja anna ihmisen hyväksyä. Opit, missä se on luotettava ja missä ei, ennen kuin koskaan luotat sen toimivan yksin, jos koskaan luotat.
3. 3
   Päätä, mitä tapahtuu kun se on väärässä

   Todennäköisyyspohjaiset ominaisuudet tarvitsevat siistin epäonnistumisen. Miten käyttäjä huomaa? Miten hän korjaa? Tekoälyominaisuus ilman näkyvää ”kumoa”- tai ”tuo ei ole oikein” -polkua on ominaisuus, johon et voi luottaa tuotannossa.
4. 4
   Mittaa käyttöä, älä uutuutta

   Seuraa, käyttävätkö ihmiset sitä oikeasti ensimmäisen viikon jälkeen ja säästääkö se lupaamasi ajan. Ominaisuus, joka piikittää julkaisussa ja litistyy sen jälkeen, kertoo sinulle jotain. Kuuntele.
5. 5
   Ole valmis poistamaan se

   Jos luvut sanovat, ettei se ansaitse paikkaansa, leikkaa se pois. Pienempi tuote, joka tekee muutaman asian luotettavasti, voittaa pöhöttyneen, joka on naulattu täyteen tekoälyominaisuuksia, joihin kukaan ei koske.

Kaikkien viiden askeleen läpi kulkeva lanka on nöyryys erehtymisestä. Tavallinen koodi joko toimii tai siinä on bugi, jonka korjaat. Tekoäly on oikeassa useimmiten ja väärässä joskus, ikuisesti — se on sen luonto, ei vika, jonka voit paikata pois. Suunnittele ominaisuus tuon todellisuuden ympärille, ja siitä tulee voimavara. Teeskentele, että tekoäly on aina oikeassa, ja olet rakentanut sen miinan, josta puhuimme aiemmin.

Suurempi kuva: tekoäly on työkalu, ei strategia

Astu tarpeeksi taakse ja koko kysymys yksinkertaistuu. Tekoäly on työkalu, samoin kuin tietokanta tai hakupalkki on työkalu. Et rakenna tuotetta tietokannan omistamisen ympärille; käytät tietokantaa siellä, missä se tekee tuotteesta paremman. Sama pidättyväisyys palvelee sinua hyvin täällä. Yritykset, jotka saavat oikeaa arvoa tekoälystä, eivät ole niitä, jotka lisäsivät sitä eniten — ne ovat niitä, jotka lisäsivät sen täsmälleen niihin harvoihin paikkoihin, joissa se poistaa aitoa kitkaa, ja pidättäytyivät kaikkialla muualla.

Tuo pidättyväisyys on muuten myös se, mikä saa oikeasti lisäämäsi tekoälyn tuntumaan vaikuttavalta. Kun jokaisella ruudulla on puolivalmis avustaja, yksikään niistä ei tunnu erityiseltä. Kun yksi ominaisuus hiljaa lukee asiakkaan sähköpostin ja säästää tiimiltäsi kymmenen minuuttia joka kerta, ihmiset muistavat sen. Vähemmän, terävämpiä, aidosti hyödyllisiä — se on tekoälyn versio, jota kannattaa rakentaa, ja se on versio, josta käyttäjäsi oikeasti kiittävät sinua.

Yleisiä kysymyksiä