Transformer les processus de gestion des connaissances

Plus d’un an s’est écoulé depuis le lancement très médiatisé de ChatGPT par OpenAI. Après l’euphorie initiale, des travaux pragmatiques autour des modèles de langue (Large Language Model – LLM) ont permis, dans tous les secteurs, de mieux discerner les opportunités offertes ainsi que les risques et limites intrinsèques.

Concernant le traitement des données personnelles et d’entreprise, des enjeux de souveraineté et de confidentialité se posent, notamment avec des éditeurs de logiciels basés hors d’Europe.

La France n’est pas en reste, avec des acteurs majeurs de l’intelligence artificielle (IA) tels que Mistral, dont les modèles open source rivalisent avec ceux de grandes entreprises comme Meta et OpenAI, et Hugging Face, fondée par des Français, devenue une plateforme mondialement reconnue de recherche et d’utilisation de solutions d’IA.

L’usage quotidien de ces modèles montre qu’ils peuvent augmenter la productivité, surtout pour les tâches impliquant un traitement textuel intensif. Cependant, des faiblesses telles que leur capacité limitée à gérer de grands volumes de documents et leur tendance à générer des réponses plausibles mais incorrectes – un phénomène souvent qualifié d’hallucination – sont rapidement devenues évidentes. Néanmoins, leur potentiel de transformation des processus de gestion des connaissances est indéniable.

Malgré leur appellation, les outils de gestion des connaissances (knowledge management) ne constituaient bien souvent jusqu’à ce jour que des outils de gestion de données améliorés. Ils permettaient à un utilisateur d’identifier, au sein d’un corpus, les documents susceptibles de lui être utiles pour traiter une question. Toutefois, la lecture et l’analyse des informations pertinentes au sein des documents identifiés grâce au système, tâche souvent longue et fastidieuse, revenaient encore à l’utilisateur.

Les LLM sont capables de traiter des informations sémantiques : le système identifie lui-même les informations les plus utiles au sein même des documents.

Pour atteindre cet objectif, il est nécessaire de tenir compte des limites susmentionnées des LLM. Ainsi, des développements intensifs sont réalisés par des entreprises et des équipes de recherche sur un processus appelé « Retrieval-Augmented Generation » (RAG), dont l’objectif premier est de connecter les LLM avec des bases de données, internes ou externes à l’entreprise, afin d’améliorer les capacités des modèles de langue et leur factualité. Un exemple typique d’application est l’automatisation, grâce à l’IA, de la tâche consistant à compiler des propositions commerciales précédentes pour en élaborer une nouvelle, en insérant des données de contexte propres au nouveau prospect.

Les systèmes de RAG combinent l’extraction d’informations à partir de sources variées – comme des documents internes à l’entreprise ou des données issues d’internet – et la génération de texte, pour répondre de manière précise aux requêtes de l’utilisateur.

Dans un processus RAG (voir schéma), deux types de données sont fournis au système d’IA : la requête textuelle de l’utilisateur ; une ou plusieurs sources d’information à partir desquelles l’utilisateur souhaite extraire des données. Requête et source d’information vont alors subir plusieurs traitements.

La requête de l’utilisateur est transmise à un modèle dit d’embedding, qui la convertira en un vecteur numérique. Ce vecteur représente la signification sémantique de la requête dans un espace vectoriel multidimensionnel, ce qui permet de mesurer des proximités sémantiques.

Dans un contexte bancaire, une requête relative à l’analyse de risque de crédit pourrait par exemple avoir pour vecteur (2;3;5), reflétant son appartenance au domaine de la gestion du risque. Cette requête serait très différente d’une requête concernant, par exemple, les stratégies d’investissement en actions, qui pourrait avoir pour vecteur (6;5;1), indiquant un focus sur les marchés d’actions. Cependant, elle serait proche d’une requête sur la gestion de portefeuille de crédit immobilier, qui pourrait avoir pour vecteur (2;3;7), en raison de leur thématique commune centrée sur le crédit. Cette requête vectorisée est ensuite stockée dans une base de données vectorielle.

Les documents sont traités de manière analogue. Avant vectorisation, ils subissent une segmentation : chaque document est divisé en plusieurs segments, étape essentielle car un document unique peut contenir des informations très différentes.

Par exemple, dans un rapport d’analyse de marché bancaire, on pourrait distinguer des segments portant sur l’évolution des taux d’intérêt, vectorisé en (2;4;1), proche de celui des taux d’intérêt ou les performances des fonds d’investissement, vectorisé en (4;5;1), dont le contexte sémantique sera probablement plus éloigné du crédit. Ces informations, dont le contenu sémantique est différent, doivent être séparées pour faciliter leur traitement. Chaque segment est alors vectorisé et stocké dans une base de données vectorielle.

Une fois la requête et les documents vectorisés, un modèle de recherche de similarité analyse les vecteurs pour identifier les segments de documents les plus pertinents par rapport à la requête. Ce modèle compare la représentation vectorielle de la requête avec celles des segments pour sélectionner ceux qui correspondent le mieux.

Enfin, la requête et les segments associés sont transmis au LLM, qui génère une réponse à la demande de l’utilisateur en intégrant les informations extraites des segments de documents.

De nouveaux systèmes de RAG sont régulièrement mis à disposition par les développeurs. Ils visent notamment à améliorer les performances sur le traitement homogène des informations contenues dans de longs documents et la diminution des hallucinations. Dans les prochains mois, des systèmes plus performants et fiables devraient donc voir le jour. En attestent les annonces régulières faites par OpenAI à ce sujet ou les travaux importants de la communauté open source sur des outils appelés « orchestrateurs », tels que LangChain ou Llamaindex, qui visent notamment à améliorer le processus RAG.

À ce jour, pour s’assurer de la véracité des informations produites par un modèle de langue, il reste indispensable qu’un être humain réalise la revue des informations produites par un outil de RAG.

Néanmoins, au regard des capacités de ces modèles, une acculturation et une montée en compétences des collaborateurs doivent être envisagées dans les mois et années à venir. Les équipes intervenant sur des tâches textuelles telles que la préparation de documents réglementaires seront probablement les premières impactées. Correctement implémentées, ces solutions limiteront le temps passé à des activités chronophages et souvent laborieuses pour se focaliser sur la prise de décision et la créativité.