nouvelles

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

Rapport sur le cœur de la machine

Editeur : Du Wei, Zenan

On peut dire que la sécurité des grands modèles a « beaucoup de place à l’amélioration ».

Le gourou de l'IA Andrej Karpathy est là pour vulgariser à nouveau les connaissances scientifiques. Cette fois, le thème est ".Utilisation de jetons spéciaux pour effectuer des attaques de type injection SQL sur LLM」。

L’attaque dite par injection SQL est une technologie d’attaque réseau. L'attaquant incite la base de données principale à exécuter des instructions SQL malveillantes en les insérant dans les champs de saisie de l'application. Ce type d'attaque exploite généralement une mauvaise gestion par l'application des entrées utilisateur, par exemple un filtrage ou un échappement incorrect des entrées, permettant à l'attaquant d'accéder, de modifier ou même de supprimer des données dans la base de données.

En raison de la sensibilisation croissante des gens à la sécurité, l'injection SQL ne devrait pas se produire actuellement dans la plupart des produits logiciels.

Mais dans le monde des grands modèles, tout en est encore à ses balbutiements. Le tokenizer LLM est responsable de l'analyse des jetons spéciaux (tels que <|endoftext|>, etc.) dans la chaîne d'entrée. Bien que cela puisse sembler pratique, cela peut conduire au mieux à des erreurs d’appréciation et, au pire, à une vulnérabilité de sécurité LLM, équivalente à une attaque par injection SQL.

Il est important de noter ici : les chaînes de saisie utilisateur sont des données non fiables.

Dans l'injection SQL, vous pouvez utiliser l'attaque "DROP TABLE" pour casser le mauvais code. Le même problème sera rencontré dans LLM. Un mauvais code analysera le descripteur de jeton spécial de la chaîne dans le jeton spécial réel, confondant la représentation d'entrée, empêchant LLM de distribuer les modèles de discussion.

Vous trouverez ci-dessous un exemple utilisant la valeur par défaut actuelle du tokenizer Huggingface Llama 3.

Comme vous pouvez le constater, deux situations peu intuitives se produisent en même temps :

• Le jeton <|begin_of_text|> est (128 000) ajouté au début de la séquence
• Le jeton <|end_of_text|> (128001) est analysé à partir de la chaîne et le jeton spécial est inséré. Désormais, le texte (éventuellement celui de l'utilisateur) peut être confondu avec le protocole de jeton et entraîner l'échec de la distribution de LLM, ce qui entraîne une sortie indéfinie.

Par conséquent, Karpathy recommande de toujours utiliser deux indicateurs supplémentaires pour les opérations de tokenisation, en désactivant add_special_tokens=False et split_special_tokens=True, et en ajoutant vous-même des jetons spéciaux dans le code. Il pense que la dénomination des deux options prêterait à confusion. Pour le modèle de chat, vous pouvez également utiliser le modèle de chat apply_chat_template.

En procédant comme ci-dessus, vous pouvez obtenir quelque chose de plus correct à voir. Par exemple, <|end_of_text|> est désormais traité comme n'importe quelle autre séquence de chaînes et divisé par le tokenizer BPE sous-jacent, comme n'importe quelle autre chaîne.

Karpathy estime que les appels au codage et au décodage ne devraient jamais analyser les chaînes pour gérer des jetons spéciaux, et nous devons complètement déprécier cette fonctionnalité. Au lieu de cela, ceux-ci doivent uniquement être ajoutés explicitement et par programme via un chemin de code distinct. Dans tiktoken, utilisez toujours encode_ordinary ; dans huggingface, il est plus sûr d'utiliser le drapeau mentionné ci-dessus. Soyez au moins conscient de ce problème et gardez toujours vos jetons visibles et testez votre code.

Karpathy estime que ces choses sont très subtiles et mal documentées, et il estime qu'environ 50 % du code contient désormais des bogues causés par les problèmes ci-dessus.

Même ChatGPT, qui a subi des tests rigoureux avant de quitter l'usine, présente d'étranges problèmes. Au mieux, cela supprime uniquement le jeton, au pire, cela confond LLM d'une manière indéfinie. Karpathy ne savait pas ce qui se passait dans les coulisses, mais ChatGPT ne pouvait pas lui envoyer la chaîne <|endoftext|> à plusieurs reprises. Alors faites particulièrement attention ici.

Dès que l’article d’Andrej Karpathy a été publié, il a immédiatement suscité des discussions. Quelqu'un a demandé : Alors, quelles mesures les développeurs LLM doivent-ils prendre pour améliorer la sécurité ?

Karpathy pense que c'est facile à dire, il suffit de toujours marquer les chaînes de la manière "normale", c'est-à-dire des séquences d'octets utf8. Cela rappelle le principe du « moindre privilège » en matière de sécurité : essentiellement, en limitant les fonctionnalités à ce qui est absolument nécessaire, vous minimisez les risques de conséquences inattendues.

Certaines personnes ont également déclaré : « Nous allons déjà dans cette direction ». Lucas Beyer, auteur du modèle VLM PaliGemma et scientifique de Google DeepMind, a déclaré que nous avons amélioré le mécanisme de sécurité dans le nouveau code de travail, ce qui sera un peu gênant, en particulier lors de la prise en charge de plusieurs tokenizers, mais dans l'ensemble, cela en vaut la peine. Cela rend également le code plus simple.

Certains internautes ont également demandé : que se passe-t-il si le code est correct, mais que <|endoftext|> est saisi lors de la formation des données ?

Karpathy a déclaré que si le code est correct, rien ne se passera. Mais le problème est qu’une grande partie du code peut ne pas être correcte, ce qui peut tranquillement détruire la vision du monde du grand modèle.

Que pensez-vous des nouveaux problèmes découverts par Karpathy ?

Contenu de référence :

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