🤖 AI

SharedRequest: Privacy-Preserving Model-Agnostic Inference for Large Language Models

L'article propose SharedRequest, un cadre agnostique du modèle qui améliore l'inférence de LLM respectueuse de la vie privée en masquant les requêtes sensibles par le mélange et le regroupement de requêtes sémantiquement équivalentes, atteignant ainsi une utilité supérieure et une réduction des coûts allant jusqu'à 5 fois sans nécessiter de modifications du modèle.

Auteurs originaux : Peihua Mai, Xuanrong Gao, Youlong Ding, Xianglong Du, Wei Liu, Yan Pang

Publié 2026-06-04

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Peihua Mai, Xuanrong Gao, Youlong Ding, Xianglong Du, Wei Liu, Yan Pang

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 vouliez poser une question à une IA super intelligente (comme un oracle numérique), mais que votre question contienne un secret — peut-être votre intitulé de poste spécifique, une condition médicale ou un détail financier. Vous ne voulez pas que l'entreprise d'IA connaisse ce secret, mais vous avez quand même besoin d'une bonne réponse.

Actuellement, essayer de cacher votre secret signifie généralement l'une de ces deux mauvaises choses :

L'approche de la « photo floue » : Vous brouillez tellement vos mots que l'IA est confuse et vous donne une mauvaise réponse.
L'approche du « verrou lourd » : Vous utilisez des mathématiques complexes pour verrouiller votre question. Cela la garde en sécurité, mais c'est si lent et coûteux qu'il est difficile de l'utiliser pour de grands groupes de personnes.

Le document présente un nouveau système appelé SharedRequest. Voyez cela comme une stratégie de « discussion de groupe » astucieuse qui résout les deux problèmes à la fois.

L'idée centrale : L'analogie de la « commande groupée »

Imaginez que vous et 99 amis vouliez tous acheter un gâteau personnalisé auprès d'une boulangerie (l'IA).

Le problème : Vous voulez tous des saveurs différentes, mais vous craignez que le boulanger ne voie votre commande spécifique et ne devine vos secrets personnels (par exemple : « Je commande un gâteau sans gluten parce que je souffre de la maladie cœliaque »).
L'ancienne méthode : Chacun envoie sa commande séparément, en brouillant ses mots pour que le boulanger ne puisse pas les lire. C'est lent, coûteux, et le boulanger pourrait quand même être confus par les mots brouillés.
La méthode SharedRequest :
1. Le regroupement : Le système remarque que 50 d'entre vous veulent simplement un « Gâteau au chocolat » et 50 veulent un « Gâteau à la vanille ». Il vous regroupe en fonction de ce que vous voulez faire (l'instruction générique), et non de qui vous êtes.
2. Le mélange : Pour le groupe « Chocolat », le système prend votre véritable commande (« Gâteau au chocolat sans gluten pour [Nom] ») et la mélange avec 10 commandes fictives (« Gâteau au chocolat sans gluten pour [Faux Nom 1] », « Gâteau au chocolat régulier pour [Faux Nom 2] », etc.).
3. Le lot : La boulangerie reçoit un énorme tas mélangé de 60 commandes de gâteaux au chocolat. Elle ne peut pas savoir laquelle est la vôtre et lesquelles sont les fausses. Elle cuit le gâteau une seule fois pour tout le groupe (économisant ainsi de l'argent) et distribue les réponses.
4. Le résultat : Vous obtenez votre réponse spécifique, mais la boulangerie ne voit qu'un amas désordonné de requêtes similaires. Votre secret est caché dans la foule.

Comment cela fonctionne (Les trois personnages)

Le système utilise trois parties pour faire opérer cette magie :

Vous (L'utilisateur) : Vous envoyez votre question. Vous cachez vos parties secrètes (comme votre nom ou votre métier) en les cryptant (en les mettant dans une boîte verrouillée).
L'échantillonneur de bruit (L'intermédiaire) : Il s'agit d'un tiers de confiance (comme un gardien de la vie privée). Il reçoit votre boîte verrouillée. Il regarde le type de question que vous avez posée (par exemple : « Trouver un restaurant ») mais ne peut pas voir votre secret. Il peut ensuite :
- Trouver d'autres personnes posant le même type de question.
- Générer des versions de « bruit » fictives de votre secret (par exemple : si votre secret est « Cybersécurité », il génère des versions fictives comme « Marketing » ou « Comptabilité »).
- Mélanger votre vrai secret avec les faux et les mélanger tous ensemble.
Le fournisseur de services (La boulangerie d'IA) : Il reçoit le grand tas mélangé de questions mixtes. Il répond à toutes les questions. Comme il ne peut pas distinguer quelle question appartient à qui, votre vie privée est préservée. Il renvoie les réponses à l'Échantillonneur de bruit, qui vous transmet la bonne réponse.

Pourquoi est-ce meilleur ?

Le document affirme que cette méthode est un « gagnant-gagnant » pour trois raisons :

C'est plus intelligent (Meilleure utilité) : Contrairement aux autres méthodes qui brouillent vos mots et ruinent la réponse, SharedRequest préserve le sens de votre question. L'IA vous comprend parfaitement car le « bruit » n'est qu'un mélange d'options similaires et plausibles, et non du charabia. Les auteurs affirment qu'il fonctionne 20 % mieux que les méthodes de confidentialité précédentes.
C'est moins cher (Amortissement des coûts) : Comme l'IA traite tout le groupe à la fois, le coût de génération des questions « fictives » est partagé entre tout le monde. Si 1 000 personnes posent des questions similaires, le coût par personne chute considérablement. Le document indique que cela peut rendre les requêtes 5 fois moins chères qu'en les posant individuellement.
C'est flexible (Indépendant du modèle) : Vous n'avez pas besoin de modifier la façon dont l'IA est construite. Cela fonctionne avec n'importe quel modèle d'IA existant (comme ChatGPT ou Gemini) sans que l'entreprise ait besoin d'installer des logiciels spéciaux.

Le filet de sécurité

Le document aborde également un problème délicat : et si l'« Échantillonneur de bruit » et la « Boulangerie d'IA » s'alliaient pour tricher ?

Les auteurs proposent une version plus robuste où il existe plusieurs Échantillonneurs de bruit. Pour briser votre vie privée, ils devraient tous s'entendre (travailler ensemble) au même moment précis. Si un seul d'entre eux est honnête, votre secret reste en sécurité.

Résumé

SharedRequest est comme aller à un concert bondé pour se cacher à la vue de tous. Au lieu de chuchoter votre secret au DJ (l'IA) seul, vous rejoignez un groupe massif où tout le monde pose des questions similaires. Le DJ entend un rugissement de requêtes similaires et ne peut pas isoler votre voix spécifique, mais vous entendez quand même votre chanson parfaitement, tandis que votre secret reste protégé. C'est plus rapide, moins cher et cela garde vos secrets en sécurité sans rendre l'IA « stupide ».

Résumé Technique : SharedRequest

Énoncé du Problème

Le déploiement généralisé des modèles de langage de grande taille (LLM) publics comme ChatGPT a créé une tension critique entre l'utilité et la vie privée des utilisateurs. Bien que les LLM basés sur le cloud offrent des capacités transformatrices, les requêtes des utilisateurs contiennent souvent des informations sensibles (par exemple, des attributs personnels, des antécédents médicaux, des détails juridiques) qui doivent rester confidentielles vis-à-vis des tiers, y compris le fournisseur de services.

Les méthodes d'inférence préservant la confidentialité existantes font face à un « trilemme » entre la confidentialité, l'utilité et l'efficacité :

Approches cryptographiques (SMPC) : Des méthodes telles qu'Iron, MPCFormer et SecFormer offrent des garanties de confidentialité fortes mais introduisent des surcoûts de communication et de calcul prohibitifs, limitant ainsi l'évolutivité.
Confidentialité Différentielle Locale (LDP) : Les approches comme RanText et CusText perturbent les requêtes côté client, mais dégradent souvent considérablement la qualité des réponses (utilité) et peinent avec les tâches de génération de texte.
Modifications spécifiques au modèle : De nombreuses solutions nécessitent l'accès aux paramètres du modèle ou des changements architecturaux, ce qui est irréalisable pour les modèles propriétaires de type « boîte noire ».
Perturbation individuelle : Les méthodes actuelles agnostiques au modèle perturbent généralement chaque requête de manière indépendante, ce qui entraîne une distorsion sémantique et des coûts de requête élevés lors de la génération de multiples variantes bruitées pour garantir la confidentialité.

Méthodologie : SharedRequest

Les auteurs proposent SharedRequest, un cadre agnostique au modèle qui reformule la protection de la vie privée au niveau du lot (batch) plutôt qu'au niveau de la requête individuelle. L'idée centrale est que les LLM commerciaux traitent des lots massifs de requêtes où de nombreux utilisateurs partagent des instructions génériques sémantiquement équivalentes (par exemple, « Quels sont les restaurants recommandés à [Lieu] ? »).

Mécanisme Central

SharedRequest fonctionne via un protocole à trois parties impliquant les Utilisateurs, un Échantillonneur de Bruit (un coordinateur tiers) et le Fournisseur de Services (propriétaire du LLM).

Décomposition de la Requête :
- La requête de l'utilisateur est divisée en une instruction générique ( $T_q$ ) et des attributs privés ( $A_q$ ).
- Les utilisateurs identifient les attributs privés et échantillonnent un ensemble d'attributs alternatifs plausibles ( $A'$ ) à partir d'une base de données préconstruite ou d'une génération locale.
Groupement au Niveau du Lot et Injection de Bruit :
- L'Échantillonneur de Bruit reçoit les attributs privés chiffrés des utilisateurs. Il regroupe les requêtes basées sur leurs instructions génériques.
- Pour chaque groupe, l'échantillonneur génère des variantes bruitées en remplaçant les attributs privés originaux par des alternatives échantillonnées.
- Crucialement, l'échantillonneur utilise un mécanisme de filtrage par combinaison. Au lieu d'envoyer toutes les combinaisons possibles d'attributs (ce qui serait exponentiellement grand), il utilise un discriminateur pré-entraîné pour noter la « véracité » des combinaisons d'attributs dans le contexte. Seules les combinaisons dépassant un seuil de qualité sont sélectionnées. Cela garantit que les requêtes bruitées sont indiscernables des requêtes authentiques.
Transmission Sécurisée :
- Transmission Vers l'Avant (Forward) : Les utilisateurs chiffrent les attributs privés à l'aide de la clé publique du Fournisseur de Services. Les messages envoyés à l'Échantillonneur de Bruit sont chiffrés avec la clé publique de l'Échantillonneur. Cela garantit que l'Échantillonneur ne voit que les instructions génériques et les listes de candidats, tandis que le Fournisseur de Services voit un mélange mélangé de requêtes authentiques et bruitées sans pouvoir les lier à des utilisateurs spécifiques.
- Transmission Vers l'Arrière (Backward) : Le Fournisseur de Services génère des réponses pour le lot. Pour empêcher l'Échantillonneur de Bruit d'apprendre le contenu, le Fournisseur de Services masque les réponses à l'aide d'un masque pseudo-aléatoire dérivé d'une graine (seed) fournie par l'utilisateur. Les utilisateurs reconstruisent la véritable réponse via une soustraction modulaire.
Amortissement des Coûts :
- Le Fournisseur de Services agrège les requêtes identiques (authentiques et bruitées) au sein d'un lot et génère une seule réponse par requête unique.
- Le coût d'inférence des requêtes « bruitées » est amorti sur l'ensemble du lot d'utilisateurs partageant la même instruction générique.

Définition de la Confidentialité

Le papier introduit l' $(A_n, \epsilon)$ -indistinguabilité, une relaxation de la Confidentialité Différentielle (DP) standard.

Voisins : Deux ensembles de requêtes sont considérés comme voisins si l'un peut être obtenu de l'autre en remplaçant les attributs privés d'une seule requête par un « attribut alternatif qualifié » issu d'un ensemble défini par l'utilisateur.
Garantie : Le mécanisme garantit que la vue du Fournisseur de Services (un ensemble mélangé de requêtes) est indiscernable concernant les changements d'attributs privés, à condition que l'Échantillonneur de Bruit et le Fournisseur de Services ne colludent pas.

Contributions Clés

Nouveau Paradigme au Niveau du Lot : Un cadre agnostique au modèle qui regroupe les requêtes sémantiquement équivalentes pour un traitement conjoint, permettant la confidentialité grâce à des variantes bruitées mélangées et la réduction des coûts grâce à l'amortissement au niveau du lot.
Protocole Multi-Parties Léger : Une conception qui préserve l'anonymat de l'utilisateur et cache les attributs privés au fournisseur de services sans nécessiter de modification de l'architecture du LLM ou d'accès aux paramètres du modèle.
Formalisation Théorique : Formalisation de la confidentialité via l' $(A_n, \epsilon)$ -indistinguabilité et analyse théorique prouvant les bénéfices d'amortissement du coût des requêtes, particulièrement sous des distributions de requêtes inégales (longue traîne).
Coordination par un Tiers : Un mécanisme pour l'échantillonnage efficace de requêtes bruitées qui réduit la charge de calcul côté utilisateur pour les requêtes comportant plusieurs attributs privés en déchargeant la sélection complexe des combinaisons vers l'Échantillonneur de Bruit.

Résultats Expérimentaux

Le cadre a été évalué sur trois ensembles de données sensibles à la confidentialité : Legal-QA, Medical-QA et MMLU-Biz.

Utilité :
- La version « Originale » (sans simplification de la requête) a atteint une utilité presque identique à la référence non privée (perte de moins de 1 %).
- Comparé aux meilleures méthodes LDP agnostiques au modèle (RanText, CusText, DP-Prompt, InferDPT), SharedRequest a obtenu une utilité supérieure de plus de 20 % (mesurée par le score F1 ou les évaluations de qualité) pour des budgets de confidentialité ( $\epsilon$ ) allant de 1 à 5.
Coût des Requêtes :
- Le mécanisme de requête partagée a réduit les coûts de requête jusqu'à 5,6× par rapport à l'inférence non groupée, particulièrement lorsque la distribution des instructions génériques est concentrée (faible entropie).
- La réduction des coûts augmente avec la taille du lot et l'asymétrie de la distribution des requêtes.
Robustesse :
- Contre les attaques d'inférence où un serveur tente de distinguer les requêtes authentiques des requêtes bruitées, SharedRequest a réduit le taux de réussite de l'attaque d'environ 32,7 % par rapport aux bases de référence d'échantillonnage aléatoire.
- Le cadre a maintenu des taux de réussite d'attaque (ASR) comparables aux autres bases de référence DP tout en offrant une utilité nettement plus élevée.
Efficacité :
- La surcharge de calcul pour le filtrage des attributs sur l'Échantillonneur de Bruit était faible (moins de 6,2 secondes par groupe d'instructions pour un discriminateur de 1,5 milliard de paramètres).
- La surcharge de communication est restée minimale (< 0,1 Mo), comparable aux méthodes DP standards et nettement inférieure aux approches basées sur le SMPC.

Signification et Revendications

Le papier affirme que SharedRequest répond aux limitations fondamentales de l'inférence de LLM préservant la confidentialité en brisant le compromis entre confidentialité, utilité et efficacité. En déplaçant le paradigre de la confidentialité de la perturbation individuelle vers le mélange au niveau du lot, le cadre tire parti de la redondance naturelle de l'utilisation des LLM à grande échelle pour amortir le coût de la protection de la confidentialité.

Les auteurs soulignent que cette approche est agnostique au modèle, ce qui la rend immédiatement applicable aux modèles propriétaires de type « boîte noire » sans nécessiter la coopération du fournisseur de services ou de changements architecturaux. Les résultats suggèrent que pour les scénarios réels avec des distributions de requêtes concentrées, SharedRequest offre une voie pratique pour déployer des LLM respectant la vie privée tout en réduisant considérablement les coûts opérationnels.

Limites Reconnues :

Le protocole suppose que l'Échantillonneur de Bruit et le Fournisseur de Services ne colludent pas.
Les utilisateurs sont responsables de l'identification des attributs privés et de la génération d'alternatives (bien que des outils comme l'NER ou des LLM locaux puissent aider).
Les avantages de coût sont maximisés lorsque les distributions de requêtes sont inégales ; les requêtes hautement uniques pourraient voir un amortissement moindre.