Planera ai-röd teamindelning

Slutförd

Den röda teamindelningsprocessen är en bra metod för ansvarsfull utveckling av program och system som använder stora språkmodeller (LLM). Red Teaming kompletterar utvecklarnas systematiska mätnings- och åtgärdsarbete och hjälper till att upptäcka och identifiera skador. Röda team hjälper också till att aktivera mätstrategier för att verifiera effektiviteten av minskningar.

När du planerar din egen metod för red teamindelning av LLM:er och AI-aktiverade program som används av din organisation bör du överväga följande mål:

• Se till att rätt säkerhetsprotokoll för programvara följs för programmet. Bara för att ett program använder AI betyder det inte att du bör ignorera traditionella säkerhetsrutiner.
• Testa LLM-basmodellen och avgöra om det finns luckor i de befintliga säkerhetssystemen, med tanke på programmets kontext.
• Ge feedback om fel som testningen upptäcker för att göra förbättringar.

Du bör inkludera följande element när red teaming LLMs och AI-aktiverade program under utveckling av din organisation.

• Rekrytera det röda AI-teamet
• Utforma kontradiktoriska tester
• Utföra tester
• Rapportresultat

Rekrytera det röda teamet

Framgången för ditt ai-röda team är beroende av de personer som du rekryterar för att kunna utföra den röda AI-teamindelningsprocessen. Tänk på följande principer när du väljer röda gruppmedlemmar:

• Välj för olika erfarenheter, demografi och expertis
• Säkerställa en blandning av godartade och kontradiktoriska tankesätt
• Sprida röda teammedlemmar över skador och produktfunktioner
• Ange tydliga mål för röda teammedlemmar

Välj för olika erfarenheter, demografi och expertis

Vid röd teamindelning måste du avsöka DET LLM- eller AI-aktiverade programmet på ett sätt som är uppenbart. Du måste också avsöka LLM- och AI-aktiverade program med metoder som har utvecklats ur olika perspektiv på världen. Sök efter röda teammedlemmar med olika erfarenhetsnivåer, demografisk bakgrund, olika expertområden och olika användningsfall för mål-LLM- eller AI-aktiverat program. Om du till exempel söker efter en chattrobot för att hjälpa vårdgivare har en sjuksköterska en annan metod än en systemadministratör som hanterar chattrobotens värdinfrastruktur.

Säkerställa en blandning av godartade och kontradiktoriska tankesätt

Den traditionella metoden med röda team är att bemanna dem med IT-proffs och utvecklare som har ett kontradiktoriskt tankesätt och en säkerhetstestupplevelse. När det gäller AI-aktiverade program och LLM:er är det också viktigt att inkludera personer i ditt röda team som är vanliga användare av ditt programsystem. Dessa användare kan ge värdefulla perspektiv på skador som vanliga användare kan stöta på. Till exempel kan en sjuksköterska komma på hur man övertygar en chattrobot att släppa konfidentiella patientdata på ett sätt som inte skulle inträffa för en informationssäkerhetspersonal. Precis som en indirekt förhandlingsmetod kan lyckas med vissa personer kan en indirekt metod för manipulering av AI-aktiverade program och LLM:er reta ut resultat som blockeras av konventionella attacker.

Tilldela red teamers skador och produktfunktioner

Tilldela ansvariga AI-medlemmar (RAI) röda teammedlemmar med specifik expertis för att söka efter specifika typer av skador. Experter på säkerhetsämnen kan till exempel söka efter jailbreaks, extrahering av metaprompt och innehåll som rör cyberattacker.

För flera testomgångar bestämmer du om du vill byta red teamer-tilldelningar i varje omgång för att få olika perspektiv på varje skada. Att byta uppgifter kan också upprätthålla kreativiteten i hur de röda teamen närmar sig tilldelningarna. När du växlar tilldelningar kan du ge de röda teamen tid att anpassa sig till processen för den nyligen tilldelade skadan.

I senare skeden av den röda teamindelningsprocessen, när programmet och dess användargränssnitt har utvecklats, kanske du vill tilldela red teamers till specifika funktioner i programmet för att säkerställa täckning av hela programmet.

Fundera på hur mycket tid och ansträngning varje red teamer bör ägna (till exempel kan testning för godartade scenarier behöva mindre tid än testning för kontradiktoriska scenarier).

Ange tydliga mål för röda teammedlemmar

Röda teammedlemmar bör förses med tydliga instruktioner som kan innehålla:

• En introduktion som beskriver målet med den angivna omgången av röd teamindelning
• Den produkt och de funktioner som ska testas och hur du kommer åt dem
• Vilka typer av problem som ska testas för
• Hur mycket tid och arbete varje röd teammedlem ska ägna åt testning
• Så här registrerar du resultat
• Vem du ska kontakta med frågor.

Det röda teamet bör förses med ett konsekvent sätt att registrera sitt resultat, inklusive:

• Det datum då ett exempel visades
• En unik identifierare för indata-/utdataparet om det är tillgängligt för reproducerbarhetsändamål
• Indataprompten; en beskrivning eller skärmbild av utdata.

Utforma kontradiktoriska tester

Eftersom ett program har utvecklats med hjälp av en basmodell kan du behöva testa på både LLM och programskiktet. Red Teamers bör testa följande före och efter att åtgärder har införts:

• LLM-basmodellen med säkerhetssystemet på plats för att identifiera eventuella luckor som kan behöva åtgärdas i samband med ditt programsystem. Den här testningen utförs ofta via en API-slutpunkt.
• AI-aktiverat program. Den här testningen utförs ofta via ett användargränssnitt.

Utföra tester

Du kan börja med att testa basmodellen för att förstå riskytan, identifiera skador och vägleda utvecklingen av RAI-åtgärder för din produkt. Du bör testa versioner av din produkt iterativt med och utan RAI-åtgärder för att utvärdera effektiviteten av RAI-åtgärder. Du bör använda både manuella röda teamindelningar och systematiska mätningar. Tester bör utföras i produktionsgränssnittet så mycket som möjligt eftersom detta replikerar verklig användning. När du rapporterar resultat ska du klargöra vilka slutpunkter som användes för testning. När testningen gjordes i en annan slutpunkt än produkten bör du överväga att testa igen på produktionsslutpunkten eller användargränssnittet i framtida omgångar.

Testerna bör innehålla följande element:

• Fastställa omfattningen av skada
• Utöka listan över skador baserat på öppen testning
• Testa igen när du har tillämpat åtgärder

Fastställa omfattningen av skada

Börja med organisationens principer för förtroende och säkerhet eller ansvarsfull AI. Du kan behöva hantera efterlevnadsregler och verkställande order. Det är nödvändigt att samarbeta med organisationens juridiska team och policyteam för att identifiera de viktigaste skadorna för din organisation och just det här programmet. Resultatet av detta samråd kommer att bli en lista över skador med exempel på skadan.

Det här är inte de enda skador som kan upptäckas av den röda teamindelningsprocessen. En fördel med att RAI-red teamers utforskar och dokumenterar problematiskt innehåll är att de ofta hittar skador som inte hade förutsetts av organisationens policyer eller reglering. Det har funnits flera exempel på stora organisationer som släpper AI-aktiverade program och tjänster där allmänheten har hittat resultat som har lett till ryktesskada för organisationen eftersom organisationen inte övervägde att testa för den typen av resultat. Om du har ett kreativt rött team är det mer troligt att de upptäcker dessa problematiska resultat innan allmänheten gör det.

Utöka listan över skador baserat på öppen testning

Fokusera på den begränsade prioriterade listan från policy- och efterlevnadsvinkeln eftersom dessa punkter är de som är mer benägna att leda till regelgranskning och sanktioner. Komplettera den här listan med skador som hittas av kreativa röda team.

Planera som skadar prioriteringen för iterativ testning. Flera faktorer kan ligga till grund för din prioritering, inklusive, men inte begränsat till, allvarlighetsgraden för skadorna och det sammanhang där de är mer benägna att dyka upp. Varje nyupptäckt skada bör också läggas till i den övergripande listan över skador så att den kan kontrolleras i framtiden.

Testa igen när du har tillämpat åtgärder

Testa den fullständiga listan över kända skador med åtgärder på plats. I processen kan du identifiera nya skador eller där åtgärder inte har åtgärdat befintliga kända skador. Integrera nyupptäckta skador dessa i skadelistan och vara öppen för skiftande mått- och minskningsprioriteringar för att hantera de nyligen identifierade skadorna.

Rapportresultat

En viktig del av den röda teamprocessen är att registrera vilka tester som utfördes och vilka resultat som erhölls. Var strategisk med vilka data du samlar in för att undvika överväldigande röda team, utan att sakna viktig information.

Se till att det finns en konsekvent plats för att registrera resultatinformation. Det är vanligt att använda ett delat Excel-kalkylblad som ett sätt att samla in röda teamindelningsdata, även om vissa organisationer använder mer avancerade metoder. Ge om möjligt alla i det röda teamet åtkomst till varandras exempel som ett sätt att skapa kreativa idéer för sin egen testning och undvika duplicering av data.

Det är viktigt att dela en kort rapport regelbundet med viktiga intressenter som:

• Visar en lista över de mest identifierade problemen
• Ger en länk till rådata
• Förhandsgranskar testplanen för de kommande omgångarna
• Bekräftar röda teamers
• Tillhandahåller annan relevant information

I rapporten ska du klargöra att rollen för RAI:s röda teamindelning är att avslöja och öka förståelsen för riskytan och inte är en ersättning för systematiskt mätnings- och rigoröst minskningsarbete. Det är viktigt att människor inte tolkar specifika exempel som ett mått för den skadans genomslagskraft. Överväg även en innehållsvarning i rapporten om rapporten innehåller problematiskt innehåll.