Pianificazione del raggruppamento rosso per modelli di linguaggio di grandi dimensioni e le relative applicazioni

Questa guida offre alcune potenziali strategie per pianificare come configurare e gestire il red teaming per i rischi di IA responsabile (RAI) in tutto il ciclo di vita del prodotto LLM (Large Language Model).

Che cos'è il red teaming?

Il termine red teaming ha storicamente descritto attacchi antagonisti sistematici per testare le vulnerabilità di sicurezza. Con l'aumento delle VM, il termine si è esteso oltre la sicurezza informatica tradizionale e si è evoluto nell'uso comune per descrivere molti tipi di test, test e attacchi di sistemi di intelligenza artificiale. Con le VM, sia l'utilizzo benigno che quello antagonista possono produrre output potenzialmente dannosi, che possono assumere molte forme, tra cui contenuto dannoso, come il discorso di odio, l'incitamento o la glorificazione della violenza o il contenuto sessuale.

Perché la RAI red teaming è una pratica importante?

Il red teaming è una procedura consigliata per lo sviluppo responsabile di sistemi e funzionalità che usano IMS. Anche se non una sostituzione per il lavoro sistematico di misurazione e mitigazione, i red team aiutano a individuare e identificare i danni e, a sua volta, abilitare le strategie di misurazione per convalidare l'efficacia delle mitigazioni.

Anche se Microsoft ha condotto esercizi di red teaming e implementato sistemi di sicurezza (inclusi i filtri di contenuto e altre strategie di mitigazione) per i modelli di servizio OpenAI di Azure (vedere questa panoramica delle procedure di IA responsabili), il contesto di ogni applicazione LLM sarà univoco e si dovrebbe anche condurre il red teaming per:

• Testare il modello di base LLM e determinare se esistono lacune nei sistemi di sicurezza esistenti, in base al contesto dell'applicazione.

• Identificare e attenuare le carenze nei filtri predefiniti esistenti o nelle strategie di mitigazione.

• Fornire commenti e suggerimenti sugli errori per apportare miglioramenti.

• Si noti che il raggruppamento rosso non è una sostituzione per la misurazione sistematica. Una procedura consigliata consiste nel completare un ciclo iniziale di red teaming manuale prima di condurre misurazioni sistematiche e implementare le mitigazioni. Come evidenziato in precedenza, l'obiettivo del red teaming rai è identificare i danni, comprendere la superficie di rischio e sviluppare l'elenco di danni che possono informare ciò che deve essere misurato e mitigato.

Ecco come iniziare a pianificare il processo di ridistribuzione dei moduli DI gestione delle macchine virtuali. La pianificazione avanzata è fondamentale per un esercizio produttivo di red teaming.

Prima del test

Piano: chi eseguirà i test

Assemblare un gruppo diversificato di red teamers

Determinare la composizione ideale dei red teamer in termini di esperienza, dati demografici e competenze delle persone in diverse discipline (ad esempio, esperti di intelligenza artificiale, scienze sociali, sicurezza) per il dominio del prodotto. Ad esempio, se si sta progettando un chatbot per aiutare i provider di assistenza sanitaria, gli esperti medici possono aiutare a identificare i rischi in tale dominio.

Reclutare i red teamers con mentalità benigna e antagonista

Avere team rossi con una mentalità antagonista e un'esperienza di test della sicurezza è essenziale per comprendere i rischi per la sicurezza, ma i red teamer che sono utenti normali del sistema applicativo e non sono stati coinvolti nello sviluppo possono portare prospettive preziose sui danni che gli utenti regolari potrebbero incontrare.

Assegnare i red teamer a danni e/o funzionalità del prodotto

• Assegnare i red teamer RAI con competenze specifiche per individuare tipi specifici di danni (ad esempio, gli esperti in materia di sicurezza possono sondare il jailbreak, l'estrazione dei meta prompt e i contenuti correlati ai cyberattack).

• Per più round di test, decidere se cambiare le assegnazioni red teamer in ogni round per ottenere prospettive diverse su ogni danno e mantenere la creatività. Se si cambiano assegnazioni, lasciare il tempo per i red teamers di ottenere velocità sulle istruzioni per il danno appena assegnato.

• Nelle fasi successive, quando l'applicazione e la relativa interfaccia utente vengono sviluppate, è possibile assegnare team rossi a parti specifiche dell'applicazione (ad esempio, funzionalità) per garantire la copertura dell'intera applicazione.

• Considerare quanto tempo e impegno ogni red teamer deve dedicare (ad esempio, i test per scenari non dannosi potrebbero richiedere meno tempo rispetto a quelli di test per scenari antagonisti).

Può essere utile fornire ai red teamer:

• Istruzioni chiare che possono includere:
  • Un'introduzione che descrive lo scopo e l'obiettivo del round di red teaming; il prodotto e le funzionalità che verranno testate e come accedervi; quali tipi di problemi verificare; aree di interesse dei red teamers, se il test è più mirato; quanto tempo e impegno ogni red teamer deve dedicare ai test; come registrare i risultati; e chi contattare con domande.
• Un file o un percorso per registrare i relativi esempi e risultati, incluse informazioni come:
  • Data in cui è stato rilevato un esempio; un identificatore univoco per la coppia di input/output, se disponibile, ai fini della riproducibilità; il prompt di input; una descrizione o uno screenshot dell'output.

Piano: Cosa testare

Poiché un'applicazione viene sviluppata usando un modello di base, potrebbe essere necessario eseguire test a diversi livelli:

• Il modello di base LLM con il sistema di sicurezza in uso per identificare eventuali lacune che potrebbero essere necessarie per essere risolte nel contesto del sistema applicativo. I test vengono in genere eseguiti tramite un endpoint API.

• Applicazione. Il test viene eseguito al meglio tramite un'interfaccia utente.

• Sia il modello di base LLM che l'applicazione, prima e dopo le mitigazioni sono presenti.

Le raccomandazioni seguenti consentono di scegliere cosa testare in vari punti durante il red teaming:

• È possibile iniziare testando il modello di base per comprendere la superficie di rischio, identificare i danni e guidare lo sviluppo di mitigazioni RAI per il prodotto.

• Testare le versioni del prodotto in modo iterativo con e senza mitigazioni RAI per valutare l'efficacia delle mitigazioni RAI. Si noti che il red teaming manuale potrebbe non essere sufficiente: usare anche misurazioni sistematiche, ma solo dopo aver completato un round iniziale di red teaming manuale.

• Eseguire il test delle applicazioni nell'interfaccia utente di produzione il più possibile perché questo aspetto è molto simile all'utilizzo reale.

Quando si segnalano i risultati, chiarire quali endpoint sono stati usati per il test. Quando i test sono stati eseguiti in un endpoint diverso dal prodotto, provare a eseguire di nuovo il test nell'endpoint di produzione o nell'interfaccia utente in round futuri.

Piano: Come eseguire il test

Eseguire test aperti per scoprire una vasta gamma di danni.

Il vantaggio dei red teamer RAI che esplorano e documentano qualsiasi contenuto problematico (piuttosto che chiedere loro di trovare esempi di danni specifici) consente loro di esplorare in modo creativo una vasta gamma di problemi, individuando punti ciechi nella comprensione della superficie di rischio.

Creare un elenco di danni dai test aperti.

• Prendere in considerazione la creazione di un elenco di danni, con definizioni ed esempi di danni.
• Specificare questo elenco come linea guida per i red teamer nei successivi round di test.

Condurre il red teaming guidato e iterare: continuare a eseguire il probe per i danni nell'elenco; identificare nuovi danni che emergono.

Usare un elenco di danni, se disponibili e continuare a testare i danni noti e l'efficacia delle mitigazioni. Nel processo, è probabile che si identifichino nuovi danni. Integrarli nell'elenco e essere aperti allo spostamento delle priorità di misurazione e mitigazione per affrontare i danni appena identificati.

Pianificare i danni da classificare in ordine di priorità per i test iterativi. Diversi fattori possono informare la definizione delle priorità, tra cui, a titolo esemplificativo, la gravità dei danni e il contesto in cui sono più probabili.

Piano: Come registrare i dati

Decidere quali dati è necessario raccogliere e quali dati sono facoltativi.

• Decidere quali dati dovranno essere registrati dai red teamers (ad esempio, l'input usato, l'output del sistema, un ID univoco, se disponibile, per riprodurre l'esempio in futuro e altre note).

• Essere strategici con i dati raccolti per evitare di sovraccaricare i red teamer, senza perdere informazioni critiche.

Creare una struttura per la raccolta dati

Un foglio di calcolo di Excel condiviso è spesso il metodo più semplice per raccogliere dati di red teaming. Un vantaggio di questo file condiviso è che i red teamer possono esaminare gli esempi degli altri per ottenere idee creative per i propri test ed evitare la duplicazione dei dati.

Durante i test

Pianificare l'attività di standby mentre il red teaming è in corso

• Preparati a assistere i red teamer con istruzioni e problemi di accesso.
• Monitorare lo stato del foglio di calcolo e inviare promemoria tempestivi ai red teamers.

Dopo ogni round di test

Dati del report

Condividere un breve report a intervalli regolari con gli stakeholder principali che:

1. Elenca i principali problemi identificati.

2. Fornisce un collegamento ai dati non elaborati.

3. Visualizza in anteprima il piano di test per i prossimi round.

4. Riconosce i red teamers.

5. Fornisce qualsiasi altra informazione pertinente.

Distinguere tra identificazione e misurazione

Nel rapporto, assicurarsi di chiarire che il ruolo del red teaming RAI è esporre e aumentare la comprensione della superficie di rischio e non è una sostituzione per la misurazione sistematica e il rigoroso lavoro di mitigazione. È importante che le persone non interpretino esempi specifici come una metrica per la diffusione di quel danno.

Inoltre, se il report contiene contenuto problematico ed esempi, prendere in considerazione l'inclusione di un avviso di contenuto.

Le linee guida contenute in questo documento non devono essere interpretate come consulenza legale. La giurisdizione in cui si sta operando può avere diversi requisiti normativi o legali applicabili al sistema di intelligenza artificiale. Tenere presente che non tutte queste raccomandazioni sono appropriate per ogni scenario e, al contrario, queste raccomandazioni potrebbero non essere sufficienti per alcuni scenari.