architecte-pipeline-recsys

Que fait architecte-pipeline-recsys ?

Un skill de spécification et de génération de scaffolds pour construire des pipelines de recommandation, classement et fil d'actualité composables. Il encode le modèle en six étapes — Source → Hydrateur → Filtre → Scoreur → Sélecteur → EffetSecondaire — popularisé par l'algorithme For You open-source de xAI (Apache 2.0). Ce skill est une réimplémentation indépendante du modèle (MIT) — aucun code copié de l'original.

Amont : https://github.com/mturac/recsys-pipeline-architect

Quand l'utiliser

• L'utilisateur souhaite construire un système qui sélectionne "les K meilleurs éléments pour un utilisateur/contexte"
• L'utilisateur demande "comment classer X" ou décrit un problème de fil d'actualité/personnalisation
• L'utilisateur a une fonction de scoring et a besoin de la tuyauterie du pipeline autour
• L'utilisateur souhaite migrer d'un score de pertinence unique vers une prédiction multi-action avec des poids ajustables
• L'utilisateur intègre un scoreur LLM/ML et a besoin de filtres, hydrateurs, effets secondaires et un scaffold exécutable dans sa pile (TypeScript / Go / Python)
• Déclencheurs : "système de recommandation", "algorithme de fil d'actualité", "pipeline de classement", "fil pour vous", "pipeline de candidats", "recommandeur de contenu", "architecture de pipeline pour recsys", "ré-ordonnanceur de récupération RAG"

Quand NE PAS l'utiliser

• Travail d'architecture de modèle (conception de transformer, récupération à deux tours, entraînement d'embeddings) — ce skill est la tuyauterie autour du modèle, pas le modèle lui-même
• Pipelines d'entraînement ML purs — la fonction de scoring est la responsabilité de l'utilisateur
• Exploitation d'un pipeline déployé (surveillance, mise à l'échelle automatique) — hors périmètre

Le framework en six étapes

#	Étape	Tâche	Parallèle ?
1	Source	Récupérer les candidats depuis une ou plusieurs origines	Oui — plusieurs sources s'exécutent en parallèle
2	Hydrateur	Enrichir chaque candidat avec les métadonnées nécessaires au filtrage et au scoring	Oui — les hydrateurs indépendants s'exécutent en parallèle
3	Filtre	Supprimer les candidats qui ne doivent jamais être montrés (bloqués, expirés, doublons, inéligibles)	Séquentiel — chaque filtre voit moins d'éléments
4	Scoreur	Assigner à chaque candidat survivant un ou plusieurs scores	Séquentiel — les scoreurs ultérieurs voient les scores précédents
5	Sélecteur	Trier par score final, retourner les K premiers	Opération unique
6	EffetSecondaire	Mettre en cache les IDs servis, enregistrer les impressions, émettre des événements, mettre à jour les compteurs	Asynchrone — ne doit jamais bloquer la réponse

Pourquoi cet ordre précis

• Sources avant hydratation : savoir quels candidats existent avant de payer pour les enrichir
• Hydratation avant filtrage : de nombreux filtres ont besoin de métadonnées que la source n'a pas fournies
• Filtrage avant scoring : le scoring est l'étape coûteuse ; éliminer d'abord les inéligibles
• Chaîne de scoreurs (pas un seul scoreur) : les systèmes réels composent scoring ML + ré-ordonnancement de diversité + règles métier
• Sélecteur après scoring : maintient le scoring déterministe et en cache
• Effets secondaires en dernier et asynchrones : les effets secondaires ne doivent jamais bloquer la réponse utilisateur

Workflow lors de l'invocation

Accompagnez l'utilisateur à travers ces huit étapes :

1. Clarifier le cas d'usage (un tour, trois questions) : éléments classés ? contexte d'entrée ? langage/environnement d'exécution ?
2. Identifier les sources de candidats : généralement en-réseau (suivis/possédés/abonnés) + hors-réseau (récupération ML / tendances / similaires-aux-aimés)
3. Lister les hydratations nécessaires : pour chaque filtre et scoreur, de quelles données a-t-il besoin que la source n'a pas fournies ?
4. Lister les filtres : doublon, soi-même, âge, blocage/masquage, déjà servi, éligibilité. L'ordre compte : peu coûteux avant coûteux.
5. Concevoir la chaîne de scoreurs : principal (ML) → combineur (multi-action avec poids) → diversité → règles métier
6. Sélecteur : trier par score final décroissant, prendre les K premiers (ou mélange stratifié pour en-réseau/hors-réseau)
7. Effets secondaires : mettre en cache les IDs servis, émettre des événements d'impression, mettre à jour les compteurs, enregistrer les analyses — tout en oubliant
8. Générer le scaffold dans la pile de l'utilisateur

Compromis clés à mettre en évidence (ne pas choisir par défaut en silence)

1. Score unique vs prédiction multi-action

• Score unique : entraîner un modèle pour prédire la pertinence. Pour changer le comportement → ré-entraîner.
• Multi-action : prédire P(action) pour plusieurs actions (lire, aimer, partager, ignorer, signaler), combiner avec des poids au moment du service. Pour changer le comportement → changer les poids. Pas de ré-entraînement.

Le système X For You utilise multi-action avec des poids à la fois positifs et négatifs. Recommander multi-action lorsque l'utilisateur prévoit d'ajuster fréquemment.

2. Isolation des candidats dans le scoring

• Isolé : chaque candidat est noté indépendamment. Déterministe, en cache possible.
• Conjoint : les candidats s'influencent mutuellement pendant le scoring (ex : transformer sur un lot). Plus expressif mais non déterministe d'un lot à l'autre.

Par défaut, choisir isolé. Conjoint seulement s'il y a une raison spécifique (ex : diversité explicite tenant compte du lot).

3. En ligne vs hors ligne

• Au moment de la requête (en ligne) : le pipeline s'exécute à chaque requête. Budget de latence : 100–300 ms. Par défaut.
• Pré-calculé (lot hors ligne) : le pipeline s'exécute périodiquement, les résultats sont mis en cache. Latence plus faible, fraîcheur plus faible.
• Hybride : récupération des candidats hors ligne, classement en ligne.

Règles strictes

1. N'inventez pas de chiffres de performance. "Combien plus rapide ?" → "dépend de la charge de travail, exécutez-le vous-même."
2. Discipline d'attribution. Lorsque le modèle est référencé, attribuez-le comme "popularisé par l'algorithme For You open-source de xAI" / github.com/xai-org/x-algorithm (Apache 2.0).
3. Pas d'utilisation de marque. Ne nommez pas l'artefact de l'utilisateur "X-like" ou n'utilisez pas la marque "For You". Le modèle est libre ; la marque ne l'est pas. Suggestion de nom : "pipeline de candidats", "pipeline de fil d'actualité", "pipeline de classement", "pipeline recsys".
4. Mettre en évidence les compromis. Multi-action vs unique, isolé vs conjoint, en ligne vs hors ligne — ne jamais choisir par défaut en silence.
5. Le scaffold généré doit s'exécuter. Pas de pseudo-code qui se fait passer pour du code.
6. L'ordre des filtres compte. Peu coûteux avant coûteux. Universel avant spécifique à l'utilisateur.
7. Les effets secondaires ne bloquent jamais. Enveloppez-les dans des modèles de type "fire-and-forget" (goroutines / promesses sans await / tâches asyncio).

Anti-modèles

• Scoring avant filtrage (gaspille du calcul sur des candidats qui seront de toute façon supprimés)
• Effets secondaires synchrones (écritures de cache / émissions d'impression bloquant la réponse)
• Un score unique de "pertinence" alors que le produit doit s'ajuster pour plusieurs objectifs (engagement vs sécurité vs diversité vs publicité)
• Scoring conjoint par défaut (non déterministe, plus difficile à mettre en cache, ne se compose pas avec les étapes de ré-ordonnancement)
• Générer du pseudo-code "pour illustration" — le scaffold doit réellement s'exécuter

Contenu amont

Le dépôt amont à l'adresse https://github.com/mturac/recsys-pipeline-architect fournit :

• SKILL.md complet avec l'intégralité du workflow en 8 étapes
• 5 documentations de référence chargées à la demande : interfaces dans 4 langages (TS/Go/Python/Rust), modèle de scoring multi-action, isolation des candidats, recueil de filtres (12 modèles), recueil de scoreurs (somme pondérée, MMR, pénalité de diversité, débiais de position)
• 3 exemples de scaffolds exécutables, tous verts sur leur suite de tests :
  • Plugin Strapi v5 (TypeScript / Jest — 3/3 réussis)
  • Pipeline compatible Zentra (Go avec génériques — 3/3 réussis)
  • Priorisateur de tâches PMAI (Python / FastAPI / pytest — 3/3 réussis)
• Version v0.1.0 taguée
• Licence MIT ; modèle attribué à l'algorithme X For You de xAI (Apache 2.0)

Installation via skills.sh : npx skills add mturac/recsys-pipeline-architect