Pelkkä vastauksen saaminen AI-mallilta ei vielä tarkoita, että järjestelmä toimii oikein. Perinteisessä ohjelmistossa voimme usein yksiselitteisesti tarkistaa, palauttiko funktio odotetun tuloksen. AI-järjestelmissä vastaus voi olla sujuva, looginen ja vakuuttava, mutta silti sisältää virheitä.
Siksi AI:n kehittyessä esiin nousee uusi insinöörihaaste: miten mitata järjestelmällisesti järjestelmän laatua, jonka vastaukset eivät aina ole identtisiä?
Tämä on juuri AI evaluation -alue, eli tekoälyjärjestelmien arviointi.
Ja se on paljon laajempi asia kuin vain sen tarkistaminen, vastaako chatbot “hyvin”.
Perinteisen ohjelmiston testaus ja AI:n testaus eivät ole sama asia
Kuvitellaan yksinkertainen funktio sovelluksessa.
Käyttäjä kirjoittaa: 2 + 2
Järjestelmän pitäisi palauttaa: 4
Jos se palauttaa 5, kyseessä on yksiselitteinen virhe.
Voimme tehdä testin: expect(calculate("2 + 2")).toBe(4)
ja saamme joka kerta selkeän tuloksen: testi läpäistään tai ei läpäistä.
AI-järjestelmissä tilanne on toisenlainen.
Käyttäjä voi kysyä: ”Kirjoita lyhyt vastaus asiakkaalle, joka kysyy tilauksen toimitusajasta.”
Järjestelmä voi tuottaa useita erilaisia vastauksia. Kaikki voivat olla kielellisesti oikeita. Kaikki voivat kuulostaa ammattimaisilta. Yksi voi kuitenkin sisältää väärän toimitusajan, toinen voi olla liian pitkä, kolmas voi jättää tärkeän tiedon pois ja neljäs voi olla täydellinen.
Ei siis riitä, että tarkistetaan, onko vastaus teknisesti tuotettu.
On tarkistettava, täyttääkö se tietyt laatukriteerit.
Ensimmäinen ongelma: hyvä vastaus ei aina ole tosi
Tämä on yksi generatiivisen AI:n tunnusomaisimmista piirteistä.
Malli voi tuottaa vastauksen, joka kuulostaa erittäin vakuuttavalta, mutta jolla ei ole katetta lähdedatassa.
RAGia hyödyntävässä järjestelmässä ongelma on vielä kiinnostavampi. Järjestelmä voi saada kysymyksen, hakea muutaman dokumentaation osan ja sitten muodostaa vastauksen.
Silloin pitää tarkistaa ainakin kolme asiaa:
- Löydettiinkö oikeat tiedot? Haimmeko mekanismilla osat, jotka liittyvät todella kysymykseen?
- Hyödyntääkö vastaus löydettyjä tietoja? Onko malli lisännyt jotain, mitä lähteissä ei ollut?
- Vastaako vastaus todella kysymykseen? Hakuvaihe voi toimia oikein, mutta lopullinen vastaus voi silti olla heikko.
Juuri siksi RAGin arviointi erottaa toisistaan muun muassa haetun kontekstin osuvuuden, haun kattavuuden, vastauksen oikeellisuuden ja sen yhdenmukaisuuden lähteiden kanssa.
Tämä on tärkeä muutos ajattelussa testauksesta.
Emme enää testaa vain: kysymys → vastaus
vaan koko ketjua: kysymys → haku → konteksti → malli → vastaus
Voi olla hyvä malli ja huono AI-järjestelmä
Tämä on toinen asia, joka unohtuu helposti.
Yritys voi valita erittäin hyvän kielimallin ja silti rakentaa heikon AI-tuotteen.
Miksi? Koska lopullisen järjestelmän laatu ei riipu vain mallista.
Merkitystä on myös:
- datan laadulla,
- kontekstin valmistelutavalla,
- promptilla,
- tiedonhakutavalla,
- mallin parametreilla,
- AI:lle tarjotuilla työkaluilla,
- sovelluslogiikalla,
- muistilla,
- virheenkäsittelyllä,
- suojauksilla,
- vastausten arviointitavalla.
Tämä tarkoittaa, että kysymys: ”Mikä malli on paras?”
on usein vähemmän hyödyllinen kuin: ”Mikä malli toimii parhaiten juuri meidän käyttötapauksessamme?”
Malli, joka on erinomainen markkinointisisällön tuottamisessa, ei välttämättä ole paras ratkaisu dokumenttien luokitteluun, datan analysointiin tai liiketoimintaprosessien hoitamiseen.
Siksi mallien vertailun pitäisi perustua todellisiin tehtäviin, joita järjestelmän on tarkoitus suorittaa.
Ensin pitää luoda oma testijoukko
AI-järjestelmää ei voi arvioida järkevästi, jos emme tiedä, mitä siltä odotamme.
Siksi yksi arvioinnin tärkeimmistä osista on testidatan valmistelu, eli todellisten tai edustavien tapausten joukko.
Esimerkiksi yritys rakentaa AI:n asiakaspalveluun.
Sen sijaan, että tarkistetaan käsin yksi vastaus jokaisen promptimuutoksen jälkeen, voidaan valmistaa muutama sata tapausta:
- yksinkertaisia kysymyksiä,
- moniselitteisiä kysymyksiä,
- kysymyksiä, joissa on virheellisiä oletuksia,
- kysymyksiä, jotka vaativat asiakirjan hakemista,
- poikkeuksia koskevia kysymyksiä,
- reklamaatioita koskevia kysymyksiä,
- kieltäytymistä vaativia kysymyksiä,
- kysymyksiä, jotka sisältävät tietoja, joita AI:n ei pitäisi paljastaa.
Jokainen järjestelmämuutos voidaan sitten ajaa saman joukon läpi.
Ja juuri tässä AI alkaa muistuttaa perinteistä ohjelmistoa.
Emme enää testaa yksittäistä vastausta. Testaamme järjestelmän käyttäytymistä koko tapausjoukossa.
Myös promptia voi testata
Promptia pidetään usein tekstinä, jonka joku kirjoitti kerran ja jätti tuotantoon.
Todellisuudessa se voi olla osa sovelluslogiikkaa.
Yhden lauseen muuttaminen voi aiheuttaa:
- vastausten paranemisen yhdessä skenaariossa,
- vastausten heikkenemisen toisessa,
- suurempaa taipumusta kieltäytyä,
- enemmän hallusinaatioita,
- pidempiä vastauksia,
- korkeampia kustannuksia,
- suurempaa tokenien kulutusta.
Siksi promptia pitäisi käsitellä samoin kuin koodia.
Jos muutamme promptia, on hyvä tietää:
- mikä parani?
- mikä heikkeni?
- ilmestyikö regressio?
Juuri siksi automaattinen arviointi on yhä tärkeämpää kuin muutaman esimerkkivastauksen manuaalinen arviointi.
AI voi läpäistä testin ja silti olla huono tuote
Oletetaan, että olemme valmistelleet 100 testitapausta.
Järjestelmä vastasi oikein 95:een. Tulos näyttää loistavalta. Mutta entä jos viisi väärää vastausta koskee kriittisiä tilanteita?
Jos chatbot vastaa aukioloaikoja koskeviin kysymyksiin, viisi virhettä voi olla ongelma.
Jos AI auttaa työntekijää analysoimaan talous-, lääketieteellisiä tai oikeudellisia asiakirjoja, näiden virheiden merkitys voi olla aivan toinen.
Siksi pelkkä keskiarvo ei riitä.
Tarvitsemme myös tapausten painotusta.
Voimme olettaa, että:
- tavallisella kysymyksellä on paino 1,
- merkittävällä virheellä on paino 5
- turvallisuusvirheen paino on 10,
- luottamuksellisen tiedon paljastamisen paino on 100.
Silloin järjestelmä ei saa ”95 prosenttia”. Saamme paljon käyttökelpoisemman kuvan riskistä.
Kaikkea ei voi mitata yhdellä luvulla
Tämä on yksi tärkeimmistä AI:n arvioinnin ongelmista.
Voimme käyttää useita mittareita:
- Accuracy - onko vastaus oikea?
- Relevance - vastaako se kysymykseen?
- Faithfulness / groundedness - perustuuko se annettuihin lähteisiin?
- Context precision - ovatko haetut katkelmat osuvia?
- Context recall - löysikö järjestelmä tarvittavat tiedot?
- Safety - toimiiko se ei-toivotulla tavalla?
- Latency - kuinka kauan käyttäjä odottaa?
- Cost - kuinka paljon tehtävän suorittaminen maksaa?
RAG voi siis tuottaa erittäin hyvän vastauksen laadun, mutta samalla hakea valtavan määrän kontekstia ja aiheuttaa ei-hyväksyttävän kustannuksen.
Toinen järjestelmä voi olla hyvin halpa ja nopea, mutta tehdä liikaa virheitä.
Siksi ei ole olemassa yhtä universaalia lukua, joka määrittäisi, onko AI ”hyvä”. Laatu pitää määritellä kyseisen käyttötarkoituksen kontekstissa.
Entä AI:n arvioiminen toisella AI:lla?
Tässä tulee esiin toinen kiinnostava mekanismi.
Yksi tapa automatisoida arviointi on käyttää mallia tuomarina, eli LLM-as-a-judge.
Esimerkiksi:
Malli A tuottaa vastauksen.
Malli B saa kysymyksen, vastauksen ja määritellyt kriteerit.
Sitten se arvioi:
- oikeellisuus,
- ohjeiden mukaisuus,
- täydellisyys,
- tyyli,
- turvallisuus.
Nykyaikaiset arviointityökalut mahdollistavat myös tällaisen arvioinnin yhdistämisen klassisiin tekstivertailuihin, omiin skripteihin tai tiettyihin sääntöihin perustuviin graderiin.
Tämä kasvattaa testauksen mittakaavaa valtavasti. Mutta se ei tarkoita, että ihminen lakkaisi olemasta tarpeellinen. Arvioiva malli voi myös erehtyä. Siksi liiketoiminnallisesti merkittävissä järjestelmissä kannattaa yhdistää automaattiset arvioinnit säännölliseen asiantuntija-arviointiin.
Suurin ongelma: regressio
Kuvitellaan järjestelmä, joka toimii erittäin hyvin. Tiimi vaihtaa mallin uudempaan. Uusi versio on nopeampi ja halvempi. Näyttää siis siltä, että kaikki etenee oikeaan suuntaan.
Käyttöönoton jälkeen kuitenkin käy ilmi, että:
- vastaukset ovat vähemmän tarkkoja,
- malli kieltäytyy vastaamasta useammin,
- se hyödyntää dokumentaatiota huonommin,
- se tulkitsee ohjeita eri tavalla,
- joissakin skenaarioissa se alkaa antaa virheellisiä tietoja.
Tämä on juuri AI-regressio.
Klassisessa ohjelmistossa regressio tunnetaan jo pitkään. Myös AI:ssa meidän täytyy havaita se, mutta ongelma on vaikeampi, koska järjestelmän käyttäytyminen voi muuttua ilman klassista ”bugia”. Siksi jokainen suurempi muutos pitäisi verrata edelliseen versioon.
Malli.
Prompti.
Embedding.
Retriever.
Dokumentaatio.
Agentin logiikka.
Parametrit.
Jokainen näistä osista voi vaikuttaa lopputulokseen.
Agenta ei riitä arvioida vain sen lopullisen vastauksen perusteella
AI-agenteissa asiat muuttuvat vielä vaikeammiksi.
Tavallinen chatbot voi suorittaa yhden tehtävän: kysymys → vastaus.
Agentti voi toimia aivan toisin: tavoite → suunnitelma → työkalu → tulos → seuraava askel → päätös → toiminta → vastaus.
Jos agentti ei saavuttanut tavoitetta, haluamme tietää muutakin kuin vain sen, että se hävisi.
Haluamme tietää: missä se teki virheen?
- Ymmärsikö se tehtävän väärin?
- Valitsiko se väärän työkalun?
- Syöttikö se väärän parametrin?
- Hakiiko se väärän datan?
- Tekikö se huonon päätöksen saatuaan tuloksen?
- Suorittiko se liian monta askelta?
- Pysähtyikö se liian aikaisin?
Agenttien arviointia koskevassa tutkimuksessa analysoidaan yhä useammin juuri ei vain lopputulosta, vaan myös toiminnan kulkua, työkalujen käyttöä, suunnittelua, muistia, luotettavuutta ja turvallisuutta.
Tämä tarkoittaa, että AI-testauksen tulevaisuus liittyy suurelta osin tracejen analysointiin, eli järjestelmän koko suorituksen kulkuun.
AI tarvitsee jotain CI/CD:n kaltaista
Jos AI on osa tuotetta, sitä ei voi testata vain ennen ensimmäistä käyttöönottoa.
Järjestelmä muuttuu.
Malli muuttuu.
Prompti muuttuu.
Tietopohja muuttuu.
Hakutapa muuttuu.
Konfiguraatio muuttuu.
Siksi arvioinnin pitäisi tulla osaksi kehitysprosessia.
Kaava voi näyttää seuraavalta: muutos → testit → arviointi → vertailu aiempaan versioon → päätös käyttöönotosta
Jos uusi versio parantaa laatua yhdessä osa-alueessa, mutta ylittää sovitun virherajan toisessa, käyttöönotto voidaan pysäyttää.
Tämä on hyvin samankaltainen filosofia kuin klassisessa CI/CD:ssä, mutta kriteerit ovat erilaiset.
AI-sovelluksissa voimme tarkastella samanaikaisesti vastauksen laatua, oikeellisuutta, turvallisuutta, kustannusta ja viivettä. On jo olemassa tutkimuksellisia ratkaisuja, jotka yhdistävät arvioinnin observabilityyn ja laatukynnyksiin LLM/RAG-järjestelmien käyttöönottoprosessissa.
Voiko AI:ta siis testata samalla tavalla kuin klassista ohjelmistoa?
Kyllä, mutta vain osittain.
Klassinen lähestymistapa on edelleen tarpeen.
Testaamme:
- API:t,
- integraatiot,
- oikeudet,
- datan validointi,
- virheet,
- aikakatkaisut,
- turvallisuus,
- suorituskyky,
- sovelluksen logiikka.
Mutta siihen emme voi lopettaa.
Mukana on toinen kerros: AI:n käyttäytymisen arviointi.
- Onko vastaus oikea?
- Onko se lähteiden mukainen?
- Pitäytyykö malli ohjeissa?
- Toimiiko järjestelmä oikein odottamattomissa tilanteissa?
- Valitseeko agentti oikeat työkalut?
- Eikö uusi versio heikentänyt laatua?
- Pysyykö toiminnan kustannus hyväksyttävänä?
- Saako käyttäjä todella arvoa?
Tämä ei enää ole klassinen unit-testi.
Paras AI-testi ei aina ole laboratoriotesti
On vielä yksi erittäin tärkeä asia.
Järjestelmä voi suoriutua erinomaisesti valmistellussa testiaineistossa ja silti kohdata ongelmia oikeassa maailmassa. Siksi on hyvä tarkkailla myös todellisia vuorovaikutuksia. Ei siksi, että jokaisesta käyttäjästä tulisi testaaja. Tarkoitus on, että järjestelmää voidaan kehittää jatkuvasti todellisten tapausten perusteella:
- missä käyttäjät korjaavat AI:ta,
- missä he pyytävät vastausta uudelleen,
- missä he keskeyttävät keskustelun,
- missä he eskaloivat asian ihmiselle,
- missä agentti ei saavuta tavoitetta,
- missä ilmenee epätavallisia kysymyksiä.
Näin syntyy jatkuva arviointisilmukka: käyttäjä → AI:n toiminta → tulos → analyysi → uusi testitapaus → järjestelmän seuraava versio
Tämä on aivan erilainen kehitysmalli kuin kertaluonteinen ajatus ”otimme AI:n käyttöön ja se toimii”.
AI:ta ei pitäisi arvioida kysymyksellä ”toimiiko se?”
Se on liian vähän.
Paremmat kysymykset kuulostavat tältä:
- Kuinka usein se toimii oikein?
- Missä tilanteissa se erehtyy?
- Kuinka vakavia nämä virheet ovat?
- Onko uusi versio parempi kuin edellinen?
- Onko järjestelmä riittävän turvallinen?
- Perustuvatko vastaukset oikeaan dataan?
- Paljonko tietyn lopputuloksen saavuttaminen maksaa?
Vasta tällainen kysymysjoukko antaa mahdollisuuden puhua kypsästä AI-järjestelmästä.
Tärkein muutos ajattelussa
Vuosien ajan ohjelmistokehityksessä vallitsi yksinkertainen sääntö: koodin pitäisi toimia.
AI-järjestelmissä sitä täytyy laajentaa: järjestelmän pitäisi toimia hyvin, ennustettavasti ja mitattavasti.
Tämä on valtava ero. Sillä AI ei ole toiminto, joka palauttaa aina saman tuloksen. Se on todennäköisyyspohjainen järjestelmä, jonka käyttäytyminen riippuu mallista, datasta, kontekstista, ohjeista ja koko sen ympärillä olevasta arkkitehtuurista.
Siksi AI:n ammattimainen käyttöönotto ei pääty siihen, kun malli alkaa vastata.
Silloin vasta alkaa kysymys: mistä tiedämme, että voimme luottaa siihen?
Ja juuri tähän kysymykseen hyvin suunnitellun arvioinnin pitäisi vastata.
Tulevaisuudessa AI-järjestelmien testaamisesta tulee todennäköisesti yhtä luonnollinen osa kehitysprosessia kuin yksikkötestit, integraatiotestit tai monitorointi. Ei siksi, että AI olisi ”lähtökohtaisesti vaarallista”. Vaan yksinkertaisesti siksi, että järjestelmä, jonka tulos ei aina ole deterministinen, vaatii erilaisen tavan mitata laatua.
Ja mitä enemmän AI siirtyy tekstin tuottamisesta todellisten prosessien hoitamiseen, datan hyödyntämiseen, RAGiin ja toimien suorittamiseen agenttien kautta, sitä tärkeämmäksi tulee kysymys ei vain ”pystyykö AI tekemään tämän?”, vaan myös: ”voimmeko todistaa, että se tekee sen riittävän hyvin?”
