LLM-evaluointiharnessi: miksi AI-tuote tarvitsee sellaisen ja miten rakentaa

Mistä puhutaan

Eval harnessi (lyhyemmin evals) on automatisoitu järjestelmä, joka mittaa LLM-pohjaisen ominaisuuden vastausten laatua kuratoituja testitapauksia vasten. Toimii samalla logiikalla kuin yksikkötestit tavallisessa koodissa: ennen mergea pipeline ajaa testit, ja jos laatu putoaa hyväksytyltä tasolta, muutos pysähtyy. Erona se, että "oikea vastaus" on harvoin yksiselitteinen — kahta eri sanavalintaa voi pitää yhtä hyvänä, ja siksi pelkkä string-vertailu ei riitä.

Olen rakentanut tämän mallin kahdessa projektissa: avoimessa Devometric-alustassa (RAG-pohjainen AI-kyvykkyysarviointi engineering-tiimeille) ja Willitin tuotteen sisäisissä tarkistuksissa. Alla on käytännön rakenne, ei akateeminen.

Miksi tarvitset tämän

Kolme tyypillistä tilannetta, joissa eval harnessin puuttuminen kostautuu:

1. Mallin päivitys. Anthropic julkaisee uuden Claude-version. Vaihto tuottaa keskimäärin parempia vastauksia, mutta yksittäisiin reunatapauksiin uusi malli vastaa eri tavalla. Ilman evalseja huomaat tämän käyttäjien kautta.
2. Prompt-muutos. Lisäät yhden lauseen system-promptiin parantaaksesi yhtä käyttötapausta. Toinen, näennäisesti irrallinen tapaus alkaa hallusinoida. Yksikkötesti ei huomaa, sillä koodi ei muuttunut.
3. RAG-indeksin uudelleenrakennus. Vaihdat embedding-mallin tai chunkaa dokumentit eri tavalla. Hakutulokset näyttävät edelleen järkeviltä — mutta jokin spesifinen kysymyksenkohta löytää nyt väärän kappaleen. Tämä on suorastaan klassinen.

Yhteistä näille on, että regressio on hiljainen. Tukipyyntöjen kasvua tai NPS-laskua mittaava asiakaspalvelu havaitsee ongelman 1–4 viikkoa myöhässä. Eval harness havaitsee saman 30 sekunnissa.

Arkkitehtuurin neljä osaa

Toimiva eval harness koostuu neljästä osasta. Pidä rakenne yksinkertaisena — monimutkaisuus on tämän työkalun pahin vihollinen, koska sitten kukaan ei lisää uusia testitapauksia.

1. Golden dataset

Kuratoitu kokoelma (syöte, odotettu lopputulos)-pareja. Aloita 10–30 tapauksesta jotka kattavat tuotteen ydinpolut + 3–5 reunatapausta jotka olet jo nähnyt rikkoutuvan tuotannossa. Älä yritä rakentaa 1000-tapauksen "kattavaa" testisettiä — se on vuoden projekti josta ei ikinä tule valmista.

Tallenna golden dataset versioidussa muodossa (YAML, JSONL, tai oma tietokantataulu). Devometricissa käytin Rails-fixtureja ja sähköpostilistalla saatuja oikeita asiakaskysymyksiä, anonymisoituina. Reaaliset käyttäjäkysymykset ovat aina parempi lähde kuin tekoavoimet edge case -listat.

2. Promptit ja agentit testin alla

Sama koodipolku jota tuotanto ajaa. Ei mock-versio — siinä piilee koko pointti. Jos tuotantopolku on liian raskas testissä (tietokanta, ulkoiset API-kutsut), eristä RAG-haku ja vektorit testifixtureiksi mutta säilytä todellinen LLM-kutsu Anthropic API:in. Mallin käyttäytymisen testaus mock-mallia vasten on hyödytöntä.

Käytännössä tämä tarkoittaa, että evals-ajot kuluttavat oikeaa API-budjettia. Devometricissa rajaan ajot 30–50 testitapaukseen kerralla, kustannus on n. €0,50–€2 per ajo Claude Sonnetilla. CI:ssä ajetaan jokaista PR:ää vasten + päivittäin schedulella main-haaraa vasten.

3. Judges (tuomarit)

Jokaiselle testitapaukselle tarvitaan tapa ratkaista, oliko vastaus hyväksyttävä. Kolme tasoa, joita yhdistän:

• Deterministiset tarkistukset — suorat regex- tai sisältötarkistukset. "Vastauksen pitää sisältää sana 'kyllä'", "vastaus saa olla korkeintaan 200 merkkiä", "vastaus ei saa sisältää sähköpostiosoitteita". Halpoja, nopeita, yksiselitteisiä.
• LLM-as-judge — toinen malli arvioi, vastaako tuotos odotusta. Itse käytän Claude Sonnetia tuomariksi, vaikka itse tuote pyörisi Haikulla. Tuomariprompti pitää testata erikseen — kalibroi se 5–10 manuaalisesti scoratun esimerkin kanssa ennen kuin luotat siihen.
• Ihmisreviewi — joitain tapauksia ei voi automatisoida. Ne menevät erilliseen jonoon johon palaan kerran viikossa. Yleensä 5–10 % tapauksista. Tärkeämpiä kuin niiden määrä antaa olettaa.

4. Raportointi ja CI-integraatio

Yksinkertaisin riittää: ajon lopussa printataan passed / failed / changed per testitapaus, rikkoutuneet näytetään diffinä (odotettu vs. saatu vastaus). CI-pipeline asettaa raja-arvon — esim. "vähintään 90 % deterministisistä passattava, vähintään 80 % LLM-judge-pisteistä per tapaus".

Tärkein huomio: raja-arvon pitää olla matalampi kuin nykyinen tulos. Jos ajat ensimmäisen kerran ja saat 92 %, älä aseta rajaa 92 %:iin — aseta 85 %:iin. Liian tiukka raja johtaa siihen että pipeline on aina punainen flaky-syistä, ja kehittäjät oppivat ohittamaan sen. Sama logiikka kuin coverage-rajojen asettamisessa.

Kolme kompastuskiveä joista voi oppia ilman, että kaatuu itse

1. Älä ulkoista golden datasetin keruuta. Olen yrittänyt — kysyin tukitiimiltä "lähetä mulle muutama kysymys". Se ei toimi. Datasetti pitää kerätä joko itse tai kanssa-kehittäjien kanssa, koska sen kuratointi on osaltaan tuotespeksin viimeistelyä.
2. LLM-as-judge ei ole "ilmaista". Tuomarimallin promptin testaus vie helposti puoli päivää ennen kuin luotat siihen. Sen jälkeen kalibroitu tuomari on luotettavampi kuin moni junior-arvioija. Mutta älä luota siihen sokeasti — käy kerran kuussa läpi 10 satunnaista pass-tapausta ja katso, oliko tuomari oikeassa.
3. Eval harnessi muuttuu osaksi tuotetta. Devometricissa golden dataset on käytännössä tuotteen elävin spesifikaatio — kun lisään uuden ominaisuuden, kirjoitan ensin testitapaukset ja vasta sitten promptin. Tämä on käytännössä TDD AI-tuotteille.

Mistä aloittaa, jos sinulla ei ole tätä vielä

Käytännön ensimmäiset askeleet, viikon jänteellä:

1. Päivä 1. Kerää 10 testitapausta tuotteen ydinpolulta — todellisia, ei keksittyjä. Tallenna YAML-tiedostoon.
2. Päivä 2. Kirjoita yksinkertainen ajuriskripti joka iteroi tapaukset, kutsuu tuotantokoodia ja tulostaa diffin.
3. Päivä 3. Lisää 3 deterministista tarkistusta per tapaus (sisältää X, ei sisällä Y, pituus < Z).
4. Päivä 4. Lisää LLM-judge-prompti yhdelle tapausluokalle. Kalibroi 5 esimerkin kanssa.
5. Päivä 5. Wraparoo CI:hin GitHub Actionsilla. Aseta matala raja-arvo. Anna ajaa.

Viidessä päivässä sinulla on toimiva harness. Se ei ole "lopullinen", eikä tarvitse olla — sen tarkoitus on alkaa tuottaa hyötyä päivästä yksi ja kasvaa orgaanisesti. Sama kuin yksikkötestit: paras testikatto on se joka oikeasti olemassa.

Lopuksi

AI-tuotteen rakentaminen ilman eval harnessia on kuin ohjelmoinnin tekeminen ilman versionhallintaa — toimii pieneen pisteeseen asti, ja sen jälkeen jokainen muutos on velkaa. Hyvä uutinen: ensimmäisen version saa pystyyn viikossa, ja se maksaa itsensä takaisin ensimmäisen estetyn regression kohdalla.

Jos haluat keskustella tästä konkreettisesti omassa projektissasi, Claude Code Team Sprint sisältää eval harnessin rakentamisen kahden viikon kiinteähintaisena toimituksena. Tai laita sähköpostia jos kysymyksiä — vastaan saman päivän aikana arkisin.