Välj testfall för en AI-pilot med tydliga förväntningar

Avtala uppgiften och den förväntade kategoriseringen

Ett fiktivt programvaruföretag planerar en AI-pilot för supportmeddelanden. AI:n ska föreslå en kategori: bug, access, review eller out-of-scope. Att ge åtkomst, ändra status och stänga ärenden förblir supportteamets uppgifter. Bedömningen gäller alltså förslaget, inte en automatiskt avslutad supporttjänst.

Fastställ det förväntade beslutet med de verksamhetsansvariga innan modellens utdata är kända. Kan de ansvariga inte enas behöver regeln först klargöras. NIST AI RMF rekommenderar dokumenterade testförhållanden och bedömning under förhållanden som liknar användningen.

Välj exempel med olika kontrollsyften

Följande urval är påhittat. Texterna illustrerar fallen; för den verkliga piloten dokumenteras godkända ursprungliga indata med språk och ursprung.

Den sista markeringen medför ingen radering i exemplet. Urvalet synliggör olika beslut; det bevisar varken fallens frekvens eller tillräcklig storlek på en testdatamängd. Ta vid senare insamling även med faktiskt nödvändiga språk, indataformer och uppgifter som saknas.

Skilj utvecklingsfall från den senare kontrollen

Exempel som teamet använder för att ändra prompt eller kategoriseringsregler är utvecklingsfall. Reservera andra fall för en senare kontroll som inte redan har använts för optimering. Kopior och nära omformuleringar av samma ursprungsmeddelande bör inte fördelas på båda sidor som oberoende belägg.

Google förklarar hur upprepat använda testdata och dubbletter kan snedvrida bedömningen inom maskininlärning. För promptutveckling följer en praktisk försiktighet: Kända exempel hjälper felsökning, men en senare kontroll bör innehålla ytterligare okända fall. Att redigera en prompt är ingen modellträning.

Dokumentera resultat per fall och feltyp

Anteckna vid det senare testet modell-, prompt- och testmängdsversion, förväntad kategori, faktisk utdata och verksamhetens bedömning. Förväntad manuell granskning är ett lämpligt resultat för ett oklart fall. En förhastad entydig tilldelning kan däremot vara ett fel.

Rapportera rutinfall, oklara fall och indata utanför uppgiften separat. Används ett fel för att anpassa lösningen ska den ursprungliga iakttagelsen finnas kvar i rapporten; fallet används därefter för utveckling och kontroll av om det kända felet återkommer. En ny oberoende kontroll kräver fler lämpliga reserverade exempel. Tabellen är en motiverad början på urvalet, inget utfört test eller belägg för lämplighet i produktion.

Källor

• NIST · AI Risk Management Framework 1.0

• Google · Dividing the original dataset