Näemme jatkuvasti saman mallin. Tiimi rakentaa tekoälytyönkulun sisällön luonnosteluun, asiakastukipyyntöjen luokitteluun, myyntisähköpostien tuottamiseen tai muuhun tehtävään. Se toimii hyvin viikolla 1. Tiimi ilahtuu ja ottaa sen käyttöön.
Kolme kuukautta myöhemmin jokin tuntuu olevan vialla. Tulosten laatu näyttää heikentyneen, asiakkaat valittavat ja työntekijät lakkaavat käyttämästä työnkulkua. Kukaan ei tiedä, milloin tai miksi muutos tapahtui.
Syy on lähes aina sama: kukaan ei mitannut. Viikolla 1 toiminut työnkulku on voinut heikentyä vähitellen, taustamalli on voinut muuttua, kehotteet ovat voineet ajautua tai syötteiden jakauma on voinut vaihtua. Ilman mittaamista ongelma huomataan vasta käyttäjien valittaessa, jolloin luottamus on jo kärsinyt.
Ratkaisu on eval-arviointi eli tekoälytulosten laadun järjestelmällinen mittaus. Sitä pidetään yleensä insinöörien asiana, mutta jokainen tekoälytyönkulkuja käyttävä tiimi tarvitsee sitä. Perusteet onnistuvat ilman koodia.
Tämä artikkeli kertoo, mitä eval-arvioinnit ovat, miksi niitä tarvitaan ja miten ne otetaan käyttöön missä tahansa tekoälytyönkulussa ilman insinööritaustaa.
Eval-arvioinnit eivät ole raportointiteatteria. Hyödyllinen arviointi johtaa päätökseen: julkaise, pidätä, palauta tai tutki. Jos pistemäärä ei voi muuttaa tiimin toimintaa, yksinkertaista arviointia, kunnes se voi.
Mitä eval-arvioinnit ovat (ja eivät ole)
Eval-arviointi mittaa tekoälyn tuloksen laatua järjestelmällisesti hallitsemiesi esimerkkien perusteella.
Osat:
- Tietoaineisto. Joukko syötteitä eli tekoälyn käsittelemiä asioita.
- Odotettu toiminta. Mitä tekoälyn halutaan tekevän syötteillä.
- Pisteytystapa. Miten oikea toiminta mitataan.
- Ajo/raportti. Käsittele aineisto, pisteytä jokainen tulos ja tee yhteenveto.
Tavoite on kysyä toistettavasti: ”tekeekö tekoäly haluamani asian odottamallani laatutasolla?” ja havaita vastauksen muuttuminen.
Eval-arvioinnit eivät ole:
- Kertaluonteista testausta rakentamisen aikana.
- Pistokokeita vasta ongelman ilmaannuttua.
- Käyttäjäpalautetta, joka on hyödyllistä mutta reaktiivista, hidasta ja vinoutunutta.
- Mututuntumaa siitä, että tulos vaikuttaa oikealta.
Todelliset arvioinnit suoritetaan aikataulutetusti määritellyllä syötejoukolla ja yhdenmukaisella pisteytyksellä. Ne antavat signaalin ilman valituksiakin.
Miksi insinöörityökalut ovat useimmille tiimeille vääriä
Kun haet ”LLM evals”, löydät Promptfoon, LangSmithin, Braintrustin ja Heliconen kaltaisia työkaluja. Ne ovat erinomaisia mutta suunniteltu insinööreille, jotka julkaisevat laajoja LLM-tuotteita.
Markkinoinnin, myynnin, operaatioiden ja tuen työnkulkuja käyttäville tiimeille ne ovat usein ylimitoitettuja. Tarvitset yksinkertaisemman tavan mitata omaa työnkulkuasi ilman uuden työkalupinon opiskelua.
Taulukkolaskenta ja LLM riittävät. Tulos ei ole LangSmithin tasoinen, mutta havaitsee useimmat laatuongelmat.
Neljä eval-arvioinnin mallia
Neljä yleistä mallia sopivat erityyppisiin työnkulkuihin.
Malli 1: täsmällinen vastaavuus
Käytä, kun oikeita vastauksia on yksi.
Esimerkkityönkulku: asiakastukipyyntöjen luokittelu 8 luokkaan.
Tietoaineisto: 50 tukipyyntöä oikeine luokkineen. Pisteytys: tekoälyn vastaus joko vastaa oikeaa luokkaa (1 piste) tai ei (0 pistettä). Tulos: oikein olevien osuus prosentteina.
Sopii luokitteluun, poimintaan ja yksinkertaisiin rakenteisiin tulosteisiin.
Malli 2: vertailu referenssiin
Käytä, kun vertailuun on tunnettu hyvä vastaus.
Esimerkkityönkulku: tuotekuvausten luonnostelu.
Tietoaineisto: 30 tuotetta ja itse kirjoittamasi referenssikuvaukset. Pisteytys: kuinka lähellä tekoälyn kuvaus on referenssiä esimerkiksi tarkkuudessa, äänensävyssä ja kattavuudessa?
Voit pisteyttää käsin asteikolla 1-5 tai käyttää seuraavan mallin LLM-arvioijaa. Referenssivertailu on sisältötyönkulkujen kultainen standardi.
Malli 3: LLM arvioijana
Käytä, kun hyväksyttäviä tulosmuotoja on monta mutta laatua voidaan arvioida.
Esimerkkityönkulku: personoitujen myyntisähköpostien tuottaminen.
Tietoaineisto: 30 potentiaalisen asiakkaan profiilia. Pisteytys: LLM toimii arvioijana ja pisteyttää syötteen ja tuloksen täsmällisyyden, ammattimaisuuden, pituuden ja äänensävyn.
LLM-arvioija on tehokas mutta vaatii huolellisen kehotteen. Yleinen malli:
You are evaluating a sales email for quality. Score it on these dimensions:
1. Specificity (1-5): Does it reference specific facts about the prospect, not generic flattery?
2. Professionalism (1-5): Does it sound like a peer rather than spam?
3. Length appropriateness (1-5): Is it concise (40-80 words)?
4. Voice match (1-5): Does it match our voice (direct, no buzzwords)?
For each dimension, give the score and a one-sentence reason.
Output JSON: {"specificity": {"score": N, "reason": "..."}, ...}
Prospect profile: [input]
Email to evaluate: [output]
Arvioiva LLM tarjoaa yhdenmukaisuutta, kun samaa mallia ja kehotetta käytetään kaikkialla. Tarkistamaton arvioija on kuitenkin vain tuntemattoman laatuinen toinen mielipide, joten kalibroi se kerran kunnolla:
- Ota 50 tiimisi jo merkitsemää esimerkkiä hyväksy/hylkää-merkinnöillä tai pisteasteikollasi. Käytä oikeita tarkistusjonon tapauksia, älä keksi synteettisiä.
- Aja arvioija samoille 50 tapaukselle ja laske yhtäpitävyys. Kun tulos on suunnilleen yli 85%, luota rutiiniseulontaan ja jätä ihmisille otos. Välillä ~70% ja 85%, lue jokainen erimielisyys; syy on yleensä epämääräinen arviointikriteeri, joten täsmennä ja suorita uudelleen. Alle ~70%, arvioija mittaa eri asiaa kuin tiimisi, eikä sitä pidä automatisoida.
- Tarkastele virheiden suuntaa, älä vain määrää. Huonoja tuloksia hyväksyvä arvioija on vaarallinen; hyviä hylkäävä on vain ärsyttävä. Aseta kynnys tämän mukaan.
- Kalibroi uudelleen 20-30 tuoreella esimerkillä aina, kun vaihdat arvioijamallia, kehotetta tai arviointikriteeriä, sillä mikä tahansa niistä muuttaa yhtäpitävyyttä huomaamatta.
Nämä vaihteluvälit ovat suositeltu aloitusmenettelymme, eivät luonnonlakeja. Kalibrointi ennen pisteiden käyttöä päätösporttina on ehdoton.
Malli 4: ominaisuustarkistus
Käytä, kun ”hyvä” voidaan ilmaista täsmällisinä testattavina ominaisuuksina.
Esimerkkityönkulku: verkkokaupan tuoteotsikoiden tuottaminen.
Tietoaineisto: 50 tuotetta. Jokaisesta tuloksesta tarkistetaan:
- Pituus on 30-70 merkkiä.
- Sisältää tuotemerkin.
- Sisältää vähintään yhden tuotteen keskeisen ominaisuuden.
- Ei käytä kiellettyjä markkinointisanoja (”amazing”, ”best”, ”revolutionary”).
Kukin ominaisuus on kyllä/ei-testi. Pisteet = kaikkien tulosten läpäisseiden ominaisuuksien prosenttiosuus.
Ominaisuustarkistukset sopivat aina voimassa oleviin rakenteisiin rajoitteisiin. Ne toimivat nopeasti ja havaitsevat täsmällisen ajautumisen.
Ensimmäisen eval-arvioinnin rakentaminen
Käytännöllinen kokoonpano muille kuin kehittäjille:
Vaihe 1: valitse työnkulku
Valitse yksi työnkulku, älä arvioi kaikkea kerralla. Valitse se, jonka laadusta olet eniten huolissasi tai jolla on suurimmat seuraukset.
Esimerkki: tekoäly luokittelee saapuvat asiakastukipyynnöt aiheen mukaan.
Vaihe 2: rakenna tietoaineisto
Luo 20-50 edustavaa esimerkkiä. Sisällytä:
- Helpot tapaukset, jotka kuuluvat selvästi luokkaan A.
- Vaikeat tapaukset, jotka voivat olla A tai B.
- Rajatapaukset, jotka eivät sovi siististi mihinkään.
- Yleiset vaihtelut eli saman tarkoituksen eri ilmaisut.
Tallenna taulukkoon tai Google Sheetiin:
| ID | Syöte | Odotettu tulos |
|---|---|---|
| 1 | ”My password isn’t working" | "account-access” |
| 2 | ”I want to cancel my subscription" | "billing” |
| 3 | ”Your latest update broke my workflow" | "bug” |
| … | … | … |
Tämä on arviointiaineistosi. Sen ei pidä muuttua usein, sillä tarkoitus on toimia vakaana referenssinä.
Vaihe 3: määritä pisteytys
Mikä on oikea vastaus kussakin esimerkissä? Ole täsmällinen.
Luokittelussa: luokan täsmällinen vastaavuus. Sisällössä: pisteet 1-5 kullakin 2-4 nimetystä ulottuvuudesta. Poiminnassa: jokainen kenttä oikein/väärin.
Kirjoita arviointikriteerit muistiin ja noudata niitä.
Vaihe 4: suorita työnkulku aineistolla
Suorita tekoälytyönkulku jokaiselle esimerkille ja tallenna tulos uuteen sarakkeeseen.
Luokittelun voi tehdä taulukossa Google Sheetsin GPT-integraatiolla tai kopioimalla käsin.
Monimutkaisemmat työnkulut voi ajaa Promptfoolla tai kerran viikossa eräajona.
| ID | Syöte | Odotettu | Todellinen |
|---|---|---|---|
| 1 | … | “account-access" | "account-access” |
| 2 | … | “billing" | "billing” |
| 3 | … | “bug" | "feature-request” |
| … | … | … | … |
Vaihe 5: pisteytä
Täsmällisessä vastaavuudessa lisää ”match”-sarake ja anna arvo 1 silloin, kun odotettu = todellinen; muussa tapauksessa anna arvo 0 ennen summan laskemista. Summa on tarkkuus.
LLM-arvioinnissa suorita arviointikehote jokaiselle tulokselle ja tallenna pisteet.
Ominaisuustarkistuksessa suorita kukin ominaisuus erillisenä testinä ja yhdistä tulokset.
Pienin käyttökelpoinen tuloskortti
Ensimmäisessä arvioinnissa seuraa vähemmän ulottuvuuksia mutta tee jokaisesta toimintaa ohjaava.
| Ulottuvuus | Kysymys | Läpäisykynnys | Toiminto kynnyksen alittuessa |
|---|---|---|---|
| Oikeellisuus | Tuottiko työnkulku oikean vastauksen tai luokituksen? | 90% | Tarkista virheet ennen julkaisua |
| Turvallisuus | Välttikö se kielletyn sisällön, perusteettomat väitteet ja riskialttiit toimet? | 100% | Estä julkaisu |
| Muoto | Palauttiko se odotetun rakenteen? | 95% | Korjaa kehote tai skeema ennen julkaisua |
| Hyödyllisyys | Hyväksyisikö käyttäjä tuloksen kohtuudella? | 4/5 average | Muokkaa esimerkkejä tai ohjeita |
| Regressio | Pysyivätkö tunnetut aiemmat virheet korjattuina? | 100% | Estä julkaisu |
Tuloskortissa pitää nimetä omistaja ja julkaisusääntö. ”Alle 90% oikeellisuus vaatii tuoteomistajan tarkistuksen” on vahvempi kuin ”seuraa oikeellisuutta”.
Vaihe 6: tee yhteenveto
Yhteenvetotaulukko:
| Eval Date | Score | Notes |
|---|---|---|
| 2026-05-01 | 47/50 (94%) | Baseline. 3 errors: tickets 8, 23, 41. |
| 2026-05-08 | 46/50 (92%) | Stable. 4 errors. |
| 2026-05-15 | 44/50 (88%) | Dropped. New errors on tickets 12, 35. |
Ajan myötä näet laatukehityksen. Pudotus käynnistää tutkimuksen.
Vaihe 7: aikatauluta
Suorita arviointi säännöllisesti. Useimmille työnkuluille viikoittainen ajo riittää. Suorita se myös ennen käyttöönottoa jokaisen kehote- tai mallimuutoksen jälkeen.
Tämä on 30-minute viikkotapa. Lisää toistuva kalenterivaraus, äläkä jätä sitä väliin.
Artikkeliin liitetty tuloskortti on suunniteltu ensimmäiseen viikkoajoon.
Lisää julkaisuportti
Eval-arvioinneilla on eniten arvoa muutoksen edessä. Käytä asiakkaisiin, operatiivisiin tietoihin tai tiimin päätöksiin vaikuttavissa työnkuluissa pientä julkaisuporttia:
- Lähtötaso. Nykyisellä tuotantotyönkululla on kirjattu pistemäärä.
- Ehdokas. Uusi kehote, malli, työkalu tai työnkulkuvaihe ajetaan samalla aineistolla.
- Vertailu. Ehdokkaan pitää säilyttää turvallisuus- ja regressiopisteet eikä se saa heikentää ensisijaista laatupistettä sovittua toleranssia enempää.
- Päätös. Julkaise, pidätä, muokkaa tai palauta. Kirjaa syy.
- Julkaisun jälkitarkistus. Suorita uudelleen pienellä oikeiden tapausten otoksella julkaisun jälkeen.
Tätä ei tarvitse automatisoida ensimmäisenä päivänä. Taulukko ja nimetty hyväksyjä riittävät, jos ne estävät mittaamattomien muutosten julkaisemisen johdonmukaisesti.
Mitä tehdä pisteiden laskiessa
Eval-arviointien tarkoitus on havaita laadun heikkeneminen. Kun niin käy, tutki.
Yksinkertainen tutkimus:
Vaihe 1: Tunnista epäonnistuneet tapaukset. Mikä meni täsmällisesti väärin?
Vaihe 2: Etsi malleja. Ryhmittyvätkö virheet samankaltaisiin syötteisiin vai ovatko ne hajallaan?
Vaihe 3: Tee diagnoosi.
- Ryhmittynyt → todennäköisesti täsmällinen heikkous, kuten kehoteongelma tai puuttuva tieto.
- Hajallaan → todennäköisesti yleinen laadun lasku, kuten mallimuutos tai ajautuminen.
Vaihe 4: Muodosta syyhypoteesi.
- Muuttuiko taustamalli? Tarkista palveluntarjoajan muutosloki.
- Muuttuiko kehote? Palauta ja testaa.
- Muuttuiko syötejakauma? Tarkastele tuoretta todellista dataa.
- Vanhentuiko tietoaineisto? Päivitä esimerkit.
Vaihe 5: Testaa korjaus. Tee yksi muutos ja suorita arviointi uudelleen. Palautuiko tulos?
Järjestelmällinen lähestymistapa voittaa paniikin ja arvailun.
Tietoaineiston kehittäminen ajan myötä
Alkuperäinen aineisto on lähtökohta. Paranna sitä:
Lisää todellisia virhetapauksia. Kun todellinen käyttäjätapaus tuottaa huonon tuloksen, lisää se aineistoon regressiotestiksi.
Karsi vanhentuneet tapaukset. Poista työnkulun kehittyessä merkityksettömät testit.
Laajenna kattavuutta. Jos aineistossa on 20 ”account-access”-tukipyyntöä ja 1 ”billing”-pyyntö, painotus on väärä. Tasapainota.
Lisää rajatapauksia löytymisen mukaan. Uudet valitusmallit, tuoteominaisuudet ja luokat.
Hyvä arviointiaineisto elää ja vastaa nykyistä, ei historiallista todellisuutta.
Yleiset virheet
Eval-ohjelmia rikkovia malleja:
Virhe 1: Täydellisen arvioinnin rakentaminen ennen aloittamista. 50 esimerkin monimutkainen aineisto pelottaa. 10 esimerkin yksinkertainen aineisto onnistuu tänään. Aloita pienesti.
Virhe 2: Vain helppojen tapausten arviointi. Sisällytä vaikeat, raja- ja aiemmin epäonnistuneet tapaukset.
Virhe 3: Arviointiaineiston ajautuminen. Aineiston muuttaminen jokaisen työnkulkumuutoksen yhteydessä tekee pistemäärästä merkityksettömän. Aineiston pitäisi muuttua harvoin.
Virhe 4: LLM-arvioijaan sokea luottaminen. LLM-arvioijat painottavat pintapiirteitä, kuten pituutta ja muotoa. Kalibroi säännöllisesti ihmisen arvioihin. Erimielisyys kertoo kehoteongelmasta.
Virhe 5: Pisteytys ilman toimintaa. Viikoittainen arviointi ilman datan perusteella toimimista on teatteria. Pudotuksen pitää käynnistää tutkimus.
Virhe 6: Vain yhden ulottuvuuden arviointi. 95% tarkkuus ei kerro laadun, vasteajan tai hallusinaatioasteen muutoksista. Seuraa olennaisia ulottuvuuksia.
Hyödylliset mutta vapaaehtoiset työkalut
Kun haluat siirtyä taulukoista eteenpäin:
Promptfoo. Avoimen lähdekoodin, YAMLilla määritettävä ja kannettavassa tai CI:ssä ajettava. Erinomainen kehotteiden testaukseen ja vertailuun.
Braintrust. Isännöity arviointialusta hyvällä käyttöliittymällä. Kalliimpi mutta tehokas.
LangSmith. Sidottu LangChain-työnkulkuihin; hyvä kyseisessä ekosysteemissä.
Helicone. LLM-kutsujen lokitus ja analytiikka arviointiominaisuuksilla.
OpenAI Evals. Avoimen lähdekoodin ja kehittäjäpainotteisempi sovelluskehys.
Useimmille muille kuin kehittäjätiimeille taulukko sekä ChatGPT/Claude riittää. Promptfoo on helpoin oikea työkalu seuraavaan vaiheeseen.
4-week eval-ohjelma
Realistinen suunnitelma nollasta aloittavalle tiimille:
Week 1: Valitse ja määritä.
- Valitse yksi työnkulku.
- Rakenna 20 esimerkin aineisto.
- Määritä pisteytys: täsmällinen vastaavuus, LLM-arvioija tai ominaisuudet.
Week 2: Ensimmäinen lähtötaso.
- Suorita arviointi ja kirjaa lähtötaso.
- Tunnista ilmeiset virheet.
- Älä vielä muuta, vaan havainnoi.
Week 3: Paranna.
- Tee yksi laatua mahdollisesti parantava muutos.
- Suorita arviointi uudelleen.
- Nousiko, laskiko vai säilyikö pistemäärä? Tutki syy.
Week 4: Aikatauluta.
- Aikatauluta viikkoajot.
- Dokumentoi arviointiprosessi.
- Kerro tiimille, mitä pisteet tarkoittavat ja mikä käynnistää toiminnan.
4 weeks kuluttua sinulla on toimiva arviointi. Laajenna sitten muihin työnkulkuihin, syvennä aineistoa ja tarkenna pisteytystä.
Kulttuurimuutos
Eval-arviointi vaatii enemmän kulttuurista kuin teknistä muutosta. ”Näyttää toimivan” -perusteella julkaisevien tiimien pitää hyväksyä mittaus.
Muutos sisältää:
Valmiuden nähdä lukujen laskevan. Innostava muutos voi heikentää laatua. Arviointi kertoo sen, ja sinun pitää olla valmis palauttamaan.
Panostuksen kalibrointiin. Uuden arvioinnin ensimmäisenä kuukautena säädä aineistoa, pisteytystä ja kehotteita. Se on investointi.
Ennen/jälkeen-tavan rakentamisen. Jokainen merkittävä työnkulkumuutos kulkee arvioinnin kautta ennen tuotantoa.
Laatutason puolustamisen. Pisteiden laskiessa korjaa tai palauta. Älä julkaise heikentynyttä laatua määräajan vuoksi.
Kulttuurimuutos on vaikein osa. Sen jälkeen työkalut ovat helppoja.
Yksi työnkulku, kaksikymmentä esimerkkiä ja puoli tuntia viikossa
Eval-arviointi erottaa ajan myötä luotettavat tekoälytyönkulut huomaamatta keskinkertaisiksi ajautuvista.
Aloittaminen ei vaadi insinöörejä, ML-osaamista tai hienoja työkaluja. Tarvitset mitattavan työnkulun, pienen aineiston, pisteytystavan ja viikoittaisen puolituntisen.
Valitse yksi työnkulku tällä viikolla. Rakenna 20-example-arviointi. Suorita se, tarkastele tulosta ja suorita ensi viikolla uudelleen. Huomaa syntyvä kurinalaisuus.
6 months kuluttua arviointeja käyttävillä tiimeillä on aidosti parantuneita työnkulkuja. Muilla työnkulut näyttävät samalta kuin 6 months sitten, mutta toimivat huonommin.



