À retenir
- Enfin, le fine-tuning du générateur. Devriez-vous fine-tuner le LLM que vous utilisez pour la génération?
- Toutes les requêtes ne se valent pas. Certaines n’ont même pas besoin de recherche, puisque le grand modèle de langage connaît déjà la réponse.
- Le modèle devient plus robuste et fournit de meilleures réponses dans l’ensemble.
Bonjour tout le monde! Je suis Louis-François, cofondateur et CTO de Towards AI. Aujourd’hui, nous explorons ce qui pourrait bien être la meilleure stack de génération augmentée par la recherche d’information (RAG), grâce à une excellente étude de Wang et al., 2024. Elle regorge d’observations utiles pour construire des systèmes RAG optimaux, et je suis ici pour vous l’expliquer.
Alors, qu’est-ce qui rend un système RAG réellement excellent? Ses composants, n’est-ce pas? Passons en revue les meilleurs composants et leur fonctionnement afin que vous puissiez vous aussi construire un excellent système RAG, puis terminons avec un bonus sur la multimodalité.
Classification des requêtes
Commençons par la classification des requêtes. Toutes les requêtes ne se valent pas. Certaines n’ont même pas besoin de recherche, puisque le grand modèle de langage connaît déjà la réponse. Si vous demandez par exemple « Qui est Messi? », le LLM sait quoi vous répondre. Aucune recherche nécessaire!
Wang et al. ont créé 15 catégories de tâches afin de déterminer si une requête fournissait assez d’information ou si une recherche était nécessaire. Ils ont entraîné un classificateur binaire pour séparer les tâches, avec l’étiquette « suffisante » lorsqu’aucune recherche n’était nécessaire et « insuffisante » lorsqu’il fallait en effectuer une. Dans cette image, le jaune signifie qu’il n’y en a pas besoin, tandis que le rouge indique qu’il faut aller chercher des documents!
Découpage
Ensuite vient le découpage. Le défi consiste à trouver la taille de bloc parfaite pour vos données. Trop long? Vous ajoutez du bruit et des coûts inutiles. Trop court? Vous perdez du contexte.
Wang et al. ont découvert que des blocs de 256 à 512 tokens fonctionnaient le mieux. Mais rappelez-vous que cela varie selon les données, alors exécutez vos évaluations! Conseil de pro : utilisez small2big, qui commence par de petits blocs pour la recherche avant de passer à de plus grands blocs pour la génération, ou essayez des fenêtres glissantes pour faire chevaucher les tokens entre les blocs.
Métadonnées et recherche hybride
Exploitez vos métadonnées! Ajoutez des éléments comme les titres, les mots-clés ou même des questions hypothétiques. Combinez le tout à la recherche hybride, qui réunit la recherche vectorielle pour les correspondances sémantiques et le bon vieux BM25 pour la recherche traditionnelle par mots-clés, et le tour est joué.
HyDE, qui génère des pseudo-documents pour améliorer la recherche, est cool et produit même de meilleurs résultats, mais il est très inefficace. Pour l’instant, restez avec la recherche hybride. Elle offre un meilleur équilibre, surtout pour le prototypage.
Modèle d’embedding
Choisir le bon modèle d’embedding ressemble à trouver la parfaite paire de chaussures. Vous ne voulez pas porter des souliers de soccer pour jouer au tennis. LLM-Embedder, de FlagEmbedding, convenait le mieux à cette étude grâce à son excellent équilibre entre performances et taille. Ni trop grand ni trop petit. Exactement ce qu’il fallait.
Notez seulement que les chercheurs ont testé des modèles open source. Cohere et OpenAI étaient donc exclus. Autrement, Cohere représente probablement votre meilleure option.
Base de données vectorielle
Passons maintenant à la base de données. Pour une utilisation à long terme, Milvus est leur base de données vectorielle de prédilection. Elle est open source, fiable et constitue une excellente option pour assurer le bon fonctionnement de votre système de recherche. J’ai aussi placé son lien dans la description ci-dessous.
Transformation des requêtes
Avant la recherche, vous devez transformer les requêtes des utilisateurs! Vous pouvez passer par la réécriture de requête pour les clarifier, la décomposition de requête pour diviser une question complexe en questions plus petites et lancer une recherche pour chaque sous-question, ou même générer des pseudo-documents, comme le fait HyDE, et les utiliser dans le processus de recherche. Cette étape est essentielle pour améliorer la précision. Rappelez-vous seulement que chaque transformation peut ajouter de la latence, surtout HyDE.
Reranking
Parlons maintenant du reranking. Après avoir récupéré les documents, vous devez vous assurer que les plus pertinents se trouvent au sommet de la pile. Voilà le rôle du reranking.
Dans cette étude, monoT5 s’est démarqué comme la meilleure option pour équilibrer les performances et l’efficacité. Il fine-tune le modèle T5 afin de réordonner les documents selon leur pertinence pour la requête, ce qui place la meilleure correspondance en premier. RankLLaMA a offert les meilleures performances globales, mais TILDEv2 était le plus rapide. L’article contient plus d’information sur chacun si le sujet vous intéresse.
Réarrangement des documents
Après le reranking, vous devrez réarranger les documents. Wang et al. recommandent la méthode « inverse », où les documents sont placés en ordre croissant de pertinence. Liu et al. (2024) ont découvert que cette approche, qui place l’information pertinente au début ou à la fin, améliore les performances. Une fois le reranking terminé, le réarrangement optimise la présentation de l’information au LLM en vue de la génération. Il l’aide à mieux comprendre l’information fournie lorsqu’elle est présentée dans un meilleur ordre plutôt que dans son ordre de pertinence théorique.
Résumé
Avant d’appeler le LLM, éliminez ensuite le superflu avec un résumé. Les longs prompts envoyés au LLM coûtent cher et sont souvent inutiles. Le résumé aide à retirer l’information redondante ou inutile et à réduire les coûts.
Utilisez des outils comme Recomp pour effectuer une compression extractive qui sélectionne les phrases utiles et une compression abstractive qui synthétise l’information de plusieurs documents. Mais si la vitesse représente votre priorité, vous pourriez sauter cette étape.
Fine-tuning du générateur
Enfin, devriez-vous fine-tuner le LLM que vous utilisez pour la génération? Absolument! Le fine-tuning avec un mélange de documents pertinents et aléatoires améliore la capacité du générateur à gérer l’information non pertinente. Le modèle devient plus robuste et fournit de meilleures réponses dans l’ensemble. L’article ne précise aucun ratio exact, mais les résultats sont clairs : le fine-tuning en vaut l’effort! Cela dépend bien sûr aussi de votre domaine.
Multimodalités
Vous travaillez avec des images? Implémentez une recherche multimodale. Pour passer du texte à l’image, interroger une base de données afin de trouver des images semblables accélère le processus. Pour passer de l’image au texte, la recherche d’images semblables récupère des légendes exactes stockées à l’avance. Tout repose sur l’ancrage dans les faits, soit la récupération d’information réelle et vérifiée.
Conclusion
En bref, l’article de Wang et al. nous donne un plan solide pour construire un système RAG efficace. Gardez toutefois en tête qu’il ne s’agit que d’un article et qu’il ne couvre pas tous les aspects du pipeline RAG. L’entraînement conjoint du système de recherche et du générateur n’a par exemple pas été exploré et pourrait libérer encore plus de potentiel. Les chercheurs n’ont pas non plus approfondi les techniques de découpage en raison des coûts, mais cette direction mérite d’être explorée.
Je vous recommande fortement de consulter l’article complet pour obtenir plus d’information. Nous avons aussi récemment lancé notre livre « Building LLMs for Production », qui regorge d’observations, de conseils et d’exemples pratiques sur le RAG et le fine-tuning pour vous aider à construire et à améliorer vos systèmes fondés sur des LLMs. Le lien vers les versions physique et numérique se trouve aussi dans la description ci-dessous.
Et comme toujours, merci d’avoir lu. Si cette analyse vous a été utile ou si vous avez des commentaires, dites-le-moi dans les commentaires ci-dessous. On se retrouve dans le prochain!
Références
Building LLMs for Production : https://amzn.to/4bqYU9b
Wang et al., 2024 (référence de l’article) : https://arxiv.org/abs/2407.01219
LLM-Embedder (modèle d’embedding) : https://huggingface.co/BAAI/llm-embedder
Milvus (base de données vectorielle) : https://milvus.io/
Liu et al., 2024 (réarrangement des documents) : https://arxiv.org/abs/2307.03172
Recomp (outil de résumé) : https://github.com/carriex/recomp
FAQ
Chaque question d’un utilisateur exige-t-elle une recherche?
Non. Un routeur peut éviter la recherche pour des questions simples et connues, puis récupérer des documents seulement lorsque des preuves externes sont utiles.
Qu’est-ce que le routage des requêtes dans le RAG?
Il classe une requête et détermine si, où et comment le système devrait rechercher du contexte.
Pourquoi reranker les passages récupérés?
Le reranking applique un modèle de pertinence plus puissant afin de placer les preuves réellement utiles devant les candidats vaguement liés.
À quoi sert le réarrangement du contexte?
Il réorganise les passages sélectionnés dans un ordre qui aide le générateur à mieux les interpréter et les utiliser.
Comment les équipes devraient-elles choisir entre les techniques RAG?
Appliquez un changement à la fois et mesurez le rappel de la recherche, la qualité des réponses, la latence et les coûts sur des requêtes représentatives.