νέα

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

Αναφορά Machine Heart

Επιμέλεια: Du Wei, Zenan

Η ασφάλεια των μεγάλων μοντέλων μπορεί να ειπωθεί ότι έχει «πολλά περιθώρια βελτίωσης».

Ο γκουρού της τεχνητής νοημοσύνης Andrej Karpathy είναι εδώ για να εκλαϊκεύσει ξανά τη γνώση της επιστήμης Αυτή τη φορά το θέμα είναι ".Χρήση ειδικών διακριτικών για την εκτέλεση επιθέσεων τύπου SQL injection στο LLM」。

Η λεγόμενη επίθεση SQL injection είναι μια τεχνολογία επίθεσης δικτύου. Ο εισβολέας εξαπατά τη βάση δεδομένων υποστήριξης για να εκτελέσει κακόβουλες δηλώσεις SQL εισάγοντάς τες στα πεδία εισαγωγής της εφαρμογής. Αυτός ο τύπος επίθεσης συνήθως εκμεταλλεύεται τον ακατάλληλο χειρισμό της εισόδου χρήστη από την εφαρμογή, όπως το μη σωστό φιλτράρισμα ή διαφυγή εισόδου, επιτρέποντας στον εισβολέα να έχει πρόσβαση, να τροποποιήσει ή ακόμα και να διαγράψει δεδομένα στη βάση δεδομένων.

Λόγω της αυξανόμενης ευαισθητοποίησης των ανθρώπων για την ασφάλεια, η έγχυση SQL δεν θα πρέπει να εμφανίζεται στα περισσότερα προϊόντα λογισμικού προς το παρόν.

Όμως στον κόσμο των μεγάλων μοντέλων, όλα είναι ακόμα στα σπάργανα. Το Tokenizer LLM είναι υπεύθυνο για την ανάλυση ειδικών διακριτικών (όπως <|endoftext|>, κ.λπ.) στη συμβολοσειρά εισόδου. Αν και αυτό μπορεί να φαίνεται βολικό, μπορεί να οδηγήσει σε λανθασμένες εκτιμήσεις στην καλύτερη περίπτωση και σε μια ευπάθεια ασφαλείας LLM, που ισοδυναμεί με επίθεση SQL injection, στη χειρότερη.

Είναι σημαντικό να σημειωθεί εδώ: οι συμβολοσειρές εισόδου χρήστη είναι μη αξιόπιστα δεδομένα.

Στην ένεση SQL, μπορείτε να χρησιμοποιήσετε την επίθεση "DROP TABLE" για να σπάσετε τον κακό κώδικα. Το ίδιο πρόβλημα θα παρουσιαστεί στο LLM Ο κακός κώδικας θα αναλύσει τον ειδικό περιγραφέα διακριτικού της συμβολοσειράς στο πραγματικό ειδικό διακριτικό, μπερδεύοντας την αναπαράσταση εισόδου, με αποτέλεσμα το LLM να μην μπορεί να διανείμει πρότυπα συνομιλίας.

Παρακάτω είναι ένα παράδειγμα που χρησιμοποιεί την τρέχουσα προεπιλογή του tokenizer huggingface Llama 3.

Όπως μπορείτε να δείτε, δύο μη διαισθητικές καταστάσεις συμβαίνουν ταυτόχρονα:

• Το διακριτικό <|begin_of_text|> προστίθεται (128000) στο μπροστινό μέρος της ακολουθίας
• Το διακριτικό <|end_of_text|> (128001) αναλύεται από τη συμβολοσειρά και εισάγεται το ειδικό διακριτικό. Τώρα το κείμενο (πιθανώς από τον χρήστη) μπορεί να συγχέεται με το πρωτόκολλο διακριτικού και να προκαλέσει την αποτυχία διανομής του LLM, με αποτέλεσμα την απροσδιόριστη έξοδο.

Ως εκ τούτου, η Karpathy συνιστά να χρησιμοποιείτε πάντα δύο επιπλέον σημαίες για λειτουργίες tokenizing, να απενεργοποιείτε το add_special_tokens=False και το split_special_tokens=True και να προσθέτετε μόνοι σας ειδικά tokens στον κώδικα. Σκέφτηκε ότι η ονομασία των δύο επιλογών θα ήταν λίγο μπερδεμένη. Για το μοντέλο συνομιλίας, μπορείτε επίσης να χρησιμοποιήσετε το πρότυπο συνομιλίας apply_chat_template.

Κάνοντας τα παραπάνω, μπορείτε να δείτε κάτι πιο σωστό. Για παράδειγμα, το <|end_of_text|> αντιμετωπίζεται πλέον ως οποιαδήποτε άλλη ακολουθία συμβολοσειρών και διασπάται από τον υποκείμενο BPE tokenizer όπως και κάθε άλλη συμβολοσειρά.

Η Karpathy πιστεύει ότι οι κλήσεις για κωδικοποίηση και αποκωδικοποίηση δεν πρέπει ποτέ να αναλύουν συμβολοσειρές για να χειρίζονται ειδικά διακριτικά και πρέπει να καταργήσουμε εντελώς αυτήν τη λειτουργία. Αντίθετα, αυτά θα πρέπει να προστίθενται ρητά και μέσω προγραμματισμού μέσω μιας ξεχωριστής διαδρομής κώδικα. Στο tiktoken, χρησιμοποιείτε πάντα encode_ordinary στο huggingface, είναι πιο ασφαλές να χρησιμοποιείτε τη σημαία που αναφέρεται παραπάνω. Τουλάχιστον να γνωρίζετε αυτό το πρόβλημα και να διατηρείτε πάντα ορατά τα διακριτικά σας και να δοκιμάζετε τον κωδικό σας.

Ο Karpathy πιστεύει ότι αυτά τα πράγματα είναι πολύ λεπτά και ελάχιστα τεκμηριωμένα, και εκτιμά ότι περίπου το 50% του κώδικα έχει τώρα σφάλματα που προκαλούνται από τα παραπάνω προβλήματα.

Ακόμη και το ChatGPT, το οποίο έχει υποβληθεί σε αυστηρές δοκιμές πριν φύγει από το εργοστάσιο, έχει κάποια περίεργα προβλήματα. Στην καλύτερη περίπτωση διαγράφει μόνο το διακριτικό, στη χειρότερη μπερδεύει το LLM με απροσδιόριστο τρόπο. Ο Karpathy δεν ήξερε τι συνέβαινε στα παρασκήνια, αλλά το ChatGPT δεν μπορούσε να του στείλει τη συμβολοσειρά <|endoftext|> επανειλημμένα. Δώστε λοιπόν ιδιαίτερη προσοχή εδώ.

Μόλις κυκλοφόρησε το άρθρο του Andrej Karpathy, προκάλεσε αμέσως συζήτηση. Κάποιος ρώτησε: Ποια μέτρα λοιπόν πρέπει να λάβουν οι προγραμματιστές LLM για να βελτιώσουν την ασφάλεια;

Ο Karpathy πιστεύει ότι είναι εύκολο να το πεις, απλώς σημειώνεις πάντα τις συμβολοσειρές με τον "κανονικό" τρόπο, δηλαδή, ακολουθίες utf8 byte. Αυτό θυμίζει την αρχή του "λιγότερου προνομίου" στην ασφάλεια - ουσιαστικά, περιορίζοντας τη λειτουργικότητα σε ό,τι είναι απολύτως απαραίτητο, ελαχιστοποιείς την πιθανότητα ακούσιων συνεπειών.

Κάποιοι είπαν επίσης: «Ήδη κινούμαστε προς αυτή την κατεύθυνση». Ο Lucas Beyer, συγγραφέας του μοντέλου VLM PaliGemma και του επιστήμονα του Google DeepMind, είπε ότι έχουμε βελτιώσει τον μηχανισμό ασφαλείας στον νέο κώδικα εργασίας, ο οποίος θα είναι λίγο ενοχλητικός, ειδικά όταν υποστηρίζονται πολλαπλοί tokenizers, αλλά συνολικά αξίζει τον κόπο. Κάνει επίσης τον κώδικα πιο απλό.

Ορισμένοι χρήστες του Διαδικτύου ρώτησαν επίσης, τι συμβαίνει εάν ο κωδικός είναι σωστός, αλλά εισάγεται <|endofext|> όταν τα δεδομένα εκπαίδευσης;

Η Karpathy λέει ότι αν ο κωδικός είναι σωστός, δεν θα γίνει τίποτα. Αλλά το πρόβλημα είναι ότι μεγάλο μέρος του κώδικα μπορεί να μην είναι σωστό, γεγονός που μπορεί να καταστρέψει αθόρυβα την κοσμοθεωρία του μεγάλου μοντέλου.

Πώς πιστεύετε για τα νέα προβλήματα που ανακάλυψε η Karpathy;

Περιεχόμενο αναφοράς:

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