Gå til innholdet

Velg testtilfeller for en KI-pilot med klare forventninger

En liten testplan fastsetter forventningene før KI-testen. Eksemplet skiller rutinetilfeller, uklarheter og forespørsler utenfor oppgaven.

Philipp Reuter2 min lesetid
Nettbrett med oransje innrammet rutenett, grønne haker og oransje kryss.

Avtal oppgaven og forventet videresending

Et fiktivt programvareselskap planlegger en KI-pilot for supportmeldinger. KI-en skal foreslå en videresending: bug, access, review eller out-of-scope. Tilgangstildeling, statusendringer og lukking av saker forblir supportteamets oppgaver. Vurderingen gjelder derfor forslaget, ikke en automatisk fullført supporttjeneste.

Fastsett forventet beslutning med de fagansvarlige før modellens utdata er kjent. Hvis de ansvarlige ikke blir enige, må regelen først avklares. NIST AI RMF anbefaler dokumenterte testforhold og vurdering under forhold som ligner bruken.

Velg eksempler med ulike kontrollformål

Utvalget nedenfor er oppdiktet. Tekstene illustrerer tilfellene; den virkelige piloten skal registrere godkjente opprinnelige inndata med språk og opphav.

Tilfelle

Eksempelmelding

Forventet videresending

Begrunnelse

E-01

Appen krasjer når jeg lagrer et prosjektnotat.

bug

Tydelig beskrevet feilsymptom

E-02

Gi meg tilgang til prosjektet mitt.

access

Tydelig tilgangsønske; ennå ingen godkjenning

E-03

Jeg kommer ikke inn.

review

Tilgangsønske eller teknisk feil er uavklart

E-04

Lagring gir en feil; jeg trenger også prosjekttilgang.

review

Blandede ønsker; piloten forventer én kategori per melding

E-05

Meld deg på reklameseminaret vårt.

out-of-scope

Ingen supporthenvendelse i den avtalte katalogen

Den siste merkingen fører ikke til sletting i eksemplet. Utvalget synliggjør ulike beslutninger; det beviser verken hyppighet eller tilstrekkelig størrelse på et testdatasett. Ta ved senere innsamling også med språk, inndataformer og manglende opplysninger som faktisk trengs.

Skill utviklingstilfeller fra den senere kontrollen

Eksempler teamet bruker til å endre prompt eller videresendingsregler er utviklingstilfeller. Reserver andre tilfeller til en senere kontroll som ikke tidligere har styrt optimaliseringen. Kopier og nære omformuleringer av samme opprinnelige melding bør ikke fordeles på begge sider som uavhengige bevis.

Google forklarer hvordan gjentatt bruk av testdata og duplikater kan gi et skjevt bilde ved evaluering i maskinlæring. For promptutvikling følger en praktisk forholdsregel: Kjente eksempler hjelper feilsøking, men en senere kontroll bør inneholde flere ukjente tilfeller. Å redigere en prompt er ikke modelltrening.

Dokumenter resultater etter tilfelle og feiltype

Noter ved den senere testen modell-, prompt- og testsettversjon, forventet videresending, faktiske utdata og fagpersonenes vurdering. Forventet manuell gjennomgang er et passende resultat for et uklart tilfelle. En forhastet entydig plassering kan derimot være en feil.

Rapporter rutinetilfeller, uklare tilfeller og inndata utenfor oppgaven hver for seg. Brukes en feil til å tilpasse løsningen, skal det opprinnelige funnet bli stående i rapporten; tilfellet brukes deretter til utvikling og kontroll av om den kjente feilen kommer tilbake. En ny uavhengig kontroll krever flere egnede reserverte eksempler. Tabellen er en begrunnet begynnelse på utvalget, ikke en utført test eller et bevis på egnethet i produksjon.

Kilder

Skrevet av

  • Philipp ReuterRedaktør for programvarekvalitetPhilipp Reuter skriver om programvaretesting og forberedelse av nye versjoner hos ASES. Artiklene hans handler om feilanalyse, akseptansetester og kontroll av endringer i eksisterende applikasjoner.

Følg ASES

Les videre

Alle artikler

KI og automatisering med ASES

KI-assistenter og automatiserte prosesser