SPARK : Exploiter les échanges techniques passés pour améliorer le support client (2025)

Abstract: S.P.A.R.K. (SAP Process Augmented Response Knowledge) est un projet qui vise à concevoir une architecture de génération augmentée par récupération (RAG) adaptée aux dialogues techniques issus de requêtes clients. L’objectif est d’améliorer l’efficacité des consultants SAP dans la résolution des demandes clients en exploitant les connaissances contenues dans des échanges antérieurs similaires. Chaque ticket résolu contient un dialogue entre un client décrivant un problème et un consultant proposant une solution technique détaillée. L’accès rapide à ces solutions déjà éprouvées constitue un atout majeur. Cet article aborde les défis spécifiques liés à l’exploitation des données conversationnelles techniques, présente les solutions proposées pour optimiser la récupération et la génération de réponses pertinentes, et traite des perspectives futures du projet.

## introduction les centres de services (cds) des entreprises disposent généralement d'archives regroupant l'ensemble des tickets résolus par le passé. chaque ticket comprend à la fois un besoin (dysfonctionnement, demande d'évolution, de développement ou d'expertise spécifique) exprimé par un client, ainsi qu'une solution détaillée fournie par le ou les consultant(s) et/ou expert(s) chargé(s) de sa résolution. généralement sous forme conversationnelle, ces échanges entre clients et cds contiennent une richesse d'informations issues d'expertises accumulées sur des centaines, voire des milliers de cas déjà traités. grâce à une architecture de génération augmentée par récupération (rag), l'intérêt d'exploiter ces données historiques pour assister les consultants face à de nouveaux tickets similaires ou identiques est devenu possible. une telle approche permettrait aux consultants des cds de ne plus systématiquement repartir de zéro, réduisant ainsi la dépendance exclusive à l'expertise individuelle des consultants. cependant, contrairement à l'utilisation traditionnelle de rag sur des documents rédigés, le format conversationnel des données sources, leur caractère technique spécifique (ici lié aux systèmes sap) et la sensibilité potentielle des informations qu'elles contiennent posent plusieurs défis majeurs. en plus de la sélection des modèles d'ia les plus adaptés, ces aspects doivent être pris en compte pour garantir la performance et la sécurité de l'outil développé. cet article revient d'abord sur des travaux antérieurs pertinents, puis détaille les défis spécifiques à notre contexte, puis expose les solutions actuellement déployées ainsi que les perspectives futures du projet, celui-ci étant toujours en cours de développement. ## travaux antérieurs les modèles de rag ont suscité un intérêt croissant dans le domaine du traitement automatique du langage naturel, en raison de leur capacité à produire des réponses informatives, contextualisées et vérifiables. cette architecture hybride combine un modèle génératif de type llm avec un composant de récupération documentaire, permettant de dépasser les limites des modèles purement paramétriques dont la connaissance est figée dans leurs poids. introduit par lewis et al. @xcite , le modèle rag s'est notamment illustré dans des tâches de question-réponse ouverte, en réduisant significativement les phénomènes d'hallucination par l'appui sur des contenus externes vérifiables. diverses variantes ont été proposées pour raffiner cette architecture, telles que rag-sequence et rag-token (lewis et al., 2020), fusion-in-decoder @xcite , realm @xcite ou encore retro @xcite , explorant des stratégies alternatives d'intégration de l'information récupérée. plus récemment, le modèle atlas @xcite a démontré l'intérêt de combiner le paradigme rag avec des approches few-shot, en injectant directement dans le prompt du modèle de langage des exemples de tâches similaires afin de guider plus finement la génération. l'application de ces approches aux données conversationnelles a principalement été étudiée dans le cadre de chatbots. des travaux comme multidoc2dial @xcite ont proposé des mécanismes de segmentation documentaire permettant de récupérer, à partir de plusieurs sources hétérogènes, les informations pertinentes nécessaires à la génération de réponses cohérentes dans des dialogues complexes. d'autres approches, telles que blenderbot 3 @xcite ou les architectures modulaires présentées dans @xcite , ont amélioré la pertinence d'un rag comme moteur d'un chatbot. plus récemment, ragate @xcite a introduit un mécanisme de filtrage dynamique du contexte, optimisé pour les interactions en dialogue ouvert. en revanche, l'utilisation des échanges conversationnels techniques, tels que les tickets issus de centres de service, comme source d'entrée structurée dans une architecture rag demeure peu explorée. bien que ces dialogues constituent une ressource précieuse pour capturer des cas d'usage réels, leur exploitation nécessite des traitements spécifiques, notamment pour structurer l'information de manière exploitable par les systèmes génératifs. dans ce contexte, plusieurs travaux ont proposé des méthodes de création automatique de résumés à partir de conversations. des systèmes tels que ceux décrit dans @xcite ont montré de bonnes performances sur des corpus comme summscreen @xcite ou @xcite , confirmant la faisabilité d'une synthèse efficace des conversations informelles. enrichir ces résumés par des représentations structurées, telles que des graphes @xcite s'est également révélé bénéfique pour la cohérence et la fidélité des contenus générés. par ailleurs, des approches non supervisées ou faiblement supervisées, s'appuyant sur des graphes lexicaux @xcite ou des paradigmes auto-apprenants, offrent des perspectives intéressantes pour des contextes à faibles ressources ou en l'absence d'annotations manuelles. enfin, l'émergence des grands modèles de langage a marqué une nouvelle étape : ceux-ci sont capables, via un simple prompt, de produire des résumés conversationnels de bonne qualité, y compris dans des domaines aussi exigeants que le médical @xcite . la protection des données les données issues d'un centre de services contiennent fréquemment des éléments sensibles : noms de clients, de sociétés, de consultants, ou encore références internes à des projets ou infrastructures techniques. leur anonymisation peut par ailleurs constituer un impératif contractuel ou réglementaire, mais aussi méthodologique. d'une part, du point de vue contractuel, un consultant traitant une demande ne doit pas être exposé à des informations permettant d'identifier les clients ayant déjà rencontré un problème similaire. d'autre part, la présence de ces éléments nominaux biaise les mécanismes d'attention des modèles d'embedding, ceux-ci ayant tendance à surpondérer les entités nommées (noms propres, acronymes, etc.) dans le calcul de similarité. cela peut entraîner un appariement artificiel entre deux tickets mentionnant un même client, indépendamment de la nature réelle du problème. la figure 1 illustre ce phénomène : des tickets sans lien thématique se retrouvent artificiellement proches dans l'espace des embeddings en raison de la répétition d'un même nom d'entreprise @xcite détaille l'enjeu de l'anonymisation dans les rag). statistique valeur nb moyen de tokens par ticket 1620 nb médian de tokens par ticket 1124 écart-type sur le nb de tokens 1572 nb moyen de messages par ticket 10.62 nb médian de messages par ticket 7 écart-type sur le nb de messages 10.49 nb total de tickets analysés 170 figure 1 -exemple de rapprochement entre tickets du même client malgré des sujets de conversations différents. la représentation résulte d'une projection via une analyse en composante principale (acp) des vecteurs d'embedding. le tableau présente les statistiques descriptives des tickets analysés. les estimations du nombre de tokens ont été effectuées avec le tokenizer cl100k_base (utilisé notamment par les modèles gpt-4 et gpt-3.5-turbo). l'aspect conversationnel les échanges entre clients et consultants suivent généralement une dynamique asynchrone, entrecoupée de clarifications, d'allers-retours, voire de digressions. l'information clé (problème métier, diagnostic, solution) est ainsi diluée dans le flux conversationnel. par exemple, dans un ticket concernant un problème de calcul du coût de revient "ccr" sur sap, la cause réelle (configuration manquante dans une transaction tierce) peut n'apparaître qu'après plusieurs échanges. à l'inverse, certains échanges sont très courts et contiennent peu ou pas d'informations pertinentes, résultant en une grande divergence sur la qualité et la quantité des informations d'un ticket (voir tableau de la figure 1 ).