Viimeisen muutaman vuoden aikana modernien tekoälysovellusten kehitys on painottunut vahvasti generatiivisen tekoälyn hyödyntämiseen. Suuria kielimalleja on saatavilla sadoittain, ja niitä on helppo käyttää moniin erilaisiin käyttötarkoituksiin. Malleilla on tosin eräs suuri heikkous: niillä ei ole pääsyä salaiseen tai tuoreeseen, mallin koulutuksen jälkeen julkaistuun tietoon.

Tekoälyarkkitehtuurin suunnittelu ja toteutus ovat ratkaisevan tärkeitä, jotta mallien rajoitteista päästään eroon. Tässä kirjoituksessa tarkastelemme, miten ohjelmistotekniikka täydentää tekoälyä ja miksi tekoälyn soveltaminen vaatii vahvan ohjelmisto-osaamisen. Lisäksi käsittelemme AI-ohjelmistokehysten käyttöä, niiden etuja ja haasteita, sekä AI-first -ajattelumallin omaksumisen tärkeyttä yrityksille. Näiden teemojen kautta pohdimme, miten yritykset voivat kehittää omia tekoälykyvykkyyksiään ja varmistaa ratkaisujensa laadukkuuden ja kestävyyden.

Ohjelmistotekniikka täydentää tekoälyä

Olet ehkä kuullut, että elektroniikan eli “raudan” puutteita paikkaillaan usein ohjelmistoilla. Sama logiikka pätee myös edellä mainittuun generatiivisen tekoälyn dataongelmaan: ohjelmistoteknisillä ratkaisuilla täydennetään tekoälymallien puutteita ja tehdään niistä entistä parempia.

Erääksi ratkaisuksi on muodostunut niin kutsuttu RAG-arkkitehtuuri (Retrieval Augmented Generation) tai helpommin ”räggi”, joka voidaan vapaasti suomentaa esimerkiksi “haulla avustettu generointi”. Tämä postaus ei perehdy kyseiseen tekoälyarkkitehtuuriin teknisesti syvällisemmin, ja lukijan odotetaan ymmärtävän aihepiirin perusteet. Ne voi kerrata esimerkiksi aikaisemmasta RAG-aiheisesta kirjoituksestani. 

Hyviä esimerkkejä RAGeista ovat esimerkiki kaikki asiakaspalveluchatit, jotka käyttävät apunaan eli tietolähteenään vaikkapa aikaisemmin ratkaistujen ongelmien tietokantaa. Käytännössä asiakkaan kysymyksen perusteella tietokannasta haetaan parhaiten ongelmaan täsmäävät ratkaistut tapaukset, ja kielimalli käyttää niitä lähteinä muodostaessaan vastauksen käyttäjälle. RAGilla voidaan minimoida kielimallin hallusinointi ja tuottaa täsmällisiä oikeaan tietoon pohjautuvia vastauksia.

Todennäköisesti kaikkien generatiivisia tekoälymalleja ja ulkoista dataa hyödyntävien sovelletun tekoälyn ratkaisujen ytimessä on jonkinlainen RAG-toteutus. Tämän vuoksi RAGin integrointi joko kiinteäksi osaksi valmista tuotetta tai erillisen, kyvykkyyksiltään laajemman AI-moottorin kehitys on nyt lähes jokaisen yrityksen toteutuslistalla.

AI-ratkaisut eivät synny ilman uudenlaista osaamista

On erittäin tärkeää, että AI-ratkaisun ohjelmisto- sekä pilviarkkitehtuuri on rakennettu järkevästi tekoälyn vaatimukset huomioiden. Kokonaisvaltainen ymmärrys sekä ohjelmistotekniikasta, pilvestä että tekoälystä on kriittistä laadukkaan ja toimivan ratkaisun toteuttamiseksi.

Sovellettu tekoäly on yhdistelmä ohjelmisto-, AI/ML- ja pilviosaamista.

Käytännössä kyse on uudesta ohjelmistotekniikan osa-alueesta, sovelletusta tekoälystä (applied AI engineering, usein myös pelkkä laajempi termi AI engineering), josta voi lukea lisää sovelletun tekoälyn palveluistamme ja sovelletun tekoälyn insinöörin kuvauksesta. AI-termistä huolimatta tekijöiden osaaminen painottuu ohjelmisto-osaamisen puolelle vahvalla ymmärryksellä tekoälystä, algoritmeista sekä näihin liittyvistä sovelluskerroksen menetelmistä.

On sanomattakin selvää, että valtaosalla yrityksistä ei ole kykyä kouluttaa tai kapasiteettia palkata sovellettuun tekoälyyn erikoistuneita ohjelmistosuunnittelijoita. Tämän vuoksi monen yrityksen ohjelmistosuunnittelijatiimi onkin ottanut käyttöön valmiita AI-ohjelmistokehyksiä, jotta softaan saadaan rakennettua helposti uusia AI-ominaisuuksia. Kuulostaa nopealta ja halvalta tieltä onneen, eikö vain?

Omistatko tekoälyarkkitehtuurisi?

Viimeisen vuoden aikana niin kutsutuista AI-ohjelmistokehyksistä (näitä voitaneen kutsua myös termillä datakehys tai LLM-kehys), kuten Langchain ja Llamaindex, on ollut paljon kriittistä keskustelua. Tyypillinen ongelma on, että ne saastuttavat koko ohjelmistoratkaisun arkkitehtuurin pakottamalla sen omaan ennalta määritettyyn muottiinsa. Lisäksi ne piilottavat usean abstraktiokerroksen alle kaiken sen logiikan, jonka muokkaaminen tulee eteen ennemmin tai myöhemmin oman datan parissa työskennellessä.

Kehysten käyttö voi olla myös hyvä asia, ja monesti ne nopeuttavat toteutusta varsinkin nopeissa kokeiluissa ja PoCeissa. Niillä on paljon arvoa, kun erilaisia RAG-arkkitehtuureja ja menetelmiä arvioidaan omaa dataa vasten. Parhaiten sopiva menetelmä oman datan hyödyntämiseen voidaan haarukoida kehyksiä käyttämällä ja lähteä valinnan pohjalta toteuttamaan omaa, vielä parempaa ratkaisua.

Tuotannollisissa toteutuksissa kehykset puolestaan luovat todennäköisesti enemmän ongelmia kuin ratkaisevat niitä. Sovelletun tekoälyn ratkaisut vaativat ainakin vielä toistaiseksi huomattavan määrän räätälöintiä per käyttötapaus. Tätä eniten arvoa tuottavaa ydinlogiikkaa harvemmin ulkoistetaan ohjelmistokehyksille, koska yrityksen ydinpalvelujen tai tuotteen ytimen on pakostakin oltava sisäisen kehittäjätiimin hallussa. Aivan kuten omistat tuotteesi ohjelmistoarkkitehtuurin, integraatioarkkitehtuurin ja data-arkkitehtuurin, sinun täytyy omistaa myös sen tekoälyarkkitehtuuri.

Tästä huolimatta moni on ottanut käyttöön valmiita avoimen lähdekoodin RAG-toteutuksia, jotta mutkia on saatu oikaistua suoriksi. Vähitellen on kuitenkin huomattu, että sovellettu tekoäly vaatii ehkä muutakin kuin yhden uuden ohjelmistokehyksen.

Ohjelmistokehyksillä ei voi paikata aukkoja tekoälyosaamisessa

RAGin hakuvaihe toimii aina hyvin lähellä yrityksen tai tuotteen dataa. Tämän kriittisen businessdatan haku, mahdollinen indeksointi ja muokkaus tulisi olla täysin yrityksen hallittavissa. Hyvin toimiva haku luo perustan toimivalle RAGille: laadukkaat hakutulokset tuottavat laadukkaita vastauksia. Hakutoiminnallisuuden pakottaminen AI-kehysten tarjoamiin valmiisiin rakenteisiin ja menetelmiin tekee laadukkaan haun toteutuksesta hankalaa, ellei jopa mahdotonta. 

Kehyksien suosion huomioiden niitä käytetään todella paljon, ja uskallan väittää, että moni laadullisesti heikko GenAI-toteutus johtuu kehysten käytöstä. Kehykset eivät tietenkään ole käyttökelvottomia tai huonoja, ja varsinkin Llamaindexin luojat tekevät uraa uurtavaa työtä uusien menetelmien ja kyvykkyyksien kanssa. Juurisyyt ongelmiin löytyvät muualta.

Kehysten pellin alla oleva oleva mekaniikka, kuten hakumenetelmät, ovat yleisiä, “yksi koko sopii kaikille” -ratkaisuja, jotka harvoin sopivat suoraan jokaisen yrityksen käyttötapauksiin. Tämä lisäksi kehykset piilottavat alleen esimerkiksi vektoritietokantoja, sekä niihin tallennettavien upotuksien eli tekstistä laskettavien vektorien muodostamisen. Haun sekä vastausten laadun arviointi jäävät lähes aina kehyksiä käytettäessä kokonaan tai osittain paitsioon. Laatu on siis mahdollisesti vaihdettu matalaan hintaan ja nopeaan toteutukseen, mutta myös tietämättömyys sovelletusta tekoälystä ja usko helppoon toteutukseen ovat osasyitä heikkoihin lopputuloksiin.

Valmiit kehykset vai räätälöidyt ratkaisut? 

Ohjelmisto- ja tekoälyarkkitehtuuria suunniteltaessa on päätettävä, käytetäänkö toteutuksessa jotakin valmista ohjelmistokehystä, vai rakennetaanko kenties kaikki itse. Entä jos käytetäänkin vain yhtä tai kahta valmista huomattavasti suppeampaa kirjastoa, ja tehdään loput itse?

Omaa yksityistä GenAI-tuotetta YOKOT.AIta kehittäessämme huomasimme hyvin varhaisessa vaiheessa Langchainin ongelmat: emme pystyneet soveltamaan kielimalleja omiin käyttötapauksiin kehyksen rajoitteiden vuoksi. Poistimme sen tuotteesta ennen ensimmäistä tuotantoon vientiä kesällä 2023 ja korvasimme osan siitä pienemmillä erikoistuneilla kirjastoilla. Tämä mahdollisti tuotteen nopeamman iteroinnin, ja uusien täysin omien sovellettujen AI-kyvykkyyksien toteutuksen.

LinkedIn puolestaan huomasi erästä AI-ominaisuutta toteuttaessaan, että 80 % valmiusaste saavutetaan nopeasti kuukaudessa tai kahdessa, mutta loppu 20 % vie aikaa puolestaan lähes puoli vuotta kokeneiltakin AI-kehittäjiltä. Sovelletun tekoälyn vieminen tuotannolliseen käyttöön on siis huomattavasti vaativampaa kuin yhden kehyksen käyttöönotto ja sieltä muutaman valmiin funktion kutsuminen. Tämä ei tietenkään päde pelkästään AI-ratkaisuihin, vaan yleisesti laadukkaaseen ohjelmistokehitykseen.

Tekoälyä hyödyntävien sovellusten toteutustavasta kuulee monesti käytettävän kahta termiä. Kevyitä, nopeasti tehtyjä ja monesti valmiita kehyksiä hyödyntäviä tekoälyratkaisuja sanotaan ohuiksi kääreiksi (thin wrapper) ja räätälöidyt, kehittyneet tekoälyarkkitehtuurit ovat niin sanotusti paksuja kääreitä (thick wrappers). Kääre viittaa siihen, että sovellus käärii piiloon yhden tai useamman generatiivisen tekoälymallin. Ohuet kääreet eivät juurikaan tuota lisäarvoa käyttäjilleen, sillä ne eivät tuo uutta toiminnallisuutta mallien päälle pieniä aputoimintoja tai käyttöliittymää lukuun ottamatta. Paksut kääreet sen sijaan keskittyvät nimenomaan lisäarvon tuottamiseen luomalla uusia tekoälykyvykkyyksiä yhdistelemällä ohjelmistoja ja malleja innovatiivisesti.

AI-first -ajattelumalli

Tekoäly on siis yllätten luonut uuden ohjelmistosuunnittelun osa-alueen, ja sen nyanssien hallinta vaatii opettelua. Arvioisin, että senioritason backend-kehittäjä pääsee alustavasti kärryille erilaisista GenAI-menetelmistä ja arkkitehtuureista noin puolen vuoden tiiviin kehityssyklin jälkeen. Tässä vaiheessa tosin on tullut jo läjä uusia menetelmiä ja kirjastoja, ja tahti vain kiihtyy. Vaikka esimerkiksi frontend-kehitys tuntuu monesti intensiiviseltä jatkuvine muutoksineen, sovelletun tekoälyn parissa työskennellessä uuden opettelun tahti on kertaluokkaa nopeampi.

Onkin korkea aika omaksua AI-first -ajattelumalli: tekoälyä tulisi kohdella osana ohjelmistoratkaisun ydintoiminnallisuutta sen sijaan että AI liimataan nopeasti vanhan päälle valmista kehystä käyttäen. Muutosprosessi ei ole yksinkertainen, koska pahimmassa tapauksessa tekoälyarkkitehtuurin täysivaltainen toteutus vaatii muutoksia lähes kaikkialle: sekä ohjelmiston kaikkiin kerroksiin että ohjelmistosuunnittelijoiden ajatusmaailmaan. Aikaisemmin hyvin toteutettu ohjelmistoarkkitehtuuri toimii tässä apuna ja helpottaa tekoälyn integrointia. Uusia ratkaisuja suunniteltaessa arkkitehtuurissa tulee ottaa huomioon tekoälyn nykyiset sekä tulevaisuuden vaatimukset.

Ota tekoäly haltuun jo tänään

Tekoälyarkkitehtuuri ei synny ilman vahvaa ohjelmisto-, pilvi-, data- ja integraatioarkkitehtuurien osaamista. Vaikka valmiiden AI-ohjelmistokehysten käyttäminen voi olla nopea ja houkutteleva ratkaisu, niiden rajoitukset tulevat usein esiin tuotannollisissa ympäristöissä. Yrityksen oman datan rakenne, laatu ja saatavuus vaikuttavat paljon toteukseen muusta infrastruktuurista puhumattakaan. Mitä lähemmäksi tekoäly tuodaan ohjelmistojen sovelluskerrosta, sitä merkityksellisempi rooli syvällisellä ohjelmistotekniikan hallinnalla on tekoälyprojektin onnistumisen kannalta.

Softlandian soveltava tekoälyosaaminen mahdollistaa nopean tekoälyn integroinnin loppukäyttäjäsovelluksiin.

AI-first -ajattelumallin omaksuminen ja tekoälyarkkitehtuurin hallinta ovat kriittisiä tekijöitä menestyvissä sovelletun tekoälyn ratkaisuissa. Yritysten on tärkeää kehittää omia kyvykkyyksiään ja ymmärrystään tekoälyn ja ohjelmistoratkaisujen integroinnista varmistaakseen, että ratkaisut ovat sekä laadukkaita että kestäviä. Näin voidaan hyödyntää tekoälyn täysi potentiaali ja säilyttää kilpailukyky ympäristössä, jossa tekoälyn käytöstä on kovaa vauhtia tulossa yritysten elinehto.

Lentävä lausahdus “kaikki yritykset ovat ohjelmistoyrityksiä” voitaneen tekoälyn aikakaudella muuntaa muotoon: kaikki yritykset ovat sekä ohjelmisto- että AI-yrityksiä.