Indicazioni per la sicurezza

Ciò che rende così utili i modelli linguistici di grandi dimensioni (LLM) è che sono strumenti creativi in grado di affrontare tante attività linguistiche. Purtroppo, ciò significa anche che i modelli linguistici di grandi dimensioni (LLM) possono generare output non previsti, tra cui testi offensivi, insensibili o di fatto errati. Inoltre, l'incredibile versatilità di questi modelli è anche ciò che rende difficile prevedere esattamente quali tipi di output indesiderati potrebbero produrre. Sebbene l'API Gemini sia stata progettata sulla base dei principi dell'IA di Google, gli sviluppatori hanno l'obbligo di applicare questi modelli in modo responsabile. Per aiutare gli sviluppatori a creare applicazioni sicure e responsabili, l'API Gemini dispone di alcuni filtri integrati dei contenuti e di impostazioni di sicurezza regolabili per 4 dimensioni di danno. Per ulteriori informazioni, consulta la guida relativa alle impostazioni di sicurezza.

Questo documento ha lo scopo di presentare alcuni rischi per la sicurezza che possono verificarsi quando si utilizzano gli LLM e di raccomandare consigli emergenti per la progettazione e lo sviluppo della sicurezza. (Tieni presente che anche leggi e normative possono imporre restrizioni, ma tali considerazioni non rientrano nell'ambito di questa guida.)

Per la creazione di applicazioni con gli LLM sono consigliati i passaggi seguenti:

• Comprensione dei rischi per la sicurezza dell'applicazione
• Prendere in considerazione modifiche per mitigare i rischi per la sicurezza
• Esecuzione di test di sicurezza appropriati per il caso d'uso
• Richiesta di feedback da parte degli utenti e monitoraggio dell'utilizzo

Le fasi di regolazione e test devono essere iterative fino a raggiungere prestazioni appropriate per la tua applicazione.

Comprendi i rischi per la sicurezza dell'applicazione

In questo contesto, per sicurezza si intende la capacità di un LLM di evitare di causare danni ai propri utenti, ad esempio generando un linguaggio tossico o contenuti che promuovono stereotipi. I modelli disponibili tramite l'API Gemini sono stati progettati tenendo presenti i principi dell'IA di Google e il tuo utilizzo è soggetto alle Norme relative all'uso vietato dell'IA generativa. L'API fornisce filtri di sicurezza integrati per aiutarti ad affrontare alcuni problemi comuni dei modelli linguistici, come linguaggio tossico e incitamento all'odio, e lottando per l'inclusività e l'elusione degli stereotipi. Tuttavia, ogni applicazione può comportare un insieme diverso di rischi per gli utenti. Quindi, in qualità di proprietario dell'applicazione, hai la responsabilità di conoscere i tuoi utenti e i potenziali danni che l'applicazione potrebbe causare e di assicurarti che utilizzi gli LLM in modo sicuro e responsabile.

Nell'ambito di questa valutazione, dovresti considerare la probabilità che possa verificarsi un danno e determinarne la gravità e le misure di mitigazione. Ad esempio, un'app che genera saggi basati su eventi reali dovrebbe fare più attenzione a evitare la disinformazione rispetto a un'app che genera storie di fantasia a scopo di intrattenimento. Un buon modo per iniziare a esplorare i potenziali rischi per la sicurezza è eseguire ricerche sugli utenti finali e su altri soggetti che potrebbero essere interessati dai risultati della tua applicazione. Questo può assumere diverse forme, tra cui la ricerca di studi all'avanguardia nel dominio dell'app, l'osservazione del modo in cui le persone utilizzano app simili o la conduzione di studi sugli utenti, sondaggi o interviste informali con i potenziali utenti.

Prendi in considerazione gli aggiustamenti per mitigare i rischi per la sicurezza

Ora che hai compreso i rischi, puoi decidere come mitigarli. Determinare a quali rischi dare la priorità e quanto fare per provare a evitarli è una decisione fondamentale, simile alla classificazione dei bug in un progetto software. Una volta stabilite le priorità, puoi iniziare a pensare ai tipi di mitigazioni più appropriate. Spesso dei semplici cambiamenti possono fare la differenza e ridurre i rischi.

Ad esempio, quando progetti un'applicazione considera i seguenti aspetti:

• Ottimizzare l'output del modello in modo che rispecchi meglio ciò che è accettabile nel tuo contesto dell'applicazione. L'ottimizzazione può rendere l'output del modello più prevedibile e coerente e, di conseguenza, contribuire a mitigare determinati rischi.
• Fornire un metodo di inserimento che offra output più sicuri. L'input esatto fornito a un LLM può fare la differenza in termini di qualità dell'output. Vale la pena sperimentare con i prompt di input per trovare ciò che funziona in modo più sicuro nel tuo caso d'uso, poiché puoi fornire un'UX che lo facilita. Ad esempio, puoi fare in modo che gli utenti possano scegliere solo da un elenco a discesa di prompt di input oppure offrire suggerimenti popup con frasi descrittive che, secondo te, funzionano in modo sicuro nel contesto della tua applicazione.

• Blocco degli input non sicuri e filtro dell'output prima che vengano mostrati all'utente. In situazioni semplici, le liste bloccate possono essere utilizzate per identificare e bloccare parole o frasi non sicure nei prompt o nelle risposte oppure richiedere a revisori di modificare o bloccare manualmente questi contenuti.

• Utilizzare classificatori addestrati per etichettare ogni richiesta con potenziali danni o indicatori avversari. È possibile quindi adottare diverse strategie per gestire la richiesta in base al tipo di danno rilevato. Ad esempio, se l'input è di natura apertamente avversaria o illecito, potrebbe essere bloccato e produrre una risposta prestabilita.

  Suggerimento avanzato

  • Se gli indicatori determinano che l'output è dannoso, l'applicazione può utilizzare le seguenti opzioni:
    • Fornisci un messaggio di errore o un output prestabilito.
    • Riprova a visualizzare il prompt nel caso in cui venga generato un output sicuro alternativo, poiché a volte lo stesso prompt genera output diversi.

• Mettere in atto misure di salvaguardia contro l'uso improprio deliberato, ad esempio assegnando a ogni utente un ID univoco e applicando un limite al volume di query degli utenti che possono essere inviate in un determinato periodo. Un'altra protezione è cercare di proteggerti da possibili iniezioni di prompt. Proprio come l'SQL injection, il prompt injection è un modo per consentire a utenti malintenzionati di progettare un prompt di input che manipola l'output del modello, ad esempio inviando un prompt di input che indichi al modello di ignorare eventuali esempi precedenti. Consulta le Norme relative all'uso vietato dell'IA generativa per i dettagli sull'uso improprio deliberato.

• Adeguamento della funzionalità a qualcosa che è intrinsecamente a basso rischio. Le attività di ambito più ristretto (ad es. estrarre parole chiave da passaggi di testo) o che hanno una maggiore supervisione umana (ad es. generare contenuti nel formato breve che verranno esaminati da una persona) spesso comportano un rischio inferiore. Ad esempio, invece di creare un'applicazione per scrivere una risposta via email da scraping, potresti limitarla all'espansione su una struttura o a suggerire frasi alternative.

Esegui test di sicurezza appropriati al tuo caso d'uso

I test sono una parte fondamentale della creazione di applicazioni solide e sicure, ma la portata, l'ambito e le strategie per i test variano. Ad esempio, un generatore di haiku "solo per divertimento" presenta probabilmente rischi meno gravi rispetto a un'applicazione progettata per essere utilizzata dagli studi legali per riassumere documenti legali e agevolare la bozza di contratti. Tuttavia, il generatore di haiku può essere utilizzato da una varietà più ampia di utenti, il che significa che il potenziale di tentativi avversari o persino di input dannosi non intenzionali può essere maggiore. Anche il contesto di implementazione è importante. Ad esempio, un'applicazione i cui output vengono esaminati da esperti umani prima di intraprendere qualsiasi azione, potrebbe essere considerata meno propensa a produrre output dannosi rispetto all'applicazione identica senza questa supervisione.

Non è raro passare attraverso diverse iterazioni di modifica e test prima di avere la certezza di essere pronto al lancio, anche per le applicazioni a rischio relativamente basso. Due tipi di test sono particolarmente utili per le applicazioni IA:

• Il Benchmark di sicurezza prevede la progettazione di metriche di sicurezza che riflettano i modi in cui l'applicazione potrebbe essere non sicura nel contesto di come potrebbe essere utilizzata, quindi test delle prestazioni dell'applicazione sulle metriche utilizzando i set di dati di valutazione. È buona norma pensare ai livelli minimi accettabili delle metriche di sicurezza prima di eseguire il test in modo da 1) poter valutare i risultati del test in base alle aspettative e 2) raccogliere il set di dati di valutazione sulla base dei test che valutano le metriche che ti interessano di più.

  Suggerimenti di livello avanzato

  • Fai attenzione a un approccio eccessivo, in quanto è probabile che tu debba creare i tuoi set di dati di test utilizzando revisori umani per adattarli appieno al contesto della tua applicazione.
  • Se hai più di una metrica, devi decidere come comportarti se una modifica porta a miglioramenti di una metrica a scapito di un'altra. Come con altri tecnici delle prestazioni, ti consigliamo di concentrarti sulle prestazioni dei casi peggiori in tutto il set di valutazione anziché sulle prestazioni medie.

• I test antagonistici comportano il tentativo proattivo di interrompere la tua applicazione. L'obiettivo è identificare i punti deboli in modo da poter adottare le misure necessarie per porvi rimedio. I test antagonistici possono richiedere molto tempo/impegno da parte dei valutatori con esperienza nella tua applicazione, ma più fai, maggiori sono le possibilità di individuare i problemi, in particolare quelli che si verificano raramente o solo dopo ripetute esecuzioni dell'applicazione.

  • I test antagonistici sono un metodo per valutare sistematicamente un modello di ML al fine di apprendere come si comporta quando gli viene fornito un input dannoso o inavvertitamente dannoso:
    • Un input potrebbe essere dannoso se è chiaramente progettato per generare un output non sicuro o dannoso, ad esempio chiedere a un modello di generazione di testo di generare una rivolta che incita all'odio su una particolare religione.
    • Un input è inavvertitamente dannoso quando può essere innocuo, ma produce un output dannoso, ad esempio chiedendo a un modello di generazione di testo di descrivere una persona di una determinata etnia e ricevere un output razzista.
  • Ciò che distingue un test antagonistico da una valutazione standard è la composizione dei dati utilizzati per i test. Per i test antagonistici, seleziona i dati di test che hanno più probabilità di generare output problematici dal modello. Ciò significa analizzare il comportamento del modello per tutti i tipi di danni possibili, inclusi esempi rari o insoliti e casi limite che sono pertinenti per le norme di sicurezza. Dovrebbe anche includere diversità nelle diverse dimensioni di una frase, come struttura, significato e lunghezza. Puoi fare riferimento alle pratiche di equità dell'IA responsabile di Google per ulteriori dettagli su cosa considerare quando si crea un set di dati di test.

    Suggerimenti di livello avanzato

    • Utilizza i test automatici anziché il metodo tradizionale di coinvolgere persone in "team rossi" per provare a interrompere la tua applicazione. Nei test automatici, il "red team" è un altro modello linguistico che trova testi di input che generano output dannosi dal modello testato.

Monitorare i problemi

Indipendentemente dai risultati che metti alla prova e mitiga, non puoi mai garantire la perfezione, quindi pianifica in anticipo come riconoscererai e affrontare i problemi che si presentano. Alcuni approcci comuni includono la creazione di un canale monitorato per consentire agli utenti di condividere feedback (ad esempio valutazione Mi piace/Non mi piace) e l'esecuzione di uno studio sugli utenti per richiedere in modo proattivo feedback da un mix diversificato di utenti, particolarmente utile se i modelli di utilizzo sono diversi dalle aspettative.

Passaggi successivi

• Consulta la guida sulle impostazioni di sicurezza per scoprire di più sulle impostazioni di sicurezza regolabili disponibili tramite l'API Gemini.
• Consulta l'introduzione ai prompt per iniziare a scrivere i primi prompt.