Pinecone sau pgvector: viteza de 3× vine cu un cost de 4,8×

În testul Markaicode, pe un milion de vectori cu 768 de dimensiuni, configurația Pinecone s1.x1 a atins 1.200 de interogări pe secundă, față de 400 pentru pgvector cu IVFFlat. Recall@10 a fost de 99,2%, respectiv 99,1%, iar costul atribuit unei mii de interogări a fost de 0,12 dolari, respectiv 0,025 dolari: un raport de 3× la debit și 4,8× la cost.

Pentru o echipă care alege între cele două, acesta este un rezultat despre configurațiile testate, nu un preț sau o viteză garantată pentru orice implementare. Pinecone poate justifica un serviciu administrat când căutarea susținută și efortul de operare contează mult. pgvector devine atractiv când interogările vectoriale depind de datele relaționale aflate deja în PostgreSQL, mai ales dacă baza are capacitate disponibilă. Indexul ales și forma traficului pot schimba ambele părți ale comparației.

Ce măsoară diferența de viteză

Testul a pus un pod Pinecone s1.x1 față în față cu pgvector 0.7.0, IVFFlat și PostgreSQL pe o instanță AWS RDS. A folosit vectori sintetici și interogări aleatoare, cu clientul în aceeași regiune cloud. Debitul rezultat aparține întregii configurații, inclusiv infrastructurii și reglajelor; nu este o proprietate permanentă a extensiei sau a serviciului.

Metodologia publicată lasă o incertitudine relevantă. Ea descrie cereri executate secvențial, dar debitul din tabel nu se împacă cu latențele mediane declarate pentru o serie strict secvențială. În plus, atribuie configurației IVFFlat parametrul ef_search, folosit de HNSW. Raporturile din tabel pot fi calculate, însă descrierea nu oferă o bază suficient de clară pentru a le reproduce sau transforma în capacitate promisă. Și calculul costului omite valorile numerice ale tarifelor orare folosite, astfel încât raportul de cost trebuie tratat ca rezultat declarat al testului.

Același recall cere reglaje diferite

Documentația pgvector precizează că, implicit, căutarea vecinilor este exactă. Indexurile aproximative HNSW și IVFFlat schimbă o parte din recall pentru viteză. La HNSW, parametrul de căutare este hnsw.ef_search; la IVFFlat contează numărul de liste și ivfflat.probes. Creșterea efortului de căutare poate îmbunătăți recallul, dar mărește timpul sau resursele consumate. Prin urmare, comparația utilă fixează întâi aceeași țintă de recall și abia apoi măsoară latența și debitul.

Filtrele pot răsturna rezultatul unei probe fără filtre. În PostgreSQL, un index vectorial aproximativ selectează candidați, iar condiția SQL poate elimina ulterior o parte dintre ei; o cerere cu LIMIT poate returna astfel mai puține rezultate decât s-au cerut. Un index obișnuit pe coloana filtrată poate fi mai potrivit când filtrul este selectiv. Pentru căutarea aproximativă, scanările iterative pot continua prin index până apar suficiente potriviri sau este atinsă limita configurată. Alegerea dintre aceste variante depinde de distribuția datelor, nu doar de mărimea corpusului.

Comparația Pinecone arată că propriile teste mai vechi preced pgvector 0.8.0, versiune care a introdus scanările iterative, și descrie podurile ca linie de produs retrasă. Rezultatele unui pod și ale unui index IVFFlat mai vechi nu stabilesc performanța unui index Pinecone On-Demand ori a unui pgvector configurat astăzi cu HNSW. Când aplicația filtrează după client, limbă sau colecție, aceeași probă trebuie să păstreze și selectivitatea acelor filtre; altfel, un recall bun fără filtre poate ascunde rezultate incomplete în interogările reale.

Costul atribuit podului nu este factura On-Demand

Costul pe mia de cereri din test distribuie cheltuiala infrastructurii peste interogările procesate. La trafic redus, capacitatea rezervată continuă să coste între cereri, astfel încât prețul efectiv al unei cereri depinde de cât este folosită. Nici instanța PostgreSQL nu este gratuită când stă inactivă. Dacă ea deservește deja aplicația și are resurse libere, însă, costul suplimentar al căutării poate fi mai mic decât costul unei instanțe cumpărate numai pentru vectori.

Tarifele Pinecone prezintă pentru On-Demand dimensiuni de consum precum stocarea, unitățile de citire și cele de scriere, precum și condiții diferite între planuri. Costul atribuit unui pod în test nu poate fi înmulțit cu numărul estimat de cereri pentru a prognoza factura On-Demand. Contează mărimea vectorilor și a metadatelor, frecvența actualizărilor, cantitatea de date citită și planul ales. Pentru pgvector, aceeași estimare trebuie să includă memoria, indexul și capacitatea necesară la vârf, nu doar spațiul ocupat de valorile vectoriale.

Trei dimensiuni de corpus, două profiluri de trafic

Un calcul condițional face mai clară alegerea. Presupunem vectori de 768 de dimensiuni și două profiluri: 10 interogări pe minut sau 100 pe secundă, menținute constant. Formula tipului vector din pgvector dă 3.080 de octeți pentru un astfel de vector. Cifrele de stocare de mai jos includ numai aceste valori; rândurile PostgreSQL, indexul, metadatele și replicile măresc necesarul. Profilul lent înseamnă aproximativ 432.000 de cereri într-o lună ipotetică de 30 de zile, iar cel intens aproximativ 259 de milioane.

• 100.000 de vectori: valorile ocupă aproximativ 308 MB. La 10 cereri pe minut, o bază PostgreSQL existentă, cu resurse libere, are un avantaj economic plauzibil: traficul nu cere debitul maxim raportat în test. La 100 pe secundă, concurența și latența devin decisive. Testul pe un milion de vectori nu indică ce debit ar avea vreuna dintre configurații la acest corpus mai mic.
• Un milion de vectori: valorile ocupă aproximativ 3,08 GB înainte de index. La 10 cereri pe minut, gradul de utilizare a capacității rezervate influențează costul mai mult decât diferența dintre debitele maxime. La 100 pe secundă, cererea ar reprezenta un sfert din debitul raportat pentru configurația pgvector și o doisprezecime din cel raportat pentru podul Pinecone. Aceasta este doar o comparație aritmetică cu testul publicat; nu garantează latența sau recallul sub concurența aplicației.
• Zece milioane de vectori: valorile singure ajung la aproximativ 30,8 GB. La 10 cereri pe minut, dimensiunea indexului și memoria pot domina costul chiar dacă traficul este modest. La 100 pe secundă, trebuie dimensionată capacitatea pentru index și pentru vârfurile de cereri. Înmulțirea cu zece a debitului ori a costului măsurat pe corpusul mai mic nu ar descrie comportamentul acestei configurații.

Profilurile separă două întrebări economice. Pentru cereri rare contează cât costă păstrarea datelor și a capacității disponibile între ele. Pentru cereri susținute contează capacitatea care atinge simultan ținta de latență și pe cea de recall. Un singur cost mediu pe interogare nu surprinde ambele situații.

Ce câștigă echipa păstrând vectorii în PostgreSQL

Cu pgvector, embeddingurile pot rămâne lângă identificatori, permisiuni și celelalte date ale aplicației. O interogare poate combina filtrarea SQL cu ordonarea după distanța vectorială, iar actualizarea vectorului și a rândului asociat poate folosi aceeași tranzacție. Acest lucru este valoros când rezultatele depind de relații sau reguli de acces care se schimbă des. Echipa păstrează însă răspunderea pentru index, planul de interogare, memorie și întreținerea bazei.

Cu Pinecone, administrarea infrastructurii specializate trece la furnizor, dar aplicația trebuie să mențină consecvente datele din două sisteme. Un volum mare de căutări și filtrele care trebuie să returneze constant numărul cerut de rezultate pot justifica această separare. Dacă sarcina vectorială este moderată și strâns legată de tranzacțiile SQL, avantajul unei singure baze poate cântări mai mult decât debitul maxim al unui test făcut pe altă configurație.

Citește și:

• ChatGPT Business sau Microsoft 365 Copilot: datele de lucru decid
• Brevo sau Mailchimp: lista mare nu înseamnă automat același cost
• Microsoft Defender sau Bitdefender: protecția egală ascunde costul de performanță