Tekoälyn perusmallin vaihto ilman laadun heikkenemistä: Evals, Canary ja Rollback

Uusi tekoälyn perusmalli lupaa usein parempia vastauksia, alhaisempia kustannuksia tai nopeampia vasteaikoja. Tuotannossa olevalle verkkosivuston chatbotille vaihto ei silti ole vain minkä tahansa ohjelmistopaketin korvaamista toisella. Jo uusi malliversio saattaa painottaa ohjeita eri tavalla, muotoilla vastaukset laveammin, luoda rakenteellista dataa poikkeavasti tai kutsua työkaluja eri järjestyksessä. Migraatio on siksi onnistunut vasta silloin, kun chatbot suorittaa konkreettiset tehtävänsä vähintään yhtä luotettavasti kuin ennen – ja kun tiimi voi ongelmatilanteissa palata vanhaan minuuteissa.

Tarjoajat poistavat malleja käytöstä säännöllisesti. OpenAI:n dokumentaatio käytöstä poistamisesta sisältää sammutuspäivät ja suositellut korvaavat mallit; Anthropic erottaa omassa Mallien elinkaari -dokumentaatiossaan tilat "Active", "Legacy", "Deprecated" ja "Retired". Tällaiset määräajat ovat syy migraatiolle, mutta ne eivät ole osoitus laadusta. Sen tarjoaa vain testaus- ja käyttöönottomenetelmä, joka sopii omaan chatbottiin.

Mitä perusmallin vaihdossa todella muutetaan

Tämä prosessi on erotettava selkeästi Embedding-mallin migraatiosta. Embedding-vaihdossa asiakirjat on vektorisoitava uudelleen ja hakuindeksit pidettävä yhteensopivina. Perusmallin vaihdossa hakuindeksi pysyy yleensä ennallaan; muutettava asia on malli, joka luo vastauksen järjestelmäohjeen, keskustelun, löydettyjen lähteiden ja työkalutulosten perusteella. Siksi testataan vastauskäyttäytymistä, lähdesidonnaisuutta, muotoa, työkalujen käyttöä, turvallisuutta, latenssia ja kustannuksia.

Myös yleinen Shadow-Mode-testi ennen verkkosivujulkaisua ratkaisee vain osan tehtävästä. Shadow Traffic voi syöttää kahdelle mallille samat syötteet toimittamatta uutta vastausta käyttäjälle. Tässä kuvattu perusmallin vaihto menee pidemmälle: se määrittelee hyväksyntämatriisin etukäteen, ohjaa pienen osan todellisesta liikenteestä ehdokkaalle, valvoo käyttäjä- ja järjestelmäsignaaleja ja pitää testatun palautusvaihtoehdon valmiina.

Ennen testiä: määritä yksiselitteinen migraatiosopimus

Vertailut ovat arvottomia, jos useat asiat muuttuvat samanaikaisesti. Pidä siksi ensimmäisellä kierroksella järjestelmäkehete, hakukonfiguraatio, työkaluskeemat, lämpötila, enimmäistulostuspituus ja turvallisuussäännöt mahdollisimman yhteensopivina ja vakioina, ja dokumentoi välttämättömät parametrimuutokset, kuten tukemattomat näytteenottovaihtoehdot. Dokumentoi aiempi malli vertailukohdaksi (basis) ja uusi malli ehdokkaaksi (kandidaatti). Käytä mahdollisuuksien mukaan eksplisiittisiä malliversioita liikkuvan aliaksen sijaan. Alias voi myöhemmin osoittaa toiseen vedokseen ja muuttaa oletettavasti toistettavaa vertailua.

Migraatiosopimus sisältää myös ne käyttäjäryhmät ja toiminnot, jotka jätetään aluksi ulkopuolelle. Esimerkiksi UKK-chatbot voidaan siirtää Canary-vaiheeseen varhaisessa vaiheessa, kun taas tilauksien kirjoitusoikeudet, sopimustiedot tai erityisen arkaluonteiset tukitapaukset pysyvät pidempään vanhalla mallilla. Tällä tavoin riskiä rajataan liiketoimintavaikutuksen eikä pelkästään teknisen monimutkaisuuden mukaan.

Testisetin on vastattava todellista liikennettä

Golden Set -testijoukon ei pitäisi sisältää vain puhtaita vakiokysymyksiä. Kerää anonymisoituja tai synteettisesti luotuja tapauksia tärkeimmistä aikeista (intents): selkeitä kysymyksiä, monitulkintaisia muotoiluja, jatkokysymyksiä, puuttuvia asiakirjoja, ristiriitaisia lähteitä, työkaluvirheitä ja syötteitä, jotka on siirrettävä ihmiselle. Jaa tapaukset kielen, laitteen, asiakastyypin ja riskiluokan mukaan. Tämä paljastaa, peittääkö hyvä kokonaisarvosana pieniä, mutta liiketoiminnan kannalta kriittisiä osaryhmiä.

Virallinen Anthropicin opas onnistumiskriteereistä ja evaleista suosittelee erityisiä, mitattavia ja käyttötarkoitukseen liittyviä kriteereitä sekä realistisia reunatapauksia. Myös OpenAI:n opas evaleihin kuvailee testejä luotettavien sovellusten olennaiseksi osaksi erityisesti silloin, kun päivitetään tai kokeillaan uusia malleja. Koska OpenAI ilmoittaa samalla sivulla poistavansa aiemman Evals-alustan käytöstä, oma Golden Set kannattaa tallentaa siirrettävässä muodossa eikä sitoa sitä yhteen ainoaan kojelautaan.

Arviointimatriisi yhden keskiarvon sijaan

Seuraavat raja-arvot ovat esimerkki, eivät yleispätevä vaatimus. Määritä ne aiemman tuotantosuorituskyvyn ja virheen aiheuttaman vahingon perusteella. Ehdokasmalli ei saa kompensoida edullisempaa token-hintaa huonommalla lähdesidonnaisuudella.

Automaattiset tarkistukset sopivat JSON-skeemoille, pakollisille sanamuodoille, linkkikohteille, työkalun argumenteille ja deterministisille liiketoimintasäännöille. Äänensävyn, täydellisyyden ja hyödyllisten selitysten osalta tarvitaan lisäksi selkeä arviointiasteikko; asiantuntijoiden tekemät pistokokeet kalibroivat LLM-pohjaisen arvioijan. Tulokset tulee tallentaa intent- ja riskiluokkakohtaisesti, ei vain yhtenä pistemääränä. Miten tällainen setti rakennetaan, näytetään myös oppaassamme koskien vastauslaatua Golden Setin avulla.

Konkreettinen esimerkki: Mallin vaihto B2B-tuessa

Oletetaan, että B2B-ohjelmistotarjoaja pyörittää chatbotia tuotekysymyksiä, tilinhallintaa ja tukipyyntöjen valmistelua varten. Tiimi luo 240 testitapausta: 120 yleistä tietokysymystä, 40 monitulkintaista jatkokysymystä, 30 tapausta puuttuvalla lähteellä, 25 työkalusimulaatiota ja 25 turvallisuus- tai siirtotapausta. Molemmat mallit saavat täsmälleen samat kehotteet, dokumenttiosumat ja simuloidut työkalutulokset.

Ehdokas vastaa vakiokysymyksiin nopeammin ja edullisemmin, mutta menettää viittauksen edelliseen viestiin viidessä jatkokysymyksessä. Kokonaisarvosana olisi silti parempi. Segmenttianalyysi näyttää kuitenkin selvän laatumurtuman. Tiimi ei lisää mielivaltaista poikkeusta, vaan tarkentaa keskustelusääntöä, laajentaa testisettiä samanlaisilla tapauksilla ja testaa molemmat mallit uudelleen. Vasta kun ehdokas täyttää kaikki kovat portit, alkaa tuotannon Canary-vaihe.

Aloitusta varten kaksi prosenttia sopivista uusista keskusteluista ohjataan ehdokkaalle. Kohdennus johdetaan keskustelun alussa esimerkiksi keskustelu-ID:n tiivisteestä (hash) ja se pidetään samana koko keskustelun ajan; korkeammat Canary-tasot koskevat vain uusia keskusteluja. Kirjoittavat työkalukutsut ja korkean riskin intentit pysyvät aluksi vanhalla mallilla. Riittävän suuren havainnointi-ikkunan jälkeen seuraavat 10, 25, 50 ja lopulta 100 prosenttia – mutta vain, jos jokainen portti pysyy vihreänä. Vaiheet ja vähimmäisotoskoot määritetään etukäteen, jotta aikapaine ei jälkikäteen vesitä sääntöjä.

Verkkosignaalit, joilla on todella merkitystä

Canary-vaiheessa HTTP-virheet ja keskimääräinen latenssi eivät riitä. Seuraa ilman vastausta jääneiden osuutta (No-Answer-Rate), keskeytyksiä ensimmäisen vastauksen jälkeen, toistuvia kysymyksiä, siirto-osuutta (Handoff-Quote), lähdeklikkauksia, skeemavirheitä ja työkalujen keskeytyksiä erikseen vanhalle ja ehdokasmallille. Yhtenäinen jäljitys (trace) yhdistää malliversion, keheteversion, hakutulokset ja työkaluvaiheet tallentamatta tarpeettomia henkilötietoja. Artikkelimme koskien chatbotin observabiliteettia selittää tämän tarkistuspolun yksityiskohtaisesti.

Vertaa myös kustannuksia ratkaistua tapausta kohden pelkkien miljoonaa tokenia kohden laskettujen kustannusten sijaan. Edullisempi malli, joka aiheuttaa useammin jatkokysymyksiä tai ihmisen tekemää jälkityötä, voi olla toiminnallisesti kalliimpi. Päinvastoin pieni latenssin kasvu voi olla hyväksyttävää, jos se tuo todistettavasti tarkempia vastauksia tärkeässä riskiluokassa.

Rollback on ominaisuus, ei asiakirja

Palautusreitti on testattava teknisesti ennen ensimmäistä Canary-vaihetta. Malli-ID ja siihen liittyvät parametrit kuuluvat versioituun konfiguraatioon tai hallittuun ominaisuuslippuun (feature flag). Niin kauan kuin tarjoaja tukee edellistä versiota, se pysyy Canary-vaiheen aikana käytettävissä palautuskohteena; ennen sen sammutuspäivää tarvitaan lisäksi tuettu varavaihtoehto. Olemassa olevien keskustelujen tulisi joko pysyä johdonmukaisesti alkuperäisessä mallissaan tai vaihtua erikseen testatun säännön mukaisesti.

Määritä kovat laukaisimet: esimerkiksi skeemavirhe kirjoitustoiminnossa, turvallisuuden kannalta olennaisen intentin heikkeneminen, virheprosentin selvä nousu tai latenssibudjetin ylitys. Tällaisesta signaalista palautus tapahtuu automaattisesti tai selkeästi nimetyn päivystäjän toimesta. Sen jälkeen lokit, ehdokasversio ja kyseinen otos säilytetään, jotta syy voidaan analysoida. Valmisteltu prosessi on huomattavasti luotettavampi kuin spontaani koodijulkaisu; lisäksi apuna toimii täydellinen Incident Response Playbook.

Tarkistuslista hyväksyntää varten

• Tallenna sammutuspäivä, korvaava malli ja kyseiset päätepisteet virallisesta tarjoajan dokumentaatiosta.
• Lukitse vanha malli ja ehdokas muuttamattomilla kehete-, haku- ja työkalukonfiguraatioilla.
• Jaa Golden Set intentin, kielen ja riskiluokan mukaan; täydennä reunatapauksilla ja todellisilla virhetilanteilla.
• Määritä kovat portit lähdesidonnaisuudelle, rakenteellisille tulosteille, työkaluille, turvallisuudelle ja siirrolle.
• Mittaa latenssi, virheprosentti, tokenit ja kustannukset ratkaistua tapausta kohden.
• Pidä Canary-kohdennus vakaana kokonaisille keskusteluille ja sulje arkaluonteiset toiminnot aluksi ulkopuolelle.
• Dokumentoi vaiheet, vähimmäisotoskoko, havainnointiaika ja keskeytysrajat ennen käyttöönottoa.
• Testaa rollback teknisesti, nimeä vastuuhenkilöt ja pidä tarjoajan tukema palautuskohde saatavilla.
• Jatka seurantaa 100 prosentin saavuttamisen jälkeen ja laajenna Golden Setiä uusilla tuotantotapauksilla.

Johtopäätös: Mallin nimi on vasta alkua

Hallittu perusmallin vaihto yhdistää tuotelaadun ja käyttövarmuuden. Viralliset elinkaariohjeet antavat määräajan, evaluaatiot tarjoavat näytön sopivuudesta, Canary-liikenne rajoittaa tuntemattomien virheiden vaikutusta ja testattu rollback lyhentää reaktioaikaa. Ne, jotka vakiinnuttavat nämä neljä kulmakiveä toistettavaksi prosessiksi, voivat hyödyntää uusia malleja ilman, että verkkosivuston chatbotista tulee kokeilu kaikille käyttäjille.

Haluatko suunnitella verkkosivustosi chatbotin malliversion, laatuportit ja käyttöönoton jäsennellysti? ChatReact auttaa sinua määrittämään tietopohjan, vastauskäyttäytymisen ja siirrot niin, että muutokset pysyvät mitattavina ja hallinnassa.