Flux de travail déterministes vs agents : leçons tirées de la création d'un assistant d'achat

Enseignements sur les workflows déterministes, le raisonnement agentique et la gestion d'état

La création d'assistants IA commence souvent par un problème d'une simplicité trompeuse. Un utilisateur pose une question, le système récupère les informations et un LLM génère une réponse. La première version fonctionne généralement de manière étonnamment efficace.

Le véritable défi apparaît à mesure que les capacités s'étendent. Avec l'introduction de nouveaux outils et workflows, les utilisateurs commencent à poser des questions couvrant plusieurs domaines. Les conversations deviennent plus longues et plus contextuelles, transformant l'assistant d'un simple bot de questions-réponses en un outil aidant les utilisateurs à accomplir des tâches complexes.

Chez TrueFoundry, nous avons été confrontés à ce défi précis lors de la création d'un assistant d'achat conversationnel. L'assistant a débuté comme un compagnon de page produit (PDP) capable de répondre à des questions sur un seul article. Au fil du temps, il a évolué pour devenir un assistant d'achat complet, capable de gérer la découverte de produits, la recherche, la synthèse d'avis, l'application de coupons, la localisation de magasins, la vérification des stocks, le choix de la livraison et les opérations de panier.

Si les capacités externes se sont considérablement développées, les défis techniques les plus critiques sont apparus dans deux domaines :

1. Déterminer quand utiliser des workflows déterministes plutôt qu'un raisonnement agentique.
2. Faire évoluer la gestion d'état d'un modèle de conversation mono-produit vers une expérience d'achat multi-produits.

1. Aperçu de l'architecture système

L'assistant d'achat repose sur quatre couches architecturales majeures conçues pour équilibrer performance, coût et fiabilité.

A. Couche de données

Le système maintient une séparation stricte entre les systèmes de stockage structurés et non structurés :

• Catalogue produits : stocké dans PostgreSQL (Cloud SQL), contenant les métadonnées des produits, les prix, les variantes, les informations de catégorie et les métadonnées de livraison.
• Avis : les avis clients sont stockés dans Qdrant. Cela permet une recherche sémantique du contenu des avis plutôt que de dépendre uniquement de la correspondance par mots-clés. Lorsque les utilisateurs posent des questions sémantiques telles que « Que disent les clients sur l'autonomie de la batterie ? », le système récupère les avis pertinents et génère un résumé basé sur des preuves.

B. Pipeline d'ingestion de données

Les données de catalogue et d'avis arrivent en continu via Google Cloud Storage (GCS) et sont traitées par des pipelines Google Dataflow :

• Pipeline de catalogue : GCS → Dataflow → Cloud SQL (traitement quotidien).
• Pipeline d'avis : GCS → Dataflow → Génération d'embeddings → Qdrant (traitement quotidien et horaire pour des retours clients actualisés).

C. Couche Modèle

Toutes les interactions avec les modèles sont acheminées via la TrueFoundry AI Gateway. Celle-ci offre un accès centralisé aux modèles, ainsi que des fonctionnalités d'observabilité, de gouvernance, de suivi des coûts, de limitation de débit et d'abstraction des modèles. L'assistant utilise les modèles Gemini 2.5 Flash et Qwen pour équilibrer latence, qualité et coûts opérationnels.

D. Couche d'orchestration

Le flux de travail conversationnel est orchestré à l'aide de LangGraph, qui permet des transitions d'état explicites et une gestion des flux tout en prenant en charge à la fois les chemins d'exécution déterministes et le raisonnement par agents.

2. Défi n°1 : Flux de travail déterministes vs agents

Une tendance courante dans les systèmes d'IA consiste à tout automatiser par des agents, en partant du principe qu'un LLM capable de raisonner devrait tout gérer. En production, une approche purement basée sur des agents devient rapidement coûteuse, lente et difficile à contrôler.

Nous avons divisé les interactions d'achat en deux paradigmes d'exécution distincts, basés sur des compromis clairs en termes de performance et d'intention :

Sous le capot : La mécanique d'exécution

Le choix architectural de séparer ces flux est fortement dicté par les boucles internes, le nombre total d'appels LLM et la surcharge liée au traitement des jetons.

[ReAct Loop]          
--> (1. Complex Tool-Selection Prompt) 
--> [Tool Call] 
--> (2. Synthesis Prompt) 
[Deterministic Flow]  
--> [Tool Call] 
--> (1. Light Formatting Prompt) 

Le cycle de vie de l'agent ReAct (boucle en 3 étapes)

Pour les flux de travail complexes, un agent ReAct dédié gère l'exécution de manière dynamique via un cycle en trois étapes :

1. Étape 1 : Le prompt de planification (appel LLM) : Le système transmet la requête de l'utilisateur accompagnée de prompts système contenant les définitions de tous les outils disponibles. Le LLM doit analyser la demande de l'utilisateur, identifier l'outil à utiliser et extraire les paramètres exacts requis pour cet outil.
2. Étape 2 : L'exécution de l'outil : Le système exécute l'outil ou l'appel API correspondant en utilisant les paramètres extraits.
3. Étape 3 : Invite d'observation et de synthèse (appel LLM) : La réponse brute de l'outil est renvoyée au LLM. Le modèle évalue cette réponse par rapport à la question initiale de l'utilisateur et la transforme en une réponse claire et contextuelle.

Le cycle de vie déterministe (raccourci en 2 étapes)

Les fonctionnalités telles que les spécifications de produits, les avis et les coupons ne nécessitent pas de raisonnement sur le choix des outils ou l'ordre d'exécution. Pour optimiser les performances, nous contournons entièrement la phase de planification :

1. Étape 1 : Exécution directe de l'outil : Comme la classification de l'intention renvoie directement à un outil connu, le premier appel d'invite LLM est totalement ignoré. Le système exécute l'outil immédiatement, ce qui supprime un cycle d'inférence complet et réduit le temps jusqu'au premier octet (TTFB).
2. Étape 2 : Synthèse de la réponse (appel LLM) : Le système transmet les données brutes de l'outil et la requête de l'utilisateur directement à une invite hautement ciblée afin de formater la réponse finale.

La latence et la pénalité liée à la complexité des invites

Au-delà du nombre d'appels, la complexité de l'invite détermine de manière significative la vitesse de réponse :

• Charge de l'invite ReAct : À l'étape 1 d'un agent ReAct, l'invite est très complexe. Le LLM doit examiner plusieurs outils, évaluer la logique d'exécution et maintenir le contexte. Cette charge cognitive élevée augmente le temps de traitement des jetons et la latence de génération.
• Efficacité de l'invite déterministe : Dans un flux déterministe, l'invite finale est simple : « Voici la question et voici la réponse brute de l'outil. Donnez la réponse. » Comme le modèle n'a pas besoin d'évaluer des chemins ou de suivre des outils, la génération de jetons est rapide et légère.

Leçon principale : Imposer une boucle de raisonnement ReAct à des requêtes de données simples ajoute une latence, un coût et une complexité opérationnelle inutiles sans améliorer la qualité de la réponse. Si une interaction peut être traitée de manière déterministe, elle doit être.

Encadrer les agents ReAct

Là où les chemins déterministes échouent (par ex., « Puis-je l'obtenir aujourd'hui ? » impliquant la résolution de localisation, la découverte de magasins et les vérifications de traitement des commandes), les agents ReAct sont essentiels. Cependant, les agents entièrement autonomes produisent souvent des expériences client incohérentes. Pour garder le contrôle, TrueFoundry a mis en place des étapes de flux de travail structurées au sein des agents dynamiques :

• Étapes de l'agent d'inventaire : Résolution de localisation → Sélection du magasin → Vérification des stocks → Explication du résultat.
• Étapes de l'agent d'achat : Validation du produit → Vérification des stocks → Sélection du mode de traitement → Opération sur le panier → Confirmation.

3. Défi n° 2 : Évolution de la gestion d'état

Passer d'un assistant de page produit unique à un compagnon d'achat couvrant tout le catalogue est fondamentalement un problème de gestion d'état.

• Phase 1 (État d'un produit unique) : Le contexte du produit était implicitement dérivé de la page active. Le modèle d'état était un simple fil de conversation linéaire.
• Phase 2 (Conversations multi-produits) : La recherche dans le catalogue permet aux utilisateurs d'introduire, de comparer et de basculer entre plusieurs produits simultanément.

Pour évoluer sans fragiliser le système, l'architecture d'état a été entièrement repensée selon quatre principes de conception clés :

1. Séparation des portées d'état

Mélanger les données utilisateur avec des données produit transitoires crée des systèmes fragiles. L'état a été refactorisé en limites distinctes :

• État au niveau de l'utilisateur : Persistant tout au long de la session d'achat (par ex., magasin favori, préférences de localisation, choix de traitement des commandes).
• État au niveau du produit : Lié à des articles spécifiques (par ex. métadonnées du catalogue, coupons actifs, avis).

2. Suivi explicite du contexte (current_product_id)

Nous sommes passés d'un contexte produit implicite à un contexte explicite en introduisant current_product_id comme variable d'état de premier ordre. Lorsqu'un utilisateur change d'article, la mise à jour de cet identifiant unique vide et actualise automatiquement les données du catalogue, les avis, les coupons et les variables d'inventaire en aval.

3. Mémoire de thread spécifique à l'agent

Le maintien d'un tableau unique et plat conversation_history = [] générait un bruit de jetons massif et dégradait les performances du modèle. Les conversations de recherche nécessitent des fenêtres de contexte totalement différentes de celles des opérations de paiement final. La mémoire a été directement intégrée dans des threads d'agents isolés (Recherche, Inventaire, Achat, Produit) afin de minimiser la pollution inter-contexte.

4. Résolution de référence produit

La classification de l'intention seule est insuffisante lorsqu'on traite un catalogue mondial. Lorsqu'un utilisateur demande « Est-ce disponible près de chez moi ? », le système s'appuie sur une couche de résolution de référence produit nouvellement introduite pour déduire mathématiquement à quel article « ce » fait référence, évaluer si la requête est ambiguë et décider si une demande de clarification est nécessaire.

Enseignement architectural clé : L'état doit représenter les flux de travail (Recherche, Inventaire, Achat) plutôt que les domaines de données (Avis, Coupons, Produits). Concevoir l'état autour de l'intention de l'utilisateur et de la progression du flux de travail simplifie considérablement l'orchestration et réduit la complexité du suivi multi-agents.