Le parcours de Shopify vers la structuration des données : du one-shot LLM à une architecture agentique fondée sur DSPy

Shopify a abandonné l’approche One-Shot LLM au profit d’une architecture multi-agents spécialisée fondée sur DSPy afin de transformer des millions de données e-commerce non structurées (pages de boutique, politiques, etc.) en données structurées. Dans ce processus, au lieu de modèles géants du niveau de GPT-4/5, l’entreprise a utilisé des modèles Qwen auto-hébergés (classe 32B/72B) et l’optimiseur Japa de DSPy, obtenant un coût réduit de 75 fois tout en doublant la qualité de l’extraction de données. Le point clé est qu’une structure de sous-agents spécialisée par objectif précis (détection de fraude, profilage de boutique, etc.) a été déterminante pour améliorer les performances, davantage qu’un agent unique.

---

Résumé sur second

Analyse approfondie (Deep Dive)

1. Contexte du problème : un déluge de données non structurées

Shopify offre une flexibilité extrême aux marchands. Cela signifie que la structure HTML, la langue et la façon de présenter les politiques varient totalement d’une boutique à l’autre. Même pour des questions simples comme « cette boutique vend-elle des téléphones portables ? » ou « quelle est sa politique de retour ? », il était très difficile d’obtenir des réponses standardisées à l’échelle de l’entreprise.

2. Évolution de la solution

• Étape 1 : One-Shot LLM (approche initiale)
  • Extraction du texte des pages principales de la boutique, puis envoi à GPT-4 (ensuite 5) avec une demande d’extraction selon un schéma.
  • Limites : impossible d’envoyer toutes les pages à cause de la limite de fenêtre de contexte (si la page de politique de retour manque, aucune réponse possible). À mesure que des champs sont ajoutés, le prompt devient fragile et le coût augmente de façon exponentielle.
• Étape 2 : approche agentique et adoption de DSPy
  • Au lieu de donner toutes les données au LLM, Shopify a adopté une architecture d’agent ReAct dotée d’« outils » (navigation, investigation) lui permettant d’explorer la boutique et de trouver lui-même les informations nécessaires.
  • Dans ce cadre, DSPy a été introduit afin de passer d’un réglage manuel des prompts à une optimisation programmée.
• Étape 3 : sous-agents spécialisés (Specialized Sub-Agents)
  • Au lieu qu’un seul agent traite tous les objectifs (fraude, fiscalité, profilage), la tâche a été séparée en trois agents spécialisés.
  • Fraud Agent : utilise un outil de recherche sur des sites externes d’avis.
  • Profile Agent : se concentre sur l’analyse des politiques internes.
  • Chaque agent est optimisé indépendamment via DSPy, ce qui permet d’améliorer les performances sans interférences entre eux.

3. Solution technique : fiabilité des évaluations et snapshotting

Quand les agents explorent des sites web en temps réel, la fiabilité du dataset d’évaluation (golden dataset) se dégrade dès que le contenu du site change. Pour résoudre ce problème, Shopify a construit un service de snapshot appelé « ShopNap ».

• L’état de la boutique au moment du labelling est figé de manière statique (frozen context).
• L’optimiseur DSPy s’exécute sur ces snapshots figés, garantissant une évaluation et un apprentissage reproductibles.

4. Architecture d’infrastructure

Pour un traitement efficace, l’exploitation est divisée en trois couches.

• Batch Layer (Flink) : gère plus de 150 000 requêtes quotidiennes de traitement de boutiques.
• Agent Layer (Kubernetes) : exécute la logique des agents, le parsing HTML et les appels d’outils sur un cluster CPU.
• LLM Layer (GPU Cluster) : fournit des modèles Qwen auto-hébergés via vLLM, entre autres.

---

Données clés et benchmarks

Voici les chiffres de comparaison de performances et de coûts communiqués par Shopify avant et après le changement d’architecture.

Élément	One-Shot (GPT-5 estimé)	Agentic + DSPy + Qwen
Coût	Point de référence (élevé)	réduit à 1/75
Qualité	Point de référence	environ 2x (amélioration de 100 %)
Couverture des boutiques	Partielle (limitée par le coût)	toutes les boutiques (Full Coverage)
Scalabilité	Revalidation complète requise à chaque ajout de champ	extension simple par ajout de sous-agents

Enseignements clés

1. Monolithic vs specialized : plus la tâche est complexe, plus des sous-agents avec séparation des responsabilités (Separation of Concerns) sont avantageux par rapport à un agent unique [21:59].
2. Architecture over Tuning : plutôt que de corriger la formulation de prompts individuels, définir la bonne architecture système et y appliquer une optimisation automatisée (DSPy) garantit des performances durables [23:24].
3. Small Models Win : sur des tâches de domaine spécifiques, des modèles petits ou intermédiaires optimisés et auto-hébergés peuvent surpasser des modèles géants généralistes à la fois en coût/performance et en qualité [23:54].