Dérive des modèles d'IA : le coût caché des déploiements d'entreprise reposant sur un seul modèle LLM

Il se peut que le modèle que vous avez déployé l'année dernière ne soit plus celui qui est actuellement utilisé. Les fournisseurs mettent à jour, remplacent et retirent les modèles selon leur propre calendrier, et les réponses de vos clients évoluent en conséquence.

La dérive d'un modèle d'IA désigne la dégradation des performances qui survient lorsqu'un fournisseur met à jour, remplace ou abandonne le modèle sous-jacent, ce qui entraîne une variation de la qualité des réponses et nécessite des opérations de redéploiement.

Les entreprises qui se sont appuyées sur un seul modèle de langage de grande envergure (LLM) subissent chacune de ces évolutions, qu'elles les aient prévues ou non. Le modèle constituant la base du système, toute modification de celui-ci entraîne une adaptation de l'ensemble du déploiement.

Points clés à retenir

• La dérive d'un modèle d'IA désigne la dégradation des performances qui survient lorsque les fournisseurs mettent à jour, remplacent ou abandonnent le modèle sous-jacent, ce qui entraîne des variations dans la qualité des réponses et engendre des coûts de redéploiement.
• Les déploiements basés sur un seul modèle LLM sont, par nature, exposés à des risques. L'entreprise subit chaque modification apportée au modèle selon le calendrier du fournisseur, et non selon le sien.
• Une architecture indépendante du modèle considère la couche modèle comme interchangeable ; elle évalue en permanence les modèles disponibles et passe de l'un à l'autre sans perturber l'expérience client.
• Lorsque les réponses s'appuient sur des connaissances contrôlées et liées à des sources, plutôt que d'être générées par un seul modèle lors de l'exécution, la qualité reste constante quel que soit le modèle utilisé. Cela permet de garantir une précision justifiable dans le cadre d'une expérience client réglementée.
• Découvrez comment Encore garantit la pérennité de l'expérience client (CX) malgré les changements de modèle.

Qu'est-ce que la dérive d'un modèle d'IA ?

La dérive d'un modèle d'IA désigne une dégradation des performances due à des modifications apportées au modèle sous-jacent lui-même, lorsque le fournisseur le met à jour, le rend obsolète ou le remplace. Elle se distingue des changements intervenant au niveau des données d'entrée.

Le mécanisme est simple. Une version du modèle sur laquelle votre déploiement a été optimisé est retirée ou modifiée, ce qui entraîne une évolution des résultats.

Parfois, le changement est subtil : une nuance de ton ou une modification de mise en page. Parfois, il est plus concret : une réponse différente à une question qui trouvait auparavant une solution claire.

Vous n’avez rien changé. Le sol s’est dérobé sous vos pieds. Dans un déploiement à LLM unique, il n’y a aucun tampon entre ce changement et votre client.

Pourquoi les déploiements basés sur un seul LLM sont vulnérables de par leur conception

Un déploiement basé sur un modèle donné hérite de la cadence de publication, des décisions de dépréciation, des modifications tarifaires et des changements de comportement propres à ce fournisseur. Vous vous alignez sur son calendrier, et non sur le vôtre.

L'environnement de développement n'est pas stable. Les fournisseurs publient de nouvelles versions, retirent les anciennes et modifient en permanence le comportement des applications, et chaque changement se répercute sur les déploiements en aval.

C'est là que réside le piège des hyperscalers. On propose aux grandes entreprises d'utiliser notre modèle au sein de notre cloud, et elles se retrouvent ainsi prisonnières d'une approche axée sur l'accès au modèle, sans couche de connaissances régie ni orchestration de l'IA spécifique à l'expérience client en arrière-plan.

Une architecture indépendante du modèle constitue la solution structurelle à cette vulnérabilité, et non une solution de contournement.

Les coûts cachés de la dérive des modèles

Les coûts liés à la dérive des modèles figurent rarement sur la facture. Ils se répercutent sur la main-d'œuvre, la qualité et les risques.

• Redéploiement et réajustement de la main-d’œuvre à chaque modification du modèle.
• Les écarts dans la qualité des réponses, qui sapent la confiance des clients et nuisent à leur satisfaction.
• La charge de travail liée aux tests de régression permet de détecter les changements de comportement avant que les clients ne s'en aperçoivent.
• Risque de non-conformité lorsqu'un chemin de réponse préalablement validé est modifié sans préavis.
• Un coût total de possession (TCO) qui fluctue de manière imprévisible et ne résiste pas à l'examen minutieux de la direction.

La cohérence est l'avantage qui se cache derrière tout cela. C'est en maintenant un niveau constant de qualité des réponses malgré les changements de modèle que l'on préserve l'amélioration de +30 % du taux de satisfaction client (CSAT) générée par une expérience stable.

La dérive du modèle n'est ni une dérive des données ni une dérive sémantique

On confond trois types de dérive. Il s'agit de problèmes distincts qui nécessitent des solutions différentes.

On parle de « dérive des données » lorsque les données d'entrée évoluent au fil du temps, de sorte qu'un modèle entraîné sur les tendances de l'année dernière interprète différemment celles de cette année.

On parle de « dérive sémantique » lorsque la signification des termes métier diverge d'un système à l'autre ; il s'agit davantage d'un problème de cohérence des données que d'un problème lié à l'IA.

On parle de « dérive du modèle » lorsque le modèle sous-jacent lui-même évolue alors que le déploiement reste stable. Les données d'entrée sont restées inchangées ; le modèle, lui, a évolué.

Ces trois éléments sont importants. Cet article porte sur le troisième, car c’est celui sur lequel un déploiement utilisant un seul modèle LLM exerce le moins de contrôle.

Pourquoi une architecture indépendante du modèle permet de neutraliser la dérive

La conception indépendante du modèle considère la couche modèle comme interchangeable. La plateforme évalue en permanence les modèles disponibles en fonction de chaque cas d'utilisation et peut passer de l'un à l'autre en temps réel.

Il en résulte une performance durable qui protège le client de la volatilité du marché des modèles. Le changement de modèle devient alors un événement interne, et non plus un événement visible par le client.

La commutation adaptative fait partie intégrante de ce processus. La plateforme alterne entre la recherche déterministe, où la précision est de mise, et les approches génératives, où la fluidité apporte une valeur ajoutée. Il s’agit là d’une fonctionnalité, et non d’un compromis.

Il s'agit de l'« intelligence programmée », qui s'appuie sur l'architecture à double LLM d'Encore, et qui constitue la solution au problème de dépendance vis-à-vis d'un fournisseur et au risque d'obsolescence des LLM.

La connaissance avant tout : pourquoi la réponse ne devrait pas dépendre du modèle

Une conception indépendante du modèle détermine quel modèle est utilisé. Une conception axée sur la connaissance détermine d'où provient la réponse, et c'est là la solution la plus profonde.

Lorsque les réponses s'appuient sur des intentions prédéfinies et liées à la source, plutôt que d'être générées par un modèle au moment même de l'interaction, la qualité des réponses reste constante, quel que soit le modèle utilisé en arrière-plan.

C'est ce qu'on appelle l'inversion « connaissance d'abord ». La connaissance structurée et régie vient en premier lieu, elle est construite grâce à l'ingénierie des connaissances, et le modèle est au service de celle-ci.

Le changement de modèle ne modifie pas la réponse validée, car le modèle n'a jamais été à l'origine de cette réponse. Cela permet d'atteindre une précision de +98 % dès le premier jour, grâce à un système de prévention des « hallucinations » intégré à l'architecture plutôt qu'ajouté a posteriori.

Comparez cela à une approche de conception axée sur les modèles, dans laquelle le modèle est à l'origine de la réponse et, par conséquent, à l'origine de la dérive.

La dérive des modèles dans le CX réglementé : un problème d'auditabilité, et pas seulement de performance

Dans les secteurs réglementés, un changement de modèle non annoncé ne constitue pas seulement un problème de qualité. C'est aussi un problème d'auditabilité.

Une procédure de réponse préalablement validée et justifiable peut être modifiée sans motif documenté, et il arrive désormais que la réponse examinée par l'autorité de régulation ne soit plus celle qui avait été approuvée.

Cette distinction est importante. « Sûr » signifie que le système ne causera aucun préjudice. « Vérifiable » signifie que l’on peut prouver ce qui s’est passé et pourquoi, même si les modèles évoluent en arrière-plan de l’interaction. C’est là toute la différence entre une « boîte de verre » et une « boîte noire ».

Une architecture indépendante du modèle et axée sur la connaissance permet de garantir que le processus décisionnel reste documenté et explicable, quel que soit le modèle utilisé, ce qui correspond aux exigences de transparence prévues notamment à l'article 13 de la loi européenne sur l'IA.

Écart par secteur d'activité : où le coût se fait le plus sentir

Services financiers. Une réponse validée relative à la divulgation ou à la gestion des dossiers qui subit une modification à la suite d'une mise à jour silencieuse du modèle constitue un risque en matière de conformité et de contrôle.

Des intentions vérifiables et liées à la source garantissent la validité des réponses dans les contextes du CFPB, de l'OCC et de la FDIC, quel que soit le modèle utilisé, conformément aux recommandations du CFPB relatives aux décisions fondées sur l'IA.

BBVA a transformé son service client grâce à la solution d'IA Inbenta, ce qui lui a permis de réduire de 84 % le nombre de cas renvoyés vers les niveaux supérieurs du service client.

Tourisme et hôtellerie. Les opérations à fort volume et multilingues, couvrant plus de 90 langues, amplifient le coût de tout écart de qualité lorsqu’un modèle change. La cohérence entre le chat, la voix et la recherche permet de préserver la satisfaction client (CSAT) à grande échelle.

GOL Airlines traite plus de 10 millions de demandes par an sur un marché naturellement multilingue, et Travel Club assure la cohérence des réponses standardisées sur tous les canaux.

Jeux d'argent et jeux en ligne, ainsi que solutions SaaS B2B destinées à une clientèle soumise à une réglementation. La résolution de niveau 1 et l'explicabilité multi-locataires doivent résister aux changements de modèle sans régression.

Lorsque les réponses sont gérées et associées à leur source, un changement de modèle ne remet pas en cause la conformité, et la traçabilité dont bénéficient vos clients reste intacte.

Comment évaluer la résilience d'une plateforme face à la dérive des modèles

Utilisez ces questions pour évaluer la résilience de n'importe quelle plateforme face à la dérive des modèles.

• La plateforme est-elle indépendante de tout modèle, ou est-elle liée à un seul fournisseur ?
• Les réponses s'appuient-elles sur des connaissances gérées et liées à des sources, ou sont-elles générées par le modèle au moment de l'exécution ?
• Qu'en est-il de la précision et des pistes d'audit lorsque le modèle sous-jacent change ?
• La plateforme est-elle capable d'évaluer les modèles et de passer de l'un à l'autre sans cycle de redéploiement ?
• Le parcours décisionnel reste-t-il traçable et justifiable après un changement de modèle ?
• Comment assure-t-on la cohérence entre les différents canaux et dans toutes les langues ?

Si la réponse honnête aux deux premières questions est « fournisseur unique » et « généré par un modèle », les autres tiennent rarement la route. Vous souhaitez mettre votre configuration actuelle à l'épreuve ? Testez-la à la lumière de vos propres cas d'utilisation.

Comment Encore garantit la pérennité de l'expérience client malgré les changements de modèle

Inbenta Encore est conçu de manière à ce que le modèle puisse évoluer sans que l'expérience client ne s'en trouve affectée.

• Conçu pour être indépendant des modèles. Encore évalue en permanence les modèles disponibles et peut passer de l'un à l'autre en temps réel, de sorte que la volatilité des modèles et des marchés reste un problème interne.
• La connaissance avant tout. Les réponses sont extraites d'intentions régulées et liées à des sources, structurées grâce à l'ingénierie des connaissances ; ainsi, le changement de modèle n'altère en rien la réponse validée.
• « Intelligence programmée », optimisée par l'architecture à double LLM d'Encore. La plateforme alterne entre la recherche déterministe et la fluidité générative en fonction du contexte, sans que l'opérateur ait à intervenir pour faire ce choix.
• Il s'intègre à votre substrat de modèle et à votre pile technologique. Encore est compatible avec Bedrock, Vertex AI et Azure-OpenAI en tant que couche de modèle, et s'intègre aux infrastructures existantes des centres de contact, y compris les environnements Genesys et IBM vieillissants, sans nécessiter de remplacement complet. L'IA vocale pour les centres de contact s'appuie sur la même base de connaissances régie.
• Une gouvernance transparente, intégrée dès la conception. Chaque réponse permet de remonter à l'intention initiale, même en cas de modifications du modèle, ce qui vous permet, ainsi qu'à votre responsable de la conformité, d'examiner les raisons pour lesquelles une réponse a été fournie.
• Des résultats durables, éprouvés en production. Une précision de +98 % dès le premier jour, une amélioration de +35 % du taux de résolution dès le premier contact, une augmentation de +30 % de la satisfaction client, un déploiement +75 % plus rapide et une recherche 2,5 fois plus rapide, dans plus de 90 langues et avec plus de 850 intégrations d'entreprise.

Inbenta Encore est une plateforme d'IA agentique unifiée qui a valu à Inbenta le TSIA Star Award dans la catégorie « Innovateur de l'année en matière de réussite client numérique ».

Le marché des modèles continuera d'évoluer. Mais votre expérience client n'a pas à suivre cette évolution. Découvrez comment Encore reste stable malgré les changements de modèles.

Foire aux questions

Qu'est-ce que la dérive d'un modèle d'IA ?

La dérive d'un modèle d'IA désigne une dégradation des performances provoquée par une modification du modèle sous-jacent lui-même, lorsque le fournisseur le met à jour, le déprécie ou le remplace. La version sur laquelle votre déploiement a été optimisé évolue, et les résultats évoluent en conséquence. Ce phénomène est distinct de la dérive des données ; dans un déploiement utilisant un seul LLM, il n'existe aucune barrière entre cette modification et votre client.

Quelle est la différence entre la dérive du modèle et la dérive des données ?

On parle de « dérive des données » lorsque les données d'entrée évoluent au fil du temps, ce qui fait qu'un même modèle interprète différemment les nouvelles données d'entrée. La « dérive du modèle » se produit quant à elle lorsque le modèle sous-jacent change au sein d'un déploiement stable, alors que les données d'entrée restent inchangées. Ces deux phénomènes nuisent à la qualité, mais leurs causes et leurs solutions sont différentes.

Pourquoi les déploiements reposant sur un seul LLM présentent-ils davantage de risques pour les entreprises ?

En effet, l'organisation hérite de la cadence de déploiement, des fonctionnalités obsolètes, des modifications tarifaires et des changements de comportement d'un fournisseur donné, selon le calendrier de ce dernier. Chaque modification du modèle se répercute directement sur l'expérience client, sans aucune marge de manœuvre. Une architecture indépendante du modèle élimine ce point de vulnérabilité unique.

Comment une plateforme indépendante des modèles permet-elle d'éviter la dérive des modèles ?

Il considère la couche de modèle comme interchangeable, en évaluant en permanence les modèles disponibles et en passant de l'un à l'autre sans cycle de redéploiement. La réponse étant issue d'une base de connaissances contrôlée plutôt que générée par un modèle unique, le changement de modèle devient un événement interne qui n'altère en rien ce que le client entend.

La dérive des modèles a-t-elle une incidence sur la conformité dans les secteurs réglementés ?

Oui. Un changement de modèle inopiné peut modifier un chemin de réponse précédemment validé sans justification documentée, ce qui pose un problème d'auditabilité, et pas seulement de performance. Les intentions liées à la source permettent de garantir la traçabilité et la justifiabilité de chaque réponse dans les contextes du CFPB, de l'OCC et de la FDIC, quel que soit le modèle sous-jacent.

En quoi une architecture axée sur la connaissance permet-elle de réduire le risque de dérive des modèles ?

Il associe les réponses à des intentions définies et liées à des sources, plutôt que de les générer à partir du modèle au moment de l'exécution. Le modèle est au service des connaissances, et non la source de la réponse ; ainsi, la modification du modèle n'entraîne pas de changement de la réponse validée. Cela permet de garantir une qualité constante et de rendre le cheminement décisionnel vérifiable, même en cas de modifications du modèle.