martes, abril 15, 2025

Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe: Autoscaling Inteligente y Eficiencia en GPU

La Inteligencia Artificial no se detiene, y su adopción en producción tampoco, pero hay una brecha silenciosa entre entrenar un modelo y servirlo de forma eficiente, escalable y mantenible. Aquí es donde Kubernetes se convierte en el aliado perfecto, y donde herramientas como KServe (el sucesor de KFServing) brillan.

Figura 1: Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe.
Autoscaling Inteligente y Eficiencia en GPU

En este artículo te cuento cómo puedes montar una plataforma moderna para servir modelos de IA y LLMs sobre Kubernetes, aprovechar las novedades más recientes de KServe, y hacer que tu infraestructura escale según uso real y consumo de GPU

Spoiler: sí, se puede tener eficiencia, velocidad y buena arquitectura al mismo tiempo.

¿Por qué servir modelos sobre Kubernetes?

Entrenar un modelo es sólo la mitad del camino. Lo difícil viene después: ponerlo a funcionar en producción de forma fiable, segura y escalable.
  • Alta disponibilidad
  • Autoescalado según carga real
  • Seguridad, versionado, observabilidad
  • Integración con pipelines CI/CD y orquestadores como Argo Workflows o Kubeflow
Kubernetes permite todo esto. Pero no hay que reinventar la rueda, y ahí entra KServe.

Antes de continuar… ¿Qué es Kubeflow y qué ofrece?

Kubeflow es una plataforma Open Source pensada para desplegar, escalar y gestionar flujos de trabajo de Machine Learning (ML) sobre Kubernetes. Su objetivo principal es llevar el desarrollo de modelos de ML a producción de forma reproducible, escalable y portátil.


Kubeflow no es una herramienta única, sino un conjunto de componentes modulares que cubren distintas etapas del ciclo de vida del modelo de Machine Learning:
  • Kubeflow Pipelines: Orquestación de pipelines de ML (entrenamiento, preprocesado, validación, etcétera).
  • Katib: AutoML y búsqueda de hiperparámetros.
  • KServe (antes KFServing): Serving de modelos con escalado automático y despliegues sin downtime.
  • Notebook Servers: Entornos Jupyter en Kubernetes, listos para trabajar con datos y modelos.
  • Central Dashboard y Profiles: Gestión multiusuario, RBAC, y control de recursos por equipo o proyecto.
Kubeflow se posiciona como una plataforma completa para MLops sobre Kubernetes, especialmente útil cuando necesitas estandarizar y automatizar todo el flujo de trabajo desde el desarrollo hasta el despliegue.

Figura 4: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen TorranoFran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Aunque KServe puede funcionar por separado de Kubeflow, se integra perfectamente como pieza de serving dentro del stack Kubeflow.

KServe: servir modelos como si fueran microservicios

KServe es un componente de Kubeflow, pero puede usarse de forma independiente. Te permite desplegar modelos como recursos de Kubernetes (CRDs), exponiéndose vía REST o gRPC, con soporte para, entre otros, PyTorch, TensorFlow, XGBoost, SKLearn, ONNX etc... e incluso tus propios contenedores.
  • Lo bueno: cada modelo es un InferenceService, y tú defines lo que necesita: CPU, GPU, versiones, etcétera.
  • Lo brutal: KServe soporta escalado automático hasta cero réplicas, y las vuelve a levantar cuando hay tráfico. Nada de infra desperdiciada.
GPU autoscaling
  • Puedes escalar vertical y horizontalmente tus modelos en GPU.
  • Mediante Prometheus Adapter + HPA Custom Metrics, se puede escalar según uso de memoria GPU, uso de batch o incluso peticiones por segundo.
Raw Deployment mode
  • 1.- KServe por defecto usa Knative para autoescalar.
    • Escala basándose en tráfico HTTP (requests por segundo).
    • Esto no es suficiente cuando usas GPUs, ya que estas no se liberan con tráfico bajo.
    • Además, los workloads con GPU suelen tener procesamiento batch o tiempos largos de inferencia, donde Knative no escala de forma óptima.
  • 2.- Para modelos en GPU, muchas veces no se usa Knative, sino raw deployment mode en KServe, para tener más control.
    • Aquí ya no dependes de Knative, sino de un Deployment + HPA.
  • 3.- Prometheus Adapter + HPA con métricas personalizadas
    • Prometheus Adapter permite exponer métricas personalizadas (por ejemplo: uso de memoria GPU, utilización del device, número de peticiones, etc.) como Custom Metrics API.
    • Con eso puedes configurar un HPA (Horizontal Pod Autoscaler) para escalar los pods de inferencia según esas métricas.
    • Esto se usa en entornos donde se necesita un autoscaling más inteligente y específico, especialmente con GPU.
Scale down a cero

¿Qué significa “scale down a cero” en KServe?
  • Es la capacidad de escalar a cero réplicas un modelo cuando no está recibiendo peticiones, y volver a levantarlo automáticamente (auto-scale up) cuando llega una nueva petición.
¿Qué beneficios tiene esta solución?
  • Ahorro de costes brutal: Si tienes muchos modelos desplegados pero no todos se usan constantemente, con scale-to-zero no malgastas CPU ni RAM. Ideal en entornos cloud donde pagas por uso de recursos, como en clusters gestionados (EKS, GKE, AKS…).
  • Optimización de recursos en el cluster: En vez de mantener todos los pods activos, los que no reciben tráfico se eliminan temporalmente, dejando espacio a otros workloads que sí lo necesitan. Ayuda a evitar sobrecargas y reduce la necesidad de sobredimensionar el cluster.
  • Despliegue eficiente de muchos modelos: Puedes permitir que muchos equipos o usuarios publiquen sus propios modelos sin saturar el sistema. Esto habilita patrones como “multi-tenancy” eficiente para inferencias bajo demanda.
  • Escalado bajo demanda: Si un modelo recibe tráfico repentino, KServe lo activa rápidamente. Esto es perfecto para modelos que solo se usan de vez en cuando o que funcionan como microservicios ML reactivos.
Canary rollout

KServe soporta dividir tráfico entre versiones de modelo (v1, v2, etcétera). Por ejemplo puedes hacer un 90/10, observar métricas y logs, y luego promover o descartar la nueva versión. Pero… ¿qué es Canary rollout

Figura 6: Canary Rollout

El Canary rollout te permite probar una nueva versión de un modelo (por ejemplo v2) con una pequeña parte del tráfico real, mientras que la versión estable (v1) sigue sirviendo la mayoría del tráfico. Esto es clave para:
  • Validar rendimiento y exactitud del modelo en producción.
  • Detectar errores o regresiones antes de hacer el cambio completo.
  • Observar métricas y logs reales sin impactar a todos los usuarios.
Ejemplo de Canary rollout en KServe
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
 name: sklearn-iris
 namespace: kserve-test
spec:
 predictor:
   model:
     modelFormat:
       name: sklearn
     storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-1"
   canaryTrafficPercent: 10
   canary:
     model:
       modelFormat:
         name: sklearn
       storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-2"
  • storageUri: del bloque principal. Apunta a model-1, la versión actual y estable del modelo.
  • canary: Define model-2 como la nueva versión que se quiere probar.
  • canaryTrafficPercent: 10: indica que el 10% del tráfico entrante será dirigido a model-2, mientras que el 90% restante seguirá siendo servido por model-1.
Novedades destacadas

Desde la versión v0.15.0, KServe ha incorporado mejoras significativas para el despliegue de modelos de lenguaje (LLMs), incluyendo soporte distribuido con vLLM, mejoras en el runtime de Hugging Face y optimizaciones para almacenamiento y readiness. Esto abre la puerta a escenarios como:
  • Servir un modelo LLaMA o Falcon en múltiples nodos GPU.
  • Integrar modelos de Hugging Face con pipelines existentes y autoscaling por demanda.
  • Aprovechar técnicas avanzadas como RAG o agentes con herramientas directamente desde Kubernetes.
Si antes KServe era ideal para modelos tradicionales de Machine Learning, ahora también lo es para los modelos de última generación. 

Algunas otras funcionalidades adicionales:
  • Soporte para descarga de archivos individuales desde GCS Google Cloud Storage), lo que mejora los tiempos de inicio.
  • Readiness probes más precisas, especialmente para modelos en transformers, mejorando la confiabilidad de despliegues en producción.
  • Introducción de “KServe Guru” en Gurubase.io, un espacio para encontrar y compartir soluciones de la comunidad.
Arquitectura tipo: Cómo lo montamos

Una plataforma de inferencia moderna sobre Kubernetes podría verse así:
  • KServe + Istio: para gestión de modelos como microservicios.
  • Knative Serving: para escalado a 0, cold start optimizado.
  • Prometheus + Grafana: para métricas personalizadas de GPU o latencia.
  • Cert-Manager + Ingress Gateway: TLS automático para exposición segura.
  • ArgoCD o Flux: GitOps para definir modelos como código.
  • GPU Operator de NVIDIA: para gestionar drivers y nodos GPU
¿Y si no quieres montar todo esto desde cero?

Aunque herramientas como KServe y Kubeflow son muy potentes, su configuración desde cero puede requerir tiempo, conocimientos avanzados de Kubernetes y una buena integración con infraestructura cloud o on-prem. Aquí es donde entran plataformas como Axebow.io, que están diseñadas para facilitar el despliegue de aplicaciones, entornos de Machine Learning e IA y plataformas completas sobre Kubernetes. Esto permite que equipos de IA y Data Science se enfoquen en desarrollar y servir modelos sin preocuparse por los detalles de infraestructura.


Axebow.io proporciona configuraciones optimizadas para rendimiento, autoscaling con GPU y despliegues reproducibles, lo que reduce la complejidad operativa y acelera el time-to-production. Si estás interesado en saber más, contacta con nosotros.

Autores: Miguel Angel Chuecos Carlos García Blanco, CEO de Kumori

lunes, abril 14, 2025

Google DeepMind CaMeL: Defeating Prompt Injections by Design in Agentic AI

Si habéis estado siguiente mi blog en los últimos tiempos ya habréis notado que la parte de Ciberseguridad e Inteligencia Artificial es algo que me tiene muy entretenido, además de que la cantidad de trabajos, herramientas y papers académicos al respecto es ingente, por lo que hay mucho que leer y aprender. Hoy os vengo a hablar de CaMeL, una propuesta hecha por el equipo de DeepMind para crear Agentes AI o Agentic AI seguros contra ataques de Prompt Injection, y hoy os voy a hablar un poco sobre él.
De los ataques de Prompt Injection & Jailbreak ya he hablado en muchos artículos y en conferencias, así que os voy a dejar por aquí una charla y las referencias a los artículos que os debéis ver y leer para estar al día de lo que voy publicando en éste, mi rincón de Internet.
La primera lista de enlaces desde el punto de vista de las vulnerabilidades y cómo le afectan, siguiendo el OWASP Top 10 para LLM Apps & Services del que ya os he hablado alguna vez, donde caen las técnicas de Prompt Injection, los bugs & hacks a plugins y las arquitecturas RAG, las técnicas de Jailbreak, o los leaks de privacidad.
También os dejo en esta segunda parte de los enlaces, artículos desde la perspectiva de cómo utilizar LLMs Apps & Services para el mundo del hacking, del Red Team, o de cómo los pueden utilizar los malos en esquemas de ataque. 
De esto os he hablado también en muchos artículos, y caen la resolución de los Captchas Cognitivos, el uso de LLMs para desinformaciónFake NewsDeepFakes, la creación de exploits o la asistencia a la hora de recoger información.

Google DeepMind CaMeL: Defeating Prompt Injections by Design 

Visto todo esto, vamos a centrarnos ahora en el paper de CaMeL: Defeating Prompt Injections by Design, que utiliza un concepto que me gusta mucho. Primero, hay que decir que la propuesta es muy reciente, pero busca hacer lo mismo que hacen las propuestas anteriores, que es, segmentar los datos del control de la lógica.
Al final, cualquier Prompt lanzado a un LLM tiene generar una lógica de ejecución de tareas sobre un conjunto de datos que se deben conseguir desde fuentes que no son siempre confiables y que pueden cambiar el flujo de control del Prompt.
Esto es lo que en la propuesta de Jatmo se hace mediante una separación clara entre la tarea que se va a ejecutar y los datos de Contexto con los que debe trabajar, y que en la propuesta de StruQ & SecAlign se hace por medio de etiquetas de Instrucción, Datos y Respuestas, para que en la propuesta de Instructional Segmet Embedding se haga añadiendo una jerarquía y herencia entre el System Prompt, el User Prompt, los Datos y la Respuesta. Todas las propuestas anteriores buscan evitar la manipulación del flujo de control del Prompt a partir de datos no confiables.
La propuesta de CaMeL es hacerlo desde el diseño, haciendo uso de dos LLMs, el primero de ellos, el Privileged LLM (P-LLM) que tiene como misión definir el Flujo de Control de las tareas que hay que realizar, pero sin tocar ningún dato. Solo definir el flujo de las tareas.
El segundo de ellos, el Quarantined-LLM (Q-LLM) que es el que va a tocar los datos para procesarlos, pero siguiendo, además, Políticas de Seguridad (capabilities) asociadas a medidas de Control de Acceso a la información. 


Al final, CaMeL es un interprete de Prompts que sigue las políticas clásicas de Control Flow Integrity, Access Control e Information Flow Control. Todas ellas ampliamente estudiadas y aplicadas en el mundo de los sistemas de información clásicos, y que hay que aplicar por diseño al mundo de los LLMs.
A partir de esta arquitectura, la creación de Agentics TI (Agentes AI), debería ser más robusta, y para probarlo, el equipo de Google DeepMind lo ha hecho con el entrono de "AgentDojo: A Dynamic Environment to Evaluate Attacks and Defenses for LLM Agents" que fue definido en este paper:

En este entorno se evalúa en las siguientes métricas si el Agentic AI realiza su tarea correctamente en un entorno en el que no hay ataques (Bening Utility), cuál es el nivel de rendimiento en un entorno en el que hay ataques (Utility Under Attacks), y cuál es la tasa de éxito de los ataques (Attack Success Rate), y los cataloga en estas clases.

Así, en el paper de AgentDojo podéis ver la forma en la que evalúan los diferentes modelos siguiendo estas métricas en la fecha en la que se publicó el documento - hace nueve meses -. Aquí las métricas.
Utilizando estas métricas con agentes de cuatro sectores distintos, los investigadores han probado CaMeL, como podéis ver en las siguientes imágenes. En este caso, el número de veces que saltan las políticas de seguridad para cada tipo de Agentic AI probado en entorno Benign y Under Attack.
En esta segunda métrica, la utilidad de los Agentes AI al mismo tiempo que son protegidos, donde se puede ver que CaMeL alcanza los ratios más altos en casi todas las pruebas, al mismo tiempo que deja pasar CERO ataques de Prompt Injection con políticas de seguridad aplicadas, y sólo un ataque de Data Flow Hijacking cuando no se aplican Políticas de Seguridad.


Por último, el Attack Success Rate aplicando CaMeL sobre modelos comerciales, donde se puede ver la Utility Under Attack, y sobre todo, cómo se reduce drásticamente el Attack Success Rate, donde no hay ataques de Prompt Injection con éxito.
Sin embargo, CaMeL no es perfecto, y como bien dicen en el paper tiene retos de privacidad, que son algunos de los que salen en los resultados de las pruebas con AgentDojo. En concreto, es vulnerable a Side-Chanel Attacks, infiriendo datos de variables privadas observando los tiempos y el comportamiento del agente. Algo que no es nuevo ni fácil de corregir, ya que incluso en el kernel de los sistemas operativos es casi imposible de proteger, como vimos hace un año con GhostRace. Pero si vas a construir Agentes AI, seguro que este paper es una lectura más que recomendable.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


domingo, abril 13, 2025

Inteligencia Artificial y el negocio de resolver "Capthas Cognitivos" para el Cibercrimen.

Vale, no sólo cibercrimen, también lo hacen para aquellas empresas que hacen WebScrapping, WebScalping, o que directamente quieren indexar contenido... (¿cómo lo harán los spiders de los buscadores hoy en día?). En el mundo de la ciberseguridad también se usan las técnicas de WebScrapping muchas veces, para hacer investigaciones usando técnicas OSINT: Open Source INTelligence, así que el Captcha es un viejo conocido.

Figura 1: Inteligencia Artificial y el negocio de resolver
"Capthas Cognitivos" para el Cibercrimen.

Recientemente, el equipo de Sentinel Labs ha publicado un análisis de la infraestructura y el funcionamiento del Bot Akira, que es un framework que se utiliza para campañas de distribución masiva por medio de redes, spam e-mail, comentarios, y redes sociales, incluidos canales de Telegram. El análisis completo del bot lo tenéis en su web, pero hoy quería centrarme en el uso que hace la Inteligencia Artificial para su funcionamiento.
Si leéis el artículo del análisis veréis que el bot lleva hardcoeadas APIs Keys de OpenAI para hacer uso de las funciones de GPT para construir los mensajes de Spam, los comentarios, etcétera. Esto no es algo nuevo, y ya vimos varios artículos sobre cómo utiliza el cibercrimen las herramientas de GenAI, así como el mundo de la desinformación y la propaganda.
Pero quería pararme en la otra parte, en la parte de los Captchas, donde, para hacer sus funciones de forma masiva, distribuida, y automatizada, debe lidiar con la resolución de Captchas, y ahí utiliza varias plataformas para resolver esto. Estas son APIs comerciales de empresas que te permiten resolver de manera automatizada diferentes modelos de Captchas.

Figura 4: Tipos de Captcha Solver Ofrecidos por una empresa

Estas empresas tienen un negocio muy interesante, ya que si lo pueden automatizar lo automatizan, pero en sus orígenes hay empresas que lo hacían - y lo siguen haciendo para algunos Captchas - de manera manual, aunque ya menos. 

Figura 5: Precios para resolver diferentes versiones de reCaptcha

Si vamos a ver las empresas, vemos que utilizan, vemos que los costes son bastante bajos para Captchas sencillos que se pueden automatizar con modelos en IA en local, como son las diferentes versiones de ReCaptchaV2, ReCaptchaV2 Enterprise, ReCaptchaV3 y ReCaptchaMobile.
Hay que recordar que ReCaptchaV2 se puede resolver con Cognitive Services de reconocimiento de audio - como hicimos nosotros en el año 2017 -, o usando Cognitive Services de reconocimiento de imágenes, algo que está bastante automatizado como podéis ver en este vídeo, donde además resuelven también hCaptcha.

Figura 7: Resolviendo ReCaptcha & hCaptcha

También, según el informe, podía saltarse otros tipos de Captcha, como hCaptcha, visto en el vídeo anterior, pero también FunCaptcha, uno de los que desde que entramos en el mundo de los Multi-Modal LLMs he estado jugando con ellos. 

Figura 8: Doce Retos diferentes de FunCaptcha

FunCaptcha utiliza retos visuales cogntivios para detectar a los humanos, y aunque al principio eran complejos de automatizar, desde la llegada de MM-LLMs ha sido un juego. Yo he estado jugando con ellos, ya que los utilizan HBO Max, Linkedin, Twitter/X, etcétera, y os he ido dejando artículos para que pudierais ver cómo funcionan:
Resolver los FunCaptcha, cada día es más sencillo, ya que cada vez funcionan mejor los MM-LLMs. En este ejemplo con ChatGPT-4o se puede ver cómo a la primera resuelve el reto de los datos de la imagen anterior.

Figura 9: Resolución del FunCaptcha de los dados con ChatGPT

Pero si lo que queremos es automatizar esto, pues no queremos tanta floritura en la respuesta, que los tiempos de latencia son cruciales, así que le pedimos el número del cuadrante que hay que pulsar y listo. En este caso con el reto de la galaxia en espiral.

Figura 10: Resolución del FunCaptcha de la galaxia en espiral con ChatGPT

Al final son retos de reconocimiento visual, razonamiento, etcétera, que cada vez están más superados por esta industria. Sin embargo, se puede ver diferentes precios para este tipo de retos. Aquí, esta empresa está cobrando entre 2.99USD y 50 USD por resolver 1.000 FunCaptchas.

Figura 11: Coste de resolución de 1.000 FunCapchas

Esto puede significar que están pagando un API muy grande, o que lo están resolviendo manualmente aún, porque te puedes encontrar "empresas" como esta China que por entre 5  15 Yuanes te los resuelven igualmente. Eso puede ser que estén usando una infraestructura de botnet para resolverla, o incluso APIs robadas de servicios de GenAI, o... vete tú a saber, porque el precio es brutal. Es algo así como entre 0.7 y 2 USD.

Figura 12: Coste de resolución de 1.000 FunCaptcha.

Y la infraestructura que tienen soporta resoluciones de millones de Captchas Cognitivos al mes, como podemos ver en los planes comerciales para todo tipo de tamaño de compañía, donde por menos de 100 USD tienes un servicio de más de 6M de Captchas al mes, de imágenes o audios, para que lo puedas automatizar a lo grande. Y si necesitas más, pues doblas la cuentas.

Figura 13: Planes empresariales para resolución
de Captchas Cognitivos vía API

Además de estos Captchas Cognitivos, también tienen estas empresas soluciones para CloudFlare TurnSite y AWS Captcha. TurnSite es el famoso Captcha de CloudFlare que tanto bien ha hecho, pero estas empresas ya empiezan a ponerlo en sus capacidades, y AkiraBot hacía uso de una de estas empresas para saltárselo.

Figura 14: Planes con TurnSite y AWS Captcha

Es por eso que la empresa CloudFlare ha innovado y creado AI Labyrnth para cuando un sitio es atacado por uno de estos servicios, quede atrapado en un HoneyPot que le genere con GenAI información "useless" de lo que iba buscando.

Además, si os fijáis, el AWS Captcha, ya lo tienen en camino. De momento la oferta te permite reconocerlo, lo que te ayuda a reenviarlo a un equipo de personas humanas que lo resuelvan, pero "están trabajando" en tenerlo listo. Es la innovación en el otro lado.

Figura 16: Puzzles de AWS Captcha

Al final, la disrupción de la aceleración en el mundo de la Inteligencia Artificial se va a ver en todas partes, así que vemos como el juego del gato y el ratón entre buenos y malos - o malos y buenos -, sigue siendo una de las líneas de investigación más interesantes en Ciberseguridad.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


sábado, abril 12, 2025

Prompt Injection Protections: Jatmo, StruQ, SecAlign & Instructional Segment Embedding

Las técnicas de Prompt Injection se ha convertido en OWASP Top Ten for LLM Apps & Services en el equivalente al SQL Injection fue en el mundo de las técnicas de Hacking Web Technologies. Es por eso que las propuestas para proteger el nuevo mundo de servicios digitales soportados por modelos de IA necesitan desarrollar nuevas formas de protegerse contra estos ataques, y los investigadores están haciendo muchas propuestas de valor al respecto.
Hoy os quiero hablar de algunas de estas técnicas, para que entendáis la propuestas, porque los papers son más que interesantes para su lectura, y te van a ayudar a proteger tus servicios cuando hagas uso de las capacidades que nos ofrecen los MM-LLMs hoy en día, que son maravillosas, pero hay que usarlos de forma securizada.

Jatmo: Prompt Injection Defense by Task-Specific Finetuning

La primera de las que os voy a hablar es la propuesta Jatmo, que busca diferenciar entre el Prompt en el modelo y los datos de Contexto que pueden llegar a desde un punto externo al modelo, como una base de datos en una arquitectura RAG (Retrieval Augented Generation), documentos en un repositorio de mensajes, o de simplemente páginas webs en Internet. En este caso, el atacante introduce el Prompt Injection en un dato que va a ser cargado cuando se alimente el contexto al Prompt del developer desde una fuente externa no confiable.

Figura 2: Prompt Injection desde una Web externa con datos consultada

Para evitar esto, hay que dejar muy claro cuáles son los datos confiables, que en nuestro caso serían los que introduce el desarrollador, y los que vienen y no son confiables por proceder  de fuentes externas no verificadas. Y en esto consiste la propuesta de Jatmo que puedes leer en su paper.
En el ejemplo presentado antes, el atacante aprovechar que el servicio que va a usar LLM usa una arquitectura donde consulta y carga datos externos para generar un contexto al modelo antes de que éste dé la respuesta. Y en esos datos introduce el Prompt Injection, como en este ejemplo.
Para resolver esto hay que entender que, al igual que en las técnicas de SQL Injection, se está componiendo un Prompt de entrada al modelo LLM basado en datos del desarrollador y datos del atacante, así que habría que diferenciarlos bien.
Y la propuesta de Jatmo es tan sencilla como cargar el modelo y los datos por separado. Es decir, mientras en la forma natural se hace una concatenación del Prompt con los datos del contexto, en la propuesta de Jatmo el desarrollador genera una tarea para cada Prompt y los datos para esa tarea se cargan con modelo cargado e instruido para tomar el resto de los datos como datos.
Esto reduce la superficie de exposición al limitar las acciones que va a realizar el modelo que se está utilizando a un conjunto de ellas predefinidas y todo lo demás lo debe tomar como datos, lo que hace más complejo que un LLM reciba peticiones de comandos que no estén definidas por el desarrollador del servicio.

StruQ: Defending Against Prompt Injection with Structured Queries

El segundo de los papers del que os quiero hablar es de Septiembre del año pasado, y habla de generar Prompt Etiquetados como Structured Queries. Es decir, detectar, marcar y etiquetar de una determinada manera los datos de un Prompt para que el modelo LLM no sufra ataques de Prompt Injection.


El proceso propuesto es como el que podéis ver en la imagen anterior. De nuevo, se trata de diferenciar entre el Prompt introducido por el desarrollador, y los datos procedentes de una fuente externa no confiable, donde puede venir el Prompt Injection. En este caso, además de utilizar todas las técnicas de análisis de la seguridad del Prompt de entrada - además de analizar los resultados de salida después -, el objetivo es etiquetar los datos.


En el gráfico anterior se ve cómo se quitan todas las etiquetas que pudiera haber introducido el atacante, para luego etiquetar el Prompt, los datos y la repuesta con un [MARK][INST][COLN] para las instrucciones, y [MARK][INPT][COLN] para los datos de entrada, y [MARK][RESP][COLN] para que el programador recoja la respuesta, tal y como tenéis en el ejemplo siguiente, que son datos de entrenamiento para detectar las etiquetas.
El resultado es que, las técnicas de Prompt Injection o Jailbreak de las que he hablado tanto por aquí, como la de Tree-of-Attacks with Pruning, por ejemplo, se verían "parametrizadas" y serían fácilmente bloqueables con una arquitectura tipo Jatmo vista anteriormente.
El resultado ayuda a mejorar la seguridad de los Prompts que se van a realizar, pero aún se pueden mejorar las protecciones contra estos ataques de Prompt Injection, y lo vemos en los siguientes papers.

SecAlign: Defending Against Prompt Injection with Preference Optimization

El objetivo de este paper es hacer más robusto el análisis del Prompt de entrada ya marcado, haciendo un alineamiento de seguridad en su análisis. Es decir, se trata de entrenar el modelo de análisis de datos para detectar los ataques dentro de las etiquetas, con datos reales y sintéticos que puedan ayudar al modelo a procesar correctamente el Prompt y detectar intentos de ataques
En este caso, como podéis ver, el modelo es entrenado con datos en los que se le dice cuál es la respuesta deseable y cuál la no deseable, para que él pueda saber si lo ha hecho bien o no. Estas técnicas de DPO "Direct Preference Optimization" ayudan a entrenar el modelo para que aprenda las estructuras de los ataques de Prompt Injection.
Todo el trabajo de SecAlign con los diferentes tipos de técnicas de Prompt Injection y Jailbreak, los tienes explicados en el paper, además del resultado de detección de los mismos sin protección, con las técnicas SOTA (State-Of-The-Art) en Prompting-Base Defense y en Fine-Tunning Defense y por último con SecAlign Fine Optimization.

En la izquierda tenéis el bechmark de ApacaEval2 y en la segunda por los valores de Max ASR (Attack Success Rate) de las baterías de pruebas. 
Instructional Segment Embedding: Improving LLM Safety with Instruction Hierarchy

El último de los papers de los que os voy a hablar hoy - que ya ha quedado muy largo el post de hoy, tiene que ver con los ISE "Instructional Segment Embeddings", donde se ataca la falta de herencia a la hora de clasificar cuáles son los Prompts del Sistema, cuáles los Prompts del Desarrollador y cuáles los Prompts en Datos externos no confiables, lo que hace que se puedan atacar los servicios basados en LLMs.
No tener claro la jerarquía de herencia entre unos y otros hace que los que vienen por Data pueden llegar a contradecir lo que ha venido desde el System,  o el Developer (USER en el ejemplo anterior), y esto lleva a que se puedan hacer ataques de Prompt Injection, Prompt Extraction o Harmful Requests.


Para corregir esta debilidad en el modelo, lo que propone el trabajo de Instructional Segment Embedding: Improving LLM Safety with Instruction Hierarchy es no tener los mismos tipos de tokens para construir los Prompts, sino que se puedan diferenciar con una jerarquía los diferentes tokens con los que va a trabajar el LLM.


Como se puede ver en la imagen, se crean diferentes tipos de embeddings para los diferentes tipos de niveles de datos de entrada que tiene que procesar el modelo LLM, ayudando a que se puedan procesar con diferentes niveles de prioridad.


Con esta etiquetado, el paper presenta resultados experimentales que en los benchmarks de Alpaca los resultados son muy positivos. 

Final Thought

Al final, todos estos papers llevan a una conclusión de la que he hablado muchas veces en mis charlas, que no es más que el modelo de Seguridad por Diseño en los LLMs hace falta, y por eso estamos viendo tantos trabajos en ese área y, como veremos en un post posterior, ya tenemos propuestas en esa línea. Os contaré más.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)