Infrastructure de récupération et magasins vectoriels

Un prototype de recherche vectorielle et un système de production qui tient sous un volume de requêtes réel sont deux problèmes d'ingénierie distincts. Nous construisons et exploitons la couche d'infrastructure de récupération qui sous-tend votre pipeline RAG, vos workflows agentiques ou votre produit de recherche sémantique — le moteur vectoriel, le pipeline d'embeddings qui l'alimente, la gestion du cycle de vie des index qui le maintient sain, et la pile d'observabilité qui détecte la dégradation de la qualité avant que les utilisateurs ne s'en aperçoivent.

Nous sommes neutres vis-à-vis du moteur. Notre pratique est agnostique quant au moteur, couvrant Qdrant, Milvus, Weaviate, pgvector et Elasticsearch kNN, et celui que nous recommandons dépend de votre nombre de vecteurs, de vos schémas de requêtes, de vos exigences de multi-tenancy et de votre capacité opérationnelle.

D'une démo à 50 K vecteurs à une production à 200 M de vecteurs

L'écart entre une démo et un système de production est presque entièrement un problème d'infrastructure. La démo charge 50 K vecteurs dans Pinecone, exécute une requête de similarité cosinus et renvoie des résultats en 40 ms. La production ne ressemble en rien à cela.

• 200 M de vecteurs et 500 requêtes par seconde soutenues
• 15 dimensions de filtres de métadonnées et des documents mis à jour toutes les heures
• Trois équipes partageant un même cluster sous une stricte isolation des locataires

À cette échelle, les pics de compaction HNSW font exploser votre P99 à 800 ms, le rappel se dégrade silencieusement après une semaine de mises à jour incrémentielles, et le pipeline d'embeddings ne parvient pas à suivre votre rythme de modification des documents. C'est là que nous intervenons.

Le choix du moteur est un exercice de benchmarking, pas une décision de marque

Chaque fournisseur revendique des performances de premier ordre ; les benchmarks racontent une histoire plus nuancée. Nous ne choisissons pas une base de données à partir d'une matrice de fonctionnalités — nous chargeons vos vecteurs réels, exécutons vos requêtes réelles avec vos filtres de métadonnées réels, et mesurons le rappel à des valeurs de k pertinentes sur le plan opérationnel, aux côtés des latences P50/P95/P99 sous charge concurrente.

Les résultats contredisent régulièrement le marketing des fournisseurs. Le niveau serverless de Pinecone paraît économique jusqu'à ce que des charges soutenues à haut QPS poussent les coûts d'unités de lecture au-delà du seuil de rentabilité de l'auto-hébergement, et pgvector paraît limité jusqu'à ce que les scans itératifs comblent l'écart de la recherche filtrée.

Le pipeline d'embeddings est l'endroit où la récupération en production casse réellement

Les équipes consacrent 60 % de leur effort d'ingénierie de recherche vectorielle au pipeline, pas au magasin de données. Le pipeline gère l'ingestion des documents, le découpage, l'inférence du modèle d'embeddings, la ré-indexation incrémentielle lors des mises à jour de documents, et la propagation des métadonnées — et chaque étape a des modes de défaillance qui dégradent silencieusement la qualité de la récupération.

• Connaissances obsolètes — la deuxième défaillance la plus courante des RAG en production. Un document est mis à jour dans Confluence mais l'index dessert toujours l'ancien embedding. La solution passe par des déclencheurs de capture des changements de données qui réintègrent les embeddings de manière incrémentielle, et non par une ré-indexation par lots nocturne.
• Documents fantômes — un document source est supprimé mais son vecteur demeure, renvoyant des résultats pour un contenu qui n'existe plus. Comme les transactions atomiques entre un système source de vérité et un magasin vectoriel sont quasi impossibles dans les architectures scindées, nous construisons des couches de réconciliation qui détectent et purgent les vecteurs orphelins.

Le choix du modèle d'embeddings compte plus que la plupart des équipes ne le réalisent, et en changer plus tard coûte cher : ré-intégrer les embeddings de 8 M de documents lorsque vous passez de text-embedding-ada-002 à text-embedding-3-large coûte des jours de calcul et nécessite une infrastructure de double écriture pour éviter les interruptions. Nous évaluons les modèles par rapport à votre jeu de requêtes propre à votre domaine avant que vous ne vous engagiez.

• Cohere embed-v4 — domine la récupération multilingue à 0,01 $ par million de tokens dans plus de 100 langues.
• Nomic Embed v2 — 137 M de paramètres, s'exécute sur CPU, avec le meilleur rapport qualité-taille du marché.
• OpenAI text-embedding-3-large — un excellent polyvalent.

Le bon choix dépend de votre combinaison linguistique, de vos exigences de latence, et selon que vous pouvez accepter une dépendance à une API ou avez besoin d'une inférence sur site.

Cycle de vie des index : le problème opérationnel dont personne ne vous prévient

Les index HNSW se dégradent — ce n'est pas un bug, mais une réalité architecturale. À 160 M de vecteurs, une reconstruction HNSW complète prend 3 à 6 heures. Les mises à jour incrémentielles rendent la structure du graphe sous-optimale et érodent le rappel au fil du temps ; les événements de compaction font grimper la latence des requêtes ; et chaque upsert, suppression et fusion de segments déclenche des reconstructions de sous-index qui consomment du CPU en maintenance au lieu de servir les requêtes. Le compromis est inévitable : passer d'un rappel de 0,8 à 0,95 augmente la latence HNSW d'environ 31 %.

Nous concevons une gestion du cycle de vie qui absorbe une ingestion continue sans perte de qualité :

• Rotation d'index bleu-vert — reconstruire sur une infrastructure séparée et basculer de manière atomique sans aucune interruption.
• Portes de validation automatisée du rappel — comparer un jeu de requêtes de référence à l'index courant après chaque opération majeure ; si le rappel passe sous le seuil, le basculement n'a pas lieu.
• La construction HNSW accélérée par GPU dans Qdrant et Elasticsearch réduit les temps de reconstruction d'un ordre de grandeur, bien que l'orchestration du moment de reconstruire, de la manière de valider et de basculer relève d'une ingénierie sur mesure.

La quantification va plus loin encore. Qdrant propose désormais une quantification en 1,5 bit, 2 bits et asymétrique , et Elasticsearch BBQ réduit le tas de plus de 95 % par rapport au float32. Cela économise de la mémoire et améliore le débit, mais chaque schéma présente un profil de rappel différent selon les distributions de données — nous caractérisons donc l'impact sur le rappel de vos vecteurs spécifiques avant de déployer la quantification en production.

Multi-tenancy et isolation à l'échelle réelle

Les équipes de plateforme desservant plus de 200 équipes ML internes, ou les produits SaaS avec des milliers de locataires clients, ont besoin d'une infrastructure qui garantit l'isolation : les requêtes du locataire A ne doivent jamais renvoyer les données du locataire B, les journaux d'audit doivent tracer chaque requête jusqu'à une identité de locataire, et les locataires froids ne devraient pas consommer les ressources dont les locataires chauds ont besoin.

• Weaviate — le modèle d'un shard par locataire avec des états de locataire (ACTIVE, INACTIVE, OFFLOADED vers S3) est l'implémentation la plus mature pour les déploiements à fort nombre de locataires.
• Milvus — prend en charge l'isolation au niveau de la base de données, de la collection, de la partition ou de la clé de partition, adaptant la granularité à vos exigences de conformité.

Les deux nécessitent une orchestration sur mesure à l'échelle — le provisionnement des locataires, les transitions d'état, la gestion des quotas et la détection des fuites inter-locataires ne sont pas pris en charge par la base de données elle-même. Nous construisons la couche opérationnelle qui rend la multi-tenancy gérable pour les déploiements réglementés exigeant la conformité SOC 2 ou ISO 27001 .

Les workflows agentiques remodèlent les exigences d'infrastructure

La vague de l'IA agentique change ce que les magasins vectoriels doivent faire. Le RAG statique récupère des documents dans un corpus fixe. Les workflows agentiques nécessitent une mémoire épisodique (historique de conversation et raisonnement intermédiaire), une recherche sémantique sur un grand corpus de documents, et des couches de profil utilisateur — sollicitant souvent les trois en une seule étape d'agent. L'exigence de latence inférieure à 400 ms est plus stricte que celle du RAG par lots, et la prise en charge des transactions ACID devient essentielle pour les agents multi-étapes qui mettent à jour l'état sans écritures partielles.

Aucune base de données vectorielle ne gère bien à elle seule les trois couches de mémoire, alors les équipes assemblent des architectures multi-magasins : Redis pour l'état de session, Qdrant ou Milvus pour la recherche sémantique, et une base de données de graphes pour le suivi des relations. L'Unified Memory Core d'Oracle (mars 2026) cherche à faire converger les requêtes vectorielles, JSON, de graphe, relationnelles et spatiales dans un seul moteur. Nous concevons la couche de récupération pour les systèmes agentiques — quels magasins gèrent quels types de mémoire, comment les requêtes sont routées entre les magasins, et comment la cohérence tient lorsqu'un agent met à jour l'état sur plusieurs backends en une seule étape de raisonnement.

Ce que nous livrons

Chaque mission commence par une phase de benchmarking : nous chargeons vos vecteurs, exécutons vos requêtes et produisons des recommandations de moteur quantifiées. À partir de là, nous construisons l'infrastructure de production :

• Le cluster de magasin vectoriel, avec planification de capacité et guides opérationnels de mise à l'échelle.
• Le pipeline d'embeddings, avec ré-indexation incrémentielle déclenchée par CDC et gestion des versions de modèles.
• L' automatisation du cycle de vie des index, avec rotation bleu-vert et portes de validation du rappel.
• La couche d'orchestration de la multi-tenancy, lorsque vous avez besoin d'une isolation des locataires.
• La pile d'observabilité, avec détection de dérive, alertes de régression du rappel et surveillance de la latence P95/P99.
• Outillage de migration pour les équipes passant d'un moteur à un autre, utilisant des formats Parquet intermédiaires afin de préserver les embeddings lorsque la dimensionnalité correspond plutôt que de forcer une ré-intégration complète.

Nous cadrons chaque mission avec des projections mensuelles explicites de coûts d'infrastructure, afin que vous sachiez ce que coûtera la production avant de vous engager.