Oman datan AI-pilotit ja niiden sudenkuopat

Lähtökohta on selkeä: Kielimalli ei ole tietomalli, eikä se ”tiedä” mitään. Siinä missä se osaa arvailla kielellisiä asioita ja tuottaa tekstiä, sillä ei ole aavistustakaan yrityksen toimintapolitiikasta, asiakkaista tai tuotteista. Mutta miten oma data löytää tiensä tekoälyn hampaisiin?

Tässä jutussa avaamme käsitteellisellä ja ei-teknisellä tasolla niitä käsitteitä ja toimintatapoja, joita oman datan upottamiseen tarvitaan. Lopuksi pohdimme sitä, miksi jotkut oman datan piloteista osoittautuvat melkoisen vaikeiksi.

Retrieval Augmented Generation – Haun tukema generointi

Kun kielimallin halutaan nojaavan kovaan tietoon, tämä tieto on annettava sille osana promptia. Tätä on helppo kokeilla vaikkapa ChatGPT:ssä: Hanki sopiva tietolähde (esimerkiksi pätkä Wikipedia-artikkelista), kopioi se promptiin ja pistä eteen kysymyksesi ja sopiva johdantolause. Oheisessa kuvassa on napattu pari tekstikappaletta vuoden urheilijasta, ja ohjeistettu bottia:

Missä seurassa Lauri Markkanen pelaa?

Vastaa vain seuraavan tiedon perusteella. Jos vastausta ei löydy alla olevasta tekstistä, vastaa "En tiedä."

Ohjeistus ”Vastaa vain seuraavan tiedon perusteella…” on tärkeässä roolissa. Se kannustaa kielimallia käyttämään sille annettua tietoa, ei sitä, mitä mallin koulutusaineistosta löytyy. Lopputulos ei ole satavarmasti oikea, mutta useimmiten oikeansuuntainen. Tätä voi testata kysymällä tällä pohjalla vaikkapa Laurin parisuhteesta – vastaus on hyvin todennäköisesti ”En tiedä”, vaikka ilman alustusta ChatGPT suostuukin asiaan satuilemaan.

Tämä on konkreettinen esimerkki ns. RAG-toimintatavasta, jossa tekoälyä pyydetään vastaamaan sille samassa yhteydessä annetun nimenomaisen tiedon perusteella. Aiempi tieto-ongelma (”Missä seurassa Lauri Markkanen pelaa?”) on yksinkertaistettu kieliongelmaksi (”Mitä seuraava teksti kertoo Lauri Markkasen tämänhetkisestä seurasta?”), ja kieliongelmissahan kielimallit juuri ovat hyviä.

Karkeasti samalla periaatteella toimii vaikkapa Bing-hakuun liitetty keskustelukin – tietolähde vain täytetään automaattisesti nettihaun perusteella. Ja kyllä – kun pyydät Microsoft 365 Copilotia vastaamaan yrityksen dokumenttien perusteella, aivan samalla tavalla GPT-malli saa dokumentin pätkiä kysymykseen vastaamisen tueksi.

Mistä löytää oikeaa tietoa mallin tueksi?

Yksinkertaista RAG-mallia on helppo käyttää, jos ihminen viitsii aina hakea oikean Wikipedia-artikkelin kyselyn tueksi. Mutta tämähän ei tietenkään riitä, vaan tekoäly pitää saada vastaamaan oikean tiedon perusteella niin, että se hakee sopivat taustatiedot promptin tueksi ihan itse. Periaatteessa pitää siis vain löytää aihetta koskeva teksti tietolähteestä, mutta miten tunnistetaan juuri se oikea teksti?

Yksinkertaisinta on etsiä kysymyksen sanoilla tietolähteestä. Helpossa kysymyksessä tämä toimiikin: ”Millainen on yrityksen autoetupolitiikka?” kolahtaa parhaimmillaan täydellisesti kohdalleen, koska autoetupolitiikka on niin hyvä hakusana. Käytännössä kysymykset ovat usein hankalampia – esimerkiksi ”Miten hoidan liisarin lasinvaihdon?” tai ”Voinko hankkia Audi A8:n (autoetu 1900 e)?” vaativat jo semantiikan ja synonyymien ymmärrystä.

Käytetyin tapa oikein tekstipätkien löytämiseen on ns. embeddings-tekniikka. Kyse on ikään kuin algoritmista, joka osaa koodata lähdetiedon merkityksen eräänlaiseksi muodoksi – parhaimmillaan jopa kieliriippumattomasti, jolloin sama ilmaisu suomeksi ja vaikka saksaksi tuottaa saman lopputuloksen. Teknisesti nämä muodot ovat yleensä 1500-ulotteisia liukulukuvektoreita, mutta koska sellaista on vaikea nähdä sielunsa silmin, seuraavassa kuvassa vektorin roolin on ottanut viivapiirros.

Muista, että kaikki esitetty data on täysin keksittyä, ja embeddingsit eivät oikeasti näytä viivapiirroksilta. Idea on kuitenkin sama: Kukaan projektissa ei välttämättä osaa täsmälleen sanoa, miksi erikielisistä ja eri sanoista muodostetut embeddingsit muistuttavat toisiaan, mutta niin ne vain tekevät.

Tämä samankaltaisuus auttaa sisällön löytämisessä. Kun käyttäjä esittää kysymyksen – vaikka nyt ”liisarin lasinvaihdosta”, voidaan tälle kysymyksellekin muodostaa oma embeddings-muoto. Kun sen jälkeen etsitään mahdollisimman samanmuotoisia tiedonjyviä tietovarastosta, saadaan nippu tekstejä, jotka voisivat sopia mallin tueksi. Tällaisia tietovarastoja kutsutaan vektoritietokannoiksi, ja Azure AI Search on niistä Microsoft-ekosysteemissä eniten käytetty.

Tila loppuu ja ahistaa

Kun oikeat tiedot on tunnistettu, pitäisi vielä taistella optimoinnin kanssa. Malleille ei voi antaa rajattomasti pohjatietoa, sillä niiden käsittelykyky – niin sanottu konteksti-ikkuna – on rajallinen. Lisäksi mitä pidempi kehote, sitä kauemmin vastaus kestää ja sitä enemmän se maksaa. Näistä syistä ei riitä löytää kaikkea tilanteeseen sopivaa tietoa, vaan pitää osata valita vain parhaiten sopiva tieto – usein esimerkiksi kolme tai viisi parhaiten embeddings-muodoltaan täsmäävää pätkää.

Tosimaailmassa embeddings-muotoja ei lasketa yksittäisistä virkkeistä kuten edellisessä kuvassa, vaan jostain hieman suuremmista palasista. Jos tekoälyä tuettaisiin yksittäisillä virkkeillä, riski väärinymmärryksille olisi varsin suuri: esimerkiksi Devisioonan HR-ohjeista löytyy virke ”Työnantaja ei osallistu kustannuksiin”, mutta missä kaikissa yhteyksissä se uskallettaisiin antaa tekoälyn ”ajattelun” pohjaksi?

Useimmissa tilanteissa juurteet (tekoälylle annettavat tiedonpätkät) ovat esimerkiksi tekstikappaleen tai dokumentin luvun kokoisia. Mitä lyhyempi juurre, sitä nopeammin ja halvemmalla malli vastaa. Mitä pidempi juurre, sitä todennäköisemmin tekoäly vastaa loogisesti eheällä tavalla – jo yksittäisessä tekstikappaleessa oleva konteksti vähentää väärinkäsityksen riskiä. Toisaalta ylipitkät juurteet (esim. kokonaiset dokumentit) toimivat huonosti tilanteissa, joissa oikea vastaus pitää tehdä yhdistelemällä useiden lähteiden tietoja.

Se, että onko parempi tarjota mallille yksi pitkä juurre vai monta lyhyttä, riippuu käsiteltävästä tekstistä ja kysymyksestä. Monesti sopivaa juurtamisstrategiaa joudutaan etsimään pilottiprojektissa, ja myös lähdedokumenttien muoto (vapaateksti, PowerPoint-esitys, verkkosivu, video, skannattu lasku…) vaikuttaa. Täydellistä kompromissia ei ainakaan lyhyellä kokeilulla edes ehditä etsiä, vaan hiontaa harrastetaan datapohjaisesti järjestelmän asetuttua tuotantoon – tai edes testiin.

”RAGs to riches” ei aina olekaan niin helppoa

Edellä kuvatuilla periaattella pystytään toteuttamaan monenlaista tekoälyn ”opettamista”. Valitettavasti tosimaailman monimutkaisuus tulee usein mukaan myös tekoälypilotointiin.

Aiemmissa esimerkeissä kuvattiin helppoja tilanteita, joissa lähteenä on vaikkapa intranetin sisältö. Useimmissa tilanteissa on erittäin OK sekoittaa lähdeaineistoja, varsinkin jos käyttäjä esittää kysymyksen tyyliin ”Miten kirjaan HR-järjestelmään hoitovapaani?” – vastaus saattaa olla suorastaan pakko hakea yhdistelemällä perhevapaapolitiikkaa ja HR-järjestelmän käyttöohjetta.

Ensimmäinen mutka matkassa ovat tilanteet, joissa lähdedokumenttien on pysyttävä toisistaan tiukasti erillään. Tähän törmätään esimerkiksi kysyttäessä tarkasti rajattua täsmätietoa: ”Millaisia haasteita X Oy:n CRM-projektissa tuli esiin?” Nyt käyttäjän asettama tärkeä rajaus X Oy:n tietystä projektista on otettava ensisijaiseksi suodattimeksi, vaikka ”CRM-haasteita” muistuttavia embeddings-muotoja olisi vektori-indeksit täynnä. Jos mallille vahingossa lipsahtaa tietoja väärän asiakkaan ”asiakaskortista”, lopputulos voi olla hyvin harhaanjohtava.

Toinen tärkeä vaatimus on metatietojen riittävän laaja huomiointi. Ihmisellä on huikea kapasiteetti ymmärtää konteksti ja myös tunnistaa sen puute. Jos löydät Teamsista satunnaisen hinnastodokumentin ilman viittausta siitä, kenen asiakkaan hinnasto se on, osaat kyllä ihmetellä asiaa. Kielimalli ei osaa, ja jos viittaus oikeaan asiakkaaseen löytyy esimerkiksi vain tiedoston hakemistopolusta, dokumentin otsakkeesta tai vastaavasta ”syrjäisestä” paikasta, on kohtalainen riski siitä, että jossain kohtaa sisältö tulee väärinymmärretyksi.

Kolmas elämää hankaloittava tekijä ovat käyttöoikeudet. Teoriassa oikeussuodatus on yksinkertainen juttu – huomioidaan vain ne embeddings-muodot, jotka on muodostettu sellaisista dokumenteista, joihin käyttäjällä on oikeus. Ongelmaksi muodostuu usein kuitenkin erilaisten käyttöoikeuskonfiguraatioiden testaaminen kriittisessä sovelluksessa. Tekoäly vastaa muutenkin epädeterministisesti (eri kerroilla eri tavoin), ja testausvaivan moninkertaistaminen tuo projekteihin monesti lisähaasteita.

Mikä siis neuvoksi?

Testaus, palaute, iterointi; toista kunnes on valmista. Perustyökalut kehittyvät tavanomaisimpien ”otetaan kaikki data paikasta X”-skenaarioiden siivittämänä nopeasti, mutta laadukkaaseen metadatan käsittelyyn ei ole vielä tullut taikakalua. Se on edelleen käsin koodattavaa liiketoimintalogiikkaa.

Useimmiten kysymys ei ole edes pelkästään siitä, miten oma data saadaan annettua tekoälyn käyttöön ja mistä embeddingsit lasketaan. Käytännössä varsin monissa projekteissa päästään ylipäätään data- ja integraatiokonsultoinnin vahvaan ytimeen: miten edes ensin huolehdittaisiin siitä, että organisaation keskeinen data olisi hallittavien rajapintojen kautta haettavissa?

Tämän kysymyksen ratkaisussakin tapahtuu edistystä, mutta se tapahtuu ennen muuta toimittajaorganisaatioiden kokemuksen kasvun ja asiakkaiden tekemän työn – esimerkiksi metadatan asettamisen – myötä. Sama työpanos ja kokemus auttaa myös muissa kuin räätälöidyissä tekoälypiloteissa – ei se Copilot for Microsoft 365:kaan maagisesti kaikkea tajua, vaan hyvin jäsennelty data on kriittisessä roolissa sitäkin ajatellen.

Ehkäpä tekoäly viimein samalla kannustaa saamaan sen datan arkihallinnan kuntoon.

Haluatko sparrailla tekoälyhaasteistasi? Mietityttääkö digitalisaation tai hajanaisen datan tilanne? Ota yhteyttä!