Mitä AI-agentin regressiotestaus tarkoittaa?
AI-agentin regressiotestaus tarkoittaa tallennetun testijoukon ajamista uudelleen mallin, promptin, työnkulun, työkalun tai tietopohjan muutoksen jälkeen. Tavoite ei ole todistaa agentin yleistä älykkyyttä, vaan havaita hyväksytyn liiketoimintatuloksen heikkeneminen. Asiakaspalvelussa regressio voi olla vääräksi muuttunut palautussääntö, puuttuva pakollinen siirto ihmiselle tai tilanne, jossa englanninkielinen vastaus pysyy oikeana mutta suomenkielinen muuttuu.
Miksi tavallinen ohjelmistotestaus ei yksin riitä?
Perinteinen testi vertaa usein determinististä tulosta odotettuun arvoon. LLM- ja agenttivastaukset voivat vaihdella ja olla silti hyväksyttäviä. Siksi kannattaa erottaa täsmälliset säännöt semanttisesta toleranssista. Tarkista hinnat, tilat, siirtotapahtumat ja kielletyt luovutukset deterministisesti. Käytä rubriikkia silloin, kun useampi sanamuoto on hyväksyttävä, ja jätä rajatapaukset tarkistettaviksi.
Käytännön regressiotestausprosessi
Hyvä prosessi sisältää kuusi vaihetta: 1) tallenna asiakkaan hyväksymät testit odotettuine lopputuloksineen, kiellettyine toimintoineen ja siirtosääntöineen; 2) tallenna benchmarkin sekä politiikan tai tietopohjan versio; 3) aja tapaukset riittävän monta kertaa satunnaisten epäonnistumisten löytämiseksi; 4) pisteytä onnistuminen, perusteettomat väitteet ja siirtokäyttäytyminen; 5) vertaa nykyistä ajoa tallennettuun perustasoon; 6) hälytä vain olennaisesta heikkenemisestä ja säilytä evidenssi.
Mikä muutos käynnistää uusinta-ajon?
Tyypillisiä triggereitä ovat mallipäivitys, promptimuutos, RAG- tai tietopohjapäivitys, työkalun integraatiomuutos, työnkulun muutos, uusi tuotekäytäntö, uuden kielen käyttöönotto ja toimittajan vaihto. Arvokkaat tapaukset voidaan ajaa myös viikoittain tai öisin, jotta hiljainen drift havaitaan.
Mitä benchmarkiin kuuluu?
Benchmarkin pitäisi kuulua liiketoimintavaatimukselle, ei yksittäiselle mallille. Tallenna vähintään asiakasintentio tai prompt, odotettu lopputulos, sallittu toleranssi, kielletty toiminta, siirtosääntö, vakavuus, lähteen omistaja ja voimaantulopäivä. Näin sama testi voidaan siirtää mallin tai toimittajan vaihtuessa.
Esimerkki: palautussäännön regressio
Jos hyväksytty normaali palautusaika on 14 päivää, testitapaus voi kysyä voiko 20 päivää sitten vastaanotetun fyysisen tuotteen palauttaa normaalilla palautusoikeudella. Odotettu vastaus on ei. Jos tietopohjapäivityksen jälkeen agentti alkaa vastata “kyllä, palautusoikeus on 30 päivää”, järjestelmän pitää kirjata tehtävävirhe ja olennainen politiikkavirhe sekä osoittaa muutos suhteessa hyväksyttyyn perustasoon.
CI vai tuotannon aikainen testaus?
Molemmille on paikkansa. Julkaisua edeltävä eval voi estää huonon muutoksen ennen tuotantoa. Ajastettu black-box- tai tuotantoa lähellä oleva testi voi havaita toimittajan mallipäivityksen, haun muutoksen tai muun ulkoisen driftin. Sopiva malli riippuu käyttöoikeuksista ja agentin toteutuksesta.
Omista benchmark. Ulkoista toistuva ajo.
Useworthy voi ajaa asiakkaan hyväksymää benchmarkia toistuvasti ja tallentaa vertailukelpoisen historian.
Keskustele testauksesta