Onnistunutta peruspolkua esittelevä demo voi peittää sotkuiset syötteet, vanhentuneet tiedot, työkaluvirheet, epäselvät pyynnöt ja turvattomat toimet.
Tuotanto ei ole yhtä siistiä. Käyttäjät liittävät mukaan sekavia syötteitä. Lähdeasiakirjat ovat vanhentuneita. API-kutsut aikakatkeavat. Kehotteet ajautuvat. Malli noudattaa väärää ohjetta. Asiakas esittää kysymyksen, joka jää juuri aineiston ulkopuolelle. Työkalukutsu onnistuu mutta päivittää väärän tietueen. Työnkulku tuottaa niin sujuvan vastauksen, ettei virhettä huomata ennen kuin myöhemmin.
Tämä on tuotannossa käytettävien tekoälyjärjestelmien vikataparekisteri. Vertaa sitä NIST:n tekoälyriskien hallintakehykseen ja ylläpidettyyn OWASP Top 10 for LLM Applications -luetteloon ja täydennä sitä järjestelmäsi todellisen arkkitehtuurin ja toimialan perusteella.
Tuotantotekoälyn katselmuksessa pitää kysyä ”miten tämä epäonnistuu?” ennen kysymystä ”kuinka vaikuttava onnistunut peruspolku on?” Jokainen vikatapa tarvitsee kontrollin, testin, omistajan ja pysäytysehdon.
Vikatapa 1: uskottava mutta virheellinen tuotos
Järjestelmä tuottaa vastauksen, joka kuulostaa oikealta mutta on perusteeton tai väärä.
Tyypillisiä tilanteita:
- Yksityiskohtaiset faktaväitteet ilman lähteisiin perustamista.
- Oikeudelliset, lääketieteelliset, taloudelliset tai toimintaohjeita koskevat kysymykset.
- Viimeaikaiset tapahtumat.
- Heikkolaatuinen haku.
- Pitkien asiakirjojen tiivistelmät, joissa olennainen näyttö jää piiloon.
Kontrollit:
- Vaadi faktaväitteille viittaukset tai lähdekatkelmat.
- Kieltäydy vastaamasta käytettävissä olevan lähdeaineiston ulkopuolelta.
- Lisää arviointitapauksia tunnetuille virheellisten vastausten malleille.
- Ohjaa vaikutuksiltaan merkittävät tuotokset ihmisen tarkastettaviksi.
- Kirjaa vastauksessa käytettyjen lähteiden tunnisteet.
Älä yritä hallita tätä sanamuodolla ”ole tarkka”. Hallitse sitä lähteillä, testeillä ja katselmointiporteilla.
Vikatapa 2: vanhentunut konteksti
Vastaus perustuu lähteeseen, mutta lähteen tieto on vanhaa.
Esimerkkejä:
- Vanha hinnoittelusivu.
- Korvattu toimintaohje.
- Sopimuksen aiempi versio.
- Vanhentunut tuotedokumentaatio.
- Välimuistiin tallennettu asiakkaan tila.
Kontrollit:
- Tallenna lähteen päivämäärä, versio, omistaja ja ajantasaisuussääntö.
- Suosi määrääviä lähteitä tiivistelmien sijaan.
- Merkitse vanhentuneet lähteet hakutuloksiin.
- Lisää ajantasaisuustestejä.
- Ilmoita omistajalle, kun keskeisen lähteen tarkastusväli on ylittynyt.
RAG-järjestelmä voi vastata vakuuttavasti vanhentuneiden asiakirjojen perusteella. Hakukerroksen on tiedettävä, mitä ”ajantasainen” tarkoittaa.
Vikatapa 3: mielistely ja liiallinen myötäily
Malli myötäilee käyttäjän oletusta sen sijaan, että kyseenalaistaisi sen.
Tällä on merkitystä strategiassa, analyysissä, suunnittelussa ja päätöksenteon tukemisessa. Käyttäjä kysyy: ”Tämä julkaisusuunnitelma vaikuttaa hyvältä, eikö vain?” ja saa riskianalyysin sijaan myötäilevän vastauksen.
Kontrollit:
- Pyydä vastaväitteitä ja epävarmuuden käsittelyä.
- Käytä päätöskriteeristöjä avoimen hyväksyntäpyynnön sijaan.
- Vaadi vastaus kysymykseen ”mikä osoittaisi tämän vääräksi?”
- Erota ideointi arvioinnista.
- Sisällytä arviointeihin esimerkkejä, joissa käyttäjän lähtöoletus on virheellinen.
Järjestelmän pitää auttaa käyttäjää ajattelemaan paremmin eikä vain muotoilla tämän nykyistä näkemystä vakuuttavammaksi.
Vikatapa 4: kehote-injektio
Malli käsittelee epäluotettavaa sisältöä ohjeena.
Esimerkkejä:
- Verkkosivulla lukee ”ohita aiemmat ohjeet”.
- Tukisähköposti sisältää haitallisia ohjeita.
- RAG-aineiston asiakirja kehottaa avustajaa paljastamaan piilotettuja tietoja.
- Työkalun tuloksessa oleva teksti yrittää muuttaa työnkulkua.
Kontrollit:
- Merkitse epäluotettava sisältö selvästi.
- Älä koskaan sijoita haettua sisältöä järjestelmä- tai kehittäjäohjeiden kanssa samalle tasolle ohjehierarkiassa.
- Rajoita työkalujen käyttöoikeuksia.
- Käytä lähtevissä toimissa sallittujen kohteiden luetteloita.
- Testaa injektioesimerkkejä arvioinneissa.
- Pidä salaisuudet poissa kehotteen kontekstista.
Kehote-injektiota ei ratkaista yhdellä nokkelalla järjestelmäkehotteella. Riskiä pienennetään arkkitehtuurilla: datarajoilla, työkalujen käyttöoikeuksilla ja tuotosten validoinnilla.
Vikatapa 5: turvaton työkalujen käyttö
Malli kutsuu väärää työkalua, kutsuu oikeaa työkalua väärillä argumenteilla tai toimii ennen kuin kontekstia on riittävästi.
Esimerkkejä:
- Päivittää väärän CRM-yhteystiedon.
- Lähettää sähköpostin väärälle vastaanottajalle.
- Luo tietueita kahteen kertaan.
- Varaa ajan vahvistamatta aikavyöhykettä.
- Poistaa tai korvaa tietoja.
Kontrollit:
- Aloita pelkillä lukuoikeuksilla.
- Käytä suppeasti rajattuja työkaluja, joilla on yksiselitteiset skeemat.
- Validoi työkaluargumentit mallin ulkopuolella.
- Vaadi kirjoitustoimille vahvistus.
- Lisää idempotenssiavaimet.
- Kirjaa työkalukutsut ja niiden tulokset.
- Lisää hätäkatkaisin.
Työnkulun pitää rajoittaa työkalujen käyttöä. Sitä ei pidä jättää mallin harkinnan varaan.
Vikatapa 6: skeeman ja sopimuksen ajautuminen
Mallin tuotoksen muoto muuttuu tai alavirran API muuttuu, jolloin työnkulku rikkoutuu huomaamatta.
Kontrollit:
- Käytä rakenteisia tuotoksia aina kun mahdollista.
- Validoi jokainen mallin tuotos ennen käyttöä.
- Käsittele väärin muotoiltu tuotos virheenä, josta voi palautua.
- Versioi kehotteet ja skeemat yhdessä.
- Lisää alavirran API-liittymille sopimustestit.
- Valvo jäsennysvirheitä.
Jos alavirran solmu olettaa saavansa kelvollista JSON-dataa, työnkulun on osoitettava, että data on kelvollista JSON-muotoa.
Vikatapa 7: heikko varamenettely
Järjestelmä havaitsee ongelman mutta ei palaudu turvallisesti.
Huonoja varamenettelyjä:
- Tyhjä vastaus.
- Hiljainen epäonnistuminen.
- Yleinen anteeksipyyntö ilman jatkotoimea.
- Toistuva uudelleenyrityssilmukka.
- Ohjaus ihmiselle ilman tarvittavaa kontekstia.
Hyviä varamenettelyjä:
- Selkeä viesti käyttäjälle.
- Siirto ihmisen työjonoon niin, että mukana ovat syöte, lähde, virhe ja yritetty toimi.
- Viiveitä kasvattava uudelleenyritys vain, jos uusi yritys on turvallinen.
- Manuaalinen toimintatapa kiireellisille tapauksille.
- Pysäytysehto toistuville epäonnistumisille.
Varamenettely on osa tuotetta. Jos sitä ei suunnitella, epäonnistumistilanteen käyttäjäkokemus syntyy sattumanvaraisesti.
Vikatapa 8: havainnoitavuuden puute
Jokin menee vikaan, eikä kukaan pysty jälkikäteen selvittämään syytä.
Kontrollit:
- Kirjaa kehotemalli ja sen versio.
- Kirjaa malli ja asetukset.
- Kirjaa lähteiden tunnisteet, ei vain vastauksen tekstiä.
- Kirjaa työkalukutsut, argumentit ja tulokset niin, että arkaluonteiset tiedot on peitetty.
- Kirjaa validointivirheet.
- Seuraa viivettä, kustannuksia ja varamenettelyjen osuutta.
- Pidä säilytysaika lyhyenä, ellei vaatimustenmukaisuus edellytä pidempää aikaa.
Älä tallenna mallin yksityiskohtaista sisäistä päättelyketjua. Tallenna päätösten tiivistelmät, lähdeviitteet, työkalujen syötteet ja tulokset sekä validoinnin tulokset.
Tuotannon vikataparekisteri
Luo yksi rivi kutakin vikatapaa kohden:
| Vikatapa | Esimerkki | Kontrolli | Testi | Mittari | Omistaja | Pysäytysehto |
|---|---|---|---|---|---|---|
| Vanhentunut lähde | Vastauksessa annetaan vanha hinta | Lähteen päivämäärän tarkistus | Vanhaa ja uutta hinnoittelua koskeva kysely | Vanhentuneisiin lähteisiin perustuvien vastausten osuus | Dokumentaation omistaja | Yksikin asiakkaalle näkyvä vanhentunut hinta |
| Turvaton työkalujen käyttö | Väärä CRM-päivitys | Argumenttien validointi + vahvistus | Päällekkäistä tai väärää yhteystietoa koskeva tapaus | Virheellisten toimien osuus | RevOps | Yksikin virheellinen kirjoitustoimi |
Tähän artikkeliin linkitetty rekisteri sisältää mallipohjan.
Älä tee tätä vielä
Älä julkaise asiakkaille näkyvää tekoälytoimintoa ilman vikataparekisteriä.
Älä anna kirjoitustoimia tekevien työkalujen ohittaa validointia.
Älä luota julkaisun jälkeen pelkkiin manuaalisiin pistokokeisiin.
Älä mittaa vain keskimääräistä laatua. Harvinaiset viat voivat muodostaa koko riskin.
Älä hyväksy väitettä ”voimme palauttaa muutoksen”, ellei joku pysty nimeämään todellista palautuspolkua.
Rekisteri, ei demo
Tuotannossa käytettävät tekoälyjärjestelmät voivat epäonnistua hallusinaation, vanhentuneen kontekstin, mielistelyn, kehote-injektion, turvattoman työkalujen käytön, skeeman ajautumisen, heikon varamenettelyn ja havainnoitavuuden puutteiden vuoksi. Rekisterin on perustuttava järjestelmän omaan uhkamalliin, häiriöhistoriaan ja arviointituloksiin.
Kypsä toimintatapa on nimetä vikatavat, lisätä kontrollit, testata ja valvoa niitä sekä osoittaa niille omistajat. Demo näyttää, mikä toimii kerran. Vikataparekisteri näyttää, selviääkö järjestelmä todellisesta käytöstä.
