S4 Embed
Passerelle FinOps pour recherche vectorielle
Une couche FinOps qui réduit le coût de votre base de données vectorielle existante tout en maintenant le rappel cible. Elle quantifie les embeddings (binary + int8) et exécute une recherche en deux étapes (étape grossière Hamming 1-bit + rescore exact) devant OpenSearch, pgvector, Qdrant ou Milvus, réduisant jusqu’à 32× le graphe ANN en RAM. Fonctionne comme une AMI Amazon Linux 2023 dans votre propre VPC, facturée à l’unité d’usage (textes embedded, documents indexés, recherches servies).
S4 Embed vous aide à trouver et exploiter une configuration de recherche vectorielle à faible coût qui respecte votre objectif de rappel. Sur un benchmark de 30k vecteurs, binary Hamming + float rescore a atteint un recall@10 de 0.976–1.000 selon le store et l’over-fetch — vous choisissez le point de fonctionnement. Les outils FinOps sont le produit : s4embed prove (estimer la frontière rappel/coût/latence), compare (mesurer le rappel live entre stores), tune (émettre une config déployable respectant un budget rappel + latence + RAM), un mode shadow de passerelle (dual-write et shadow-compare avant cutover) et drift (surveiller la dérive des embeddings). Indépendant du store sur OpenSearch, pgvector, Qdrant et Milvus.
Le problème
La recherche vectorielle conserve son graphe ANN en RAM, de sorte qu'à mesure que votre corpus s'accroît, l'empreinte mémoire — et le coût — de votre base de données vectorielle augmentent avec lui, rendant cette dépense difficile à prévoir. Vous ne voulez pas sacrifier le recall pour économiser de l'argent, ce qui vous oblige à choisir entre coût et qualité. De plus, il existe rarement un bon moyen de savoir quel store et quelle configuration parmi OpenSearch, pgvector, Qdrant ou Milvus sont les plus rentables avant de les déployer en production.
Fonctionnement
- 1
Quantifier les embeddings
S4 Embed quantifie vos embeddings en binaire (un graphe ANN en RAM jusqu'à 32x plus petit) et en un résidu int8 (des vecteurs sur disque environ 4x plus petits), réduisant ainsi la RAM que votre base de données vectorielle doit conserver.
- 2
Recherche en deux étapes pour maintenir le recall
Une étape grossière Hamming à 1 bit construit une courte présélection, puis un rescore exact la réorganise. En ajustant le point de fonctionnement de l'over-fetch et du rescore, vous maintenez votre objectif de recall tout en limitant la RAM.
- 3
Valider avec les données avant la bascule
s4embed prove, compare et tune mesurent la frontière recall/coût/latence sur vos propres vecteurs et génèrent une configuration déployable. Le mode shadow de la gateway effectue du dual-write et du shadow-compare sur les lectures réelles afin que vous puissiez observer le chemin compressé reproduire votre flux principal avant la bascule.
Points forts
La quantification binary réduit jusqu’à 32× le graphe ANN en RAM ; recall@10 de 0.976–1.000 sur un benchmark de 30k vecteurs (selon store / over-fetch) — choisissez le point de fonctionnement pour votre objectif de rappel.
Indépendant du store (OpenSearch / pgvector / Qdrant / Milvus) ; le mode shadow valide le chemin compressé par rapport à votre primaire avant tout cutover.
CLI FinOps — prove / compare / tune / drift — mesure le coût, le rappel et la latence, puis émet une config déployable.
Ce qui est inclus
- AMI Amazon Linux 2023 (x86_64) — une passerelle FinOps de recherche vectorielle qui s'exécute derrière votre propre load balancer, au sein de votre propre VPC
- Quantification binaire + int8 avec un pipeline de recherche à deux étapes (étape grossière Hamming 1-bit plus rescore exact), réduisant le graphe ANN en RAM jusqu'à 32x
- Un pipeline agnostique du store pour OpenSearch, pgvector, Qdrant et Milvus, sans lock-in
- Une CLI FinOps — s4embed prove (estimer la frontière rappel/coût/latence), compare (mesurer le rappel ANN en direct sur les différents stores), tune (générer une configuration respectant un budget de rappel + latence + RAM) et drift (surveiller la dérive des embeddings et le rappel, et recommander un nouveau tuning)
- Un mode shadow de la gateway qui effectue une double écriture et compare en mode shadow les lectures en direct, afin de confirmer que le chemin compressé reproduit votre primaire avant toute bascule
- Un quick-start CloudFormation qui provisionne les chemins OpenSearch et pgvector (Qdrant et Milvus se connectent en pointant la gateway vers votre endpoint existant)
- Fonctionnalités opérationnelles — authentification par clé API (si configurée), limites de taille de requête et de concurrence, readiness probe en fail-closed en cas de problème de facturation ou de store, métriques Prometheus et facturation mesurée à l'usage (par texte converti en embedding, document indexé et recherche traitée)
Cas d'usage
Charges de travail de recherche et de RAG à grande échelle où le coût en RAM de la base de données vectorielle augmente avec la taille du corpus
Équipes qui souhaitent réduire le coût de la recherche vectorielle tout en maintenant leur objectif de rappel
Mesurer quel store et quelle configuration parmi OpenSearch, pgvector, Qdrant et Milvus sont les plus rentables avant de basculer en production
Exécuter des recherches vectorielles avec une facturation mesurée à l'usage tout en conservant vos données et votre base de données vectorielle au sein de votre propre compte
FAQ
La compression nuit-elle au rappel ?
Vous choisissez le point de fonctionnement. Sur un benchmark de 30k vecteurs, la combinaison Hamming binaire + rescore float a atteint un recall@10 de 0.976 à 1.000 (OpenSearch 0.995, pgvector 0.996, Qdrant 1.000, Milvus 0.976) — le tout avec une réduction de RAM de 32x. Le rappel augmente avec l'over-fetch, vous ajustez donc le point de fonctionnement selon votre objectif de rappel. Le rappel évolue avec l'over-fetch, et le meilleur point est choisi par charge de travail.
Combien de RAM cela permet-il d'économiser ?
La quantification binaire rend le graphe ANN en RAM jusqu'à 32x plus petit, et le résidu int8 rend les vecteurs sur disque environ 4x plus petits. La réduction exacte dépend de votre corpus, de votre store et du point de fonctionnement choisi, donc le moyen le plus fiable de la dimensionner est de faire une estimation à partir de vos propres données avec s4embed prove et tune.
Quels vector stores sont supportés ?
Le pipeline est agnostique du store et compatible avec OpenSearch, pgvector, Qdrant et Milvus. Les chemins OpenSearch et pgvector peuvent être provisionnés avec le quick-start CloudFormation fourni, tandis que Qdrant et Milvus fonctionnent en pointant la gateway vers votre endpoint existant. s4embed compare vous permet de mesurer le rappel ANN en direct sur les différents stores.
Puis-je valider avant de basculer en production ?
Oui. s4embed prove et tune estiment une configuration sur vos propres vecteurs, et compare mesure le rappel ANN en direct sur les différents stores. Le mode shadow de la gateway effectue une double écriture et compare en mode shadow les lectures en direct afin que vous puissiez confirmer que le chemin compressé reproduit votre primaire avant la bascule, puis s4embed drift surveille la dérive des embeddings et le rappel et recommande un nouveau tuning.
Où résident mes données et comment sont-elles facturées ?
S4 Embed s'exécute sous forme d'une AMI Amazon Linux 2023 standard derrière votre propre load balancer, au sein de votre propre VPC. Vos données et votre base de données vectorielle ne quittent jamais votre compte, et il n'y a pas de lock-in. La facturation est mesurée à l'usage sur votre facture AWS — par texte converti en embedding, document indexé et recherche servie — et rapportée toutes les heures via le AWS Marketplace Metering Service.
Modèle de tarification
Facturation à l’usage (textes embedded, documents indexés, recherches servies) + EC2 dans votre propre VPC (AMI Amazon Linux 2023).
Autres produits S4
S4 — Squished S3
Gateway transparent de compression S3 par GPU
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch