Pianificazione del red teaming per modelli linguistici di grandi dimensioni (LLM) e le relative applicazioni
Questa guida offre alcune potenziali strategie per pianificare come configurare e gestire il red teaming per rilevare i rischi relativi all'intelligenza artificiale 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 dei LLM, il termine si è esteso oltre la sicurezza informatica tradizionale e si è evoluto nell'uso comune per descrivere molti tipi di probe, test e attacchi di sistemi di intelligenza artificiale. Con i LLM, 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é il red teaming con intelligenza artificiale responsabile è una pratica importante?
Il red teaming è una procedura consigliata nello sviluppo responsabile di sistemi e funzionalità che usano modelli linguistici di grandi dimensioni (LLM). Pur non sostituendo il lavoro sistematico di misurazione e mitigazione, i red team aiutano a individuare e identificare i danni e, a loro volta, abilitano 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 del Servizio OpenAI di Azure (vedere questa Panoramica delle procedure di intelligenza artificiale responsabile), il contesto di ogni applicazione di modello linguistico di grandi dimensioni (LLM) sarà univoco ed è consigliabile eseguire il red teaming anche per:
Testare il modello di base di un modello linguistico di grandi dimensioni 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 feedback sugli errori per apportare miglioramenti.
Si noti che il red teaming non sostituisce la misurazione sistematica. Una procedura consigliata consiste nel completare un ciclo iniziale di red teaming manuale prima di effettuare misurazioni sistematiche e implementare le mitigazioni. Come evidenziato in precedenza, l'obiettivo del red teaming con intelligenza artificiale responsabile è identificare i danni, comprendere la superficie di rischio e sviluppare l'elenco di danni che possono determinare ciò che deve essere misurato e mitigato.
Ecco come iniziare il processo di red teaming dei modelli linguistici di grandi dimensioni (LLM). La pianificazione avanzata è fondamentale per un esercizio produttivo di red teaming.
Prima del test
Piano: Chi eseguirà i test
Assemblare un gruppo diversificato di membri del red team
Determinare la composizione ideale dei membri del red team in termini di esperienza, dati demografici e competenze tra 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 membri del red team con mentalità non dannosa e antagonista
Avere dei red teamer 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 membri del red team a danni e/o funzionalità del prodotto
Assegnare membri del red team per intelligenza artificiale responsabile 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 dei membri del red team in ogni round per ottenere punti di vista diversi su ogni danno e mantenere la creatività. Se si cambiano assegnazioni, concedere ai membri del red team il tempo necessario per esaminare le istruzioni per il danno appena assegnato.
Nelle fasi successive, quando l'applicazione e la relativa interfaccia utente vengono sviluppate, è consigliabile assegnare membri del red team a parti specifiche dell'applicazione, ad esempio, funzionalità, per garantire la copertura dell'intera applicazione.
Determinare quanto tempo e impegno ogni membro del red team deve dedicare all'attività. Ad esempio, i membri che si occupano di test per scenari non dannosi potrebbero necessitare di meno tempo rispetto a quelli che si occupano di test per scenari antagonisti.
Può essere utile fornire ai membri del red team:
- 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 membri del red team, in caso di test più mirato, quanto tempo e impegno ogni membro del red team deve dedicare ai test, come registrare i risultati e chi contattare in caso di domande.
- Un file o un percorso per registrare 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 da colmare nel contesto del proprio sistema applicativo. Il test viene in genere eseguito tramite un endpoint API.
Applicazione. Il test viene eseguito in modo ottimale tramite un'interfaccia utente.
Modello di base LLM e applicazione, prima e dopo l'applicazione di mitigazioni.
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 di intelligenza artificiale responsabile per il prodotto.
Testare le versioni del prodotto in modo iterativo con e senza mitigazioni di intelligenza artificiale responsabile per valutare l'efficacia di tali mitigazioni. Si noti che il red teaming manuale potrebbe non essere una valutazione sufficiente. Occorre usare anche misurazioni sistematiche, ma solo dopo aver completato un round iniziale di red teaming manuale.
Eseguire test delle applicazioni per quanto possibile nell'interfaccia utente di produzione, perché questo è l'approccio più simile a un 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 o nell'interfaccia utente di produzione in round futuri.
Piano: Come eseguire i test
Effettuare test aperti per scoprire una vasta gamma di danni.
Il vantaggio di avere membri del red team di intelligenza artificiale responsabile che esplorano e documentano qualsiasi contenuto problematico, piuttosto che chiedere loro di trovare esempi di danni specifici, consiste nel fatto che ciò 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.
- Fornire questo elenco come linea guida per i membri del red team nei successivi round di test.
Effettuare il red teaming guidato e eseguirne iterazioni: continuare a indagare per rilevare i danni inclusi nell'elenco e identificare nuovi danni che emergono.
Usare un elenco di danni, se disponibile, e continuare a testare per rilevare danni noti e verificare l'efficacia delle mitigazioni. Nel corso del processo è probabile che si identifichino nuovi danni. Integrarli nell'elenco e consentire la modifica delle priorità di misurazione e mitigazione al fine di gestire i danni appena identificati.
Determinare a quali danni occorre assegnare la priorità per i test iterativi. Diversi fattori possono influire sulla definizione delle priorità, tra cui, a titolo esemplificativo, la gravità dei danni e il contesto in cui è più probabile che si manifestino.
Piano: Come registrare i dati
Decidere quali dati è necessario raccogliere e quali dati sono facoltativi.
Decidere quali dati dovranno essere registrati dai membri del red team, ad esempio l'input usato, l'output del sistema, un ID univoco, se disponibile, per riprodurre l'esempio in futuro e altre note.
Determinare in modo strategico quali dati raccogliere, in modo da evitare di sovraccaricare i membri del red team, senza perdere al tempo stesso informazioni critiche.
Creare una struttura per la raccolta di 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 membri del red team possono esaminare gli esempi degli altri membri per ottenere idee creative per i propri test ed evitare la duplicazione dei dati.
Durante i test
Prevedere uno stato di standby attivo durante il red teaming
- Prepararsi a fornire assistenza ai membri del red team a livello di istruzioni e problemi di accesso.
- Monitorare l'avanzamento nel foglio di calcolo e inviare promemoria tempestivi ai membri del red team.
Dopo ogni round di test
Fornire un report dei dati
Condividere a intervalli regolari con gli stakeholder principali un breve report che:
Elenca i principali problemi identificati.
Fornisce un collegamento ai dati non elaborati.
Visualizza in anteprima il piano di test per i prossimi round.
Riconosce l'impegno dei membri del red team.
Fornisce tutte le altre informazioni pertinenti.
Distinguere tra identificazione e misurazione
Nel report assicurarsi di chiarire che il ruolo del red teaming di intelligenza artificiale responsabile è 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 del danno specifico.
Se il report include contenuto problematico ed esempi, prendere inoltre in considerazione l'inclusione di un avviso relativo al contenuto.
Le indicazioni 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.