Guide essentiel pour garantir la fiabilité lors de l’adoption d’API de langage naturel en production (Microsoft Developer Community)

Principes clés

• Lors de la mise en place d’une API de langage naturel en production, il est indispensable de séparer semantic parsing et execution
• Les LLM ne doivent être utilisés que pour convertir le langage naturel en requêtes structurées canoniques (canonical structured requests)
• Le langage naturel doit être traité uniquement comme une entrée, et non comme un contrat d’API (le langage est fragile)

Problèmes liés à l’utilisation directe du langage naturel

• Comportement non déterministe (nondeterministic behavior)
• Logique métier basée sur les prompts → difficile à déboguer et à reproduire
• Contrat d’API implicite → de petits changements peuvent modifier le fonctionnement
• Apparition d’échecs silencieux (silent failures), rendant le système vulnérable

Architecture : séparation en deux couches

1. Semantic Parse API (langage naturel → structure)

• Accepte les entrées textuelles des utilisateurs
• Extrait l’intention et les entités avec un LLM
• Complète un schéma prédéfini
• En cas d’informations insuffisantes, pose une question de clarification (sans exécuter la logique métier)
• Joue le rôle d’un compilateur (p. ex., “blue backpack but cheaper” → {intent: “recommend_similar”, reference_product_id: “blue_backpack_123”, price_bias: -0.8})

2. Structured Execution API (structure → exécution)

• N’accepte que des entrées structurées
• Déterministe, versionnée et testable
• Ne traite pas le langage naturel et joue le rôle d’un backend fiable

Élément principal : Canonical Schemas

• Contrat défini dans le code pour chaque intention (champs obligatoires/facultatifs, plages de valeurs, règles de validation)
• Absorbe les variations du langage naturel → garantit une sortie cohérente
• Sert de colonne vertébrale au contrat d’API

Schema Completion (Clarification)

• En cas d’informations insuffisantes, réponse needs_clarification (champs manquants, question ciblée, état courant)
• Gestion de la mémoire via un objet d’état (l’API est stateless)
• Le client transmet l’état pour maintenir la conversation → exécution de canonical_request une fois le schéma complété

Orchestration : utilisation de LangGraph

• Modélisation d’un workflow structuré (classification de l’intention → extraction des entités → fusion du schéma → validation → routage vers complétion/clarification)
• Les décisions sont prises dans le code, le LLM ne fait que proposer
• Transitions d’état claires, observabilité et retries sûrs

Garde-fous : Confidence Gates

• Exiger un score de confiance pour les sorties du LLM
• Si le seuil n’est pas atteint, bloquer l’exécution et demander une clarification (p. ex., “the bag” ambigu → faible confiance → question supplémentaire)
• Empêche les mauvaises interprétations silencieuses

Normalisation : Lightweight Ontologies

• Basées sur le code (intentions autorisées, mappings de synonymes, validation croisée entre champs)
• Les valeurs proposées par le LLM sont normalisées dans le code (p. ex., “cheaper” → price_bias: -0.7)
• En cas d’incohérence logique, demander une clarification (p. ex., question sur la priorité entre faible prix et haute qualité)

Considérations de performance

• Latence : classification d’intention ~40 ms, extraction d’entités ~200 ms, validation 1 ms → total 250300 ms
• Acceptable pour une UX de chat, et moins coûteux que les erreurs

Principaux enseignements (Key Takeaways)

• Le langage n’est pas un contrat d’API, il doit être converti en structure
• Le serveur doit maîtriser la complétion du schéma
• Le LLM ne sert qu’à la découverte et à l’extraction, pas à l’exécution
• La sécurité et le déterminisme sont prioritaires
• Basé sur une expérience réelle de construction de systèmes avec Azure OpenAI + LangGraph

https://aisparkup.com/posts/9012