Planera röd teamindelning för stora språkmodeller (LLM: er) och deras program

Den här guiden innehåller några potentiella strategier för att planera hur du konfigurerar och hanterar röda teamindelningar för ansvarsfulla AI-risker (RAI) i produktlivscykeln för storspråksmodellen (LLM).

Vad är röd teamindelning?

Termen red teaming har historiskt beskrivit systematiska angrepp mot säkerhetsrisker. Med ökningen av LLMs har termen utvidgats utöver traditionell cybersäkerhet och utvecklats i vanlig användning för att beskriva många typer av avsökning, testning och angrepp av AI-system. Med LLM kan både godartad och kontradiktorisk användning producera potentiellt skadliga utdata, som kan ta många former, inklusive skadligt innehåll som hatpropaganda, uppvigling eller förhärligande av våld eller sexuellt innehåll.

Varför är RAI red teaming en viktig övning?

Röd teamindelning är en bra metod för ansvarsfull utveckling av system och funktioner med hjälp av LLM:er. Även om de röda teamen inte ersätter systematiskt mätnings- och minskningsarbete hjälper de till att upptäcka och identifiera skador och i sin tur göra det möjligt för mätstrategier att verifiera effektiviteten av minskningar.

Medan Microsoft har genomfört röda teamindelningsövningar och implementerat säkerhetssystem (inklusive innehållsfilter och andra riskreduceringsstrategier) för sina Azure OpenAI Service-modeller (se den här översikten över ansvarsfulla AI-metoder), kommer kontexten för varje LLM-program att vara unik och du bör också utföra röd teamindelning för att:

• Testa LLM-basmodellen och avgöra om det finns luckor i de befintliga säkerhetssystemen, med tanke på programmets kontext.

• Identifiera och åtgärda brister i befintliga standardfilter eller riskreduceringsstrategier.

• Ge feedback om fel för att göra förbättringar.

• Observera att röd teamindelning inte ersätter systematiska mätningar. Bästa praxis är att slutföra en första omgång manuell röd teamindelning innan du utför systematiska mätningar och implementerar åtgärder. Som nämnts ovan är målet med RAI red teaming att identifiera skador, förstå riskytan och utveckla listan över skador som kan informera vad som behöver mätas och mildras.

Så här kommer du igång och planerar processen med red teaming LLM:er. Förhandsplanering är avgörande för en produktiv röd teamindelningsövning.

Före testning

Planera: Vem utför testningen

Sätta ihop en mångfaldig grupp röda teamers

Bestäm den idealiska sammansättningen av red teamers när det gäller människors erfarenhet, demografi och expertis inom olika områden (till exempel experter inom AI, samhällsvetenskap, säkerhet) för din produkts domän. Om du till exempel utformar en chattrobot för att hjälpa vårdgivare kan medicinska experter hjälpa till att identifiera risker i den domänen.

Rekrytera röda team med både godartade och kontradiktoriska tankesätt

Att ha red teamers med ett kontradiktoriskt tänkesätt och säkerhetstestningsupplevelse är viktigt för att förstå säkerhetsrisker, men red teamers som är vanliga användare av ditt programsystem och inte har varit involverade i dess utveckling kan ge värdefulla perspektiv på skador som vanliga användare kan stöta på.

Tilldela red teamers till skador och/eller produktfunktioner

• Tilldela RAI red teamers med specifik expertis för att söka efter specifika typer av skador (till exempel kan experter på säkerhetsämnen söka efter jailbreaks, metapromptextrahering och innehåll som är relaterat till 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 och upprätthålla kreativiteten. Om du byter tilldelningar kan du ge de röda teamen tid att komma igång med instruktionerna för deras nyligen tilldelade skada.

• När programmet och dess användargränssnitt utvecklas senare kanske du vill tilldela red teamers till specifika delar av programmet (dvs. funktioner) för att säkerställa täckningen för hela programmet.

• Tänk på hur mycket tid och arbete varje red teamer bör ägna (till exempel kan de som testar för godartade scenarier behöva mindre tid än de som testar för kontradiktoriska scenarier).

Det kan vara bra att tillhandahålla red teamers med:

• Tydliga instruktioner som kan vara:
  • En introduktion som beskriver syftet med och målet med den givna omgången av röd teaming; Den produkt och de funktioner som kommer att testas och hur du kommer åt dem. vilka typer av problem som ska testas för; red teamers fokusområden, om testningen är mer riktad; hur mycket tid och ansträngning varje red teamer bör spendera på testning; hur du registrerar resultat; och vem som ska kontaktas med frågor.
• En fil eller plats för inspelning av deras exempel och resultat, inklusive information som:
  • 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.

Plan: Vad du ska testa

Eftersom ett program utvecklas med en basmodell kan du behöva testa på flera olika lager:

• LLM-basmodellen med säkerhetssystemet på plats för att identifiera eventuella luckor som kan behöva åtgärdas i samband med ditt programsystem. (Testning görs vanligtvis via en API-slutpunkt.)

• Ditt program. (Testning utförs bäst via ett användargränssnitt.)

• Både LLM-basmodellen och ditt program, före och efter åtgärder finns på plats.

Följande rekommendationer hjälper dig att välja vad du vill testa vid olika tidpunkter under röd teamindelning:

• 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.

• Testa versioner av din produkt iterativt med och utan RAI-åtgärder för att bedöma effektiviteten av RAI-åtgärder. (Observera att manuell röd teamindelning kanske inte är tillräcklig för utvärdering – använd även systematiska mätningar, men först efter att ha slutfört en inledande omgång manuell röd teamindelning.)

• Utför testning av program i produktionsgränssnittet så mycket som möjligt eftersom detta mest liknar 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.

Plan: Så här testar du

Utför öppen testning för att upptäcka en mängd olika skador.

Fördelen med rai red teamers utforska och dokumentera allt problematiskt innehåll (snarare än att be dem att hitta exempel på specifika skador) gör det möjligt för dem att kreativt utforska en mängd olika problem, avslöja blinda fläckar i din förståelse av riskytan.

Skapa en lista över skador från den öppna testningen.

• Överväg att skapa en lista över skador, med definitioner och exempel på skadorna.
• Ange den här listan som en riktlinje för red teamers i senare testomgångar.

Genomför guidad röd teamindelning och iterera: Fortsätt att söka efter skador i listan; identifiera nya skador på ytan.

Använd en lista över skador om de är tillgängliga och fortsätt att testa för kända skador och hur effektiva deras åtgärder är. Under processen kommer du sannolikt att identifiera nya skador. Integrera dessa i listan och var öppen för att flytta mått- och åtgärdsprioriteringar för att åtgärda de nyligen identifierade skadorna.

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.

Plan: Så här registrerar du data

Bestäm vilka data du behöver samla in och vilka data som är valfria.

• Bestäm vilka data de röda teamen behöver registrera (till exempel de indata de använde, systemets utdata, ett unikt ID, om tillgängligt, för att återskapa exemplet i framtiden och andra anteckningar.)

• Var strategisk med vilka data du samlar in för att undvika överväldigande röda team, utan att gå miste om viktig information.

Skapa en struktur för datainsamling

Ett delat Excel-kalkylblad är ofta den enklaste metoden för att samla in röda teamindelningsdata. En fördel med den här delade filen är att red teamers kan granska varandras exempel för att få kreativa idéer för sina egna tester och undvika duplicering av data.

Under testningen

Planera att vara i aktivt vänteläge medan röd teamindelning pågår

• Var beredd på att hjälpa red teamers med instruktioner och åtkomstproblem.
• Övervaka förloppet i kalkylbladet och skicka påminnelser i tid till red teamers.

Efter varje testomgång

Rapportdata

Dela en kort rapport regelbundet med viktiga intressenter som:

1. Visar de vanligaste identifierade problemen.

2. Innehåller en länk till rådata.

3. Förhandsgranskar testplanen för de kommande omgångarna.

4. Bekräftar röda teamers.

5. Innehåller all annan relevant information.

Skilja mellan identifiering och mätning

I rapporten måste du klargöra att RAI:s röda teamindelning är att avslöja och öka förståelsen för riskytan och inte ersätta systematiskt mätnings- och rigoröst minskningsarbete. Det är viktigt att människor inte tolkar specifika exempel som ett mått för den här skadans genomslagskraft.

Om rapporten dessutom innehåller problematiskt innehåll och exempel bör du överväga att inkludera en innehållsvarning.

Vägledningen i detta dokument är inte avsedd att vara, och bör inte tolkas som tillhandahållande av juridisk rådgivning. Den jurisdiktion där du arbetar kan ha olika regler eller juridiska krav som gäller för ditt AI-system. Tänk på att inte alla dessa rekommendationer är lämpliga för varje scenario, och omvänt kan dessa rekommendationer vara otillräckliga för vissa scenarier.