Retrieval-Augmented Generation (RAG)

Modèles d'embedding : Vitesse vs Précision dans RAG

La création d'un système robuste de Génération Augmentée par Récupération (RAG) exige plus que de simples assemblages de LLM et de bases de données vectorielles. L'élément central de cette architecture est le modèle d'embedding, qui transforme le texte non structuré en vecteurs denses pour la recherche sémantique. Dans les environnements de production, vous devez constamment arbitrer entre trois contraintes conflictuelles : la vitesse d'inférence (latence), la précision de la récupération (métriques MRR/R@k) et le coût opérationnel (heures de calcul/GPU).

Cet article compare les modèles d'embedding modernes populaires pour vous aider à prendre des décisions fondées sur des données pour votre cas d'utilisation spécifique.

Le triangle des compromis

Il n'existe pas de « meilleur » modèle d'embedding. Il n'existe que le meilleur modèle pour vos contraintes. Les modèles à haute dimensionnalité comme SentenceTransformers/all-MiniLM-L6-v2 offrent un bon compromis pour de nombreuses applications, tandis que des modèles plus lourds comme E5-Mistral-7B offrent une précision supérieure au prix d'une latence accrue.

Métriques clés à considérer

  • Latence : Temps nécessaire pour encoder une requête unique. Critique pour les expériences utilisateur en temps réel.
  • Débit : Embeddings par seconde par GPU. Affecte les coûts de mise à l'échelle de l'infrastructure.
  • Recall@k : Pourcentage de documents pertinents trouvés parmi les k premiers résultats. C'est votre métrique de précision principale.
  • Dimensionnalité : Des dimensions plus élevées augmentent l'utilisation de la mémoire et le coût des calculs de distance.

Exemple de code de benchmark

Pour effectuer vos propres benchmarks, vous pouvez utiliser la bibliothèque sentence-transformers combinée avec timeit. Voici un script pratique pour mesurer la latence d'inférence et l'utilisation de la mémoire.

import time
from sentence_transformers import SentenceTransformer

def benchmark_model(model_name, texts):
    print(f"Chargement du modèle : {model_name}...")
    model = SentenceTransformer(model_name)
    
    # Exécution de préchauffage
    model.encode(texts[:10])
    
    start_time = time.time()
    # Benchmark de la vitesse d'encodage
    embeddings = model.encode(texts)
    end_time = time.time()
    
    latency = (end_time - start_time) / len(texts)
    print(f"Modèle : {model_name}")
    print(f"Latence moyenne par doc : {latency*1000:.2f} ms")
    print(f"Forme de l'embedding : {embeddings.shape}")
    print("-" * 30)

# Exemple d'utilisation
dataset = ["Le ciel est bleu.", "Les robots vont prendre le contrôle.", "Python est génial."]
benchmark_model("sentence-transformers/all-MiniLM-L6-v2", dataset)

Recommandations de modèles par cas d'utilisation

1. Faible latence, haute efficacité coûts

Pour la recherche interne en entreprise ou les applications à haut débit où une latence inférieure à 10 ms est requise, sentence-transformers/all-MiniLM-L6-v2 reste la référence de l'industrie. Il fonctionne efficacement sur les CPU, réduisant considérablement les coûts de GPU cloud.

2. Équilibre entre précision et vitesse

Pour les chatbots grand public, bge-large-en-v1.5 offre une augmentation significative de la précision par rapport à MiniLM avec une augmentation modeste de la latence. Il est optimisé pour l'anglais et gère bien les contextes longs.

3. Précision maximale pour les requêtes complexes

Si vos documents sont très techniques ou si les requêtes sont ambiguës, envisagez E5-Mistral-7B. Ce modèle s'appuie sur un backbone de grand modèle linguistique pour les embeddings, offrant un recall de pointe. Cependant, il nécessite une accélération GPU et entraîne des coûts opérationnels plus élevés.

Conclusion

Le choix d'un modèle d'embedding est une décision stratégique qui impacte l'expérience utilisateur et la rentabilité de votre pipeline RAG. Commencez par une base comme MiniLM, puis testez incrémentalement des modèles plus lourds sur votre jeu de données spécifique en utilisant des métriques comme le MRR (Mean Reciprocal Rank). Profillez toujours la latence sous charge, et non pas uniquement isolément, pour garantir que votre déploiement en production reste réactif et rentable.

Share: