Mga database ng vector
Isang managed vector database na PostgreSQL lamang
Mag-imbak ng mga embedding at hanapin ang mga ito ayon sa kahulugan, sa pgvector na pinapatakbo at binibigyan namin ng backup para sa iyo. Walang bagong datastore na dapat matutunan, walang cluster na dapat sukatin — lumikha ng index, isulat ang iyong mga vector, at i-query ito gamit ang API key na mayroon ka na.
Ang database na pinagkakatiwalaan mo na, na may isang karagdagang uri ng column
Ang isang vector database ay kadalasang pangalawang sistema na tatakbo kasabay ng una: isa pang cluster, isa pang kuwento ng backup, isa pang bagay na gigisingan. Ito ang pgvector sa loob ng PostgreSQL — ang parehong makina, ang parehong tibay, ang parehong nightly base backup at tuloy-tuloy na write-ahead log archiving na nakukuha ng lahat ng iba pa rito. Ang iyong index ay isang ordinaryong table na may HNSW index dito, kaya mabilis ito para sa approximate nearest-neighbour search at boring sa bawat iba pang aspeto, na siyang katangiang gusto mo sa alas-tres ng umaga.
Ang lapad ng iyong modelo, hindi ang lapad na pinili namin
Karamihan sa mga pinamamahalaang vector service ay nagpapasya sa iyo mula sa maikling listahan ng mga dimensyon. Ang sa iyo ay hindi kailangang maging isang bilog na numero: ang anuman mula 1 hanggang 3072 ay tinatanggap at eksaktong pinapanatili, dahil ang isang mas makitid na vector ay pinupunan sa susunod na pisikal na lapad ng mga zero — na nagbabago sa cosine, Euclidean at panloob na produktong distansya nang eksaktong wala. Ang isang modelong may 1408 na dimensyon ay kapareho ng ranggo sa isa na may katutubong sukat para dito, at ang mga pagbasa ay nagbabalik sa iyo ng 1408 na halaga na iyong itinakda, hindi kailanman ang padding.
Kasama sa bawat plano ng vector
- Anumang lawak ng embedding hanggang 3072, at cosine, Euclidean o inner-product na distansya
- Metadata na naka-imbak sa bawat vector, at na-filter sa oras ng query
- Mga nightly backup na may 30-araw na pagpapanatili at point-in-time recovery
- Seguridad sa antas ng row, kaya ang mga vector ng isang organisasyon ay hindi maaabot ng iba
Mga plano at pagpepresyo
Tatlong tier, na may presyo batay sa dalawang bagay na talagang nagkakahalaga sa amin: kung gaano kalaki ang iyong iniimbak at kung gaano kadalas ka maghanap.
May presyo batay sa iyong configuration
Nakasalalay ang gastos sa rehiyon, laki ng makina, bandwidth, at storage na pipiliin mo, kaya walang iisang buwanang halaga na tapat naming mailalagay rito. Ibigay sa amin ang workload at bibigyan ka namin ng presyo.
Pinapagana ng 100% na nababagong enerhiya
Bawat server na pinatatakbo namin, sa bawat produkto, ay pinatatakbo ng nababagong kuryente. Hindi ito binabawi pagkatapos — ganoon na talaga ito kinukuha.
- 100% nababagong kuryente sa lahat ng aming pag-host
- Mga data centre na tumatakbo sa PUE na 1.1 hanggang 1.2
- Ang mga site sa aming shared platform ay nakapasa sa mga pagsusuri ng Green Web Foundation — isang third party na maaari mong i-verify nang mag-isa
Mga tanong ng mga tao bago sila bumili
Aling mga embedding model ang gumagana rito?
Alinman sa mga ito. Ipinapadala ninyo sa amin ang mga numerong ginawa ng inyong modelo, kaya ang OpenAI, Cohere, Voyage, isang Sentence-Transformers na modelo sa inyong sariling makina, at anupaman ay pare-pareho lang sa amin. Sinasabi ninyo sa amin ang lapad kapag ginawa ninyo ang index — ang 384, 768, 1024, 1536, at 3072 ay karaniwan, gayundin ang anumang nasa pagitan nito.
Maaari ko bang baguhin ang lapad o function ng distansya ng isang index sa ibang pagkakataon?
Hindi, at mas gugustuhin naming sabihin iyon nang tuwiran kaysa hayaan kang madiskubre ito. Ang pareho ay nagpapasya kung saan pisikal na nakaimbak ang iyong mga vector at kung paano sila niraranggo, kaya ang pagbabago sa alinman ay tahimik na magpapawalang-bisa sa lahat ng nasa index na. Kung lumipat ka sa ibang embedding model, gumawa ng pangalawang index at sumulat dito — ang parehong bagay na hinihiling sa iyo ng bawat vector database, at para sa parehong dahilan.
Mayroon bang pagkakaiba ang napakalawak na mga vector?
Oo, at nararapat itong malaman. Higit sa 2,000 dimensyon, ang mga halaga ay naka-store sa kalahating katumpakan (half precision), dahil ang HNSW index ng PostgreSQL ay hindi tumatanggap ng buong-katumpakang kolum na mas malawak kaysa rito. Para sa mga modelong may 3072 na dimensyon, ito ang diskarte na inirerekomenda mismo ng pgvector at bale-wala ang epekto sa ranking — ngunit ito ay isang tunay na trade-off at dapat ninyong marinig ito mula sa amin kaysa sa hulaan lang.
May makukuha ba akong connection string ng database?
Hindi ngayon. Naaabot mo ang iyong index sa pamamagitan ng HTTPS gamit ang iyong Zinn® API key, na may saklaw upang ang isang key na maaaring maghanap ay hindi makakagawa ng anupaman sa iyong account. Iyon ang nagbibigay-daan sa amin na tapat na sukatin ang mga query at panatilihing hindi naa-access ang mga row ng isang tenant mula sa iba. Kung direktang koneksyon ang kailangan mo, sabihin sa amin — mas gusto naming itugayo ito dahil may nagtanong kaysa manghula.
Paano ito sinusukat, at maaari ko bang suriin ang mga numero sa aking sarili?
Sa dalawang metro: kung gaano kalaki ang iyong iniimbak at kung gaano karaming paghahanap ang iyong isinasagawa sa isang buwan sa kalendaryo. Pareho silang nasa iyong dashboard habang nagaganap ang mga ito. Ang imbakan ay isang nai-publish na formula sa halip na pisikal na laki ng talahanayan — overhead ng row, kasama ang nakaimbak na lapad, kasama ang haba ng iyong sariling mga id at metadata — nang tiyak upang maulit mo ang pigura na ibinabill namin sa iyo sa halip na paniwalaan lamang ang aming salita.