Tässä kirjoituksessa yritän selittää, miten chat-pohjainen AI-työkalu, esimerkiksi OpenAI:n ChatGPT tai Anthropicin Claude, toimii.
Jos olet jo jossain määrin perehtynyt asiaan, tämä aihe voi tuntua itsestään selvältä. Huomasin kuitenkin itsestäni, että perusasioiden vääntäminen rautalangasta auttoi minua itseänikin ymmärtämään tekoälyn toimintaa paremmin, joten uskon, että moni hyötyy tästä kirjoituksesta.
Mitä paremmin ymmärtää tekoälyn toimintalogiikkaa, sitä paremmat edellytykset on rakentaa sen ympärille oikeita, toimivia työnkulkuja. Lisäksi hyvä ymmärrys auttaa ymmärtämään tekoälyn rajoitteita ja toisaalta löytämään tapoja ottaa ne huomioon ratkaisuja rakennettaessa.
Tämän kirjoituksen tarkoitus on luoda pohjaa tuleville kirjoituksille, joissa syvennytään AI:n muihin puoliin.
Olen yrittänyt käsitellä asiaa niin yksinkertaisesti, että tämän voi ymmärtää hyvin kevyelläkin teknisellä taustalla.
Lähdetään liikkeelle siitä, miten chat-pohjainen tekoäly ylipäätään toimii.
Mitä komponentteja chat-pohjaisessa tekoälytyökalussa on?
Chat-pohjainen tekoälytyökalu koostuu sovelluksesta (usein selaimessa toimiva web-sovellus tai mobiilisovellus) ja erillisestä kielimallista.
Käyttäjä syöttää sovellukseen promptin eli jonkin pyynnön tai kysymyksen, jonka sovellus välittää eteenpäin kielimallille. Kielimalli saa käyttäjän pyynnön, prosessoi sen parhaansa mukaan ja antaa vastauksen, joka välitetään sovellukselle, joka puolestaan näyttää sen käyttäjälle. Alla oleva kuva esittää periaatetta tästä.
Tämä on yksinkertaista. Kun kielimalli saa käyttäjän pyynnön, se ymmärtää kielen rakenteita ja pystyy päättelemään, mitä käyttäjä tarkoittaa. Se ei hae vastausta mistään valmiina, vaan tuottaa sen pala kerrallaan opitun aineistonsa pohjalta, käyttäjän toivomalla kielellä. Meistä käyttäjinä tuntuu siltä, että kielimalli tietä mistä se “puhuu”. Mutta mitä vastaamisessa todellisuudessa tapahtuu? Käsitellään sitä.
Miten kielimalli generoi vastauksen?
Kielimalli ei hae vastausta valmiista tietokannasta samalla tavalla kuin hakukone hakee verkkosivuja. Sen sijaan se tuottaa vastauksen pala kerrallaan.
Kuten totesimme, kielimalli pilkkoo ensin kysymyksen tokeneiksi. Vastaus generoidaan samalla tavalla, token kerrallaan.
Kielimalli ei siis kirjoita koko vastausta yhdellä kertaa valmiiksi. Se muodostaa vastauksen askel kerrallaan siten, että jokainen uusi pala perustuu käyttäjän promptiin, aiempaan keskusteluun ja siihen tekstiin, jonka malli on jo ehtinyt tuottaa.
Vaikka tämä kuulostaa mekaaniselta, lopputulos voi silti näyttää hyvin älykkäältä. Kielimalli on koulutettu valtavilla tekstimäärillä, minkä vuoksi se on oppinut kielen rakenteita, käsitteiden välisiä suhteita, tyylejä, päättelyketjuja ja tapoja, joilla ihmiset yleensä vastaavat erilaisiin kysymyksiin.
Vastaus perustuu todennäköisyyksiin
Kielimallit eivät “tiedä” tai “muista” asioita samalla tavalla kuin asiantuntija tietää jonkin asian. Kun se lähtee vastaamaan johonkin kysymykseen, sillä ei ole koko vastausta valmiina mielessä, vaan se generoi vastauksensa lennosta todennäköisyyksien mukaan token kerrallaan. (Tämä on yksinkertaistus: tutkimus viittaa siihen, että malli voi sisäisesti hahmottaa jotain tulevasta jo etukäteen, mutta ainakaan näkyvästi se ei kirjoita koko vastausta valmiiksi ennen tuottamista.)
Toisin sanoen se tuottaa vastausta token eli tekstin palanen kerrallaan ja arvioi jokaisen tokenin jälkeen, mikä olisi todennäköinen seuraava token ottaen huomioon kysymyksen ja jo tuotetun vastauksen.
Jos vastaus on hyvin todennäköinen, kuten alla olevassa esimerkissä, päätyy malli suurella todennäköisyydellä aina samaan vastaukseen.
Entä jos vastaus ei ole näin itsestään selvä, vaan kysymykseen onkin monta todennäköistä vastausta?
Vastaukseen liittyy satunnaisuutta
Malli arpoo seuraavan tokenin todennäköisyyksien suhteessa joka kerta. Kun yksi vaihtoehto hallitsee jakaumaa, arpa osuu käytännössä aina samaan tokeniin; kun vaihtoehdot ovat keskenään tasaisia, tulos taas vaihtelee. Juuri tästä syntyy vastauksen satunnaisuus: sama kysymys voi tuottaa eri vastauksen eri kerroilla.
Otetaan esimerkiksi kysymys: Mikä on paras tapa viettää viikonloppu? Nyt vastaus ei ole itsestäänselvä. Tällöin lopputulos voidaan valita arpomalla, minkä vuoksi sama kysymys useampaan kertaan toistettuna voi tuottaa erilaisia vastauksia.
Satunnaisuuden määrää voidaan säätää. Tätä kutsutaan lämpötilaksi (temperature). Matalalla lämpötilalla malli valitsee lähes aina todennäköisimmän vaihtoehdon — vastaukset ovat ennustettavia ja toistettavia, mutta myös tylsempiä.
Jos lämpötila on kylmä, pysyttäytyy malli tiukasti todennäköisyyksissä ja jos taas lämpötila on korkeampi, voi se valita seuraavaksi tokeniksi vaihtoehtoja, jotka ovat kauempana todennäköisimmästä vaihtoehdosta.
Tässä on hyvä huomata, että lämpötilan säätö tapahtuu varsinaisen kielimallin ulkopuolella. Malli tuottaa kiinteän todennäköisyysjakauman, ja sen ulkopuolinen poimintavaihe päättää lämpötilan avulla, kuinka uskollisesti jakaumaa noudatetaan. Kun lämpötila lasketaan käytännössä nollaan, malli valitsee aina todennäköisimmän tokenin, jolloin sama kysymys tuottaa toistettavasti saman vastauksen. Tämä selittää myös sen, miksi sama kysymys joskus antaa identtisen vastauksen ja joskus ei.
Mitä ongelmia vastausten generoimisesta seuraa?
Kun kielimalli antaa vastauksen, se ei itsessään tarkista sitä. Siksi kielimalli voi antaa erittäin hyödyllisiä vastauksia, mutta myös erehtyä uskottavan kuuloisesti. Jos sen saama lähtötieto on puutteellinen, epäselvä tai väärä, myös vastaus voi mennä pieleen. Tämä on yksi syy siihen, miksi promptin laatu ja mallille annettu konteksti ovat niin tärkeitä.
Todellisuudessa vastaukset eivät kuitenkaan ole täysin satunnaisia. Sovellus ja kielimalli tuottavat tiettyä suuntaa vastauksiin, mutta vastauksissa on tilaa satunnaisuudelle.
Tässä satunnaisuutta voidaan suitsia tarkalla ohjeistuksella, kuten tulevassa kirjoituksessa näemme.
Nyt tiedämme, että kielimalli generoi vastauksen ja se perustuu todennäköisyyksiin. Mutta mitä tapahtuu, kun keskustelu jatkuu? Tarkastellaan hieman sitä, miten keskustelu käytännössä tapahtuu.
Mitä kielimalleihin perustuvassa chatissa tapahtuu kun sen kanssa keskustelee?
Otetaan taas hyvin yksinkertainen esimerkki, jossa käyttäjä esittää sovellukselle jonkin kysymyksen. Lähtötilanteessa sovellus ei tiedä yhtään mitään käyttäjästä. Myöskään kielimalli ei tiedä yhtikäs mitään käyttäjästä.
Tässä käytännössä lähdetään puhtaalta pöydältä. Käyttäjän antama prompti lähetetään sellaisenaan kielimallille, joka antaa pyyntöön perustuvan vastauksen. Tämä on siis vastaava tilanne kuin ylempänä esitin. Alla oleva kuva esittää tällaista tilannetta.
Nyt käyttäjä jatkaa keskustelua ja esittää uuden kysymyksen. Hän näkee ensimmäisen kysymyksensä ja kielimallin esittämän vastauksen sovelluksessa (siis usein selaimessa).
Sovellus kuitenkin tietää, että kielimallilla ei ole mitään hajua siitä, että käyttäjä on vähän aikaa sitten esittänyt kysymyksen. Siksi se liittää käyttäjän promptiin tiedot aiemmasta kysymyksestä ja kielimallin antamasta vastauksesta. Näin kielimalli saa hieman kontekstia uuden vastauksensa pohjaksi.
Kun se vastaa, näyttää siltä, että se ymmärtää käyttäjää hieman paremmin. Ja sehän on totta, koska kielimallille välitettiin nyt enemmän tietoa.
Alla oleva kuva esittää tätä tilannetta.
Entä jos käyttäjä jatkaa keskustelua ja esittää sovellukselle kolmannen kysymyksen? Homma toimii aivan samalla tavalla kuin äskenkin. Sovellus liittää kielimallille lähetettävään pyyntöön aiemmat kysymykset ja vastaukset, kielimalli saa ne, prosessoi kaikki ja antaa taas viisaan vastauksen.
Olennaista tässä on ymmärtää, että nyt kielimallille lähetetään entistä enemmän tietoa. Tässä esimerkissä kielimallin kyvyt alkavat tulla vastaan. Siksi käydään läpi uusi termi, nimittäin konteksti-ikkuna eli context window.
Mikä on konteksti-ikkuna?
Konteksti-ikkuna (engl. context window) määrittelee sen, miten paljon tietoa kielimalli pystyy kerralla käsittelemään. Sama ikkuna rajaa myös vastauksen pituutta, sillä osa ikkunasta kuluu mallin tuottamaan vastaukseen.
Palataan äskeiseen tilanteeseen, jossa käyttäjä esitti kolmannen kysymyksen. Sovellus ottaa sen vastaan ja lähettää kysymyksen sekä aiemman keskusteluhistorian kielimallille. Tämä kysymys mahtuu vielä konteksti-ikkunaan, mutta ikkuna alkaa täyttyä. Alla oleva esimerkkikuva esittää tätä tilannetta.
Mitä tapahtuu, kun konteksti-ikkuna täyttyy? Yleensä sovellus on tietoinen siitä, miten paljon tietoa kielimalli pystyy käsittelemään. Siksi jos sovellus huomaa, että nyt ikkuna täyttyy, se leikkaa sisältöä pois.
Oikeasti tilanne ei ole näin yksioikoinen, mutta kuvitellaan yksinkertaisuuden vuoksi, että näin käy. Alla oleva kuva esittää tilannetta, kun näin käy.
Kielimallille ei pystytty välittämään kaikkea tietoa siitä, miten keskustelu on aiemmin edennyt. Siksi vastauksessakaan ei ole huomioitu aivan keskustelun alkua. Käyttäjä voi huomata tämän ja päätellä, että kielimallin muisti petti.
Nykyään uusien kielimallien konteksti-ikkuna on niin suuri, että tämä ei tule ihan heti vastaan peruskeskustelussa, mutta jos mallille syöttää esimerkiksi suuria dokumentteja, ikkuna kyllä täyttyy.
Usein myös vastauksen kokoa on rajoitettu, jotta käsiteltävä tietomäärä pysyy järjellisenä.
Käyttäjänä on hyvä ymmärtää, että promptit ja vastaukset kulkevat mallille useita kertoja ja kuluttavat siten konteksti-ikkunaa.
Mitä sovellus sitten voi tehdä pienentääkseen kontekstikkunan rajallisuudesta johtuvaa ongelmaa? Vastaus on sisällön tiivistäminen.
Miten sisällön tiivistäminen toimii
Todellisuudessa sovellus ennakoi uhkaavan konteksti-ikkunan täyttymisen ja lähtee tiivistämään aiempaa keskusteluhistoriaa.
Ennen kuin se ottaa käyttäjän uusinta promptia käsittelyyn, se lähettää keskusteluhistorian alkupäästä osan kielimallille ja pyytää sitä tiivistämään sen. Kielimalli tekee työtä käskettyä ja palauttaa siis tiivistelmän sisällöstä. Alla oleva kuva esittää tätä tilannetta.
Sovellus sai siis kielimallilta tiivistelmän, jolla voi korvata ne viestit, joista tiivistelmä on tehty. Nyt konteksti-ikkunassa on taas tilaa ottaa uusi prompti vastaan ja prosessoida vastaus. Seuraavan promptin osalta tilanne näyttäisi kutakuinkin tällaiselta.
Käyttäjä saa taas vastauksen, joka perustuu keskusteluhistoriaan. Voi kuitenkin olla, että käyttäjä alkaa ihmetellä, että jotain outoa tapahtui. Kielimallin muisti ei vaikuta täydelliseltä.
Se johtuu siitä, että tiivistäminen tapahtuu yksityiskohtia hävittämällä. Kyse ei siis ole tietojen pakkaamisesta samaan tapaan kuin tiedostoja voi pakata tietokoneella. Osa pakkauksesta on häviötöntä — esimerkiksi ZIP-pakkaus palauttaa alkuperäisen tiedoston bitilleen ennalleen. Tiivistäminen taas on häviöllistä, samaan tapaan kuin JPEG-kuva, josta yksityiskohtia katoaa eikä niitä saa enää takaisin. Yksityiskohtia joudutaan heittämään menemään, jotta kokonaisuus mahtuu sille varattuun tilaan.
Tiivistäminen muistuttaakin johdon tiivistelmää, johon pyritään kokoamaan olennaisimmat osat käsiteltävästä asiasta. Se on aina tekijänsä käsitys siitä, mitä johtajien pitäisi tietää asiasta. Tämä tiivistelmä ei sisällä kaikkia lukuja, yksityiskohtia tai perusteluja, vaan ainoastaan olennaisimmat.
Onko konteksti-ikkunan koolla käytännön merkitystä?
Aiemmin ikkunan koolla oli suuri merkitys kaikessa käytössä. Konteksti-ikkunan koko on kuitenkin kasvanut viime vuosina eksponentiaalisesti, minkä vuoksi sen merkitys on vähentynyt.
Tavallisessa chat-käytössä, jossa kielimallille esittää kysymyksiä ja siltä saa vastauksia, konteksti-ikkunan koolla ei enää ole juuri merkitystä.
Alla oleva taulukko esittää konteksti-ikkunan koon kasvua. Luvut ovat tokeneita. K tarkoittaa tuhatta ja M miljoonaa tokenia. Käyn token-asiaa läpi hieman tuonnempana.
| Vuosi | Malli | Valmistaja | Konteksti-ikkuna |
| 2020 | GPT-3 | OpenAI | 2K |
| 2022 | GPT-3.5 Turbo | OpenAI | 4K → 16K |
| 2023 | GPT-4 | OpenAI | 8K |
| 2023 | Claude 2 | Anthropic | 100K |
| 2023 | GPT-4 Turbo | OpenAI | 128K |
| 2023 | Claude 2.1 | Anthropic | 200K |
| 2024 | Claude 3 (Opus/Sonnet/Haiku) | Anthropic | 200K |
| 2024 | GPT-4o | OpenAI | 128K |
| 2025 | Claude Sonnet 4 / Opus 4 | Anthropic | 200K (1M beta) |
| 2025 | GPT-5 | OpenAI | 400K |
| 2026 | GPT-5.5 | OpenAI | 1M (API) |
| 2026 | Claude Opus 4.8 / Sonnet 4.6 | Anthropic | 1M (API) |
Taulukossa on yksinkertaisuuden vuoksi vain OpenAI:n GPT-malli sekä Anthropicin Claude. Halusin tällä taulukolla kuvata ikkunan koon kasvua, en absoluuttisia arvoja. Esimerkiksi Googlen Gemini-mallin konteksti-ikkuna on tässä esitettyjä arvoja suurempi.
On hyvä huomata, että konteksti-ikkunan koko ei ole ihan yksioikoinen asia.
Usein yritykset ilmoittavat API:n kautta käytössä olevan konteksti-ikkunan koon. Kuitenkin suuri osa käyttäjistä käyttää kiinteähintaista tilausta tai kuluttajat jopa ilmaisversioita. Näissä ikkuna on pienempi.
Lisäksi vaikka konteksti-ikkuna on virallisesti suuri, mallit pystyvät käytännössä hyödyntämään koko ikkunaa huonosti. Osa ikkunan sisällöstä, usein sen keskivaiheilla oleva, jää vähemmälle huomiolle, ja tämä voi vaikuttaa lopputulokseen.
Ikkunan koolla on merkitystä silloin, kun kielimallille annetaan suuria määriä dokumentteja analysoitavaksi. Silloin ikkuna voi tulla täyteen hyvinkin nopeasti. Varsinkin, kun koko chat-historiaa siirrellään edestakaisin mallille ja takaisin.
Tämä aihe on kuitenkin monimutkainen ja olisikin kiinnostavaa tarkastella tätä syvällisemmin toisessa kirjoituksessa.
Joka tapauksessa on usein perusteltua aloittaa uuden aiheen yhteydessä uusi keskustelu. Tämä tekee myös keskustelujen hakemisesta helpompaa, ja näin samaan aiheeseen palatessa ei tarvitse aloittaa ihan alusta.
Äskeisessä taulukossa vilahti termi token. Mikä se on? Lue eteenpäin niin saat tietää.
Mikä on token?
Toinen keskeinen termi AI:n käytössä on token. Kielimallille annetut tehtävät kuluttavat tokeneita, joten herää kysymys siitä, mikä token oikein on.
Kielimalli ei lue tekstiä sanoina niin kuin me ihmiset luemme. Se lukee tekstiä pötkönä ja pilkkoo sitä lyhyempiin palasiin. Token on siis tällainen tekstin palanen.
Token ei ole sana eikä kiinteä määrä merkkejä, vaan vaihtelevan pituinen tekstin palanen. Yleiset sanat ja sananosat ovat omia tokeneitaan, kun taas harvinaisemmat sanat pilkkoutuvat useampaan osaan.
Teksti muutetaan tokeneiksi ns. tokenisaattorin avulla. Se on kuin lukemaan opetteleva, tekstiä väärin tavuttava lapsi. Se ei toisin sanoen seuraa tavurajoja, vaan pätkii tekstiä oman sanastonsa mukaan. Pilkkominen ei kuitenkaan ole satunnaista, vaan sama teksti pilkkoutuu aina samalla tavalla.
Näin teksti muuttuu tokeneiksi ja vastaavasti tokenit lopuksi takaisin tekstiksi.
Kielien välillä on eroja, miten paljon kielen käsittely vie tokeneita. Tämä ero kiinnosti ja yritin hieman selvittää tätä eroa tarkemmin. En päässyt käsiksi Clauden tai Geminin tokenisaattoreihin, mutta OpenAI:n tokenisaattoria pystyi kokeilemaan. Pääsin seuraaviin tuloksiin:
- Yleisesti ajatellaan, että englanninkielisen tekstin osalta yksi token vastaa noin neljää merkkiä. Suomen kielellä saman arvon ajatellaan olevan noin 3,4 merkkiä per token.
- Sanojen osalta ero on suurempi. Englannissa yksi sana vie arviolta 1,1 tokenia, kun suomen kielellä kuluu 3,5 tokenia.
- Suomeksi tarvitaan tyypillisesti vähemmän sanoja kuin englanniksi, mutta jokainen suomen sana pilkkoutuu useampaan tokeniin. Nämä kaksi tekijää vaikuttavat vastakkaisiin suuntiin, mutta token-kustannus per sana painaa enemmän. Lopputulos on, että saman asiasisällön tuottaminen suomeksi maksaa arviolta 1,5–2 kertaa enemmän tokeneita kuin englanniksi. Luku on suuntaa antava: pieni otokseni antaa merkki- ja sanapohjaisesti laskettuna hieman eri arvioita, joten en uskaltaisi luvata yhtä tarkkaa kerrointa. Joka tapauksessa suunta on selvä — kun käytämme kielimallia suomeksi, maksamme siitä kovempaa hintaa kuin englanninkielinen maailma.
Mihin tokeneita kuluu?
Tokeneita kuluu kolmeen asiaan:
- Syötteeseen (input). Prompti, keskusteluhistoria ja mahdolliset dokumentit muutetaan tokeneiksi, jotka kielimalli käsittelee. Mitä pidempi keskustelu tai suurempi aineisto, sitä enemmän syötetokeneita kuluu.
- Päättelyyn (reasoning). Uusimmat mallit ”ajattelevat” vastausta ennen sen tuottamista. Tämä päättely kuluttaa tokeneita, jotka laskutetaan yleensä tuotostokeneina. Vaativissa tehtävissä päättely voi muodostaa merkittävän osan kustannuksista.
- Vastaukseen (output). Kielimallin tuottama vastaus koostuu tokeneista, jotka muutetaan lopuksi takaisin tekstiksi. Tuotostokenit ovat tyypillisesti syötetokeneita kalliimpia.
Alla oleva kuva esittää periaatetta.
Kun tähän tietoon yhdistää sen, mitä aiemmin opittiin siitä, että sovellus tuuppaa kielimallille aina koko keskusteluhistorian, se kaikki tokenisoidaan ja prosessoidaan joka kerta.
Tällä ei välttämättä ole suurta merkitystä, jos käytetty kielimalli on edullinen tai jos keskusteluhistoria on lyhyt. Asialla on kuitenkin suuri merkitys, jos kielimallille antaa esimerkiksi useita dokumentteja käsiteltäväksi.
API-käytössä toistuvan keskusteluhistorian kustannusta tosin lieventää nykyään niin sanottu prompt caching, jossa aiemmin käsitelty sisältö hinnoitellaan edullisemmin.
Yhteenveto
Tämän kirjoituksen tarkoitus oli avata joitakin peruskäsitteitä, joita on hyvä ymmärtää, kun suunnittelee laajojen kielimallien käyttöä yritysratkaisuissa.
Kävimme läpi sovelluksen roolia kielimallin kanssa keskustelemisessa ja miten kielimalli tuottaa vastauksia. Lisäki opimme, että koko keskusteluhistoria lähetetään joka kerta kielimallille, kun kysymme siltä jotain.
Tämä vaikuttaa vaativammissa käyttötilanteissa konteksti-ikkunan riittävyyteen ja kielimallin kykyyn hahmottaa koko syötetty sisältö.
Samoin tutustuimme token-käsitteeseen ja käsittelimme hieman tokenien kulutusta.
Nämä kaikki peruskäsitteet loivat pohjaa ottaa haltuun uudempia ja varmasti kiinnostavampia AI-käsitteitä.
Julkaisen piakkoin seuraavan kirjoituksen, jossa tulen käsittelemään AI-agenttien toimintaa. Jos tämä ja tulevat tähän aihealueeseen liittyvät kirjoitukset kiinnostavat, tilaa uutiskirjeeni, niin saat tiedon uusista kirjoituksista.