Nachricht

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

Maschinenherzbericht

Herausgeber: Du Wei, Zenan

Bei der Sicherheit großer Modelle gebe es „viel Raum für Verbesserungen“.

KI-Guru Andrej Karpathy ist wieder hier, um wissenschaftliches Wissen bekannt zu machen. Diesmal lautet das Thema: „Verwendung spezieller Token zur Durchführung von SQL-Injection-ähnlichen Angriffen auf LLM」。

Der sogenannte SQL-Injection-Angriff ist eine Netzwerkangriffstechnologie. Der Angreifer bringt die Backend-Datenbank dazu, schädliche SQL-Anweisungen auszuführen, indem er diese in die Eingabefelder der Anwendung einfügt. Bei dieser Art von Angriff wird in der Regel die unsachgemäße Verarbeitung von Benutzereingaben durch die Anwendung ausgenutzt, z. B. indem Eingaben nicht ordnungsgemäß gefiltert oder maskiert werden, sodass der Angreifer auf Daten in der Datenbank zugreifen, diese ändern oder sogar löschen kann.

Aufgrund des zunehmenden Sicherheitsbewusstseins der Menschen sollte SQL-Injection derzeit in den meisten Softwareprodukten nicht vorkommen.

Doch in der Welt der großen Modelle steckt noch alles in den Kinderschuhen. Der LLM-Tokenizer ist für das Parsen spezieller Token (z. B. <|endoftext|> usw.) in der Eingabezeichenfolge verantwortlich. Auch wenn dies praktisch erscheinen mag, kann es im besten Fall zu Fehleinschätzungen und im schlimmsten Fall zu einer LLM-Sicherheitslücke führen, die einem SQL-Injection-Angriff gleichkommt.

Hier ist es wichtig zu beachten: Benutzereingabezeichenfolgen sind nicht vertrauenswürdige Daten.

Bei der SQL-Injection können Sie den „DROP TABLE“-Angriff verwenden, um fehlerhaften Code zu knacken. Das gleiche Problem tritt in LLM auf. Fehlerhafter Code analysiert den speziellen Token-Deskriptor der Zeichenfolge in den tatsächlichen speziellen Token, was die Eingabedarstellung verwirrt und dazu führt, dass LLM keine Chat-Vorlagen verteilen kann.

Unten finden Sie ein Beispiel für die aktuelle Standardeinstellung des Huggingface Llama 3-Tokenizers.

Wie Sie sehen, treten zwei unintuitive Situationen gleichzeitig auf:

• Das <|begin_of_text|>-Token wird (128000) am Anfang der Sequenz hinzugefügt
• <|end_of_text|> token (128001) wird aus der Zeichenfolge analysiert und das spezielle Token wird eingefügt. Jetzt kann Text (möglicherweise vom Benutzer) mit dem Token-Protokoll verwechselt werden und dazu führen, dass LLM die Verteilung fehlschlägt, was zu einer undefinierten Ausgabe führt.

Daher empfiehlt Karpathy, immer zwei zusätzliche Flags für Tokenisierungsvorgänge zu verwenden, add_special_tokens=False und split_special_tokens=True zu deaktivieren und spezielle Token selbst im Code hinzuzufügen. Er dachte, die Benennung der beiden Optionen wäre etwas verwirrend. Für das Chat-Modell können Sie auch die Chat-Vorlage apply_chat_template verwenden.

Wenn Sie die oben genannten Schritte ausführen, können Sie etwas korrekteres sehen. Beispielsweise wird <|end_of_text|> jetzt wie jede andere Zeichenfolgenfolge behandelt und vom zugrunde liegenden BPE-Tokenizer wie jede andere Zeichenfolge aufgebrochen.

Karpathy ist der Ansicht, dass Aufrufe zum Kodieren und Dekodieren niemals Zeichenfolgen analysieren sollten, um spezielle Token zu verarbeiten, und wir müssen diese Funktionalität vollständig ablehnen. Stattdessen sollten diese nur explizit und programmgesteuert über einen separaten Codepfad hinzugefügt werden. Verwenden Sie in Tiktok immer encode_ordinary. In Huggingface ist es sicherer, die oben genannte Flagge zu verwenden. Seien Sie sich dieses Problems zumindest bewusst und halten Sie Ihre Token immer sichtbar und testen Sie Ihren Code.

Karpathy glaubt, dass diese Dinge sehr subtil und schlecht dokumentiert sind, und er schätzt, dass etwa 50 % des Codes mittlerweile Fehler aufweisen, die durch die oben genannten Probleme verursacht werden.

Sogar ChatGPT, das vor Verlassen des Werks strengen Tests unterzogen wurde, weist einige seltsame Probleme auf. Im besten Fall löscht es nur den Token, im schlimmsten Fall verwirrt es LLM auf undefinierte Weise. Karpathy wusste nicht, was sich hinter den Kulissen abspielte, aber ChatGPT konnte ihm die Zeichenfolge <|endoftext|> nicht wiederholt senden. Seien Sie hier also besonders aufmerksam.

Sobald der Artikel von Andrej Karpathy erschien, löste er sofort Diskussionen aus. Jemand fragte: Welche Maßnahmen müssen LLM-Entwickler also ergreifen, um die Sicherheit zu verbessern?

Karpathy meint, es sei einfach zu sagen: Markieren Sie Strings einfach immer auf die „normale“ Art und Weise, also in UTF8-Bytesequenzen. Dies erinnert an das Prinzip der „geringsten Privilegien“ in der Sicherheit – im Wesentlichen minimiert man durch die Beschränkung der Funktionalität auf das absolut Notwendige das Risiko unbeabsichtigter Folgen.

Einige Leute sagten auch: „Wir bewegen uns bereits in diese Richtung.“ Lucas Beyer, Autor des VLM-Modells PaliGemma und Google DeepMind-Wissenschaftler, sagte, dass wir den Sicherheitsmechanismus im neuen Arbeitscode verbessert haben, was insbesondere bei der Unterstützung mehrerer Tokenizer etwas mühsam sein wird, aber insgesamt lohnt es sich. Dadurch wird der Code auch einfacher.

Einige Internetnutzer fragten auch: Was passiert, wenn der Code korrekt ist, aber beim Training der Daten <|endoftext|> eingegeben wird?

Karpathy sagt, dass nichts passieren wird, wenn der Code korrekt ist. Das Problem besteht jedoch darin, dass ein Großteil des Codes möglicherweise nicht korrekt ist, was das Weltbild des großen Modells stillschweigend zerstören kann.

Was halten Sie von den neuen Problemen, die Karpathy entdeckt hat?

Referenzinhalt:

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