Vector databanken
Een beheerde vectordatabase die gewoon PostgreSQL is
Sla embeddings op en doorzoek ze op betekenis, op pgvector die wij voor u beheren en waarvan we back-ups maken. Geen nieuwe database om te leren, geen cluster om in te schatten: maak een index aan, schrijf uw vectoren en beraag deze met de API-sleutel die u al hebt.
De database die u al vertrouwt, met één extra kolomtype
Een vectordatabase is doorgaans een tweede systeem dat naast het eerste draait: een andere cluster, een ander back-upverhaal, weer iets waarvoor u uit uw slaap wordt gehaald. Dit is pgvector binnen PostgreSQL — dezelfde engine, dezelfde duurzaamheid, dezelfde nachtelijke base-back-up en continue write-ahead log-archivering die al het andere hier krijgt. Uw index is een gewone tabel met een HNSW-index erop, waardoor deze snel is voor 'approximate nearest-neighbour'-zoekopdrachten en in elk ander opzicht saai, wat precies de eigenschap is die u om drie uur 's nachts wilt.
De breedte van uw model, niet een breedte die wij hebben gekozen
Bij de meeste beheerde vectordiensten moet u kiezen uit een korte lijst met dimensies. Die van u hoeft geen rond getal te zijn: alles van 1 tot 3072 wordt geaccepteerd en exact behouden, omdat een smallere vector wordt aangevuld tot de volgende fysieke breedte met nullen — wat de cosinus-, Euclidische en inproductafstand met precies niets verandert. Een model met 1408 dimensies scoort identiek aan een model dat er native voor is ontworpen, en bij het uitlezen krijgt u de 1408 waarden terug die u heeft opgeslagen, en nooit de opvulling.
Inbegrepen bij elk vector-abonnement
- Elke inbedbreedte tot 3072, en cosinus-, Euclidische of inproductafstand
- Metadata die bij elke vector wordt opgeslagen en waarop tijdens het opvragen wordt gefilterd
- Nachtelijke back-ups met een bewaartermijn van 30 dagen en point-in-time recovery
- Rij-niveau beveiliging, zodat de vectoren van de ene organisatie niet toegankelijk zijn vanuit die van een andere
Plannen en prijzen
Drie niveaus, geprijsd op basis van de twee dingen die ons daadwerkelijk iets kosten: hoeveel u opslaat en hoeveel u doorzoekt.
Geprijsd op basis van je configuratie
De kosten zijn afhankelijk van de regio, de machinegrootte, de bandbreedte en de opslag die u kiest, dus er is geen vast maandelijks bedrag dat we hier eerlijk kunnen vermelden. Vertel ons wat de workload is en we maken een offerte.
Aangedreven door 100% hernieuwbare energie
Elke server die we gebruiken, voor elk product, wordt aangedreven door hernieuwbare elektriciteit. Niet achteraf gecompenseerd — zo ingekocht.
- 100% duurzame elektriciteit voor al onze hosting
- Datacenters die draaien op een PUE van 1,1 tot 1,2
- Sites op ons gedeeld platform doorstaan de controles van de Green Web Foundation — een derde partij die u zelf kunt verifiëren
Veelgestelde vragen voor de aankoop
Met welke embeddingmodellen werkt dit?
Elke van allemaal. U stuurt ons de getallen die uw model heeft gegenereerd, dus OpenAI, Cohere, Voyage, een Sentence-Transformers-model op uw eigen machine en al het andere zijn voor ons hetzelfde. U geeft de breedte op wanneer u de index aanmaakt — 384, 768, 1024, 1536 en 3072 zijn allemaal gebruikelijk, evenals iets daartussenin.
Kan ik de breedte of afstandsfunctie van een index achteraf wijzigen?
Nee, en we zeggen dat liever openlijk dan dat u er zelf achter komt. Beide bepalen waar uw vectoren fysiek worden opgeslagen en hoe ze worden gerangschikt, dus het wijzigen van een van beide zou alles wat al in de index staat stilletjes ongeldig maken. Als u overstapt op een ander embedding-model, maak dan een tweede index aan en schrijf daarnaar – precies wat elke vectordatabase van u vraagt, en om dezelfde reden.
Is er iets anders aan zeer brede vectoren?
Ja, en dat is goed om te weten. Boven de 2.000 dimensies worden de waarden op halve precisie opgeslagen, omdat de HNSW-index van PostgreSQL geen kolom met volledige precisie accepteert die breder is dan dat. Voor modellen met 3072 dimensies is dit de aanpak die pgvector zelf aanbeveelt en het effect op de ranking is verwaarloosbaar — maar het is een reële afweging en u horen dat liever van ons dan dat u het zelf moet afleiden.
Krijg ik een database-verbindingsreeks?
Vandaag niet. U bereikt uw index via HTTPS met uw Zinn® API-sleutel, zo ingesteld dat een sleutel die kan zoeken niets anders kan doen in uw account. Dat is wat ons in staat stelt om zoekopdrachten eerlijk te meten en de rijen van de ene huurder onbereikbaar te houden voor die van een andere. Als een directe verbinding is wat u nodig hebt, laat het ons dan weten — we bouwen het liever omdat iemand erom heeft gevraagd dan dat we gissen.
Hoe wordt dit gemeten en kan ik de cijfers zelf controleren?
Op twee punten: hoeveel u opslaat en hoeveel zoekopdrachten u uitvoert in een kalendermaand. Beide staan op uw dashboard zodra ze plaatsvinden. Opslag is een gepubliceerde formule in plaats van een fysieke tabelgrootte — rij-overhead, plus de opgeslagen breedte, plus de lengte van uw eigen ids en metagegevens — juist zodat u het bedrag dat we bij u in rekening brengen kunt narekenen in plaats van dat u ons op ons woord hoeft te geloven.