Introduction à la personnalisation des LLM
Ces dernières années, les progrès rapides de l’intelligence artificielle ont conduit au développement de grands modèles de langage (LLMs), révolutionnant le domaine du traitement automatique du langage naturel (NLP). Ces modèles puissants, tels que ChatGPT, Llama, Mistral, Zephyr, et d’autres, ont démontré des capacités supérieures pour comprendre et générer un langage semblable à celui des humains.
Cependant, ces LLMs ont des limites. Ils sont entraînés sur une grande quantité de données avec une date limite spécifique, ce qui signifie que si nous les utilisons pour générer des réponses qui nécessitent des connaissances plus récentes que leurs données d’entraînement, nous risquons d’obtenir des réponses inexactes. Il est donc essentiel d’adapter ces modèles à nos tâches et domaines spécifiques afin de libérer tout leur potentiel. C’est là que la personnalisation des LLM entre en jeu.
Lors d’un récent Unstructured Data Meetup de Zilliz à Seattle, le CEO d’OSS4AI et ancien Senior Developer Advocate de Zilliz, Yujian Tang, a présenté plusieurs options pour personnaliser les LLMs afin d’améliorer leurs performances sur des tâches spécifiques. Avant d’aborder les différentes options de personnalisation d’un LLM, explorons brièvement l’histoire des LLMs.
Regardez le replay de la conférence de Yujian
Brève histoire des LLMs
La recherche ayant conduit à la création des LLMs a parcouru un long chemin, à partir de l’architecture de réseau neuronal de base. Une couche de réseau neuronal de base se compose d’une couche d’entrée, d’une ou plusieurs couches cachées et d’une couche de sortie, comme le montre le graphique ci-dessous.
Architecture de réseau neuronal
L’architecture de réseau neuronal de base s’est révélée très puissante pour les tâches de classification et peut gérer des données non structurées telles que des textes et des images. Cependant, elle est inefficace pour les tâches nécessitant des dépendances à long terme ou un traitement séquentiel, ce qui est essentiel pour les tâches de langage naturel. Dans les réseaux neuronaux de base, chaque entrée est traitée indépendamment, et la sortie est générée uniquement sur la base de l’entrée actuelle. Cela signifie que les réseaux neuronaux ne tiennent pas compte de l’ordre ni du contexte de l’entrée par rapport à l’ensemble de la séquence.
Sans la capacité de gérer les dépendances à long terme, un réseau neuronal ne peut pas inférer le sens sémantique d’une séquence d’entrée ou d’un texte entier — la création des réseaux neuronaux récurrents (RNNs) visait à résoudre ce problème.
Les RNNs résolvent le problème en introduisant un état caché, qui agit comme une mémoire capturant les informations de ce que le réseau a déjà vu. Cet état caché est transmis d’un pas de temps au suivant, permettant au réseau de maintenir une représentation de la séquence. L’ajout d’un état caché permet aux RNNs de se souvenir ou d’oublier sélectivement des informations de la séquence d’entrée, ce qui les rend plus efficaces que les réseaux neuronaux de base pour les dépendances des séquences d’entrée.
Architecture RNN
Cependant, les RNNs présentent également plusieurs limites, telles que :
Problème de disparition du gradient : les RNNs souffrent du problème de disparition du gradient, où les gradients utilisés pour mettre à jour les paramètres du modèle pendant l’entraînement deviennent plus petits à mesure qu’ils sont rétropropagés dans le temps. Ce problème rend difficile pour les RNNs l’apprentissage des dépendances à long terme dans les séquences.
Traitement séquentiel : les RNNs traitent les séquences de manière séquentielle, ce qui limite leur capacité à paralléliser le calcul et les rend moins efficaces sur le plan computationnel.
Ces limitations des RNN ont conduit au développement du Transformer, qui utilise un mécanisme d’auto-attention pour traiter les séquences d’entrée en parallèle et éviter le problème de disparition du gradient.
Architecture Transformer
L’architecture Transformer se compose de plusieurs blocs d’encodeur et de décodeur. Chaque bloc d’encodeur et de décodeur contient une couche spéciale appelée couche d’attention. Cette couche joue un rôle crucial dans la détermination du sens sémantique de chaque token par rapport à l’ensemble de la séquence d’entrée. Par exemple, considérez les trois phrases suivantes :
Apple a réalisé un bénéfice de 97 milliards de dollars en 2023
J’aime manger une tarte aux pommes pour le profit en 2023
Le résultat net d’Apple a augmenté de manière record en 2023
Si nous utilisons uniquement une approche traditionnelle, comme une approche basée sur les mots-clés, les deux premières phrases formeront la paire la plus similaire. Nous avons trouvé trois mots-clés similaires dans ces deux phrases : Apple, 2023 et profit.
Cependant, nous savons que les première et troisième phrases sont les paires les plus similaires sur le plan sémantique. La couche d’attention au sein de l’architecture Transformer peut capturer ce contexte et renvoyer les première et troisième comme la paire la plus similaire sur le plan sémantique.
Les performances puissantes et la polyvalence des modèles Transformers ont entraîné des avancées rapides de l’IA dans différents domaines, de la vision par ordinateur au NLP et aux tâches multimodales.
L’un des modèles introduits après le grand succès des Transformers est le modèle Generative Pretrained Transformers (GPT). Ce modèle utilise la partie décodeur de l’architecture Transformer pour prédire le token suivant dans une séquence d’entrée et sert de colonne vertébrale à de nombreux LLMs que nous connaissons jusqu’à présent, tels que ChatGPT et Llama.
Architecture GPT
Ces LLMs sont très puissants pour générer des réponses semblables à celles d’un humain, car ils ont été entraînés sur d’énormes quantités de données. Cependant, comme vous le savez peut-être déjà, les données d’entraînement ont une date limite, ce qui signifie que nous n’obtiendrons pas de réponse précise de nos LLMs si nous posons des questions sur des informations plus récentes que leurs données d’entraînement. C’est là que nous devons personnaliser nos LLMs.
Génération augmentée par récupération (RAG)
La première façon de personnaliser notre LLM est via RAG, et son concept est assez simple. Nous fournissons aux LLMs à la fois la requête et les contextes pertinents en entrée, ce qui leur permet de générer des réponses contextuelles et précises en exploitant les contextes fournis.
Architecture RAG
Pour exploiter les LLMs pour RAG, nous avons besoin de deux composants essentiels :
Modèle d’embedding vectoriel : Un modèle qui transforme notre requête et nos contextes en embeddings vectoriels.
Base de données vectorielle : Une base de données pour stocker tous les embeddings de contexte et effectuer une recherche vectorielle afin de fournir à nos LLMs les contextes les plus pertinents et les plus similaires sur le plan sémantique en fonction de la requête.
Plusieurs modèles peuvent être utilisés pour générer des embeddings vectoriels, notamment des modèles de deep learning d’OpenAI ou des sentence transformers. Alternativement, des modèles traditionnels basés sur le sac de mots comme TF-IDF ou BM25 peuvent également être employés.
Milvus est une base de données vectorielle open source populaire. Elle stocke les données nécessaires, composées de deux types : les embeddings vectoriels générés par le modèle et leurs métadonnées. Par exemple, considérons un extrait de texte d’un article publié par Towards Data Science le premier jour de juin 2023. Les données stockées dans la base de données vectorielle Milvus pourraient ressembler à ceci :
Exemple de données d’embedding vectoriel et de leurs métadonnées
Les métadonnées sont utiles pour effectuer divers filtres lors des opérations de recherche vectorielle afin de fournir à nos LLM des contextes plus précis. Par exemple, vous pourriez vouloir récupérer des contextes provenant d’une publication spécifique ou ceux publiés après une certaine date (par exemple, 2020).
Une fois que nous avons la requête et que nous connaissons les métadonnées spécifiques que nous voulons filtrer, une base de données vectorielle comme Milvus fera son travail. Elle effectuera une recherche vectorielle pour trouver les contextes les plus similaires sémantiquement à notre requête qui satisfont aux conditions de filtrage des métadonnées.
Réglage fin
Une autre approche pour personnaliser les LLM consiste à recourir au réglage fin. Le concept est simple : nous entraînons un LLM pré-entraîné sur nos propres données, ce qui donne des modèles avec de nouveaux poids adaptés pour effectuer des tâches propres à notre domaine de données.
Il existe plusieurs façons d’affiner les LLM :
Réglage fin complet : Cette approche modifie les poids de tous les paramètres au sein du LLM original. Cependant, elle implique un processus de calcul coûteux.
LORA : Cette approche introduit des adaptateurs de faible rang au sein de l’architecture du LLM. Les poids d’origine sont gelés pendant le réglage fin, et seuls les poids des adaptateurs sont mis à jour.
QLORA : Cette approche introduit la quantification dans la méthode LORA originale, réduisant les coûts de calcul et les ressources tout en préservant des performances raisonnables.
Réglage fin complet vs LORA
Maintenant que nous connaissons les différentes méthodes de réglage fin, discutons des différentes techniques de réglage fin :
Réglage fin supervisé : Dans cette méthode, nous fournissons à nos LLM nos propres données d’entraînement et les étiquettes correspondantes. Nous entraînons ensuite nos LLM comme n’importe quel modèle d’apprentissage automatique supervisé.
Apprentissage par renforcement à partir de retours humains (RLHF) : Cette méthode intègre la théorie de l’apprentissage par renforcement. Nous collectons diverses réponses du LLM à partir d’une requête, puis évaluons la qualité de chaque réponse. Au fil du temps, nos LLM produisent des réponses qui correspondent à nos préférences.
Réglage fin supervisé vs apprentissage par renforcement à partir de retours humains
Puisque le réglage fin supervisé est simple, discutons plus en détail du RLHF. Un inconvénient du RLHF natif est la nécessité pour les humains d’évaluer la qualité des réponses générées par les LLM. Cette approche est coûteuse et chronophage.
Les data scientists ont introduit l’optimisation proximale de politique (Proximal Policy Optimization, PPO) pour atténuer ce problème.PPO introduit un modèle de récompense pour remplacer l’évaluation humaine. Cependant, ce modèle de récompense doit être entraîné séparément, ce qui rend l’application de PPO fastidieuse. De plus, le modèle de récompense doit être réentraîné chaque fois que de nouvelles données sont ajoutées.
Pour résoudre ces problèmes, l’optimisation directe des préférences (Direct Preference Optimization, DPO) a été introduite. DPO optimise la politique du LLM en utilisant la fonction de perte de log-vraisemblance négative sur des données de préférences humaines. Le jeu de données pour le réglage fin avec DPO se compose de prompts, de réponses préférées et de réponses non préférées :
Exemple du format de données utilisé pour affiner les LLM avec DPO
Cependant, DPO a tendance à surajuster rapidement le jeu de données de préférences. Pour atténuer ce problème, l’optimisation des préférences d’identité (Identity Preference Optimization, IPO) a été développée.
IPO introduit un terme de régularisation dans la fonction de perte DPO afin d’éviter le surapprentissage. Il utilise également un terme de rapport de cotes logarithmique ajouté à la fonction de perte de log-vraisemblance négative (NLL), permettant au LLM d’être affiné selon le style souhaité tout en pénalisant les réponses non préférées.
Conclusion
Yujian Tang a présenté différentes façons de personnaliser les LLM pour une utilisation optimale dans nos cas d’usage spécifiques lors de son exposé. La présentation a commencé par un bref historique des avancées de l’IA qui ont conduit au développement des LLM. Ce sujet a été suivi d’une explication de deux méthodes pour personnaliser les LLM : RAG et le fine-tuning.
RAG améliore la qualité des réponses générées par les LLM en injectant des contextes pertinents avec la requête en tant qu’entrées. Les bases de données vectorielles comme Milvus stockent les embeddings de contexte et effectuent des recherches vectorielles pour mettre en œuvre RAG. Les LLM utilisent ensuite ces contextes pour générer des réponses appropriées.
La deuxième approche est le fine-tuning, et il existe deux méthodes de fine-tuning :
Fine-tuning supervisé : Cette méthode consiste à fournir à nos LLM nos propres données d’entraînement et les étiquettes correspondantes, puis à les entraîner comme n’importe quel modèle d’apprentissage automatique supervisé.
Apprentissage par renforcement à partir de feedback humain (RLHF) : Cette méthode intègre la théorie de l’apprentissage par renforcement, où nous collectons diverses réponses du LLM à partir d’une requête et évaluons la qualité de chaque réponse. Au fil du temps, nos LLM produisent des réponses qui correspondent à nos préférences.
Pour plus de détails sur la personnalisation des LLM, regardez le replay de l’exposé de Yujian.
Continuer à lire
What Is a Vector Lakebase?
A Vector Lakebase is a unified, lake-native data architecture for AI that combines vector-database-grade serving with open lake storage, reusable lake-level indexes, and a shared semantic layer.
Creating Collections in Zilliz Cloud Just Got Way Easier
We've enhanced the entire collection creation experience to bring advanced capabilities directly into the interface, making it faster and easier to build production-ready schemas without switching tools.
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.