notizia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Rapporto sul cuore della macchina

Editore: Du Wei, Zenan

Si può dire che la sicurezza dei modelli di grandi dimensioni abbia “ampio margine di miglioramento”.

Il guru dell'intelligenza artificiale Andrej Karpathy è qui per divulgare nuovamente la conoscenza scientifica. Questa volta il tema è ".Utilizzo di token speciali per eseguire attacchi di tipo SQL injection su LLM」。

Il cosiddetto attacco SQL injection è una tecnologia di attacco di rete. L'aggressore induce il database backend a eseguire istruzioni SQL dannose inserendole nei campi di input dell'applicazione. Questo tipo di attacco in genere sfrutta la gestione impropria dell'input dell'utente da parte dell'applicazione, ad esempio il filtraggio o l'escape non corretto dell'input, consentendo all'aggressore di accedere, modificare o addirittura eliminare i dati nel database.

A causa della crescente consapevolezza delle persone in materia di sicurezza, al momento l'SQL injection non dovrebbe verificarsi nella maggior parte dei prodotti software.

Ma nel mondo dei modelli di grandi dimensioni tutto è ancora agli inizi. Il tokenizzatore LLM è responsabile dell'analisi di token speciali (come <|endoftext|> e così via) nella stringa di input. Sebbene ciò possa sembrare conveniente, può portare, nella migliore delle ipotesi, a valutazioni errate e, nel peggiore, a una vulnerabilità della sicurezza LLM, equivalente a un attacco SQL injection.

È importante notare qui: le stringhe di input dell'utente sono dati non attendibili.

Nell'iniezione SQL, puoi utilizzare l'attacco "DROP TABLE" per violare il codice errato. Lo stesso problema verrà riscontrato in LLM. Il codice errato analizzerà il descrittore del token speciale della stringa nel token speciale effettivo, confondendo la rappresentazione dell'input e impedendo a LLM di distribuire i modelli di chat.

Di seguito è riportato un esempio che utilizza l'attuale tokenizzatore Huggingface Llama 3 predefinito.

Come puoi vedere, si verificano contemporaneamente due situazioni non intuitive:

• Il token <|begin_of_text|> è (128000) aggiunto all'inizio della sequenza
• <|end_of_text|> token (128001) viene analizzato dalla stringa e viene inserito il token speciale. Ora il testo (probabilmente proveniente dall'utente) può essere confuso con il protocollo token e causare la mancata distribuzione di LLM, con conseguente output indefinito.

Pertanto, Karpathy consiglia di utilizzare sempre due flag aggiuntivi per le operazioni di tokenizzazione, disabilitando add_special_tokens=False e split_special_tokens=True e aggiungendo tu stesso token speciali nel codice. Pensava che la denominazione delle due opzioni avrebbe creato un po' di confusione. Per il modello di chat, puoi anche utilizzare il modello di chat apply_chat_template.

Facendo quanto sopra, puoi ottenere qualcosa di più corretto da vedere. Ad esempio, <|end_of_text|> viene ora trattato come qualsiasi altra sequenza di stringhe e suddiviso dal tokenizzatore BPE sottostante proprio come qualsiasi altra stringa.

Karpathy ritiene che le chiamate alla codifica e alla decodifica non dovrebbero mai analizzare stringhe per gestire token speciali e dobbiamo deprecare completamente questa funzionalità. Questi dovrebbero invece essere aggiunti solo in modo esplicito e a livello di codice tramite un percorso di codice separato. In tiktoken, usa sempre encode_ordinary; inhuggingface, è più sicuro usare il flag sopra menzionato. Almeno sii consapevole di questo problema e mantieni sempre visibili i tuoi token e testa il tuo codice.

Karpathy ritiene che queste cose siano molto subdole e scarsamente documentate e stima che circa il 50% del codice ora contenga bug causati dai problemi di cui sopra.

Anche ChatGPT, che è stato sottoposto a rigorosi test prima di lasciare la fabbrica, presenta alcuni strani problemi. Nella migliore delle ipotesi cancella solo il token, nella peggiore confonde LLM in modo indefinito. Karpathy non sapeva cosa stesse succedendo dietro le quinte, ma ChatGPT non poteva inviargli ripetutamente la stringa <|endoftext|>. Quindi presta particolare attenzione qui.

Appena uscito l’articolo di Andrej Karpathy ha subito fatto discutere. Qualcuno ha chiesto: quali misure devono adottare gli sviluppatori LLM per migliorare la sicurezza?

Karpathy pensa che sia facile dirlo, basta contrassegnare sempre le stringhe nel modo "normale", cioè sequenze di byte utf8. Ciò ricorda il principio del "privilegio minimo" in materia di sicurezza: in sostanza, limitando la funzionalità a ciò che è assolutamente necessario, si riduce al minimo la possibilità di conseguenze indesiderate.

Alcuni hanno anche detto: "Ci stiamo già muovendo in questa direzione". Lucas Beyer, autore del modello VLM PaliGemma e scienziato di Google DeepMind, ha affermato che abbiamo migliorato il meccanismo di sicurezza nel nuovo codice di lavoro, il che sarà un po' problematico, soprattutto quando si supporteranno più tokenizzatori, ma nel complesso ne vale la pena. Inoltre rende il codice più semplice.

Alcuni utenti della rete hanno anche chiesto, cosa succede se il codice è corretto, ma viene inserito <|endoftext|> durante l'addestramento dei dati?

Karpathy dice che se il codice è corretto, non succederà nulla. Ma il problema è che gran parte del codice potrebbe non essere corretto, il che può distruggere silenziosamente la visione del mondo del modello di grandi dimensioni.

Cosa ne pensate dei nuovi problemi scoperti da Karpathy?

Contenuto di riferimento:

https://twitter.com/karpathy/status/1823418177197646104