Optimiser un Chatbot/LLM avec le fine tuning ou le RAG

Voici la méthode officielle d'OpenAI d'optimisation d'un LLM avec le fine-tuning, la RAG et le prompt engineering.

L'optimisation des LLM est un défi auquel sont confrontées les entreprises qui expérimentent l’IA générative.

En effet, trop d'entreprise, éblouies par les performances de ChatGPT, pense ce que les LLMs sont des outils magiques qui produisent des résultats sans effort.

C'est une erreur: il faut de véritables compétences en gestion du language naturel NLP pour parvenir à les dompter.

Il existe deux grands familles de solutions pour créer un chatbot qui s'appuie sur une technologie de type LLM comme ChatGPT.

1. Passer par une plateforme no code clé en main.

Vous louez un chatbot standard comme Chatbot.com qui peut s'installer sur site web, par exemple.

Vous êtes alors très dépendant de la plateforme et le niveau de personnalisation

2. Développer vous-même un chatbot entièrement personnalisable

Cela suppose que vous disposiez d'une équipe de développement, d'une série de logiciels (frameworks et libraries), d'un ordinateur puissant (dans vos locaux ou dans le cloud) pour mettre au point et tester le chatbot puis le passer en production.

Ce guide décode les techniques à utiliser pour développer le 2ème type de chatbots.

Il permet à un non technicien motivé de comprendre des techniques comme la RAG (Retrieval Augmented Generation) ou le Fine-Tuning, afin de pouvoir piloter un projet de développement de chatbot.

Les enjeux

• Faire penser le LLM comme vous le feriez
• Minimiser les erreurs/hallucinations
• Obtenir des réponses les plus précises possibles

Trois grandes techniques existent afin d’optimiser les applications reposant sur des LLM:

• Le prompt engineering qui consiste à envoyer les informations les plus précises possibles dans la fenêtre de contexte (c’est-à-dire le prompt au sens large, qui peut inclure la question, des documents en annexe ainsi qu’une série de paramètres techniques)
• Le fine-tuning qui consiste à ré-entrainer un LLM standard (comme GPT3.5) avec vos données ou votre façon de répondre
• Le RAG (Retrieval Augmented Generation) qui est un système plus léger qui consiste, une fois la question de l’utilisateur posée, à récupérer les données pertinentes de votre base de données privées avant de demander au LLM de formuler une réponse.

Certains spécialistes ne jurent que par le RAG, plus souples, plus rapide à développer et surtout plus facile à mettre à jour.

D’autres tiennent absolument à toucher au cœur du modèle, en espérant, gagner en rapidité (l’un des points faibles du RAG) grâce au Fine-Tuning. Les techniques de Fine Tuning se snot tellement démocratiser qu’il y a 700 000 LLM fine-tunés qui sont hébergés sur la plateforme Hugging Face fin mai 2024 !

Ce guide décortique ces différentes techniques et surtout donne des éléments pour choisir la technique la plus adaptée à vos besoins.

Ce guide est librement inspiré des recommandations officielles d’OpenAI.

Cet article présente un modèle mental permettant d'optimiser la précision et le comportement des LLM. Nous explorerons des méthodes telles que le prompt engineering, la Retrieval Augmented Generation (RAG) et le fine-tuning.

Contexte d'optimisation du LLM

De nombreux guides pratiques sur l'optimisation la décrivent comme un simple flux linéaire - vous commencez par Le prompt engineering, puis vous passez à la Retrieval Augmented Generation, puis au fine-tuning. Cependant, il s'agit de leviers qui résolvent des problèmes différents, et pour optimiser de la bonne façon, il faut sélectionner le bon levier.

Voici une proposition de matrice pour déterminer les priorités.

Source : OpenAI

Commençons par le commencement

Le début du travail sur le LLM commence dans le coin inférieur gauche avec le prompt engineering: on teste des prompts qui permettent d'évaluer les performances du LLM de base pour obtenir une base de référence, pour la suite.

Il faut le faire sérieusement en partant d'un principe: il est très possible qu'il n'y ait pas besoin de sortir l'artillerie lourde ou en tout cas, si l'on a pas poussé le modèle dans ses retranchements avec un excellent prompt engineering, les techniques d'optimisations avancées (plus lourdes et plus coûteuses à manipuler) ne révèleront pas leur vrai potentiel.

Une fois que nous avons obtenu des réponses de qualité du prompt engineering et déterminé pourquoi ils sont incorrects, nous pouvons actionner l'un de nos leviers :

• Optimisation du contexte
  Vous devez optimiser le contexte lorsque :
  1) le modèle manque de connaissances contextuelles parce qu'elles ne figuraient pas dans son ensemble d'apprentissage,
  2) ses connaissances sont obsolètes
  ou 3) il nécessite la connaissance d'informations exclusives.
  Cet axe maximise la précision des réponses.
• Optimisation du LLM
  Vous devez optimiser le LLM lorsque :
  1) le modèle produit des résultats incohérents avec un formatage incorrect,
  2) la tonalité ou le style des réponses n'est pas correct,
  ou 3) le raisonnement n'est pas suivi de manière cohérente.
  Cet axe maximise la cohérence du comportement.

En réalité, le process d’optimisation d’une application qui repose sur un LLM est itératif.

C’est un cycle de tests

• Evaluation de la qualité des réponses du LLM et identification d’un problème spécifique (ex : réponse incomplète)
• Formulation d’une hypothèse sur la façon de résoudre ce problème
• Test de la solution imaginée
• Evaluation des résultats après mise en place de la solution pour déterminer si le problème a été résolu
• Identification d’un autre problème
• Formulation d’une nouvelle hypothèse…
• Etc…

Voici une façon de représenter l’enchaînement de ces cycles dans le shéma précédent :

Source : OpenAI

Dans le schéma précédent, voici le scénario imaginé :

• Commencer par tester un prompt, très bien construit, puis évaluer sa performance (c’est-à-dire la qualité des réponses sur un jeu de requêtes tests)
• Ajouter, dans le prompt, des exemples de quelques modèles (Add few shot), ce qui devrait améliorer la cohérence des résultats.
• Intégrer la technologie du RAG (Retrieval Augmented Generation) pour intégrer quelques exemples issus de votre base de données, spécifique à chaque requête, soient intégré au contexte - cela améliore les performances en garantissant un contexte pertinent pour chaque requête,
• Personnaliser le modèle grâce à un fine-tuning léger (reposant sur 50 exemples, par exemple) pour améliorer la cohérence.
• Affiner le RAG et ajouter une étape de vérification des faits pour trouver les hallucinations afin de limiter les errreurs et obtenir une réponse plus précise
• Ré-entraîner le modèle fine-tuné sur les nouveaux exemples d'entraînement qui incluent les données RAG améliorées.

Il s'agit d'un scénario d'optimisation pour un cas typique rencontré par les entreprises pionnières : il nous aide à décider si nous avons besoin d'un contexte plus pertinent ou si nous avons besoin d'un comportement plus cohérent de la part du modèle. Autrement dit, si nous devons travailler, d’abord, plutôt le prompt engineering et mettre en place un système de RAG ou bien finetuner le modèle.

Cette matrice permet de prendre les problèmes dans le bon ordre.

Voici maintenant des conseils sur les trois techniques évoquées:

• Prompt Engineering
• Retrieval Augmented Generation
• Fine-Tuning

Prompt Engineering

C’est le point de départ de toute intégration d’un LLM dans une application.

Cela consiste à définir la bonne instruction au LLM.

C’est la base de tout.

D’ailleurs, c’est, en réalité, une techniques suffisante à utiliser pour développer des applications telles que :

• le résumé de texte,
• la traduction
• la génération de code.

En effet, dans ces cas, toutes les informations nécessaires peuvent déjà se trouver dans le modèle (dans la mesure où évidement si le modèle est suffisamment performant).

Pour passer et réussir cette étape, il faut tout d’abord ce que serait une bonne réponse de la part du LLM (taille, style, niveau de vocabulaire, structure de la réponse…).

Il est recommandé de débuter par un prompt simple et le résultat que le LLM devrait générer en réponse.

Ensuite, ajouter un contexte, des instructions ou des exemples au prompt, jusqu’à ce que le LLM génère une réponse proche de la réponse idéale que vous aviez défini au départ.

Pour ce faire, vous devez toujours commencer par définir un prompt simple et un résultat attendu, puis optimiser le prompt en ajoutant un contexte, des instructions précises ou des exemples jusqu'à ce qu'elle vous donne un résultat proche du résultat attendu.

C’est vraiment ce par quoi il faut commencer.

Déterminer exactement ce que vous attendez et itérer jusqu’à ce que vous vous rapprochiez du résultat espéré.

Ecrire un bon prompt pour une application reposant sur un LLM répond aux mêmes exigences que celles requises pour un bon prompt pour ChatGPT ou Perplexity par exemple.

Mais, on peut y ajouter deux autres types d’éléments :

• Des paramètres techniques limitant le nombre de caractères, la possibilité pour le llm de répéter ou non des mots figurant déjà dans le début du texte…
• Des annexes comme des statistiques ou des documents PDF, des exemples précisant le format des réponses…

Evaluation

Dans certains cas comme celui des problématiques de traduction, il existe des outils qui permettent d’évaluer automatiquement la production du LLM que l’on est en train d’optimiser.

Mais, en dehors de ces cas spécifiques, on peut tout simplement tester ce que produit le LLM et le comparer à un jeu d’évaluation de 10 questions/réponses de références (c’est-à-dire des réponses du niveau de qualité souhaité, rédigé à l’avance par des humains). La comparaison des réponses souhaitées avec les réponses réellement générées par le LLM permet de comprendre ce qui va et ce qui ne va pas pour émettre des hypothèses sur les raisons d’une éventuelle sous performances du modèle.

Si vous souhaitez approfondir le sujet de l’évaluation, consultez ce recueil de conseils d’OpenAI sur ce sujet.

Après avoir évalué,  réalisé l’analyse et formulé des hypothèses, deux grands cas peuvent se produire :

1. Vous pensez que retravailler le prompt permettra d’améliorer et vous recommencer un cycle de test du nouveau prompt
2. Vous pensez que le prompt ne peut plus être améliorer et passez à l’étape suivante

L’étape suivante de l’optimisation du LLM

Vous avez optimisé le prompt engineering, vous avez créé un jeu d'évaluation, et votre modèle ne fait toujours pas exactement ce que vous attendez de lui.

L'étape suivante consiste à diagnostiquer l'origine de l'échec et à déterminer l'outil le plus efficace pour l'améliorer.

Voici un arbre de décision pour déterminer la démarche la plus adaptée :

• Retrieval Augmented Generation ?
• Fine-Tuning ?

En général, si le prompt engineering a été optimisé, vos problèmes de qualité de réponse relèvent:

• soit d’un problème de mémoire de contexte (ou In-context memory ou mémoire de court terme ou fenêtre de contexte),
• soit d’un problème de mémoire apprise (ou learned memory ou mémoire de long terme)
• soit des deux.

Si les deux concepts ne sont pas clairs dans votre esprit, voici une analogie pour comprendre la différence technique entre les problèmes de mémoire de contexte et de mémoire apprise.

Imaginez que vous passiez un examen. Il y a deux façons de s'assurer que vous obtenez la bonne réponse :

• Vous assistez aux cours depuis 6 mois, où vous voyez de nombreux exemples répétés du fonctionnement d'un concept particulier. Il s'agit d'une mémoire apprise (learned memory). Pour améliorer les performances du LLM sur ce point, vous devez lui montrer de nombreux exemples de prompts et de réponses que vous attendez, et le modèle apprend à partir de ces exemples. Vous ré-entrainez en profondeur le modèle, au final pour en créer un nouveau, légèrement différent. Vous l’avez fine-tuné.
• Vous avez le manuel avec vous et vous pouvez rechercher les bonnes informations pour répondre à la question. Il s'agit de la mémoire de contexte (in context memory). Pour améliorer les performances du LLM sur ce point, vous ne le ré-entrainez pas totalement, mais vous insérer des informations pertinentes, spécifiques à la question posée, dans la fenêtre de contexte, en utilisant le RAG.

Ces deux méthodes d'optimisation (Fine-tuning et RAG) sont complémentaires et non exclusives. Parfois, vous n’avez besoin que de l’une. Parfois, vous avez besoin des deux.

Supposons que vous soyez confrontés à un problème de mémoire de contexte : vous devez utiliser la RAG pour le résoudre.

Génération augmentée par récupération (RAG)

La RAG est un processus de récupération du contenu avant génération de la réponse par le LLM pour enrichir le prompt avec des informations pertinentes, correspondant à la requête de l’utilisation qui sera transmis au LLM avant qu’il génère une réponse. Il est utilisé pour donner au modèle l'accès à un contexte spécifique au domaine afin de réaliser la tâche qu’il doit réaliser.

La RAG est un outil précieux et très populaire pour accroître la précision et la cohérence d'un LLM. De nombreuses applications que vous utilisez reposent uniquement sur cette techno et sur celle du prompt engineering.

Dans cet exemple, on a fait rentrer dans la boucle une base de connaissances contentant des statistiques dont on a besoin pour que le LLM réponde de façon plus complète, plus précise, plus fiable…(cela aurait pu tout autant pu être du texte, du code, des infos client..).

Ensuite, voici les différentes étapes qui s’enchaînent :

1. L'utilisateur pose une question/expose son problème
2. Le système de RAG extrait le contenu le plus pertinent de la base de connaissances
3. Ce contenu est intégré au prompt
4. Le tout est transmis au LLM qui répond ensuite à la question/au problème posés en analysant/synthétisant tout ce qui lui a été transmis.

Mais, un système reposant sur de la RAG n’est, lui-même, pas naturellement optimisé. Il faut donc, l’optimiser et ce, à plusieurs niveaux. Ce processus est décrit dans le détail dans un article indépendant.

Mais, décrivons, tout d’abord, les différents briques d’un système de RAG.

Comment fonctionne un système de RAG ?

Le RAG se compose principalement de deux phases : la récupération d'information et la génération de texte.

1. Récupération d'information

La première phase du RAG consiste à récupérer des documents ou des passages pertinents à partir d'une base de données ou d'un index de connaissances. Cette récupération est effectuée à l'aide de modèles de recherche sémantique basés sur des représentations vectorielles denses. Les techniques couramment utilisées incluent TF-IDF, BM25, et des modèles de récupération neuronale plus avancés comme les modèles de récupération dense.

• Préparation des données : Les documents sont collectés et prétraités, incluant la tokenisation, le nettoyage des données et la gestion des informations personnelles (PII). Les documents sont ensuite segmentés en morceaux de longueur appropriée en fonction du modèle d'embedding choisi et de l'application LLM en aval.
• Indexation des données : Les embeddings des documents sont produits et un index de recherche vectorielle est hydraté avec ces données.
• Récupération des données : Les parties pertinentes des données sont récupérées en réponse à une requête utilisateur et fournies comme contexte dans le prompt utilisé pour le LLM.

2. Génération de texte/ de réponse

La deuxième phase consiste à utiliser les informations récupérées comme contexte pour générer des réponses. Un modèle de génération, tel que GPT, est utilisé pour créer des réponses textuelles basées sur le contexte fourni par la phase de récupération.

• Architecture du modèle : Un modèle de génération est choisi ou conçu pour produire des réponses créatives. Ce modèle peut être un modèle de langage pré-entraîné comme GPT ou une architecture de génération neuronale personnalisée.
• Intégration : Les modèles de récupération et de génération sont combinés, le modèle de génération utilisant les informations récupérées comme contexte pour produire des réponses.

Avantages du RAG

Le RAG offre plusieurs avantages par rapport aux modèles de génération de texte traditionnels :

• Précision et pertinence accrues : En intégrant des informations récupérées en temps réel, le RAG produit des réponses plus précises et contextuellement pertinentes.
• Transparence et traçabilité : Les modèles RAG peuvent fournir des liens vers les sources des informations utilisées, permettant aux utilisateurs de vérifier l'exactitude des réponses.
• Personnalisation : Les réponses peuvent être personnalisées en fonction des préférences de l'utilisateur, des interactions passées et des données historiques.
• Efficacité : L'automatisation des processus de récupération d'information réduit le temps et les efforts nécessaires pour trouver des informations pertinentes.

Dans les applications de RAG, il faut commencer par optimiser la récupération d’information (retrieval).

Voici une grille d’évaluation de RAG :

Il y a deux domaines dans lesquels votre application RAG peut pêcher

Il existe, en réalité, bien d’autres axes d’optimisation de la partie recherche/récuparation d’information.

Si jamais, en les ayant exploré, vous avez amélioré les résultat, mais que cela ne suffit toujours pars, vous pouvez revenir sur le prompt engineering en testant de nouveaux prompts plus adaptés aux informations récupérées après mise en place du RAG.

Enfin, si cela ne suffit toujours pas, il faut passer aux choses sérieuses :

• Soit fine-tuner le modèle, c’est-à-dire créer un LLM dérivé du LLM standard que vous utilisiez jusqu’ici. Attention, fine-tuner un LLM peut totalement le détraquer ou, à tout le moins, totalement changer son comportement (les réponses qu’il génère).
• Soit changer de LLM, quitte à prendre le risque de devoir reprendre le travail à zéro.

Fine Tuning

Recourir au Fine Tuning, si l’on se réfère à grille de lecture précédente, revient à tenter de résoudre un problème de mémoire apprise (mémoire de long terme, learned memory).

Les développeurs expérimenter fine-tune le LLM, c’est-à-dire qu’ils complètent l’entraînement de base du LLM, grâce à un ensemble de données plus petit et plus spécifique à un domaine afin de l'optimiser pour la tâche spécifique que vous lui avez confiée.

On recourt ainsi au fine-tuning est généralement effectuée pour l'une des deux raisons suivantes :

• Améliorer la précision du modèle pour une tâche spécifique : Entraîner le modèle sur des données spécifiques à une tâche pour résoudre un problème de mémoire apprise en lui montrant de nombreux exemples d'exécution correcte de cette tâche.
• Améliorer l'efficacité du modèle : Obtenir la même précision avec moins de jetons (ce qui permet de réaliser des économies et/ou d’amliorer les temps de réponses, donc l’expérience utilisateur),

Préparation de données

Le processus de mise au point commence par la préparation d'un ensemble de données d'exemples pour l'entraînement. Il s'agit de l'étape la plus critique, car les exemples doivent représenter exactement ce que le modèle devra traiter dans le monde réel, une fois en production.

Pour cela, on constitue une longue bibliothèque de prompts/réponses que l’on fournit ensuite à un framework permettant de fine-tuner le LLM (si l’on développe un LLM Open Source de Mixtral, par exemple, qui fournit un package de Fine-tuning, nomme Mistral-Finetune ou que l’on envoie à l’API de loueur de LLM comme OpenAI).

(Ré)-entrainement du LLM

Attention, il faut avoir à l’esprit que tous les LLMs disponibles via une API ne peuvent pas tous être fine-tunés.

Le cycle d’entraînement commence alors. Selon la plateforme technique vous utilisez vous pouvez, le cas échéant, en profiter pour modifier les « hyperparamètres », comme pour n'importe quel autre modèle de machine learning.

Il est recommandé comme pour l’évaluation de tout modèle de machine learning de conserver une partie du jeu de données constitué pour l’entraînement, à part (c’est-à-dire de ne pas le fournir au modèle lors du fine-tuning), pour vérifier que la version fine-tuné du modèle répond bien. En effet, si l’on demande à la version fine-tuné du LLM de répondre à l’un des prompts/questions qui ont permis de la finetuner, le LLM de fortes de bien répondre, ce qui ne signifie pas qu’il répondre bien à toute autre question.

Garder de côté des données similaires aux données d’entraînement, permet de rapidement évaluer l’efficacité du modèle fine-tuné.

Pour des conseils sur la façon de construire un bon ensemble de données d'entraînement, vous pouvez consulter les conseils d’OpenAI ici et là. Une fois l'entraînement terminé, le nouveau modèle fine-tuné est disponible pour l'inférence (c’est-à-dire, qu’il est prêt à répondre).

Bonnes pratiques pour le fine-tuning

 Les pratiques clés à observer ici sont les suivantes :

• Commencez avant tout par bétonner la partie prompt engineering
  Assurez-vous de disposer d'un solide jeu de données d'évaluation issu de l’étape de prompt engineering, que vous pouvez utiliser comme base de référence (point de comparaison).
• Commencez petit, concentrez-vous sur la qualité
  La qualité des données d'entraînement est plus importante que la quantité lorsqu'il s'agit de fine-tuner un modèle de base. Commencez avec au moins 50 exemples, évaluez (et notamment, vérifiez que vous n’avez pas détraqué le LLM en tentant de le fine-tuné), puis augmentez la taille de votre jeu de données d’entraînement si vous n'avez pas encore atteint le niveau de performance attendu et si, et seulement si, les problèmes à l'origine des mauvaises réponses sont dus à la cohérence/au comportement du LLM et non au contexte (le prompt au sens large)
• Veillez à ce que vos exemples soient représentatifs
  L’un des écueils les plus fréquents est la non-représentativité des données d'entraînement, lorsque les exemples utilisés pour le fine-tuning diffèrent subtilement, par leur format ou leur forme, de ce que le LLM devra traiter en production. Par exemple, si vous avez une application RAG, affinez le modèle avec des exemples RAG afin qu'il n'apprenne pas à utiliser le contexte à zéro. Eh oui, car le LLM fine tuné devra travailler avec des informations issues du RAG, si vous êtes passés par l’étape RAG.

Prompt Engineering + RAG+ Fine Tuning

Ces techniques peuvent potentiellement se compléter, sans que cela soit une règle absolue.

Mais, pour apprécier la complémentarité, voici des éléments à prendre en compte

• Utiliser le fine-tuning pour minimiser le nombre de tokens/jetons utilisés pour le prompt engineering, en remplaçant les instructions et les exemples peu fréquents par de nombreux exemples de formation afin d'ancrer un comportement cohérent dans le modèle (autrement formulé, vous réalisez un gros investissement en technique et en finance pour fine-tuner le modèle, mais après, vous avez besoin de fournir beaucoup moins d’information dans le contexte, pour obtenir des réponses de qualité et comme moins d’information dans le contexte égale moins de tokens égale moindres coûts d’utilisation de l’API d’OpenAI ou de Mistral, vous réalisez des économies sur le moyen terme – jamais sur le long terme, car il faut ré-entrainer les modèles pour les mettre à jour-)
• Utiliser le fine-tuing pour apprendre un comportement complexe au système
• Utiliser la RAG pour injecter du contexte (des informations contextuelles), du contenu plus récent ou tout autre contexte spécialisé nécessaire à vos cas d’usage (données propre au client ou brique de cours dans un chatbot tuteur, par exemple).

A ce stade, vous devez être capable de bien comprendre les concepts de RAG et de fine-tuning, et de savoir quand il est pertinent de recours à l’un ou l’autre.

 La dernière chose que vous avez en tête est la gestion des cycles d’itération/mises à jour :

• Pour la RAG, il faudra ajuster la partie récupération et le comportement du LLM.
• Pour le fine-tuning, à chaque fois, vous devrez à la fois régérer le ré-entrainement du  LLM, du jeu d’apprentissage et du jeu de validation.

Au fure et à mesure que vos demandes au LLM croisseront en complexité, les risques de regression à chaque re-entrainement ou enrichissement des données « récupérées » augmenteront.

Autrement dit, poussez jusqu’au maximum le prompt engineering avant de passer à la RAG ou au fine-tuning, qui augmentent la complexité, le coût et les risques.

Dans la pratique, quand faut-il décider de s’arrêter de fine-tuner ou de « rager » ?

Quels critères utiliser pour décider que le niveau de performance/précision/complétude atteint est suffisant pour passer en production ?

Voici un modèle proposé par OpenAI qui se fonde sur un calcul économique et dont la logique est la suivante.

On attribue une valeur ou un coût à chaque usage du LLM.

Exemple dans le cas d’un chatbot de type service client

• Valeur d’un problème entièrement résolu par le chatbot: 20 €
• Coût d’un échec du chatbot à résoudre le problème et bascule sur un être humain : $40
• Coût de la perte d’un client à cause de la frustration générée par l’échange avec le chatbot : $1000. Imaginons que cela se produise dans e

Faisons le calcul de l’impact économique avec les données suivantes

Sur 1000 échanges avec le chatbot :

• 815 problèmes résolus par le chatbot : 815 x 20 € : 16 300 €
• 175 échecs du chatbot et bascule vers un humain : - 175 x 40 € = 7000 €
• 10 pertes de clients : 10 000€

Gain/perte lié au chatbot : 16300€ -7000€ - 10000 €= - 700 €

Dans ce cas, la mise en production du chatbot n’est pas intéressante parce qu’il génère plus de coûts qu’il ne permet de réaliser d’économie.

Soit il faut continuer d’améliorer les performances du chatbot (en changeant de modèle de fondation ? En poursuivant le fine-tuning ? En améliorant le promet engineering ? En améliorant de système RAG ? …)

Il faudrait évidement inclure dans le calcul les frais d’amortissement le coût de développement et d’exploitation du chatbot.

D’autres éléments à considérer avant de mettre en production :

• CAST : on peut réaliser des enquêtes de satisfaction et calculer un CSAT (Customer Satisfactions Score ou Indice de satisfaction client)
• Le risque juridique
• Les coûts indirects liés à une mauvaise décision (un remboursement non justifié, par exemple)

On peut aussi imaginer, s’il n’est pas possible d’améliorer les performances du LLM de tenter de détecter une partie des cas qui provoquent des départs de clients et d’entraîner le chatbot pour qu’il redirige rapidement ces clients vers un conseiller client, ce qui pourrait, au moins en théorie, permettre d’augmenter la rentabilité du chatbot. On peut imaginer le même type d’approche dans le cas où le chatbot demande à l’internaute de préciser sa demande s’il est pas totalement certain d’avoir compris le besoin du client pour augmenter le niveau de certitude d’identification de l’intention de l’internaute.

Etude de cas concrète : créer un correcteur linguistique

Imaginons que nous créions un correcteur linguistique

Créer une application qui utilise le modèle gpt-4-turbo pour corriger des phrases en islandais (désolé de cet exemple un peu particulier, c’est celui qui figure dans la documentation technique officielle d’Open AI qui a servi de base à la rédaction de cet article).

Utilisation du prompt engineering

On utilise, dans cet exemple, un fichier, l’Icelandic Errors Corpus, contenant des phrases avec des erreurs délibérées en Icelandais, et qui contient également les versions corrigées. Ce fichier a été créé pour permettre aux techniciens qui entraînent des modèles d’avoir de la donné pour réaliser leurs tests. Autrement dit, c’est un fichier qui permet de fournir de la matière à un LLM pour vérifier la capacité de GPT4-Turbo à corriger les erreurs.

Dans le scénario imaginé, on va, donc, envoyer à GPT4-Turbo, une à une, les phrases de ce fichier, en demandant à GPT4-Turbo de corriger la phrase. Ensuite, pour contrôler automatiquement la qualité de la traduction, on utilise un outil de vérification automatique, dénommé « Blue score » qui permet de comparer les versions corrigées par GPT4-Turbo avec les versions corrigées fournis dans l’Icelandic Errors Corpus, pour mesurer la qualité relative de la correction effectuée par GPT4-Turbo.

Si l’on demande, avec un prompt simple présenté ci-dessous à GPT4-Turbo de corriger le texte, il obtient un « blue score » de 62.

Passons maintenant à un prompt agrémenté d’exemples de bonnes corrections pour voir si le blue score augmente.

Ce prompt, transmis à l’API d’OpenIA pour le guider afin qu’il corrige mieux est présenté ci dessous (vous remarquerez que c’est plus qu’un prompt ChatGPT ordinaire).

La valeur du paramètre SYSTEM contient les instructions génériques

Les exemples de bonnes corrections sont fournis sous forme de couple de valeur USER (avec la phrase à corriger) et ASSISTANT avec la version corrigée de la phrase.

Le prompt se termine avec la phrase à corriger

SYSTEM

The following sentences contain Icelandic sentences which may include errors. Please correct these errors using as few word changes as possible.

# Examples

USER

"Stofnendurnir séu margir og eru fulltrúar hennar frá Englandi, Grikklandi, Rússlandi, Svíþjóð og fleiri löndum Evrópu."

ASSISTANT

"Hann segir að stofnendur leynireglunnar séu margir og að fulltrúar hennar séu frá Englandi, Grikklandi, Rússlandi, Svíþjóð og fleiri löndum Evrópu."

USER

"Helsta fæða bjúgorma eru hægfara lífverur sem eru á sama búsvæði og bjúgormarnir, oft smærri ormar eins og burstormar (fræðiheiti: Polychatete)."

ASSISTANT

"Helsta fæða bjúgorma eru hægfara lífverur sem eru á sama búsvæði og bjúgormarnir, oft smærri ormar eins og burstaormar (fræðiheiti: Polychatete)."

USER

"Sörvistölur eru nær hálsi og skartgripir kvenna á brjótsti."

ASSISTANT

"Sörvistölur eru nær hálsi og skartgripir kvenna á brjósti."

USER

[phrase à corriger]

Avec ce prompt, toujours dans le scénario imaginé, on demande à Blue Score de noter la qualité des corrections et le niveau de qualité globale de la traduction est meilleure, puisque l’on obtient avec un Blue Score de 70 (soit +8%).

Cela tend à démontrer que le fait de donner au LLM des exemples de la tâche à réaliser l'aide à apprendre et améliorer ses performances.

C'est satisfaisant, mais on peut faire mieux en s’attaquant non plus au contexte, mais au comportement.

C’est au modèle qu’il faut s’attaquer.

Pour ce faire, on peut tester deux approches.

• Fine-Tuner le LLM

L’hypothèse initiale étant qu'il s'agissait d'un problème d'optimisation du comportement, notre première étape consistera, à fine tuner le modèle.

On essaiera de fine-tuner gpt-3.5-turbo, puis, gpt-4.

• RAG

On essaiera aussi d’intégrer du RAG - dans ce cas, notre hypothèse est que des exemples pertinents peuvent fournir un contexte supplémentaire qui pourrait aider le modèle à résoudre le problème.

Fine-tuner le LLM

Pour fine-tuner le LLM au cas d'usage présent, on utilise un jeu de donnée de 1 000 exemples similaires à aux quelques exemples ci-dessus :

SYSTEM

Les phrases suivantes contiennent des phrases islandaises qui peuvent contenir des erreurs. Veuillez corriger ces erreurs en changeant le moins possible de mots.

UTILISATEUR

"Hið sameinaða fyrirtæki verður einn af stærstu bílaframleiðendum í heiminum."

ASSISTANT

"Hið sameinaða fyrirtæki verður einn af stærstu bílaframleiðendum heims".

On utilise ces 1000 exemples pour entraîner les modèles gpt-3.5-turbo et gpt-4 et on ré-évaluera sur le jeu de données réservés à la validation.

Dans cet exemple, le modèle 3.5 Turbo fine-tuné dépasse en performance (78)  le modèle gpt-4 (70) à qui l’on fournissait quelques exemples (few shot examples).

En revanche, en fine-tunant le modèle GPT4 avec le même jeu de données que celui utilisé pour fine-tuner le GPT3.5Turbo, on gagne encore 11 points de performance au Blue Score et on attend un score proche de ce qu’il faut pour passer en production

Et si l’on ajoutait du RAG au modèle GPT4 fine-tuné ?

On crée une base de connaissance pour le RAG avec 1000 autres exemples de bonnes réponses, stockés dans une base vectorielle afin qu’elle puisse être récupéré et transmis au GPT4 fine-tuné, via un système de RAG.

De façon étonnante, les performances du système baisse de 4 points (score 83 inférieur au score de 87 du GPT4 fine-tuné) comme on le voit ci-dessous.

« Plus » (d’optimisation) ne signifie, donc, pas toujours « mieux » et l’intégration du RAG dans ce cas d’usage précis ne pas permet d’améliorer davantage les performances.

Cela illustre le fait qu'il faut utiliser le bon outil d'optimisation pour la bonne tâche.

Le comportement observé lors des évaluations met en évidence que ce qui était en jeu était un problème d'optimisation du comportement et qu’ajouter un contexte supplémentaire (via le RAG) ne contribuait pas à améliorer les performance :

Il fallait :

- changer de modèle

- Fine-tuner le modèle pour lui apprendre à mieux exécuter une tâche.