Quand les utilisateurs ne peuvent pas être partagés, FedCGR partage plutôt un langage

La recommandation inter-domaine fonctionne parce qu'elle peut emprunter ce qu'un système sait d'un utilisateur dans un domaine et le dépenser dans un autre. Une fois le dispositif fédéré, le prêt s'effondre : les ancres qui rendent le transfert possible, des utilisateurs présents dans plusieurs domaines et des signaux d'interaction partagés, sont précisément ce qu'un déploiement préservant la confidentialité ne peut pas faire circuler. Elles finissent par être éparses, indisponibles ou trop sensibles pour y toucher, selon un article publié sur arXiv le 11 août 2026.

La réponse de l'article, un framework nommé FedCGR, contourne le problème au lieu de l'affronter. Il cesse de chercher à aligner les espaces où vivent les items de chaque domaine et traite plutôt chaque item comme une séquence discrète d'identifiants sémantiques (SID) dérivés de métadonnées publiques propres aux items. L'alignement provient d'un vocabulaire partagé que tout le monde possède déjà, et non de comportements privés échangés entre les clients.

La double contrainte qui fait échouer la recommandation inter-domaine fédérée

La recommandation inter-domaine, généralement abrégée en CDR, transfère la connaissance des préférences entre des domaines apparentés. Dans un déploiement classique, ce transfert s'appuie sur des ancres comportementales : des utilisateurs qui apparaissent dans plus d'un domaine, ou des signaux d'interaction qui relient les deux espaces d'items. Les auteurs de FedCGR soutiennent que ces ancres sont précisément ce sur quoi les environnements fédérés ne peuvent pas compter. Elles sont éparses, parfois indisponibles, et souvent sensibles du point de vue de la confidentialité d'un client à l'autre.

C'est la tension autour de laquelle l'article est construit. Sans ancres partagées, il n'y a rien à aligner, et les approches qui tentent d'aligner des plongements propres à chaque domaine ont soit besoin de faire circuler des signaux privés, soit perdent entièrement le signal inter-domaine. FedCGR recadre la tâche comme une génération sur un langage d'items sémantique stable. Représentez les items comme des séquences de SID construites à partir de métadonnées publiques, et deux domaines s'alignent parce qu'ils partagent déjà un vocabulaire, non parce qu'ils ont échangé quoi que ce soit de privé.

Fédérer directement de tels générateurs impose deux contraintes de conception, notent les auteurs. Le tokeniseur de SID doit rester fixe pour préserver la cohérence des jetons entre les clients. Si chaque client re-tokenisait les items localement, le dictionnaire partagé se fragmenterait. Mais un tokeniseur fixe crée un goulot d'étranglement purement sémantique : les signaux locaux de filtrage collaboratif (CF) ne peuvent être ni partagés ni alignés globalement, si bien que le générateur ne voit jamais que ce que décrivent les métadonnées publiques. En outre, le moyennage fédéré standard peut provoquer un transfert négatif lorsque les domaines sont hétérogènes. Moyenner les paramètres de clients dissemblables tire chaque domaine vers les autres, et l'aide inter-domaine se transforme en bruit inter-domaine.

Un langage d'items partagé, construit à partir de métadonnées publiques

La manœuvre clé est délibérément modeste. Au lieu d'apprendre des plongements à aligner entre les domaines, FedCGR dérive l'identité de chaque item de métadonnées propres aux items, publiques par conception. Le langage d'items reste stable tandis que le modèle s'adapte autour de lui.

L'intuition est proche de deux équipes qui se mettent d'accord sur un dictionnaire avant de cesser de se parler. Une fois le vocabulaire fixé, l'alignement inter-domaine est induit par le vocabulaire partagé lui-même, plutôt que par l'échange d'interactions privées ou l'alignement de représentations apprises. Et comme les métadonnées sont publiques, représenter les items de cette manière ne coûte rien au budget de confidentialité.

Le prix à payer, c'est le goulot d'étranglement purement sémantique. Les métadonnées publiques décrivent les items, pas la façon dont les gens se comportent autour d'eux, et c'est là que le goulot d'étranglement se fait sentir. La réponse de FedCGR est une interface sémantique sensible à la fiabilité qui injecte les signaux locaux de CF dans le processus de génération, une façon de réinjecter le comportement localisé dans un modèle qui, sans cela, ne s'appuie que sur la sémantique.

Agrégation sélective, et ce que les benchmarks ne disent pas

Pour empêcher l'hétérogénéité d'empoisonner le modèle partagé, FedCGR entraîne un générateur personnalisé par prototypes. Il agrège sélectivement les paramètres partagés en fonction de la parenté entre domaines, et conserve les quantités propres à chaque domaine en local. Les domaines apparentés partagent davantage le modèle ; les domaines sans lien se polluent moins entre eux. C'est le mécanisme d'adaptation explicite qui, selon les auteurs, manque au moyennage fédéré standard.

Côté évaluation, l'article rapporte des expériences sur six scénarios inter-domaines Amazon. FedCGR surpasse systématiquement les lignes de base génératives fédérées et atteint des performances compétitives face à de solides méthodes séquentielles et de CDR fédérées, sous des protocoles d'évaluation à la fois en classement complet et par échantillonnage.

Le choix des mots compte. Le résumé revendique la compétitivité, pas la domination, et il ne publie aucun écart chiffré ; le constat honnête est donc que le framework soutient la comparaison avec de solides méthodes non fédérées tout en résolvant un vrai problème de confidentialité. C'est dans cet écart entre une performance qui préserve la confidentialité et une performance sans contraintes que vit habituellement cette ligne de recherche, et FedCGR semble réduire cet écart sans prétendre l'avoir comblé.

Le point essentiel est la philosophie de conception. La confidentialité est traitée au niveau de la représentation : les items reçoivent une identité publique stable, et chaque domaine s'adapte localement autour de cette identité, sans que des interactions privées changent de mains ni que des plongements spécifiques à chaque domaine aient besoin d'être alignés. Ce n'est pas une solution universelle. Les comportements qui contredisent les métadonnées publiques restent invisibles pour le modèle, et le tokeniseur fixe borne jusqu'où l'adaptation peut aller. Mais comme modèle pour la recommandation fédérée, construire la couche partagée à partir de ce qui est déjà public est la partie qui vaut la peine d'être reprise.