noticias

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

Informe del corazón de la máquina

Editor: Du Wei, Zenan

Se puede decir que la seguridad de los modelos grandes tiene “mucho margen de mejora”.

El gurú de la IA, Andrej Karpathy, está aquí nuevamente para popularizar el conocimiento científico. Esta vez el tema es ".Uso de tokens especiales para realizar ataques similares a inyecciones SQL en LLM」。

El llamado ataque de inyección SQL es una tecnología de ataque a la red. El atacante engaña a la base de datos backend para que ejecute sentencias SQL maliciosas insertándolas en los campos de entrada de la aplicación. Este tipo de ataque generalmente aprovecha el manejo inadecuado de la entrada del usuario por parte de la aplicación, como no filtrar o escapar adecuadamente la entrada, lo que permite al atacante acceder, modificar o incluso eliminar datos en la base de datos.

Debido a la creciente conciencia de la gente sobre la seguridad, la inyección SQL no debería ocurrir en la mayoría de los productos de software en la actualidad.

Pero en el mundo de los modelos grandes, todo está todavía en pañales. El tokenizador LLM es responsable de analizar tokens especiales (como <|endoftext|>, etc.) en la cadena de entrada. Si bien esto puede parecer conveniente, en el mejor de los casos puede provocar errores de juicio y, en el peor, una vulnerabilidad de seguridad LLM, equivalente a un ataque de inyección SQL.

Es importante tener en cuenta aquí: las cadenas de entrada del usuario son datos que no son de confianza.

En la inyección SQL, puede utilizar el ataque "DROP TABLE" para descifrar código incorrecto. Se encontrará el mismo problema en LLM. El código incorrecto analizará el descriptor de token especial de la cadena en el token especial real, confundiendo la representación de entrada y provocando que LLM no pueda distribuir plantillas de chat.

A continuación se muestra un ejemplo que utiliza el tokenizador predeterminado actual de Huggingface Llama 3.

Como puedes ver, se producen dos situaciones poco intuitivas al mismo tiempo:

• El token <|begin_of_text|> se agrega (128000) al frente de la secuencia
• El token <|end_of_text|> (128001) se analiza a partir de la cadena y se inserta el token especial. Ahora el texto (posiblemente del usuario) se puede confundir con el protocolo del token y provocar que LLM no se distribuya, lo que genera una salida indefinida.

Por lo tanto, Karpathy recomienda usar siempre dos indicadores adicionales para las operaciones de tokenización, deshabilitar add_special_tokens=False y split_special_tokens=True, y agregar tokens especiales usted mismo en el código. Pensó que nombrar las dos opciones sería un poco confuso. Para el modelo de chat, también puedes utilizar la plantilla de chat apply_chat_template.

Al hacer lo anterior, podrá ver algo más correcto. Por ejemplo, <|end_of_text|> ahora se trata como cualquier otra secuencia de cadenas y el tokenizador BPE subyacente la divide como cualquier otra cadena.

Karpathy cree que las llamadas a codificación y decodificación nunca deben analizar cadenas para manejar tokens especiales, y debemos desaprobar esta funcionalidad por completo. En cambio, estos solo deben agregarse explícita y programáticamente a través de una ruta de código separada. En tiktoken, usa siempre encode_ordinary; en huggingface, es más seguro usar la bandera mencionada anteriormente. Al menos tenga en cuenta este problema y mantenga siempre sus tokens visibles y pruebe su código.

Karpathy cree que estas cosas son muy sutiles y están mal documentadas, y estima que alrededor del 50% del código ahora tiene errores causados ​​por los problemas anteriores.

Incluso ChatGPT, que se sometió a rigurosas pruebas antes de salir de fábrica, tiene algunos problemas extraños. En el mejor de los casos, solo elimina el token; en el peor, confunde a LLM de forma indefinida. Karpathy no sabía lo que estaba pasando detrás de escena, pero ChatGPT no pudo enviarle la cadena <|endoftext|> repetidamente. Así que preste especial atención aquí.

Tan pronto como apareció el artículo de Andrej Karpathy, inmediatamente suscitó discusión. Alguien preguntó: Entonces, ¿qué medidas deben tomar los desarrolladores de LLM para mejorar la seguridad?

Karpathy cree que es fácil de decir, simplemente marque siempre las cadenas de la forma "normal", es decir, secuencias de bytes utf8. Esto recuerda el principio de "privilegio mínimo" en seguridad: esencialmente, al limitar la funcionalidad a lo absolutamente necesario, se minimiza la posibilidad de consecuencias no deseadas.

Algunas personas también dijeron: "Ya estamos avanzando en esta dirección". Lucas Beyer, autor del modelo VLM PaliGemma y científico de Google DeepMind, dijo que hemos mejorado el mecanismo de seguridad en el nuevo código de trabajo, lo que será un poco problemático, especialmente cuando admita múltiples tokenizadores, pero en general vale la pena. También hace que el código sea más sencillo.

Algunos internautas también preguntaron, ¿qué sucede si el código es correcto, pero se ingresa <|endoftext|> al entrenar datos?

Karpathy dijo que si el código es correcto, no pasará nada. Pero el problema es que gran parte del código puede no ser correcto, lo que puede destruir silenciosamente la visión del mundo del modelo grande.

¿Qué opinas de los nuevos problemas descubiertos por Karpathy?

Contenido de referencia:

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