Bases de données vectorielles
Une base de données vectorielle gérée qui n'est autre que PostgreSQL
Stockez des vecteurs et effectuez des recherches par similarité sémantique, sur pgvector que nous gérons et sauvegardons pour vous. Aucun nouveau stockage à apprendre, aucun cluster à dimensionner : créez un index, écrivez vos vecteurs et interrogez-les avec la clé API que vous possédez déjà.
La base de données à laquelle vous faites déjà confiance, avec un type de colonne supplémentaire
Une base de données vectorielle est généralement un second système à faire fonctionner en parallèle du premier : un autre cluster, une autre stratégie de sauvegarde, un autre service qui risque de vous réveiller la nuit. Il s'agit de pgvector dans PostgreSQL — le même moteur, la même durabilité, la même sauvegarde de base nocturne et la même journalisation continue des transactions (write-ahead log archiving) dont bénéficie tout le reste. Votre index est une table ordinaire dotée d'un index HNSW, ce qui la rend rapide pour la recherche des k plus proches voisins approximatifs et ennuyeuse à tout autre égard, ce qui est la qualité recherchée à trois heures du matin.
La largeur de votre modèle, et non une largeur que nous avons choisie
La plupart des services de vecteurs gérés vous obligent à choisir parmi une liste restreinte de dimensions. Le vôtre n'a pas besoin d'être un nombre rond : n'importe quelle valeur de 1 à 3072 est acceptée et conservée à l'identique, car un vecteur plus étroit est complété par des zéros jusqu'à la largeur physique suivante, ce qui ne modifie en rien les distances cosinus, euclidienne et le produit scalaire. Un modèle à 1408 dimensions se classe de manière identique à un modèle configuré nativement pour cette taille, et les lectures vous restituent les 1408 valeurs que vous avez stockées, et jamais le remplissage.
Inclus dans chaque forfait vectoriel
- N'importe quelle largeur d'incorporation jusqu'à 3072, et distance cosinus, euclidienne ou de produit scalaire
- Métadonnées stockées avec chaque vecteur et filtrées lors de la requête
- Sauvegardes nocturnes avec conservation de 30 jours et restauration à un moment précis
- Sécurité au niveau des lignes, afin que les vecteurs d'une organisation soient inaccessibles depuis une autre
Formules et tarifs
Trois forfaits, tarifés selon les deux seules choses qui nous coûtent réellement : le volume de stockage et le volume de recherche.
Tarifé selon votre configuration
Le coût dépend de la région, de la taille de la machine, de la bande passante et du stockage que vous choisissez. Il n'y a donc pas de chiffre mensuel unique que nous pourrions honnêtement afficher ici. Indiquez-nous votre charge de travail et nous vous établirons un devis.
Alimenté par des énergies 100 % renouvelables
Chaque serveur que nous faisons fonctionner, pour chaque produit, est alimenté par de l'électricité renouvelable. Pas compensée après coup : obtenue directement ainsi.
- 100 % d'électricité renouvelable pour l'ensemble de notre hébergement
- Centres de données fonctionnant avec un PUE de 1,1 à 1,2
- Les sites de notre plateforme partagée réussissent les contrôles de la Green Web Foundation, un tiers que vous pouvez vérifier par vous-même
Questions que les gens se posent avant d'acheter
Avec quels modèles d'intégration cela fonctionne-t-il ?
N'importe lequel. Vous nous envoyez les nombres produits par votre modèle, de sorte que OpenAI, Cohere, Voyage, un modèle Sentence-Transformers sur votre propre machine et tout le reste nous reviennent au même. Vous nous indiquez la largeur lors de la création de l'index : 384, 768, 1024, 1536 et 3072 sont des valeurs courantes, tout comme toute autre valeur intermédiaire.
Puis-je modifier la largeur ou la fonction de distance d'un index ultérieurement ?
Non, et nous préférons le dire clairement plutôt que de vous laisser le découvrir. Tous deux déterminent l'emplacement physique de stockage de vos vecteurs ainsi que leur mode de classement, de sorte que la modification de l'un ou de l'autre invaliderait silencieusement l'ensemble des données déjà présentes dans l'index. Si vous optez pour un autre modèle d'incorporation, créez un second index et écrivez dedans : c'est ce que demande toute base de données vectorielle, et pour la même raison.
Existe-t-il des particularités concernant les vecteurs très larges ?
Oui, et cela vaut la peine de le savoir. Au-delà de 2 000 dimensions, les valeurs sont stockées en demi-précision, car l'index HNSW de PostgreSQL n'accepte pas de colonne en précision complète plus large que cela. Pour les modèles à 3072 dimensions, c'est l'approche que pgvector lui-même recommande et l'effet sur le classement est négligeable — mais c'est un réel compromis et vous devez l'entendre de notre part plutôt que de le déduire.
Obtiens-je une chaîne de connexion à la base de données ?
Pas aujourd'hui. Vous accédez à votre index via HTTPS avec votre clé API Zinn®, délimitée de sorte qu'une clé de recherche ne puisse rien faire d'autre dans votre compte. C'est ce qui nous permet de comptabiliser les requêtes en toute transparence et d'empêcher qu'un client accède aux lignes d'un autre. Si vous avez besoin d'une connexion directe, dites-le-nous : nous préférons la construire à la suite d'une demande plutôt que de deviner.
Comment est-ce mesuré, et puis-je vérifier les chiffres moi-même ?
Sur deux compteurs : la quantité de données que vous stockez et le nombre de recherches que vous effectuez au cours d'un mois calendaire. Tous deux apparaissent sur votre tableau de bord en temps réel. Le stockage repose sur une formule publiée plutôt que sur la taille physique d'une table — surcharge par ligne, plus la largeur stockée, plus la longueur de vos propres identifiants et métadonnées —, précisément afin que vous puissiez reproduire le chiffre qui vous est facturé au lieu de simplement nous croire sur parole.