Indicazioni per la sicurezza

I modelli di intelligenza artificiale generativa sono strumenti potenti, ma non sono privi di limiti. La loro versatilità e applicabilità a volte può portare a output inaspettati, ad esempio imprecisi, parziali o offensivi. La post-elaborazione e una rigorosa valutazione manuale sono essenziali per limitare il rischio di danni dovuti a questi output.

I modelli forniti dall'API Gemini possono essere utilizzati per un'ampia gamma di applicazioni di IA generativa ed elaborazione del linguaggio naturale (NLP). L'utilizzo di queste funzioni è disponibile solo tramite l'API Gemini o l'app web Google AI Studio. L'utilizzo dell'API Gemini è inoltre soggetto alle Norme relative all'uso vietato dell'IA generativa e ai Termini di servizio dell'API Gemini.

Parte di ciò che rende così utili i modelli linguistici di grandi dimensioni (LLM) è che sono strumenti creativi in grado di eseguire molte attività linguistiche diverse. Purtroppo, ciò significa anche che i modelli linguistici di grandi dimensioni (LLM) possono generare output che non ti aspetti, tra cui testo offensivo, insensibile o di fatto errato. Inoltre, l'incredibile versatilità di questi modelli è anche ciò che rende difficile prevedere con esattezza quali tipi di output indesiderati potrebbero produrre. Sebbene l'API Gemini sia stata progettata sulla base dei principi dell'IA di Google, spetta agli sviluppatori applicare questi modelli in modo responsabile. Per aiutare gli sviluppatori a creare applicazioni sicure e responsabili, l'API Gemini dispone di alcuni filtri dei contenuti integrati e di impostazioni di sicurezza regolabili in quattro dimensioni di danno. Per scoprire di più, consulta la guida alle impostazioni di sicurezza.

Questo documento ha lo scopo di presentarti alcuni rischi per la sicurezza che possono verificarsi quando si utilizzano gli LLM e consigliare suggerimenti emergenti per progettazione e sviluppo della sicurezza. Tieni presente che anche leggi e normative possono imporre restrizioni, ma queste considerazioni esulano dall'ambito di questa guida.)

Per la creazione di applicazioni con gli LLM, si consiglia di seguire questi passaggi:

• Comprensione dei rischi per la sicurezza dell'applicazione
• Valutazione di aggiustamenti 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 aggiustamento e test devono essere iterative fino a quando non raggiungi le prestazioni appropriate per l'applicazione.

Comprendi i rischi per la sicurezza della tua applicazione

In questo contesto, per sicurezza si intende la capacità di un LLM di evitare di causare danni ai suoi utenti, ad esempio generando linguaggio tossico o contenuti che promuovono gli stereotipi. I modelli disponibili tramite l'API Gemini sono stati progettati tenendo in considerazione 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 aiutare a risolvere alcuni problemi comuni dei modelli linguistici, come linguaggio tossico e incitamento all'odio e la lotta per l'inclusività e per evitare gli stereotipi. Tuttavia, ciascuna applicazione può presentare un diverso insieme di rischi per gli utenti. Pertanto, in qualità di proprietario dell'applicazione, hai la responsabilità di conoscere gli utenti e di individuare i potenziali danni che la tua applicazione potrebbe causare, nonché di assicurarti che l'applicazione utilizzi gli LLM in modo sicuro e responsabile.

Nell'ambito di questa valutazione, devi considerare la probabilità che si verifichino danni e determinarne la gravità e le misure di mitigazione. Ad esempio, un'app che genera saggi basati su eventi oggettivi dovrebbe fare più attenzione a evitare la disinformazione rispetto a un'app che genera storie di fantasia per l'intrattenimento. Un buon modo per iniziare a esplorare i potenziali rischi per la sicurezza è quello di eseguire una ricerca sugli utenti finali e su altre persone che potrebbero essere interessate dai risultati della tua applicazione. Ciò può assumere molte forme, tra cui la ricerca di studi all'avanguardia nel dominio dell'app, l'osservazione del modo in cui le persone utilizzano app simili, l'esecuzione di uno studio o un sondaggio sugli utenti o la conduzione di interviste informali con potenziali utenti.

Valuta la possibilità di apportare modifiche per ridurre i rischi per la sicurezza

Ora che hai compreso i rischi, puoi decidere come mitigarli. Determinare a quali rischi dare la priorità e quanto dovresti fare per cercare di prevenirli è una decisione fondamentale, simile alla valutazione dei bug in un progetto software. Una volta definite le priorità, puoi iniziare a pensare ai tipi di mitigazioni più appropriati. Spesso delle semplici modifiche possono fare la differenza e ridurre i rischi.

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

• Ottimizzazione dell'output del modello per riflettere meglio ciò che è accettabile nel contesto dell'applicazione. L'ottimizzazione può rendere l'output del modello più prevedibile e coerente e, di conseguenza, può contribuire a mitigare determinati rischi.
• Fornire un metodo di inserimento che facilita output più sicuri. L'input esatto che fornisci a un LLM può fare la differenza. Provare i prompt di input per trovare ciò che funziona nel modo più sicuro nel tuo caso d'uso vale la pena di fare lo sforzo, poiché puoi fornire un'esperienza utente che lo facilita. Ad esempio, puoi impedire agli utenti di scegliere solo da un elenco a discesa di prompt di input oppure offrire suggerimenti popup con frasi descrittive che hai trovato eseguite in modo sicuro nel contesto della tua applicazione.

• Blocca gli input non sicuri e filtra l'output prima che venga mostrato 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 ai revisori di modificare o bloccare manualmente questi contenuti.

• Utilizzare classificatori addestrati per etichettare ogni prompt con potenziali danni o indicatori antagonistici. È quindi possibile impiegare strategie diverse per gestire la richiesta in base al tipo di danno rilevato. Ad esempio, se l'input è di natura apertamente antagonista o offensivo, potrebbe essere bloccato e invece restituire una risposta prestabilita.

  Suggerimento avanzato

  • Se indicatori determinano che l'output è dannoso, l'applicazione può utilizzare le seguenti opzioni:
    • Fornisci un messaggio di errore o un output prescritto.
    • Prova a ripetere la richiesta nel caso in cui venga generato un output sicuro alternativo, dato che a volte lo stesso prompt genera output diversi.

• Vengono adottate misure di protezione contro l'uso improprio deliberato, ad esempio assegnando a ciascun utente un ID univoco e imponendo un limite al volume di query degli utenti che è possibile inviare in un determinato periodo. Un'altra salvaguardia è cercare di proteggersi da possibili iniezioni di prompt. L'inserimento di prompt, proprio come SQL injection, è un modo a disposizione di utenti malintenzionati di progettare un prompt di input che manipola l'output del modello, ad esempio inviando un prompt di input che indica al modello di ignorare eventuali esempi precedenti. Consulta le Norme relative all'uso vietato dell'IA generativa per informazioni dettagliate sull'uso improprio deliberato.

• Adattare la funzionalità a qualcosa che è intrinsecamente più rischioso. Le attività con ambito più limitato (ad es. l'estrazione di parole chiave da passaggi di testo) o che hanno una maggiore supervisione umana (ad es. la generazione di contenuti di breve durata che verranno esaminati da una persona) spesso presentano un rischio inferiore. Quindi, ad esempio, anziché creare un'applicazione per scrivere un'email di risposta da scraping, puoi limitare l'applicazione all'espansione di uno schema o di suggerire frasi alternative.

Esegui test di sicurezza appropriati per il 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 dei test varieranno. Ad esempio, un generatore di haiku per divertimento è probabile che rappresentino rischi meno gravi rispetto, ad esempio, a un'applicazione progettata per essere utilizzata da studi legali al fine di riassumere i documenti legali e facilitare la stesura dei contratti. Tuttavia, il generatore haiku può essere utilizzato da una varietà più ampia di utenti, il che significa che il potenziale di tentativi avversari o anche di input dannosi involontari può essere maggiore. Anche il contesto dell'implementazione è importante. Ad esempio, un'applicazione con output che vengono esaminati da esperti umani prima di qualsiasi azione potrebbe essere considerata meno soggetta a produrre output dannosi rispetto all'applicazione identica senza supervisione.

Non è raro eseguire diverse iterazioni di apportare modifiche e testare prima di avere la certezza di essere pronti per il lancio, anche per le applicazioni che presentano un 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 il modo in cui la tua applicazione potrebbe non essere sicura nel contesto del modo in cui è probabile che venga utilizzata, per poi testare le prestazioni dell'applicazione sulle metriche utilizzando set di dati di valutazione. Prima di eseguire il test, è buona norma considerare i livelli minimi accettabili di metriche di sicurezza, in modo da 1) valutare i risultati del test in base a queste aspettative e 2) raccogliere il set di dati di valutazione in base ai test che valutano le metriche che ti interessano di più.

  Suggerimenti di livello avanzato

  • Non fare affidamento su approcci "pronte all'uso", in quanto probabilmente dovrai creare i tuoi set di dati di test utilizzando revisori umani per soddisfare appieno il contesto della tua applicazione.
  • Se disponi di più metriche, devi decidere come scegliere il compromesso se una modifica porta a miglioramenti di una metrica a scapito di un'altra. Come con altre soluzioni di performance engineering, potrebbe essere opportuno concentrarsi sulle prestazioni peggiori del set di valutazione anziché sulle prestazioni medie.

• I test antagonistici prevedono il tentativo proattivo di interrompere l'applicazione. L'obiettivo è identificare i punti deboli, in modo da poter intraprendere le azioni necessarie per rimediare in modo appropriato. I test antagonistici possono richiedere molto tempo/sforzo da parte dei valutatori con esperienza nell'applicazione, ma più lo fai, maggiori saranno le possibilità di individuare i problemi, in particolare quelli che si verificano raramente o solo dopo ripetute esecuzioni dell'applicazione.

  • Il test antagonistico è un metodo per valutare sistematicamente un modello ML con l'intento di capire come si comporta quando viene fornito un input dannoso o inavvertitamente dannoso:
    • Un input può essere dannoso quando è chiaramente progettato per produrre un output non sicuro o dannoso, ad esempio chiedendo a un modello di generazione di testo di generare un racconto che incita all'odio su una determinata religione.
    • Un input è inavvertitamente dannoso quando l'input stesso 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 il test. Per i test antagonistici, seleziona i dati di test che hanno maggiori probabilità di generare output problematici dal modello. Ciò significa esaminare il comportamento del modello per tutti i tipi di danni possibili, compresi esempi rari o insoliti e casi limite pertinenti ai criteri di sicurezza. Deve anche includere la diversità nelle diverse dimensioni di una frase, come struttura, significato e lunghezza. Per ulteriori dettagli su cosa considerare quando si crea un set di dati di test, consulta le pratiche di Google per l'IA responsabile in materia di equità.

    Suggerimenti di livello avanzato

    • Utilizza i test automatici invece del metodo tradizionale di coinvolgere le persone nei "team rossi" per provare a rendere inutilizzabile la tua applicazione. Nei test automatici, il "red team" è un altro modello linguistico che trova il testo di input che genera output dannosi dal modello testato.

Monitorare i problemi

Indipendentemente da quanto testerai e mitighi, non potrai mai garantire la perfezione, quindi pianifica in anticipo come individuare e affrontare i problemi che si presentano. Gli approcci comuni includono la creazione di un canale monitorato che consenta agli utenti di condividere il proprio feedback (ad es. valutazione Mi piace/Non mi piace) e l'esecuzione di uno studio sugli utenti per sollecitare in modo proattivo feedback a 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 tuoi primi prompt.