LLM-based Retrieval ou Embedding-based Retrieval ? Les deux, merci !

, par Bertrand Degoy

LLM-based Retrieval utilise directement la capacité des grands modèles de langage à comprendre et raisonner sur une requête ; Embedding-based Retrieval transforme documents et requêtes en vecteurs et récupère par similarité.
Chacune a ses forces : compréhension contextuelle et flexibilité pour les LLMs ; scalabilité et rapidité pour les embeddings.

Pour les données structurées et les sélections exhaustives, les LLM sont inadaptés et les embeddings montrent des limites ; la solution proposée combine ReAct (orchestrateur LLM) + outils déterministes + RAG pour tirer parti des deux approches.

Nous évoquons des développements qui iraient dans le même sens : embeddings avec filtrage, recherche hybride.

LLM-based Retrieval et Embedding-based Retrieval sont deux approches utilisées pour récupérer des informations dans un système de recherche, mais elles diffèrent par leur fonctionnement et leurs applications. Voici une comparaison détaillée :

1. LLM-based Retrieval (Basé sur les Large Language Models)

Principe

  • Les Large Language Models (LLMs), comme OpenAI GPT, MistralAI ou d’autres modèles similaires, sont directement utilisés pour comprendre une requête et récupérer des informations pertinentes.
  • La récupération se fait en s’appuyant sur la capacité du LLM à comprendre le langage naturel et à raisonner sur les données ou documents disponibles.

Méthode

  • Le modèle est "interrogé" avec une requête.
  • Il peut soit :
    • Générer une réponse directement en s’appuyant sur son entraînement (s’il est pré-entraîné sur un large corpus).
    • S’appuyer sur un context augmenter en consultant des bases de connaissances ou des données supplémentaires pertinentes.

Avantages

  • Compréhension contextuelle avancée : LLM peut raisonner sur des requêtes complexes en tenant compte des subtilités linguistiques.
  • Flexible : Peut fournir une réponse directe ou agir comme un intermédiaire intelligent pour filtrer et reformuler des résultats.
  • Peu d’efforts de pré-traitement nécessaires : La requête peut être en langage naturel.

Inconvénients

  • Coût computationnel élevé : L’interrogation d’un LLM nécessite généralement beaucoup de ressources.
  • Risque d’erreurs contextuelles : Si les informations sont absentes ou mal structurées, les LLM peuvent "halluciner" (inventer des réponses).
  • Moins adapté pour des ensembles de données massifs sans techniques d’indexation supplémentaires.

2. Embedding-based Retrieval (Basé sur les embeddings)

Principe

  • Les embeddings sont des représentations vectorielles denses de données (textes, requêtes, documents, etc.).
  • Une récupération basée sur les embeddings repose sur la similarité entre les représentations vectorielles de la requête et des documents.

Méthode

  • Les textes (documents ou requêtes) sont transformés en vecteurs denses à l’aide d’un modèle pré-entraîné (par exemple, Sentence-BERT, OpenAI embeddings, etc.).
  • Une fois les vecteurs générés :
    • La requête est également convertie en vecteur.
    • Une recherche de proximité est effectuée (par exemple, en utilisant la cosine similarity ou une autre métrique) pour trouver les documents les plus pertinents.

Avantages

  • Efficacité sur de grands ensembles de données : Une fois les embeddings générés, les recherches sont rapides grâce à des techniques comme l’approximation de la recherche des plus proches voisins (ANN).
  • Robustesse aux variations linguistiques : Les embeddings capturent les relations sémantiques même si les mots exacts diffèrent.
  • Scalabilité : Bien adapté pour des millions ou milliards de documents.

Inconvénients

  • Nécessite un prétraitement initial : Les documents doivent être convertis en embeddings à l’avance. Cela va dans le sens de la frugalité et, le plus souvent, c’est la norme s’agissant du RAG dans les entreprises.
  • Moins bon pour les requêtes complexes : Peut manquer de compréhension contextuelle avancée comparée à un LLM.
  • Dépend des données d’entraînement du modèle : Si les embeddings ne capturent pas correctement les relations dans un domaine spécifique, la récupération sera sous-optimale.

Résumé des différences

Aspect LLM-based Retrieval Embedding-based Retrieval
Approche principale Récupération basée sur les capacités du LLM à générer ou filtrer des résultats en langage naturel. Basée sur des vecteurs sémantiques pré-calculés.
Compréhension contextuelle Très élevée (grâce à la puissance des LLM). Modérée (limitée aux relations sémantiques capturées).
Efficacité Moins efficace pour les bases de données massives (coût élevé). Très efficace après le calcul initial des embeddings.
Coût Coût computationnel élevé à chaque requête. Coût initial pour le calcul des embeddings, faible coût pour la recherche.
Applications Questions complexes, dialogue, synthèse d’informations. Recherche dans des bases massives de documents.

Cas d’utilisation typiques

  • LLM-based Retrieval : Systèmes de dialogue, assistant virtuel, recherche contextuelle avancée dans des données limitées.
  • Embedding-based Retrieval : Moteurs de recherche, récupération de documents scientifiques, bases de données denses. Les deux approches peuvent être combinées dans un système hybride pour tirer parti des forces de chacune (par exemple, utilisation d’embeddings pour une recherche rapide suivie d’un raisonnement contextuel via un LLM). C’est la base des outils RAG que nous développons : Outils d’IA textuels.

Les limites de la recherche par embeddings

Cet article : Theoretical Limitations of Embedding-Based Retrieval met en avant les limitations de la recherche par embeddings.

On y démontre l’incapacité d’une recherche par embeddings à retrouver 46 documents simples parmi un corpus de 50.000 documents ( noter que la recherche par LLM ne fait pas mieux, c’est d’ailleurs la raison pour laquelle l’article mentionné reste sur une solution par embeddings ) .

On peut observer que les "petits documents" sont des assertions simples telles que "Ellis Smith likes apples." Ces documents du genre "X aime Y", "W n’aime pas Z" etc. sont des assertions qui, d’un point de vue sémantique, ont peu ou pas de chances de partager un contexte commun : elles sont donc très dispersées dans l’espace vectoriel. Une requête par embeddings ne peut les sélectionner en une fois. L’expérience étant confirmée par la théorie, ceci est indiscutable.

Une fois cette démonstration faite, la suite de l’article porte sur une amélioration de la recherche par embeddings en introduisant une indexation multi vectorielle. Nous ne pouvons suivre cette voie qui procède de la recherche, pas de l’ingénierie.

Posons un constat :

  • les "petits documents" ont une forme quasi-formatée, assimilables à des données,
  • l’objectif du test est d’obtenir une sélection exhaustive,
  • le nombre de résultats recherchés dépasse largement le petit nombre de résultats qu’un LLM est capable de traiter en aval de la recherche - on s’accorde généralement sur un nombre de 3 à 10 (le fameux paramètre top-k).

La conclusion est évidente :

La recherche par embeddings n’est pas adaptée à la sélection exhaustive de données structurées.

Cependant, n’oublions pas que : La recherche par embeddings a fait ses preuves dans le domaine de la recherche informelle, notamment pour réaliser des chat bots, des aides en ligne etc .

Quelle solution pour traiter des données structurées ?

Nous sommes guidés par ce principe :

Aux outils les sélections déterministes pour sélectionner des données structurées et en extraire de l’informel. A l’IA le travail d’analyse et de synthèse sur de l’informel.

Notre solution - décrite ici RAG : Chat Engine ReAct avec outils - consiste à :

Construire notre application sur un algorithme ReAct (donc un LLM capable de fonctions) accédant à :

  • des outils de sélection de données métier, structurées ; ces outils sont déterministes et donnent des résultats exhaustifs,
  • un outil RAG, fondé sur la recherche par embeddings, dont le résultat est fourni au LLM pour analyse et synthèse .

En amont, ReAct sélectionnera les outils en fonction de la question. En aval, ReAct fera appel au LLM pour mettre en forme la réponse.

Prenons le cas idéal de la maintenance technique : les données sont à la fois structurées ( identifiants, catégorie, dates etc. ) et peuvent comporter des informations textuelles.

  • Les outils de sélection permettent d’accéder aux données de façon déterministe : les réponses sont exactes et complètes.
  • L’outil RAG sera employé pour synthétiser les informations textuelles contenues dans les réponses (telles que des commentaires, des observations) en effectuant des rapprochements avec les documents métiers (tels que des notices techniques, des prescriptions, des compte-rendus, des historiques etc.) .

Ainsi, des questions de l’utilisateur pourront être :

"Recherche les interventions sur la pompe N-92c et effectue une synthèse des pannes mentionnées"

"Fais moi une synthèse des pannes sur les pompes de la même référence"

Aller plus loin

Hybrid Search

L’article mentionne également la supériorité de l’algorithme BM25. BM25 capte les correspondances exactes et les mots‑clés ; les embeddings captent le sens et les synonymes. Les combiner corrige les faiblesses de chaque méthode. Le concept hybrid search désigne la combinaison d’une recherche lexicale (BM25/keyword) et d’une recherche sémantique (embeddings).

Filtrage par métadonnées

L’hybrid search pourrait être renforcé par filtrage : cela consiste à ne sélectionner que les documents qui respectent des contraintes structurées avant ou après la recherche par embeddings.

• Pré‑filtre : appliquer la contrainte sur une table de métadonnées des documents puis construire la requête dense/BM25 sur ce sous‑ensemble.

• Post‑filtre : exécuter la recherche dense puis éliminer les résultats dont les métadonnées ne correspondent pas (utile si le vector store ne supporte pas de filtre natif).

Il serait idéal de fournir à ReAct un outil de recherche fondé sur ces principes. Il en résulterait non seulement un avantage de précision, mais aussi une économie d’appel au LLM. Time is Energie !