Bases de données vectorielles, plongements et reclassement : trois parties distinctes de la recherche

Les embeddings, les bases de données vectorielles et les rerankers sont trois parties différentes de la recherche d'information. Un modèle d'embedding convertit du texte ou d'autres données en représentations numériques ; une base de données vectorielle ou un index vectoriel stocke et recherche ces représentations pour récupérer des éléments candidats ; un reranker prend un ensemble de candidats plus restreint et le réordonne à l'aide d'un modèle de pertinence ou d'une méthode de scoring plus coûteuse. Ils apparaissent souvent ensemble dans le RAG, mais aucun d'entre eux n'est identique au RAG, et aucun n'est obligatoire dans tous les systèmes de recherche d'information.

Ce que cela signifie vraiment

Les systèmes de recherche ont deux objectifs concurrents : trouver suffisamment de matériel potentiellement pertinent et placer le meilleur matériel près du sommet. La récupération rapide de premier stade optimise généralement la génération de candidats. Un modèle de second stade plus puissant peut ensuite consacrer plus de calcul à distinguer les meilleurs candidats.

Les embeddings, les index vectoriels et les rerankers occupent différentes positions dans ce processus. Les traiter comme une seule fonctionnalité masque des choix de conception importants concernant le rappel, la précision, la latence, le stockage, le filtrage des métadonnées et le coût du modèle.

La distinction évite également une erreur courante du RAG : supposer que stocker des embeddings de documents dans une base de données vectorielle crée automatiquement une recherche de haute qualité. La qualité de la recherche dépend du modèle d'embedding, du découpage, des métadonnées, de la construction de la requête, de la configuration de l'index, du nombre de candidats, de la recherche hybride, du reranking et de l'autorité des sources sous-jacentes.

L'exemple le plus simple

Supposons qu'une base de connaissances contienne 100 000 segments de documents. Un utilisateur demande : « Comment révoquer un jeton d'API ? »

D'abord, un modèle d'embedding peut encoder la requête en un vecteur. Les segments de documents peuvent déjà avoir leurs propres embeddings stockés. Une recherche vectorielle compare ensuite le vecteur de requête aux vecteurs de documents indexés et renvoie, par exemple, 30 candidats probables.

Ces 30 candidats peuvent ensuite être transmis à un reranker. Le reranker compare la requête plus directement à chaque candidat et produit un nouvel ordre de pertinence. L'application peut conserver les cinq meilleurs pour le contexte du modèle.

Où l'exemple simple s'arrête

Les systèmes de recherche réels ne sont pas obligés d'utiliser des embeddings denses. La recherche par mots-clés telle que BM25 peut être le récupérateur de premier stade. La récupération apprise creuse, les filtres SQL, le parcours de graphe ou les API applicatives peuvent également générer des candidats.

Un reranker ne se soucie pas non plus que les candidats proviennent d'une base de données vectorielle. Il peut reranker des résultats BM25, des résultats hybrides, des documents sélectionnés manuellement ou des candidats provenant de plusieurs récupérateurs.

De même, les embeddings ne nécessitent pas de base de données vectorielle spécialisée. Les petits jeux de données peuvent être comparés en mémoire ou avec des bases de données généralistes et des extensions vectorielles. Les systèmes vectoriels spécialisés deviennent utiles lorsque l'indexation, la recherche approximative des plus proches voisins, le filtrage, l'échelle, le comportement de mise à jour ou les exigences opérationnelles les justifient.

Embeddings : représentation, pas récupération

Un embedding est une représentation numérique produite par un modèle. Pour la récupération sémantique, les textes ayant une signification liée sont censés occuper des positions utiles dans un espace vectoriel afin qu'une fonction de similarité ou de distance puisse les comparer.

Sentence-BERT a été une étape influente pour rendre la similarité sémantique au niveau des phrases pratique avec des représentations de style bi-encodeur qui peuvent être calculées indépendamment et comparées efficacement. L'idée générale reste centrale pour la récupération dense moderne : précalculer les représentations des documents, calculer la représentation de la requête au moment de la recherche, puis les comparer.

L'embedding lui-même ne recherche pas dans un corpus. C'est une donnée produite par un modèle d'embedding. La récupération commence lorsque le système compare la représentation de la requête aux candidats stockés.

Le modèle d'embedding définit l'espace de représentation

Les vecteurs de documents et de requêtes doivent être compatibles avec le modèle et la configuration utilisés pour les créer. Remplacer un modèle d'embedding peut modifier la dimensionnalité, le comportement de similarité, la couverture linguistique et les performances du domaine.

C'est pourquoi une migration de modèle d'embedding n'est pas simplement un changement de nom d'API. Les documents existants peuvent devoir être ré-embeddés et l'index reconstruit ou versionné.

Les représentations denses et creuses sont différentes

Les embeddings denses contiennent généralement de nombreuses dimensions non nulles et sont couramment utilisés pour la similarité sémantique. Les représentations creuses contiennent de nombreux zéros et peuvent préserver une structure plus forte de type token ou terme.

Les deux peuvent prendre en charge la récupération sémantique, et les systèmes de recherche modernes peuvent combiner des signaux denses, creux et lexicaux. « Recherche vectorielle » ne signifie donc pas toujours un seul pipeline de similarité cosinus dense.

Les fonctions de similarité font partie du contrat de représentation

La similarité cosinus, le produit scalaire et la distance euclidienne ne signifient pas la même chose. La métrique correcte dépend de la façon dont le modèle d'embedding a été entraîné et normalisé.

La documentation actuelle de Qdrant, par exemple, exige une métrique de distance dans le cadre de la configuration vectorielle et documente les choix de type cosinus, produit scalaire et euclidien. La règle architecturale importante est de traiter la métrique comme faisant partie du contrat d'embedding/index plutôt que d'en choisir une arbitrairement.

Bases de données vectorielles et index : récupération de candidats

Une base de données vectorielle ou un système de recherche compatible avec les vecteurs organise les représentations vectorielles afin que l'application puisse récupérer efficacement les candidats proches. Les systèmes pratiques associent généralement les vecteurs à des identifiants et à des métadonnées de charge utile telles que la source, la langue, le locataire, le type de document, l'horodatage ou la portée d'accès.

Qdrant, par exemple, organise les données en collections de points où un point contient un vecteur et des métadonnées de charge utile facultatives. Sa documentation décrit la recherche de similarité basée sur HNSW et le filtrage des métadonnées comme des capacités distinctes de la couche de récupération.

Cette distinction est importante : l'index vectoriel répond à un problème de plus proche voisin, tandis que les filtres de charge utile imposent des contraintes structurelles telles que le locataire, la classe de document ou la langue.

La recherche approximative du plus proche voisin échange l'exactitude contre l'efficacité

Comparer un vecteur de requête à chaque vecteur peut être pratique pour de petites collections mais coûteux à grande échelle. Les index approximatifs du plus proche voisin tels que HNSW réduisent le coût de recherche en naviguant dans une structure d'index au lieu de scanner exhaustivement chaque vecteur.

La recherche approximative introduit un compromis rappel/latence. Une recherche plus rapide peut manquer des candidats que la recherche exacte renverrait. Les paramètres d'index affectent donc la qualité de la récupération, pas seulement les performances de l'infrastructure.

Qdrant expose à la fois les paramètres liés à HNSW et une option de recherche exacte, illustrant que le stockage vectoriel et la politique de récupération approximative sont des décisions distinctes.

Le filtrage des métadonnées intervient avant ou pendant la récupération des candidats

Si l'utilisateur ne peut accéder qu'au locataire A, récupérer des segments sémantiquement similaires du locataire B et tenter de les supprimer plus tard est une mauvaise frontière de sécurité. L'autorisation et les filtres d'éligibilité stricts doivent contraindre l'espace des candidats avant que ces candidats puissent influencer le traitement en aval.

Le même principe s'applique à la locale, au statut du document, à la classe de source, à la date, à la version du produit et à d'autres contraintes déterministes. La similarité doit classer les candidats éligibles ; elle ne doit pas outrepasser l'éligibilité.

Une base de données vectorielle est facultative

Pour un petit corpus, une comparaison cosinus par force brute peut être simple et suffisante. Une base de données relationnelle avec support vectoriel peut également convenir. Une base de données vectorielle dédiée devient précieuse lorsque son indexation, son filtrage, son stockage distribué, son comportement de mise à jour ou ses fonctionnalités opérationnelles répondent à un besoin réel.

Choisir une base de données vectorielle parce que « le RAG en a besoin » inverse le processus d'architecture. Commencez par les exigences de récupération et l'échelle, puis sélectionnez la technologie de stockage/index.

Reclassement : affinement de la pertinence en deuxième étape

Un reclassificateur reçoit une requête et un ensemble plus restreint de candidats déjà récupérés, puis attribue des scores de pertinence plus forts ou un nouvel ordre. Il est normalement plus coûteux en calcul que la récupération de première étape, c'est pourquoi il est appliqué après la génération de candidats plutôt qu'à l'ensemble du corpus.

Les recommandations actuelles d'Elastic décrivent le reclassement sémantique comme une technique de dernière étape sur un petit ensemble top-k et notent qu'il peut affiner la récupération lexicale, sémantique ou hybride. Cohere documente la même architecture : recherche lexicale ou sémantique de première étape suivie d'une étape de reclassement.

Une implémentation courante utilise un modèle de type cross-encoder qui examine la requête et chaque candidat ensemble. Cette interaction plus riche peut distinguer la pertinence plus précisément que la similarité d'embedding indépendante, mais elle est beaucoup plus coûteuse à l'échelle du corpus.

La récupération par bi-encodeur et le reclassement par cross-encodeur résolvent des problèmes de coût différents

Un reclassificateur ne peut pas récupérer ce que la récupération a manqué

Si le document pertinent est absent de l'ensemble de candidats, le reranking n'a rien à promouvoir. C'est la raison centrale pour évaluer la recherche et le reranking séparément.

Un pipeline peut avoir une excellente précision de reranker et échouer malgré tout parce que le rappel de la première étape est faible. Augmenter la qualité du reranker ne réparera pas une couverture source manquante, un mauvais découpage, des filtres restrictifs ou un retriever de candidats faible.

La recherche hybride est un choix de conception distinct

La recherche sémantique dense est performante lorsque la requête et le document utilisent des formulations différentes mais expriment un sens apparenté. La recherche lexicale est performante lorsque des termes exacts, des identifiants, des noms, des codes ou des expressions rares importent.

La recherche hybride combine plusieurs signaux candidats, souvent BM25 lexical et similarité vectorielle, puis fusionne les classements à l'aide d'une méthode telle que la Reciprocal Rank Fusion ou une combinaison pondérée de scores.

Le reranking peut alors opérer sur l'ensemble de candidats fusionné. La recherche hybride et le reranking sont donc des étapes complémentaires mais distinctes.

BM25 n'est pas obsolète parce que les embeddings existent

La recherche par mots-clés peut surpasser la recherche dense pour des identifiants exacts, des numéros de version, des messages d'erreur, des codes produit et un vocabulaire spécialisé. SQLite FTS5, par exemple, inclut une fonction de classement BM25 pour la recherche en texte intégral.

Une architecture de recherche solide peut utiliser la recherche lexicale comme seule première étape, la recherche vectorielle comme seule première étape, ou combiner les deux selon le corpus et la distribution des requêtes.

Le découpage modifie ce que les embeddings et les rerankers peuvent voir

Si un document est mal découpé, aucun composant de recherche ultérieur ne peut reconstruire entièrement l'unité sémantique manquante. Un chunk qui sépare une condition de son exception peut produire un embedding trompeur et peut aussi être mal reranké parce que le texte candidat est incomplet.

La taille des chunks, le chevauchement, les frontières structurelles et les métadonnées affectent donc à la fois le rappel des candidats et le jugement du reranker. L'évaluation de la recherche doit tester l'ensemble du pipeline, de l'ingestion au classement, et pas seulement le modèle d'embedding.

Ne comparez pas les scores de recherche comme s'il s'agissait de probabilités universelles

La similarité cosinus, les scores BM25, les scores de vecteurs creux, les rangs RRF et les scores de reranker ont des significations différentes. Un score de 0,82 provenant d'un modèle d'embedding n'est pas automatiquement comparable à 0,82 provenant d'un autre modèle ni à un score de reranker.

Les seuils doivent être calibrés pour le modèle, le corpus et la tâche réels. Les recommandations actuelles d'Elastic notent également que les scores de similarité d'embedding peuvent dépendre de la requête, ce qui rend les seuils universels risqués.

Évaluer les étapes de recherche séparément

Cette séparation est opérationnellement importante. Si Recall@50 est faible, le reranker n'est pas le premier composant à corriger. Si Recall@50 est élevé mais que le meilleur passage reste au rang 38, le reranking ou la fusion de classements devient une cible plausible.

Quelle couche a réellement échoué ?

Pertinence et Source de Vérité sont différentes

Un reranker peut faire paraître un document obsolète extrêmement pertinent. Un index vectoriel peut récupérer un résumé secondaire qui est sémantiquement plus proche que la source primaire. La qualité de la récupération ne peut donc pas remplacer les règles d'autorité.

Là où l'autorité de la source importe, les filtres de métadonnées, les classes de sources, les règles de version et la provenance devraient contraindre la récupération avant que le résultat ne devienne un contexte de modèle.

Preuves d'implémentation originales

Moteur de Recherche de Source de Vérité : la récupération lexicale et sémantique sont séparées

Le Moteur de Recherche de Source de Vérité contient un chemin de récupération lexicale local utilisant SQLite FTS5/BM25 et un chemin de récupération sémantique optionnel séparé utilisant des embeddings générés localement.

Son implémentation de recherche sémantique calcule un vecteur de requête et le compare avec les vecteurs de chunks stockés en utilisant la similarité cosinus. Le projet traite délibérément la similarité sémantique comme un signal de découverte plutôt que comme une preuve : un candidat doit encore être retracé jusqu'à une source et un localisateur concrets avant de pouvoir soutenir une affirmation.

C'est une preuve d'implémentation utile pour R01 car le même corpus peut soutenir le classement lexical et la similarité vectorielle sans confondre l'un ou l'autre mécanisme avec l'autorité probante.

Client IA Aaasaasa : Qdrant est un composant d'infrastructure vectorielle

Le Client IA Aaasaasa inclut l'infrastructure Qdrant/vectorielle comme une ressource locale séparée. L'architecture Electron expose les services Qdrant depuis le côté processus principal de confiance plutôt que de traiter la recherche vectorielle comme faisant partie du modèle lui-même.

Le dépôt contient un adaptateur client Qdrant, une configuration de service Qdrant et une infrastructure Qdrant basée sur Docker. Cela démontre la séparation architecturale entre l'exécution du fournisseur/modèle IA et le stockage/recherche vectorielle.

L'existence du support Qdrant ne doit pas être surestimée comme un pipeline RAG de production complet. La preuve ici est plus étroite : l'infrastructure vectorielle est implémentée comme sa propre frontière de composant.

Quand avez-vous besoin de chaque composant ?

Une séquence pratique de conception de la récupération

Idées fausses courantes

Cas limites et limitations

Certaines applications n'ont pas besoin de recherche sémantique. Une recherche exacte en base de données ou du SQL structuré peut être plus correct, plus rapide et plus facile à auditer que la récupération par embeddings.

Certains corpus sont si petits qu'un balayage vectoriel complet est acceptable. L'indexation approximative ajoute de la complexité sans bénéfice significatif.

Certaines requêtes nécessitent un rappel élevé avant toute optimisation de précision. La découverte juridique, la recherche et l'examen de conformité peuvent préférer une récupération large de candidats suivie d'un filtrage transparent et d'une revue humaine.

La récupération multilingue et spécifique à un domaine peut se comporter très différemment selon les modèles d'embedding. Les affirmations de performance issues de jeux de données publics ne doivent pas être considérées comme une preuve pour un corpus privé.

La latence du reranking augmente avec le nombre et la longueur des candidats. La taille des candidats doit donc être ajustée comme une variable de précision/coût/latence plutôt que copiée d'un tutoriel.

Qu'est-ce qui changerait cette réponse ?

Les frontières entre composants ne changeraient pas si un fournisseur regroupait la génération d'embeddings, l'indexation vectorielle et le reranking derrière une seule API. Le produit peut masquer les étapes, mais elles restent conceptuellement des responsabilités différentes avec des modes de défaillance différents.

De futurs modèles d'embedding ou de récupération pourraient réduire le besoin d'un reranking séparé dans certaines charges de travail, tandis que des méthodes plus fortes d'interaction tardive ou d'apprentissage creux peuvent brouiller les catégories traditionnelles dense/lexicale. L'architecture devrait toujours se demander quelle étape produit les représentations, quelle étape génère les candidats et quelle étape affine le classement.

La meilleure conception change aussi avec la taille du corpus, le mélange de requêtes, la langue, la terminologie du domaine, la fréquence de mise à jour, l'autorité des sources, le budget de latence et les résultats d'évaluation.

Connaissances canoniques associées

R01 suppose que le concept de base du RAG est déjà compris. Le RAG est le modèle plus large dans lequel des informations externes récupérées sont fournies à un modèle ; les embeddings, la recherche vectorielle et le reranking sont des composants de récupération optionnels à l'intérieur de ce modèle.

Lorsque la recherche échoue, diagnostiquez séparément la couverture des sources, la recherche, le classement, l'assemblage du contexte et la génération plutôt que de traiter l'ensemble du système comme un seul « échec du RAG ».

L'architecture de source de vérité est la couche d'autorité autour de la recherche : elle décide quelle source peut établir une affirmation, tandis que les embeddings et le classement décident seulement quels candidats semblent pertinents.

Questions fréquentes

Glossaire

Conclusion

Le modèle de recherche clair est simple : les embeddings représentent le sens, la recherche vectorielle récupère les candidats, et les reclassificateurs affinent l'ordre des candidats.

Une fois ces frontières explicites, les décisions d'architecture deviennent plus faciles à diagnostiquer. Les candidats manquants pointent vers la couverture des sources, le découpage, les embeddings, les filtres ou la recherche de premier étage. Un mauvais ordonnancement pointe vers le classement, la fusion ou le reclassement. Les réponses finales incorrectes peuvent alors être étudiées séparément au niveau du contexte et de la génération.

Le résultat le plus important n'est pas de choisir le composant de recherche le plus à la mode. C'est de construire un pipeline de recherche dont les étapes, les frontières d'autorité, les métriques et les modes de défaillance peuvent être mesurés indépendamment.

Sources primaires et preuves de mise en œuvre

Les références externes ci-dessous documentent les mécanismes de représentation, de recherche vectorielle et de reclassement utilisés dans cet article. Les sections spécifiques au projet sont des preuves de mise en œuvre originales et sont intentionnellement plus étroites que des affirmations sur la maturité complète d'un RAG en production.