RAG, LoRA, few-shot, RLHF… Comment personnaliser un LLM ?

Le fond ou la forme ? Le tout ou la partie ? L’humain ou la machine ? Autant d’angles sous lesquels on peut aborder la personnalisation des grands modèles de langage. Et autant de techniques sous-jacentes.

La distinction fond/forme peut sous-tendre un choix en particulier, entre finetuning (ajustement) et RAG (génération augmentée de récupération).

Le premier procédé implique de surentraîner le modèle avec des informations supplémentaires. On est plutôt sur l’aspect « forme » : assimilation de jargons, développement des capacités de raisonnement, modification de style ou de ton… Il s’agit, en quelque sorte, de faire évoluer la « personnalité » des modèles.

Le RAG se prête davantage au renforcement des connaissances (le « fond »). Il consiste à enrichir les requêtes avec des informations récupérées « à la volée » depuis des sources externes. En première ligne à l’heure actuelle, les bases de données vectorielles. Les éléments qu’on y stocke sont préalablement encodés sous forme de vecteurs. Les invites (requêtes au LLM) le sont aussi, au fil de l’eau. On les projette alors dans l’espace vectoriel pour déterminer les contenus qui en sont les plus proches – traditionnellement, c’est le cosinus qui détermine cette proximité. L’ensemble est concaténé et transmis au modèle.

Les bases de données graphes émergent comme une alternative. Ou, du moins, un complément. Elles permettent de définir des relations entre entités (un résumé et ses sources, deux fragments issus de documents différents…). Cela donne la possibilité de récupérer un élément se trouvant à un “saut logique” d’une requête même s’il en est éloigné dans l’espace vectoriel.

LoRA ou le finetuning allégé

Depuis l’article « fondateur » qui a donné corps à la notion de RAG en 2020, des progrès ont été enregistrés sur l’indexation (ajout de métadonnées, mécanismes de réduction des disparités entre documents…) comme sur la récupération (optimisation des modèles servant à vectoriser, création de vecteurs différents selon le contexte…) et l’intégration dans les invites (compression, positionnement des informations les plus pertinentes aux extrémités…).

La technique de positionnement aux extrémités est née d’un constat : les modèles ont tendance à moins bien traiter les informations localisées au coeur de leur fenêtre de contexte. Ce n’est pas là leur seul écueil. Ils ont aussi une prédisposition à l’oubli à mesure qu’on les surentraîne. La technique dite LoRA (Low-Rank Adaptation) minimise cet effet en « gelant » l’essentiel des poids pour se concentrer sur des matrices spécifiques. L’approche qLoRA y ajoute le principe de quantisation (réduction de la précision, généralement à 4 ou 8 bits). Lors de la conférence NeurIPS 2023 s’est tenu un LLM Efficiency Challenge. Les participants disposaient de 24 heures et d’un GPU pour réaliser l’ajustement le plus optimal possible. Tous les gagnants ont utilisé (q)LoRA.

Parallèlement au risque d’oubli, l’ajustement peut se révéler complexe quand les éléments qu’on souhaite inculquer au modèle vont à l’encontre de ce qu’il a appris jusqu’alors. Attention également à l’obsolescence des connaissances lorsque les données viennent à évoluer.

En son principe même et du fait qu’on peut le définir comme seule source de vérité pour le LLM, le RAG apparaît comme une solution potentielle à ce problème d’obsolescence. Il en soulève toutefois d’autres. En premier lieu, sur les capacités de mise à l’échelle. Plus encore si on combine les méthodes de recherche (lexicale, sémantique, vectorielle…).

Le RAG, autre approche, autres coûts

Sur la question des coûts, on s’épargne certes les frais liés à l’ajustement ainsi qu’à l’hébergement du nouveau modèle, mais la mécanique qui s’enclenche à chaque prompt a un prix. Variable non seulement en fonction des volumes de données transmis (par nature peu prévisibles avec les LLM, sauf à paramétrer des seuils), mais aussi du socle technologique. Illustration sur AWS : il en coûte nettement plus de recourir à OpenSearch et ses capacités vectorielles natives qu’à une base RDS avec extension de type pgvector.

Un modèle ajusté a potentiellement plus d’« agilité », au sens où il est susceptible de délivrer des réponses appropriées à partir d’invites moins précises que ne l’exige le RAG. Ce dernier apporte néanmoins une autre forme de flexibilité : l’adaptation d’un modèle à plusieurs utilisateurs, en variant les sources de données, par exemple en fonction des permissions de chacun. On peut, en outre, l’exploiter comme un cache, pour stocker un historique de conversation qui dépasserait la fenêtre de contexte (l’API Assistant d’OpenAI implémente un tel pipeline). Même s’il existe aujourd’hui diverses techniques pour étendre cette dernière, dont l’interpolation (ajustement des positions de tokens à partir de valeurs intermédiaires non entières) ou RoPE et son extension YaRN (prise en compte de la distance entre les tokens d’entrée et non simplement de leurs positions absolues).

Agir directement sur les prompts

On peut aussi imaginer ajuster un modèle… pour qu’il s’améliore dans l’exercice de la récupération. Meta s’est livré à ce type d’expérience, où le dataset d’entraînement a fait office de base de connaissances. L’expérimentation a reposé sur Chroma, une base vectorielle avec RAG intégré.

Pour qui ne dispose pas d’un tel produit ou souhaite un contrôle fin sur la chaîne de récupération, le framework Llamaindex est une option. Il ouvre notamment la porte à la gestion de données structurées (filtres de métadonnées, récupération récursive…). Quoique plus généraliste, LangChain se prête aussi au RAG. L’implémentation H2OGPT en fait usage.

Piste éventuelle pour faire sans RAG : un entraînement non supervisé suivi d’un ajustement pour le suivi d’instructions sur les cas d’usage voulus. Autre option : insérer des exemples directement dans les invites (few-shot prompting). Ou encore fragmenter ces dernières. Et pourquoi pas se dispenser ainsi de la recherche vectorielle au profit d’une recherche plus classique par mots-clés.

Illustration © tookitook – Adobe Stock