Sources de régression en production

Page en construction

Comprendre pourquoi un agent conversationnel RAG peut voir ses performances se dégrader en production, et l'importance du cycle d'évaluations continu

Un agent conversationnel RAG peut afficher des résultats moins bons en production pour de nombreuses raisons, qui tiennent autant à l’évolution du contexte réel d’usage qu’aux contraintes techniques et organisationnelles.

Un système RAG ne “se dégrade” pas spontanément en production : il est exposé à des usages réels, des données vivantes et des contraintes opérationnelles que seule une évaluation continue permet de maîtriser. Pour appuyer l'importance de mesurer régulièrement la qualité du système et l'ensemble des composants, voici quelques facteurs d'explication d'une dégradation de la satisfaction des utilisateurs.

Écart entre les usages réels et les hypothèses de conception

En production, les utilisateurs posent :

• des questions plus variées, ambiguës ou mal formulées ;
• des demandes hors périmètre initial ;
• des questions multi-intentions ou conversationnelles longues.

Le jeu de tests initial ne couvre pas toujours cette diversité, ce qui dégrade la pertinence perçue des réponses.

Évolution ou dérive de la documentation (data drift)

La base documentaire évolue en continu :

• ajout de nouveaux documents ;
• mise à jour ou suppression de contenus existants ;
• coexistence de versions contradictoires.

Ces changements peuvent altérer la qualité du retrieval, introduire du bruit ou des incohérences, sans modification du modèle lui-même.

Problèmes de retrieval à l’échelle

À mesure que le volume de documents augmente :

• les embeddings deviennent moins discriminants ;
• le moteur de recherche remonte plus de documents non pertinents ;
• le contexte fourni au LLM se dégrade.

Même un bon modèle de génération ne peut compenser un mauvais contexte.

Contraintes de performance et d’optimisation en production

En production, des arbitrages sont souvent faits sur :

• la taille du contexte ;
• le nombre de documents récupérés ;
• le modèle utilisé (coût / latence).

Ces optimisations peuvent réduire la qualité par rapport à l’environnement de test.

Évolution du modèle ou des dépendances techniques

• mise à jour du LLM (nouvelle version, nouveau fournisseur) ;
• modification des embeddings ;
• évolution des librairies ou des paramètres par défaut.

Ces évolutions peuvent introduire des régressions invisibles sans évaluation systématique.

Effets de charge et de montée à l’échelle

Sous forte charge :

• augmentation de la latence ;
• timeouts ;
• comportements dégradés ou incomplets.

L’expérience utilisateur se dégrade, même si la qualité intrinsèque reste correcte.

Problèmes de sécurité et de garde-fous

En production :

• manœuvres visant à contourner les règles ou les limites, exploitation des failles techniques de l'outil
• prompts utilisateurs imprévus ;
• conflits entre règles de sécurité et qualité de réponse.

Des garde-fous trop stricts ou mal calibrés peuvent conduire à des refus excessifs ou à des réponses vagues.