Découvrez une approche hybride de la récupération d’informations combinant recherche vectorielle et requêtes déterministes pour garantir une précision absolue sur les données structurées.
Introduction
La génération augmentée par récupération (RAG) est devenue le modèle par défaut pour interagir avec la documentation d’entreprise via les grands modèles de langage (LLM). La plupart des exemples publics se concentrent sur les documents non structurés (PDF, HTML, Markdown) — domaines où les embeddings et la recherche par similarité vectorielle excellent.
Mais dès qu’on travaille avec des données hautement structurées comme des tableaux Excel ou CSV, ce modèle standard montre ses limites :
- Effondrement sémantique : des lignes adjacentes ne diffèrent que par de minuscules variations lexicales.
- Saturation des embeddings : la recherche par plus proche voisin (distance cosinus) renvoie « presque la même » ligne, mais pas forcément l’exacte même.
- Flou des nombres dans l’espace d’embedding : pour le modèle, « 120 mm » et « 130 mm » peuvent sembler quasiment identiques, donc les requêtes qui dépendent d’un diamètre exact risquent de pointer la mauvaise ligne.
Dans des environnements soumis à des contraintes de conformité (tuyauterie chimique, appariement de pièces aérospatiales, dosages médicaux…), « presque correct » équivaut à totalement faux. Cet article propose et évalue une pile de récupération hybride, qui associe un stockage classique NoSQL à un détecteur d’intention léger basé sur un LLM, en déléguant les requêtes Excel à des recherches déterministes tout en conservant le RAG pour les contenus véritablement non structurés.
Pourquoi le « tout-vectoriel » échoue sur les tableaux répétitifs
Prenons la matrice de compatibilité miniature suivante (en format CSV pour plus de clarté) :
Pipe-A | Pipe-B |
100 mm | 100 mm |
100 mm | 120 mm |
100 mm | 130 mm |
120 mm | 120 mm |
120 mm | 130 mm |
La stratégie « une phrase par ligne » convertit chaque ligne en un morceau de langage naturel, par exemple pour la deuxième ligne :
« Un Pipe-A de 100 mm de diamètre est compatible avec un Pipe-B de 120 mm de diamètre. »
Si vous injectez ces cinq phrases dans un modèle d’embedding (par ex. text-embedding-3-large ou multilingual-e5-large), vous obtenez cinq vecteurs différant principalement sur deux positions de tokens. En pratique, les embeddings sont à plus de 95 % similaires, si bien que le modèle est incapable de distinguer une ligne d’une autre.
Un top-k retrieval (k = 3) typique ne garantit donc pas que la ligne numériquement exacte apparaisse : l’appariement erroné « 130 mm » peut arriver en tête simplement à cause d’arrondis ou de représentations flottantes des sous-tokens.
Un affinage des embeddings sur des paraphrases numériques synthétiques aide un peu, mais le rapport coût/bénéfice est peu intéressant lorsque :
- le tableau est très petit (quelques centaines de lignes) ;
- la précision numérique est obligatoire ;
- la latence doit rester sous 100 ms.
Le modèle de récupération hybride
Un pipeline RAG classique comporte trois étapes :
- Embedding : tous les fragments de texte (paragraphes PDF, blocs HTML, lignes de tableau) sont transformés en vecteurs denses.
- Recherche par similarité : la question de l’utilisateur est encodée et la recherche vectorielle récupère les vecteurs « les plus proches ».
- Génération : le contenu récupéré est injecté dans le LLM avec la question pour produire une réponse.
Cela fonctionne à merveille pour de la prose, mais échoue sur la précision millimétrique des tableaux techniques.
Le modèle hybride répartit les responsabilités au lieu de forcer tous les types de données à passer par la même porte vectorielle :
- Stockage des données tabulaires
Les informations des fichiers tabulaires sont stockées dans des bases de données structurées. Dans notre cas, le volume étant faible (quelques centaines de lignes), nous avons opté pour un cache Redis : les données sont chargées en mémoire, ce qui facilite l’accès et réduit la latence au minimum. - Extraction d’intention et de paramètres
À l’aide de petits LLM + prompt système (few-shot), cette couche extrait l’intention de l’utilisateur et les paramètres associés (slots) : l’utilisateur demande-t-il « Est-ce que X et Y sont compatibles ? » et si oui, quelles sont les valeurs ? - Recherche déterministe
Si les slots sont présents, nous récupérons les données exactes dans la base et convertissons la ligne canonique en phrase(s) lisible(s), à fusionner avec le contexte RAG classique.
(Nous n’abordons pas ici certains cas particuliers, comme la réponse « inconnu » si la paire de compatibilité n’est pas trouvée, pour rester concis.)
Principaux choix techniques
- Mémoire prioritaire : Redis met en cache toute la feuille (<1 Mo) en RAM, réduisant la latence (latence médiane ~1 ms dans la même région Azure).
- Inférence sans état : le LLM d’intention est appelé uniquement pour extraire l’intention et les slots. Léger et peu coûteux (<200 tokens en entrée). Un prompt few-shot tient en moins de 200 tokens ; utiliser un modèle léger comme gpt-3.5-turbo limite le coût à <0,0004 $ par appel.
- Aucune modification du pipeline RAG : la récupération documentaire (recherche vectorielle sur les PDFs) reste inchangée. La phrase de compatibilité des tuyaux est injectée dans le prompt système/contexte, réduisant le risque d’hallucination. Si la BDD est indisponible, le chatbot bascule vers « je ne suis pas sûr, voici ce que disent les manuels… » via le RAG. Pas de point de défaillance unique pour le reste de la base de connaissances.
Avantages
- Aucune hallucination sur les faits tabulaires : la vérité numérique est récupérée, pas déduite.
- Explicabilité : on peut enregistrer la ligne exacte ayant servi à formuler la réponse.
- Séparation des préoccupations : la chaîne principale RAG reste centrée sur le langage ; les données structurées vivent ailleurs.
- Elasticité / modularité : remplacer Redis par Cosmos DB ou DynamoDB est trivial pour des feuilles plus grandes.
Conclusion
La recherche vectorielle est imbattable pour le rappel sémantique flou, mais elle s’affaiblit dès que des correspondances numériques exactes sont nécessaires pour établir la vérité.
En introduisant une fine couche qui détecte l’intention, extrait les valeurs numériques, interroge un magasin clé-valeur en mémoire, et réinjecte le fait déterministe dans le prompt RAG, on obtient le meilleur des deux mondes : précision déterministe pour les données structurées et raisonnement génératif riche pour la prose.
La surcharge d’ingénierie est minimale, le coût d’exécution négligeable, et le gain — zéro hallucination sur des spécifications critiques — est substantiel.
