Arena Pro
Ihmisen pään ääriviivat ja AI sekä Prompt tekstit kuvan päällä

Kuva: Adobe Stock

Avoimet kielimallit suomenkielisen tekstin luokitteluun

Teknologia ja teollisuus

Viimevuosina kielen käsittely on ottanut suuria harppauksia eteenpäin uusien suurten generatiivisten kielimallien myötä. Tekstin luokittelu on yksi käyttökohde, johon generatiivisia kielimalleja voi soveltaa. Avoimet kielimallit mahdollistavat tietoturvallisen tekstin luokittelun omassa laskentaympäristössä.

Suuret kielimallit, kuten yleisesti tunnettu OpenAI:n ChatGPT, ovat mahdollistaneet täysin uudenlaisen kielen käsittelyn ja pystyvät nykyään jo älykkääseen vuorovaikutukseen ihmisen kanssa. Keskustelun lisäksi nämä kielimallit pystyvät seuraamaan ihmisen antamaa ohjeistusta, ja niitä voi hyödyntää myös muihin tehtäviin, kuin pelkästään vastaamaan triviakysymyksiin. Malleja käytetään yleisesti raakatekstin muotoiluun, tekstin tiivistämiseen, kielikäännösten tekemiseen ja moniin muihin tehtäviin, jotka säästävät paljon käyttäjien omaa aikaa tekstin käsittelystä (Hadi ym., 2024).

Edellä mainittujen käyttöesimerkkien lisäksi nämä uudet kielimallit toimivat erinomaisesti myös tekstin luokitteluun. Tekstin luokittelu ei ole välttämättä niin hyödyllinen ominaisuus normaalille tekoälyn käyttäjälle, kuin muut edellä mainitut esimerkit, mutta suurten tekstistä koostuvien datamassojen analysointiin tekstin luokittelu on tärkeä askel datan esikäsittelyssä.

Ennen kuin uudet kielimallit tulivat saataville, tekstin luokittelu oli erittäin haastavaa. Ongelman ratkaisemiseksi tarvittiin työläs vaihe, jossa ihminen valmisteli tekoälylle tuhansista näytteistä koostuvan opetusdatasetin (Li ym., 2022). Opetusdatasetti sisälsi tekstinäytteitä, jotka ihminen oli käynyt läpi, ja merkinnyt kuuluvaksi johonkin tiettyyn luokkaan. Uusien suurten generatiivisten kielimallien kanssa tämä ei ole enää välttämätön työvaihe, vaan nämä mallit sisältävät jo niin paljon älyä, että ne pystyvät tekemään luokittelua ohjeistuksen, tai vain muutaman esimerkin perusteella (Wei ym., 2022).

Luokiteltu data mahdollistaa sen, että datamassasta löytyviä samaan kategoriaan liittyviä näytteitä käsitellään yhtenä joukkona. Tämä mahdollistaa esimerkiksi datan analysoinnin ja visualisoinnin niin, että eri kategorioihin menevien näytteiden määrää seurataan ylätasolla, joka voi olla hyödyllistä esimerkiksi valmistavan teollisuuden prosessien seurantaan, kuten laadunvarmistuksessa löytyneiden virheiden analysointiin.

Monissa käyttökohteissa luokiteltava data voi kuitenkin olla arkaluonteista. ChatGPT palvelun tyyppisissä tuotteissa luokiteltavaksi haluttava teksti lähetetään palveluntarjoajan konesaliin prosessoitavaksi, joka voi tietyissä käyttötapauksissa olla rajoittava tekijä tietoturvan vuoksi.

Viime aikoina suuret teknologiayritykset ovat kuitenkin alkaneet julkaisemaan avoimesti saatavilla olevia generatiivisia suuria kielimalleja, joita käyttäjät voivat ajaa omilla laskenta-alustoillaan. Tällöin datan tietoturva voidaan varmistaa tasolla, joka ei ole mahdollista kolmannen osapuolen tarjoamien palvelujen, kuten ChatGPT:n kanssa.

Yksi tällaisista avoimista kielimalleista on Meta yrityksen (Facebook), julkaisema Llama kielimalli (Meta, 2024). Tässä artikkelissa käsitellään kokemuksia selvityksestä, jossa Llama 3.1 70B kielimallia hyödynnettiin Jamkin omassa laskentaympäristössä (Jokinen ym., 2020) traktorivalmistaja Valtran laadunvarmistusprosessissa syntyneen suomenkielisen tekstidatan luokitteluun.

Tekoälyn ohjeistaminen luokitteluun

Tärkeä osa generatiivisten suurten kielimallin käyttöä on mallin promptaus, eli mallin syötteen suunnittelu sellaiseksi, että mallin antama vastaus on mahdollisimman laadukas, ja vastaa käyttäjän odotusta. Kun malleja sovelletaan tehtävien suorittamiseen, kuten luokitteluun, niin mallin syötteessä tulee selvästi kuvailla tehtävä, jota mallin odotetaan suorittavan.

Mallin syötteen suunnittelu on enemmän taidetta, kuin tiedettä. Aiheen ympärille on syntynyt ihan uusi tutkimuksen suuntaus “Prompt engineering”, jossa pyritään kehittämään parhaita syötteitä kielimalleille halutun käyttäytymisen saavuttamiseksi (Sahoo ym., 2024). Koska mallin käyttäytyminen on loppujen lopuksi riippuvainen siitä, että minkälaista dataa mallin opettamiseen on käytetty, niin syötteen suunnittelu voi olla hyvin mallikohtainen. Yhdenlainen syöte voi toimia hyvin tietyn tekoälymallin kanssa, mutta huonosti toisen kanssa.

Koska suuret generatiiviset kielimallit on opetettu seuraamaan käyttäjän ohjeistusta, ja ne on opetettu massiivisella määrällä ihmisten kirjoittamaa tekstiä, niin lähtökohtaisesti syötteen muoto voi olla hyvin ihmismäinen. Tehtävänannon voi kirjoittaa hyvin samalla tavalla, kuin miten esimerkiksi työnantaja voisi ohjeistaa uutta harjoittelijaa.

Mallille menevä syöte koostuu yleensä eri osista. Useat mallit tukevat niin sanottua “system prompt” osiota, jossa mallille annetaan yleiset ohjeet odotetusta käyttäytymismallista. Tässä osiossa voidaan esimerkiksi rajoittaa malli vastaamaan vain kysymyksiin, jotka liittyvät tiettyyn aihealueeseen.

Tässä selvityksessä mallin system prompt osio oli yksinkertaisuudessaan:

You are a helpful AI assistant. Keep the answer short and concise. Respond ”Unsure about answer” if not sure about the answer.

System prompt osion jälkeen syöte jatkuu käyttäjän (user rooli) ja mallin (assistant rooli) vuoropuhelulla käyttäjän aloituksella.

Tässä selvityksessä syöte alkoi seuraavanlaisella ohjeistuksella, joka oli osana ensimmäistä user roolina annettua viestiä. Syötteessä mainittu käyttäjän valitsema vikaluokka oli hyödyllinen vain muutamien kategorioiden kohdalla, ja usein se sisälsi vain arvon “Asennusvirhe”:

Tractor manufacturer has collected data from their manufacturing process. They want to classify the defects from the manufacturing process to a small number of classes. The defects are flaws that happen during the tractor assembly process, and are discovered at some point in the assembly line or during the quality assurance. The defects are free text descriptions of the defect written by specialists working in the assembly line or in QA. The person who reported the defect also selects a defect class for the report, however the class is not always correct or logical. The user reported defect class is in the first line of the defect report. With part shortage defects, the user reported class is usually correct. In some cases the reporter also includes the part id of which the report concerns. The description is in Finnish and includes a lot of jargon terms that are related to tractors.

Kielen vaikutus syötteen prosessointiin

Kuten edellä olevista esimerkeistä voi huomata, niin tässä selvityksessä käytettiin englannin kieltä mallin syötteen ohjeistusosuudessa, vaikka lopputavoitteena oli luokitella suomenkielistä tekstiä.

Englannin kielen käyttöön päädyttiin sillä perusteella, että vaikka käytetty Llama malli tuloksien perusteella selvästi ymmärtää suomea, niin julkaisijan mukaan malli ei kuitenkaan tue suomen kieltä (Meta, 2024). Tämä voi viitata siihen, että suomen kielen osaaminen ei ole ollut mallin opetusvaiheessa prioriteetti, vaan malli on oppinut suomen “vahingossa” opetusdatasetissä olleen suomenkielisen tekstin avulla.

Toinen syy englannin kielen käyttöön on tekninen, ja liittyy tekstin esikäsittelyyn siinä vaiheessa, kun se muutetaan sellaiseen muotoon, että malli pystyy sitä käsittelemään. Kaikki tämän hetken suuret generatiiviset kielimallit käyttävät ennalta määriteltyä rajallista sanastoa johon mallin syöte muutetaan ennen prosessointia, eli kun syöte tokenisoidaan.

Mallin käyttämä sanasto määritellään mallin opetusdatasetistä, ja se koostuu sanoista ja osa-sanoista, jotka esiintyvät paljon datasetissä (Zouhar ym., 2023). Tässä selvityksessä käytetyn Llama 3.1 70B mallin sanasto on kooltaan 128 256 tokenia, eli malli tuntee näin monta sanaa tai osasanaa.

Koska Llama mallit on opetettu pääasiassa englanninkielisellä datalla, niin sanasto sisältää helposti kaikki yleisesti käytetyt englannin kielen sanat kokonaisuudessaan omina tokeneinaan, mukaanlukien yleisesti käytetyt sanojen taivutusmuodot, mutta suomen kieltä tokenisoitaessa sanat joutuu koostamaan useasta osa-sanasta. Esimerkiksi syötteen alku englanniksi ja suomeksi tokenisoituu seuraavanlaisesti.

[’Tr’, ’actor’, ’ manufacturer’, ’ has’, ’ collected’, ’ data’, ’ from’, ’ their’, ’ manufacturing’, ’ process’, ’.’]

[’Tr’, ’akt’, ’or’, ’in’, ’val’, ’mist’, ’aja’, ’ on’, ’ ker’, ’än’, ’ny’, ’t’, ’ data’, ’a’, ’ he’, ’id’, ’än’, ’ val’, ’mist’, ’us’, ’pro’, ’sess’, ’ista’, ’an’, ’.’]

Eli englannin kielellä tokenisoidun lauseen pituus on vain 11, koska kaikki englanninkieliset sanat löytyvät suoraan mallin sanastosta poislukien “Tractor”, joka koostetaan kahdesta osa-sanasta “Tr” ja “actor”. Sanastosta löytyy kyllä sanat “tractor” ja “ tractor”, mutta ei isolla alkukirjaimella alkavaa välilyönnitöntä versiota sanasta.

Suomen kielisessä lauseessa pelkästään “ on” tokeni löytyy mallin tuntemista sanoista suoraan, ja kaikki muut sanat on koostettu osasanoista. Tämän vuoksi suomenkielinen tokenisoitu syöte on pituudeltaan 25, eli yli kaksi kertaa pidempi, kuin englanninkielinen vastaava lause.

Johtuen suurten generatiivisten tekoälymallien teknisestä toteutuksesta, jokainen lisätokeni syötteessä nostaa vaadittujen laskusuoritusten määrää silloin, kun malli vastaa käyttäjän syötteeseen, eli generoi uutta tekstiä (Duman Keles ym., 2023). Tämän vuoksi malli generoi tekstiä hieman nopeammin lyhyellä syötteellä, kuin pitkällä syötteellä. Kun mallilla prosessoi suuria datamassoja, niin syötteen pituuden ero voi nousta merkittäväksi tekijäksi.

Mallin suurin mahdollinen syötteen pituus on myös rajallinen, joten englannin kielellä mallille pystyy antamaan enemmän informaatiota, kun suomen kielellä. Llama 3.1 70B mallille ilmoitettu maksimaalinen syötteen pituus, jolloin malli voi vielä muistaa alkupään tekstiä, on kuitenkin 128 tuhatta tokenia, joten se ei ollut rajoittava tekijä tässä selvityksessä (Meta, 2024).

Luokkien määritys syötteessä

Esiohjeistuksen lisäksi mallille tulee antaa mahdolliset luokat, joihin käyttäjä haluaa tekstin luokittelun tapahtuvan. Tässä tutkimuksessa näytteet haluttiin luokiteltavan aina vain yhteen luokkaan, joten luokat oli määriteltävä sillä tavalla, että ne olisivat mahdollisimman vähän päällekkäisiä. Tekstillä tulisi olla jokin selvä luokka mihin se aina kuuluu, mutta tämä voi olla haastavaa.

Halutut luokat annettiin mallille osana ensimmäistä käyttäjä roolilla tehtyä viestiä jatkamalla edellä ollutta syötettä seuraavanlaisesti:

The description is in Finnish and includes a lot of jargon terms that are related to tractors. The defects must be classified in the following defect classes:

– **Leaks**: Use this class only when the defect description explicitly mentions a leak (vuotaa, öljyssä, öljynoro) with some system
– **Scratched Parts and Other Appearance Defects**: Use this class when the defect mentions scratches, misaligned decorative covers, or other issues related to appearance
– **Adjustment**: Use this class when some part needs adjustment
– **Windshield Washer**: Use this class for all defects that describe problems with water flow to window washing system (pissapoika), or when the washer system spray is not hitting the right spot
– … (lista jatkuu muilla luokilla, joita oli yhteensä 15)
– **Other**: Use this class for all other defects where the description does not fit to any other class

Tässä tutkimuksessa luokkia oli yhteensä 15, eikä luokkien suuri määrä näyttänyt olevan ongelma mallille.

Jotkut virheet, kuten tuulilasin pesurin suuntaukseen liittyvät ongelmat menivät aluksi aina “Leaks” luokkaan mallin logiikan mukaan, sen sijaan, että ne menisivät “Adjustment” luokkaan, joka ainakin oman logiikan mukaan olisi parempi luokka. Ongelma oli kuitenkin helposti korjattavissa luomalla tarkasti tuulilasin pesuriin liittyvä luokka “Windshield Washer”, johon malli kyllä hienosti osasi luokitella kyseiset ongelmat. Tarvittaessa kyseisen luokan virheet voi jälkikäteen helposti yhdistää “Adjustment” luokan virheisiin saavuttaen alkuperäisen tavoitteen.

Suomenkielisten esimerkkisanojen lisääminen virheen kuvaukseen lisäsi luokittelutarkkuutta joidenkin virheiden kohdalla. Esimerkiksi termi “noro” näytti olevan mallille hankala suomenkielinen termi, mutta termiä käytettiin jonkin verran kuvaamaan heikkoa vuotoa jossain paikassa. Lisäämällä “(vuotaa, öljyssä, öljynoro)” “Leaks” luokan kuvaukseen auttoi mallia luokittelemaan nämä virheet oikein.

Haluttujen luokkien lisäksi mallille kannattaa antaa myös “Other” luokka, johon malli voi luokitella sellaiset virheet, jotka eivät kuulu loogisesti mihinkään muuhun luokkaan.

Luokkien listauksen jälkeen mallin syöte jatkuu seuraavalla ohjeistuksella:

Based on defect description, select one of the classes that is most suitable for the defect. Only select one class. When a defect fits in multiple classes, prefer the class that is listed first. If not sure about the class, select the **Other** class. Answer only the class name, no need for explanation why the class was chosen.

Kuten aiemmin mainittiin, tässä selvityksessä haluttiin luokitella tekstit aina vain yhteen ainoaan luokkaan. Tämä tuotiin mallille ilmi tässä vaiheessa syötettä.

Mallia myös ohjeistettiin valitsemaan paras luokka järjestyksen perusteella, jos teksti kuului loogisesti kahteen tai useampaan eri luokkaan. Tämä ohjeistus ei kuitenkaan testien perusteella toiminut erityisen hyvin. Luokkien järjestyksen vaikutusta luokitteluun testattiin muutamalla virheellä, joiden luokitus olisi hyvin osunut useaan eri luokkaan. Malli ei kuitenkaan näyttänyt suosivan ensimmäisenä listattua luokkaa. Ohjeistus kuitenkin jätettiin syötteeseen, koska siitä ei näyttänyt olevan mitään haittaa.

Aluksi malli perusteli vastauksensa, joka vaikeutti annetun luokan ohjelmallista tulkintaa, koska vastauksen formaatti muuttui vastausten välillä. Ohjeistus “Answer only the class name…” oli kuitenkin riittävä mallille siihen, että se ei alkanut perustelemaan päätöstään, vaan vastasi aina pelkästään luokan nimellä, kuten sitä oli ohjeistettu.

Formaatin oikeellisuutta pystyi vahvistamaan vielä lisää antamalla yksi esimerkkivastaus syötteen alussa. Kuten alussa mainittiin, niin näiden uusien kielimallien syöte yleisesti koostuu “system prompt” osiosta, jonka jälkeen alkaa “user” roolin, ja “assistant” roolin vuoropuhelu.

Aina kun mallia pyydetään generoimaan uutta tekstiä, niin vuoropuhelun historia menee mallille tekstinä. Kaikki viestihistorian käyttäjän kirjoittamat viestit on merkattu “user” roolin omaaviksi viesteiksi ja kaikki mallin aiemmin generoimat viestit ovat “assistant” roolin omaavia viestejä. Tästä malli näkee keskustelun aiemman kontekstin ja näkee mitä “hän” on aiemmin vastannut käyttäjälle.

Keskusteluhistorian voi kuitenkin “väärentää” tavalla, jolla keskusteluhistorian ensimmäinen luokittelupyyntöön vastaava “assistant” roolilla oleva viesti on oikeasti käyttäjän määrittelemä eikä mallin generoima. Tällä tavalla mallille voi antaa esimerkkivastauksen käyttäjän kysymykseen, johon pohjautuen malli jatkaa samaa käyttäytymistä keskustelussa.

Keskusteluhistorian “väärentämistekniikka” oli mahdollista tässä tutkimuksessa, koska mallia ajettiin omalla laskentapalvelimella, jolloin syötteen esikäsittely oli mahdollista muokata halutunlaiseksi. Kolmannen osapuolen hallinnoimat palvelut, kuten ChatGPT voivat rajoittaa keskusteluhistorian muokkausta, ja mahdollistaa vain “user” roolilla olevien viestien lisäämisen keskusteluhistoriaan.

Löydökset

Luokittelun laadukkuus yllätti todella positiivisesti. Perinteisille tekoälymalleille pystytään yleensä laskemaan helposti jonkinlainen hyvyysluku, joka kertoo mallin kyvykkyydestä opetusdatasetin ulkopuolisten näytteiden luokitteluun. Hyvyysluku johdetaan opetusdatasetissä esiintyvien ihmisen määrittelemien todellisten luokkien avulla, joita verrataan tekoälymallin antamiin luokkiin. Tässä selvityksessä mallin hyvyydelle oli kuitenkin hankala määrittää mitään kuvaavaa lukua, koska luokittelu tehtiin ilman minkäänlaista opetusdatasettiä, eli tekstille ei ollut tiedossa todellisia luokkia, joihin ne kuuluvat.

Manuaalisesti selaamalla ja arvioimalla pientä osaa tuloksista luokittelun oikeellisuus oli kuitenkin erinomaista. Myös omasta mielestäni väärin luokitelluista teksteistä löytyi aina jonkinlainen logiikka, joka selitti, että miksi malli oli laittanut sen väärään luokkaan. Syötteessä olevia luokkakuvauksia muokkaamalla, tai uusia luokkia lisäämällä, virheluokittelut saatiin lähes aina menemään haluttuun luokkaan.

Syötettä oli helppo debugata esittämällä mallille jatkokysymyksen “Explain why the class was chosen” luokittelutuloksen jälkeen, jos se oli jotain muuta kuin mitä odotettiin. Tällöin malli avasi luokittelulogiikkaa, josta yleensä kävi hyvin ilmi mistä väärinkäsitys johtui. Tällä menetelmällä syötettä oli hyvä kehittää eteenpäin ja löytää tarvittavat luokat.

Esimerkkinä mallille hankalasti ymmärrettävä kuvaus, joka kuvailee ongelmaa oven tiivisteen paikallaanpysymisen kanssa:

User: User reported defect class is Asennusvirhe
Defect description: Oven yläreunasta tippuu tiiviste

Assistant: Leaks

User: Explain why the class was chosen

Assistant: I chose the class ”Leaks” because the defect description mentions ”tippuu” which is Finnish for ”is dripping” or ”is leaking”, and ”tiiviste” which is Finnish for ”sealant” or ”gasket”, implying that there is a leak from the sealant.

Vaikka tässä selvityksessä käytetyt Valtran laadunvarmistusprosessista peräisin oleva tekstidata sisältää paljon ammattislangia ja kiireestä johtuvia kirjoitusvirheitä, niin malli selvästikin ymmärsi hyvin suomen kieltä, vaikka virallisesti se ei suomea tuekaan. Esimerkiksi virhekuvaus “Taka kuspoika ruikkii sinne tänne.” meni oikein edellä kuvattuun “Windshield Washer” luokkaan.

Käyttämällä edellä esiteltyä syötettä, sekä historian “väärennystekniikkaa”, mallin vastausformaatti saatiin virheettömäksi. Mallin toimintaa testattiin useaan tuhanteen uniikkiin virhekuvaukseen, ja joka kerta malli vastasi pelkästään käyttäen luokan nimeä, eikä missään vaiheessa hallusinoinut uusia luokkia, joita ei ollut määritelty syötteessä.

Vaikka tässä selvityksessä käytetty Llama 3.1 70B kielimalli on avoin, ja kaikkien ladattavissa, sen ajaminen omalla työkoneella sen täydessä potentiaalissa ei ole kuitenkaan vielä tänä päivänä realistista. Malli vaatii paljon laskentatehoa toimiakseen ja se toimii vain nykypäivän palvelinlaskenta-alustoilla.

Kyseisestä mallista on saatavilla myös pienempi versio, Llama 3.1 8B (Meta, 2024), jonka ajamiseen riittää jo nykypäivän tehokkaimmat pelitietokoneet. Myös tätä pienempää mallia testattiin tässä tutkimuksessa, mutta sen luokittelutulokset jäivät selvästi isompaa mallia huonommiksi.

Mallista on saatavissa myös suurempi versio, Llama 3.1 405B (Meta, 2024), mutta kyseisen mallin ajamiseen vaaditaan jo niin paljon laskentaresurssia, että sitä ei pysty ajamaan Jamkin omassa laskentaympäristössä. Sen vuoksi mallia ei pystytty testaamaan tässä tutkimuksessa.

VauhtiData – Datasta vauhtia valmistavan teollisuuden liiketoimintaan

VauhtiData-hankkeessa pilotoidaan dataan perustuvia toimintamalleja, tukien valmistavan teollisuuden vihreää siirtymää. Osana hanketta kasvatetaan alalla toimivien tietämystä data-analytiikasta ja taitoa hyödyntää data-analyysimenetelmiä, mahdollistaen uusien tuotteiden ja palvelujen innovoinnin teollisuuden käyttöön. VauhtiData on Euroopan unionin osarahoittama hanke.

Lue lisää hankkeesta Avautuu uuteen välilehteen
Logo - Euroopan unionin osarahoittama