Déployer un retrieval hybride léger avec Quanta

Le problème des piles RAG trop dispersées

Une application RAG commence souvent par un index vectoriel. Puis viennent la recherche plein texte, un graphe de connaissances, un magasin de documents, un cache et parfois plusieurs fournisseurs d’embeddings. Chaque composant apporte une capacité utile, mais aussi une surface de déploiement, une configuration et des modes de panne différents.

Le preprint de Ioannis E. Livieris présente Quanta: A Self-Contained Python Library for Hybrid Retrieval over Quantised Embeddings, Lexical Indexes, and Knowledge Graphs. La bibliothèque réunit une recherche vectorielle dense, une recherche BM25 et une exploration de graphe derrière une API de retrieval unique. L’intérêt pour un hébergement sur VPS ne tient pas à une promesse magique de simplicité : il tient à une séparation claire entre ce qui peut rester dans le processus Python et ce qui doit être fourni par un service réseau.

Le document décrit un système et un déploiement observé. Il ne fournit pas une recette universelle de production. Ce guide explique donc comment lire ses choix d’architecture, comment les transposer prudemment à un petit serveur et quelles vérifications conserver avant de remplacer une pile existante.

Un déploiement en couches

Dans Quanta, un MultiRetriever possède des index vectoriels nommés et expose une entrée asynchrone de recherche. Trois familles de composants peuvent être ajoutées : un index lexical, un graphe et un cache d’embeddings. Le document prévoit des implémentations nulles pour les composants optionnels. Une installation peut donc démarrer avec la recherche vectorielle seule, puis activer d’autres signaux par configuration.

La distinction entre local et réseau est importante pour un VPS. Les index vectoriels quantifiés et l’index plein texte Tantivy résident dans le processus de la bibliothèque. Le magasin de documents, le graphe Neo4j et le cache Redis sont des services réseau dans l’architecture décrite. Le fournisseur d’embeddings reste du côté de l’application consommatrice, et une adaptation LlamaIndex peut piloter le retriever.

Cette organisation réduit le nombre de services nécessaires pour un premier déploiement, sans supprimer les dépendances lorsque le besoin apparaît. Un VPS peut héberger le processus Python et, selon ses ressources, les services complémentaires. Mais il faut conserver une frontière explicite : un index local n’a pas les mêmes garanties de sauvegarde, de réplication ou de montée en charge qu’un service dédié.

La recherche vectorielle quantifiée

Quanta stocke les embeddings sur quatre bits. Le preprint donne un ordre de grandeur : un million de vecteurs de dimension 768 occuperait environ 366 MiB en quatre bits, contre 2,86 GiB en float32. Ce calcul indique pourquoi un index local peut devenir envisageable sur une machine plus petite. Il ne suffit pas à dimensionner un VPS : il faut ajouter le texte, les métadonnées, le processus Python, les connexions réseau, les caches et la marge de sécurité mémoire.

La recherche reste exhaustive sur la représentation quantifiée. Elle est donc exacte relativement aux vecteurs quantifiés, mais sa durée augmente avec la taille du corpus. Cette propriété peut convenir à un corpus modéré et à un service où la simplicité compte davantage qu’une latence minimale. Elle devient moins évidente lorsque le nombre de vecteurs, le nombre de requêtes simultanées ou la dimension augmentent fortement.

Le stockage des identifiants utilise un hash xxHash-64 à graine fixe pour passer des identifiants applicatifs aux adresses de l’index. La bibliothèque rejette une insertion lorsque le hash entre en collision avec un identifiant différent. Une vérification de collision et une stratégie de sauvegarde restent nécessaires autour de cette couche. La quantification réduit l’empreinte, mais elle ne dispense pas de tester le rappel sur les questions réelles.

Filtrage et magasins de documents

Le document décrit deux implémentations de magasin de documents derrière une même interface asynchrone. PostgresDocStore utilise PostgreSQL et un index GIN sur une colonne de métadonnées JSONB. DuckDBDocStore fournit une option embarquée. Ce choix permet d’adapter le stockage à la taille et au niveau d’exploitation disponibles.

Le filtrage n’est pas appliqué comme un simple post-traitement. Quanta résout d’abord le prédicat, obtient les identifiants autorisés, puis limite la recherche vectorielle à cette liste. Le même mécanisme sert à la seconde passe de re-ranking après expansion du graphe. L’avantage conceptuel est important : un filtre sélectif ne réduit pas silencieusement la qualité en récupérant d’abord des voisins puis en jetant ceux qui ne respectent pas la contrainte.

Sur un VPS, cette propriété doit être accompagnée d’un contrôle des index et des requêtes. Un prédicat correctement exprimé peut rester lent si le magasin de documents n’a pas de chemin d’accès adapté. Mesurez séparément le temps de filtrage, le temps de recherche vectorielle et le temps de récupération des documents. Une latence globale acceptable peut cacher un point de saturation qui apparaîtra avec la concurrence.

Fusionner sans comparer des scores incompatibles

Les scores d’une recherche dense, de BM25 et d’une distance de graphe ne vivent pas sur la même échelle. Quanta les combine avec une fusion réciproque par rang pondérée, plutôt que de normaliser les scores bruts. Chaque signal fournit une liste classée ; la position d’un document dans chaque liste contribue à son score final selon un poids et une constante d’amortissement.

Cette décision évite de supposer qu’une similarité cosinus et un score BM25 sont directement comparables. Elle rend aussi les réglages plus lisibles : on ajuste la contribution relative d’un signal au lieu de corriger une normalisation dont le comportement peut varier selon la requête.

La fusion ne garantit pas la pertinence. Un poids mal choisi peut favoriser un signal qui fonctionne bien sur une famille de requêtes et mal sur une autre. Avant de déployer, conservez une ligne de base avec recherche dense seule, puis comparez les variantes avec un jeu de questions annotées. Les scores de fusion doivent rester des indicateurs de classement, pas des probabilités de vérité.

Le graphe comme expansion, pas comme juge

Quanta traite le graphe comme un moyen d’élargir les candidats. Une première passe classe les documents avec les signaux de contenu. Les meilleurs éléments deviennent des graines. Une exploration bornée du graphe ajoute des identifiants voisins, puis les index denses reclassent les nouveaux candidats avec une liste autorisée.

La proximité structurelle détermine donc ce qui peut être considéré ; la similarité de contenu détermine ensuite comment l’élément se classe. Cette séparation empêche une relation proche dans le graphe de dominer automatiquement un document dont le contenu répond mal à la question. Elle limite également le rôle du graphe lorsque l’expansion n’apporte pas de vecteur exploitable.

Dans le cas clinique décrit, trois index denses, un index BM25 et un graphe sont utilisés. Une première recherche produit 18 identifiants. Une exploration à deux sauts depuis trois graines atteint 50 nœuds, dont 41 à 42 nouveaux selon la question. Environ 70 % des nouveaux candidats reçoivent ensuite une similarité lors du re-ranking contraint. Le pool final est multiplié approximativement par 3,3.

Ces nombres caractérisent le déploiement de l’article ; ils ne prédisent pas le comportement d’un autre graphe. Ils montrent néanmoins ce qu’il faut mesurer : taille du pool initial, taille du pool après expansion, nombre de candidats réellement reclassés et coût de chaque passe.

Ce que montre le déploiement observé

Le corpus expérimental est un jeu synthétique de dossiers hospitaliers dans Neo4j. Il contient 100 patients, 30 médecins, 12 diagnostics, 12 procédures, 12 médicaments et 5 hôpitaux. Les index couvrent notamment les résumés de patients, les expertises, les diagnostics, les procédures et les images. Les index sont quantifiés en quatre bits et un magasin DuckDB embarqué est utilisé dans la configuration rapportée.

Pour une question clinique, le dispatcher est le composant qui accède aux données. Il dialogue avec le modèle, Neo4j et les index de recherche. Redis peut conserver l’historique lorsqu’il est configuré. Le retrieval reste en processus ; le point d’accès au modèle, le graphe et le cache franchissent une frontière réseau.

Dans ce déploiement, les recherches denses et denses plus BM25 prennent 7 à 9 millisecondes sur le corpus utilisé. L’expansion du graphe porte la durée observée à 44–115 millisecondes. Les appels d’outils vont de 19 à 984 millisecondes, tandis que les tours complets durent 19 à 32 secondes, principalement à cause de la génération. Ces mesures ne sont pas un benchmark de production : elles décrivent un cas et un matériel qui ne sont pas détaillés comme une matrice de capacité universelle.

Le système répond correctement aux six questions cliniques non vues dans le scénario décrit, avec un modèle ouvert de 27 milliards de paramètres sur un endpoint local. Cette observation est utile pour comprendre la chaîne, mais elle ne remplace ni une évaluation de retrieval contrôlée ni un test de charge.

Installer prudemment sur un VPS

Un premier déploiement peut séparer quatre responsabilités : le processus applicatif, les index locaux, le magasin de documents et les services optionnels. Commencez par mesurer l’empreinte mémoire du corpus réel, puis réservez une marge pour les pics de requêtes et les opérations de maintenance. Un VPS qui tient l’index au repos peut manquer de mémoire lors d’un re-ranking concurrent.

Conservez ensuite une procédure de reconstruction. Les index locaux doivent pouvoir être régénérés à partir d’une source versionnée, les métadonnées doivent être sauvegardées et les identifiants doivent rester stables. Pour PostgreSQL, testez restauration et migrations ; pour DuckDB, vérifiez le verrouillage, les copies et l’accès concurrent adapté à votre usage. Pour Neo4j ou Redis, documentez la persistance et la récupération séparément.

Exposez uniquement l’interface nécessaire. Le modèle ou le frontend ne devrait pas accéder directement à chaque backend si le dispatcher peut appliquer les contrôles de requête, les limites d’expansion et les journaux de provenance. La séparation ne rend pas automatiquement le système sûr, mais elle réduit le nombre de chemins d’accès à surveiller.

Ajoutez des contrôles de qualité avant d’activer le graphe. Comparez les résultats de la recherche dense seule, de la fusion dense-BM25 et de l’expansion structurée. Enregistrez les latences par étape, le nombre de candidats et les documents finalement utilisés. Si l’expansion augmente la durée sans améliorer le rappel sur les questions annotées, désactivez-la pour les routes concernées plutôt que de conserver une complexité invisible.

Limites et statut de la publication

Quanta est présenté comme un système et une bibliothèque open source. Le preprint indique explicitement qu’il ne fournit pas une évaluation de retrieval contrôlée avec jugements de pertinence et baseline complète. Les résultats de latence, le facteur d’expansion et les six questions du cas clinique ne permettent donc pas de conclure à une supériorité générale.

La recherche exhaustive peut devenir un frein sur de grands corpus. La quantification peut modifier le rappel selon le modèle d’embeddings et le domaine. Les services réseau peuvent introduire des pannes, des délais et des besoins de sauvegarde que l’index local ne supprime pas. Enfin, un VPS n’est pas un fournisseur managé : l’équipe reste responsable des mises à jour, des secrets, des accès, des journaux et des plans de restauration.

Cette publication est un preprint ArXiv, pas une validation par les pairs. Elle constitue une base de conception intéressante pour raisonner sur un hébergement léger, à condition de reproduire les mesures sur les données et le trafic visés. La bonne question n’est pas seulement « combien de services puis-je faire tenir sur un VPS ? », mais « quelles preuves de pertinence, de disponibilité et de restauration puis-je vérifier après chaque changement ? »

Checklist de validation

Avant de considérer un déploiement comme prêt, vérifiez les points suivants :

• le corpus, les métadonnées et les identifiants peuvent être reconstruits ;
• la mémoire et la latence sont mesurées avec le trafic attendu ;
• les filtres sont testés sur des requêtes sélectives ;
• la fusion est comparée à une baseline dense seule ;
• l’expansion du graphe est bornée et son coût est observable ;
• la réponse peut retrouver les documents et la version des données utilisés ;
• une panne du graphe, du cache ou du magasin déclenche un comportement explicite ;
• les sauvegardes et restaurations ont été essayées sur une copie ;
• les limites du preprint ne sont pas transformées en garanties commerciales.

Cette checklist ne remplace pas une revue de sécurité ni un test de capacité. Elle fournit plutôt une frontière minimale entre une démonstration technique et un service dont le comportement peut être suivi.

Source

Ioannis E. Livieris, « Quanta: A Self-Contained Python Library for Hybrid Retrieval over Quantised Embeddings, Lexical Indexes, and Knowledge Graphs », ArXiv 2609.18248v1 : résumé et preprint, PDF.