Ningún truco gana; lo más barato es solo reintentar

Los LLM son dados, no calculadoras. Hazle al mismo modelo la misma pregunta dos veces y puedes obtener dos respuestas distintas, porque por dentro está muestreando un camino a través de un espacio de probabilidad, no consultando un dato. La mayoría de las veces ese no determinismo es una molestia que intentas eliminar por ingeniería. Cuando estás construyendo un agente al que un filtro de seguridad rechaza una y otra vez, resulta ser la herramienta más barata que tienes.

El trabajo que hace SwarmAttacker es ofensivo por naturaleza, así que el clasificador de seguridad del modelo a veces rechaza una petición perfectamente autorizada, y un rechazo detiene al agente a mitad de ejecución. Dedicamos mucho tiempo a una pregunta: cuando el modelo dice que no, ¿qué es lo que de verdad le hace decir que sí?

Ningún truco único gana

Cogimos los casos difíciles: 411 peticiones que ya habían sido rechazadas una vez, y reprodujimos cada una a través de cuatro intervenciones distintas en GPT-5.5. La idea era encontrar la única técnica ingeniosa que rompe un rechazo de forma fiable. No existe tal técnica.

Vestir la petición con contexto la hizo pasar el 52% de las veces, lo cual está dentro del ruido de no hacer nada. Decirle al modelo que era un encargo autorizado ayudó más, un 68%, pero esa ganancia es frágil: se mueve mucho según el modelo, y hemos escrito sobre por qué disfrazar el prompt no funciona de forma fiable. La única intervención que despejó todo fue cambiar a un modelo más permisivo, que por definición funciona el 100% de las veces. No hay ninguna frase mágica. La jugada ganadora es apilar unos cuantos intentos baratos y guardar una red de seguridad garantizada al final.

¿Por qué funciona simplemente reintentar una petición rechazada por un LLM?

Mira de nuevo la barra resaltada. Reenviar la misma petición rechazada, sin cambios, sin ningún truco encima, la despejó alrededor del 54% de las veces. Algo más de la mitad de las peticiones a las que ya se les había dicho que no pasaron en un reintento simple, por la sencilla razón de que el modelo muestrea un camino diferente la segunda vez.

Un rechazo no es un veredicto. Es una tirada de dados, y tienes permiso para volver a tirar.

Por eso reintentar no es el recurso aburrido al que echas mano después de que las ideas ingeniosas fallan. En un sistema no determinista es la jugada de mayor retorno. Cuesta una llamada extra y supera a todas las técnicas de prompt que probamos, salvo el cambio de modelo.

Reintenta un par de veces, luego escala

La trampa es que reintentar decae rápido. Cada intento adicional trabaja sobre las peticiones que los intentos anteriores no lograron rescatar, así que las probabilidades empeoran en cada ronda.

El primer reintento rescató el 31% de las peticiones que vio; el segundo solo el 16%. La lección no es "reintenta para siempre", es "reintenta dos veces, luego escala". En producción cableamos esto en una pequeña escalera: reintentar en el mismo modelo, reintentar una vez más, luego entregar la petición a un modelo más permisivo. A lo largo de 598 rechazos en una ejecución completa, esa escalera resolvió todos y cada uno. Ninguno dejó al agente atascado.

Una advertencia honesta sobre ese 54%

Tenemos que ser francos sobre una cosa. Ese "aproximadamente el 54% simplemente funciona al reintentar" es una medición de tiempo de reproducción, tomada más tarde. Durante las ejecuciones en vivo originales, esa misma cola difícil de peticiones rechazadas se despejó solo alrededor del 16% en un reintento simple, mismo modelo, mismas peticiones. Nada cambió por nuestra parte. El clasificador de seguridad simplemente derivó hacia mucho más permisivo entre la ejecución en vivo y la reproducción.

Así que no te ancles en la cifra exacta. El beneficio del reintento oscila ampliamente según el humor del clasificador en un día dado. Lo que sigue siendo cierto en ambas mediciones es su forma: una parte significativa de los rechazos se evapora en un reenvío gratis, y un cambio de modelo es la red de seguridad que siempre cierra el hueco.

Qué significa esto si estás construyendo un agente

La conclusión práctica es más pequeña de lo que suena y fácil de incorporar:

• Trata un rechazo o un mal resultado de herramienta como una tirada de dados, no como un muro. Antes de echar mano de una reescritura del prompt, simplemente inténtalo de nuevo.
• Pon los reintentos primero en el bucle. Son lo de mayor retorno que puedes añadir y te cuestan una llamada extra.
• Limita los reintentos y escala. Dos intentos en el mismo modelo, luego salta a uno más permisivo. No hagas un bucle eterno persiguiendo un beneficio que decae.

El prompt engineering se lleva toda la atención, pero en un modelo de frontera actual es a menudo la palanca que apenas se mueve. Si tienes curiosidad por lo poco que valía en realidad el andamiaje ingenioso, esa es su propia historia: ¿están muertos los prompts? La palanca más grande y más tonta es simplemente dejar que el modelo lo intente de nuevo.