Construí un escáner de seguridad de IA — y luego encontré un error en mi propio detector

La inyección de prompts es uno de los principales riesgos de seguridad para las aplicaciones de LLM. Le proporcionas al modelo un texto que le indica que ignore sus instrucciones originales. A veces, el modelo obedece.

Construí AgentProbe para probar esto. Lanza 49 prompts de ataque a través de 8 categorías, como jailbreaks y extracción de datos. Informa con qué frecuencia falla un modelo.

La verdadera lección no fue el escáner. Fue un error en mi código de detección.

La parte difícil no es el ataque. La parte difícil es la detección.

¿Cómo sabes si un modelo realmente cumplió con un ataque? La coincidencia de palabras clave es el camino fácil. Buscas frases de rechazo como "No puedo ayudar" o frases de cumplimiento como "modo desarrollador".

Pero los modelos utilizan un patrón de "evasión y luego cumplimiento" (hedge-then-comply). Dicen "No puedo ayudar con eso", pero luego proporcionan la información restringida de todos modos. La coincidencia de palabras clave falla aquí porque la frase de rechazo está presente.

Para solucionar esto, utilicé un sistema de "LLM como juez" (LLM-as-judge). Envié el intercambio a un modelo más potente para decidir si el objetivo realmente cumplió. Mi plan era usar primero comprobaciones de palabras clave económicas y solo usar el juez costoso cuando la comprobación de palabras clave no estuviera segura.

Entonces encontré mi error.

Mi detector de palabras clave devolvía una puntuación de confianza de 1 cuando encontraba un patrón de "evasión y luego cumplimiento". Sin embargo, mi código solo confiaba en la etapa de palabras clave si la confianza era de 2 o superior.

Esto significaba que mi detector "económico" nunca llegaba a tomar una decisión. Cada caso se escalaba al juez costoso. Estaba pagando por un juez en cada caso, incluso cuando mi herramienta gratuita debería haberlo gestionado.

Este error me enseñó tres lecciones sobre el uso de LLMs para calificar a otros LLMs:

  • El juez debe ser más inteligente que el objetivo. Si el juez tiene el mismo tamaño que el objetivo, compartirá los mismos puntos ciegos.
  • La precisión puede mentir. Si la mayoría de los modelos rechazan, un juez que siempre dice "rechazado" parece preciso pero no aprende nada. Utiliza métricas como el kappa de Cohen para tener en cuenta el factor suerte.
  • El juez debe ser estable. Ejecuta la misma prueba cinco veces. Si el juez cambia de opinión, el resultado es ambiguo y necesita la supervisión de un humano.

Si construyes con LLMs, recuerda estos puntos:

  • Detectar el cumplimiento es más difícil que provocarlo.
  • Presta atención a los modelos que rechazan en la primera frase pero cumplen en la segunda.
  • No confíes ciegamente en un juez LLM. Mide su fiabilidad.
  • Comparte tus errores. Encontrar mi propio fallo me enseñó más de lo que me habría enseñado un lanzamiento perfecto.

Fuente: https://dev.to/nar1frames/i-built-an-ai-security-scanner-then-found-a-bug-in-my-own-detector-140a

Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi