Tekoäly itse toimii stokastisesti, mutta sen teknisen selkärangan pitää käyttäytyä niin ennustettavasti ja johdonmukaisesti kuin mahdollista. Tämä on laadunvarmistuksen ensimmäinen ja perustavin vaihe: kalleimpien ja helpoimmin vältettävien virheiden estäminen.
Kutsumme tätä nimellä System Robustness eli järjestelmän toimintavarmuus.

1. Tekninen perusta

Laadunvarmistukselle oleellisen tärkeää on, että data liikkuu oikein. Varmistamme, että API-kutsut, tunnistautuminen ja yhteydet ovat kunnossa, että integraatiot toimivat tarkoitetulla tavalla, että data kulkee oikeassa muodossa oikeaan kohteeseen ja että käyttöoikeuksien hallinta estää luvattoman käytön.

LLM-pohjaisissa järjestelmissä tämä tarkoittaa myös sitä, että palveluntarjoajan häiriöt käsitellään hallitusti. LLM-rajapinnat tuovat mukanaan vikatilanteita, jotka pitää käsitellä erikseen. Kutsurajat, aikakatkaisut, osittaiset vastaukset ja palveluntarjoajan omat häiriöt ovat yleisiä. Pipelinessä pitää olla uudelleenyritykset, katkaisijat (circuit breakers) ja varastrategiat.

• Eksponentiaalisesti kasvava odotusaika ja uudelleenyritysstrategiat
• Idempotenssiavaimet, jotka tekevät uudelleenyrityksistä turvallisia
• Katkaisijat (circuit breaker) tilanteisiin, joissa palveluntarjoaja ei vastaa
• Varastrategiat, kuten pienempi malli, välimuistista haettu vastaus tai hallittu heikentyminen

Ilman kunnossa olevaa perustaa mallin älykkyydellä ei ole merkitystä.

2. Skeeman hallinta ja rakenteiset tulosteet

Generatiivinen tekoäly keksii helposti rakenteita, joita ei ole olemassa, tai palauttaa väärän tietotyypin. Pipelinessä pitää olla automaattiset tarkistukset, jotka varmistavat, että syntyvä JSON tai muu rakenteinen tuloste noudattaa sovittuja skeemoja.

Nykyiset mallirajapinnat tarjoavat tähän valmiita keinoja:

• Structured outputs: palveluntarjoaja pakottaa JSON-skeeman jo dekoodausvaiheessa
• Function calling ja työkalujen käyttö: tyypitetyt parametrit ja niiden validointi
• JSON-tila: takaa kelvollisen JSONin, mutta ei skeeman mukaisuutta

Näistä huolimatta palvelinpuolen validointi on pakollista. Skeemakuri estää järjestelmän kaatumisen silloin, kun malli tuottaa jotain odottamatonta.

3. Promptien versiointi ja hallinta

Prompteja pitää hallita samalla kurilla kuin koodia. Ne ohjaavat mallin toimintaa samalla tavalla kuin sovelluslogiikka ohjaa palvelun toimintaa. Silti promptit ovat usein hajallaan tekstitiedostoissa, koodiin kirjoitettuina merkkijonoina tai pahimmassa tapauksessa vain kehittäjän päässä.

Kypsä pipeline kohtelee prompteja itsenäisinä artefakteina:

• Versionhallinta: jokainen promptin muutos katselmoidaan ja on jäljitettävissä
• Ympäristökohtainen julkaisu: promptit voidaan viedä kehityksestä testiympäristöön ja sieltä tuotantoon
• A/B-testauksen infrastruktuuri: useita promptiversioita voi olla käytössä samaan aikaan
• Regressiotestaus: muutokset prompteihin, malliin tai kontekstin asetuksiin käynnistävät saman evaluointisarjan kuin muutokset koodiin

Ilman tätä kuria pieni sanamuodon korjaus voi huomaamatta heikentää laatua tuhansilla käyttäjillä.

4. Resurssien vakaus

Tekoäly tuo mukanaan taloudellisen riskin, jota perinteisessä laadunvarmistuksessa ei ole tarvinnut miettiä: kustannus vaihtelee kutsu kutsulta. Yksi huonosti rakennettu prompti, tai yksi käyttäjä joka käyttää avointa rajapintaa väärin, voi kasvattaa API-kuluja monta kertaluokkaa.

Testaa vasteajat ja budjettirajat jokaisessa buildissa:

• Aseta kovat token-rajat kutsua ja sessiota kohden
• Seuraa syöte- ja tulostetokenien suhdetta (tulostetokenit maksavat tyypillisesti noin kolmesta viiteen kertaan enemmän kuin syötetokenit)
• Tarkkaile agenttisilmukoita, joissa malli kutsuu itseään toistuvasti
• Määritä kustannuksille SLO-tavoitteet ja hälytä niiden rikkoutumisesta

Tokenien kulutuksen pitää olla ennustettavaa, mitattavaa ja rajattua.

5. Regressiotestaus ja golden test set

Ylläpidä huolellisesti valittua joukkoa edustavia syötteitä, niin kutsuttua golden test settiä, ja aja se jokaisen merkittävän muutoksen yhteydessä. Näin havaitset odottamattomat muutokset vastausten rakenteessa, vasteajoissa, keskeisessä toiminnassa tai evaluointituloksissa.

Koska mallin tulosteet ovat stokastisia myös tarkasti rajatuilla asetuksilla, regressiotestauksen pitää perustua määriteltyihin raja-arvoihin ja odotettuun käyttäytymiseen, ei täsmälliseen vastausten vertailuun. Jos regressio havaitaan, järjestelmän pitää hälyttää heti.

6. Ympäristöjen yhdenmukaisuus

Yleinen syy tuotantohäiriöille on ympäristöjen erkaantuminen. Kehityksessä on käytössä yksi malliversio, testiympäristössä toinen ja tuotannossa kolmas. Tai promptit ovat erilaiset. Tai embedding-malli on päivitetty yhdessä ympäristössä mutta ei muissa.

Pidä ympäristöjen yhdenmukaisuutta ehdottomana vaatimuksena:

• Sama malliversio kaikissa ympäristöissä, ellei eroa testata tarkoituksella
• Samat embeddingit, vektori-indeksit ja hakuasetukset
• Samat promptipohjat ja työkalumäärittelyt
• Sama guardrails-asetusten kokoonpano

Kun jokin toimii testiympäristössä mutta hajoaa tuotannossa, syy on lähes aina ympäristöjen välinen ero.

Tämä oli ensimmäinen postaus EvalOps blogisarjassamme. Lue seuraava täältä!

• Blog
|
• EvalOps