Evaluoinnit ovat tekoälyominaisuuden määrittely

Kielimallin varaan rakennettu ominaisuus vastaa eri tavalla joka kerta, kun sitä kysytään. Se rikkoo lauseen, johon jokainen vaatimusdokumentti nojaa: ”se toimii”. Tämä artikkeli kertoo, mikä sen korvaa, kuka korvaajan kirjoittaa ja mitä studio oppi määritellessään kahdeksan tekoälyympäristöä yhteen tuotteeseen.

Miksi ”se toimii” ei riitä tekoälyominaisuudelle?

Koska ei ole yhtä ainoaa tulostetta tarkistettavaksi. Deterministinen ominaisuus hyväksytään kerran; malliin perustuva on hyväksyttävä tilastollisesti, merkitsevien tapausten yli, ja hyväksyttävä uudelleen aina, kun prompti tai malli muuttuu. Hamel Husain, tekoälykonsultti, joka on toimittanut tällaisia järjestelmiä vuodesta 2023, kirjoitti 29. maaliskuuta 2024, että epäonnistuneet tekoälytuotteet ”almost always share a common root cause: a failure to create robust evaluation systems”. Epäonnistuvat tiimit pelaavat myyränkolkkausta: yksi vastaus korjataan, toinen menee rikki, eikä koskaan tiedetä, missä mennään.

Mikä evaluointi on tuotetermein?

Kolmiosainen määrittely, kirjoitettu lukijan kielellä ja tuoteroolin omistama.

• Tapaukset, jotka sen on hoidettava: todellisia syötteitä, mieluiten oikeilta käyttäjiltä tai lokeista, kunkin kohdalla se, mitä hyvä vastaus sisältää.
• Tapaukset, joissa sen on kieltäydyttävä: rajauksen ulkopuoliset kysymykset, tiedot, joita se ei koskaan saa paljastaa, toimet, joita se ei koskaan saa väittää tehneensä.
• Toleranssi: kuinka usein se saa epäonnistua kussakin joukossa ennen kuin ominaisuus vedetään pois, ilmaistuna lukuna, jonka joku on allekirjoittanut.

Husain kuvaa kolme testauksen tasoa, jotka vastaavat näitä osia: halvat tarkistukset, jotka ajetaan jokaisessa muutoksessa, lokitettujen ajojen läpikäynti ihmisen ja mallin toimesta, sekä A/B-testit oikeilla käyttäjillä. Kaksi ensimmäistä ovat evaluointi. Määrittely on lista tapauksia ja luku, ja luku on tuotepäätös, koska se vaihtaa laatua toimitukseen.

Kuka sen kirjoittaa?

Se, joka muuten kirjoittaisi hyväksymiskriteerit. Kehittäjä voi kirjoittaa testikehyksen; vain tuoterooli voi sanoa, mitkä kaksikymmentä tapausta merkitsevät, mitkä kieltäytymiset ovat ehdottomia ja minkä epäonnistumisasteen liiketoiminta sietää. Anthropicin 19. joulukuuta 2024 julkaistu ohjeistus agenttien suunnittelusta tekee saman huomion arkkitehtuurin puolelta: etsi ”the simplest solution possible, and only increasing complexity when needed”, ja valitse ennalta määritelty työnkulku itsenäisen agentin sijaan kaikkialla, missä askeleet voidaan tietää etukäteen. Se valinta on määrittelypäätös, ja sen tekee se, joka omistaa tapaukset.

Mitä studio oppi tekemällä sen?

Torn Studiolla oli tuoterooli Changemkrissä, muutosjohtamisen tekoälyalustassa, josta studio omistaa osan, kesäkuuhun 2026 asti. Kesäkuun rajalla yhdellä palvelulla pyöri kahdeksan tekoälyympäristöä, kullakin oma malli, omat työkalut ja oma promptiversiointi yhden klikkauksen palautuksella, laskettavissa promptirekisteristä. Jokainen promptimuutos oli julkaisu, ja jokainen julkaisu hyväksyttiin tapauksiaan vasten.

Kesäkuussa 2026 ulkopuolinen konsulttitoimisto testasi suunnittelijan tekoälyavustajaa ja raportoi sen epäluotettavaksi. Studio muutti raportin 27 numeroiduksi havainnoksi, ryhmitteli ne juurisyyn mukaan ennen kuin koodiin koskettiin, ja totesi, että 4 niistä 27:stä oli tuotepäätöksiä, jotka eivät vaatineet lainkaan koodikorjausta: ominaisuus teki, mitä sille oli sanottu, ja se, mitä sille oli sanottu, oli väärin. Tuo jako, bugi vai päätös, on se, minkä evaluointi tekee näkyväksi ennen kuin testaaja tekee.

Todentaminen on se kohta, jossa rehellinen raja sijaitsee. Korjaukset ajettiin koko pinoa vasten konteissa selaintestein: 11 läpäisi, 1 ohitettiin, ja kolmea suurta generatiivista virtaa ei koskaan todennettu päästä päähän, koska niiden tulosteet vaihtelevat ajojen välillä eikä samaa tulostetta joka kerta odottava testi kanna niitä. Raportti sanoo sen havaintoa kohden, ja se on pointti: todennus, joka raportoi itsensä täysin vihreäksi, on sellainen, johon kukaan ei voi luottaa seuraavalla kerralla.

Missä kohtaa luottamus tulee mukaan?

Evaluointi kattaa oikeellisuuden; kieltäytymistä ja ilmoittamista koskevat tapaukset kattavat luottamuksen, ja ne kuuluvat samaan dokumenttiin. Google PAIRin People + AI Guidebook pyytää tiimejä kalibroimaan luottamuksen — ”tell the user when a lack of data might mean they’ll need to use their own judgment” — ja näyttämään varmuuden luokkina. Euroopan komission tekoälyasetusta käsittelevä sivu sanoo, että chatbottien on tehtävä ihmisille selväksi, että he ovat tekemisissä koneen kanssa, läpinäkyvyyssääntöjen tullessa sovellettaviksi elokuusta 2026, ja linkittää tekstiin. Se, miten ominaisuus ansaitsee tuon luottamuksen, on oma artikkelinsa; evaluointi on paikka, jossa tapaukset kirjataan ensin.

Se, missä malli sijaitsee olemassa olevassa järjestelmässä — rajattu tehtävä tarkistuksen ympäröimänä — kuvataan artikkelissa tekoäly nykyisissä järjestelmissänne. Evaluoinnin tapaukset valitaan samalla tavalla kuin backlog priorisoidaan, ja se menetelmä on artikkelissa mitä rakennetaan seuraavaksi.

Näin studio määrittelee tekoälyominaisuuden

Product Management Torn Studiolla hinnoitellaan toimeksiannoittain hinta kiinteänä ennen työn alkua, ja toimeksiannon piiriin kuuluva tekoälyominaisuus saa evaluointinsa kirjoitettuna ennen promptiaan: tapaukset, kieltäytymiset, toleranssin, sen henkilön allekirjoittamana, joka lukee luvun. Studio rakentaa sitten sitä vasten, jolloin ominaisuus toimitetaan dokumentin kanssa, joka sanoo, mitä se saa tehdä ja missä sen on kieltäydyttävä.