KI-testingHafsteinn Runarsson · AI Konsulent26 Sept 2026 · 10 min

Promptfoo: test og red teaming av KI-applikasjoner

Promptfoo er et åpen kildekode-verktøy for systematisk evaluering og red teaming av KI-applikasjoner. Det lar et team beskrive prompter, modeller, testdata og krav i en konfigurasjon, kjøre kombinasjonene lokalt eller i CI, og sammenligne resultatene før en endring når produksjon.

Kort sagt: Bruk Promptfoo når en manuell sjekk av noen få svar ikke lenger er nok. Verktøyet passer særlig godt når dere må oppdage regresjoner, sammenligne modeller, teste RAG eller agenter og undersøke hvordan løsningen reagerer på uønskede eller ondsinnede innspill.

Hva er Promptfoo?

Promptfoo er både et kommandolinjeverktøy og et bibliotek for å evaluere og sikkerhetsteste applikasjoner bygget på store språkmodeller. Ifølge den offisielle prosjektbeskrivelsen kan det kjøre de samme testtilfellene mot flere prompter og modelltilbydere, kontrollere svar mot definerte krav og vise resultatene i en matrise.

Den grunnleggende modellen er enkel:

• Prompter er instruksjonene eller malene som skal prøves.
• Providers er modellene, API-ene eller den egendefinerte applikasjonen som mottar forespørselen.
• Tests inneholder input, variabler og forventninger.
• Assertions avgjør om et svar består, feiler eller må vurderes manuelt.

Dette gjør KI-testing mer lik vanlig programvaretesting. Testene kan versjoneres sammen med koden, kjøres på nytt etter en endring og brukes som en fast referanse når teamet vurderer en ny modell eller prompt.

Når bør du bruke Promptfoo?

Promptfoo er mest nyttig når dere har et konkret sett med forventninger til løsningen. Verktøyet erstatter ikke produktforståelse, men gjør forventningene repeterbare og synlige.

Typiske bruksområder er:

• Promptregresjon: Kontroller at en omskrevet systemprompt fortsatt håndterer viktige oppgaver og kjente feiltilfeller.
• Modellsammenligning: Kjør samme datasett mot flere modeller eller konfigurasjoner før dere bytter leverandør eller modellversjon.
• RAG-evaluering: Undersøk om svar er relevante og forankret i konteksten som ble hentet.
• Agenttesting: Test verktøybruk, oppgavefullføring og flerstegsforløp.
• Policy- og tilgangstesting: Sjekk om ulike roller får riktige svar og om uautoriserte forespørsler blir avvist.
• Red teaming: Prøv angrepsmønstre som prompt injection, jailbreaks og uønsket informasjonsdeling.
• Kvalitetsport i CI/CD: Kjør et avgrenset evalueringssett på hver pull request og et bredere sett før utrulling.

Den offisielle prosjektoversikten beskriver evaluering av prompter og modeller, red teaming og automatiserte kontroller i CI/CD. Det er et godt tegn på verktøyets styrke: én arbeidsflyt kan dekke flere typer KI-funksjonalitet, mens selve testkravene tilpasses produktet.

Hvordan fungerer en evaluering?

En Promptfoo-evaluering bygger en matrise av prompter, providers og testtilfeller. Hver kombinasjon kjøres, og resultatet vurderes av én eller flere assertions. Det gir både en samlet oversikt og et detaljnivå der teamet kan se hvilket input som utløste en feil.

En praktisk arbeidsflyt er:

1. Definer målet. Bestem hvilken beslutning evalueringen skal støtte, for eksempel om en ny prompt kan erstatte den gamle.
2. Velg representative testtilfeller. Ta med normale oppgaver, randtilfeller og tidligere feil.
3. Definer tydelige krav. Bruk deterministiske kontroller når svaret kan vurderes eksakt, og semantiske vurderinger når kvaliteten ikke kan reduseres til strengmatching.
4. Kjør evalueringen. Kommandoen promptfoo eval kjører matrisen.
5. Undersøk resultatene. promptfoo view åpner en visning for sammenligning og feilsøking.
6. Gjør testsettet varig. Legg konfigurasjon og testdata under versjonskontroll, og utvid dem når nye feil oppdages.

Assertions er valgfrie, men et rent manuelt oppsett skalerer dårlig. Den beste balansen er ofte automatiske kontroller for klare krav og manuell vurdering av et mindre utvalg der nyanser, tone eller faglig kvalitet er avgjørende.

Kom i gang med Promptfoo

Den raskeste veien er å starte med et lite, beslutningsrettet testsett. Ikke prøv å modellere hele produktet i første runde.

1. Kontroller forutsetningene

Den offisielle startveiledningen viser installasjon med npm og kjøring med npx. Sjekk alltid prosjektets gjeldende krav før installasjon, fordi runtime-krav kan endres.

Du kan installere verktøyet globalt med npm install -g promptfoo, eller kjøre siste versjon via npx promptfoo@latest uten en global installasjon. Bekreft installasjonen med promptfoo --version.

2. Opprett en startkonfigurasjon

Kjør promptfoo init for en veiledet oppstart, eller bruk eksemplet npx promptfoo@latest init --example getting-started. Da opprettes blant annet promptfooconfig.yaml, som samler prompter, providers og tester.

Hold hemmeligheter utenfor konfigurasjonsfilen. API-nøkler bør ligge i miljøvariabler eller i hemmelighetshåndteringen som CI-plattformen bruker.

3. Bygg et lite testsett

Start med 10–20 situasjoner dere faktisk bryr dere om:

• fem til ti normale brukeroppgaver
• noen vanskelige eller tvetydige spørsmål
• minst ett tidligere feiltilfelle
• noen sikkerhets- eller policytester
• én kontroll for tomme, ugyldige eller svært lange input

Antallet er mindre viktig enn at hvert testtilfelle representerer en reell risiko eller beslutning. Et stort datasett med uklare forventninger gir mindre verdi enn et lite sett med tydelige krav.

4. Kjør og les feilene

Kjør promptfoo eval, og åpne resultatene med promptfoo view. Se først på feil som kan føre til feil handling, datalekkasje eller misvisende svar. Deretter kan dere vurdere tone, format og mindre kvalitetsforskjeller.

Når en feil er forstått og rettet, bør testtilfellet bli liggende. Slik blir hendelsen til en regresjonstest i stedet for en engangsobservasjon.

5. Flytt testen inn i CI

Når testsettet er stabilt, kan det kjøres automatisk ved relevante kode- eller promptendringer. Promptfoo-prosjektet beskriver automatiserte kontroller i CI/CD, og integrasjonsveiledningene viser typiske mønstre med kjøring på pull requests, terskler, caching og separate evalueringer for ulike miljøer.

En god kvalitetsport bør være streng nok til å stoppe kjente alvorlige feil, men ikke så tilfeldig at teamet begynner å ignorere røde bygg.

Slik lager du et testsett som faktisk hjelper

Et godt evalueringssett må speile produktets viktigste beslutninger, ikke bare det som er lett å måle.

Del testene etter formål

Hold ulike kvalitetsdimensjoner adskilt:

• Korrekthet: Er svaret faglig riktig og forankret i tilgjengelig kontekst?
• Oppgavefullføring: Gjorde agenten det brukeren ba om, med riktig verktøy og rekkefølge?
• Policy: Fulgt løsningen tilgangsregler, personvernkrav og interne retningslinjer?
• Sikkerhet: Motstår løsningen manipulerende eller ondsinnede input?
• Format: Returnerer den gyldig struktur, påkrevd språk og nødvendige felter?
• Brukskvalitet: Er svaret tydelig, relevant og handlingsrettet?

Når én totalscore blander alt, blir det vanskelig å se hva som faktisk ble bedre eller verre.

Bruk riktig type assertion

Bruk eksakte eller regelbaserte kontroller for krav som JSON-format, påkrevde ord, forbudte uttrykk og forventede felter. Bruk en modellbasert vurderer når kriteriet er semantisk, for eksempel om et svar forklarer en risiko korrekt.

En modellbasert dommer er nyttig, men ikke deterministisk. Formuler rubrikken konkret, lagre eksempler på bestått og ikke bestått, og kalibrer resultatet mot menneskelig vurdering før det brukes som en hard kvalitetsport.

Test dataflyten, ikke bare modellen

Mange produksjonsfeil ligger rundt modellen: feil kontekst, manglende tilgangskontroll, ugyldig verktøykall eller en respons som tolkes feil av applikasjonen. Test derfor hele kjeden der det er mulig, gjerne mot et kontrollert stagingmiljø med ufarlige testdata.

Promptfoo red teaming forklart

Vanlig evaluering spør om løsningen gjør det den skal. Red teaming spør hvordan den kan lokkes til å gjøre det den ikke skal.

I Promptfoo består red teaming av et mål, plugins som genererer uønskede input, og strategier som varierer hvordan angrepet presenteres. Den offisielle prosjektoversikten beskriver red teaming og sårbarhetsskanning som en del av samme verktøy som brukes til evaluering.

En trygg arbeidsflyt er:

1. Beskriv applikasjonens formål, data og viktigste grenser.
2. Koble til et testmål i et kontrollert miljø.
3. Velg plugins som svarer til produktets reelle trusselbilde.
4. Velg relevante angrepsstrategier.
5. Kjør testen med promptfoo redteam run.
6. Vurder funnene manuelt, rett årsaken og legg kritiske funn inn som faste regresjonstester.

Kjør bare red teaming mot systemer dere eier eller har uttrykkelig tillatelse til å teste. Verktøyet kan avdekke svake kontrollmekanismer, men erstatter ikke en bred sikkerhetsgjennomgang av autentisering, autorisasjon, infrastruktur, logging og hendelseshåndtering.

Promptfoo i CI/CD

Promptfoo gir mest verdi når evaluering blir en del av leveranseløpet, ikke en sjekk som bare kjøres før en stor lansering.

Et praktisk oppsett kan ha tre nivåer:

• På hver endring: Et raskt sett med kritiske regresjons- og formattester.
• Før utrulling: Et bredere sett som dekker modeller, RAG, agentforløp og policy.
• Planlagt kjøring: Tyngre red teaming og tester som er dyrere eller mer variable.

Lagre resultatfiler som byggartefakter, men ikke eksponer prompter, personopplysninger eller modellresponser ukritisk. Evalueringsdata kan inneholde like sensitiv informasjon som applikasjonen den tester.

Skill også mellom staging og produksjon. Produksjonstrafikk kan gi nyttige testtilfeller etter nødvendig rensing og godkjenning, men aktive sikkerhetstester bør normalt kjøres i et kontrollert miljø.

Styrker og begrensninger

Styrker: Promptfoo samler evaluering, sammenligning, assertions, lokal kjøring, CI-integrasjon og red teaming i én arbeidsflyt. Det passer utviklere som ønsker testtilfeller i versjonskontroll og vil koble evaluering tett til produktendringer.

Begrensninger: Store testmatriser kan bli tunge å vedlikeholde i ren YAML. Modellbasert gradering kan variere mellom kjøringer. Kostnad og kjøretid vokser når mange modeller, testtilfeller og dommere kombineres. Team som trenger omfattende annotering, datasettforvaltning eller produksjonsobservabilitet kan fortsatt trenge andre verktøy ved siden av.

En praktisk gjennomgang av Promptfoo peker på samme avveining: den testorienterte arbeidsflyten og red teaming er sterke sider, mens komplekse matriser og omfattende datasettforvaltning krever mer struktur rundt verktøyet.

Det riktige spørsmålet er derfor ikke om Promptfoo dekker all KI-kvalitet. Spør heller om det gir teamet en kortere vei fra kjente risikoer til repeterbare tester. For mange utviklingsteam er det den viktigste starten.

Sjekkliste før du bruker resultatet som kvalitetsport

• Testsettet dekker de viktigste brukeroppgavene og feiltypene.
• Kritiske policy- og tilgangsregler har egne testtilfeller.
• Assertions er kalibrert mot menneskelig vurdering.
• Tilfeldige modellvariasjoner blir ikke tolket som sikre fakta.
• Hemmeligheter og sensitive data holdes utenfor repo og logger.
• Alvorlige funn blir til permanente regresjonstester.
• Kjøringen har tydelig eier og en avtalt prosess for feil.
• Red teaming skjer bare mot autoriserte mål.

Hva er Promptfoo brukt til?

Promptfoo brukes til å evaluere prompter, modeller, RAG-løsninger og KI-agenter. Det kan sammenligne svar, kontrollere krav automatisk og kjøre red teaming mot en KI-applikasjon før en endring går i produksjon.

Er Promptfoo gratis?

Kjerneprosjektet er åpen kildekode og publiseres med MIT-lisens i det offisielle GitHub-repositoriet. Bruk av eksterne modell-API-er kan likevel gi kostnader hos den aktuelle leverandøren.

Kan Promptfoo kjøre lokalt?

Ja. Selve evalueringsverktøyet kan kjøre lokalt, og den offisielle dokumentasjonen beskriver at evalueringene kan gå fra din maskin direkte til modellen eller applikasjonen som testes. Tilkoblingen dere velger kan fortsatt sende data til en ekstern modell- eller API-leverandør.

Kan Promptfoo teste RAG og KI-agenter?

Ja. Promptfoo har eksempler og vurderingsmønstre for både RAG og agenter. For RAG bør dere teste blant annet relevans og forankring i hentet kontekst. For agenter bør dere også kontrollere verktøybruk, oppgavefullføring, tilgang og flerstegsforløp.

Erstatter Promptfoo en sikkerhetstest?

Nei. Red teaming kan finne svakheter i hvordan KI-laget håndterer angrep og uønskede input, men dekker ikke hele sikkerhetsbildet. Vanlig applikasjonssikkerhet, tilgangskontroll, infrastruktur og manuell verifikasjon må fortsatt vurderes separat.

Trenger dere et evalueringsoppsett som passer produktet?

Et nyttig oppsett starter med produktets faktiske risikoer, ikke med flest mulig målinger. Hvis dere vil avgrense et testsett, koble det til CI og få en tydelig plan for videre forbedring, kan dere starte en samtale med Daia.