Tealium : Pourquoi la qualité du RAG dépend des données en temps réel

Freddy Berlanti, chef de produit principal en IA appliquée chez Tealium, explore la génération augmentée par la recherche (RAG). Image : Getty Images

Freddy Berlanti, chef de produit principal en IA appliquée chez Tealium, analyse le fossé crucial qui sépare les systèmes RAG qui apportent de la valeur de ceux qui sapent silencieusement la confiance des utilisateurs

La plupart des systèmes d’entreprise de génération augmentée par la recherche (RAG) ne récupèrent qu’un instantané du client : un magasin de vecteurs indexé mardi dernier, une base de connaissances synchronisée pendant la nuit, ou un profil reflétant qui était l’utilisateur il y a 12 heures. C’est cet écart qui distingue les systèmes RAG efficaces de ceux qui érodent discrètement la confiance.

Il est 20 h 47 un jeudi. Un client ajoute un article supplémentaire à son panier, faisant ainsi passer le montant total au-dessus du seuil de livraison gratuite, puis ouvre le chat d’assistance et demande si la livraison est incluse.

L’agent répond en quelques millisecondes. Sa réponse est fluide, polie, bien documentée… et erronée, car le profil qu’il a récupéré a été constitué avant que le panier ne soit modifié. Le temps que les données indexées par lots rattrapent leur retard, le moment où elles devaient servir d’information est déjà passé.

Deux grandeurs distinctes régissent cet échange, mais la plupart des systèmes de production n’en mesurent qu’une seule. La latence de réponse correspond au temps écoulé entre la question et la réponse, et les équipes la mesurent de manière obsessionnelle. L’«âge de l’information», un indicateur formalisé par Kaul, Yates et Gruteser, mesure l’ancienneté d’un fait au moment où le système agit en fonction de celui-ci. En termes simples : à quel point le contexte était-il obsolète lorsque vous l’avez utilisé ?

Dans cet exemple, la latence de réponse était inférieure à une seconde, mais l’information datait de plusieurs heures. Le système était rapide sans être à jour. Et seul l’un de ces chiffres figurait sur le tableau de bord.

Cette distinction est importante, car une réponse rapide basée sur des données clients obsolètes reste une mauvaise réponse. Pour le RAG orienté client, la rapidité et l’actualité sont deux problèmes distincts, et l’optimisation de l’un ne garantit pas l’autre.

Les deux sont indépendants, et sous la charge, ils peuvent évoluer dans des directions opposées. Des mises à jour plus fréquentes ne signifient pas toujours des informations plus récentes. Au-delà d’un certain seuil, les mises à jour s’accumulent, rendant la donnée la plus récente disponible plus ancienne, et non plus récente. Le traitement par lots nocturne n’est qu’un cas extrême : un système fonctionnant sur une vision du monde datant de la veille. La solution ne consiste pas à transférer davantage de données selon le même calendrier. Elle consiste à transférer les changements qui comptent au fur et à mesure qu’ils se produisent, ce qui nécessite une architecture différente, et pas seulement une architecture plus rapide.

Le modèle RAG a fait ses preuves en résolvant le problème du « livre fermé ». Plutôt que de répondre uniquement de mémoire, le système recherche d’abord les informations pertinentes, puis répond à partir de ce qu’il a trouvé. Ces informations constituent le corpus. Si le corpus est correct, le modèle cesse d’improviser.

Pour un assistant de connaissances interne, un corpus synchronisé pendant la nuit suffit. Mais pour un client en pleine session, le problème est différent. Le panier vient de franchir un seuil, et un agent doit décider immédiatement s’il propose la livraison gratuite ou s’il fait patienter le client. Un instantané pris avant l’aube n’est pas une limitation à corriger ultérieurement ; c’est une architecture inadaptée, car le temps que les données indexées par lots rattrapent leur retard, l’opportunité qu’elles étaient censées éclairer est déjà passée.

Le RAG par lots récupère un souvenir ; le RAG en temps réel récupère le client

Les défaillances sont mineures, plausibles et insidieuses. Elles déclenchent rarement des alertes ou des rapports de bogues ; les utilisateurs apprennent simplement à ne pas faire confiance au système et cessent de l’utiliser. Lorsque cela apparaît sur un tableau de bord, cela ressemble à un problème d’adoption sans cause évidente.

La solution commence avant toute décision relative aux outils. Il s’agit d’un accord de niveau de service, rédigé pour chaque cas d’utilisation, qui répond à trois questions : quel doit être le degré d’actualité du contexte ? À quelle vitesse la réponse doit-elle parvenir ? À quel moment le système doit-il s’arrêter et confier la conversation à un humain ?

L’état du panier nécessite une actualisation en quelques secondes. Le contenu des produits peut tolérer quelques minutes. Les politiques peuvent se contenter d’une mise à jour quotidienne. Ces chiffres cessent d’être une simple préférence pour devenir une contrainte de conception : ils déterminent l’architecture et le coût. L’erreur courante consiste à traiter l’actualité comme un paramètre global unique appliqué de manière uniforme à tout. L’actualité est un budget. Utilisez-le là où cela influence une décision, et cessez de le payer là où ce n’est pas le cas.

Pour les agents en contact avec la clientèle, le corpus, c’est le client.

Cela signifie que l’identité est harmonisée sur tous les appareils et canaux, de sorte que tous les points de contact sont associés à une seule et même personne. Cela signifie que le consentement est lié au profil lui-même, de sorte que chaque consultation en aval est autorisée par nature plutôt que par un document de politique que l’on espère avoir été lu.

Cela signifie également renoncer à la reconstruction nocturne. La capture des données modifiées, qui consiste à ne transmettre en continu que ce qui a changé au lieu de tout recharger, réintègre un profil unique en quelques secondes plutôt que de retraiter des millions de profils. La recherche s’effectue alors de manière hybride : recherche vectorielle dense pour le sens, recherche par mot-clé pour les chaînes exactes qui comptent, comme les références produit et les numéros de commande, les deux étant fusionnées par classement, avec un passage de reclassement sur les résultats finalistes. Les niveaux « chauds » et « froids » permettent de maîtriser les coûts : vous achetez ainsi une actualité de deuxième niveau pour la poignée d’attributs qui influencent réellement une décision, et une actualité quotidienne pour tout le reste.

La pile toujours à jour, à lire de gauche à droite, avec la boucle de mesure en dessous

Connecter manuellement chaque agent à chaque source de données crée un réseau d’intégrations, chacune avec sa propre authentification, ses changements de schéma et ses points de défaillance. C’est cette complexité qui explique pourquoi tant de projets pilotes prometteurs peinent à se développer à grande échelle.

Le Model Context Protocol (MCP), une norme ouverte permettant de connecter des agents à des outils et à des données, transforme cette jonction en un port. Il suffit de connecter une source une seule fois pour que tout agent compatible puisse la découvrir, avec les schémas et les autorisations associés. Une passerelle se trouve en amont : elle valide les appels entrants, masque les données avec le consentement de l’utilisateur et consigne la piste d’audit. C’est cette partie peu glamour qui vous permet de passer en production.

Rien de tout cela ne peut fonctionner sans mesure, et un seul chiffre ne suffit pas. Un score de satisfaction vous indique que quelque chose ne va pas. Trois tableaux de bord distincts vous indiquent quoi.

La qualité de la récupération permet de déterminer si vous avez bien extrait le bon contexte : précision contextuelle, rappel contextuel, décalage de périmité. Aucun modèle n’est nécessaire pour y répondre. La qualité de la génération permet de vérifier si le modèle a utilisé fidèlement ce qui lui a été fourni : pertinence de la réponse et couverture des citations, notées par un évaluateur calibré par rapport à un examen humain. Les résultats commerciaux permettent de déterminer si tout cela a eu une incidence : délai de résolution, confinement, coût, CSAT. Considérés séparément, un indicateur en baisse pointe directement vers la couche qui nécessite des améliorations, qu’il s’agisse des données, du modèle ou du flux de travail.

Trois tableaux de bord : une baisse vous indique quelle couche corriger

Ensuite, déployez de manière ciblée. Testez un cas d’utilisation bien délimité sur du trafic réel, affinez-le jusqu’à ce qu’il respecte le SLA que vous avez défini, mettez-le en production avec la remontée d’incident activée, puis élargissez le déploiement. Le schéma de stagnation est exactement l’inverse, et c’est actuellement le modèle de projet le plus courant dans le secteur : l’outil d’abord, les données ensuite, les indicateurs jamais.

Les modèles s’améliorent pour tout le monde le même jour. Quel que soit l’avantage qu’une version pionnière vous procure ce trimestre, votre concurrent l’achètera au prix catalogue le trimestre suivant. Ce qu’il ne peut pas acheter, ce sont la valeur, la gouvernance et l’identité du contexte que vos agents récupèrent au moment où ils répondent.

Le modèle, c’est le cerveau. Le contexte, c’est la mémoire. Un seul des deux vous appartient. Découvrez l’ebook complet.