Comment j’ai utilisé les technologies RAG pour transformer un service client grâce à l’IA

Lors d’une récente démo pour un prospect, j’ai eu l’opportunité d’explorer et d’implémenter une solution utilisant la technologie RAG (Retrieval-Augmented Generation). Mon objectif était de démontrer comment cette approche peut non seulement enrichir un outil d’aide au SAV, mais aussi faciliter la création et l’amélioration continue d’une FAQ. Voici comment j’ai mis en place cette solution et les résultats que j’ai obtenus.

Le Contexte : des PDF, des emails, un wiki et une montagne d’informations

Le prospect disposait de plusieurs sources d’informations critiques :

• Un grand nombre d’emails (format .eml), contenant des échanges détaillés avec les clients.

• Des documents techniques et des ressources internes, souvent au format PDF.

• Un Wiki interne, accessible mais peu exploité.

Ces données étaient vastes, mais difficiles à interroger efficacement. Le défi était donc clair : permettre une recherche en langage naturel qui non seulement retourne une réponse pertinente, mais indique aussi d’où provient cette information.

Étape 1 : Extraction et préparation des données

a première étape a consisté à extraire et transformer les données disponibles :

• Extraction des pages du Wiki : J’ai utilisé Python pour extraire toutes les pages du Wiki interne. Ces pages ont ensuite été converties en PDF. (Certes, ce n’était pas la méthode idéale, mais elle a permis de transformer rapidement ces informations en un format uniforme.)

• Traitement des emails : Les emails en format .eml ont été convertis en texte brut pour être intégrés dans le pipeline d’analyse.

Le résultat ? Un millier de fichiers PDF et d’emails prêts à être indexés.

Étape 2 : Indexation avec la technologie RAG

Pour la partie RAG, j’ai utilisé une combinaison de text embeddings et de modèles de langage avancés :

• Embeddings avec text-embedding-ada-002 : J’ai utilisé ce modèle d’OpenAI pour générer des vecteurs de similarité sémantique à partir de chaque document (emails, PDF, Wiki). Cela permet de transformer le contenu textuel en représentations vectorielles exploitables pour la recherche.

• GPT-3.5-turbo-0125 pour les réponses : Ce modèle a servi à comprendre les requêtes en langage naturel et générer des réponses pertinentes. Pour offrir plus de flexibilité, j’ai également intégré la possibilité de basculer vers GPT-4 Turbo ou Claude Sonnet 3.5, en fonction des besoins de précision ou de contexte.
• Test avec Llama 3.2 : une performance décevante
• Pour comparer les performances, j’ai par ailleurs testé cette solution avec Llama 3.2, en l’exécutant sur un Mac M4. Malheureusement, les résultats se sont avérés bien moins convaincants. Non seulement le modèle était nettement plus lent à répondre, mais les résultats étaient aussi beaucoup moins pertinents, surtout pour des questions nécessitant une recherche fine dans les données indexées. Bien que prometteur pour certaines applications spécifiques, Llama 3.2 n’était clairement pas à la hauteur pour ce type de cas d’utilisation basé sur la recherche et la génération contextuelle.

Étape 3 : Recherche contextuelle et feedback utilisateur

L’un des avantages majeurs de cette solution est sa capacité à fournir des réponses contextuelles tout en indiquant leur origine :

• Recherche en langage naturel : L’utilisateur peut poser des questions directement (par exemple : “Comment résoudre une erreur sur le produit X ?”) et recevoir une réponse claire, accompagnée des PDF ou emails dans lesquels cette réponse a été trouvée.

• Feedback utilisateur : J’ai ajouté un système permettant à l’utilisateur de signaler si une réponse était pertinente ou non. Ce feedback est stocké dans une base de données locale.

Étape 4 : Optimisation des coûts grâce au stockage local

Pour éviter des requêtes inutiles à OpenAI ou d’autres modèles coûteux, j’ai conçu une solution locale :

• Si une question similaire a déjà été posée et une réponse pertinente a été validée, elle est directement extraite de la base de données locale. Cela évite des requêtes redondantes et réduit les coûts.

Résultats et avantages

Cette solution basée sur la technologie RAG a offert plusieurs avantages immédiats :

1. Gain de productivité : Les équipes SAV peuvent désormais trouver rapidement des réponses, sans parcourir manuellement des centaines de documents.

2. Confiance accrue : Le fait de montrer la source des informations renforce la crédibilité des réponses.

3. Coût maîtrisé : Le système de stockage local réduit considérablement les frais liés aux API de modèles de langage

Ce que j’ai appris (et les limites)

1. Les PDF ne sont pas toujours idéaux : Bien que pratiques, les fichiers PDF ne sont pas le format le plus flexible pour l’indexation. Un format JSON ou une base de données textuelle structurée aurait été plus efficace.

2. Embeddings précis mais gourmands : Les embeddings générés par text-embedding-ada-002 sont d’une grande qualité, mais leur génération sur un grand volume de données peut être coûteuse et lente.

3. Importance du feedback utilisateur : Le système de feedback s’est avéré crucial pour améliorer la pertinence des réponses et affiner l’expérience utilisateur.

Conclusion : le potentiel des technologies RAG

La combinaison des technologies RAG, des embeddings avancés et de modèles de langage comme GPT-3.5/4 Turbo ou Claude Instant ouvre de nouvelles perspectives pour les entreprises. Que ce soit pour le SAV, la création de FAQ ou même l’assistance interne, ces outils transforment la manière dont les informations sont gérées et exploitées.

Pour les prospects ou les entreprises souhaitant tirer parti de leurs données non structurées, cette approche représente une solution puissante, flexible et évolutive. Avec un peu de travail supplémentaire, je suis convaincu que ce système pourra aller encore plus loin, en intégrant par exemple des fonctionnalités de résumé automatique ou de traduction.