Porteur : DINUM

Chef de produit : Pierre-Etienne Devineau

Participants : ReciTAL

Le problème

Le succès phénoménal de ChatGPT suite à sa mise en service en novembre 2022 a incité les entreprises et les administrations à se doter de chatbots internes aux performances équivalentes et adaptés à leurs données internes. De plus, pour une partie d’entre elles, l’utilisation de systèmes hors de leur cloud n’est pas envisageable pour des raisons de sécurité et de propriété des données.

L’approche RAG, pour Retrieval Augmented Generation, ou Génération Augmentée par la Recherche, s’est développée pour répondre à ces contraintes. Le RAG permet de proposer des chatbots qui utilisent les données internes de la structure tout en interagissant à la manière d’un chatbot.

Si l’approche RAG fonctionne très bien et a donné lieu à l’émergence de nombreux projets / startups / produits, elle pose néanmoins un certain nombre de difficultés, notamment celle de son évaluation. Dans le contexte du RAG en effet, les réponses renvoyées par le système sont des phrases ou des paragraphes entiers pouvant porter sur une multitude de sujets selon la taille du corpus de connaissance, générées de manière originale en fonction d’une infinité possible de questions. Comment alors s’assurer que la réponse renvoyée par le RAG est correcte pour une question donnée ?

Les difficultés les plus fréquentes dans ce genre de système sont :

• les hallucinations, lorsque le LLM “invente” une information qui peut être fausse ou sans lien avec les chunks récupérés
• les biais, lorsque le LLM renvoie un texte partial
• les discours problématiques, insultants, racistes ou toxiques

Il est possible de contrôler autant que possible les textes renvoyés par un LLM, la plupart du temps à l’aide de vérification humaine consommatrice en temps et par essence jamais exhaustive. Que faire alors lorsqu’une nouvelle version du RAG est livrée, suite à une mise à jour de la brique d’indexation et/ou de de génération ? Il n’est pas imaginable de recommencer tous les tests manuels qui avaient permis la mise en production de la version précédente.

L’innovation

Si l’approche RAG fonctionne très bien et a donné lieu à l’émergence de nombreux projets / startups / produits, elle pose néanmoins un certain nombre de difficultés, notamment celle de son évaluation. Dans le contexte du RAG en effet, les réponses renvoyées par le système sont des phrases ou des paragraphes entiers pouvant porter sur une multitude de sujets selon la taille du corpus de connaissance, générées de manière originale en fonction d’une infinité possible de questions. Comment alors s’assurer que la réponse renvoyée par le RAG est correcte pour une question donnée ? Les difficultés les plus fréquentes dans ce genre de système sont :

• les hallucinations, lorsque le LLM “invente” une information qui peut être fausse ou sans lien avec les chunks récupérés
• les biais, lorsque le LLM renvoie un texte partial
• les discours problématiques, insultants, racistes ou toxiques

Il est possible de contrôler autant que possible les textes renvoyés par un LLM, la plupart du temps à l’aide de vérification humaine consommatrice en temps et par essence jamais exhaustive. Que faire alors lorsqu’une nouvelle version du RAG est livrée, suite à une mise à jour de la brique d’indexation et/ou de de génération ? Il n’est pas imaginable de recommencer tous les tests manuels qui avaient permis la mise en production de la version précédente.

La stratégie

Afin de pouvoir tester un RAG de manière agnostique, i.e. sans avoir à en connaître le fonctionnement, un FactGenerator part des réponses validées par des humains pour en extraire des faits vérifiables.

Ces faits sont revus par des utilisateurs humains pour en valider la cohérence et la pertinence.

Par la suite, la comparaison avec une nouvelle version du RAG, quelle qu’en soit la différence (Retriever, Generator, les deux, ou encore un autre élément) est réalisée sur la base de ces faits par le Validator.

Pour chaque question du jeu de test, les faits qui lui sont associés sont validés par rapport à la réponse effectuée par la nouvelle version du RAG. Si tous les faits sont vérifiés, alors la nouvelle version fonctionne au moins aussi bien que la précédente sur ces points de contrôle. Dans les deux cas, FactGenerator et Validator sont basés sur des grands modèles de langue. L’objectif du projet est, en plus de proposer une bibliothèque permettant la mise en oeuvre simple de cette approche, d’inclure également des LLM open source fine tunés pour le FactGenerator et le Validator. Les données d’entraînement seront récupérées au cours du projet pour la phase d’ajustement (fine tuning). Les résultats du projet sont donc :

• L’équipe Albert autonome sur les tests de sa plateforme
• Un repo Github Ragtime avec une communauté dynamique
• Une méthodologie éprouvée
• Deux LLM fine tunés

Montant

Pour les 6 mois conduisant à la mise en service, une équipe externe sera mobilisée sur un forfait de 100 000€. La DINUM mobilisera une équipe interne pour un montant de masse salariale équivalent.