Olli-Pekka Heinisuo
Perustaja, Senior Software Architect
icon

Microsoft Copilot, Grok, ChatGPT ja YOKOT.AI – näin RAG:t toimivat

Generatiiviset AI-ratkaisut ottivat valtavan harppauksen eteenpäin marraskuussa: Microsoft julkaisi Copilotin, X.ai beta-version Grok-mallista ja uudet OpenAI-ominaisuudet julkaistiin OpenAI:n devaajatapahtumassa. Olennainen tieto näiden ratkaisujen toiminnasta on kuitenkin haudattu pöhinän ja muotisanojen alle, joita useimmat ihmiset eivät ymmärrä. Tekninen tieto on vaikeasti saatavilla, ja sen ymmärtäminen on hankalaa, koska vain generatiivisten AI-ratkaisujen parissa työskentelevät ymmärtävät uusia termejä ja sanastoa.

Tässä blogikirjoituksessa kerron, mitä yhteistä näillä ratkaisuilla on ja miten ne toimivat – tai ainakin vaikuttavat toimivan. Minulla ei ole pääsyä kaikkien näiden ratkaisujen tarkkoihin teknisiin tietoihin. Oman generatiivisen tekoälytuotteemme YOKOT.AI:n ja internetistä löytyneiden lähteiden perusteella voin kuitenkin tehdä valistuneen arvauksen niiden toimintalogiikasta.

Generatiiviset tekoälymallit hyödyntävät esikoulutettua tietoa

MS Copilot, Grok, YOKOT.AI ja ChatGPT hyödyntävät konepellin alla niin kutsuttuja perusmalleja. Yleensä perusmallina on GPT-3.5 tai GPT-4, koska ne ovat tällä hetkellä tehokkaimpia suuria kielimalleja (LLM, large language model). Grok käyttää Grok-1-mallia, joka muistuttaa pitkälti GPT-3.5:tä.

Kun käyttäjä kysyy kysymyksiä näiltä malleilta, ne vastaavat niiden tietojen perusteella, joilla ne on koulutettu. Tästä syystä jokaisella mallilla on tietty katkaisupäivämäärä, jonka jälkeisestä materiaalista tai tapahtumista mallilla ei ole tietoa. Kun ihmiset käyttävät näitä malleja ja haluavat hyödyntää joko ajantasaista tai toisaalta yksityistä tietoa, se on jollain tavalla opetettava mallille.

On olemassa kallis ja hidas tapa hienosäätää kielimalli kouluttamalla se lisätietojen avulla. Siinä mittakaavassa, jossa Microsoft, X ja jopa me Softlandiassa toimimme, tämä ei ole käytännöllistä hitauden sekä korkeiden kustannusten vuoksi. Hienosäätö on kuitenkin hyödyllistä tietyissä käyttötapauksissa. Tällainen työ tehdään yleensä erillisinä projekteina asiakkaille, jotka vaativat erityistä lähestymistapaa johonkin liiketoimintansa osa-alueeseen. Mutta jos ei käytetä hienosäätöä, miten mallit saadaan hyödyntämään lisättyä dataa?

Lyhyt johdatus RAGiin – retrieval augmented generation

Tuotteemme YOKOT.AI käyttää kehittynyttä RAG-menetelmää eli (haulla tehostettu generointi, retrieval augmented generation) täydentämään perusmallia käyttäjän järjestelmään lisäämällä datalla. Suomess kehittäjät käyttäjät RAGista usein sanontaa "räggi".

Mitä RAG tarkoittaa? Käytännössä RAG on ohjelmistotekninen lähestymistapa, jolla pyritään korjaamaan puutteita suurten kielimallien tiedoissa. RAG hakee relevantin ulkoisen datan määritetystä lähteestä, täydentää käyttäjän kyselyä haetuilla tiedoilla ja antaa haetut tiedot sekä käyttäjän kysymyksen LLM:lle. Näin kielimalli generoi vastauksen käyttäen tätä tietoa lisäkontekstina. Mallin ankkurointiin (eng. grounding, termiä on hankala suomentaa) voidaan käyttää monia menetelmiä. Yksinkertaisuuden vuoksi keskitymme tässä yhteydessä kontekstissa tapahtuvaan oppimiseen (in-context learning).

Hakuvaihe toteutetaan yleensä vektoritietokannan avulla. Vektoritietokanta sisältää kaiken lisätyn tekstitiedon numeerisessa, vektorisoidussa muodossa, jotta tietoa voidaan helposti hakea matemaattisesti. Teksti muutetaan upotusmalleilla vektoreiksi, eli numerolistoiksi tai tokeneiksi, jotka edustavat tekstin pienempiä osia. OpenAI:n Ada-malli on hyvä esimerkki upotusmallista. Relevantti tieto haetaan vektoritietokannasta käyttäjän vektorisoidun kyselyn perusteella. Vektoreiden vertailuun tyypillinen mittari on kosinisamankaltaisuus (cosine similarity).

Vektoritietokannasta saamme listan parhaiten käyttäjän syötteeseen täsmääviä tekstejä. Järjestelmän tehtävänä on päättää, miten se käyttää, yhdistää tai jatkokäsittelee näitä ennen käyttäjän kyselyn täydentämistä tietokannasta saaduilla tiedolla. Tämän jälkeen järjestelmä tekee generatiivisen kutsun LLM:lle ja palauttaa vastauksen käyttäjälle.

Käytän Softlandian yksityistä generatiivista tekoälyratkaisua eli YOKOT.AI:ta esimerkkinä tiivistääkseni nämä vaiheet:

  1. Käyttäjä käy läpi Softlandian verkkosivuston YOKOT.AI:n avulla. Tämän jälkeen YOKOT.AI:lla on kaikki Softlandian verkkosivujen sisällöt indeksoituina vektoritietokantaan "Softlandia" -tunnisteella.

  2. Käyttäjä esittää kysymyksen YOKOT.AI:lle ja opastaa YOKOT.AI:ta käyttämään "Softlandia" -tunnisteen alla olevaa aineistoa tietolähteenä: "Kerro minulle Softlandiasta."

  3. Käyttäjän kysymys muunnetaan vektorimuotoon upotusmallilla.

  4. Vektoritietokannasta haetaan parhaiten vastaavat tekstit.

  5. Parhaat osumat lisätään lopulliseen LLM-kyselyyn.

  6. Järjestelmä palauttaa vastauksen käyttäjälle.

Parhaiden tulosten saavuttamiseksi prosessi vaatii monimutkaisempaa logiikkaa ja yleensä lisäpäättelyä useiden LLM-kutsujen tai LLM:ien funktiokutsukykyjen avulla. Tämä yksinkertaistettu yhteenveto kuitenkin toivottavasti auttaa ymmärtämään, miten nämä tekoälyratkaisut toimivat.

MS Copilotin ja Grokin arkkitehtuurin analysointi

Nyt kun olemme käyneet läpi RAG-menetelmän, voimme peilata sitä MS Copilotin ja Grokin arkkitehtuuriin. Microsoft on julkaissut joitain korkean tason arkkitehtuurikaavioita, jotka muistuttavat hyvin paljon RAGia. Microsoft käyttää omaa Graph APIaan noutaakseen käyttäjälle saatavilla olevan datan. Kaavioiden perusteella noudettua organisaatiodataa indeksoidaan jatkuvasti järjestelmään, johon voidaan tehdä semanttisia hakuja. Tämä tarkoittaa, että jossain on todennäköisesti jonkinlainen vektoritietokanta. LLM-kyselyt ankkuroidaan tietokannasta saatuihin vastauksiin.

Kaavio MS Copilotin RAGista

Grokista tiedämme sen, että X käyttää Qdrant-vektoritietokantaa syöttääkseen sille reaaliaikaisesti Grokin käyttämää dataa. Tämä viittaa jälleen RAG-lähestymistapaan: kaikki uudet viestit (tweetit) lisätään reaaliajassa vektoritietokantaan, ja Grok tekee sitten kyselyitä kyseiseen tietokantaa saadakseen reaaliaikaisesti kontekstin keskusteluihin. Qdrantia käytetään myös X:n uudessa "samankaltaiset viestit" -ominaisuudessa, joka on käytännössä RAG:n hakuvaihe. Myös YOKOT.AI muuten käyttää Qdrant-tietokantaa!

Olen yksinkertaistanut monia asioita tässä postauksessa, mutta korkean tason arkkitehtuuri näissä kolmessa ratkaisussa on todennäköisesti melko samankaltainen. Voidaan siis sanoa, että tällä hetkellä RAG-pohjainen lähestymistapa on suosittu arkkitehtuuri generatiivisille tekoälysovelluksille. Yksinkertaisiin käyttötapauksiin tässä postauksessa kuvaillun kaltainen RAG riittää varsin hyvin. Monimutkaisemmat käyttötapaukset vaativat uudenlaisia lähestymistapoja tiedon indeksointiin, hakemiseen ja yhdistämiseen sekä promptaukseen.

Enemmän ohjelmistokehitystä, vähemmän tekoälyä

Mitä voimme tästä oppia? Sen, että huippuluokan tekoälyratkaisujen kehittämisessä suurten kielimallien päälle on ennen kaikkea kyse ohjelmistotekniikasta, ei niinkään tekoälystä. Toki tarvitset syvällistä osaamista ja tietoa tekoälystä sekä koneoppimisesta, mutta painopiste on ohjelmistopuolella. Näitä uusia ratkaisuja kehittäviä henkilöitä kutsutaan englanniksi nimikkeellä applied AI engineer - ohjelmistotekniikan insinööri, joka ovat erikoistunut soveltamaan tekoälyä ohjelmistoratkaisuissa.

Kuten tässä blogikirjoituksessa on selitetty, perusmallien rajoitukset voidaan selättää älykkäillä ohjelmistotekniikan kikoilla, jotka saavat LLM:n hyödyntämään lisätietoa ilman varsinaista uudelleenkoulutusta. Tätä alaa tutkitaan ja kehitetään jatkuvasti. Uusia lähestymistapoja RAG:iden parantamiseksi julkaistaan säännöllisesti - ja me arvioimme niitä jatkuvasti YOKOT.AI:ta kehittäessämme.

Jos haluat tietää enemmän generatiivisesta tekoälystä, RAG:ista ja viimeisimmistä sovelletuista tekoälyratkaisuista, ota meihin yhteyttä. Teemme jatkuvasti yhteistyötä yritysten kanssa, jotka ovat edelläkävijöitä LLM:ien ja muiden nykyaikaisten tekoälyratkaisujen hyödyntämisessä.