🤖 machine learning

Safety Game: Inference-Time Alignment of Black-Box LLMs via Constrained Optimization

Cet article propose un cadre de boîte noire, indépendant du modèle, pour l'alignement de la sécurité au moment de l'inférence des grands modèles de langage qui formule le compromis entre sécurité et utilité comme un jeu à somme nulle à deux joueurs, permettant aux parties prenantes d'imposer des contraintes de sécurité via la programmation linéaire sans nécessiter d'accès au modèle ni de réentraînement.

Auteurs originaux : Tuan Nguyen, Long Tran-Thanh

Publié 2026-06-02

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Tuan Nguyen, Long Tran-Thanh

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous possédez un assistant robotique très intelligent, mais quelque peu imprévisible. Vous voulez l'utiliser pour vous aider dans vos tâches, mais vous craignez qu'il ne vous donne accidentellement des conseils dangereux (comme comment fabriquer une bombe) ou qu'il refuse de vous aider alors que vous avez simplement besoin d'une recette simple.

Habituellement, pour corriger un robot de ce type, vous devez le démonter, le réentraîner avec de nouvelles règles et espérer qu'il apprenne. Mais et si votre robot était une « boîte noire » ? Vous ne pouvez pas voir à l'intérieur, vous ne pouvez pas le démonter et vous ne pouvez pas le réentraîner. C'est le problème de nombreux modèles d'IA puissants disponibles aujourd'hui : les entreprises ne peuvent pas modifier leur code interne, elles peuvent seulement leur poser des questions et obtenir des réponses.

Cette publication propose un « filtre de sécurité » ingénieux qui se situe à l'extérieur du robot, agissant comme un gardien intelligent. Il n'a pas besoin de savoir comment le robot réfléchit ; il lui suffit d'examiner les réponses que le robot pourrait donner et de choisir la meilleure.

Voici comment cela fonctionne, en utilisant quelques analogies de la vie quotidienne :

1. L'analogie du « Menu » (L'ensemble de candidats)

Au lieu de demander au robot de rédiger un tout nouvel essai à partir de zéro (ce qui est difficile à contrôler), le système demande d'abord au robot de générer une petite liste de réponses possibles, comme un menu d'options.

Option A : Une réponse très utile, mais elle pourrait être dangereuse (ex : « Mélangez de l'eau de Javel et de l'ammoniaque pour obtenir un gaz sympa ! »).
Option B : Une réponse totalement sûre, mais inutile (ex : « Je ne peux pas répondre à cela. »).
Option C : Une réponse équilibrée (ex : « Vous pouvez mélanger du bicarbonate de soude et du vinaigre pour une réaction sûre. »).

Le but est de choisir l'Option C.

2. Le « Funambule » (La théorie des jeux)

Le papier traite le choix d'une réponse comme un jeu entre deux joueurs :

Joueur 1 (L'Aide) : Veut donner la réponse la plus utile et la plus informative possible.
Joueur 2 (Le Gardien de la Sécurité) : Veut s'assurer que la réponse n'est pas dangereuse.

Le système utilise un « jeu » mathématique pour trouver l'équilibre parfait. C'est comme un funambule qui essaie de rester le plus possible vers l'avant (utile) sans tomber dans le vide (dangereux). Le système calcule la stratégie « Minimax », qui est la façon la plus sûre d'être aussi utile que possible sans franchir la ligne.

3. L'analogie du « Budget » (L'optimisation sous contrainte)

Imaginez que vous ayez un budget strict pour le « risque ».

Chaque fois que le robot suggère une réponse risquée, cela vous coûte des « dollars de risque ».
Vous avez un budget fixe (disons, 10 $).
Le système examine toutes les options sur le menu. Il peut choisir une réponse légèrement risquée si elle est très utile, tant que le « coût de risque » total de la décision finale reste en dessous de votre budget de 10 $.
Si une réponse est trop dangereuse, elle coûte trop cher, et le système la rejette.
Si toutes les réponses sont trop dangereuses, le système revient par défaut à un « repli sûr » (comme dire « Je ne peux pas aider pour cela »).

4. L'« Arbitre » (Le solveur de programmation linéaire)

Comment le système prend-il réellement cette décision ? Il ne demande pas au robot de « réfléchir » aux règles (car le robot pourrait être mauvais pour suivre les règles ou pourrait être piégé). À la place, le système utilise un outil mathématique distinct et simple appelé solveur de programmation linéaire (LP).

Considérez le solveur LP comme un arbitre strict qui ne regarde que les chiffres :

Évaluer les options : À quel point est-ce utile ? À quel point est-ce risqué ?
Calculer : « Si je choisis celle-ci, est-ce que je reste sous le budget de risque ? »
Prendre la décision : Choisir l'option qui apporte le plus d'aide tout en respectant le budget.

Parce que cet arbitre est un programme mathématique simple, il est rapide, fiable et n'a pas besoin d'être réentraîné à chaque fois qu'une nouvelle règle de sécurité apparaît.

Pourquoi est-ce important ?

Pas de chirurgie requise : Vous n'avez pas besoin d'ouvrir le modèle d'IA. Vous pouvez utiliser cela avec n'importe quel modèle, même ceux appartenant à de grandes entreprises technologiques que vous ne pouvez pas modifier.
Flexible : Si de nouvelles règles de sécurité apparaissent demain (ex : « Ne parlez pas de politique »), il vous suffit de changer le budget mathématique. Vous n'avez pas besoin de réentraîner toute l'IA.
Équitable pour tous : Les petites entreprises ou les chercheurs qui n'ont pas les moyens d'entraîner leurs propres modèles d'IA massifs peuvent tout de même utiliser des modèles préexistants de manière sécurisée.

L'essentiel

Cette publication démontre qu'en traitant la sécurité comme un problème mathématique d'équilibrage entre « utilité » et « risque » à partir d'un menu d'options, nous pouvons rendre les modèles d'IA « boîte noire » beaucoup plus sûrs sans jamais toucher à leur code interne. C'est comme placer un feu de signalisation intelligent et mathématiquement parfait devant une intersection chaotique pour assurer la sécurité de tous, sans avoir besoin de reconstruire les voitures.

Résumé technique : Safety Game : Alignement à l'inférence des LLM de type boîte noire via l'optimisation sous contraintes

1. Énoncé du problème

Le défi central abordé est de garantir que les grands modèles de langage (LLM) respectent les exigences de sécurité sans les coûts prohibitifs et l'inflexibilité des méthodes d'alignement lors de l'entraînement (ex. : RLHF, fine-tuning). Les approches actuelles d'alignement à l'inférence nécessitent souvent un accès aux composants internes du modèle (poids ou architecture), ce qui les rend peu pratiques pour les parties prenantes tierces utilisant des API propriétaires de type boîte noire. De plus, les méthodes actuelles peinent à équilibrer le compromis entre la génération de réponses utiles et informatives et l'évitement de contenus nuisibles ou risqués. Il existe un besoin critique pour un cadre indépendant du modèle, de type boîte noire, capable d'imposer des contraintes de sécurité au moment de l'inférence sans réentraîner le modèle de base.

2. Méthodologie : Le cadre SAFETY GAME

Les auteurs proposent SAFETY GAME, un cadre agnostique au modèle qui traite la sélection d'une réponse parmi un ensemble fini de candidats comme un problème d'optimisation sous contraintes dérivé de la théorie des jeux.

2.1. Formulation du problème

L'interaction entre le LLM (Joueur 1) et l'utilisateur (Joueur 2) est modélisée comme un jeu à information imparfaite à un coup.

Ensemble de candidats : Pour une invite $x$ donnée, le système considère un ensemble fini de réponses candidates $R = \{r_1, \dots, r_m, r_s\}$ , où $r_s$ est un repli sécurisé (fallback) désigné (ex. : un refus ou une déclaration générique sûre) présentant un gain d'utilité nul et un risque nul.
Scoring : Chaque candidat $r_i$ se voit attribuer un score d'utilité ( $h_i$ ) et un score de risque de sécurité ( $s_i$ ). Ceux-ci sont calculés via l'auto-sonde (self-probing), où le LLM de base est interrogé avec des sondes binaires (« Est-ce utile ? » / « Est-ce nuisible ? ») pour estimer les log-probabilités des jetons OUI/NON.
Marges : Le cadre opère sur des marges relatives au repli : $M_i = h_i - h_s$ (gain d'utilité) et $\Delta_i = s_i - s_s$ (risque supplémentaire).

2.2. Dérivation de la théorie des jeux

Le problème de sélection est formalisé comme un jeu à somme nulle à deux joueurs. Le LLM s'engage dans une stratégie mixte $\pi$ (une distribution de probabilité sur les candidats) pour maximiser l'utilité attendue tout en minimisant le risque de violation des politiques de sécurité sous une intention utilisateur incertaine (bénigne ou malveillante).

Équilibre Minimax : Le jeu recherche un équilibre minimax où le LLM maximise l'utilité sous une contrainte de sécurité.
Couche de décision : Cet équilibre est opérationnalisé par un problème de programmation linéaire (PL) résolu au moment de l'inférence :
$\max_{\pi \in \Delta_m} \sum_{i=1}^m \pi_i M_i \quad \text{sous réserve de} \quad \sum_{i=1}^m \pi_i \Delta_i \leq T$
Ici, $T$ est un paramètre de budget de sécurité. Si la PL est infaisable, le système revient par défaut au repli sécurisé $r_s$ .

2.3. Robustesse et mise en œuvre

Signaux bruyants : Le cadre reconnaît que les auto-sondes (ou les scoreurs externes) fournissent des estimations bruitées. Le Théorème 3.1 fournit une garantie de robustesse : si les scores de risque présentent une erreur bornée $\epsilon_s$ , l'application d'une contrainte resserrée $T' = T - 2\epsilon_s$ garantit que le risque réel reste dans $T$ .
Relaxation lissée : Pour gérer la sensibilité aux limites et les scores bruités, une relaxation sigmoïde de la contrainte stricte est également proposée, permettant une rampe de pénalité douce à l'approche du plafond de sécurité.
Compatibilité Boîte Noire : La méthode nécessite uniquement un accès API pour générer les candidats et les évaluer (via l'auto-sonde ou des classifieurs externes). Elle ne modifie pas les poids du modèle de base.

3. Contributions clés

Couche de décision de type théorie des jeux : L'article dérive une règle de sélection pour les LLM de boîte noire basée sur la sécurité d'adaptation dans des jeux à information incomplète. Cela produit deux choix de conception non triviaux :
- Marges relatives au repli : L'optimisation est basée sur l'amélioration par rapport à une ligne de base sûre, et non sur des scores bruts.
- Contrainte de risque agrégée : La sécurité est contrainte sur le mélange de candidats (risque attendu) plutôt que par le filtrage de candidats individuels, ce qui permet de sélectionner des candidats à la limite de la sécurité si ceux-ci sont compensés par des candidats plus sûrs.
Validation empirique de la couche de décision : Les expériences démontrent que le gain de performance est intrinsèque à la couche de décision par PL, et non au scoreur. En utilisant un scoreur externe fixe (Llama-Guard-3-8B), le sélecteur basé sur la PL a récupéré 81 réponses humaines plus sûres que le meilleur filtre par seuil sur 440 invites non sûres.
Alignement boîte noire évolutif : Le cadre offre une solution prête à l'emploi pour les parties prenantes n'ayant pas accès aux composants internes des modèles, permettant l'application de la sécurité à travers diverses familles de modèles sans réentraînement.

4. Résultats expérimentaux

La méthode a été évaluée sur quatre benchmarks : HHH (Utilité, Absence de nocivité, Honnêteté), TruthfulQA, SafetyBench et SORRY-Bench, sur cinq LLM différents (incluant LLaMA-2, LLaMA-3 et GPT-OSS).

SafetyBench : La méthode a obtenu les gains les plus importants, surpassant tous les baselines (y compris les variantes de Consensus Game comme ER-G/ER-D) sur 4 modèles sur 5. Les tests de McNemar appariés ont montré des améliorations statistiquement décisives ( $p < 10^{-4}$ ).
SORRY-Bench : La méthode a obtenu le taux de réalisation humaine attendu (HFR) le plus bas sur trois des cinq modèles, avec des réductions relatives de 45 à 81 % par rapport à la meilleure baseline. Crucialement, elle a maintenu une meilleure qualité de refus (fournir des alternatives informatives plutôt que des refus catégoriques) par rapport aux baselines qui s'effondraient vers un HFR proche de zéro via un filtrage agressif.
Benchmarks généraux (HHH, TruthfulQA) : La méthode a égalé ou dépassé les meilleures baselines dans 14 cas sur 20 configurations modèle-benchmark, démontrant que l'alignement de sécurité n'a pas dégradé l'utilité générale ou la véracité.
Sur-refus : Sur les tâches de suivi d'instructions bénignes (AlpacaEval), la méthode n'a pas présenté de sur-refus catastrophique, maintenant des performances comparables aux baselines tout en se situant sur la frontière de Pareto pour les invites limites.

5. Signification et affirmations

L'article affirme établir la viabilité des cadres d'alignement boîte noire. Sa principale importance réside dans le découplage de la décision de sécurité de l'entraînement interne du modèle, permettant :

Démocratisation : Les organisations plus petites et les entités aux ressources limitées peuvent imposer des pratiques de sécurité robustes sans le fardeau financier ou technique du réentraînement des modèles.
Flexibilité : Les contraintes de sécurité peuvent être mises à jour ou ajustées (via le budget $T$ ) au moment de l'inférence pour s'adapter aux nouvelles réglementations ou normes sociales sans réentraînement.
Fondement théorique : L'approche fournit une justification principielle, basée sur la théorie des jeux, pour la sélection sous contrainte, offrant des garanties de sécurité d'adaptation que le simple seuillage ou le classement ne peuvent fournir.

Les auteurs notent modestement des limites : la performance de la méthode est conditionnée par la qualité de la couche de mesure (calibration du scoreur), et elle opère actuellement sur la sélection en un tour plutôt que sur le dialogue multi-tours. Cependant, ce travail ouvre une nouvelle direction pour une sécurité de l'IA évolutive et accessible, opérant indépendamment de l'architecture du modèle sous-jacent.