Améliorer la fiabilité de l’IA conversationnelle grâce à un routage contrôlé des fonctions

Introduction

Les systèmes d’IA conversationnelle modernes sont capables de générer des réponses fluides, mais la création d’assistants fiables orientés vers des tâches nécessite plus que de simples capacités de génération de langage naturel. Bien que l’interface de fonction-calling d’OpenAI représente un progrès important en permettant aux grands modèles de langage (LLM) de sélectionner les fonctions backend appropriées et de renseigner les arguments JSON, les implémentations pratiques atteignent généralement seulement 90% de précision dans la sélection des outils. Pour les applications de recherche et de e-commerce, chaque appel mal dirigé se traduit par une perte de revenus ou une mauvaise expérience utilisateur, ce qui rend ce seuil de précision insuffisant.

Pour atteindre 99% de fiabilité, nous avons repensé l’architecture du système en limitant le rôle du LLM à la seule compréhension du langage naturel. Une couche d’orchestration dédiée gère l’interaction entre le modèle et la logique métier via trois composants :

1. Routeur d’intention : des règles de classification déterministes ou des modèles spécialisés déterminent quelle API invoquer.
2. Reconstruction de schéma : des validateurs de type et un remplissage des paramètres basé sur des modèles garantissent que tous les arguments respectent les exigences syntaxiques et sémantiques avant les appels API.
3. Boucles de secours : lorsque des arguments requis sont manquants, le système demande automatiquement des précisions à l’utilisateur et réessaie l’opération.

Cette approche explicite et modulaire offre un contrôle granulaire, une traçabilité complète et la possibilité de corriger facilement les erreurs. Le système résultant maintient la fluidité conversationnelle tout en offrant la fiabilité des interfaces programmatiques traditionnelles.

Cet article illustre ce schéma à travers la mise en œuvre complète d’un chatbot prenant en charge trois fonctions courantes du commerce de détail :

• Recommandation de produits : recherche classique de produits via des requêtes en langage naturel.
• Suivi de commande : demande du statut d’une commande.
• Localisation de magasin : obtention de l’adresse du magasin le plus proche.

Ce cadre s’étend au traitement des retours, aux réclamations de garantie, aux recommandations personnalisées et à d’autres scénarios nécessitant des interfaces conversationnelles avec une intégration API fiable.

Améliorer la recherche e-commerce grâce au routage contrôlé des fonctions

L’un des principaux avantages de la solution proposée est son extensibilité : elle s’insère simplement entre l’interface client (page web) et le backend.

Les systèmes de recherche par mots-clés traditionnels, y compris ceux enrichis par la recherche vectorielle, font face à quatre défis fondamentaux qui impactent la performance commerciale. Le routage contrôlé répond à chacun de ces défis de façon systématique :

1. Décalage de vocabulaire et pont sémantique : Les clients utilisent rarement la taxonomie exacte des marchands. Des termes comme « cheminée », « poêle à bois » ou « foyer » peuvent référer à la même catégorie de produits, mais la recherche lexicale les traite comme des entités distinctes. En traitant toutes les requêtes via un LLM pour en extraire le sens sémantique (par exemple, {category:"fire_stove"}) et en transmettant cette intention normalisée aux API de catalogue, le système élimine les variations de synonymes et retourne systématiquement des résultats pertinents.
2. Traitement des requêtes longues pour extraction de signal: Prenons la requête : « Je cherche un cadeau pour mon fils de 18 ans qui aime les vélos bleus et la randonnée. » Les moteurs bag-of-words accordent un poids égal à tous les mots, même ceux sans importance. Le routage contrôlé extrait les informations essentielles sous forme structurée, permettant aux moteurs de recherche de recevoir de propres filtres structurés au lieu d’un texte bruité.
3. Adoption de filtres avancés via la conversation : Si les utilisateurs aguerris comprennent les recherches à facettes, la plupart évitent les interfaces de filtres complexes. Le chatbot collecte naturellement les critères de filtrage au fil de la conversation (« Bleu, oui. Plutôt ville ou BMX, pas montagne. Il roule surtout en ville. ») puis exécute automatiquement la requête avancée. Les utilisateurs bénéficient d’une expérience naturelle, tandis que les équipes merchandising reçoivent des données analytiques précises.
4. Résolution d’intentions multiples en réponse unifiée : quand un client demande « profondeur d’étanchéité de l’iPhone 15 Pro », la recherche traditionnelle doit choisir entre fournir la spécification ou suggérer des produits. Le routage contrôlé gère les deux intentions simultanément : l’orchestrateur identifie le besoin d’information technique et de recommandation produit, effectue une génération augmentée par récupération (RAG) sur la documentation pour fournir « IP68, 6 mètres pendant 30 minutes », et ajoute un carrousel de produits disponibles. Cette approche satisfait plusieurs besoins sans changer d’interface.

Architecture de routage conversationnel par couches

L’architecture proposée remplace les approches monolithiques par une chaîne de routage en couches, positionnant un contrôleur léger et déterministe entre le LLM et toutes les API aval. Chaque couche a une responsabilité unique et bien définie (détection d’intention, complétion de paramètres, exécution métier), ce qui garantit que les échecs restent isolés, traçables et corrigibles.

Dans ce schéma, le LLM est limité à son point fort : l’interprétation du langage naturel. Toutes les décisions concernant la sélection des outils, la validation des entrées et la gestion des erreurs sont prises par des composants de code explicites et testables. On obtient ainsi un système conversationnel qui conserve la qualité d’interaction naturelle des solutions LLM de bout en bout, tout en atteignant les standards de fiabilité exigés par les entreprises.

Couche de détection d’intention

« Cibler le sujet, pas la syntaxe »

Avant toute opération fonctionnelle, le système doit déterminer la demande réelle de l’utilisateur. Ce processus comporte deux étapes :

1. Condensation de la conversation : Plusieurs messages, clarifications et prompts système sont condensés en un résumé concis (une ou deux phrases), garantissant des prompts ultérieurs brefs, économiques et riches en contexte. Ces résumés sont mis en cache pour l’efficacité. Si l’utilisateur modifie un détail (« en fait, c’est la commande 59-A, pas 59-B »), seul l’élément concerné est mis à jour.
2. Classification de l’intention : Le résumé condensé est traité par un classificateur léger (prompting few-shot, petits modèles spécialisés ou heuristiques regex pour MVP), qui produit une étiquette unique parmi un ensemble prédéfini (PRODUCT_SEARCH, ORDER_STATUS, STORE_LOCATION). La nature déterministe de cette tâche permet de remplacer le classificateur sans impacter les autres composants et de suivre la précision en temps réel.

Bénéfices :

• Routage accéléré : la synthèse réduit la consommation de tokens et la latence.
• Traçabilité complète : chaque tour de dialogue est logué avec l’intention et le score de confiance.
• Maintenance efficace : les erreurs de routage se corrigent en ajustant le classificateur, sans devoir réentraîner le modèle principal.

Couche d’analyse de la demande

« Remplir les blancs, poliment »

Après identification de l’intention, le système a besoin d’arguments complets et valides pour l’API concernée. Cette couche met en œuvre un sous-pipeline dédié en trois étapes :

1. Extraction spécifique au cas d’usage : Chaque intention utilise un prompt ou des règles dédiées pour identifier les paramètres candidats dans le résumé. La valeur la plus récente pour chaque champ est priorisée, évitant la rétention d’informations obsolètes (« bleu… non, finalement rouge »). La modularité de ces prompts permet leur itération, traduction ou remplacement indépendants.
2. Vérification de complétude : Un schéma définit les champs obligatoires, optionnels et mutuellement exclusifs pour chaque appel API. Si des champs obligatoires manquent, le système génère des questions de relance automatiques (« Je peux vérifier cette commande, pouvez-vous me donner le numéro ? ») jusqu’à satisfaction ou abandon de l’utilisateur.
3. Validation et nettoyage des entrées : Regex et validateurs de type détectent les entrées malformées (emails, téléphones, codes postaux, numéros de commande). En cas d’échec, le système demande une correction en langage naturel. Les valeurs validées sont transmises sous forme structurée au backend.

Bénéfices : 

• Séparation des responsabilités : le LLM gère le langage naturel, la qualité des données est assurée par du code déterministe.
• Extensibilité sûre : ajouter une intention nécessite seulement un nouvel extracteur, pas de modifier toute l’architecture.

Couche de logique métier

« Exécuter et expliquer »

Une fois l’intention identifiée et les paramètres validés, la dernière couche accomplit deux fonctions principales :

1. Orchestration API : Les objets d’arguments propres sont routés vers les microservices appropriés (catalogues produits, gestion de commandes, localisation de magasins), avec gestion centralisée des retries, timeouts et authentification.
2. Génération de réponse : Les payloads JSON du backend sont formatés via des appels LLM dédiés à la mise en forme naturelle (« Votre commande 59-A a été expédiée le 14 juin et arrivera demain »). Pour la recherche produit, les résultats peuvent être enrichis de tableaux markdown ou de carrousels.

Bénéfice principal :

• Observabilité accrue : tous les appels API sortants et payloads entrants peuvent être logués, monitorés ou rejoués sans prompts LLM supplémentaires, maintenant le debugging dans les outils DevOps standards

Conclusion

Les grands modèles de langage offrent des capacités de compréhension du langage naturel sans précédent, mais la compréhension seule ne garantit pas l’exécution fiable. Dans les applications e-commerce critiques, où chaque erreur de routage API peut entraîner une perte de transaction ou un échec du support, la fiabilité doit tendre vers la perfection. L’architecture présentée montre comment concilier ces deux objectifs : des interactions naturelles et conversationnelles pour les clients, et des performances déterministes et auditables pour les équipes techniques.

En décomposant le système en trois couches spécialisées (détection d’intention, analyse de la demande, logique métier), le rôle du LLM est limité à l’interprétation sémantique, tandis que toutes les décisions irréversibles sont confiées à du code vérifiable. Cette approche apporte des améliorations mesurables :

1. Précision accrue : des tests montrent plus de 99,9 % de précision dans la sélection des outils, contre environ 90 % pour les approches monolithiques.
2. Développement accéléré : nouveaux intents et règles de validation facilement déployables.
3. Visibilité opérationnelle : logs propres, scoring de confiance et payloads validés s’intègrent sans friction à l’infrastructure DevOps existante.
4. Impact business : les requêtes complexes sont résolues efficacement en résultats précis, mises à jour de commande et services de localisation, améliorant satisfaction client et chiffre d’affaires.

Le design agnostique du framework permet une large application : remplacer « recherche produit » par « consultation de police », « création de ticket » ou « réservation de voyage » ne requiert aucune modification architecturale. Tout scénario nécessitant une entrée conversationnelle vers une exécution API bénéficie de la stabilisation du comportement LLM par le routage contrôlé.

Lors du développement de fonctionnalités conversationnelles, évitez de tout faire passer par un unique prompt « intelligent ». Exploitez les modèles pour l’extraction de sens humain, et le code traditionnel pour les tâches machine : décisions déterministes, validation des entrées, invocation de services. Cette approche produit des assistants conversationnels intuitifs et prévisibles, transformant les demandes clients en résultats business mesurables.