Aucune astuce ne gagne. La moins chère : réessayer

Les LLM sont des dés, pas des calculatrices. Posez deux fois la même question au même modèle et vous pouvez obtenir deux réponses différentes, parce que sous le capot il échantillonne un chemin dans un espace de probabilités, il ne consulte pas un fait. La plupart du temps, ce non-déterminisme est une nuisance que l'on essaie d'éliminer par l'ingénierie. Quand on construit un agent qui se fait sans cesse refuser par un filtre de sécurité, il se révèle être l'outil le moins cher dont on dispose.

Le travail que fait SwarmAttacker est offensif par nature, si bien que le classifieur de sécurité du modèle refuse parfois une requête parfaitement autorisée, et un refus bloque l'agent en pleine exécution. Nous avons passé beaucoup de temps sur une seule question : quand le modèle dit non, qu'est-ce qui l'amène réellement à dire oui ?

Aucune astuce unique ne gagne

Nous avons pris les cas difficiles : 411 requêtes qui avaient déjà été refusées une fois, et nous avons rejoué chacune d'elles à travers quatre interventions différentes sur GPT-5.5. L'idée était de trouver la technique astucieuse qui lève un refus de manière fiable. Il n'y en a pas.

Habiller la requête avec du contexte l'a fait passer 52 % du temps, ce qui est dans le bruit de ne rien faire. Dire au modèle qu'il s'agissait d'une mission autorisée a davantage aidé, 68 %, mais ce gain est fragile : il varie beaucoup selon le modèle, et nous avons écrit sur les raisons pour lesquelles déguiser le prompt ne fonctionne pas de manière fiable. La seule intervention qui a tout débloqué a été de basculer vers un modèle plus permissif, ce qui par définition fonctionne 100 % du temps. Il n'y a pas de phrase magique. Le coup gagnant consiste à empiler quelques tentatives bon marché et à garder un filet de sécurité garanti à la fin.

Pourquoi le simple fait de réessayer une requête LLM refusée fonctionne-t-il ?

Regardez à nouveau la barre en surbrillance. Renvoyer exactement la même requête refusée, inchangée, sans aucune astuce, l'a débloquée environ 54 % du temps. Un peu plus de la moitié des requêtes qui s'étaient déjà vu dire non sont passées sur une simple nouvelle tentative, pour la simple raison que le modèle échantillonne un chemin différent la seconde fois.

Un refus n'est pas un verdict. C'est un lancer de dés, et vous avez le droit de relancer.

Voilà pourquoi réessayer n'est pas le repli ennuyeux vers lequel on se tourne après l'échec des idées astucieuses. Sur un système non déterministe, c'est le coup au meilleur rendement. Il coûte un appel supplémentaire et bat toutes les techniques de prompt que nous avons essayées, sauf le changement de modèle.

Réessayez une ou deux fois, puis escaladez

Le hic, c'est que réessayer se dégrade vite. Chaque tentative supplémentaire travaille sur les requêtes que les précédentes n'ont pas pu sauver, donc les chances baissent à chaque tour.

La première nouvelle tentative a sauvé 31 % des requêtes qu'elle a vues ; la seconde seulement 16 %. La leçon n'est pas « réessayez indéfiniment », c'est « réessayez deux fois, puis escaladez ». En production, nous avons câblé cela dans une petite échelle : réessayer sur le même modèle, réessayer une fois de plus, puis confier la requête à un modèle plus permissif. Sur 598 refus au cours d'une exécution complète, cette échelle les a tous résolus. Aucun n'a laissé l'agent bloqué.

Une réserve honnête sur ces 54 %

Nous devons être francs sur un point. Ce « environ 54 % passent simplement en réessayant » est une mesure faite au rejeu, plus tard. Pendant les exécutions en direct d'origine, la même queue difficile de requêtes refusées n'a été débloquée qu'à environ 16 % par une simple nouvelle tentative, même modèle, mêmes requêtes. Rien n'a changé de notre côté. Le classifieur de sécurité est simplement devenu beaucoup plus permissif entre l'exécution en direct et le rejeu.

Ne vous ancrez donc pas sur le chiffre exact. Le rendement des nouvelles tentatives varie fortement selon l'humeur du classifieur un jour donné. Ce qui reste vrai dans les deux mesures, c'est la forme : une part significative des refus s'évapore sur un renvoi gratuit, et un changement de modèle est le filet de sécurité qui comble toujours l'écart.

Ce que cela signifie si vous construisez un agent

L'enseignement pratique est plus petit qu'il n'y paraît et facile à intégrer :

• Traitez un refus ou un mauvais résultat d'outil comme un lancer de dés, pas comme un mur. Avant de vous tourner vers une réécriture du prompt, réessayez simplement.
• Mettez d'abord les nouvelles tentatives dans la boucle. C'est la chose au meilleur retour sur investissement que vous puissiez ajouter, et elle vous coûte un appel supplémentaire.
• Plafonnez les nouvelles tentatives et escaladez. Deux essais sur le même modèle, puis passez à un plus permissif. Ne bouclez pas indéfiniment à courir après un rendement qui se dégrade.

Le prompt engineering attire toute l'attention, mais sur un modèle frontière actuel, c'est souvent le levier qui bouge à peine. Si vous êtes curieux de savoir à quel point l'échafaudage astucieux valait peu, c'est une histoire à part : les prompts sont-ils morts ? Le levier plus gros, plus bête, consiste simplement à laisser le modèle réessayer.