Tässä kirjoituksessa käyn läpi kolme asiaa, jotka vaikuttavat keskeisesti AI-projektin onnistumiseen: miten oppi jää organisaatioon, miksi projektin pitää olla nopea, ja miten toteutus kannattaa tehdä.

Rakenna sen päälle, mitä organisaatio jo osaa

Oppiminen on usein jopa tärkeämpää kuin tehdyn työn tulos. Hyvä tekijä voi edesauttaa sitä, että työn lopputulos tai tuote koetaan "hyödyllisenä" ja "onnistuneena". Mutta jo ensimmäisiä kokeiluita tehtäessä on hyvä herkistyä sille, että projektista voi oppia ja jopa että projektien suurinta antia voi olla se miten se valmistaa tuleviin kokeiluihin ja projekteihin. Tekoälytuote itsessään vanhenee ja muuttuu – mutta se mitä te opitte organisaatiossanne, se jää.

Projekteista oppiminen kannattaa siis maksimoida. AI-projekteissa tätä voi edesauttaa sillä, että huomio pidetään tiukasti organisaation omassa domainissa ja osaamisessa. Silloin opittavana on vain yksi asia: mitä AI on tällä domainilla – ei kaikki mahdollinen tekoälyyn liittyvä.

Silti kuulen usein, miten AI-asiantuntijat – he voivat olla innokkaita työntekijöitä, jotka haluavat päästä mukaan kiinnostavaan toimintaan, tai konsultteja, jotka yrittävät vakuuttaa pätevyydellään ja voittaa asiakkaan luottamuksen – puhuvat silmät ja korvat täyteen AI-jargonia. Se mitä he sanovat voi olla täysin todenmukaista ja se voi tulla hyvistä lähteistä, mutta se on "kaivoon kannettua vettä" ja hyödytöntä tietoa, jos sitä ei yhdistetä organisaation tekemiseen. Jos se ei liity organisaatiossa jo tiedettyyn, niin se unohtuu ja pysyvää oppimista ei tapahdu.

Tilaajan rooli projektissa on keskeinen. Minä tiedän miten AI-ratkaisuja rakennetaan – mutta en tiedä millaisilla ohjeilla energia-alan agentin osaamista pitäisi testata, enkä tiedä mitä dokumentteja teidän intrastanne löytyy, enkä osaa arvioida millaiset vastaukset tekoälyltä ovat hyväksyttäviä. En osaa tehdä säätieteellisiä analyyseja yhtä hyvin kuin ammattimeteorologit enkä tiedä miten lentovarausjärjestelmien monisyinen logiikka on suunniteltu.

Mutta onneksi projekteissa oli aina joku jolla oli se tieto. Ja sen tiedon varaan on hyvä rakentaa AI-ymmärrystä: ei tarvitse oppia kaikkea mitä AI-ratkaisuun kuuluu, vaan riittää ymmärtää ne tekijät, jotka mahdollistivat ratkaisun toimivuuden tässä tapauksessa ja miksi tiettyjä ongelmia piti ratkaista ennen kuin saatiin todella hyviä tuloksia. Ja nämä opit jäävät hyvin mieleen, koska ne liittyvät johonkin tunnettuun ja hyvin ymmärrettyyn.

Pidä projekti pienenä ja nopeana

Datatieteen ja koneoppimisen projekteissa olen oppinut yhden keskeisen periaatteen: optimoi syklin nopeutta. Jokainen iteraatio opettaa jotain. Joskus mennään nopeasti metsään, mutta sieltä myös palataan nopeasti suotuisalle reitille. Kun sykli on lyhyt ja halpa, väärä suunta ei ole katastrofi vaan oppi.

Sama periaate pätee AI-projekteihin laajemmin. On iso virhe aloittaa liian laajasti – olen tehnyt sen itsekin: kunnianhimoiset arkkitehtuurit, viiden integraation PoC:t, kuukausia työtä ennen kuin kukaan näkee tuloksia.

Ensimmäinen kokeilu kannattaa rajata niin pieneksi, että se voidaan toteuttaa viikoissa – ei kuukausissa:

• Yksi käyttötapaus, ei kolmea
• Rajattu data, ei koko yrityksen tietovarasto
• Yksinkertainen arkkitehtuuri, joka toimii ensin ja jota optimoidaan myöhemmin
• Selkeä onnistumisen mittari, josta näkee oliko kokeilusta hyötyä

Pieni kokeilu on halpa. Siitä oppii. Ja sen tulosten perusteella voi päättää, kannattaako jatkaa, muuttaa suuntaa vai lopettaa.

Koodi ja infrastruktuuri ovat iteroinnin perusta

Nopea iterointi vaatii vakaan pohjan. Ja tässä kohtaa on hyvä puhua siitä, kuka työtä tekee ja miten.

Lahjakas datatieteilijä voi saada ihmeiltä tuntuvia asioita aikaan. Mutta toisinaan datatieteilijä ei dokumentoi kaikkia askelia, joita hän on ottanut ratkaisuun pääsemiseksi. Vastaavasti pilvipalvelun konsolissa työskennellyt konsultti ei välttämättä jätä jälkeäkään siitä, miten hän rakensi palvelun ja millaisella konfiguraatiolla se on ajossa. Tulos voi olla vaikuttava, mutta kukaan muu ei pysty toistamaan sitä – saati iteroimaan sen päälle.

Tästä syystä AI-projektin toteutuksessa kaksi asiaa ovat välttämättömiä:

Sovelluskoodi versionhallinnassa. Kaikki ratkaisun logiikka on koodissa, joka on tilaajan koodivarastossa. Ei piilotettuja konfiguraatioita, ei konsultin omia ympäristöjä, ei notebookeja, jotka toimivat vain datatieteilijän koneella. Kun koodi on hallinnassa, kuka tahansa pätevä kehittäjä voi jatkaa työtä.

Infrastructure as Code (IaC). Pilvi-infrastruktuuri – palvelimet, tietokannat, verkkoasetukset – on määritelty koodina. Koko ratkaisun voi pystyttää uudelleen yhdellä komennolla, ja jokainen muutos on jäljitettävissä. Tämä tekee iteroinnista turvallista: voit kokeilla, rikkoa ja palauttaa ilman pelkoa pysyvistä menetyksistä.

Kun ratkaisun logiikka ja infrastruktuuri ovat versiohallinnoidussa koodissa, jokaisella iteraatiokierroksella ei tarvitse rakentaa pohjaa uudelleen. Energia menee siihen, mikä on tärkeää: ratkaisun parantamiseen. Tai ratkaisua voi nopeasti soveltaa vaikka toiseen kohteeseen.

Miten tämä heijastuu työhöni ja hinnoitteluuni

Näistä periaatteista seuraa luontevasti se, miten itse hinnoittelen ja teen työni. Myyn AI-toteutuksia urakkahinnoittelulla, jossa kaikki työn tuotokset – sovelluskoodi, IaC, dokumentaatio – jäävät tilaajan omaisuudeksi. Toimituksen jälkeen tilaajalla on vapaus hoitaa operointi ja jatkokehitys itse, valitsemallaan tiimillä.

Täältä löydät hinnastoni.

Jos tämä herätti ajatuksia tai sinulla on AI-hanke mielessä, ota yhteyttä.