Promptfoo vai Giskard: CI-testit ja automaattiskannaus

Valitse Promptfoo, jos tiedät jo, mitä riskejä haluat testata toistuvasti ja millä ehdoilla muutos saa läpäistä CI-ajon. Promptfoon red team -määrityksessä kohde, sovelluksen tarkoitus, hyökkäyksiä tuottavat lisäosat ja hyökkäystavat määritetään erikseen. Se antaa tiimille tavan rajata testattavat tilanteet ja säilyttää samat tapaukset myöhempää arviointia varten.

Valitse Giskard, jos agentin mahdolliset heikkoudet ovat vielä epäselviä ja haluat aloittaa niiden etsinnästä. Giskardin Scan-toiminto luo agentin kuvauksesta skenaarioita, ajaa ne agenttia vasten ja arvioi vastaukset. Sen vulnerability_scan etsii haavoittuvuuksia, kun taas quality_scan vertaa vastauksia omaan tietopohjaan. Molemmilla työkaluilla voi rakentaa CI-portin; valintaa ohjaa se, määritetäänkö testit ensin vai etsitäänkö niitä skannauksella.

Kohteen määritys ratkaisee testin osuvuuden

Promptfoossa kohteeksi voidaan määrittää malli, rajapinta tai sovellus. Sovelluksen tarkoitus ohjaa hyökkäysten tuottamista, ja lisäosilla valitaan riskit, joita halutaan koetella. Jos tarkoitus on löytää prompt-injektioita agentin hakemista sisällöistä, testin on kuljettava kyseisen haku- ja vastausketjun kautta. Pelkälle taustamallille lähetetty syöte ei paljasta, miten sovellus käsittelee haetun sisällön tai rajaa työkalujen käyttöä.

Giskardissa annetaan kutsuttava agentti ja kuvaus siitä, mitä se tekee. Kuvauksen kannattaa nimetä myös toiminnan rajat: esimerkiksi millaisiin kysymyksiin agentti saa vastata ja mitä tietoja se ei saa paljastaa. Silloin tuotetut skenaariot kohdistuvat oman sovelluksen käyttäytymiseen. Yleisluonteinen kuvaus jättää vähemmän aineksia erottaa agentille olennainen rikkomus tilanteesta, joka olisi ongelma lähes mille tahansa chatbotille.

Suomeksi palvelevan sovelluksen testikieli on osa kohteen määritystä. Promptfoon määrityksessä hyökkäysten kielet voi valita, ja Giskardin skannaus ottaa vastaan kielivalinnan. Jos tuotantokäyttö tapahtuu suomeksi mutta testit laaditaan vain englanniksi, testijoukko ei kata samaa kielellistä tilannetta kuin käyttäjän pyyntö. Sama koskee käyttöoikeuksia: vuotoa koskeva testi tarvitsee uskottavan eron käyttäjän omien ja muiden tietojen välille.

Hyökkäysten tuottaminen ja tuomarin arvio ovat eri päätöksiä

Promptfoon lisäosat määrittävät, millaisia haitallisia syötteitä luodaan, ja strategiat määrittävät, miten niitä toimitetaan kohteelle. Giskardin skannaus käyttää agentin kuvausta lähtökohtana sille, millaisia tilanteita se kokeilee. Kummassakin tapauksessa hyökkäyksen tuottava malli vaikuttaa siihen, kuinka osuvia ja vaihtelevia tapaukset ovat. Laaja määrä huonosti kohdistettuja syötteitä ei korvaa sovelluksen tehtävään liittyvää skenaariota.

Kun kohde vastaa, tulos pitää arvioida. Tarkasti havaittavaan seuraukseen sopii täsmällinen ehto: esimerkiksi kielletyn merkkijonon palautumista tai luvattoman työkalukutsun syntymistä voidaan etsiä suoraan, jos testijärjestelmä näkee tarvittavan vastauksen tai jäljen. Avoimemmissa tilanteissa arviointiin voidaan käyttää kielimallia. Silloin tuomari tulkitsee, rikkooko vastaus sovelluksen tarkoitusta, eikä päätös ole yhtä yksiselitteinen kuin suora tekninen tarkistus.

Mallituomari voi erehtyä kumpaankin suuntaan. Kohtelias kieltäytyminen voi silti sisältää paljastuneen yksityiskohdan, ja sallittu vastaus voidaan tulkita rikkomukseksi, jos arviointiohje kuvaa agentin tehtävän liian ahtaasti. Siksi epäonnistunut skenaario tarvitsee vastauksen ja keskustelun kulun tarkastelun ennen kuin siitä tulee julkaisuja pysäyttävä testi. Puhdas skannaus puolestaan kertoo vain siitä testijoukosta ja arviointitavasta, joilla se tehtiin.

CI-porttiin viedään tallennettu testijoukko

Promptfoossa uusien hyökkäysten luonti ja aiemmin luotujen tapausten arviointi voidaan erottaa toisistaan. Sen CI-ohje kuvaa redteam run -ajon sekä aiemmin generoidun redteam.yaml-tiedoston ajamisen redteam eval -komennolla. Ohjeessa näytetään myös, miten arvioinnin epäonnistuminen tai valittu laatukynnys voi pysäyttää putken. Näin muutospyynnössä voidaan ajaa tunnetut tapaukset ilman, että hyökkäysjoukko rakennetaan joka kerta uudelleen.

Giskardissa CI-työnkulku tallentaa skannauksen tuottaman Suite-testisarjan tiedostoon ja ajaa saman sarjan uudelleen muutospyynnöissä. Tulos voidaan viedä JUnit XML -raporttiin, ja epäonnistuneiden tapausten määrästä voidaan tehdä putken pysäyttävä ehto. Tallennetun sarjan uusinta ohittaa skenaarioiden generoinnin, mutta kielimallia käyttävä tuomari tarvitsee edelleen mallikutsun.

Kiinteä testijoukko tekee peräkkäisistä ajoista vertailukelpoisempia: sama syöte kohtaa sovelluksen uuden version. Se ei kuitenkaan takaa täysin samaa tuomiota, jos arvioiva malli tai agentin vastaus vaihtelee. Uusien hyökkäysten generointi sopii erilliseen löytämisajoon, jossa vaihtelu on tarkoituksenmukaista. Jos skannaus luo joka muutospyynnössä eri tapaukset, muuttunut tulos voi johtua joko sovelluksesta tai testiaineistosta.

Löydös muuttuu regressiotestiksi vasta tarkistuksen jälkeen

Kun skannaus paljastaa mahdollisen prompt-injektion tai tietovuodon, pysyvään sarjaan kannattaa säilyttää muutakin kuin hyökkääjän viimeinen viesti. Testi tarvitsee tilanteen, jossa virhe syntyi: agentin tehtävän, tarvittavan keskusteluhistorian, käytettävissä olleet työkalut sekä käyttäjän oikeudet. Muuten myöhempi ajo saattaa testata eri toimintaa kuin alkuperäinen löydös, vaikka syöte näyttäisi samalta.

Seuraava päätös koskee odotettua tulosta. Jos ongelma oli toisen käyttäjän tiedon palautuminen, ehto voidaan kohdistaa juuri siihen paljastumiseen. Jos agentti antoi kiellettyä neuvontaa, arvioinnissa tarvitaan selvä kuvaus siitä, mikä vastaus on sovelluksessa sallittu. Ihmisen tarkistama tapaus on vakaampi portti kuin kokonainen käsittelemätön skannausraportti, jossa yksittäinen epävarma tuomio voi pysäyttää muutospyynnön.

Korjauksen jälkeen sama tapaus voidaan ajaa vanhaa ja uutta versiota vasten. Näin nähdään, muuttuiko juuri löydökseen liittyvä käyttäytyminen. Testisarjan voi myöhemmin täydentää uusilla skannauksilla, mutta lisäykset kannattaa arvioida erikseen: uusi tapaus voi tuoda näkyviin uuden riskin tai olla aiemman testin muunnelma. Pysyvän sarjan arvo syntyy tunnistettavista ehdoista, ei pelkästä tapausten määrästä.

Kulut ja tietojen kulkureitti voivat ratkaista valinnan

Testauksen kustannus muodostuu ainakin kohdeagentin kutsuista, hyökkäysten tuottamisesta ja vastausten arvioinnista. Tallennetun sarjan ajaminen säästää generointivaiheen kutsut, mutta ei välttämättä kohteen tai tuomarin kutsuja. Mitä useammin CI ajetaan ja mitä suurempi sarja on, sitä enemmän tällä erolla on merkitystä. Kulua kannattaa siksi arvioida erikseen löytämisajolle ja muutospyyntöjen pysyvälle regressiosarjalle.

Tietosuojan kannalta kohde, hyökkäysten tuottaja ja tuomari ovat erillisiä reittejä. Promptfoon tietojenkäsittelyohje kertoo, että palvelun ylläpitämä generointi voi saada sovelluksen tarkoituksen ja arviointi myös testisyötteen sekä kohteen vastauksen. Omalla malliyhteydellä reittiä voi muuttaa, mutta osa lisäosista vaatii etäpalvelua. Giskardin skannaus tarvitsee puolestaan mallipalveluntarjoajan skenaarioiden tuottamiseen ja arviointiin.

Jos testivastaukset voivat sisältää asiakastietoa, arviointimallin valinta on yhtä olennainen kuin testattavan agentin valinta. Promptfoo sopii tiimille, joka haluaa rajata hyökkäystyypit asetuksissa ja ajaa tarkistetut tapaukset toistuvasti. Giskard sopii lähtökohdaksi, kun agentin tehtävä tunnetaan mutta hyökkäyspolut halutaan löytää skannaamalla. Kummassakin pysyvä CI-portti perustuu lopulta siihen, mitkä löydökset hyväksytään testeiksi ja miten niiden tulokset arvioidaan.

Lue myös: