🤖 AI

Self-EvolveRec: Self-Evolving Recommender Systems with LLM-based Directional Feedback

Le papier propose Self-EvolveRec, un nouveau cadre qui surmonte les limites des espaces de recherche fixes et des métriques scalaires dans la conception traditionnelle de systèmes de recommandation en intégrant un Simulateur d'Utilisateur et un Outil de Diagnostic de Modèle pour créer une boucle de rétroaction auto-évolutive et directionnelle qui adapte dynamiquement les critères d'évaluation et surpasse de manière significative les bases de référence existantes de NAS et de modèles pilotés par les LLM.

Auteurs originaux : Sein Kim, Sangwu Park, Hongseok Kang, Wonjoong Kim, Jimin Seo, Yeonjun In, Kanghoon Yoon, Hyunsik Jeon, Chanyoung Park

Publié 2026-07-10

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Sein Kim, Sangwu Park, Hongseok Kang, Wonjoong Kim, Jimin Seo, Yeonjun In, Kanghoon Yoon, Hyunsik Jeon, Chanyoung Park

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 essayez d'apprendre à un robot à devenir l'assistant de shopping ultime. Pendant des années, la méthode standard pour faire cela consistait à jouer aux « Mad Libs » avec un livre de règles très strict. Vous donniez au robot une liste fixe de briques Lego (des opérateurs mathématiques prédéfinis) et lui disiez : « Construis le meilleur moteur de recommandation en utilisant uniquement ces briques ». C'est ce qu'on appelle la Recherche d'Architecture Neuronale (NAS). Le problème ? Le robot ne peut construire que des choses qui rentrent dans la boîte de briques que vous lui avez donnée. Il ne peut pas inventer un nouveau type de brique, et il ne peut pas corriger les instructions sur la façon de les utiliser si les instructions sont erronées.

Puis, une nouvelle tendance est arrivée : l'évolution de code pilotée par les LLM. C'était comme donner au robot une toile vierge et un stylo magique, en lui disant : « Écris ton propre code ! ». Le robot pouvait désormais inventer de nouvelles briques. Mais il y avait un piège. Le robot était toujours évalué sur un chiffre unique et ennuyeux, comme une note d'examen. Si le score baissait, le robot se disait simplement : « Peut-être que je devrais changer ce nombre ? », puis il essayait à nouveau. C'était un jeu de fléchettes les yeux bandés. Il ne savait pas pourquoi il avait raté la cible. La recommandation était-elle trop populaire ? Avait-il ignoré le goût étrange de l'utilisateur pour les chaussettes vintage ? Le robot savait juste que le score avait chuté et il paniquait.

Voici entré Self-EvolveRec, un nouveau framework qui agit comme un coach super intelligent doté de deux assistants spéciaux.

Les deux assistants : Le Critique et Le Docteur

Au lieu de simplement regarder un score d'examen, Self-EvolveRec utilise un Simulateur d'Utilisateur (appelons-la « Le Critique ») et un Outil de Diagnostic de Modèle (appelons-le « Le Docteur »).

Le Critique est une équipe de clients virtuels ayant des personnalités distinctes. L'un peut être un étudiant soucieux de son budget qui déteste l'électronique chère ; un autre peut être un adepte des tendances qui veut les derniers gadgets. Quand le robot fait une recommandation, Le Critique ne dit pas seulement : « Score : 4/5 ». Elle dit : « Je m'ennuie ! Tu m'as donné trois consoles de jeux à la suite. J'ai besoin de variété ! » ou « Cet article est bien trop cher pour mon budget. » Cela donne au robot un feedback directionnel : une carte claire de ce qui ne va pas et de pourquoi.

Le Docteur est un mécanicien qui regarde sous le capot. Tandis que Le Critique se plaint de l'expérience utilisateur, Le Docteur vérifie la santé interne du moteur. Il peut repérer quelque chose d'invisible pour l'utilisateur, comme l'« Effondrement d'Embedding » (Embedding Collapse). Imaginez que toutes les idées du robot pour « chaussures » et « sandales » se soient écrasées dans un minuscule coin de son cerveau, le faisant penser qu'elles sont exactement la même chose. Le Docteur mesure cela mathématiquement et dit : « Hé, ton cerveau est en train de s'embrouiller ; tes idées sont trop similaires. »

La boucle magique : La Co-Évolution

C'est ici que cela devient vraiment génial. Habituellement, si le robot apprend un nouveau tour (comme une nouvelle façon de traiter les prix), l'ancien Docteur pourrait ne pas savoir comment vérifier ce nouveau tour. Il serait comme : « Je n'ai pas d'outil pour cette nouvelle pièce de moteur ! »

Self-EvolveRec résout cela avec la Co-Évolution Outil de Diagnostic - Modèle. À mesure que le robot évolue et apprend de nouveaux tours, le Docteur évolue avec lui. Si le robot invente un nouvel « Encodeur de Prix », le Doctлу invente automatiquement un nouvel outil de « Vérification de Prix » pour le mesurer. Si Le Critique se plaint d'un « manque de diversité », le Docteur invente une nouvelle formule mathématique pour mesurer la diversité et vérifier si le robot a réellement corrigé le problème. Ils grandissent ensemble, garantissant que le robot est toujours vérifié par les bons outils.

Les résultats : Pas seulement une supposition

Les auteurs ont testé cela sur des données réelles d'Amazon (CDs, Électronique, Fournitures de bureau) et de MovieLens. Ils ont comparé Self-EvolveRec aux anciennes méthodes de « briques Lego » et aux méthodes d'évolution de code de type « fléchettes les yeux bandés ».

Les résultats ont montré que Self-EvolveRec surpasse systématiquement les autres. Dans le jeu de données CDs, par exemple, en partant d'un modèle de base, Self-EvolveRec a boosté le NDCG@5 (une mesure de la qualité des meilleures recommandations) à 0,3865, tandis que le meilleur concurrent « aux yeux bandés » n'a atteint que 0,3610. Sur le HR@5 (Hit Ratio), Self-EvolveRec a atteint 0,5274, battant le 0,4870 de la concurrence.

Mais la vraie victoire n'était pas seulement dans les chiffres. Lorsque les auteurs ont demandé à des juges IA indépendants d'évaluer la qualité du code écrit par le robot, Self-EvolveRec a obtenu les scores les plus élevés en Créativité (8,04 contre 7,50 pour le suivant) et en Perspicacité (8,16 contre 7,40). Cela suggère que le robot ne faisait pas que deviner ; il comprenait réellement les problèmes et inventait des solutions ingénieuses, comme ajouter des « Négatifs Durs Sensibles à la Catégorie » (Category-Aware Hard Negatives) pour empêcher de recommander sans cesse la même chose de façon monotone.

Ils ont également lancé une simulation de « satisfaction utilisateur ». Dans un test où des utilisateurs virtuels décidaient de continuer à naviguer ou d'abandonner, Self-EvolveRec les a maintenus engagés plus longtemps. La Profondeur (le nombre de pages consultées) a atteint 2,048 sur le jeu de données CDs, contre 1,952 pour la méthode suivante. Cela suggère que les recommandations semblent plus humaines et moins robotiques.

Ce que ce n'est pas

Il est important de noter ce que cet article ne prétend pas. Les auteurs précisent avec prudence que, bien que leur « Simulateur d'Utilisateur » soit très bon pour imiter le comportement humain, il s'agit toujours d'une simulation. Ils déclarent explicitement que la validation complète de ces améliorations pour des utilisateurs réels nécessiterait de véritables tests A/B avec de vraies personnes, ce qu'ils laissent pour des travaux futurs. Ils ont également constaté que si l'on retire le « Critique » (le Simulateur d'Utilisateur) pour n'utiliser que le « Docteur » (l'Outil de Diagnostic), le robot s'améliore tout de même, mais beaucoup moins. C'est la combinaison des deux qui crée la magie.

En résumé, Self-EvolveRec suggère que pour construire un véritable système de recommandation, on ne peut pas se contenter de regarder le score. Il faut un coach capable de vous dire pourquoi vous avez échoué, un mécanicien capable de vérifier vos engrenages internes, et un système où les deux apprennent et grandissent en même temps que vous. Cela transforme le processus chaotique de « devine et vérifie » en un voyage guidé de la découverte.

Résumé Technique : Self-EvolveRec

Définition du Problème

La conception automatisée traditionnelle des systèmes de recommandation, en particulier la recherche d'architecture neuronale (NAS), est contrainte par des espaces de recherche fixes définis par des a priori humains. Ces méthodes limitent l'innovation à des opérateurs prédéfinis et échouent souvent à optimiser conjointement les composants non architecturaux tels que les fonctions de perte et les pipelines de traitement de données. De plus, les récents cadres d'évolution de code pilotés par les LLM, bien que capables d'une exploration ouverte de l'espace des programmes, reposent principalement sur des métriques scalaires (ex. : NDCG, Hit Ratio) pour l'orientation. Ces métriques scalaires manquent de capacité de diagnostic ; elles quantifient la dégradation des performances mais ne parviennent pas à expliquer les causes profondes (ex. : biais de popularité, insuffisance de la diversité des catégories ou effondrement des embeddings) ni à fournir une direction qualitative pour l'amélioration. Par conséquent, l'évolution dans ces systèmes dégénère souvent en recherches par essais et erreurs non dirigées.

Méthodologie

Les auteurs proposent Self-EvolveRec, un nouveau cadre d'évolution de code piloté par LLM conçu pour établir une boucle de rétroaction directionnelle pour l'automatisation de la conception de systèmes de recommandation. Le cadre opère via trois mécanismes fondamentaux :

1. Génération de Rétroaction Directionnelle

Au lieu de s'appuyer uniquement sur des scores scalaires, Self-EvolveRec intègre deux sources de rétroaction complémentaires pour fournir des informations exploitables :

Simulateur d'Utilisateur (SIM) : Un système agentique qui simule divers personas d'utilisateurs (caractérisés par des traits tels que l'Activité, la Conformité et la Diversité) pour évaluer les listes de recommandations. Le SIM génère des critiques qualitatives en langage naturel (ex. : « Je recherche des accessoires à bas prix, pas de l'électronique coûteuse ») qui expliquent pourquoi une recommandation échoue, traitant ainsi les désalignements sémantiques que les métriques scalaires ignorent.
Outil de Diagnostic de Modèle (DIAG) : Un module de sondage computationnel qui effectue une vérification quantitative des propriétés structurelles internes du modèle. Il détecte les problèmes cachés invisibles à la perception de l'utilisateur, tels que l'effondrement des embeddings (via l'analyse de la similarité cosinus) et les déficiences de la marge de classement.

2. Pipeline d'Évolution

Le cadre emploie une stratégie d'exploration basée sur la population où un agent LLM affine itérativement la base de code à travers un flux de travail en quatre phases :

Évaluation Multi-facettes : La base de code actuelle est évaluée pour génire des scores scalaires, des rapports de feedback utilisateur ( $R_{SIM}$ ) et des rapports de diagnostic ( $R_{DIAG}$ ).
Planification et Récupération Sensibles au Feedback : Le LLM agit comme un planificateur, formulant des requêtes de recherche spécifiques basées sur la rétroaction directionnelle pour récupérer la littérature académique pertinente (RAG). Cela déplace l'accent de la collecte de connaissances générales vers la résolution ciblée des défaillances.
Évolution du Code : Guidé par un rapport de développement structuré dérivé du feedback et de la littérature récupérée, le LLM implémente des modifications précises au niveau du code pour faire évoluer le pipeline de recommandation.
Co-évolution Outil de Diagnostic - Modèle : À mesure que l'architecture de recommandation évolue (ex. : introduction de nouveaux encodeurs ou fonctions de perte), un outil de diagnostic statique devient obsolète. Self-EoreRec introduit une stratégie de co-évolution où l'outil DIAG lui-même est mis à jour. Le LLM analyse les changements structurels et les critiques des utilisateurs pour générer dynamiquement de nouvelles métriques et de nouveaux sondages capables de vérifier les nouveaux composants et de traduire le feedback qualitatif en signaux mesurables.

3. Variante Efficace

Pour répondre aux coûts de calcul, les auteurs proposent une variante efficace utilisant des proxys à coût nul. Cette approche estime le potentiel du pipeline via une seule passe avant-arrière sur un mini-lot, utilisant des signaux tels que le rang effectif et les normes de gradient, permettant un déploiement scalable avec une accélération allant jusqu'à 12×.

Contributions Clés

Boucle de Rétroaction Directionnelle : L'intégration de la simulation d'utilisateur qualitative et du diagnostic de modèle quantitatif pour guider l'évolution du code, allant au-delà de l'optimisation des métriques scalaires.
Co-évolution Outil de Diagnostic - Modèle : Une stratégie novatrice garantissant que les critères d'évaluation s'adaptent dynamiquement aux changements structurels de la base de code, maintenant la validité de la boucle de rétroaction tout au long du processus évolutif.
Optimisation Ouverte : Démontrer qu'en passant de pools d'opérateurs fermés à des espaces de programmes ouverts, guidés par une rétroaction directionnelle, il est possible d'inventer de nouveaux composants au-delà des espaces de conception prédéfinis.

Résultats Expérimentaux

Des expériences approfondies ont été menées sur quatre jeux de données (Amazon CDs, Electronics, Office et MovieLens) comparant Self-EvolveRec aux bases de comparaison de pointe de la NAS (AutoFIS, NASRec, etc.) et aux cadres d'évolution pilotés par LLM (AlphaEvolve, DeepEvolve).

Performance de Recommandation : Self-EvolveRec a systématiquement surpassé toutes les bases de comparaison dans les métriques standards (NDCG@5, HR@5) sur tous les jeux de données et architectures de départ (NCF, NGCF, SASRec, MoRec). Notamment, il a atteint une performance de pointe en moins d'itérations (8–11) par rapport aux bases de comparaison (13–19) ou a échoué à s'améliorer.
Satisfaction de l'Utilisateur : Évalué via des simulateurs agentiques (Agent4Rec et PUB) avec des schémas de personas distincts, Self-EvolveRec a démontré une performance supérieure dans les métriques centrées sur l'utilisateur (Vue, Satisfaction, Profondeur), indiquant que les modèles évolués s'alignent mieux sur les besoins complexes des utilisateurs et les comportements de rétention.
Qualité de la Base de Code : Une évaluation par "LLM-as-a-Judge" a révélé que Self-EvolveRec a produit du code avec des scores plus élevés en Créativité, Explicité, Insight et Personnalisation par rapport aux bases de comparaison.
Robustesse : Le cadre a montré une forte adaptabilité dans des scénarios d'initialisation extrêmes, réussissant à faire évoluer des systèmes de recommandation aléatoires vers des pipelines compétitifs et à affiner des modèles d'ensemble complexes là où les bases de comparaison basées uniquement sur des scalaires ont échoué.

Signification

L'article affirme que Self-EvolveRec répond à la limitation critique des méthodes de conception automatisée existantes : l'absence d'insight de diagnostic dans l'optimisation. En établissant une boucle de rétroaction directionnelle qui combine les critiques qualitatives des utilisateurs et la vérification structurelle quantitative, le cadre permet une évolution ciblée, pilotée par les causes profondes. L'introduction de la stratégie de Co-évolution Outil de Diagnostic - Modèle garantit que le mécanisme d'évaluation reste pertinent à mesure que le système évolue, empêchant la boucle de rétroaction de devenir obsolète. Les résultats suggèrent que cette approche améliore non seulement la précision de la recommandation, mais renforce également la qualité technique et la centricité utilisateur des algorithmes générés, offrant une voie robuste vers une conception de système de recommandation entièrement autonome.