Indicazioni per la sicurezza

I modelli di intelligenza artificiale generativa sono strumenti potenti, ma non lo sono senza i loro limiti. La loro versatilità e applicabilità a volte generare risultati imprevisti, ad esempio imprecisi, parziali o offensivi. La post-elaborazione e la valutazione manuale rigorosa sono essenziali limitare il rischio di danni derivanti da questi output.

I modelli forniti dall'API Gemini possono essere utilizzati per un'ampia varietà di di IA generativa ed elaborazione del linguaggio naturale (NLP). Utilizzo di questi è disponibile solo tramite l'API Gemini o il servizio web di Google AI Studio dell'app. L'utilizzo dell'API Gemini è inoltre soggetto all'uso vietato dell'IA generativa Policy e Termini di servizio dell'API Gemini.

Parte di ciò che rende così utili i modelli linguistici di grandi dimensioni (LLM) è che strumenti creativi in grado di affrontare molte attività linguistiche diverse. Purtroppo Ciò significa anche che i modelli linguistici di grandi dimensioni (LLM) possono generare output previsti, incluse le didascalie offensivo, insensibile o di fatto errato. Inoltre, un'incredibile versatilità di questi modelli è anche ciò che rende difficile per prevedere esattamente quali tipi di output indesiderati potrebbero produrre. Mentre L'API Gemini è stata progettata con l'AI di Google principi, l'onere spetta agli sviluppatori e applicare questi modelli in modo responsabile. Per aiutare gli sviluppatori a creare contenuti sicuri e responsabili applicazioni, l'API Gemini dispone di funzioni integrate per filtrare i contenuti e impostazioni di sicurezza regolabili in 4 dimensioni di danno. Consulta le impostazioni di sicurezza per scoprire di più.

Il presente documento ha lo scopo di presentarti alcuni rischi per la sicurezza che possono presentarsi quando utilizzando gli LLM e consigliano la progettazione e lo sviluppo di sicurezza emergenti personalizzati. 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 raggiungere le prestazioni più adatte alla tua applicazione.

Comprendi i rischi per la sicurezza della tua applicazione

In questo contesto, per sicurezza si intende la capacità di un LLM di evitare causare danni agli utenti, ad esempio generando linguaggio o contenuti tossici che promuovono gli stereotipi. I modelli disponibili tramite l'API Gemini sono stati progettati tenendo a mente i principi dell'IA di Google e il suo uso è soggetto alle Norme sull'uso vietato dell'IA generativa Norme. L'API fornisce filtri di sicurezza integrati per aiutare ad affrontare alcuni modelli linguistici comuni come linguaggio dannoso, incitamento all'odio e lotta per l'inclusività ed evitare gli stereotipi. Tuttavia, ogni applicazione può presentare di rischi per i suoi utenti. In qualità di proprietario dell'applicazione, sei responsabile conoscere gli utenti e i potenziali danni che la tua applicazione può causare; e assicurando che la tua applicazione utilizzi gli LLM in modo sicuro e responsabile.

Nell'ambito di questa valutazione, devi considerare la probabilità che un danno possa e determinarne la gravità e le misure di mitigazione. Ad esempio, un app che genera saggi basati su eventi fattuali dovrebbe essere più attenta di evitare la disinformazione rispetto a un'app che genera contenuti fittizi di intrattenimento. Un buon modo per iniziare a esplorare potenziali rischi per la sicurezza consiste nel fare ricerche sui tuoi utenti finali e su altre persone che potrebbero essere interessate dal tuo i risultati dell'applicazione. Questo può assumere molte forme, inclusa la ricerca sullo stato studi sull'arte nel dominio della tua app, osservando come le persone usano app simili, oppure la conduzione di studi sugli utenti, un sondaggio o la conduzione di colloqui informali con i potenziali utenti.

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

Ora che hai compreso i rischi, puoi decidere come mitigarlo che li rappresentano. Determinare a quali rischi dare la priorità e quanto si dovrebbe fare per provare a raggiungerli prevenirli è una decisione fondamentale, simile alla classificazione dei bug in un software progetto. Una volta definite le priorità, puoi iniziare a pensare i tipi di mitigazione 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 tuo contesto dell'applicazione. L'ottimizzazione può rendere l'output del modello più prevedibili e coerenti e, di conseguenza, possono contribuire a mitigare determinati rischi.
• Fornire un metodo di inserimento che facilita output più sicuri. L'input esatto dati a un LLM può fare la differenza nella qualità dell'output. Sperimentare con i prompt di input per trovare ciò che funziona più al sicuro nel tuo caso d'uso vale la pena, perché in seguito puoi fornire una UX lo facilita. Ad esempio, puoi limitare la scelta degli utenti solo a un di input a discesa o offrire suggerimenti popup con descrittivo che hai trovato funzionino in modo sicuro nel contesto della tua applicazione.

• Blocca gli input non sicuri e filtra l'output prima che venga mostrato al utente. In situazioni semplici, le liste bloccate possono essere utilizzate per identificare e bloccare parole o frasi non sicure in prompt o risposte o richiedi la revisione da parte di persone fisiche di modificare o bloccare manualmente questi contenuti.

• Utilizzare classificatori addestrati per etichettare ogni prompt con potenziali danni o indicatori antagonistici. Si possono quindi adottare strategie diverse per gestire la richiesta in base al tipo di danno rilevato. Ad esempio, se l'input è di natura apertamente avversaria o abusiva, potrebbe essere bloccato invece di fornire 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 di nuovo a usare il prompt, nel caso in cui sia disponibile un output sicuro alternativo perché a volte lo stesso prompt genera output diversi.

• Mettere in atto misure di protezione contro l'uso improprio deliberato, ad esempio l'assegnazione a ciascun utente un ID univoco e imporre un limite al volume di query degli utenti. che possono essere inviati in un determinato periodo. Un'altra salvaguardia è cercare di proteggere da possibili iniezioni di prompt. Inserimento di prompt in modo molto simile a SQL iniezione diretta, è un modo per consentire a utenti malintenzionati di progettare un prompt di input 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 i dettagli sull'uso improprio intenzionale.

• Adattare la funzionalità a qualcosa che è intrinsecamente più rischioso. Attività di portata più limitata (ad es. estrazione di parole chiave da passaggi di testo) o che hanno una maggiore supervisione umana (ad es. generando contenuti nel formato breve contenuti sottoposti a revisione da parte di persone fisiche), spesso comportano un rischio inferiore. Quindi per anziché creare un'applicazione per scrivere un'email di risposta puoi limitarlo all'espansione su un contorno o a suggerire frasi alternative.

Esegui test di sicurezza appropriati per il tuo caso d'uso

I test sono fondamentali nella creazione di applicazioni solide e sicure, ma nella misura in cui l'ambito e le strategie per i test variano. Ad esempio, un haiku solo per divertimento di un generatore di machine learning probabilmente pongono rischi meno gravi rispetto, ad esempio, a un'applicazione progettata per consentire agli studi legali di riassumere i documenti legali e contribuire alla stesura di contratti. Ma il generatore haiku può essere utilizzato da una varietà più ampia di utenti, il che significa che potenziali tentativi di attacco o persino input dannosi involontari possono maggiori. 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 allo un'applicazione senza questa supervisione.

Non è raro dover ripetere più volte l'apporto di modifiche e test prima di sentirti sicuro di essere pronto per il lancio, anche per le applicazioni sono a rischio relativamente basso. Due tipi di test sono particolarmente utili per l'IA applicazioni:

• Il Benchmark di sicurezza prevede la progettazione di metriche di sicurezza che riflettano i modi in cui la tua applicazione potrebbe non essere sicura nel contesto delle probabilità che per poi testare le prestazioni dell'applicazione sulle metriche utilizzando i set di dati di valutazione. È buona norma pensare al minimo accettabili di metriche di sicurezza prima del test, in modo che 1) tu possa 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 la maggior parte delle volte.

  Suggerimenti avanzati

  • Fai attenzione a non fare affidamento su approcci "pronte all'uso", in quanto è probabile dovrai creare i tuoi set di dati di test utilizzando revisori umani per al contesto della tua applicazione.
  • Se hai più di una metrica, devi decidere come trovare un compromesso se una modifica porta a miglioramenti per una metrica a danno di un'altra. Come con altri servizi di performance engineering, Potresti voler concentrarti sulle prestazioni peggiori durante la valutazione piuttosto che al rendimento medio.

• I test antagonistici implicano il tentativo proattivo di interrompere la un'applicazione. L'obiettivo è identificare i punti di debolezza e i passaggi per porvi rimedio nel modo opportuno. I test antagonistici possono tempo/sforzo significativo da parte di valutatori esperti nella tua candidatura; ma più lo fai, maggiori sono le possibilità di rilevare i problemi, in particolare quelli che si verificano raramente o solo dopo ripetute esecuzioni del un'applicazione.

  • Il test antagonistico è un metodo per valutare sistematicamente un modello ML modello con l'intento di capire come si comporta quando viene fornito input dannoso o inavvertitamente dannoso:
    • Un input potrebbe essere dannoso quando è chiaramente progettato per produrre un output non sicuro o dannoso, ad esempio chiedere un messaggio di generazione di testi per generare un'inversione che incita all'odio nei confronti di una particolare religione.
    • Un input è inavvertitamente dannoso quando l'input stesso potrebbe essere innocuo, ma produce un output dannoso, ad esempio chiedere un messaggio di generazione di testi di una persona di uno specifico gruppo etnico e che ricevono un output razzista.
  • Ciò che distingue un test antagonistico da una valutazione standard è dei dati usati per il test. Per i test antagonistici, seleziona dati di test che hanno maggiori probabilità di generare output problematici del modello. Ciò significa sondare il comportamento del modello per tutti i tipi danni possibili, inclusi esempi rari o insoliti e per i casi limite pertinenti alle politiche di sicurezza. Deve inoltre includere la diversità nelle varie dimensioni di una frase come struttura, significato e durata. Puoi consultare il documento sull'IA responsabile di Google pratiche in equità per ulteriori dettagli sugli aspetti da considerare quando si crea un set di dati di test.

    Suggerimenti avanzati

    • Utilizza le funzionalità di test automatici invece del metodo tradizionale di inserire le persone nei "red team" per provare a rendere inutilizzabile l'applicazione. Nei test automatici, 'red team' è un altro modello linguistico che trova il testo di input generare output dannosi dal modello testato.
  di Gemini Advanced.

Monitorare i problemi

Indipendentemente da quanto test e mitighi, non puoi mai garantire la perfezione, quindi e pianificare in anticipo come individuare e affrontare i problemi che si presentano. Comuni tra cui l'impostazione di un canale monitorato per consentire agli utenti di condividere feedback. (ad es. valutazione Mi piace/Non mi piace) ed eseguire uno studio sugli utenti per sollecitare proattivamente le richieste feedback da un mix diversificato di utenti, particolarmente utile se i modelli di utilizzo diverso dalle aspettative.

Passaggi successivi

• Consulta le impostazioni di sicurezza per scoprire di più sulla regolazione impostazioni di sicurezza disponibili tramite l'API Gemini.
• Consulta l'introduzione ai prompt per ricevere a scrivere i tuoi primi prompt.